{"id":"IL-0150","org":"Amazon Web Services","date":"2025-10-19","docs":[],"title":{"en":"A latent race condition in DynamoDB's DNS automation left an empty DNS record for dynamodb.us-east-1.amazonaws.com, and the DynamoDB and EC2 launch failures that followed caused EKS, ECS and Fargate container launch failures and cluster scaling delays in us-east-1","ko":"DynamoDB DNS 자동화의 경쟁 조건이 us-east-1 리전 엔드포인트의 DNS 레코드를 비워 DynamoDB 와 EC2 인스턴스 시작이 실패했고, 그 여파로 EKS, ECS, Fargate 의 컨테이너 시작과 클러스터 스케일링이 14시간 넘게 막혔다"},"domain":["aws","kubernetes","networking"],"impact":{"scope":"DynamoDB API, EC2 instance launches, Network Load Balancer, Lambda, ECS, EKS, Fargate, Amazon Connect, STS, IAM sign-in, Redshift, AWS Support and other services that depend on them; EKS, ECS and Fargate had container launch failures and cluster scaling delays","users":"unknown","region":"us-east-1 (N. Virginia)"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":{"en":"A single DNS record that automation can empty is enough to take a widely used regional endpoint off the network, and every service built on it fails in turn. A check made once at the start of a long operation can be stale by the time the operation writes its result.\n\nRecovery of the dependency is not recovery of the dependents: systems that lost state during the outage, such as EC2's droplet leases and network propagation backlog, can collapse under their own catch-up work, and container services that rely on new instance launches keep failing to launch and scale until that work is done.","ko":"DNS 자동화가 스스로 고칠 수 없는 상태에 빠지면 사람이 손대기 전까지 리전 엔드포인트가 통째로 사라진다. 계획이 더 새로운지 적용 전에 한 번만 확인하면, 처리가 길게 지연됐을 때 그 확인 결과는 낡은 정보가 된다.\n\n기반 서비스가 돌아와도 그 위의 시스템은 밀린 작업 때문에 혼잡 붕괴에 빠질 수 있다. 이번에는 정해진 복구 절차가 없어 엔지니어들이 여러 조치를 조심스럽게 시도한 끝에 04시 14분에야 스로틀링과 호스트 재시작으로 풀었다. EKS 처럼 EC2 인스턴스 시작에 기대는 서비스는 DynamoDB 가 회복된 뒤에도 EC2 와 네트워크 전파가 정상화될 때까지 컨테이너 시작과 스케일링이 막혔다. 헬스 체크에 따른 자동 장애 조치는 상태 정보가 흔들릴 때 정상 용량까지 빼 버릴 수 있다."},"related":[],"sources":[{"url":"https://aws.amazon.com/message/101925/","kind":"official-status","license":"unknown","archived":null}],"summary":{"en":"DynamoDB keeps hundreds of thousands of DNS records for its load balancers in each region, maintained by automation in two parts. The DNS Planner watches load balancer health and capacity and produces new DNS plans; the DNS Enactor, running independently in three availability zones, applies each plan to Route 53 in a transaction. Before applying a plan, an Enactor checks once that it is newer than the plan already applied. That night one Enactor was badly delayed by retries while the Planner kept producing new plans and a second Enactor applied a much newer one. When the second Enactor finished, its clean-up deleted plans far older than its own. At the same moment the delayed Enactor, whose newer-than check was by now stale, wrote its old plan over the regional endpoint; the clean-up then deleted that plan, leaving the record for dynamodb.us-east-1.amazonaws.com empty. With the active plan gone, no Enactor could apply later plans, and the automation could not repair itself.\n\nEngineers identified DynamoDB's DNS state as the source at 12:38 AM. By 1:15 AM temporary mitigations let some internal services connect and repaired internal tooling, and manual operator intervention restored all DNS information by 2:25 AM. Clients recovered as cached DNS records expired between 2:25 and 2:40 AM.\n\nEC2 took much longer. The DropletWorkflow Manager (DWFM), which holds a lease on every physical server (droplet) that hosts instances, depends on DynamoDB for its periodic state checks, so leases across the fleet had slowly been timing out. When DynamoDB returned, DWFM tried to re-establish leases with so many droplets that the work timed out and was queued again, a congestive collapse with no established recovery procedure. At 4:14 AM engineers throttled incoming work and selectively restarted DWFM hosts, and by 5:28 AM all leases were back. The Network Manager then had a large backlog of network configuration for new instances, so new instances lacked connectivity until 10:36 AM. NLB's health checks brought those instances into service before their network state had propagated, which made health checks flap and triggered automatic availability zone DNS failover that removed capacity; engineers disabled automatic health check failover at 9:36 AM. Throttles were relaxed from 11:23 AM and EC2 was fully recovered at 1:50 PM.\n\nECS, EKS and Fargate in us-east-1 had container launch failures and cluster scaling delays from 11:45 PM PDT on 19 October until the services recovered at 2:20 PM PDT on 20 October.","ko":"DynamoDB 는 리전마다 아주 많은 로드 밸런서를 운영하고, 이를 위해 DNS 레코드 수십만 개를 자동화로 관리한다. DNS 관리 시스템은 두 구성 요소로 나뉜다. DNS Planner 는 로드 밸런서의 상태와 용량을 살펴 엔드포인트마다 로드 밸런서와 가중치로 이뤄진 새 DNS 계획을 주기적으로 만든다. DNS Enactor 는 그 계획을 Amazon Route53 에 반영하며, 세 가용 영역에서 서로 독립적으로 하나씩 돈다. Enactor 는 새 계획을 적용하기 전에 그 계획이 이전에 적용된 것보다 새로운지 한 번만 확인한다.\n\n장애 직전 Enactor 하나가 여러 엔드포인트에서 이례적으로 긴 지연을 겪으며 재시도를 반복했다. 그사이 Planner 는 더 새로운 계획을 여러 세대 만들었고, 다른 Enactor 가 가장 새로운 계획을 빠르게 모든 엔드포인트에 적용했다. 두 번째 Enactor 는 적용을 마친 뒤 훨씬 오래된 계획을 지우는 정리 작업을 돌렸다. 바로 그때 지연됐던 첫 번째 Enactor 가 훨씬 오래된 계획을 리전 엔드포인트에 덮어썼다. 시작할 때 한 확인의 결과는 이미 낡아 있어서 덮어쓰기를 막지 못했다. 정리 작업이 이 오래된 계획을 지우자 리전 엔드포인트의 IP 주소가 모두 사라졌다. 활성 계획이 지워져 시스템이 일관되지 않은 상태가 됐고, 어떤 Enactor 도 다음 계획을 적용하지 못해 운영자가 손으로 바로잡아야 했다.\n\n00시 38분 엔지니어들이 DynamoDB 의 DNS 상태를 원인으로 찾았다. 01시 15분 임시 조치로 일부 내부 서비스가 DynamoDB 에 연결되고 핵심 내부 도구가 살아났다. 02시 25분 DNS 정보가 모두 복구됐고, 02시 25분부터 02시 40분 사이 캐시된 DNS 레코드가 만료되면서 고객도 다시 연결됐다.\n\nEC2 는 DynamoDB 가 돌아온 뒤에도 회복하지 못했다. AWS 는 EC2 물리 서버를 droplet 이라 부르고, 이를 관리하는 시스템이 DropletWorkflow Manager, 줄여서 DWFM 이다. DWFM 은 droplet 마다 자신이 관리 중이라는 표시인 리스를 유지하려고 몇 분마다 상태를 확인한다. 이 확인이 DynamoDB 에 기대고 있어 장애 동안 리스가 하나씩 만료됐다. 리스가 없는 droplet 은 새 인스턴스를 올릴 후보가 되지 못해 EC2 API 가 \"insufficient capacity\" 오류를 냈다. 02시 25분 DWFM 이 리스를 다시 맺기 시작했지만 droplet 이 너무 많아 작업이 타임아웃 전에 끝나지 못했고, 재시도 작업이 큐에 쌓이며 DWFM 이 혼잡 붕괴 상태에 빠졌다. 정해진 복구 절차가 없어 엔지니어들은 조심스럽게 여러 조치를 시도했고, 04시 14분 들어오는 작업을 스로틀링하고 DWFM 호스트를 골라 재시작했다. 05시 28분 모든 droplet 의 리스가 다시 맺어졌다.\n\n그 뒤 Network Manager 가 밀린 네트워크 구성 전파를 한꺼번에 처리하면서 06시 21분부터 전파 지연이 커졌다. 새 인스턴스는 떴지만 네트워크 연결이 없었다. NLB 헬스 체크 시스템은 이런 인스턴스를 서비스에 넣었다가 헬스 체크 실패로 빼기를 되풀이했고, 늘어난 부하로 헬스 체크 자체가 느려지면서 가용 영역 DNS 장애 조치가 자동으로 일어나 용량이 서비스에서 빠졌다. 10시 36분 네트워크 전파 시간이 정상이 됐고, 11시 23분부터 요청 스로틀링을 풀어 13시 50분 EC2 가 완전히 회복됐다. EKS, ECS, Fargate 는 14시 20분에 복구됐다."},"trigger":{"en":"One DNS Enactor, slowed by unusually high retry delays, applied a much older DNS plan to the regional DynamoDB endpoint just as another Enactor that had applied the newest plan ran its clean-up, which deleted that older plan and with it every IP address of the endpoint.","ko":"DynamoDB DNS 관리 시스템에 잠재해 있던 경쟁 조건 때문에 리전 엔드포인트 dynamodb.us-east-1.amazonaws.com 의 DNS 레코드가 빈 값이 됐고, 자동화가 이를 복구하지 못했다."},"severity":"unknown","symptoms":["dns-resolution-failures","high-error-rate","autoscaler-scale-up-failed","intermittent-connection-failures","high-latency"],"timeline":{"detected_after":null,"resolved_after":"14h 32m"},"date_kind":"incident","detection":{"en":"DNS failures to DynamoDB began immediately at 11:48 PM PDT and the engineering teams of affected AWS services were engaged at once; by 12:38 AM they had identified DynamoDB's DNS state as the source. The later NLB health check problem was detected by monitoring at 6:52 AM.","ko":"영향받은 AWS 서비스의 엔지니어링 팀이 23시 48분 장애가 시작되자 바로 투입돼 조사했고, 00시 38분 DynamoDB 의 DNS 상태를 원인으로 찾았다. NLB 헬스 체크 문제는 06시 52분 모니터링 시스템이 감지했다."},"components":["dns-server","database","cloud-load-balancer"],"root_cause":"software-bug","remediation":[{"text":{"en":"applied temporary mitigations by 1:15 AM that let some internal services reach DynamoDB and repaired key internal tooling","ko":"01시 15분 PDT 까지 임시 조치를 적용해 일부 내부 서비스가 DynamoDB 에 연결되게 하고 복구에 필요한 핵심 내부 도구를 고쳤다."}},{"text":{"en":"restored all DynamoDB DNS information by 2:25 AM through manual operator intervention","ko":"운영자가 손으로 DynamoDB 리전 엔드포인트의 DNS 정보를 바로잡아 02시 25분 모두 복구했다."}},{"text":{"en":"throttled incoming work and selectively restarted DWFM hosts from 4:14 AM so droplet leases could be re-established","ko":"04시 14분 DWFM 으로 들어오는 작업을 스로틀링하고 DWFM 호스트를 골라 재시작해 큐를 비우고 droplet 리스를 다시 맺게 했다."}},{"text":{"en":"reduced the load on Network Manager to bring network configuration propagation times back to normal by 10:36 AM","ko":"Network Manager 의 부하를 줄이고 복구를 앞당기는 조치를 해 10시 36분 네트워크 구성 전파 시간을 정상으로 되돌렸다."}},{"text":{"en":"disabled automatic health check failover for NLB at 9:36 AM, and re-enabled it at 2:09 PM after EC2 recovered","ko":"09시 36분 NLB 의 자동 헬스 체크 장애 조치를 꺼서 정상인 NLB 노드와 백엔드 대상을 모두 서비스로 되돌렸고, EC2 가 회복된 뒤 14시 09분 다시 켰다."}},{"text":{"en":"relaxed the EC2 request throttles from 11:23 AM until all EC2 APIs and launches were normal at 1:50 PM","ko":"11시 23분부터 EC2 하위 시스템을 보호하려고 걸어 둔 요청 스로틀링을 풀기 시작해 13시 50분 EC2 API 와 새 인스턴스 시작을 정상화했다."}}],"action_items":[{"text":{"en":"Disable the DynamoDB DNS Planner and DNS Enactor automation worldwide","ko":"DynamoDB DNS Planner 와 DNS Enactor 자동화를 전 세계에서 껐다."}},{"text":{"en":"Fix the race condition and add protections against applying incorrect DNS plans before re-enabling the DNS automation","ko":"자동화를 다시 켜기 전에 경쟁 조건을 고치고, 잘못된 DNS 계획이 적용되지 않도록 보호 장치를 더한다."}},{"text":{"en":"Add a velocity control to NLB that limits how much capacity a single load balancer can remove when health check failures cause availability zone failover","ko":"헬스 체크 실패로 가용 영역 장애 조치가 일어날 때 NLB 하나가 서비스에서 뺄 수 있는 용량을 제한하는 속도 제어 장치를 넣는다."}},{"text":{"en":"Build an additional EC2 test suite that exercises the DWFM recovery workflow at scale","ko":"기존 규모 테스트에 더해 DWFM 복구 흐름을 실행해 보는 테스트 스위트를 만들어 회귀를 찾는다."}},{"text":{"en":"Improve throttling in EC2 data propagation systems so incoming work is rate limited by the size of the waiting queue","ko":"EC2 데이터 전파 시스템의 스로틀링을 개선해 대기 큐 크기에 따라 들어오는 작업의 속도를 제한한다."}}],"contributing":["automation-amplified","retry-storm","no-runbook"],"recurrence_of":null,"symptoms_text":{"en":"At 11:48 PM PDT on 19 October 2025, every system that reached DynamoDB in us-east-1 through the public regional endpoint started getting DNS failures and could not connect. This included customer traffic and internal AWS services that depend on DynamoDB. DynamoDB global table replicas in other regions still answered but fell behind in replication to and from us-east-1.\n\nEC2 API calls in us-east-1 returned more errors and took longer, and new instance launches failed with \"insufficient capacity\" errors, later also with \"request limit exceeded\" errors from throttling. Instances already running were not affected. From 5:28 AM new launches began to succeed, but new instances could lack network connectivity until about 10:36 AM.\n\nFrom 5:30 AM some Network Load Balancers had more connection errors: health checks alternated between failing and passing, so NLB nodes and targets were removed from DNS and put back. Lambda, Amazon Connect, STS, IAM console sign-in, Redshift and AWS Support were also affected.\n\nBetween 11:45 PM PDT on 19 October and 2:20 PM PDT on 20 October, ECS, EKS and Fargate in us-east-1 had container launch failures and cluster scaling delays.","ko":"2025년 10월 19일 23시 48분 PDT 부터 us-east-1 리전에서 공개 엔드포인트로 DynamoDB 에 연결하려던 모든 시스템이 DNS 조회에 실패했다. 고객 트래픽과 DynamoDB 에 기대는 AWS 내부 서비스가 함께 실패했다.\n\nEKS, ECS, Fargate 에서는 10월 19일 23시 45분부터 10월 20일 14시 20분 PDT 까지 컨테이너 시작 실패와 클러스터 스케일링 지연이 이어졌다. EC2 는 10월 19일 23시 48분부터 10월 20일 13시 50분 PDT 까지 API 오류와 지연이 늘고 새 인스턴스 시작이 실패했다. 새 인스턴스 시작은 \"request limit exceeded\" 또는 \"insufficient capacity\" 오류로 실패했다. 이미 떠 있던 EC2 인스턴스는 영향을 받지 않았다.\n\n증상은 세 시기로 나뉘었다. 23시 48분부터 02시 40분까지는 DynamoDB API 오류율이 올랐다. 02시 25분부터 10시 36분까지는 새 EC2 인스턴스 시작이 실패했고, 10시 37분부터 시작은 성공했지만 일부 새 인스턴스는 13시 50분까지 네트워크 연결에 문제가 있었다. 05시 30분부터 14시 09분까지는 일부 Network Load Balancer 에서 연결 오류가 늘었다.\n\nNLB 헬스 체크는 실패와 성공을 오갔다. 네트워크 구성이 아직 다 전파되지 않은 새 EC2 인스턴스를 헬스 체크 시스템이 서비스에 넣으면서, 실제로는 정상인 NLB 노드와 백엔드 대상이 DNS 에서 빠졌다가 다음 헬스 체크가 성공하면 돌아오기를 되풀이했다. Lambda, Amazon Connect, STS, IAM 사용자의 콘솔 로그인, Redshift, AWS Support 도 오류와 지연을 겪었다."},"updated_at":"2026-11-10T00:00:36.196299Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0150","org_slug":"amazon-web-services"}