{"id":"IL-0223","org":"Amazon Web Services","date":"2021-12-07","docs":[],"title":{"en":"A connection surge congested the devices between AWS's internal and main networks in us-east-1, breaking EC2 APIs","ko":"us-east-1 에서 AWS 내부 네트워크와 주 네트워크를 잇는 장비가 연결 폭주로 혼잡해져 EC2 API 와 여러 AWS 서비스의 제어 평면이 몇 시간 동안 오류를 냈다."},"domain":["aws","networking"],"impact":{"scope":"AWS services and control planes that depend on the internal network in us-east-1: EC2 APIs and instance launches, ELB, Route 53 APIs, Console logins, STS, CloudWatch, VPC Endpoints for S3 and DynamoDB, API Gateway, EventBridge, Fargate, ECS, EKS, Amazon Connect and support case creation","users":"unknown","region":"us-east-1"},"review":{"written_by":"session","reviewed_at":null,"reviewed_by":null},"lessons":null,"related":[],"sources":[{"url":"https://aws.amazon.com/message/12721/","kind":"official-status","archived":"https://web.archive.org/web/20261031052904/https://aws.amazon.com/message/12721/"}],"summary":{"en":"AWS runs foundational services, including monitoring, internal DNS, authorization services and parts of the EC2 control plane, on an internal network separate from the main AWS network where most AWS services and all customer applications run. Several geographically isolated networking devices connect the two networks and provide routing and network address translation between them. At 7:30 AM PST on 7 December 2021 an automated activity that scales the capacity of one AWS service on the main network set off a large surge of connection activity from clients in the internal network that overwhelmed these devices. The delays raised latency and errors for services talking across the two networks, which caused even more connection attempts and retries and kept the devices congested. The clients have back-off behaviour meant to let systems recover from such congestion, but a latent issue in a code path that had been in production for many years kept them from backing off.\n\nMoving internal DNS traffic off the congested paths fixed DNS at 9:28 AM PST. Isolating the largest traffic sources, disabling some heavy services and adding capacity improved the congestion significantly by 1:34 PM PST, and all network devices had recovered by 2:22 PM PST. The work went slowly because monitoring data was still not visible, the internal deployment systems were affected, and operators changed things carefully to avoid harming workloads that still worked. The main network was not affected, but control planes that use services on the internal network failed, including the EC2, ELB and Route 53 APIs, Console logins, STS, CloudWatch, VPC Endpoint access to S3 and DynamoDB, API Gateway, EventBridge, Fargate, ECS, EKS and Amazon Connect. The impaired monitoring and the Service Health Dashboard tooling's failure to fail over delayed customer updates, and support cases could not be created until 2:25 PM PST. Services built on the internal network recovered later as their backlogs cleared: STS by 4:28 PM; API Gateway largely by 4:37 PM, after its automated recycling of broken servers could use the EC2 APIs again; Amazon Connect at 4:41 PM; Fargate API errors from 5:00 PM; and EventBridge delivery latency by 6:40 PM PST. AWS disabled the scaling activities that started the event.","ko":"AWS 는 대부분의 서비스와 모든 고객 애플리케이션을 주 AWS 네트워크에서 돌리고, 모니터링, 내부 DNS, 권한 서비스, EC2 제어 평면 일부 같은 기반 서비스는 별도의 내부 네트워크에서 돌린다. 두 네트워크는 지리적으로 떨어진 여러 네트워크 장비로 이어지고, 이 장비가 라우팅과 네트워크 주소 변환을 맡는다. 2021-12-07 PST 오전 7시 30분에 주 네트워크의 한 서비스 용량을 늘리는 자동 작업이 내부 네트워크의 많은 클라이언트에서 예상하지 못한 동작을 일으켰고, 연결이 폭주해 두 네트워크 사이의 장비가 넘쳤다. 통신이 늦어지자 지연과 오류가 늘고 그 때문에 연결 시도와 재시도가 더 늘어, 혼잡이 계속 이어졌다. 클라이언트에는 혼잡할 때 재시도 간격을 늘려 물러서는 back-off 동작이 있었고, 이 동작은 충분히 시험한 것이었다. 하지만 오래전부터 운영 중이던 코드 경로의 잠재된 문제 때문에 이번에는 back-off 가 제대로 동작하지 않았다.\n\n혼잡은 곧바로 운영팀의 실시간 모니터링 데이터를 끊었다. 운영자는 로그에서 내부 DNS 오류가 늘어난 것을 찾았다. 내부 DNS 트래픽을 혼잡한 경로에서 옮겨 오전 9시 28분에 DNS 해석 오류를 없앴지만, 혼잡은 남았다. 그 뒤 트래픽을 가장 많이 내는 출처를 전용 장비로 분리하고, 트래픽이 많은 서비스 일부를 끄고, 네트워크 용량을 늘렸다. 이 작업은 느렸다. 모니터링이 보이지 않았고, 내부 네트워크에서 도는 배포 시스템도 영향을 받았으며, 정상으로 돌고 있는 워크로드를 건드리지 않으려고 아주 조심스럽게 바꿔야 했기 때문이다. 혼잡은 오후 1시 34분에 크게 나아졌고 오후 2시 22분에 모든 네트워크 장비가 회복됐다.\n\n주 네트워크는 멀쩡해서 고객 워크로드는 직접 영향을 받지 않았지만, 내부 네트워크에 기대는 서비스 제어 평면이 망가졌다. EC2 API, ELB API, Route 53 API, Console 로그인, STS, CloudWatch, VPC Endpoints 를 거친 S3 와 DynamoDB 접근, API Gateway, EventBridge, Fargate, ECS, EKS, Amazon Connect 가 영향을 받았다. 일부 서비스는 밀린 작업을 처리하느라 네트워크 회복 뒤에도 몇 시간 더 걸렸다. 모니터링이 망가지고 Service Health Dashboard 도구가 대기 리전으로 넘어가지 못해 고객 공지가 늦었고, 지원 케이스도 오후 2시 25분까지 만들 수 없었다. AWS 는 이번 일을 촉발한 확장 작업을 즉시 껐다."},"trigger":{"en":"At 7:30 AM PST an automated activity that scales the capacity of one AWS service hosted in the main AWS network triggered unexpected behaviour from a large number of clients inside the internal network.","ko":"PST 오전 7시 30분에 주 AWS 네트워크에서 도는 한 AWS 서비스의 용량을 늘리는 자동 작업이, 내부 네트워크 안의 많은 클라이언트에서 예상하지 못한 동작을 일으켰다. 연결 시도가 한꺼번에 몰려 내부 네트워크와 주 네트워크 사이의 네트워크 장비가 감당하지 못했다."},"severity":"unknown","symptoms":["control-plane-slow","high-latency","high-error-rate","monitoring-down","dns-resolution-failures"],"timeline":{"detected_after":null,"resolved_after":"6h 52m"},"date_kind":"incident","detection":{"en":"The congestion immediately cut off real-time monitoring data for the AWS operations teams, who turned to logs and first identified elevated internal DNS errors.","ko":"혼잡이 시작되자 운영팀의 실시간 모니터링 데이터가 곧바로 끊겼다. 운영자는 로그를 보고 상황을 파악했고, 처음에는 내부 DNS 오류가 늘어난 것을 찾았다."},"components":["interconnect","capacity-manager"],"root_cause":"software-bug","remediation":[{"text":{"en":"Moved internal DNS traffic away from the congested network paths","ko":"내부 DNS 트래픽을 혼잡한 네트워크 경로에서 옮겼다. PST 오전 9시 28분에 이 작업을 마치자 DNS 해석 오류가 완전히 회복됐지만 혼잡은 남았다."}},{"text":{"en":"Isolated the top sources of traffic onto dedicated network devices","ko":"내부 네트워크의 트래픽을 가장 많이 내는 출처를 찾아 전용 네트워크 장비로 분리했다."}},{"text":{"en":"Disabled some heavy network traffic services, including EventBridge event delivery","ko":"네트워크 트래픽이 많은 서비스 일부를 껐다. PST 오후 12시 35분에는 EventBridge 이벤트 전달도 껐다."}},{"text":{"en":"Brought additional networking capacity online","ko":"네트워크 용량을 늘렸다. 혼잡은 오후 1시 34분에 크게 나아졌고 오후 2시 22분에 모든 네트워크 장비가 회복됐다."}},{"text":{"en":"Disabled the automated scaling activities that triggered the event","ko":"이번 일을 촉발한 확장 작업을 즉시 껐다."}}],"action_items":[{"text":{"en":"Keep the triggering scaling activities off until all remediations are deployed","ko":"모든 개선 조치를 배포할 때까지 이번 일을 촉발한 확장 작업을 다시 켜지 않는다."}},{"text":{"en":"Fix the latent issue that kept networking clients from backing off","ko":"네트워크 클라이언트가 혼잡에서 제대로 back-off 하지 못하게 한 잠재 문제를 고치는 수정을 만들어 2주 안에 배포한다."}},{"text":{"en":"Deploy network configuration that protects the affected networking devices in a similar congestion event","ko":"비슷한 혼잡이 다시 생겨도 영향받을 수 있는 네트워크 장비를 보호하도록 네트워크 설정을 추가한다. 이 설정은 이미 배포했다."}},{"text":{"en":"Keep API Gateway servers healthy when the internal network is unavailable and speed up their recycling","ko":"내부 네트워크를 쓸 수 없을 때도 API Gateway 서버가 정상으로 남게 하는 완화책을 만들고, 비슷한 일이 생겼을 때 더 빨리 복구하도록 서버 교체 과정을 개선한다."}},{"text":{"en":"Release a new Service Health Dashboard that makes service impact easier to understand","ko":"서비스 영향을 더 쉽게 알아볼 수 있는 새 Service Health Dashboard 를 내년 초에 내놓는다."}},{"text":{"en":"Run the support system actively across multiple AWS regions","ko":"고객과의 소통이 늦어지지 않도록 여러 AWS 리전에서 동시에 도는 새 구조의 지원 시스템을 내놓는다."}}],"contributing":["retry-storm","circular-dependency"],"recurrence_of":null,"symptoms_text":{"en":"From 7:30 AM PST on 7 December 2021, AWS services in us-east-1 that communicate between AWS's internal network and its main network saw rising latency and errors. The AWS operations teams lost real-time monitoring data at once, and the first thing found in the logs was elevated internal DNS errors.\n\nRunning EC2 instances kept working, but the EC2 APIs for launching and describing instances returned more errors and latency from 7:33 AM PST, and launches of new instances recovered only at 2:40 PM PST, so customers of Amazon RDS, EMR and Workspaces could not create new resources. ELB APIs were slow to provision load balancers and register instances, Route 53 APIs were impaired from 7:30 AM to 2:30 PM PST while existing DNS answers kept working, AWS Console logins failed, STS was slow to provide credentials through OpenID Connect, CloudWatch data was delayed and partly missing, and access to S3 and DynamoDB through VPC Endpoints was impaired. API Gateway and, in the early part of the event, EventBridge had elevated error rates, and Amazon Connect had elevated failure rates for phone calls, chat sessions and task contacts. In Fargate, ECS and EKS, tasks and pods that stopped could not be restarted, and Fargate later returned Insufficient Capacity Errors.\n\nBecause internal DNS is foundational for all services and its traffic was believed to add to the congestion, the teams first moved internal DNS traffic away from the congested paths. DNS resolution errors fully recovered at 9:28 AM PST and several services improved, but the congestion and much of the service impact remained. Operators then isolated the top traffic sources onto dedicated network devices, disabled some heavy traffic services, including EventBridge event delivery at 12:35 PM, and brought extra network capacity online.\n\nThis work went slowly because monitoring data was still not visible, because AWS's internal deployment systems run in the internal network and were affected too, and because operators changed things carefully to avoid harming the many workloads on the main network that still worked. The Service Health Dashboard tooling could not fail over to its standby region at first, and updates to it succeeded only by 8:22 AM PST. Creating support cases was impaired from 7:33 AM until 2:25 PM PST.\n\nCongestion improved significantly by 1:34 PM PST and all network devices recovered by 2:22 PM PST. EC2 API error rates and latencies began to improve at 1:15 PM PST. STS fully recovered at 4:28 PM, API Gateway largely recovered at 4:37 PM, Fargate API error rates began to return to normal at 5:00 PM, and EventBridge event delivery latency stayed elevated until 6:40 PM PST.","ko":"2021-12-07 PST 오전 7시 33분부터 us-east-1 에서 새 인스턴스를 띄우거나 기존 인스턴스를 조회하는 EC2 API 의 오류율과 지연이 늘었다. AWS 운영팀은 혼잡이 시작되자 곧바로 실시간 모니터링 데이터를 볼 수 없었다.\n\n모니터링 데이터가 없어 운영자는 로그로 상황을 파악했고, 처음에는 내부 DNS 오류가 늘어난 것을 찾았다. 내부 DNS 트래픽이 혼잡을 키운다고 보고 이 트래픽을 혼잡한 경로에서 옮겼다. 오전 9시 28분에 DNS 해석 오류는 완전히 회복됐지만 혼잡과 서비스 영향은 남았고, 모니터링 데이터도 여전히 보이지 않았다. 운영자는 그 뒤 트래픽을 가장 많이 내는 출처를 전용 네트워크 장비로 분리했다. 오후 12시 35분의 EventBridge 이벤트 전달을 포함해 트래픽이 많은 서비스 일부를 끄고, 네트워크 용량을 늘렸다. 이 작업은 느렸다. 모니터링 데이터가 보이지 않았고, 내부 네트워크에서 도는 배포 시스템도 영향을 받았다. 주 네트워크에서 정상으로 돌던 워크로드를 건드리지 않으려고 조심스럽게 바꿔야 하기도 했다.\n\n이미 돌고 있는 EC2 인스턴스는 영향이 없었지만, 새 EC2 인스턴스를 띄울 수 없어 Amazon RDS, EMR, Workspaces 고객은 새 리소스를 만들지 못했다. 기존 Elastic Load Balancer 는 정상이었지만 ELB API 오류와 지연으로 새 로드 밸런서 프로비저닝이 늦어지고 기존 로드 밸런서에 인스턴스를 등록하는 데 시간이 더 걸렸다. Route 53 API 는 오전 7시 30분부터 오후 2시 30분까지 망가져 DNS 레코드를 바꿀 수 없었지만, 기존 레코드와 DNS 질의 응답은 정상이었다. 이 리전의 AWS Console 로그인이 실패했다. OpenID Connect 로 외부 ID 제공자용 자격 증명을 발급하는 Amazon Secure Token Service 도 느려져, Redshift 처럼 STS 로 인증하는 서비스의 로그인이 실패했다.\n\n다른 서비스에서도 증상이 나왔다. CloudWatch 모니터링이 내내 늦어 고객은 애플리케이션 영향을 파악하기 어려웠고, 일부 지표에는 데이터가 빠졌다. VPC Endpoints 를 거친 S3 버킷과 DynamoDB 테이블 접근이 망가졌다. Lambda 함수를 호출하는 데 자주 쓰는 API Gateway 의 오류율이 올랐고, EventBridge 도 초기에 오류가 늘었다. Fargate, ECS, EKS 는 API 오류와 지연이 늘었고, 기존 태스크나 파드는 계속 돌았지만 종료되거나 실패한 컨테이너는 다시 시작하지 못했다. Fargate 는 밀린 컨테이너 기동 요청 때문에 Insufficient Capacity Errors 를 냈다. Amazon Connect 는 전화, 채팅, 태스크 처리 실패율이 올랐다.\n\n고객과의 소통도 막혔다. 지원 컨택 센터가 AWS 내부 네트워크에 의존해 오전 7시 33분부터 오후 2시 25분까지 지원 케이스를 만들 수 없었다. Service Health Dashboard 도구는 혼잡 때문에 대기 리전으로 넘어가지 못했고, 오전 8시 22분에야 업데이트가 올라가기 시작했다.\n\n혼잡은 오후 1시 34분에 크게 나아졌고 오후 2시 22분에 모든 네트워크 장비가 회복됐다. EC2 API 는 오후 1시 15분부터 나아졌지만 새 인스턴스 기동은 오후 2시 40분에 회복됐다. STS 는 오후 4시 28분, API Gateway 는 오후 4시 37분에 대부분 회복됐다. EventBridge 는 밀린 이벤트를 처리하느라 오후 6시 40분까지 이벤트 전달이 늦었고, Fargate 는 오후 5시부터 API 오류율이 정상으로 돌아오기 시작했다."},"updated_at":"2026-11-14T05:53:43.765310Z","url":"https://benchlet.com/incidentlib/app/cases/IL-0223","org_slug":"amazon-web-services"}