DynamoDB에서 시작된 레이스 컨디션이
EC2, 네트워크, 보안, 고객 콜센터까지 무너뜨린 15시간

미국 서부시간(PDT) 기준 2025년 10월 19일 밤 11시 48분부터 10월 20일 오후 2시 20분까지, AWS의 북부 버지니아 리전(us-east-1)에서 대규모 서비스 장애가 발생했다. 영향은 세 갈래로 나뉜다.

DynamoDB 장애 (10/19 11:48 PM ~ 10/20 2:40 AM)
DynamoDB의 엔드포인트 DNS가 잘못 구성되면서 API 호출이 실패했고, 신규 연결 자체가 안 됐다. 이건 단순히 DynamoDB만 죽은 게 아니라, DynamoDB에 의존하는 수많은 AWS 내부 서비스까지 동시에 흔들었다.
EC2 신규 인스턴스 장애 (10/20 2:25 AM ~ 10:36 AM, 후속 영향은 1:50 PM까지 지속)
기존에 떠 있던 인스턴스는 살아있었지만, 새로운 EC2 인스턴스가 뜨지 않거나 네트워크가 붙지 않는 치명적 문제가 이어졌다. 결과적으로, 확장(scale-out), 복구(auto-healing), 신규 배포 롤아웃이 막혔다.
NLB(Network Load Balancer) 연결 오류 (10/20 5:30 AM ~ 2:09 PM)
로드밸런서가 정상 인스턴스를 ‘비정상’으로 오판하면서 트래픽 라우팅이 흔들렸고, 일부 애플리케이션은 실제로 외부 연결 자체가 불가능해졌다.

동시에 Lambda, ECS/EKS/Fargate, STS(보안 토큰), Redshift, Amazon Connect(콜센터), IAM 로그인 등 다수의 핵심 서비스가 영향을 받았다. 즉, 이번 사건은 “DynamoDB만 불편했던 밤”이 아니라 “AWS의 심장부(us-east-1)에 걸린 심근경색”에 가까웠다.

1차 원인: DynamoDB의 DNS가 사라졌다

DynamoDB에서 벌어진 일은 놀랍도록 아이러니하다. 문제는 스토리지나 컴퓨팅 리소스 부족이 아니라 DNS 레벨에서 서비스 엔드포인트가 ‘없는 것처럼’ 보여버린 것이다.

DynamoDB 같은 초대형 서비스는 지역 엔드포인트(예: dynamodb.us-east-1.amazonaws.com)를 DNS로 계속 갱신한다.
이 갱신은 자동화된 두 컴포넌트가 맡는다:
- DNS Planner: 어떤 로드밸런서들이 살아 있고 용량이 충분한지 보고 “플랜”을 짠다.
- DNS Enactor: 그 플랜을 실제로 Route53에 반영한다. 이건 고가용성을 위해 AZ 3곳에서 독립적으로 돌아간다.

원래 설계 의도는 훌륭하다.

여러 가용영역에서 독립적으로 적용 → 한쪽이 죽어도 다른 쪽이 복구 가능
계획(Planner)과 실행(Enactor)을 분리 → 회복력 강화

그런데 바로 이 분리 구조와 고가용성 설계가, 이번엔 희귀한 레이스 컨디션(race condition) 을 만들었다.

대략적으로 이런 일이 벌어졌다:

Enactor A가 오래된 DNS 플랜을 아직 반영 중이었는데, 처리 지연이 길어졌다.
그 사이 Enactor B는 더 새로운 플랜을 이미 빠르게 전체 반영하고, “아주 오래된 플랜은 이제 정리(삭제)하자”고 클린업을 돌렸다.
타이밍이 최악이었다. A가 뒤늦게 자기(오래된) 플랜을 DynamoDB의 리전 엔드포인트에 덮어쓰는 순간과, B가 “오래된 플랜은 지워버릴게!” 하고 삭제하는 순간이 겹쳤다.
결과: 리전 엔드포인트 DNS 레코드가 ‘빈 상태(empty record)’로 남았다. 즉, DynamoDB의 공식 출입문이 주소를 잃어버린 것.
더 치명적인 것: 시스템이 스스로 고칠 수 없는 비일관(inconsistent) 상태에 빠졌고, 이후 자동화가 다음 플랜을 적용하지 못했다. 결국 인간 오퍼레이터가 수동介入해야 했다.

