북부 버지니아(US-EAST-1) 지역의 Amazon DynamoDB 서비스 장애 요약

https://aws.amazon.com/message/101925/

2025년 10월 19일과 20일에 북부 버지니아(us-east-1) 지역에서 발생한 서비스 장애에 대한 추가 정보를 제공하고자 합니다. 이 이벤트는 10월 19일 오후 11:48 PDT에 시작되어 10월 20일 오후 2:20 PDT에 종료되었으며, 고객 애플리케이션에 영향을 미친 세 가지 뚜렷한 기간이 있었습니다. 첫째, 10월 19일 오후 11:48에서 10월 20일 오전 2:40까지 Amazon DynamoDB는 북부 버지니아(us-east-1) 지역에서 API 오류율이 증가했습니다. 둘째, 10월 20일 오전 5:30에서 오후 2:09까지 네트워크 로드 밸런서(NLB)는 북부 버지니아(us-east-1) 지역의 일부 로드 밸런서에서 연결 오류가 증가했습니다. 이는 NLB 플릿의 상태 확인 실패로 인해 일부 NLB에서 연결 오류가 증가한 결과였습니다. 셋째, 10월 20일 오전 2:25에서 오전 10:36까지 새로운 EC2 인스턴스 시작이 실패했으며, 오전 10:37부터 인스턴스 시작이 성공했지만, 일부 새로 시작된 인스턴스는 오후 1:50까지 연결 문제가 해결되었습니다.

#### DynamoDB

10월 19일 오후 11:48 PDT에서 10월 20일 오전 2:40 PDT까지, 고객은 북부 버지니아(us-east-1) 지역에서 Amazon DynamoDB API 오류율 증가를 경험했습니다. 이 기간 동안 고객 및 DynamoDB에 의존하는 다른 AWS 서비스는 서비스에 새로운 연결을 설정할 수 없었습니다. 이 사건은 서비스의 자동 DNS 관리 시스템 내의 잠재적 결함으로 인해 DynamoDB의 엔드포인트 해석 실패로 촉발되었습니다.

AWS의 많은 대규모 서비스는 원활한 확장, 장애 격리 및 복구, 낮은 지연 시간, 그리고 지역성을 제공하기 위해 DNS에 크게 의존합니다. DynamoDB와 같은 서비스는 각 지역에서 매우 큰 이종 로드 밸런서 플릿을 운영하기 위해 수십만 개의 DNS 레코드를 유지합니다. 이 DNS 레코드를 자주 업데이트하여 추가 용량을 추가하고, 하드웨어 장애를 올바르게 처리하며, 고객 경험을 최적화하기 위해 트래픽을 효율적으로 분산시키는 자동화가 중요합니다. 이 자동화는 다양한 운영 문제를 복구할 수 있도록 설계되었습니다. 공용 지역 엔드포인트를 제공하는 것 외에도, 이 자동화는 FIPS 준수 엔드포인트, IPv6 엔드포인트, 계정별 엔드포인트를 포함한 여러 동적 DynamoDB 변형에 대한 추가 DNS 엔드포인트를 유지합니다. 이 문제의 근본 원인은 DynamoDB DNS 관리 시스템 내의 잠재적 레이스 컨디션으로, 서비스의 지역 엔드포인트(dynamodb.us-east-1.amazonaws.com)에 대한 잘못된 빈 DNS 레코드를 생성하여 자동화가 이를 복구하지 못한 결과였습니다.

이 사건을 설명하기 위해 DynamoDB DNS 관리 아키텍처에 대한 몇 가지 세부 사항을 공유해야 합니다. 시스템은 가용성을 위해 두 개의 독립적인 구성 요소로 나뉩니다. 첫 번째 구성 요소인 DNS Planner는 로드 밸런서의 상태와 용량을 모니터링하고, 각 서비스 엔드포인트에 대한 새로운 DNS 계획을 주기적으로 생성합니다. 단일 지역 DNS 계획을 생성하여 용량 관리와 장애 완화를 단순화하며, 최근 출시된 IPv6 엔드포인트 및 공용 지역 엔드포인트와 같이 여러 엔드포인트 간에 용량이 공유되는 경우에 효과적입니다. 두 번째 구성 요소인 DNS Enactor는 최소한의 종속성을 가지도록 설계되어 어떤 시나리오에서도 시스템 복구가 가능하며, Amazon Route53 서비스에서 필요한 변경 사항을 적용하여 DNS 계획을 실행합니다. 복원력을 위해 DNS Enactor는 세 개의 서로 다른 가용 영역(AZ)에서 완전히 독립적으로 작동합니다. 각 독립적인 DNS Enactor 인스턴스는 새로운 계획을 찾아 Route53을 업데이트하여 현재 계획을 새로운 계획으로 교체하며, 여러 DNS Enactor가 동시에 업데이트를 시도하더라도 각 엔드포인트가 일관된 계획으로 업데이트되도록 보장합니다.

