2025년 10월 20일 발생한 AWS 장애

한국 시간으로 10월 20일 오후 4시 11분경 AWS에서 대규모 장애가 발생했습니다. 제가 지금 운영 중인 서비스도 AWS 기반인 데다 핵심 기능 대부분이 AWS API 호출로 돌아가고 있어서, 이번 장애는 타격이 컸습니다. 장애 발생 얼마 되지 않아 사내 슬랙에 장애 알림이 돌기 시작했고 AWS Health 모니터링 및 서비스 영향도 분석 및 대응을 진행했습니다.

그리고 장애 발생 이후 AWS 측에서는 us-east-1 리전의 장애에 대해서 요약한 내용의 글이 업로드 되었습니다. 장애와 관련하여 여러 아티클을 읽었는데 AWS에서 공식적으로 요약한 내용의 글은 명확한 장애의 상황을 인지하는데 가장 도움 될 것으로 생각했습니다.

이번 글에서는 이번 AWS 장애 상황에 대해 AWS 측에서 올린 요약 글을 바탕으로 정리해보도록 하겠습니다.

장애의 규모와 us-east-1 리전의 특수성

2025 년 10월 20일 AWS 에서AWS에서 발생한 대규모 장애는 전 세계의 수많은 온라인 서비스를 마비시키며 현대 디지털 인프라의 상호 의존성과 취약성을 드러냈습니다. 다양한 국가의 다양한 산업군의 다양한 디지털 서비스가 영향을 받았으며, 이런 서비스를 사용하는 사용자들은 큰 불편을 겪었고 경제적인 피해 또한 엄청날 것으로 추정합니다. 대체 클라우드 인프라의 넘버원인 AWS에서 장애 상황이 15시간 이상 지속되어 발생했을까요?

us-east-1 리전에 대한 특수성을 먼저 이해하는 것으로 시작해야합니다. us-east-1 (버지니아) 리전은 AWS의 최초의 리전입니다. 버지니아 리전은 가장 규모가 크고 오래된 데이터센터입니다. 실제로 다양한 글로벌 서비스를 제공하는 기업들이 해당 리전을 기본 리전으로 설정하여 사용하고 있습니다. 또한 AWS 내부적으로 백본 역할을 하는 리전으로 IAM과 같은 핵심 글로벌 서비스가 해당 리전에 기반을 두고 운영되고 있습니다. 그렇기 때문에 대부분의 멀티 리전 아키텍처가 갖춰진 서비스라 할지라도 핵심적인 내부 기능이 us-east-1에 의존하고 있던 상황이었습니다.

직접적인 기술적 원인: DynamoDB의 DNS 장애

us-east-1 리전 장애의 직접적인 기술적 원인은 DNS (Domain Name System) 였습니다. DNS는 dynamodb.us-east-1.amazonaws.com과 같이 사람이 읽을 수 있는 도메인 이름을 IP 주소로 변환해 주는 시스템입니다. 만약 해당 시스템이 정상적으로 작동하지 않게 된다면, 서비스들은 서비스 간의 IP 주소를 알 수 없어 잘못된 요청을 목적지로 보내게 됩니다.

AWS는 “DynamoDB API 엔드포인트의 DNS Resolution 문제”를 근본적인 초기 장애 원인으로 지목하였습니다. 이는 많은 애플리케이션과 서비스들이 도메인을 사용하여 DynamoDB에 접근하려 해도 그 주소를 찾을 수 없다는 것을 의미합니다.

DynamoDB는 AWS에서 제공하는 완전 관리형 NoSQL 데이터베이스 서비스로 key-value 기반의 데이터를 가지며 높은 확장성과 성능이 특징입니다. DynamoDB는 AWS 고객뿐만 아니라 AWS의 내부 서비스들의 기반 인프라로 광범위하게 사용되고 있었습니다. EC2, Lambda, IAM 등 가장 기본적인 (Fundamental) 서비스들 조차 상태 정보 저장, 메타데이터 관리 등을 위해 DynamoDB에 의존하고 있습니다.

근본 원인: 자동화 시스템의 ‘경쟁 조건(Race Condition)’

DNS 의 장애를 초래한 결정적인 원인은 자동화된 DNS 관리 시스템의 잠재적인 결함인 ‘경쟁 조건(Race Condition)‘이었습니다. 다음은 AWS의 장애 요약에서 확인할 수 있는 경쟁 조건이 발동된 메커니즘입니다.

