- 2025년 10월 19~20일, AWS N. Virginia 리전(us-east-1) 에서 Amazon DynamoDB를 비롯한 여러 핵심 서비스가 장시간 장애를 겪음
- 장애는 DynamoDB의 자동 DNS 관리 시스템 내 잠재적 경쟁 조건(race condition) 으로 인해 잘못된 빈 DNS 레코드가 생성되면서 시작됨
- 이로 인해 EC2 인스턴스 생성 실패, Network Load Balancer(NLB) 연결 오류, Lambda·ECS·Redshift 등 다수 서비스의 API 지연 및 실패가 연쇄적으로 발생
- AWS는 문제 원인을 DynamoDB DNS Enactor 간 비정상 동시 업데이트 충돌로 규명하고, 수동 복구를 통해 10월 20일 오후 2시 20분경 완전 복구
- 이번 사건은 AWS 내부 자동화 시스템 간 상호 의존성의 복잡성을 드러내며, 향후 DNS·EC2·NLB 복원력 강화를 위한 구조적 개선이 예고됨
사건 개요
- 장애는 2025년 10월 19일 오후 11시 48분(PDT)에 시작되어 10월 20일 오후 2시 20분(PDT)에 종료
- 세 차례의 주요 영향 구간이 존재:
- 10월 19일 11:48PM~10월 20일 2:40AM: DynamoDB API 오류율 급증
- 10월 20일 5:30AM~2:09PM: NLB 연결 오류 증가
- 10월 20일 2:25AM~10:36AM: EC2 신규 인스턴스 생성 실패 및 네트워크 연결 문제
- 장애는 DynamoDB DNS 관리 시스템의 결함에서 시작되어 EC2, NLB, Lambda, Redshift 등 다수 서비스로 확산
DynamoDB 장애 원인 및 영향
-
DynamoDB의 자동 DNS 관리 시스템 내 잠재적 결함이 트리거되어, dynamodb.us-east-1.amazonaws.com의 DNS 레코드가 비어 있는 상태로 잘못 갱신됨
- 시스템은 두 구성요소로 분리되어 있음:
-
DNS Planner: 로드밸런서 상태를 모니터링하고 새로운 DNS 계획 생성
-
DNS Enactor: Route53에 변경사항을 적용하는 역할
- 세 개의 가용 영역(AZ)에 독립적으로 배치된 DNS Enactor 간 경쟁 조건(race condition) 이 발생
- 첫 번째 Enactor가 지연된 상태에서 오래된 계획을 적용
- 두 번째 Enactor가 최신 계획을 적용 후 오래된 계획을 삭제하면서, 모든 IP 주소가 제거되고 시스템이 불일치 상태로 전환
- 자동 복구 실패로 인해 수동 조작(manual intervention) 이 필요
- 11:48PM 장애 발생 직후, DynamoDB에 의존하는 모든 서비스와 고객 트래픽이 연결 실패
- 글로벌 테이블을 사용하는 고객은 다른 리전의 복제본으로 요청 가능했으나, 복제 지연(replication lag) 발생
- 12:38AM에 AWS 엔지니어가 DNS 상태를 문제 원인으로 확인
- 1:15AM 임시 복구 조치로 일부 내부 서비스 연결 복원
- 2:25AM DNS 정보 완전 복원, 2:40AM 모든 연결 정상화
Amazon EC2 영향 및 복구 과정
- 10월 19일 11:48PM~10월 20일 1:50PM 동안 EC2 API 오류율 상승, 인스턴스 생성 실패, 지연 증가 발생
- EC2 인스턴스 관리에는 DropletWorkflow Manager(DWFM) 와 Network Manager 두 하위 시스템이 사용됨
- DWFM은 물리 서버(‘droplet’)의 상태를 관리하며, 주기적으로 상태 점검 수행
- Network Manager는 인스턴스 네트워크 구성을 전파
- DynamoDB 장애로 DWFM의 상태 점검이 실패하면서 droplet 임대(lease)가 만료
- 2:25AM DynamoDB 복구 후 DWFM이 재연결 시도했으나, 대규모 droplet 수로 인해 혼잡 붕괴(congestive collapse) 발생
- 4:14AM 엔지니어가 DWFM 호스트를 선택적으로 재시작하여 큐를 정리하고 복구 진행
- 5:28AM 모든 droplet 임대 복원, 신규 인스턴스 생성 재개
- 이후 Network Manager가 지연된 네트워크 상태 전파(backlog)를 처리하면서 네트워크 연결 지연 발생
- 10:36AM 네트워크 전파 시간 정상화
- 11:23AM 요청 제한(throttling) 완화 시작, 1:50PM EC2 완전 복구
Network Load Balancer(NLB) 영향
- 10월 20일 5:30AM~2:09PM 동안 일부 고객이 NLB 연결 오류 증가 경험
- NLB는 다중 테넌트 구조로, 백엔드 EC2 인스턴스에 트래픽을 라우팅
- 장애 원인은 네트워크 상태 전파 지연으로 인한 헬스체크 실패
- 새로 추가된 EC2 인스턴스의 네트워크 구성이 완료되지 않아 헬스체크가 실패
- 헬스체크 결과가 불안정하게 반복되어 NLB 노드가 DNS에서 제거되었다가 복귀하는 현상 발생
- 6:52AM 모니터링 시스템이 문제 감지, 엔지니어가 대응 시작
- 헬스체크 서브시스템 부하 증가로 자동 AZ DNS 장애 조치(failover) 발생
- 9:36AM 자동 장애 조치 비활성화로 모든 정상 노드 복귀
- 2:09PM EC2 복구 후 자동 장애 조치 재활성화
기타 AWS 서비스 영향
-
AWS Lambda:
- 10월 19일 11:51PM~10월 20일 2:15PM 동안 API 오류 및 지연
- DynamoDB 장애로 함수 생성·갱신 실패, SQS/Kinesis 이벤트 처리 지연
- 7:04AM NLB 헬스체크 실패로 내부 시스템 축소, 비동기 호출 제한
- 2:15PM 모든 백로그 처리 완료 및 정상화
-
ECS, EKS, Fargate:
- 10월 19일 11:45PM~10월 20일 2:20PM 동안 컨테이너 실행 실패 및 클러스터 확장 지연
-
Amazon Connect:
- 10월 19일 11:56PM~10월 20일 1:20PM 동안 통화·채팅·케이스 처리 오류
- DynamoDB 복구 후 대부분 기능 정상화, 그러나 7:04AM 이후 NLB 및 Lambda 영향으로 재차 오류 발생
- 1:20PM 완전 복구
-
AWS STS:
- 10월 19일 11:51PM~10월 20일 9:59AM 동안 인증 API 오류 및 지연
- DynamoDB 복구 후 일시 정상화, NLB 문제로 재차 오류 발생
-
IAM 로그인 및 Identity Center:
- 10월 19일 11:51PM~10월 20일 1:25AM 동안 인증 실패 증가
- DynamoDB 복구 후 정상화
-
Amazon Redshift:
- 10월 19일 11:47PM~10월 20일 2:21AM 동안 쿼리 및 클러스터 수정 실패
- DynamoDB 복구 후 일부 클러스터는 EC2 장애로 여전히 비정상
- 10월 21일 4:05AM 완전 복구
- IAM API 의존성으로 인해 글로벌 리전에서도 일시적 쿼리 실패 발생
-
기타 서비스:
- Managed Workflows for Apache Airflow, Outposts, AWS Support Center 등도 영향
사후 조치 및 개선 계획
-
DynamoDB DNS Planner 및 Enactor 자동화 전면 비활성화, 재활성화 전 경쟁 조건 수정 및 보호 장치 추가 예정
-
NLB: 헬스체크 실패 시 단일 NLB가 제거할 수 있는 용량을 제한하는 속도 제어 메커니즘 도입
-
EC2:
- DWFM 복구 워크플로우를 포함한 새로운 테스트 스위트 구축
- 데이터 전파 시스템의 스마트 스로틀링 개선으로 대기 큐 크기에 따른 요청 제한 기능 추가
- AWS는 전체 서비스 간 상호 의존성 분석을 통해 복구 시간 단축 및 유사 사고 방지 방안을 추가 검토 중
결론 및 사과
- AWS는 이번 사건으로 고객에게 미친 영향에 대해 공식 사과
- 자사 서비스의 높은 가용성을 유지해왔으나, 이번 장애가 고객 비즈니스에 중대한 영향을 미쳤음을 인정
- 본 사건을 교훈 삼아 자동화 시스템의 복원력 및 장애 대응 절차 강화를 약속