레이스 컨디션은 두 DNS Enactor 간의 드문 상호작용으로 발생했습니다. 정상적인 경우, DNS Enactor는 최신 계획을 가져와 서비스 엔드포인트를 통해 이 계획을 적용하기 시작합니다. 이 프로세스는 일반적으로 빠르게 완료되며 DNS 상태를 최신으로 유지하는 데 효과적입니다. 새로운 계획을 적용하기 전에 DNS Enactor는 계획이 이전에 적용된 계획보다 최신인지 한 번 확인합니다. DNS Enactor가 엔드포인트 목록을 처리하면서 다른 DNS Enactor가 동일한 엔드포인트를 업데이트하여 트랜잭션이 차단되면 지연이 발생할 수 있습니다. 이 경우 DNS Enactor는 모든 엔드포인트에 계획이 성공적으로 적용될 때까지 각 엔드포인트를 재시도합니다. 이 이벤트가 시작되기 직전에 한 DNS Enactor는 여러 DNS 엔드포인트에서 업데이트를 재시도해야 하는 비정상적으로 높은 지연을 경험했습니다. 이 과정에서 여러 가지 일이 동시에 일어났습니다. 첫째, DNS Planner는 계속 실행되어 여러 세대의 새로운 계획을 생성했습니다. 둘째, 다른 DNS Enactor가 최신 계획 중 하나를 적용하기 시작하여 모든 엔드포인트를 빠르게 진행했습니다. 이러한 이벤트의 타이밍이 잠재적 레이스 컨디션을 촉발했습니다.

두 번째 Enactor(최신 계획 적용)가 엔드포인트 업데이트를 완료한 후, 방금 적용한 계획보다 훨씬 오래된 계획을 식별하고 삭제하는 계획 정리 프로세스를 호출했습니다. 이 정리 프로세스가 호출된 동시에 첫 번째 Enactor(비정상적으로 지연된)는 훨씬 오래된 계획을 지역 DDB 엔드포인트에 적용하여 최신 계획을 덮어썼습니다. 계획 적용 프로세스 시작 시 수행된 확인(계획이 이전에 적용된 계획보다 최신인지 확인)은 Enactor 처리의 비정상적으로 높은 지연으로 인해 이 시점에서 오래된 상태였습니다. 따라서 오래된 계획이 최신 계획을 덮어쓰는 것을 막지 못했습니다. 두 번째 Enactor의 정리 프로세스는 방금 적용한 계획보다 여러 세대 오래된 이 계획을 삭제했습니다. 이 계획이 삭제되면서 지역 엔드포인트의 모든 IP 주소가 즉시 제거되었습니다. 또한, 활성 계획이 삭제되면서 시스템이 일관되지 않은 상태에 빠져 이후 계획 업데이트가 어떤 DNS Enactor에 의해서도 적용되지 못했습니다. 이 상황은 수동 운영자 개입이 필요했습니다.

이 문제가 11:48 PM PDT에 발생했을 때, 공용 엔드포인트를 통해 북부 버지니아(us-east-1) 지역의 DynamoDB 서비스에 연결하려는 모든 시스템은 즉시 DNS 실패를 경험하고 DynamoDB에 연결하지 못했습니다. 이는 고객 트래픽뿐만 아니라 DynamoDB에 의존하는 내부 AWS 서비스 트래픽도 포함했습니다. DynamoDB 글로벌 테이블을 사용하는 고객은 다른 지역의 복제 테이블에 성공적으로 연결하고 요청을 처리할 수 있었지만, 북부 버지니아(us-east-1) 지역의 복제 테이블과의 복제 지연이 길어졌습니다. 영향을 받은 AWS 서비스의 엔지니어링 팀은 즉시 참여하여 문제를 조사하기 시작했습니다. 10월 20일 오전 12:38까지 엔지니어들은 DynamoDB의 DNS 상태를 정전의 원인으로 확인했습니다. 오전 1:15까지 적용된 임시 완화 조치로 일부 내부 서비스가 DynamoDB에 연결되고 추가 복구를 차단 해제하는 주요 내부 도구가 복구되었습니다. 오전 2:25까지 모든 DNS 정보가 복원되었으며, 모든 글로벌 테이블 복제본은 오전 2:32까지 완전히 동기화되었습니다. 고객은 오전 2:25에서 2:40 사이에 캐시된 DNS 레코드가 만료됨에 따라 DynamoDB 엔드포인트를 해석하고 성공적으로 연결할 수 있었습니다. 이로써 주요 서비스 장애 이벤트로부터의 복구가 완료되었습니다.

