미국 동부(버지니아 북부, us-east-1) 리전에서 발생한 Amazon DynamoDB 서비스 중단 요약

미국 동부(버지니아 북부, us-east-1) 리전에서 2025년 10월 19~20일에 발생한 서비스 중단에 대해 추가 정보를 공유드립니다. 이벤트는 10월 19일 오후 11시 48분(PDT)에 시작되어 10월 20일 오후 2시 20분(PDT)에 종료되었으며, 고객 애플리케이션에 세 차례에 걸친 명확한 영향 구간이 있었습니다. 첫째, 10월 19일 오후 11시 48분부터 10월 20일 오전 2시 40분까지 Amazon DynamoDB의 API 오류율이 증가했습니다. 둘째, 10월 20일 오전 5시 30분부터 오후 2시 09분까지 일부 Network Load Balancer(NLB)에서 연결 오류가 증가했습니다. 이는 NLB 플릿에서 헬스 체크 실패가 발생하여 일부 NLB에서 연결 오류가 늘어난 데 기인합니다. 셋째, 10월 20일 오전 2시 25분부터 오전 10시 36분까지 신규 EC2 인스턴스 시작이 실패했으며, 오전 10시 37분부터 시작이 성공하기 시작했지만 일부 신규 인스턴스에서 연결 문제가 발생했고 이는 오후 1시 50분에 해소되었습니다.

DynamoDB

10월 19일 오후 11시 48분부터 10월 20일 오전 2시 40분(PDT)까지, N. Virginia(us-east-1) 리전에서 고객들은 Amazon DynamoDB API 오류율 증가를 겪었습니다. 이 기간 동안 DynamoDB에 종속된 고객 및 기타 AWS 서비스는 서비스에 대한 신규 연결을 설정할 수 없었습니다. 인시던트는 서비스의 자동화된 DNS 관리 시스템 내 잠재 결함으로 인해 DynamoDB의 엔드포인트 해석 실패가 발생하면서 촉발되었습니다.

대규모 AWS 서비스 다수는 원활한 확장, 장애 격리 및 복구, 지연 시간 단축, 지역성(locality) 제공을 위해 DNS에 광범위하게 의존합니다. DynamoDB와 같은 서비스는 각 리전에서 매우 큰 이기종 로드 밸런서 플릿을 운영하기 위해 수십만 개의 DNS 레코드를 유지합니다. 자동화는 이러한 DNS 레코드를 자주 업데이트하여 신규 용량을 추가하고, 하드웨어 장애를 올바르게 처리하며, 트래픽을 효율적으로 분산해 고객 경험을 최적화하는 데 필수적입니다. 이 자동화는 복원력을 고려해 설계되어 다양한 운영 이슈에서의 복구를 가능하게 합니다. 퍼블릭 리전 엔드포인트 제공과 더불어, 이 자동화는 FIPS 규격 준수 엔드포인트, IPv6 엔드포인트, 계정별 엔드포인트 등 여러 동적 DynamoDB 변형에 대한 추가 DNS 엔드포인트도 유지합니다. 이번 이슈의 근본 원인은 DynamoDB DNS 관리 시스템의 잠재적인 레이스 컨디션으로, 서비스의 리전 엔드포인트(dynamodb.us-east-1.amazonaws.com)에 대해 잘못된 빈 DNS 레코드가 생성되었고 자동화가 이를 복구하지 못한 것이었습니다.