이 한 방으로 어떤 일이 일어났나?

외부 고객 애플리케이션은 DynamoDB에 새 연결을 못 맺음
AWS 내부 서비스도 DynamoDB를 못 봄
글로벌 테이블은 다른 리전 복제본으로 쿼리는 가능했지만, us-east-1 쪽 복제가 밀리면서 지연/정체 발생

복구는 이렇게 진행됐다:

12:38 AM: 엔지니어들이 “이거 DNS다”라고 원인 확인
1:15 AM: 일부 임시우회 마련, 내부 주요 툴 복구
2:25 AM: DNS 정보 완전 복구
2:40 AM: 캐시 만료를 거치며 고객 연결 회복 완료

이건 디스크나 CPU가 아니라 ‘이름 해석(Name Resolution)’이 죽었을 때 전체 클라우드가 어떤 꼴이 되는지 보여준 교육용 사례다.

2차 충격: EC2 신규 인스턴스가 안 뜨는 장기 후폭풍

DynamoDB 쪽 DNS는 2:25 AM에 복구됐지만, 그게 곧장 “모든 게 정상화”를 의미하진 않았다.

EC2는 새 인스턴스를 띄우고 네트워크를 구성할 때 여러 내부 서브시스템을 거친다. 그 중 두 개가 중요한데:

DWFM (DropletWorkflow Manager)
물리 서버(“droplet”) 상태를 추적하고, 새 인스턴스를 얹을 수 있는지 관리하는 시스템.
각 droplet은 DWFM과 ‘리스(lease)’라는 관계를 맺고 있어야 배포 대상이 된다.
Network Manager
새 인스턴스에 VPC 라우팅/보안/인터넷 경로 등 네트워크 구성을 전파하는 시스템.

여기서 벌어진 일:

DWFM 리스가 깨졌다
장애 시작 시점(11:48 PM)부터 DWFM은 DynamoDB에 의존한 상태 체크를 못 돌렸다.
그동안 유지 중이던 droplet-리스가 타임아웃나기 시작했다.
리스가 없는 droplet은 “배포 가능 후보”에서 빠진다 → 결과적으로 EC2는 “용량 부족(insufficient capacity)” 또는 “요청 한도 초과(request limit exceeded)” 오류를 뿜기 시작.
복구 시도 중 DWFM이 과부하에 빠졌다
2:25 AM 이후 DynamoDB가 돌아오자 DWFM은 모든 droplet과 리스를 다시 맺으려 했지만, 대상이 너무 많아서 처리 큐가 밀리며 스스로 병목에 걸렸다.
이건 사실상 DWFM 자체의 “혼잡 붕괴(congestive collapse)”였다.
이 상황은 정형화된 플레이북이 없던 유형이라 AWS 엔지니어가 조심스럽게 수작업 개입을 시작했다.
- 4:14 AM: 유입 트래픽(요청)을 인위적으로 줄이고
- DWFM 호스트들을 선별 재시작해서 큐를 비우는 방식으로 회복을 유도
5:28 AM: 결국 모든 droplet 리스가 복구되고, 새로운 EC2 인스턴스가 다시 뜨기 시작했다.
하지만 네트워크 전파(Network Manager)가 밀렸다
인스턴스는 이제 뜨는데, VPC 라우팅/보안 그룹 등 네트워크 설정이 뒤늦게 반영되면서 새 인스턴스들이 “부팅은 했지만 통신이 안 되는 좀비” 상태가 됨.
6:21 AM: Network Manager가 밀린 전파(backlog)를 처리하느라 지연이 커졌고, 신규 인스턴스들이 실사용 네트워크에 붙지 못했다.
10:36 AM: 네트워크 전파 지연 해소.
전체 EC2 정상화는 오후에야
EC2 팀은 과도한 요청 폭주를 막기 위해 걸어둔 스로틀(throttle)을 점진적으로 풀었다.
1:50 PM: 신규 인스턴스 생성과 API 호출이 완전히 정상화되었다.

