AWS us-east-1 14시간 장애: 클라우드 시대, 여전히 불완전한 이유

2025년 10월 20일, AWS us-east-1에서 14시간 동안 이어진 대규모 장애가 발생했습니다. 140개의 서비스가 멈췄고, 핵심인 EC2는 물론 DynamoDB, Lambda 등 전반적인 AWS 운용에 혼란이 퍼졌죠. AWS의 명성이 흔들리는 이 사건은 왜 발생했고, 우리에게 어떤 교훈을 남겼을까요? 오늘은 실질적인 장애 흐름과 숨겨진 원인, 그리고 앞으로 클라우드 신뢰성을 어떻게 바라봐야 할지 흥미롭게 풀어봅니다.

AWS us-east-1을 강타한 장애, 일파만파로 번진 원인

AWS의 장애는 단 하나의 서비스 --- DynamoDB ---에서 시작됐습니다. 6:48AM UTC에 발생한 작은 장애가, 이내 EC2와 네트워크 부문, 그리고 나머지 137개 서비스로 확산됐죠. 많은 서비스들이 DynamoDB와 EC2에 직간접적으로 의존하는 구조 때문입니다. 특히 AWS는 자사 서비스 개발과 운영에 DynamoDB를 적극적으로 "도그푸딩"하는데, 이렇게 '1단계 서비스'가 멈추면 도미노처럼 모든 서비스가 같이 다운됩니다.

DNS 관리 시스템의 '경쟁 조건'과 설계 오류

장애의 핵심 원인은 DynamoDB의 DNS 관리 자동화 시스템에 숨어 있었습니다. AWS는 DNS 레코드를 관리하는 'Enactor' 프로세스를 세 AZ(가용영역)에 분산시켜 독립적으로 운영하지만, 이들 간에는 별도의 조율이 없습니다. 한 AZ, 즉 us-east-1a의 Enactor가 심각하게 느려진 사이, 오래된 DNS 계획(Plan)이 삭제되면서 실제 활성 DNS 정보까지 잘못 날아가버렸죠. 결국 DynamoDB의 엔드포인트가 'IP 주소 0개', 즉 완전한 장애 상태에 빠집니다. 이런 TOCTOU(Time-of-check-time-of-use) 버그는 AWS 같이 대규모 트래픽을 감당하는 플랫폼에서도 언제든 숨어 있을 수 있다는 걸 보여줍니다.

DynamoDB 장애가 EC2의 '메타스테이블 실패'로 번지다

DynamoDB가 멈추자 EC2 역시 중대한 장애를 맞았습니다. EC2의 물리 서버(Droplets) 상태를 관리하는 DropletWorkflow Manager(DWFM)가 DynamoDB를 통해 '상태 체크' 신호를 주고받는데, 이 신호가 끊겨서 수십만 개의 서버 리스(lease)가 한꺼번에 끊긴 거죠. 시스템은 정상일 때 소수의 broken lease만 관리하면 되지만, 장애 시에는 '리스 복구 대기열'이 폭증해 DWFM이 아예 마비됐습니다. 결국, EC2 사용자들은 인스턴스를 생성, 조작, 삭제조차 할 수 없는 기간이 길게 이어졌으며, 수작업이 들어가서야 복구되었습니다.

네트워크 로드 밸런서(NLB) 장애의 악순환

EC2 장애는 네트워크 로드 밸런서(NLB)에도 충격을 줬습니다. EC2 내 네트워크 설정 관리자가 폭주하면서 NLB 전체의 네트워크 구성 업데이트가 뒤처졌고, 이 때문에 NLB의 헬스체크 시스템이 잘못된 피드백을 받아 AZ(Availability Zone) 장애가 반복되는 악순환에 빠졌죠. AWS 내부에서도 "속도 제어 메커니즘이 필요하다"고 평가할 정도로, 컨트롤 시스템 설계의 범위와 한계가 확실하게 드러난 장애였습니다.

'뇌 유출', 나이 탓? 장애 분석의 흔한 오해와 진짜 교훈

대형 장애 때마다 따라붙는 "AWS의 인재 유출" 혹은 "us-east-1의 노후화" 같은 원인론은 이번에도 나왔지만, 실제 증거는 거의 없습니다. 오히려, 장애가 어느 기업이나 일어날 수 있음을 인정해야 합니다. 클라우드 서비스, 특히 AWS와 GCP 모두 최근 1년 새 심각한 장애를 겪었죠. 오늘의 교훈은, 아무리 안정적인 플랫폼이라도 복잡한 설계 속에 숨어 있는 취약점이 반드시 존재한다는 점입니다.

현대 클라우드 시스템은 언제든 '퇴행'할 수 있다

이 장애는 "소프트웨어 시스템은 본질적으로 결함과 버그, 잠재적 위험을 품고 운영된다"는 사실을 새삼 상기시킵니다. EC2, DynamoDB, NLB 모두 평소에도 여러 결함과 불완전함을 극복하며 돌아가죠. 장애가 오면 그 복잡성에 감춰진 문제들이 한꺼번에 터져나옵니다. '다섯 9'(99.999%)의 안정성은 대단한 도전이며, 진화하는 자동화와 운영 기술 덕분에 어느 정도 달성될 뿐입니다.

앞으로의 클라우드 신뢰성: 설계와 운용의 꾸준한 진화

비록 14시간이라는 엄청난 장애가 있었지만, AWS 그리고 전체 퍼블릭 클라우드 산업은 계속해서 설계와 운영의 미흡함을 찾아내고 극복하는 방향으로 진화합니다. 이제는 '루트 원인'만 찾으려는 시각 대신, 시스템 각 부분 간의 상호작용에서 문제가 어떻게 제어 실패로 이어지는지 입체적으로 바라봐야 합니다. 여러분의 서비스도 장애가 반드시 오겠지만, 이를 대비할 수 있는 설계와 절차가 핵심입니다.

마무리하며, 저 역시 AWS의 안정성을 높이 평가해왔지만, 오늘 사례에서 알 수 있듯이 '완벽함'은 여전히 요원합니다. 여러분의 서비스가 클라우드 위에서 돌고 있다면, 장애가 올 때 뜻밖의 연쇄 작용이 일어날 수 있음을 꼭 기억하세요. 크고 작은 장애 경험을 잘 기록하고 학습하는 것, 그게 현대 클라우드 시대의 살아남는 힘입니다.

출처 및 참고 : More Than DNS: The 14 hour AWS us-east-1 outage – Jonathon Belotti [thundergolfer]