이번 이벤트를 설명하기 위해 DynamoDB DNS 관리 아키텍처를 일부 공유하겠습니다. 가용성을 위해 시스템은 두 개의 독립 구성요소로 분리되어 있습니다. 첫 번째 구성요소인 DNS Planner는 로드 밸런서의 상태와 용량을 모니터링하고, 각 서비스 엔드포인트에 대해 로드 밸런서 집합과 가중치로 구성된 새로운 DNS 플랜을 주기적으로 생성합니다. 최근 출시된 IPv6 엔드포인트와 퍼블릭 리전 엔드포인트처럼 여러 엔드포인트가 용량을 공유하는 경우 용량 관리와 장애 완화가 크게 단순해지므로, 리전 단위의 단일 DNS 플랜을 생성합니다. 두 번째 구성요소인 DNS Enactor는 어떤 상황에서도 시스템 복구가 가능하도록 의존성을 최소화해 설계되었으며, Amazon Route 53 서비스에 필요한 변경을 적용함으로써 DNS 플랜을 실행(enact)합니다. 복원력을 위해 DNS Enactor는 세 개의 서로 다른 가용 영역(AZ)에서 완전히 독립적으로 중복 운영됩니다. 각 독립 Enactor 인스턴스는 새로운 플랜을 탐색하고, Route 53 트랜잭션을 사용해 현재 플랜을 새 플랜으로 교체함으로써 플랜을 적용합니다. 이를 통해 여러 DNS Enactor가 동시에 업데이트를 시도하더라도 각 엔드포인트가 일관된 플랜으로 업데이트되도록 보장합니다.

레이스 컨디션은 두 개의 DNS Enactor 간 드물게 발생하는 상호작용에서 비롯됩니다. 정상 동작에서는 하나의 DNS Enactor가 최신 플랜을 가져와 서비스 엔드포인트 목록을 순회하며 플랜을 적용합니다. 이 과정은 일반적으로 빠르게 완료되어 DNS 상태를 신선하게 유지합니다. 새 플랜을 적용하기 전, DNS Enactor는 자신이 가진 플랜이 이전에 적용된 플랜보다 최신인지 일회성 검사를 수행합니다. Enactor가 엔드포인트 목록을 처리하는 동안, 동일 엔드포인트를 다른 Enactor가 업데이트 중이면 트랜잭션이 차단되어 지연이 발생할 수 있습니다. 이 경우 Enactor는 해당 엔드포인트에 대해 플랜이 모든 엔드포인트에 성공적으로 적용될 때까지 재시도합니다.

이 이벤트 직전, 한 DNS Enactor가 여러 DNS 엔드포인트에서 업데이트를 재시도해야 하는 비정상적으로 긴 지연을 겪었습니다. 이 Enactor가 엔드포인트를 천천히 처리하는 동안, 다른 일들이 동시에 일어났습니다. 첫째, DNS Planner는 계속 실행되어 더 최신 세대의 플랜을 여러 개 생성했습니다. 둘째, 다른 DNS Enactor 하나가 더 최신 플랜 중 하나를 적용하기 시작했고, 모든 엔드포인트를 빠르게 진행했습니다. 이러한 타이밍이 잠재된 레이스 컨디션을 촉발했습니다. 최신 플랜을 적용하던 두 번째 Enactor가 엔드포인트 업데이트를 완료하자, 자신이 방금 적용한 플랜보다 현저히 오래된 플랜을 식별해 삭제하는 플랜 정리(clean-up) 프로세스를 호출했습니다. 바로 그 시점에, 비정상적으로 지연되던 첫 번째 Enactor가 훨씬 오래된 플랜을 리전 DDB 엔드포인트에 적용해 최신 플랜을 덮어써 버렸습니다. 플랜 적용 시작 시점에 수행되는 “자신의 플랜이 이전에 적용된 플랜보다 최신인지”를 확인하는 검사는, Enactor 처리 지연이 비정상적으로 길어졌기 때문에 이미 구식이 되어 있었습니다. 따라서 이 검사는 오래된 플랜이 최신 플랜을 덮어쓰는 것을 막지 못했습니다. 이어서 두 번째 Enactor의 정리 프로세스가 이 오래된 플랜을 삭제했는데, 이는 자신이 방금 적용한 플랜에 비해 여러 세대 이전이었기 때문입니다. 이 플랜이 삭제되면서 리전 엔드포인트의 모든 IP 주소가 즉시 제거되었습니다. 또한 활성 플랜이 삭제되어 시스템이 불일치 상태에 빠졌고, 그 결과 이후의 어떤 DNS Enactor도 플랜 업데이트를 적용할 수 없게 되었습니다. 이 상황은 최종적으로 수동 운영자 개입을 필요로 했습니다.

