2025년 10월 미국 버지니아 북부(US-EAST-1) AWS 서비스 장애 요약
2025년 10월 19~20일, 미국 버지니아 북부 리전에서 Amazon DynamoDB의 결함으로 시작된 AWS 대규모 서비스 장애가 발생했습니다. 이 장애는 DynamoDB에서 시작해 EC2, NLB 등 주요 서비스에 연쇄적으로 영향을 미쳤고, AWS는 원인과 대응, 재발 방지 조치까지 자세하게 밝혔습니다. 아래에서는 시간순으로 사건의 경과와 각 서비스에 미친 영향을 단계별로 자세히 정리합니다.
1. 장애의 시작: DynamoDB DNS 시스템 결함 발생
2025년 10월 19일 밤 11:48(미국 태평양 표준시, PDT), DynamoDB에서 비정상적으로 높은 API 오류율이 감지되면서 장애가 시작됐습니다. 이 문제는 DynamoDB DNS 자동화 시스템의 잠재 결함으로 인한 것이었습니다.
- DynamoDB는 수십만 개의 DNS 레코드를 통해 대규모 로드밸런서를 관리하고, 이들 레코드는 자동화 시스템인 DNS Planner와 DNS Enactor가 Route53에서 갱신합니다.
- 이번 사건은 두 개의 독립적으로 동작하는 DNS Enactor 간의 드문 경쟁 상태(race condition)에 의해 한 Enactor가 오래된 DNS 플랜을 우연히 적용했고, 이것이 최종적으로 최신 플랜을 삭제하면서 서비스 엔드포인트(dynamodb.us-east-1.amazonaws.com) DNS 레코드가 빈 상태로 남게 되었습니다.
- 이로 인해 외부뿐만 아니라 내부 AWS 서비스(예: Lambda, Redshift 등) 역시 DynamoDB에 접근할 수 없었습니다.
"이번 장애의 근본 원인은 DynamoDB의 DNS 관리 시스템 내에 존재했던 잠재적인 경쟁 상태로, 이로 인해 서비스 지역 엔드포인트의 DNS 레코드가 잘못 비워지는 현상이 발생했습니다."
AWS 엔지니어팀은 곧 문제를 인지했고, 10월 20일 1:15엔 내부 툴링 복구 및 임시 조치에 성공, 2:25쯤 DNS 정보를 모두 복구했습니다. 캐시된 DNS 레코드가 만료되면서 2:40까지 모든 고객들이 정상적으로 DynamoDB에 연결할 수 있게 됐습니다.
2. EC2: 인스턴스 신규 생성 실패와 복구 과정
장애 시작과 동시에, 고객들은 EC2 인스턴스 생성 실패 및 API 지연 현상도 겪게 됩니다.
- EC2 인스턴스 생성 및 관리에 필요한 DropletWorkflow Manager(DWFM)와 Network Manager도 DynamoDB에 의존합니다.
- 장애 발생 후 기존에 실행 중이던 EC2 인스턴스는 정상적으로 유지되었지만, DWFM과 droplets(EC2 물리 호스트) 간의 임대(lease) 갱신이 실패하여, 장애 기간 동안 신규 인스턴스 생성은 불가능해집니다.
- DynamoDB API가 복구된 후 DWFM이 모든 droplet과 임대를 재설정해야 하는데, 장애 동안 expired된 임대로 인해 작업량이 폭증하며 시스템이 정체(congestive collapse)에 빠지고 맙니다.
- 여러 번의 수동 복구 시도 끝에 엔지니어팀이 DWFM 호스트를 순차적으로 재시작하고, 큐가 비워지며 결국 5:28쯤 복구가 시작됩니다.
- 이때부터도 네트워크 정보 전파 작업이 지연되면서, 인스턴스가 뜨더라도 통신 문제가 일부 존재했습니다. 10:36경 네트워크 전파 지연이 해소되고, 13:50에 모든 EC2 서비스가 정상화되었습니다.
"신규 EC2 인스턴스는 네트워크 연결을 받지 못해, 성공적으로 실행되더라도 실질적으로 사용할 수 없는 상태였습니다."
3. NLB(Network Load Balancer): 연결 오류 및 장애 복구
EC2 장애 여파로, NLB(Network Load Balancer) 서비스와 이를 사용하는 서비스들도 연결 오류를 폭넓게 경험했습니다.
- 10월 20일 새벽 5:30부터 오후 2:09까지, 일부 NLB에서 연결 오류가 증가했습니다.
- 원인은 네트워크 전파 지연으로 인해 NLB 헬스체크(health check)가 실패했고, 건강한 노드임에도 불구하고 비정상으로 인식되어 DNS에서 제거 및 복구가 반복되는 비정상 상태가 이어졌습니다.
- 엔지니어들은 오전 9:36에 자동 헬스체크 페일오버(AZ DNS failover)를 비활성화하여 문제를 진정시켰고, 이후 EC2가 정상화되며 NLB도 오후 2:09에 완전히 복구됐습니다.
"헬스체크 결과가 교대로 실패와 성공을 반복하면서, NLB 노드와 백엔드 대상이 DNS에서 제거되었다 다시 서비스로 복귀하는 현상이 발생했습니다."
4. Lambda, ECS/EKS/Fargate, Redshift 등 AWS 주요 서비스 연쇄 장애
DynamoDB, EC2, NLB 장애는 여러 AWS 핵심 서비스에 연속적인 영향을 미쳤습니다.
- Lambda: DynamoDB 엔드포인트 장애로 함수 생성·업데이트와 SQS/Kinesis 관련 이벤트 처리, Invocation에 오류 발생. backlog 복구 후 2:15 PM에 정상화.
- ECS, EKS, Fargate: 컨테이너 생성 실패와 클러스터 확장 지연이 동반, 2:20 PM까지 복구.
- Amazon Connect: 전화/채팅/상담 사례 등 처리 불가, 장애 해소 후에도 일부 기능(채팅)은 추가 장애 지속.
- AWS STS, IAM/Identity Center: 인증 실패 및 지연, 콘솔 로그인 불가 등, DynamoDB가 복구되며 이슈 해소.
- Redshift: 쿼리 및 클러스터 생성/변경 불가, EC2 인스턴스 교체 시도도 막혀 클러스터 이용 불가가 계속됨.
"DynamoDB 엔드포인트가 장애를 일으키자 AWS 내부 서비스뿐 아니라, 신규 함수 생성·업데이트, SQS 큐 polling, Lambda invocation까지 광범위한 장애가 연쇄적으로 발생했습니다."
"IAM 연동이 필요한 Redshift 쿼리도 일시적으로 전 AWS 리전에서 영향을 받았고, 'local' 사용자만 정상적으로 연결할 수 있었습니다."
또한 Airflow, Outposts, Support Center 등 DynamoDB나 신규 EC2 인스턴스에 의존하는 서비스도 유사한 패턴으로 장애를 겪었습니다.
5. 재발 방지 및 개선 사항
AWS는 이번 사건으로부터 다양한 교훈과 개선책을 마련했습니다.
- DynamoDB DNS Planner 및 Enactor의 자동화 시스템은 일시적으로 전 세계적으로 중단했고, 경쟁 상태와 플랜 적용 보호책을 추가할 예정입니다.
- NLB에는 헬스체크 실패 시 한 번에 너무 많은 용량이 AZ 페일오버로 빠지지 않도록 velocity control 기능을 도입합니다.
- EC2의 경우, DWFM 복구 흐름을 강화하는 내부 테스트를 추가하고, 스케일 아웃 및 부하 상황에 적절히 대처할 수 있는 스로틀링 메커니즘을 개선할 계획입니다.
- 재발 방지를 위해 모든 관련 AWS 서비스에 대한 추가적인 분석 및 대응책을 계속해서 발전시킬 계획입니다.
"가능한 한 빠르게 문제를 복구하고, 향후 유사한 장애를 미연에 방지하기 위해 모든 노력을 기울이겠습니다."
마무리
이번 AWS N. Virginia(US-EAST-1) 리전 장애는 DynamoDB DNS 시스템의 경쟁 상태에서 시작되어 EC2, NLB, Lambda 등 수많은 클라우드 서비스로 파급되었습니다. AWS는 투명한 사고 분석과 구체적 재발 방지 계획을 내세웠으나, 대규모 클라우드 인프라에서의 상호 의존성과 자동화 시스템의 복잡성이 얼마나 큰 영향을 미칠 수 있는지 보여주는 사례였습니다. 이런 장애를 계기로 클라우드 인프라 운영의 신뢰성과 복원력에 대한 고민이 더욱 깊어질 것으로 보입니다.
"AWS 서비스가 고객 비즈니스에 얼마나 중요한지 잘 알기에, 이번 사고로 끼친 피해에 깊이 사과드리며 반드시 더 나은 서비스를 만들겠습니다."