#### Amazon EC2

10월 19일 오후 11:48 PDT에서 10월 20일 오후 1:50 PDT까지, 고객은 북부 버지니아(us-east-1) 지역에서 EC2 API 오류율 증가, 지연 시간, 및 인스턴스 시작 실패를 경험했습니다. 이벤트 시작 전에 시작된 기존 EC2 인스턴스는 건강 상태를 유지했으며 이벤트 기간 동안 영향을 받지 않았습니다. DynamoDB DNS 문제를 오전 2:25 PDT에 해결한 후에도 고객은 새 인스턴스 시작에 대해 오류가 증가하는 것을 계속 경험했습니다. 복구는 오후 12:01 PDT에 시작되어 오후 1:50 PDT에 EC2가 완전히 복구되었습니다. 이 기간 동안 새 인스턴스 시작은 "요청 제한 초과" 또는 "용량 부족" 오류로 실패했습니다.

무슨 일이 있었는지 이해하려면 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 PDT부터 이러한 DWFM 상태 확인이 DynamoDB에 의존하여 완료하지 못해 실패하기 시작했습니다. 이는 실행 중인 EC2 인스턴스에는 영향을 미치지 않았지만, droplet이 호스팅하는 EC2 인스턴스에 대한 추가 인스턴스 상태 변경이 발생하기 전에 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 시작 요청에 대해 "용량 부족 오류"를 반환했습니다. DWFM은 EC2 플릿 전체에서 droplet과 리스를 재설정하는 프로세스를 시작했지만, droplet 수가 많아 새로운 droplet 리스를 설정하는 작업이 시간이 초과되기 전에 완료되지 못했습니다. 추가 작업이 droplet 리스를 다시 시도하기 위해 대기열에 추가되었습니다. 이 시점에서 DWFM은 혼잡 붕괴 상태에 들어가 droplet 리스를 복구하는 데 진전을 이루지 못했습니다. 이 상황에는 확립된 운영 복구 절차가 없었기 때문에 엔지니어들은 DWFM 문제를 추가 문제 없이 해결하려고 주의 깊게 시도했습니다. 여러 완화 단계를 시도한 후, 오전 4:14에 엔지니어들은 들어오는 작업을 제한하고 DWFM 호스트를 선택적으로 재시작하여 이 상황에서 복구를 시작했습니다. DWFM 호스트를 재시작하면 DWFM 대기열이 정리되고, 처리 시간이 단축되어 droplet 리스를 설정할 수 있었습니다. 오전 5:28까지 DWFM은 북부 버지니아(us-east-1) 지역 내 모든 droplet과 리스를 설정했으며, 새 시작이 다시 성공하기 시작했지만, 전체 요청 부하를 줄이기 위해 도입된 요청 제한으로 인해 많은 요청이 여전히 "요청 제한 초과" 오류를 경험했습니다.

