# 미국 동부(버지니아 북부, US-East-1) 리전에서 발생한 Amazon DynamoDB 서비스 중단 요약

> Clean Markdown view of GeekNews topic #23881. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=23881](https://news.hada.io/topic?id=23881)
- GeekNews Markdown: [https://news.hada.io/topic/23881.md](https://news.hada.io/topic/23881.md)
- Type: GN+
- Author: [xguru](https://news.hada.io/@xguru)
- Published: 2025-10-24T10:40:21+09:00
- Updated: 2025-10-24T10:40:21+09:00
- Original source: [aws.amazon.com](https://aws.amazon.com/message/101925/)
- Points: 3
- Comments: 2

## Topic Body

- 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)에 종료  
  - 세 차례의 주요 영향 구간이 존재:  
    1) 10월 19일 11:48PM~10월 20일 2:40AM: DynamoDB API 오류율 급증  
    2) 10월 20일 5:30AM~2:09PM: NLB 연결 오류 증가  
    3) 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는 이번 사건으로 고객에게 미친 영향에 대해 공식 사과  
- 자사 서비스의 높은 가용성을 유지해왔으나, 이번 장애가 **고객 비즈니스에 중대한 영향을 미쳤음**을 인정  
- 본 사건을 교훈 삼아 **자동화 시스템의 복원력 및 장애 대응 절차 강화**를 약속

## Comments



### Comment 45480

- Author: shakespeares
- Created: 2025-10-26T22:21:38+09:00
- Points: 1

시니어들을 자른 후폭풍이라고 하던데..맞나요?

### Comment 45400

