AWS 대규모 장애 분석 - 2025년 10월 20일

들어가며

어제(10월 20일) 오후 4시쯤 저도 HUGO와 AWS S3, CloudFront로 블로그를 해보겠다고 이리저리 해보고 있는데 ACM 페이지에서 갑자기 오류가 뜨길래 에잇! 이놈에 인터넷! 하고 죄없는 ISP를 욕하고 있었는데 ㅎㅎ알고보니 AWS 장애가 발생했었다고 합니다. 이후로 구글 트렌드에도 AWS가 뜨고 버지니아 리전에 붉은색이 막 뜨는걸보니 제법 큰 장애겠구나 싶었습니다.

2년 만에 또 AWS에서 대규모 장애가 발생했습니다. 이번엔 좀 크더군요. 약 15시간 동안이나 전 세계 서비스들이 먹통이 되었으니까요.

그래서 이번 장애가 어떻게 일어났는지, 언론사들은 어떤 보도를 했고, AWS는 뭐라고 했는지, 그리고 우리는 뭘 배워야 하는지 정리해보겠습니다.

1. 언론사 보도

한국 언론 보도

한국 언론들은 이번 장애의 피해 규모를 중점적으로 다뤘습니다.

발생 시점

한국시간 10월 20일 오후 4시경 (미국은 새벽 3시쯤이었죠)
미국 북부 버지니아에 있는 US-EAST-1 리전에서 시작
AWS 최대 데이터센터 권역 중 하나라고 하네요

영향받은 서비스들

생각보다 정말 많았습니다.

글로벌 서비스들:

Snapchat, Fortnite, Roblox 같은 게임들
Perplexity 같은 AI 검색 서비스
Coinbase, Robinhood 같은 금융 서비스
Venmo, Signal, Duolingo까지

국내도 마찬가지:

삼성월렛, 삼성닷컴
배틀그라운드 (크래프톤)

심지어 항공사도:

델타항공, 유나이티드항공 웹사이트와 앱이 다운
일부 공항에서는 수동으로 탑승 수속을 해야 했다고 하네요

영국까지:

로이드은행, 스코틀랜드은행
보다폰, BT 그룹 같은 통신사
심지어 국세청 웹사이트까지

다운디텍터(장애를 추적하는 사이트)에 신고가 5만~6.5만 건이 접수됐다고 합니다. 전 세계 1,000개 이상의 사이트와 서비스가 영향을 받았다니… 규모가 어마어마합니다.

미국 언론 보도

미국 언론들은 좀 더 기술적인 부분에 집중했습니다.

발생 원인인

근본 원인은 DNS(Domain Name System) 확인 문제였다고 합니다. 쉽게 말하면, 웹사이트 주소를 IP 주소로 변환해주는 시스템이 고장 난 거죠. 구체적으로는 DynamoDB라는 데이터베이스 서비스의 API 엔드포인트에서 DNS 해석이 안 되는 문제였습니다.

여기서 끝이 아니었습니다. DNS 문제는 해결했는데, EC2 인스턴스를 새로 구동하는 것이 안됐다고 합니다. EC2가 DynamoDB에 의존하고 있었거든요. 그러니까 연쇄적으로 문제가 확산된 거죠. 거기다 Network Load Balancer까지 헬스체크가 안 되면서 Lambda, CloudWatch 같은 서비스들도 덩달아 문제가 생겼다고 합니다.

복구는 어떻게

새벽 3:11 (미 동부시간): AWS가 처음으로 “문제가 있네요” 인정
오전 6:35: DNS 문제는 해결
오후 12:28: 많이 복구됨
오후 6:00: 거의 다 정상으로 돌아옴
총 약 15시간 걸렸네요

전문가들 말로는 “사이버 공격은 아닌 것 같다"고 하고, “현대 인터넷이 소수의 클라우드 회사에 너무 의존하고 있다"는 우려를 표했습니다. 맞는 말이죠.

2. AWS 공식발표

AWS도 공식적으로 발표를 했습니다. 생각보다 투명하게 정보를 공개했습니다.

공식 타임라인

10월 19일 23:49 ~ 10월 20일 02:24 (PDT 기준)

US-EAST-1 리전에서 오류율이랑 지연시간이 확 늘어남
Amazon.com이랑 자회사들, 심지어 AWS Support팀도 영향을 받음

10월 20일 00:11

여러 서비스에서 오류율 증가 확인
DynamoDB API 엔드포인트의 DNS 해석 문제로 파악

10월 20일 00:26

원인을 명확하게 특정함 - 지역 DynamoDB 서비스 엔드포인트의 DNS 해석 장애