이 이슈가 10월 19일 오후 11시 48분(PDT)에 발생했을 때, 퍼블릭 엔드포인트를 통해 N. Virginia(us-east-1) 리전의 DynamoDB 서비스에 연결해야 하는 모든 시스템은 즉시 DNS 실패를 겪었고 DynamoDB에 연결하지 못했습니다. 여기에는 고객 트래픽과 DynamoDB에 의존하는 내부 AWS 서비스 트래픽이 포함되었습니다. DynamoDB 글로벌 테이블을 사용한 고객은 다른 리전의 복제본 테이블에는 성공적으로 연결해 요청을 보낼 수 있었지만, N. Virginia(us-east-1) 리전의 복제본 테이블과의 양방향 복제 지연이 장시간 발생했습니다. 영향받은 AWS 서비스의 엔지니어링 팀은 즉시 참여해 조사를 시작했습니다. 10월 20일 오전 12시 38분까지 엔지니어는 DynamoDB의 DNS 상태가 장애의 원인임을 확인했습니다. 오전 1시 15분까지 적용된 임시 완화 조치로 일부 내부 서비스가 DynamoDB에 연결할 수 있게 되었고, 추가 복구를 가로막던 핵심 내부 도구가 복구되었습니다. 오전 2시 25분까지 모든 DNS 정보가 복원되었고, 오전 2시 32분까지 모든 글로벌 테이블 복제본의 동기화가 완료되었습니다. 고객은 DNS 캐시가 만료됨에 따라 오전 2시 25분에서 2시 40분 사이에 DynamoDB 엔드포인트를 정상적으로 해석하고 연결을 수립할 수 있었습니다. 이로써 1차 서비스 중단 이벤트로부터의 복구가 완료되었습니다.

Amazon EC2

10월 19일 오후 11시 48분부터 10월 20일 오후 1시 50분(PDT)까지, N. Virginia(us-east-1) 리전에서 고객은 EC2 API 오류율 및 지연 증가, 인스턴스 시작 실패를 겪었습니다. 이벤트 시작 이전에 시작된 기존 EC2 인스턴스는 내내 정상 상태를 유지했으며 영향이 없었습니다. 오전 2시 25분에 DynamoDB DNS 이슈를 해결한 후에도, 신규 인스턴스 시작에서 오류가 계속 발생했습니다. 복구는 오전 12시 01분(PDT)에 시작되어, 오후 1시 50분에 EC2가 완전히 복구되었습니다. 이 기간 동안 신규 인스턴스 시작은 “request limit exceeded” 또는 “insufficient capacity” 오류로 실패했습니다.

상황을 이해하기 위해, EC2 인스턴스 시작 관리와 신규 EC2 인스턴스의 네트워크 연결 구성에 사용되는 일부 하위 시스템에 대해 설명드리겠습니다. 첫 번째 하위 시스템은 DropletWorkflow Manager(DWFM)로, EC2 인스턴스를 호스팅하는 모든 물리 서버의 관리를 담당합니다. 우리는 이 서버들을 “droplet”이라고 부릅니다. 두 번째 하위 시스템은 Network Manager로, 모든 EC2 인스턴스와 네트워크 어플라이언스에 네트워크 상태를 관리하고 전파합니다. 각 DWFM은 각 가용 영역 내에서 일정 범위의 droplet을 관리하며, 현재 관리 중인 각 droplet에 대한 리스를 유지합니다. 이 리스는 DWFM이 droplet 상태를 추적하도록 하여, EC2 API에서 발생하는 작업이나 EC2 인스턴스 운영체제에서 시작되는 종료 또는 재부팅과 같은 작업이 EC2 전반의 올바른 상태 변경으로 이어지게 합니다. 이 리스를 유지하는 과정의 일부로, 각 DWFM 호스트는 자신이 관리하는 각 droplet과 몇 분마다 체크인하고 상태 점검을 완료해야 합니다.

10월 19일 오후 11시 48분부터, DynamoDB에 의존하는 이 DWFM 상태 점검이 완료되지 못해 실패하기 시작했습니다. 이는 실행 중인 EC2 인스턴스에는 영향을 주지 않았지만, 해당 droplet이 호스팅 중인 EC2 인스턴스에 대해 이후의 상태 변경이 발생하기 전에 droplet이 DWFM과 새로운 리스를 수립해야 하는 상황을 초래했습니다. 10월 19일 오후 11시 48분부터 10월 20일 오전 2시 24분 사이에, EC2 플릿 내 DWFM과 droplet 간 리스가 서서히 만료되기 시작했습니다.