요약하면:
DynamoDB 한 번 비틀어진 게 → DWFM이 droplet 리스 다 잃고 → DWFM 복구 과정에서 과부하가 나고 → 복구 후엔 Network Manager가 밀리고 → EC2 신규 인스턴스 전체가 ‘제대로 못 뜨거나, 떠도 안 붙거나, 붙어도 제한된 상태’에 들어가는 도미노였다.

여기서 중요한 건 기존에 이미 떠 있던 EC2 인스턴스는 정상이었다는 점이다. 즉, 이번 사태는 “확장/재배포/자동복구가 막혔다”는 점에서 운영팀과 SRE 팀에게는 최악의 악몽이었다.

3차 파급: NLB와 상위 서비스들까지 연쇄 붕괴

EC2 신규 인스턴스의 네트워크 전파가 지연되자, 그 위에 얹혀 있는 NLB(Network Load Balancer) 도 흔들렸다 (5:30 AM ~ 2:09 PM).

NLB는 백엔드 타깃(주로 EC2 인스턴스)이 헬스한지 체크해서 라우팅을 조정한다. 그런데 이번엔 이런 일이 발생했다:

네트워크 설정이 아직 안 붙은 새 인스턴스들이 투입되다 보니, 헬스 체크가 “얘 죽었네?”라고 잘못 판단.
그러면 로드밸런서는 “죽은 타깃 빼!” 하고 DNS에서 빼고, 또 다음 주기에는 “어? 살아있네?” 하고 다시 넣고…를 반복.
이 플리핑이 폭증하면서 헬스 체크 서브시스템도 부하를 받음.
결국 일부 가용영역(AZ) 전체를 비활성화하는 자동 페일오버가 오작동처럼 연쇄 발생 → 남은 용량이 트래픽을 못 받는 순간 실제 고객 연결 오류로 이어짐.

AWS는 9:36 AM에 자동 AZ 페일오버를 강제로 껐고, 그 즉시 정상 노드들이 다시 서비스에 편입되면서 NLB 연결 오류가 줄었다. 이후 EC2가 충분히 회복된 뒤 2:09 PM에 자동 페일오버를 재활성화했다.

이 NLB 흔들림은 상위 계층 서비스까지 동시에 건드렸다. 예를 들어:

AWS Lambda
함수 생성/업데이트 실패
이벤트 소스(SQS/Kinesis 등) 처리 지연
내부 시스템이 과소 스케일된 상태에서 재확장 못 하다가 throttling으로 버티는 상황 발생
완전 정상화는 2:15 PM
ECS / EKS / Fargate
새 컨테이너 기동 실패, 클러스터 오토스케일 지연
정상화는 2:20 PM
Amazon Connect(콜센터 서비스)
고객사의 인바운드 콜이 통화 중 신호로 튕기거나 연결 불가
상담원이 로그인조차 안 되는 경우도 발생
실시간/히스토리 대시보드 데이터 업데이트도 지연
복구는 1:20 PM (단, 데이터 백필은 10월 28일까지 진행 예정이라고 명시)

또한,

STS(Security Token Service): 임시 보안 토큰 발급 지연 및 에러 (IAM 인증 흐름 전체에 영향)
IAM 기반 로그인: AWS 콘솔 로그인 자체가 일정 시간 장애
Redshift: 쿼리 불가, 클러스터 수정 불가. 일부 클러스터는 EC2 인스턴스 교체(자동 복구)조차 못 해서 “수리 중(modifying)”에 갇혔다가 다음날 새벽(10/21 4:05 AM PDT)까지 순차 복구.

