Incident Library

IL-0223 Amazon Web Services · 2021-12-07awsnetworking

us-east-1 에서 AWS 내부 네트워크와 주 네트워크를 잇는 장비가 연결 폭주로 혼잡해져 EC2 API 와 여러 AWS 서비스의 제어 평면이 몇 시간 동안 오류를 냈다.

AWS 는 대부분의 서비스와 모든 고객 애플리케이션을 주 AWS 네트워크에서 돌리고, 모니터링, 내부 DNS, 권한 서비스, EC2 제어 평면 일부 같은 기반 서비스는 별도의 내부 네트워크에서 돌린다. 두 네트워크는 지리적으로 떨어진 여러 네트워크 장비로 이어지고, 이 장비가 라우팅과 네트워크 주소 변환을 맡는다. 2021-12-07 PST 오전 7시 30분에 주 네트워크의 한 서비스 용량을 늘리는 자동 작업이 내부 네트워크의 많은 클라이언트에서 예상하지 못한 동작을 일으켰고, 연결이 폭주해 두 네트워크 사이의 장비가 넘쳤다. 통신이 늦어지자 지연과 오류가 늘고 그 때문에 연결 시도와 재시도가 더 늘어, 혼잡이 계속 이어졌다. 클라이언트에는 혼잡할 때 재시도 간격을 늘려 물러서는 back-off 동작이 있었고, 이 동작은 충분히 시험한 것이었다. 하지만 오래전부터 운영 중이던 코드 경로의 잠재된 문제 때문에 이번에는 back-off 가 제대로 동작하지 않았다.

혼잡은 곧바로 운영팀의 실시간 모니터링 데이터를 끊었다. 운영자는 로그에서 내부 DNS 오류가 늘어난 것을 찾았다. 내부 DNS 트래픽을 혼잡한 경로에서 옮겨 오전 9시 28분에 DNS 해석 오류를 없앴지만, 혼잡은 남았다. 그 뒤 트래픽을 가장 많이 내는 출처를 전용 장비로 분리하고, 트래픽이 많은 서비스 일부를 끄고, 네트워크 용량을 늘렸다. 이 작업은 느렸다. 모니터링이 보이지 않았고, 내부 네트워크에서 도는 배포 시스템도 영향을 받았으며, 정상으로 돌고 있는 워크로드를 건드리지 않으려고 아주 조심스럽게 바꿔야 했기 때문이다. 혼잡은 오후 1시 34분에 크게 나아졌고 오후 2시 22분에 모든 네트워크 장비가 회복됐다.

주 네트워크는 멀쩡해서 고객 워크로드는 직접 영향을 받지 않았지만, 내부 네트워크에 기대는 서비스 제어 평면이 망가졌다. EC2 API, ELB API, Route 53 API, Console 로그인, STS, CloudWatch, VPC Endpoints 를 거친 S3 와 DynamoDB 접근, API Gateway, EventBridge, Fargate, ECS, EKS, Amazon Connect 가 영향을 받았다. 일부 서비스는 밀린 작업을 처리하느라 네트워크 회복 뒤에도 몇 시간 더 걸렸다. 모니터링이 망가지고 Service Health Dashboard 도구가 대기 리전으로 넘어가지 못해 고객 공지가 늦었고, 지원 케이스도 오후 2시 25분까지 만들 수 없었다. AWS 는 이번 일을 촉발한 확장 작업을 즉시 껐다.

심각도
–
영향 범위
AWS services and control planes that depend on the internal network in us-east-1: EC2 APIs and instance launches, ELB, Route 53 APIs, Console logins, STS, CloudWatch, VPC Endpoints for S3 and DynamoDB, API Gateway, EventBridge, Fargate, ECS, EKS, Amazon Connect and support case creation
영향 사용자
–
지역
us-east-1
감지까지
–
복구까지
6h 52m

증상

2021-12-07 PST 오전 7시 33분부터 us-east-1 에서 새 인스턴스를 띄우거나 기존 인스턴스를 조회하는 EC2 API 의 오류율과 지연이 늘었다. AWS 운영팀은 혼잡이 시작되자 곧바로 실시간 모니터링 데이터를 볼 수 없었다.