새 EC2 인스턴스가 시작될 때 Network Manager라는 시스템은 인스턴스가 동일한 Virtual Private Cloud(VPC) 내의 다른 인스턴스, 다른 VPC 네트워크 장비 및 인터넷과 통신할 수 있도록 네트워크 구성을 전파합니다. 오전 5:28 PDT, DWFM 복구 직후, Network Manager는 새로 시작된 인스턴스와 이벤트 중 종료된 인스턴스에 업데이트된 네트워크 구성을 전파하기 시작했습니다. DWFM 문제로 인해 이러한 네트워크 전파 이벤트가 지연되었기 때문에 북부 버지니아(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 인스턴스 시작이 정상적으로 작동했습니다.

#### 네트워크 로드 밸런서(NLB)

새로 시작된 EC2 인스턴스의 네트워크 상태 전파 지연은 네트워크 로드 밸런서(NLB) 서비스와 NLB를 사용하는 AWS 서비스에도 영향을 미쳤습니다. 10월 20일 오전 5:30에서 오후 2:09 PDT까지 일부 고객은 북부 버지니아(us-east-1) 지역의 NLB에서 연결 오류가 증가했습니다. NLB는 로드 밸런싱 엔드포인트를 제공하고 백엔드 타겟(일반적으로 EC2 인스턴스)으로 트래픽을 라우팅하는 고도로 확장 가능한 다중 테넌트 아키텍처를 기반으로 구축되었습니다. 이 아키텍처는 NLB 아키텍처 내 모든 노드에 대해 정기적으로 상태 확인을 실행하고 건강하지 않은 것으로 간주되는 노드를 서비스에서 제거하는 별도의 상태 확인 하위 시스템을 사용합니다.

이 이벤트 동안 NLB 상태 확인 하위 시스템은 상태 확인 실패가 증가하기 시작했습니다. 이는 상태 확인 하위 시스템이 네트워크 상태가 아직 완전히 전파되지 않은 새 EC2 인스턴스를 서비스에 투입하면서 발생했습니다. 이로 인해 기본 NLB 노드와 백엔드 타겟이 건강하더라도 상태 확인이 실패하는 경우가 있었습니다. 이로 인해 상태 확인이 성공과 실패를 번갈아 가며 발생하여 NLB 노드와 백엔드 타겟이 DNS에서 제거되었다가 다음 상태 확인이 성공하면 다시 서비스로 돌아왔습니다.

모니터링 시스템은 오전 6:52에 이를 감지했으며, 엔지니어들은 문제를 해결하기 위해 작업을 시작했습니다. 상태 확인 결과의 번갈아 가는 현상은 상태 확인 하위 시스템의 부하를 증가시켜 성능 저하를 일으켰고, 상태 확인 지연을 유발하여 자동 AZ DNS 페일오버가 발생했습니다. 다중 AZ 로드 밸런서의 경우, 이로 인해 용량이 서비스에서 제외되었습니다. 이 경우 남아 있는 건강한 용량이 애플리케이션 부하를 처리하기에 충분하지 않으면 애플리케이션에서 연결 오류가 증가했습니다. 오전 9:36에 엔지니어들은 NLB의 자동 상태 확인 페일오버를 비활성화하여 모든 사용 가능한 건강한 NLB 노드와 백엔드 타겟을 다시 서비스로 가져왔습니다. 이는 영향을 받은 로드 밸런서의 연결 오류 증가를 해결했습니다. EC2가 복구된 직후, 오후 2:09에 자동 DNS 상태 확인 페일오버를 다시 활성화했습니다.

#### 기타 AWS 서비스

10월 19일 오후 11:51 PDT에서 10월 20일 오후 2:15 PDT까지, 고객은 북부 버지니아(us-east-1) 지역에서 Lambda 함수에 대한 API 오류와 지연을 경험했습니다. 처음에는 DynamoDB 엔드포인트 문제로 인해 함수 생성 및 업데이트가 방지되고, SQS/Kinesis 이벤트 소스 처리 지연과 호출 오류가 발생했습니다. 오전 2:24까지 서비스 운영이 복구되었지만, SQS 큐 폴링을 담당하는 내부 하위 시스템이 실패하여 자동으로 복구되지 않아 SQS 큐 처리가 영향을 받았습니다. 오전 4:40에 이 하위 시스템을 복구하고 오전 6:00까지 모든 메시지 백로그를 처리했습니다. 오전 7:04부터 NLB 상태 확인 실패로 인해 인스턴스 종료가 발생하여 Lambda 내부 시스템의 일부가 축소되었습니다. EC2 시작이 여전히 손상된 상태에서, 우리는 지연에 민감한 동기 호출을 우선순위로 삼기 위해 Lambda 이벤트 소스 매핑과 비동기 호출을 제한했습니다. 오전 11:27까지 충분한 용량이 복구되어 오류가 줄어들었습니다. 이후 제한을 점진적으로 줄이고 모든 백로그를 오후 2:15까지 처리하여 정상적인 서비스 운영이 재개되었습니다.

10월 19일 오후 11:45 PDT에서 10월 20일 오후 2:20 PDT까지, 고객은 북부 버지니아(us-east-1) 지역에서 Amazon Elastic Container Service(ECS), Elastic Kubernetes Service(EKS), Fargate에서 컨테이너 시작 실패와 클러스터 스케일링 지연을 경험했습니다. 이러한 서비스는 오후 2:20에 복구되었습니다.

10월 19일 오후 11:56 PDT에서 10월 20일 오후 1:20 PDT까지, Amazon Connect 고객은 북부 버지니아(us-east-1) 지역에서 전화, 채팅, 케이스 처리에서 오류가 증가했습니다. DynamoDB 엔드포인트 복원 후 대부분의 Connect 기능이 복구되었지만, 고객은 오전 5:00까지 채팅에 대해 오류가 증가했습니다. 오전 7:04부터 고객은 Connect가 사용하는 NLB와 Lambda 함수 호출의 오류율 및 지연 시간 증가로 인해 새 전화, 채팅, 작업, 이메일, 케이스 처리에서 다시 오류가 증가했습니다. 인바운드 호출자는 통화 중 신호, 오류 메시지, 또는 연결 실패를 경험했습니다. 에이전트가 시작한 또는 API로 시작한 아웃바운드 호출이 실패했습니다. 응답된 호출은 프롬프트 재생 실패, 에이전트로의 라우팅 실패, 또는 무음 오디오를 경험했습니다. 또한, 에이전트는 연락 처리에서 오류가 증가했으며, 일부 에이전트는 로그인할 수 없었습니다. 고객은 API 및 Contact Search에 접근하는 데 오류가 증가했습니다. 실시간, 이력 대시보드 및 Data Lake 데이터 업데이트가 지연되었으며, 모든 데이터는 10월 28일까지 백필됩니다. Lambda 함수 호출 오류가 복구되면서 오후 1:20에 서비스 가용성이 복구되었습니다.

10월 19일 오후 11:51에서 오전 9:59 PDT까지, 고객은 북부 버지니아(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 PDT에서 10월 20일 오전 1:25 PDT까지, IAM 사용자를 사용하여 AWS Management Console에 로그인하려는 AWS 고객은 북부 버지니아(us-east-1) 지역의 기본 DynamoDB 문제로 인해 인증 실패가 증가했습니다. 북부 버지니아(us-east-1) 지역에 IAM Identity Center를 구성한 고객도 Identity Center를 사용하여 로그인할 수 없었습니다. 루트 자격 증명을 사용하는 고객 및 signin.aws.amazon.com을 사용하여 아이덴티티 페더레이션을 구성한 고객은 북부 버지니아(us-east-1) 지역 외의 지역에서 AWS Management Console에 로그인하려고 할 때 오류를 경험했습니다. DynamoDB 엔드포인트가 오전 1:25에 접근 가능해지면서 서비스가 정상 운영을 시작했습니다.

10월 19일 오후 11:47 PDT에서 10월 20일 오전 2:21 PDT까지, 고객은 북부 버지니아(us-east-1) 지역에서 Redshift 클러스터 생성 및 수정 또는 기존 클러스터에 대한 쿼리 발행 시 API 오류를 경험했습니다. Redshift 쿼리 처리는 클러스터에서 데이터를 읽고 쓰기 위해 DynamoDB 엔드포인트에 의존합니다. DynamoDB 엔드포인트가 복구되면서 Redshift 쿼리 작업이 재개되었으며, 오전 2:21까지 Redshift 고객은 클러스터를 성공적으로 쿼리하고 클러스터 구성을 생성 및 수정할 수 있었습니다. 그러나 DynamoDB 엔드포인트가 정상 운영으로 복원된 후에도 일부 Redshift 컴퓨팅 클러스터는 손상되어 쿼리에 사용할 수 없었습니다. 클러스터 노드의 자격 증명이 갱신되지 않고 만료되면서 Redshift 자동화는 기본 EC2 호스트를 새 인스턴스로 교체하는 워크플로우를 트리거했습니다. EC2 시작이 손상된 상태에서 이러한 워크플로우가 차단되어 클러스터가 쿼리 처리를 방해하는 "수정 중" 상태에 머물렀고 워크로드에 사용할 수 없게 되었습니다. 오전 6:45에 엔지니어들은 워크플로우 백로그가 증가하는 것을 막기 위해 조치를 취했으며, Redshift 클러스터가 오후 2:46에 교체 인스턴스를 시작하기 시작하면서 워크플로우 백로그가 소진되기 시작했습니다. 10월 21일 오전 4:05 PDT까지 AWS 운영자는 교체 워크플로우로 인해 손상된 클러스터의 가용성을 복원했습니다. 클러스터 가용성 손상 외에도, 10월 19일 오후 11:47에서 10월 20일 오전 1:20까지, 모든 AWS 지역의 Amazon Redshift 고객은 IAM 사용자 자격 증명을 사용하여 쿼리를 실행할 수 없었습니다. 이는 Redshift가 사용자 그룹을 확인하기 위해 북부 버지니아(us-east-1) 지역의 IAM API를 사용하는 결함 때문이었습니다. 이 기간 동안 IAM의 손상으로 인해 Redshift는 이러한 쿼리를 실행할 수 없었습니다. "로컬" 사용자를 사용하여 Redshift 클러스터에 연결하는 AWS 지역의 Redshift 고객은 영향을 받지 않았습니다.

10월 19일 오후 11:48 PDT에서 10월 20일 오전 2:40 PDT까지, 고객은 AWS Support Console 및 API를 통해 지원 케이스를 생성, 조회, 업데이트할 수 없었습니다. Support Center는 설계대로 다른 지역으로 성공적으로 페일오버했지만, 계정 메타데이터를 담당하는 하위 시스템이 합법적인 사용자가 AWS Support Center에 접근하지 못하도록 하는 응답을 제공하기 시작했습니다. Support Center는 응답이 성공적이지 않을 경우 이 시스템을 우회하도록 설계되었지만, 이 이벤트에서는 이 하위 시스템이 유효하지 않은 응답을 반환하여 시스템이 예기치 않게 합법적인 사용자의 지원 케이스 기능 접근을 차단했습니다. 이 문제는 오전 2:40에 완화되었으며, 오전 2:58에 재발 방지를 위한 추가 조치를 취했습니다.

DynamoDB, 새 EC2 인스턴스 시작, Lambda 호출, Fargate 작업 시작에 의존하는 Managed Workflows for Apache Airflow 및 Outposts 라이프사이클 작업과 같은 기타 AWS 서비스도 북부 버지니아(us-east-1) 지역에서 영향을 받았습니다. 영향을 받은 서비스의 전체 목록은 이벤트 기록을 참조하십시오.

이 운영 이벤트의 결과로 여러 가지 변경 사항을 적용하고 있습니다. 우리는 이미 전 세계적으로 DynamoDB DNS Planner와 DNS Enactor 자동화를 비활성화했습니다. 이 자동화를 다시 활성화하기 전에 레이스 컨디션 시나리오를 수정하고 잘못된 DNS 계획의 적용을 방지하기 위한 추가 보호 장치를 추가할 것입니다. NLB의 경우, 상태 확인 실패로 인해 AZ 페일오버가 발생할 때 단일 NLB가 제거할 수 있는 용량을 제한하는 속도 제어 메커니즘을 추가하고 있습니다. EC2의 경우, 기존 스케일 테스트를 보강하기 위해 DWFM 복구 워크플로우를 실행하여 향후 회귀를 식별하는 추가 테스트 스위트를 구축하고 있습니다. 높은 부하 기간 동안 서비스를 보호하기 위해 대기열 크기에 따라 들어오는 작업을 속도 제한하는 EC2 데이터 전파 시스템의 제한 메커니즘을 개선할 것입니다. 마지막으로, 모든 AWS 서비스에서 이 이벤트의 세부 사항을 계속 검토하면서 유사한 이벤트로 인한 영향을 피하고 복구 시간을 더욱 단축할 수 있는 추가 방법을 찾을 것입니다.

#### 마무리

이 이벤트로 인해 고객에게 미친 영향에 대해 사과드립니다. 우리는 서비스를 최고 수준의 가용성으로 운영하는 강력한 실적을 가지고 있지만, 우리의 서비스가 고객, 그들의 애플리케이션 및 최종 사용자, 그리고 그들의 비즈니스에 얼마나 중요한지 알고 있습니다. 이 이벤트가 많은 고객에게 상당한 영향을 미쳤다는 것을 알고 있습니다. 우리는 이 이벤트에서 배운 모든 것을 활용하여 가용성을 더욱 개선하기 위해 최선을 다할 것입니다.