오전 2시 25분(PDT), DynamoDB API가 복구되자 DWFM은 EC2 플릿 전반의 droplet과 리스를 재설정하기 시작했습니다. 활성 리스가 없는 droplet은 신규 EC2 시작 후보로 간주되지 않으므로, EC2 API는 들어오는 신규 EC2 시작 요청에 대해 “insufficient capacity” 오류를 반환했습니다. DWFM은 EC2 플릿 전반에서 droplet과의 리스 재설정을 진행했으나, droplet 수가 매우 많아 작업이 완료되기 전에 시간 초과가 발생했고, droplet 리스 수립을 재시도하기 위한 추가 작업이 큐에 적재되었습니다. 이 시점에 DWFM은 혼잡 붕괴(congestive collapse) 상태에 들어가 droplet 리스 복구에서 전진(progress)을 하지 못했습니다. 이 상황에 대해서는 확립된 운영 복구 절차가 없었기 때문에, 엔지니어들은 추가 문제를 야기하지 않도록 신중하게 DWFM 이슈 해결을 시도했습니다. 여러 완화 조치를 시도한 뒤, 오전 4시 14분에 엔지니어들은 들어오는 작업을 제한(throttle)하고 DWFM 호스트를 선별적으로 재시작하여 상황을 복구하기 시작했습니다. DWFM 호스트 재시작으로 DWFM 큐가 비워지고 처리 시간이 단축되어 droplet 리스를 수립할 수 있게 됐습니다. 오전 5시 28분까지 DWFM은 N. Virginia(us-east-1) 리전의 모든 droplet과 리스를 수립했으며, 신규 시작이 다시 성공하기 시작했습니다. 다만 전체 요청 부하를 줄이기 위해 도입한 요청 제한으로 인해 많은 요청에서 여전히 “request limit exceeded” 오류가 관찰되었습니다.

신규 EC2 인스턴스가 시작되면, Network Manager라는 시스템이 해당 인스턴스가 동일 VPC 내 다른 인스턴스, 다른 VPC의 네트워크 어플라이언스, 인터넷과 통신할 수 있도록 네트워크 구성을 전파합니다. 오전 5시 28분(PDT), DWFM 복구 직후 Network Manager는 이벤트 동안 종료된 인스턴스 및 신규로 시작된 인스턴스에 대한 업데이트된 네트워크 구성을 전파하기 시작했습니다. 이들 네트워크 전파 이벤트는 DWFM 이슈로 지연되었기 때문에, N. Virginia(us-east-1) 리전의 Network Manager가 처리해야 할 네트워크 상태 전파 백로그가 상당했습니다. 그 결과 오전 6시 21분에 Network Manager는 네트워크 상태 변경 백로그를 처리하는 과정에서 네트워크 전파 지연이 증가하기 시작했습니다. 신규 EC2 인스턴스를 시작하는 것은 가능했지만, 네트워크 상태 전파 지연으로 인해 필요한 네트워크 연결성이 확보되지 않을 수 있었습니다. 엔지니어들은 Network Manager의 부하를 낮추고 네트워크 구성 전파 시간을 개선하기 위한 조치를 취했습니다. 오전 10시 36분까지 네트워크 구성 전파 시간은 정상 수준으로 돌아왔고, 신규 EC2 인스턴스 시작도 다시 정상적으로 동작했습니다.

EC2 복구의 최종 단계는 다양한 EC2 하위 시스템의 부하를 줄이기 위해 도입했던 요청 제한을 완전히 제거하는 것이었습니다. API 호출과 신규 EC2 인스턴스 시작 요청이 안정화됨에 따라, 오전 11시 23분(PDT)에 엔지니어들은 완전한 복구를 향해 요청 제한을 완화하기 시작했습니다. 오후 1시 50분에는 모든 EC2 API와 신규 EC2 인스턴스 시작이 정상적으로 운영되었습니다.

Network Load Balancer (NLB)

