{"id":"IL-0224","org":"Amazon Web Services","date":"2012-12-24","docs":[],"title":{"en":"ELB control plane APIs failed in US-East, and load balancers it then changed broke, after ELB state data was deleted","ko":"유지보수 작업이 운영 ELB 상태 데이터 일부를 지워 US-East 리전의 Elastic Load Balancer 일부가 오류를 내고 나머지는 확장하거나 바꿀 수 없게 됐다."},"domain":["aws","networking"],"impact":{"scope":"Applications using Amazon ELB in the US-East Region: up to 6.8% of running load balancers degraded with errors, and the rest could not scale or be modified","users":"unknown","region":"US-East"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":null,"related":[],"sources":[{"url":"https://aws.amazon.com/message/680587/","kind":"official-status","archived":"https://web.archive.org/web/20261101130553/https://aws.amazon.com/message/680587/"}],"summary":{"en":"The ELB control plane uses state data to manage the configuration of the load balancers in a region, for example which backend hosts each load balancer sends traffic to. A maintenance process run against production deleted part of this data at 12:24 PM PST on 24 December, and the developer who ran it did not notice. AWS normally blocks all access to production service data, but the ELB service had given a few developers extra access for operational processes that were being automated, and that access had been set as persistent instead of requiring approval for each use. The missing data was not needed for basic operation, so running load balancers kept working until the control plane changed them; then the control plane, lacking the data, configured them wrongly.\n\nAt 5:02 PM PST the team disabled several ELB control plane workflows, including scaling and descaling, so that no more running load balancers would be changed; the rest kept working but could not scale or be modified by customers. Some affected load balancers were recovered by hand that night. The first method used to restore the state data to just before 12:24 PM took several hours and did not produce a usable snapshot. With another process, a snapshot from just before the deletion was restored at 2:45 AM PST on 25 December, merged with the state changes since then and verified by 5:40 AM. Workflows and APIs were then re-enabled slowly: most by 8:15 AM, almost all affected load balancers fully working by 10:30 AM, and normal operation announced at 12:05 PM PST.","ko":"ELB 상태 데이터는 ELB 제어 평면이 리전의 로드 밸런서 설정을 관리하는 데 쓰는 데이터이고, 로드 밸런서마다 트래픽을 보낼 백엔드 호스트 목록도 여기에 있다. 2012-12-24 PST 오후 12시 24분에 운영 환경 접근 권한을 가진 소수의 개발자 가운데 한 명이 유지보수 프로세스를 실수로 운영 ELB 상태 데이터를 대상으로 실행해 데이터 일부를 논리적으로 지웠다. AWS 는 운영 데이터를 모든 접근을 막는 정책으로 보호하지만, ELB 는 아직 자동화가 끝나지 않은 운영 절차를 돌리도록 소수 개발자에게 추가 접근을 허용했다. 이 접근은 접근마다 승인을 받는 방식이 아니라 상시 권한으로 잘못 설정돼 있었다.\n\n삭제 직후 제어 평면의 API 지연과 오류율이 올랐다. 팀은 몇 시간 동안 일부만 실패하는 API 오류를 쫓았다. 그사이 제어 평면이 설정을 바꾼 로드 밸런서는 필요한 상태 데이터가 없어 잘못 설정됐고, 성능 저하와 오류를 냈다. 이 로드 밸런서들을 파고들어 사라진 상태 데이터가 원인임을 확인한 뒤, 팀은 오후 5시 2분에 확장과 축소를 포함한 제어 평면 워크플로 여러 개를 껐다. 정점에서 돌고 있는 로드 밸런서의 6.8% 가 영향을 받았고, 나머지는 정상으로 돌았지만 확장하거나 바꿀 수 없었다.\n\n팀은 월요일 밤에 일부 로드 밸런서를 손으로 복구하고, 상태 데이터를 사고 직전 시점으로 되돌린 뒤 그 뒤의 변경을 합치는 방식으로 복구를 시도했다. 처음 쓴 복원 방법은 몇 시간이 걸리고도 쓸 수 있는 스냅샷을 만들지 못해 복구가 늦어졌다. 다른 방법으로 12월 25일 오전 2시 45분에 삭제 직전 시점의 스냅샷을 복원했고, 오전 5시 40분에 그 뒤의 변경을 합치고 검증을 마쳤다. 이어 워크플로와 API 를 천천히 다시 켜 오전 8시 15분에 대부분을 되살렸고, 오전 10시 30분에 영향받은 로드 밸런서가 거의 모두 정상으로 돌아왔다. 팀은 서비스를 더 지켜본 뒤 오후 12시 5분에 정상 운영을 알렸다."},"trigger":{"en":"One of the very few developers with access to the production ELB environment inadvertently ran a maintenance process against the production ELB state data, and it logically deleted part of that data.","ko":"운영 환경에 접근할 수 있는 아주 적은 수의 개발자 가운데 한 명이 유지보수 프로세스를 실수로 운영 ELB 상태 데이터를 대상으로 실행해 데이터 일부를 논리적으로 지웠다. 그 개발자는 그때 실수를 알아채지 못했다."},"severity":"unknown","symptoms":["control-plane-slow","high-error-rate","high-latency"],"timeline":{"detected_after":null,"resolved_after":"22h 6m"},"date_kind":"incident","detection":{"en":"The ELB team noticed the control plane API errors first; the missing state data was found only after the team investigated load balancers that had become degraded.","ko":"데이터가 지워진 뒤 ELB 제어 평면에서 로드 밸런서를 관리하는 API 호출의 지연과 오류율이 올랐고, 기술팀은 이 API 오류부터 살폈다. 사라진 상태 데이터는 팀이 성능이 떨어진 로드 밸런서를 깊이 파고든 뒤에야 찾았다. 데이터를 지운 개발자는 그때 실수를 알아채지 못했다."},"components":["cloud-load-balancer"],"root_cause":"human-operation","remediation":[{"text":{"en":"Disabled several ELB control plane workflows, including scaling and descaling","ko":"PST 오후 5시 2분에 확장과 축소 워크플로를 포함한 ELB 제어 평면 워크플로 여러 개를 꺼서, 돌고 있는 다른 로드 밸런서가 사라진 상태 데이터의 영향을 받지 않게 했다."}},{"text":{"en":"Recovered some of the affected running load balancers by hand","ko":"영향받은 로드 밸런서 가운데 일부를 월요일 밤에 손으로 복구했다."}},{"text":{"en":"Restored a snapshot of the ELB state data from just before the deletion, using an alternate recovery process","ko":"처음 쓴 복원 방법이 몇 시간 걸리고도 쓸 수 있는 스냅샷을 만들지 못하자 다른 복구 절차를 찾아, 12월 25일 PST 오전 2시 45분에 데이터가 지워지기 직전 시점의 ELB 상태 데이터 스냅샷을 복원했다."}},{"text":{"en":"Merged the restored data with the state changes since the snapshot and verified it","ko":"복원한 데이터에 스냅샷 이후의 시스템 상태 변경을 합쳤고, 오전 5시 40분에 병합과 새 상태 데이터 검증을 마쳤다."}},{"text":{"en":"Re-enabled the ELB workflows and APIs slowly while recovering each affected load balancer","ko":"영향받지 않은 로드 밸런서를 건드리지 않고 영향받은 로드 밸런서마다 제대로 복구되도록 ELB 워크플로와 API 를 천천히 다시 켰다. 오전 8시 15분에 대부분의 API 와 백엔드 워크플로가 다시 켜졌고, 오전 10시 30분에 영향받은 로드 밸런서가 거의 모두 정상으로 돌아왔다."}}],"action_items":[{"text":{"en":"Require per-incident Change Management approval for all access to production ELB state data","ko":"운영 ELB 상태 데이터의 접근 통제를 바꿨다. 상시 권한으로 잘못 설정된 접근을 되돌렸고, 운영 ELB 데이터에 접근할 때마다 사고 건별 Change Management 승인을 받게 했다."}},{"text":{"en":"Change the data recovery process so ELB state data can be recovered much faster","ko":"이번에 배운 것을 반영해 데이터 복구 절차를 고쳤다. AWS 는 비슷한 일이 생기면 ELB 상태 데이터를 훨씬 빨리 복구할 수 있다고 봤다."}},{"text":{"en":"Reprogram the ELB control plane workflows to reconcile central service data with current load balancer state","ko":"ELB 제어 평면 워크플로가 중앙 서비스 데이터와 현재 로드 밸런서 상태를 더 신중하게 맞추도록 다시 짜, 논리적 데이터 손실이나 손상이 생겨도 손으로 복원하지 않고 자동으로 복구되게 한다."}}],"contributing":["no-safeguard-on-destructive-change","backup-unverified","automation-amplified"],"recurrence_of":null,"symptoms_text":{"en":"From 12:24 PM PST on 24 December 2012, the Amazon Elastic Load Balancing (ELB) control plane in the US-East Region showed high latency and error rates for API calls that manage load balancers. Running load balancers kept handling requests normally at first.\n\nSome APIs succeeded and others failed: customers could create and manage new load balancers but could not manage existing ones. This puzzled the ELB team, which spent the next couple of hours on the API errors.\n\nLater some running load balancers began to perform badly and return errors for the customer applications behind them. This happened only after the ELB control plane had changed a load balancer, because a user modified its configuration or because it had to scale up or down; at the peak, 6.8% of running ELB load balancers were affected, and the rest operated correctly but could not scale or be modified by customers. Only when the team dug into these degraded load balancers did it find that part of the ELB state data was missing.","ko":"2012-12-24 PST 오후 12시 24분부터 US-East 리전의 ELB 제어 평면에서 로드 밸런서를 관리하는 API 호출의 지연과 오류율이 올랐다. 이때는 돌고 있는 로드 밸런서의 요청 처리에 영향이 없었다.\n\n기술팀은 이후 몇 시간 동안 API 오류를 쫓았지만 많은 API 가 성공하고 일부만 실패해 원인을 짚지 못했다. 고객은 새 로드 밸런서를 만들고 관리할 수 있었지만 기존 로드 밸런서는 관리할 수 없었다.\n\n시간이 지나자 일부 고객의 돌고 있는 로드 밸런서에서 성능 문제가 나타났다. 이 문제는 제어 평면이 설정을 바꾼 로드 밸런서에서만 일어났다. 사용자가 설정을 바꿨거나 로드 밸런서가 확장 또는 축소된 경우였다. 제어 평면에 필요한 상태 데이터가 없어 이 로드 밸런서들이 잘못 설정됐고, 이를 쓰는 고객 애플리케이션에 성능 저하와 오류가 났다. 팀은 성능이 떨어진 로드 밸런서를 깊이 파고든 뒤에야 ELB 상태 데이터가 사라진 것이 원인임을 찾았다.\n\n정점에서는 돌고 있는 ELB 로드 밸런서의 6.8% 가 영향을 받았다. 나머지 로드 밸런서는 제대로 동작했지만 확장할 수도, 고객이 설정을 바꿀 수도 없었다."},"updated_at":"2026-11-14T05:53:43.993538Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0224","org_slug":"amazon-web-services"}