- Author: neo
- Created: 2025-10-24T10:40:22+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=45677139) 
- 나는 이 주제에 대해 늘 같은 말을 반복하는 사람임. 아직 **Richard Cook의 글**을 읽지 않았다면, 지금 이 포스트모템을 멈추고 먼저 [How Complex Systems Fail](https://how.complexsystems.fail/)을 읽어보길 권함. 이 글은 복잡한 시스템 실패를 다룬 최고의 기술 글 중 하나임. Cook은 “루트 원인(root cause)”이라는 개념 자체를 거부하는데, 이번 사건에서도 그가 옳다고 생각함  
  - Cook의 글은 괜찮지만, 사실상 **직관적인 주장들의 나열**처럼 느껴짐. 진짜 깊이 이해하려면 참고문헌을 다 읽어야 할 듯함. MIT의 시스템 수업 6.033에서도 비슷한 주제를 다루는 [1962년 논문](https://news.ycombinator.com/item?id=10082625)과 [다른 고전 논문](https://news.ycombinator.com/item?id=16392223)을 읽게 함. 이런 문제는 결국 **‘Wicked problem’** 수준의 복잡성에 도달한 사례라고 봄  
  - Cook의 글에서 인상 깊었던 부분은, 사고 후 시스템을 “더 안전하게” 고치려는 시도가 오히려 **안전성을 낮출 수 있음**이라는 점이었음. 인간 오류를 막기 위한 조치들이 시스템의 결합도와 복잡성을 높여, 잠재적 실패 지점을 늘리고 탐지·차단을 더 어렵게 만든다는 설명이 특히 와닿았음  
  - 또 다른 관점으로는 **‘Normal Accidents’ 이론**이 있음. 구성 요소들이 강하게 결합되고 상호작용이 복잡하며 실패의 결과가 심각할수록 시스템은 본질적으로 더 위험해진다는 주장임. [Normal Accidents 위키](https://en.wikipedia.org/wiki/Normal_Accidents) 참고  
  - 나는 두 문서를 다 완독하진 않았지만, 단지 시스템이 복잡하다고 해서 실패의 **루트 원인**을 규정할 수 없다는 주장에는 동의하지 않음. 스포츠에서도 득점은 여러 요인의 결과지만, 결국 ‘득점자’는 존재함. 넓은 시야는 좋지만, 핵심 원인을 짚는 것도 실용적임  
  - 나는 **온콜(oncall)** 근무를 하는 계약자임. 대부분의 회사가 온콜을 진지하게 다루지 않음. 문서화도 부족하고, 다른 사람의 복잡한 코드를 읽을 시간도 주지 않음. AWS처럼 온콜을 학습과 책임의 일부로 여기는 문화를 꼭 경험해보고 싶음  

- 인터넷이 점점 **집중화된 단일망(mononet)** 으로 변하고 있음. 냉전 시절 분산 네트워크로 태어난 인터넷이 이제는 한 번의 배포 실수로 전 세계 은행·쇼핑·여행이 멈출 수 있는 구조가 됨. 클라우드 메타포는 이미 한계를 넘었음.  
  스타트업이나 R&D에는 여전히 유용하지만, 성장 단계 기업이나 정부는 **자체 서버·자체 클라우드·자체 핵심 서비스**를 가져야 함. 기술과 인력은 충분히 있음  

- AWS의 포스트모템에서 **정확한 타임라인 시각화**가 인상적이었음. GDC의 전설적인 강연 [“I Shot You First”](https://youtu.be/h47zZrqjgLc?t=1587)처럼, 시간의 흐름을 기울어진 화살표로 표현하며 “지연이 어디서 발생했는가”를 묻는 방식이 유용했음.  
  하지만 나를 더 놀라게 한 건, EC2 노드 리스 관리 서비스에 **복구 절차(runbook)** 가 없었다는 점임. AWS의 핵심 서비스라면 거의 모든 예외 상황이 대비되어 있을 줄 알았음  
  - 이런 상황은 두려워할 게 아니라 **복잡계의 본질적 패턴**으로 인식해야 함. 잠재적 실패는 프랙탈처럼 존재하고, 모든 경우의 수에 대한 런북을 갖추는 건 불가능함  

- 이번 사건의 핵심은 DNS 시스템의 **캐시 무효화(cache invalidation)** 문제 변형 같음. 두 개의 DNS Enactor가 서로 다른 타이밍으로 계획(plan)을 적용하면서 **레이스 컨디션**이 발생했고, 오래된 계획이 새로운 계획을 덮어써 버림  
  - 이건 대중용 설명일 뿐, 실제 내부에서는 사건 해결 후 **재발 가능성 평가와 완화책(runbook) 작성**이 이루어짐. 이후 조직 차원의 학습과 공유가 이어짐  
  - 나는 이 **레이스 컨디션 자체가 루트 원인**이라고 봄. 그 버그만 없었어도 사건은 없었을 것임  
  - DNS Planner와 Enactor를 왜 분리했는지 의문임. 하나의 서비스였다면 이런 경쟁 상태가 더 명확히 드러났을 것임. **마이크로서비스 남용**이 복잡성을 키운 결과일 수도 있음  
  - 비슷한 문제를 겪은 적이 있는데, 원인은 **JVM GC 지연**과 고장난 하드웨어였음. 이번에도 그런 가능성이 있음  
  - 그런데 AWS는 이런 지연이 다시 발생했을 때의 **예방책**을 명시하지 않았음  

- Enactor가 새 값을 적용하기 전에 **현재 레코드의 버전 비교(CAS)** 를 했어야 함. 효율성은 떨어지더라도 기본적인 안전장치임. DynamoDB 자체에서 처리할 수 있었을 것임  

- DynamoDB가 지역별로 수십만 개의 DNS 레코드를 관리한다는 설명을 보고 놀랐음. `dynamodb.us-east-1.amazonaws.com`이 수십만 IP로 해석될 수 있다니, **Route53의 한계를 넘는 수준** 같음. 아마도 TTL을 낮게 두고 일부만 갱신하는 방식일 듯함  
  - 실제로 AWS의 DNS는 그렇게 동작함. Route53은 **리소스 레코드 세트(RRSet)** 단위로 작동하고, 헬스체크나 지연 기반 선택 로직을 통해 적절한 세트를 반환함  
  - CDN도 비슷하게 동작함. 시스템 메트릭을 수집해 네트워크별 최적 PoP을 계산함. [bunny.net SmartEdge](https://bunny.net/network/smartedge/)가 좋은 예시임  
  - 나도 S3로 테스트해봤는데, 몇 초 만에 수백 개의 서로 다른 IP를 받았음. 단일 리전에서도 이런 다양성이 있음  

- 버그는 언제나 존재함. **형식 검증(formal verification)** 은 어렵고, 낮은 확률의 버그는 수년 후에야 터지기도 함.  
  그래서 시스템은 반드시 실패한다고 가정하고, **피해를 제한하는 구조**를 설계해야 함. 셀 기반 아키텍처, 단계적 롤아웃, 격리된 존이 그 예임.  
  AWS도 셀 기반을 시도하지만, 특히 us-east-1에는 **레거시 교차 의존성**이 남아 있음. 장기적으로는 리전을 완전히 독립적으로 설계해야 함.  
  이런 작업은 고위 임원 지원이 없으면 진행되지 않지만, **주주 입장에서는 회사 존속 리스크**를 줄이는 핵심 투자임  

- 보고서에서 **UTC가 아닌 PT 타임존**을 쓴 게 의외였음  
  - “epoch fail?”이라는 농담이 나올 정도지만, 대부분의 고객이 미국 기반이라 PT가 더 직관적일 수 있음  
  - 아마도 **야간 대응의 어려움**을 강조하려는 의도였을 수도 있음  

- per-endpoint 버전 관리나 **2PC, 단일 writer lease** 같은 패턴이 없다는 게 놀라웠음. 그래도 AWS가 이렇게 투명하게 공개한 건 높이 평가함  
  - 실제로 DNS 변경 API는 CAS를 수행하지만, 여러 비동기 writer가 **논리적 순서 없이 경쟁**하면서 문제가 생김. zone serial이나 sentinel record를 이용해 순서를 직렬화했어야 함  

- 나는 이번 사건의 **직접적 원인**이 DynamoDB DNS 관리 시스템의 잠재적 레이스 컨디션이었다고 봄. 오래된 계획이 최신 계획을 덮어써 지역 엔드포인트의 DNS 레코드가 비어버림  
  - 하지만 “루트 원인”이라는 개념에는 주의가 필요함. 이번은 **메타안정적 붕괴(metastable collapse)** 였고, 핵심 문제는 복구 절차(runbook)의 부재였음.  
    참고: [How Complex Systems Fail](https://how.complexsystems.fail/)