10월 20일 02:24

DynamoDB DNS 문제 완전 해결
근데 일부 내부 시스템은 아직도 문제 있음

10월 20일 12:28

많은 고객과 서비스가 상당히 복구됨
EC2 새 인스턴스 띄우는 거 천천히 풀어주는 중

10월 20일 15:01

모든 서비스 정상 복귀
일부는 밀린 메시지 처리 중

문제 발생원인 정리리

정리하면 이렇습니다:

1차 원인: DynamoDB의 DNS 해석이 안 됨
2차 문제: DNS는 고쳤는데 EC2가 DynamoDB에 의존해서 EC2 인스턴스를 못 띄움
3차 파급: Network Load Balancer 헬스체크 실패로 Lambda, CloudWatch 등도 연쇄적으로 문제 생김

3. 언론 vs AWS 공식 발표 비교

일치하는 부분

시간과 장소

둘 다 미 동부시간 새벽 3시경, US-EAST-1 리전이라고 함
복구 시각도 저녁 6시경으로 일치

원인

DNS 문제라는 건 언론이나 AWS나 똑같이 말함
DynamoDB 관련이라는 것도 동일

영향

전 세계 수백~수천 개 서비스가 타격
항공, 금융, 게임, 통신 등 다양한 분야

차이점

기술적 디테일

언론은 일반인들 눈높이에 맞춰서 “DNS 문제"로 간단히 설명했지만, AWS는 좀 더 구체적으로 설명했습니다:

DynamoDB API 엔드포인트의 DNS 해석 문제
EC2 내부 서브시스템의 DynamoDB 의존성
Network Load Balancer 헬스체크 연쇄 장애

복구 과정의 복잡함

AWS 발표를 보니, DNS 문제를 해결한 후에도 EC2 인스턴스 런칭을 일부러 제한(throttling)하면서 천천히 복구했다고 하네요. 급하게 복구하다가 또 뭔가 터질까 봐 조심스럽게 진행한 거죠. 이건 언론에서는 안 다뤘습니다.

내부 피해

언론은 외부 서비스 중단만 다뤘는데, AWS 발표를 보니 Amazon.com이랑 자회사들, 심지어 AWS Support 팀까지 영향을 받았다고 하네요. 실제로 CNBC 보도에서는 Amazon 물류창고 직원들이 내부 시스템을 못 써서 휴게실에서 기다려야 했다고 합니다.

평가

전반적으로 AWS가 꽤 투명하게 정보를 공개했습니다. 근데 아쉬운 점도 있죠:

왜 터졌나: DNS 문제가 발생한 근본 원인(소프트웨어 업데이트 실수? 설정 오류?)은 설명 안 함
보상은: 과거에도 문제였던 보상 정책에 대한 언급이 없음
재발 방지: 앞으로 어떻게 할 건지 구체적인 대책이 빠짐

4. 과거에도 이런 적 있었나

맞습니다. AWS도 이런 대형장애가 처음은 아닙니다.

주요 장애 이력

2021년 12월 7일 - US-EAST-1 장애

최근 대규모 장애 중 가장 심각했던 것
약 5시간 넘게 지속
항공 예약, 자동차 딜러십, 결제 앱, 비디오 스트리밍 다 먹통
Amazon Kinesis Data Streams 문제가 원인

2023년 6월 13일 - US-EAST-1 장애

몇 시간 동안 웹사이트들 오프라인
The Boston Globe, 뉴욕 MTA, AP통신 등 영향
Lambda, EventBridge, SQS, CloudWatch 등 문제

기타

2020년: 여러 차례 장애
2018년 11월 22일: 한국 서울 리전 마비 (DNS 문제였음!)
2017년: S3 대란
2015년: DynamoDB 장애

장애 시점들 대비 비교/패턴턴

이번 2025년 10월 20일 장애

2023년 6월 장애로부터 약 2년 4개월 경과
2021년 12월 대규모 장애로부터 약 3년 10개월 경과

발견한 패턴들:

US-EAST-1 리전이 자꾸 문제의 중심에 있음
DNS 관련 문제가 반복됨 (2018년 한국, 2025년 미국)
대규모 장애가 대략 2~3년 주기로 발생
DynamoDB도 반복적으로 문제 (2015년, 2025년)

5. AWS 대응은 어땠나

잘한 점

빠른 초기 대응

문제 발생 후 약 22분 만에 공식 인지 및 공지
약 1시간 15분 만에 근본 원인 파악

투명한 소통

Health Dashboard로 실시간 업데이트
기술적 세부사항도 공개
구체적인 타임라인 제공