모니터링 데이터가 없어 운영자는 로그로 상황을 파악했고, 처음에는 내부 DNS 오류가 늘어난 것을 찾았다. 내부 DNS 트래픽이 혼잡을 키운다고 보고 이 트래픽을 혼잡한 경로에서 옮겼다. 오전 9시 28분에 DNS 해석 오류는 완전히 회복됐지만 혼잡과 서비스 영향은 남았고, 모니터링 데이터도 여전히 보이지 않았다. 운영자는 그 뒤 트래픽을 가장 많이 내는 출처를 전용 네트워크 장비로 분리했다. 오후 12시 35분의 EventBridge 이벤트 전달을 포함해 트래픽이 많은 서비스 일부를 끄고, 네트워크 용량을 늘렸다. 이 작업은 느렸다. 모니터링 데이터가 보이지 않았고, 내부 네트워크에서 도는 배포 시스템도 영향을 받았다. 주 네트워크에서 정상으로 돌던 워크로드를 건드리지 않으려고 조심스럽게 바꿔야 하기도 했다.

이미 돌고 있는 EC2 인스턴스는 영향이 없었지만, 새 EC2 인스턴스를 띄울 수 없어 Amazon RDS, EMR, Workspaces 고객은 새 리소스를 만들지 못했다. 기존 Elastic Load Balancer 는 정상이었지만 ELB API 오류와 지연으로 새 로드 밸런서 프로비저닝이 늦어지고 기존 로드 밸런서에 인스턴스를 등록하는 데 시간이 더 걸렸다. Route 53 API 는 오전 7시 30분부터 오후 2시 30분까지 망가져 DNS 레코드를 바꿀 수 없었지만, 기존 레코드와 DNS 질의 응답은 정상이었다. 이 리전의 AWS Console 로그인이 실패했다. OpenID Connect 로 외부 ID 제공자용 자격 증명을 발급하는 Amazon Secure Token Service 도 느려져, Redshift 처럼 STS 로 인증하는 서비스의 로그인이 실패했다.

다른 서비스에서도 증상이 나왔다. CloudWatch 모니터링이 내내 늦어 고객은 애플리케이션 영향을 파악하기 어려웠고, 일부 지표에는 데이터가 빠졌다. VPC Endpoints 를 거친 S3 버킷과 DynamoDB 테이블 접근이 망가졌다. Lambda 함수를 호출하는 데 자주 쓰는 API Gateway 의 오류율이 올랐고, EventBridge 도 초기에 오류가 늘었다. Fargate, ECS, EKS 는 API 오류와 지연이 늘었고, 기존 태스크나 파드는 계속 돌았지만 종료되거나 실패한 컨테이너는 다시 시작하지 못했다. Fargate 는 밀린 컨테이너 기동 요청 때문에 Insufficient Capacity Errors 를 냈다. Amazon Connect 는 전화, 채팅, 태스크 처리 실패율이 올랐다.

고객과의 소통도 막혔다. 지원 컨택 센터가 AWS 내부 네트워크에 의존해 오전 7시 33분부터 오후 2시 25분까지 지원 케이스를 만들 수 없었다. Service Health Dashboard 도구는 혼잡 때문에 대기 리전으로 넘어가지 못했고, 오전 8시 22분에야 업데이트가 올라가기 시작했다.

혼잡은 오후 1시 34분에 크게 나아졌고 오후 2시 22분에 모든 네트워크 장비가 회복됐다. EC2 API 는 오후 1시 15분부터 나아졌지만 새 인스턴스 기동은 오후 2시 40분에 회복됐다. STS 는 오후 4시 28분, API Gateway 는 오후 4시 37분에 대부분 회복됐다. EventBridge 는 밀린 이벤트를 처리하느라 오후 6시 40분까지 이벤트 전달이 늦었고, Fargate 는 오후 5시부터 API 오류율이 정상으로 돌아오기 시작했다.

증상 컨트롤 플레인 지연지연 시간 증가오류율 상승모니터링 중단DNS 조회 실패

원인

원인 소프트웨어 결함

구성 요소 트랜짓 게이트웨이와 네트워크 연결 장비자동 용량 관리 시스템
기여 요인 재시도 폭주순환 의존
촉발
PST 오전 7시 30분에 주 AWS 네트워크에서 도는 한 AWS 서비스의 용량을 늘리는 자동 작업이, 내부 네트워크 안의 많은 클라이언트에서 예상하지 못한 동작을 일으켰다. 연결 시도가 한꺼번에 몰려 내부 네트워크와 주 네트워크 사이의 네트워크 장비가 감당하지 못했다.

감지

혼잡이 시작되자 운영팀의 실시간 모니터링 데이터가 곧바로 끊겼다. 운영자는 로그를 보고 상황을 파악했고, 처음에는 내부 DNS 오류가 늘어난 것을 찾았다.

조치

후속 조치

교훈

–

출처

관련 사례

내 클러스터에도 있는지 확인하기

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: 트랜짓 게이트웨이와 네트워크 연결 장비, 자동 용량 관리 시스템. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.