신규로 시작된 EC2 인스턴스에 대한 네트워크 상태 전파 지연은 Network Load Balancer(NLB) 서비스와 NLB를 사용하는 AWS 서비스에도 영향을 주었습니다. 10월 20일 오전 5시 30분부터 오후 2시 09분(PDT)까지 일부 고객은 N. Virginia(us-east-1) 리전의 NLB에서 연결 오류 증가를 겪었습니다. NLB는 고도로 확장 가능한 멀티 테넌트 아키텍처 위에 구축되어 로드 밸런싱 엔드포인트를 제공하고, 일반적으로 EC2 인스턴스인 백엔드 타겟으로 트래픽을 라우팅합니다. 또한 아키텍처는 별도의 헬스 체크 하위 시스템을 사용하여 NLB 아키텍처 내 모든 노드에 대해 정기적으로 헬스 체크를 수행하고, 비정상으로 간주되는 노드를 서비스에서 제외합니다.

이벤트 중 헬스 체크 하위 시스템에서 헬스 체크 실패가 증가하기 시작했습니다. 이는 네트워크 상태가 아직 완전히 전파되지 않은 신규 EC2 인스턴스를 헬스 체크 하위 시스템이 서비스에 투입했기 때문입니다. 이로 인해, 근본적으로 NLB 노드와 백엔드 타겟이 정상임에도 일부 경우 헬스 체크가 실패했습니다. 그 결과 헬스 체크 결과가 실패와 정상 사이를 번갈아가며 나타났고, 이에 따라 NLB 노드와 백엔드 타겟이 DNS에서 제거되었다가 다음 헬스 체크가 성공하면 다시 서비스에 투입되는 현상이 반복되었습니다.

모니터링 시스템은 오전 6시 52분에 이를 감지했고, 엔지니어들은 문제 해결을 시작했습니다. 번갈아 나타나는 헬스 체크 결과로 인해 헬스 체크 하위 시스템의 부하가 증가하여 성능이 저하되었고, 헬스 체크 지연이 발생하며 자동 AZ DNS 페일오버가 트리거되었습니다. 멀티 AZ 로드 밸런서의 경우, 이로 인해 일부 용량이 서비스에서 제외되었습니다. 남은 정상 용량이 애플리케이션 부하를 처리하기에 충분하지 않으면 애플리케이션에서 연결 오류가 증가하게 됩니다. 오전 9시 36분에 엔지니어들은 NLB의 자동 헬스 체크 페일오버를 비활성화하여, 사용 가능한 모든 정상 NLB 노드와 백엔드 타겟이 다시 서비스에 투입되도록 했습니다. 이 조치로 영향받은 로드 밸런서의 연결 오류 증가가 해소되었습니다. 이후 EC2가 복구된 직후인 오후 2시 09분에 자동 DNS 헬스 체크 페일오버를 다시 활성화했습니다.

기타 AWS 서비스

10월 19일 오후 11시 51분부터 10월 20일 오후 2시 15분(PDT)까지, N. Virginia(us-east-1) 리전에서 고객은 Lambda 함수의 API 오류 및 지연을 겪었습니다. 초기에는 DynamoDB 엔드포인트 문제로 인해 함수 생성과 업데이트가 불가능했고, SQS/Kinesis 이벤트 소스 처리 지연 및 호출 오류가 발생했습니다. 오전 2시 24분까지 서비스 운영은 복구되었으나, SQS 큐 처리는 내부적으로 SQS 큐 폴링을 담당하는 하위 시스템이 실패하고 자동 복구되지 않아 계속 영향을 받았습니다. 이 하위 시스템은 오전 4시 40분에 복구되었고, 오전 6시까지 모든 메시지 백로그를 처리했습니다. 오전 7시 04분부터는 NLB 헬스 체크 실패로 인스턴스 종료가 트리거되어 Lambda 내부 시스템 일부가 스케일 부족 상태가 되었습니다. EC2 시작이 여전히 제약을 받는 상황에서, 지연 시간에 민감한 동기식 호출의 우선순위를 보장하기 위해 Lambda 이벤트 소스 매핑과 비동기 호출을 제한했습니다. 오전 11시 27분까지 충분한 용량이 복원되면서 오류가 감소했습니다. 이후 점진적으로 제한을 완화하고 오후 2시 15분까지 모든 백로그를 처리했으며, 정상 서비스 운영을 재개했습니다.