이걸 비즈니스 관점에서 번역하면,

“서버를 늘릴 수 없고”
“콜센터는 전화를 못 받고”
“데이터 웨어하우스는 쿼리를 안 받고”
“오토스케일링은 뻗었고”
“보안 토큰도 안 나와서 콘솔도 잘 못 들어가고”
→ SaaS 기업, 커머스, 금융, 게임, 고객지원센터, 데이터 분석 파이프라인, 거의 모든 B2C/B2B 실시간 비즈니스가 us-east-1에 물려 있었다면 직격탄이었다.

us-east-1은 AWS에서 가장 오래되고 가장 큰 리전 중 하나다. 거기서 이런 일이 발생했다는 건 단지 “한 리전 문제”라고 치부하기 어렵다. 사실상 인터넷 인프라의 중추가 흔들린 셈이다.

왜 이렇게 크게 번졌나?

핵심 교훈은 세 가지다.

초기 단일 장애 지점이 의외로 ‘DNS 자동화’였다
누구나 고가용성을 위해 자동화를 쌓는다.
AWS도 Planner/Enactor의 이중화·분산화를 통해 “설계상 안전”을 확보했다고 믿었다.
그런데 그 복잡성과 중복성이, 예측 불가능한 동시 동작으로 인해 ‘희귀하지만 치명적인 상태’를 만들었다.
즉, 탄탄한 자동화가 때로는 인간이 상상하지 못한 부조화를 터뜨릴 수 있다는 점이 드러났다.
내부 의존성의 사슬 효과
DynamoDB 장애 → DWFM 상태 갱신 실패 → EC2 신규 인스턴스 불가 → 네트워크 전파 백로그 → NLB 헬스체크 혼란 → 상위 서비스(Lambda, Connect 등) 연결 붕괴
이는 “마이크로서비스의 상호 의존성”이 실제로는 거대한 단일 생태계라는 걸 적나라하게 보여준다.
독립적으로 보이는 각 서비스는 사실상 서로의 생존을 보장하는 인프라 레이어였다.
복구는 기술만의 문제가 아니었다, 운영의 문제였다
DWFM이 혼잡 붕괴에 빠졌을 때, 그 상황은 매뉴얼화되어 있지 않았다.
엔지니어들은 추가적인 장애를 유발하지 않으면서 큐를 비우고 스로틀링을 조정하고, 호스트를 선별 재시작해야 했다.
즉, 이건 “셀프 힐링 아키텍처”만으로 해결되는 문제가 아니었다. 여전히 경험 많은 인간 운영자가 마지막 안전장치였다.

AWS가 약속한 후속 조치

AWS는 이번 사건 이후 다음과 같은 수정 계획을 공개했다.

DynamoDB 쪽 자동화(DNS Planner / DNS Enactor) 전 세계 비활성화
레이스 컨디션을 재현·수정하고
잘못된 DNS 플랜이 Route53에 반영되거나 삭제되지 못하도록 보호 장치(‘더블 세이프티’) 추가 예정.
NLB 쪽 보호 장치
헬스체크 오판으로 인해 특정 AZ 전체가 빠르게 빠져나가는 것을 제한하는 속도 제어(velocity control) 를 도입해, 급격한 용량 이탈을 막겠다고 밝혔다.
EC2 / DWFM 쪽 개선
DWFM 복구 워크플로 자체를 부하 상황에서 반복 테스트하는 새로운 테스트 스위트 추가
대기열 크기를 기반으로 하는 지능적 스로틀링(= 단순한 일괄 제한이 아니라, 실제 큐 상태를 보고 유입량을 제어) 도입
추후 유사 상황에서도 DWFM이 혼잡 붕괴에 빠지지 않도록 복구 가능한 운영 경로(formalized recovery path)를 마련

