AWS N. Virginia(US-EAST-1) 서비스 장애와 복구: 2025년 10월 사건의 모든 것

2025년 10월 19일부터 20일까지, AWS의 중추적 서비스들이 북버지니아(us-east-1) 리전에서 연쇄적으로 장애를 겪었습니다. 이 기간 동안 DynamoDB, EC2, NLB, Lambda 등 주요 클라우드 서비스들이 전체 시스템에 큰 영향을 주는 장애를 경험했는데요. 오늘은 그 장애의 원인부터 복구 과정, 그리고 사후 대책까지 상세하게 풀어봅니다.

장애의 시작: 작은 DNS 오류가 거대한 파도를 만들다

장애의 첫 신호는 10월 19일 11시 48분(PDT) DynamoDB에서 발생했습니다. AWS의 핵심 데이터 서비스인 DynamoDB가 DNS 설정 오류로 API 에러율이 급증하며 연결이 불가능해진 것이죠. 이 문제의 원인은 '자동화된 DNS 관리 시스템' 내에 잠재된 레이스 컨디션(race condition)이었는데, 올바른 DNS 레코드 대신 빈 값이 적용되며 서비스 연결이 막혔습니다.

AWS는 복잡한 DNS 구조를 자동화하여 수백만 이상의 레코드를 실시간으로 관리하고 있습니다. 이런 자동화 덕분에 확장성과 복구 능력을 확보하지만, 이번엔 예상치 못한 동시 처리 오류가 연쇄적으로 터졌습니다.

EC2 인스턴스 런치 실패와 네트워크 트래픽 혼란

DynamoDB 장애가 터지자, 즉각적으로 EC2 인스턴스의 신규 런치에 심각한 문제가 발생했습니다. 기존에 구동 중인 인스턴스는 영향을 받지 않았지만, 새로운 인스턴스를 띄우는 API 요청이 'capacity 부족' 혹은 'request limit exceeded' 오류로 실패하기 시작한 것입니다.

원인은 EC2의 하위 관리 시스템(DropletWorkflow Manager)이 정상적으로 상태 체크를 못 하면서 신규 런치 요청을 처리할 수 없었기 때문입니다. 또한 네트워크 매니저(Network Manager)가 새로운 인스턴스의 네트워크 상태를 전파하는 데 지연이 발생해, 런치된 인스턴스조차도 통신 장애를 겪었습니다.

네트워크 로드밸런서(NLB)에도 충격파: 정상-오류 반복

EC2 장애가 네트워크 로드밸런서(NLB)까지 번졌습니다. 새로 추가된 EC2 인스턴스들의 네트워크 상태가 늦게 반영되면서 NLB의 헬스체크가 오락가락, 노드가 계속 서비스에서 제거됐다가 다시 등록되는 악순환이 반복됐죠.

이런 불안정한 상태가 자동 DNS 페일오버를 촉발해, 멀티 AZ(NLB가 여러 가용영역에 분산됨) 환경에서는 용량 일부가 서비스에서 깔끔히 빠지며 연결 오류가 많아졌습니다. 엔지니어들이 자동 페일오버를 중단하면서 일시적으로 문제가 잡혔습니다.

Lambda, ECS, Redshift 등 주요 서비스 연쇄 장애

DynamoDB, EC2, NLB 장애는 AWS 생태계 전체로 확산됐습니다. 서버리스 환경인 Lambda에서 함수 생성·업데이트가 지연됐고, 메시지 큐 SQS와 Kinesis 이벤트 처리까지 오류가 났으며, ECS와 EKS, Fargate 상에서 컨테이너 런치와 클러스터 확장도 늦춰졌습니다.

Redshift 역시 쿼리 처리와 클러스터 관리에 장애가 발생, IAM 인증 실패와 EC2 문제로 일부 클러스터는 복구까지 24시간 가까이 걸렸습니다.

장애 극복 과정: 엔지니어들의 침착한 대응

AWS 엔지니어들은 문제 원인을 빠르게 파악하고, 부분적으로 우선 복구를 진행했습니다. DynamoDB의 DNS 상태를 되살리고, NLB의 헬스체크와 EC2 인스턴스 런치/네트워크 상태를 정상화하기 위한 여러 단계의 작업을 밤샘으로 수행했습니다.

특히 DropletWorkflow Manager와 Network Manager 등 복잡한 하부 시스템을 재실행하며 대기열을 해소하고, 신규 인스턴스 런치와 네트워크 연결이 순차적으로 복구됐습니다.

근본 원인 분석과 재발 방지 대책 발표

AWS는 이번 장애의 핵심 원인을 'DynamoDB DNS 관리 시스템의 동시 처리 결함'으로 공식적으로 밝혔습니다. 문제 재발을 막기 위해 관련 DNS 자동화 시스템을 글로벌 적용 중단하고, 안전장치를 추가할 계획입니다. NLB에는 헬스체크로 인한 가용성 손실을 제한하는 'velocity control'을 도입하고, EC2에는 복구 절차 자동화 및 큐 기반 요청 스로틀링 방식을 개선 중입니다.

장기적으로는 장애 겪은 모든 서비스를 점검해 연쇄 장애나 복구 지연이 없도록 체계적인 개선을 약속했습니다.

쿠키 정책: 개인정보 보호와 맞춤 경험의 균형

AWS는 장애 안내와 더불어 쿠키 관리와 개인정보 보호에도 신경을 씁니다. 필수 쿠키는 서비스 운영에 반드시 필요하며, 사용자가 선택적으로 성능, 광고, 기능성 쿠키를 허용·차단할 수 있습니다. 타겟 광고/행동 광고 관련 설정 역시 유연하게 지원됩니다.

개인정보와 쿠키 설정 관리에 대한 안내 역시 모든 사용자에게 투명하게 제공됩니다.

마무리: 클라우드 안정성의 중요성과 실용적 조언

이번 AWS 장애는 '작은 시스템 결함이 대규모 클라우드 인프라에 어떻게 연쇄적인 영향을 줄 수 있는지' 생생하게 보여줬습니다. 클라우드 환경을 통한 비즈니스 확장과 자동화가 매력적인 만큼, 장애 대응 및 복구 시나리오를 반드시 갖춰야 한다는 교훈도 다시금 확인하게 되었죠.

혹시 AWS나 클라우드 기반 서비스를 운영 중이라면, 고가용성 설정과 멀티 리전 백업, 장애 상황에서의 즉각적인 커뮤니케이션 채널을 미리 준비하세요. 또한, 쿠키와 개인정보 보호 설정 역시 팀/사용자와 함께 꼼꼼히 체크하는 습관이 중요합니다.

기술의 발전과 자동화가 편리함을 가져오는 만큼, 예상하지 못한 실패 시에도 빠르고 침착한 대응이 진정한 경쟁력이 될 것입니다.

출처 및 참고 : Summary of the Amazon DynamoDB Service Disruption in Northern Virginia (US-EAST-1) Region