10월 19일 오후 11시 45분부터 10월 20일 오후 2시 20분(PDT)까지, Amazon Elastic Container Service(ECS), Elastic Kubernetes Service(EKS), Fargate 전반에서 컨테이너 시작 실패와 클러스터 스케일링 지연이 N. Virginia(us-east-1) 리전에서 발생했습니다. 해당 서비스는 오후 2시 20분에 복구되었습니다.

10월 19일 오후 11시 56분부터 10월 20일 오후 1시 20분(PDT)까지, Amazon Connect 고객은 N. Virginia(us-east-1) 리전에서 통화, 채팅, 케이스 처리 오류 증가를 겪었습니다. DynamoDB 엔드포인트 복원 이후 대부분의 Connect 기능은 복구되었으나, 오전 5시까지 채팅에서의 오류 증가는 지속되었습니다. 오전 7시 04분부터는 Connect가 사용하는 NLB의 영향과 Lambda 함수 호출 오류율 및 지연 증가로 인해 신규 통화, 채팅, 태스크, 이메일, 케이스 처리에서 오류가 다시 증가했습니다. 인바운드 발신자는 통화 중 신호음, 오류 메시지 또는 연결 실패를 경험했습니다. 상담사 initiated 및 API initiated 방식의 아웃바운드 통화가 실패했습니다. 연결된 통화에서도 프롬프트 재생 실패, 상담사 라우팅 실패, 무음(dead-air) 오디오가 발생했습니다. 또한 상담사는 연락 처리 오류가 증가했고 일부 상담사는 로그인하지 못했습니다. 고객은 API 및 연락 검색(Contact Search) 접근 시 오류 증가를 겪었습니다. 실시간 및 이력 대시보드, 데이터 레이크(Data Lake) 데이터 업데이트는 지연되었으며, 모든 데이터는 10월 28일까지 백필될 예정입니다. 오후 1시 20분에 Lambda 함수 호출 오류가 복구됨에 따라 서비스 가용성이 복원되었습니다.

10월 19일 오후 11시 51분부터 오전 9시 59분(PDT)까지, 고객은 N. Virginia(us-east-1) 리전에서 AWS Security Token Service(STS) API 오류 및 지연을 경험했습니다. 내부 DynamoDB 엔드포인트 복원 이후 오전 1시 19분에 STS가 복구되었습니다. 오전 8시 31분부터 9시 59분 사이에는 NLB 헬스 체크 실패의 영향으로 STS API 오류율과 지연이 다시 증가했습니다. 오전 9시 59분까지 NLB 헬스 체크 실패로부터 복구되었고 서비스는 정상 운영을 시작했습니다.

10월 19일 오후 11시 51분부터 10월 20일 오전 1시 25분(PDT)까지, IAM 사용자를 사용해 AWS Management Console에 로그인하려는 고객은 N. Virginia(us-east-1) 리전의 기본 DynamoDB 이슈로 인해 인증 실패가 증가했습니다. N. Virginia(us-east-1) 리전에 IAM Identity Center를 구성한 고객 또한 Identity Center를 사용해 로그인할 수 없었습니다. 루트 자격 증명을 사용한 고객과, signin.aws.amazon.com을 사용하도록 구성된 아이덴티티 페더레이션을 사용하는 고객은 N. Virginia(us-east-1) 리전 외의 리전에서 AWS Management Console에 로그인하려 할 때 오류를 경험했습니다. 오전 1시 25분에 DynamoDB 엔드포인트 접근이 가능해지면서 서비스는 정상 운영을 시작했습니다.