신중한 복구

DNS 문제 해결 후 EC2 스로틀링으로 안정적 복구
추가 장애 방지를 위한 단계적 접근

개방적이고 좋은 대응으로 보입니다.

아쉬운 점

같은 문제의 반복

DNS 문제는 2018년 한국에서도 있었음
7년이 지났는데 또 같은 문제
DynamoDB도 마찬가지 (2015년, 2025년)

단일 리전 의존

US-EAST-1 하나가 터졌는데 전 세계가 먹통
글로벌 서비스들도 여전히 단일 리전에 과하게 의존

보상 정책

과거에 한국 기업들이 불공정 계약으로 제대로 된 보상 못 받은 사례가 있음
이번엔 어떻게 할지 아직 불명확

예방 조치 부족

2~3년마다 대규모 장애 반복
같은 US-EAST-1에서 계속 문제
충분한 테스트가 안 된 건 아닌지…

다른 클라우드도 비슷하긴 합니다

AWS만 그런 건 아니에요:

Microsoft Azure: 2023년 1월 Teams, Outlook, Microsoft 365 터짐
Microsoft 365: 2025년 10월 초 장애 (구글이 이걸 마케팅으로 써먹음 ㅋㅋ)
Google Cloud: 2025년 6월 장기 장애로 OpenAI, Shopify 등 타격
CrowdStrike: 2024년 7월 소프트웨어 업데이트 실수로 Fortune 500 기업들에게 54억 달러 손실

클라우드 산업 전체의 구조적 문제이거나,, 현재로써는 이정도 수준이 최선일수도 있겠습니다.

6. 우리는 뭘 배워야 하나

클라우드 의존성의 위험

집중화의 함정

AWS가 전 세계 클라우드 시장의 약 30~33%를 차지합니다. 거기에 Microsoft, Google까지 합치면… 소수 회사에 너무 많이 의존하고 있어 보입니다. 전형적인 단일 장애점(Single Point of Failure) 문제입니다.

어떻게 개선할 수 있을까?

Multi-Cloud 전략

단일 클라우드 제공업체에만 의존하지 맙시다. 중요한 시스템은 여러 리전에 분산 배포하고요. 최소한 핵심 기능만이라도 failover 시스템을 구축해두는 게 좋습니다.

설계부터 다르게

장애를 가정한 설계 (Design for Failure)
Circuit Breaker 패턴 같은 장애 격리 메커니즘
Graceful degradation 구현 (서비스가 완전히 죽지 않고 기능만 제한되게)

사회적으로는?

규제와 정책

클라우드 서비스를 중요 인프라로 지정하는 논의 필요
SLA 및 보상 정책에 대한 규제 강화
공공 서비스의 클라우드 의존도 관리

다각화

오픈소스 대안이나 자체 호스팅도 검토
지역별, 국가별 클라우드 생태계 육성
과도한 중앙집중화 방지

마무리하며

2025년 10월 20일 AWS 장애는 우리의 클라우드 의존도가 꽤 크다는 것을 잘 보여줬습니다. 약 15시간 동안 전 세계 수백만 명이 일상적인 서비스를 못 쓰고, 기업들은 막대한 손실을 입었습니다.

AWS는 나름 투명하게 문제를 공개하고 빠르게 대응했습니다. 하지만 2~3년마다 반복되는 대규모 장애, 특히 같은 US-EAST-1 리전에서 계속 발생하는 문제들을 보면… 구조적 개선이 필요해 보입니다. DNS나 DynamoDB 같은 핵심 서비스에서 과거와 비슷한 장애가 재발하는 건 좀 걱정스럽습니다.

기억해야 할 점은:

AWS를 포함해서 어떤 클라우드도 100% 완벽할 수 없다. 장애는 ‘만약’이 아니라 ‘언제’의 문제다. 그러니 우리 모두 클라우드 장애에 대비해야 한다.

클라우드의 편리함과 확장성은 정말 좋고 부인할 수 없습니다. 하지만 그에 따른 리스크도 분명 존재합니다. 현명한 클라우드 활용은 이 리스크를 인지하고 대비하는 것에서 시작됩니다.

완벽한 시스템은 없습니다. 중요한 건 장애에 얼마나 잘 대비하고, 발생했을 때 얼마나 빠르게 복구하며, 재발 방지를 위해 뭘 배우느냐입니다.

AWS의 이번 장애는 우리 모두에게 다시 한번 이 교훈을 일깨워줬습니다.

AWS도 장애가 날 수 있으니, 항상 대비합시다 ;-)