DynamoDB의 DNS 시스템은 ‘DNS Planner’가 DNS 변경 계획을 생성하고, 여러 가용 영역(AZ)에서 독립적으로 실행되는 ‘DNS Enactor’가 이 계획을 실제 DNS 레코드에 적용하는 구조로 작동합니다.
장애 직전, ‘Enactor 1’이 특정 오래된 계획(Old Plan) 을 적용하던 중 비정상적으로 높은 지연(delay)을 겪으며 작업이 매우 느려졌습니다.
그 사이 ‘Planner’는 정상적으로 계속 작동하며 여러 세대의 최신 계획(New Plan) 들을 생성했고, 다른 ‘Enactor 2’가 이 최신 계획 중 하나를 가져와 모든 엔드포인트에 성공적으로 빠르게 적용을 완료했습니다.
‘Enactor 2’는 최신 계획 적용을 마친 직후, “plan clean-up process(정리 프로세스)“를 시작하여 자신이 적용한 계획보다 “여러 세대 이전(many generations older)“이라고 판단되는 계획들을 삭제 대상으로 식별했습니다. 여기에는 ‘Enactor 1’이 아직 붙들고 있던 이전 계획이 포함되었습니다.
바로 이 시점에 경쟁 조건(Race Condition)이 발생했습니다. ‘Enactor 2’의 정리 프로세스가 이 이전 계획을 삭제하려던 찰나, 지연되던 ‘Enactor 1’이 마침내 해당 이전 계획을 리전 엔드포인트에 적용하는 데 성공하며 ‘Enactor 2’가 적용했던 최신 계획을 덮어썼습니다.
이 덮어쓰기로 인해 ‘Enactor 1’이 적용한 이전 계획이 시스템의 유효한(활성화된) 계획이 되었지만, ‘Enactor 2’의 정리 프로세스는 이 사실을 인지하지 못했습니다. ‘Enactor 2’는 자신이 적용한 최신 계획을 기준으로 “오래되었다”라고 판단했기 때문에, 방금 활성화된 이 유효한 계획을 삭제해 버렸습니다.
결과적으로, 활성화된 계획이 삭제되면서 dynamodb.us-east-1.amazonaws.com 엔드포인트의 모든 IP 주소 레코드가 DNS에서 즉시 제거되었고, 시스템은 더 이상 자동 업데이트가 불가능한 비정상 상태에 빠졌습니다.

대규모 시스템 운영에 필수적인 자동화가 장애의 원인이 되었습니다. 운영 효율성을 극대화하기 위한 정교한 자동화 시스템에서 발생할 수 있는 결함을 파악하지 못한 채 경쟁 조건이라는 문제가 발생하면서 시스템이 스스로 장애가 발생하는 방향으로 동작하게 되었습니다.

장애의 연쇄 확산 과정

DynamoDB DNS 장애라는 단일 실패는 AWS 인프라의 여러 계층을 거치며 연쇄적으로 확산되었습니다.

1단계: 글로벌 제어 영역 장애 전파

DynamoDB의 DNS 확인이 불가능해지면서 DynamoDB에 의존하는 내부 서비스들이 가장 먼저 실패하기 시작했습니다.
특히 US-EAST-1에 기반을 둔 IAM과 같은 글로벌 제어 영역 서비스가 영향을 받았습니다. 이로 인해 다른 리전의 사용자들 조차 IAM을 사용한 서비스에 문제를 겪게 되었습니다.

2단계: EC2 장애 전파

DNS 문제로 인하여 장애는 EC2로 확산되었습니다. EC2 인스턴스가 실행되는 물리 서버인 Droplet의 상태와 임대(Lease)를 관리하는 DropletWorkflow Manger(DWFM)라는 내부 시스템은 자신의 상태 정보를 저장하는데 DynamoDB를 사용하고 있었습니다.

DynamoDB에 접근할 수 없게 된 DWFM는 상태 확인에 실패해 EC2 인스턴스는 새로운 상태 변경이 불가능하여 시작 혹은 중지등 액션이 불가능하게 되었습니다. 이후 DynamoDB 가 복구되고 나서 (최초 장애 발생 후 2시간 29분 후) 전체EC2 플릿에 걸쳐 DWFM 는 임대 상태를 재설정하려는 시도가 급격하게 발생하면서 시스템의 처리 용량을 초과하는 요청 증가로 인해 시스템이 마비되었습니다.