10월 19일 오후 11시 47분부터 10월 20일 오전 2시 21분(PDT)까지, 고객은 N. Virginia(us-east-1) 리전에서 Redshift 클러스터 생성 및 수정, 기존 클러스터 질의 실행 시 API 오류를 경험했습니다. Redshift 질의 처리는 클러스터에서 데이터를 읽고 쓰기 위해 DynamoDB 엔드포인트에 의존합니다. DynamoDB 엔드포인트가 복구됨에 따라 Redshift 질의 작업이 재개되었고, 오전 2시 21분까지 고객은 클러스터 질의 및 클러스터 구성 생성·수정을 성공적으로 수행했습니다. 그러나 DynamoDB 엔드포인트가 정상 운영으로 복원된 이후에도 일부 Redshift 컴퓨트 클러스터는 여전히 영향받아 질의에 사용할 수 없었습니다. 클러스터 노드의 자격 증명이 갱신되지 못하고 만료되면, Redshift 자동화는 기본 EC2 호스트를 새 인스턴스로 대체하는 워크플로를 트리거합니다. EC2 시작이 제약을 받으면서 이 워크플로가 차단되어 클러스터가 “modifying” 상태에 머무르게 되었고, 이로 인해 질의 처리가 불가능해져 워크로드에 사용할 수 없었습니다. 오전 6시 45분에 엔지니어들은 워크플로 백로그가 증가하지 않도록 조치를 취했으며, 오후 2시 46분에 Redshift 클러스터가 대체 인스턴스 시작을 시작하면서 워크플로 백로그가 소진되기 시작했습니다. 10월 21일 오전 4시 05분(PDT)까지 AWS 운영자는 대체 워크플로로 인해 영향받은 클러스터의 가용성 복원을 완료했습니다. 추가로, 10월 19일 오후 11시 47분부터 10월 20일 오전 1시 20분 사이에는, 모든 AWS 리전의 Amazon Redshift 고객이 IAM 사용자 자격 증명을 사용해 질의를 실행할 수 없었습니다. 이는 사용자 그룹 해석을 위해 N. Virginia(us-east-1) 리전의 IAM API를 사용하는 Redshift 결함 때문이었고, 해당 기간의 IAM 장애로 인해 Redshift가 이러한 질의를 실행하지 못했습니다. Redshift 클러스터에 “로컬” 사용자를 사용해 접속하는 고객은 영향을 받지 않았습니다.

Managed Workflows for Apache Airflow, Outposts 수명 주기 작업, AWS Support Center 등 DynamoDB, 신규 EC2 인스턴스 시작, Lambda 호출, Fargate 태스크 시작에 의존하는 기타 AWS 서비스도 N. Virginia(us-east-1) 리전에서 영향을 받았습니다.

이번 운영 이벤트를 계기로 여러 변경을 진행하고 있습니다. 전 세계에서 DynamoDB DNS Planner와 DNS Enactor 자동화를 이미 비활성화했습니다. 자동화를 재활성화하기 전에, 레이스 컨디션 시나리오를 수정하고 잘못된 DNS 플랜 적용을 방지하기 위한 추가 보호 장치를 도입하겠습니다. NLB의 경우, 헬스 체크 실패로 AZ 페일오버가 발생할 때 단일 NLB가 제거할 수 있는 용량을 제한하는 속도 제어 메커니즘을 추가합니다. EC2의 경우, 기존 규모 테스트를 보완하기 위해 DWFM 복구 워크플로를 실행해 향후 회귀를 식별하는 추가 테스트 스위트를 구축하고 있습니다. 또한 EC2 데이터 전파 시스템의 스로틀링 메커니즘을 개선하여, 대기 큐 크기에 기반해 유입 작업을 레이트 리밋함으로써 고부하 기간 동안 서비스를 보호하겠습니다. 마지막으로, 모든 AWS 서비스 전반에서 이번 이벤트의 세부 사항을 계속 검토하면서 유사 이벤트의 영향을 피할 수 있는 추가 방안을 모색하고, 복구 시간을 더욱 단축할 방법을 찾겠습니다.

마무리

이번 이벤트로 고객 여러분께 영향을 끼친 점 사과드립니다. 우리는 서비스 가용성을 최고 수준으로 운영해 온 강력한 실적을 보유하고 있지만, 우리의 서비스가 고객, 그들의 애플리케이션과 최종 사용자, 그리고 비즈니스에 얼마나 중요한지 잘 알고 있습니다. 이번 이벤트가 많은 고객에게 중대한 영향을 끼쳤다는 점을 인지하고 있습니다. 우리는 이번 이벤트로부터 모든 것을 학습하여, 가용성을 한층 더 개선하는 데 최선을 다하겠습니다.

Post-Event Summaries로 돌아가기