큰 틀에서 보면, AWS는 이번 사건을 “희귀 이벤트”로만 처리하지 않았다. DNS 자동화를 전 세계적으로 잠시 멈췄다는 건, 이번 이슈를 구조적 취약점으로 인식했다는 뜻이다. 이건 매우 중대한 시그널이다. DNS는 클라우드의 혈관이다. 혈관 수술 없이 다시 걷지 않겠다는 얘기다.

우리(고객/엔터프라이즈/SaaS)는 무엇을 배워야 하나

“멀티 리전”은 구호가 아니라 생존 전략이다.
DynamoDB 글로벌 테이블을 다른 리전에 두었던 고객은 읽기/쓰기 대체 경로를 어느 정도 확보했다.
하지만 애플리케이션 아키텍처가 us-east-1에 하드코딩된 팀은 장시간 마비를 피하기 어려웠다.
이제 DR(재해 복구) 시나리오에서 “같은 리전 내 다른 AZ로 페일오버”만으로 충분하다는 주장은 설득력이 약해진다. 이번 장애는 AZ 수준이 아닌 리전 전반에서 발생했다.
오토스케일과 셀프 힐링은 만능이 아니다.
많은 팀이 “문제 생기면 ASG(Auto Scaling Group)가 새 인스턴스 띄워줄 거야”라고 믿는다.
이번 사건에서 바로 그 ‘새 인스턴스 띄우기’가 안 됐다.
즉, 자동 복구 전략 자체가 장애의 인질이 될 수 있다.
장기 운영 전략엔 “안정적으로 떠 있는 최소 코어 인프라를 유지하고, 대규모 재배포 없이도 몇 시간 버틸 수 있는 설계”가 필요하다.
콜센터, 인증, 데이터 웨어하우스까지… ‘업타임’의 정의가 바뀐다.
많은 기업의 매출은 콜센터(예: Amazon Connect 기반), 결제 처리용 마이크로서비스(Lambda/ECS), 실시간 분석(Redshift) 위에 서 있다.
이번 장애는 “클라우드가 멈추면 내 비즈니스는 얼마나 빨리 오프라인화되는가?”라는 질문을 경영진 레벨까지 끌어올릴 것이다.
단순 SLA(99.99%) 문구가 아니라, 콜센터 우회 시나리오 / 인증 백업 경로 / 데이터 분석 지연 허용 범위 등을 보드룸에서 논의해야 한다.
컴플라이언스·규제 환경도 바뀔 수 있다.
금융, 헬스케어, 공공기관 고객은 이런 사고를 보고 “클라우드 단일 사업자 리스크”를 다시 테이블 위에 올릴 것이다.
특히 us-east-1처럼 단일 리전에 서비스와 데이터가 집중된 구조는, 규제 기관 시각에서 ‘집중 리스크’로 읽힌다.
유럽이 DSA로 빅테크 투명성과 책임을 강제하듯, 인프라 레벨에서도 “가용성·회복 전략의 투명한 공개” 요구가 커질 가능성이 있다.

이번 us-east-1 장애는 하나의 교훈을 남긴다.

우리는 늘 “클라우드는 탄력적이고, 자가치유하고, 알아서 복구된다”고 믿어왔다. 하지만 실제로 시스템을 지탱한 것은 수십만 개에 이르는 DNS 레코드를 굴리는 자동화, 복잡한 상태 관리 파이프라인(DWFM, Network Manager), 그리고 마지막 순간에 수동으로 밸브를 잠그고 큐를 비우는 사람들,
이었다.

다시말해, 클라우드는 마법이 아니었다. 아주 복잡한 기계이며, 그 기계의 허리 하나—이번엔 DynamoDB DNS—가 끊어지면, 애플리케이션 레이어부터 고객센터 전화선까지 한 번에 흔들릴 수 있다는 사실이 증명됐다.

이 사건은 이제 모든 CTO, SRE, CISO, COO에게 같은 질문을 던진다.

“us-east-1이 12시간 동안 부분 마비되면, 당신 회사는 몇 분 안에 알아차릴 준비가 되어 있는가?
그리고 그다음 11시간 동안 버틸 계획은 있는가?”