이로 인해 신규 EC2 인스턴스 시작이나 기존 시스템 상태 변경이 대규모로 실패하게 되었습니다.

3단계: 애플리케이션 장애 전파

EC2 시작이 지연되자 인스턴스 상태를 확인하는 NLB의 헬스 체크 시스템이 영향을 받았습니다. NLB는 새로 시작된 EC2 인스턴스가 네트워크 설정 지연으로 응답하지 않자 이를 비정상으로 판단하고 로드 밸런싱 대상에서 제외하고 정상화되었을 때 다시 포함시키는 과정이 반복되면서 네트워크의 불안정성을 야기했습니다.

앞선 문제로 인해 Lambda, ECS, EKS, SQS 등 고수준 AWS 서비스들이 연쇄적으로 오류율 증가와 연결 문제를 겪었습니다. 이 시점에서 장애는 AWS의 거의 모든 계층으로 확산되었고 최종 사용자들은 서비스의 마비를 경험하게 되었습니다.

최초 장애 발생 원인인 DNS 문제는 2시간 30분 만에 해결되었지만 완전한 정상화까지는 길게는 하루가 넘게 소요된 서비스도 있었습니다. 초기 DNS 문제가 해결되자 대기하고 있던 DWFM 시스템이 DynamoDB에 폭발적으로 접근하면서 시스템이 마비되었습니다. AWS는 복구 과정에서 EC2 인스턴스 시작과 같은 요청을 의도적으로 쓰로틀링 하여 2차 장애 제어를 위한 조치를 수행하였습니다. 이는 필수적인 조치였지만 복구가 지연되는 원인이 되었습니다.

복구 지연과 2차 장애

매일 작업하는 ‘클라우드’라는 시스템이 얼마나 복잡하게 얽혀서 돌아가고 있는지, 그리고 장애는 정말 피할 수 없는 것이란 걸 다시 한번 깨닫게 됐습니다.

이번 AWS 장애는 특히 ‘단일 실패 지점(SPOF)‘이 가진 구조적 취약점이 제대로 증명된 사례가 아닌가 싶습니다.

생각해 보면 이렇습니다.

AWS 고객들은 AWS 인프라에 의존하고 있었기 때문에 장애를 겪었고,
AWS 내부 서비스들은 그들의 백본인 us-east-1 리전에 의존하고 있었기 때문에 장애가 확산되었습니다.

겉으로는 드러나지 않았지만, AWS의 중앙 집중된 제어 영역이 사실상 거대한 단일 실패 지점이 될 가능성을 안고 있었던 것 같습니다. 결국 장애 복구를 위해 비싼 돈 들여 멀티 리전 전략을 구축했던 수많은 서비스가 이 us-east-1 의존성 하나 때문에 속수무책으로 무력화되는 상황을 마주해야 했습니다.

그리고 또 하나, 복구 과정에서 발생한 ‘재시도(Retry)‘은 의외의 지점에서 배울 점이 많은 것 같습니다.

DynamoDB 문제가 해결되자마자, EC2의 내부 관리 시스템(DWFM)으로 리스(lease) 갱신 요청이 한꺼번에 몰렸습니다. DWFM은 이 요청들을 처리하려 했지만, 큐가 꽉 차고 작업은 타임아웃되기 시작했죠. 그리고 타임아웃된 작업은 재시도(Retry)되었습니다.

결국 DWFM은 풀가동되고 있었지만, 실제로는 밀려드는 재시도 요청을 처리하느라 아무런 ‘유용한’ 작업도 완료하지 못하는 완전한 마비 상태에 빠졌습니다.

사실 이건 저도 비슷한 경험이 있습니다. 타임아웃이 발생하면 재시도를 하도록 되어 있는 설정으로 인해 이미 실패한 요청이 작업 큐에 계속 남아있는 상태에서 재시도 요청이 쌓이면서 기존의 요청은 계속해서 리소스를 사용하는 로직을 찾아내 개선했던 기억이 있습니다.

이번 AWS 장애를 보면서 시스템에 넣는 ‘재시도 로직’은 정말 서비스의 안정적인 회복을 위한 것일지, 아니면 오히려 서비스 장애를 더 크게 만드는 방아쇠는 아닐지 생각했습니다.