요약

  • AWS는 IAM, Route 53, CloudFront의 제어 평면을 us-east-1에 두고, 그 지역이 열화된 동안에는 생성·수정·삭제·목록 작업에 의존하는 복구가 실패할 수 있다고 밝힌다.
  • 같은 열화 상태에서도 Route 53은 이름 해석과 상태 확인을 계속 수행한다. 미리 설정된 전환은 버티고, 장애 중 레코드를 고치는 전환은 버티지 못한다.

아무도 지역 때문에 클라우드를 사지 않는다. 사는 것은 한 부분이 망가져도 나머지는 계속 서비스된다는 약속이다. 그 약속은 상업적 추상이다. 그 아래에는 작업 목록이 있고, 각 작업은 특정 장소에 고정되어 있으며, 그 목록은 브로슈어가 인정하는 것보다 훨씬 자주 ‘버지니아’라고 적는다.

AWS는 그 목록을 공개한다. 장애 격리 경계 백서는 상용 파티션에서 IAM, Route 53, CloudFront의 제어 평면을 us-east-1에 둔다고 명시하면서 데이터 평면은 분산되어 있다고 덧붙인다. 문장은 분명하다. “These service operations have a cross-Region control plane dependency.” (AWS Fault Isolation Boundaries: global services)

이것은 신뢰성이 나쁘다는 고백이 아니라, 어떤 종류의 행동이 어디서 실행되는지에 대한 설명이다. 이사회에게 물음은 us-east-1이 믿을 만한가가 아니다. us-east-1의 나쁜 하루를 넘기는 계획이 us-east-1에서 실행되는 작업을 필요로 하는가이다.

상태 확인은 장애를 살아남는다. 절차서는 대개 그렇지 못한다.

같은 문서군은 DNS 전환의 두 절반을 유난히 또렷하게 나눈다. 이름 해석, 상태 확인의 실행, 그리고 상태 확인이 일으키는 라우팅 변경은 Route 53의 데이터 평면에 속한다. 반면 레코드 편집, 가중치 변경, 신규 레코드 생성은 “These approaches depend on the Route 53 control plane.” (Partitional services best practices)

즉 업계에서 가장 흔한 전환 설계는 구조적으로 제어 평면에 의존한다. 지역이 열화되면 CNAME을 고쳐 쓰는 절차서는 기능적으로 망가진 것으로 망가진 곳을 탈출하는 셈이다. 이미 설정된 상태 확인은 아무도 아무것도 편집하지 않은 채 트래픽을 옮긴다. 전자는 장애 중에 유효하고, 후자는 장애 이후에만 유효하다.

같은 문서는 두 번째 함정도 지적한다. 열화된 지역에서 CloudWatch 지표를 읽을 수 없으면 상태 확인이 마지막으로 알려진 상태에 머무를 수 있다. 전환을 일으켜야 할 경보 자체가 의존성이 되며, 운영자 자신의 권고는 관련 경보를 보호 대상 지역 밖에 두라는 것이다.

자격 증명은 제목보다 세부가 중요하다.

“AWS STS will process your request based on the originating Region and DNS resolver used.” 기본 활성화 지역에서 나와 Amazon DNS 서버로 해석된 요청은 현지에서 처리될 수 있다. 옵트인 지역에서 나온 요청이나 다른 DNS 사업자를 통해 해석된 요청은 계속 us-east-1에서 처리된다 (AWS STS Regions and endpoints). 전역 도메인 이름으로는 반대 결론을 끌어낼 수 없다. 엔드포인트 유형과 처리 지역을 기록한 CloudTrail 필드만이 판정한다.

전환을 실제로 무너뜨리는 것은 순환 의존이다.

2026년 9월 AWS 아키텍처 팀은 대부분의 장애 회고보다 유용한 사례를 냈다. Terraform Enterprise의 다지역 재해 복구를 시험하던 저자들은 주 지역 밖에서 도는 전환 스크립트가 여전히 그 지역 S3 상태 파일의 식별자를 필요로 한다는 것을 발견했다. S3 연결을 끊자 스크립트가 실패했다. 복구 경로가 복구 대상에 의존하고 있었던 것이다 (Validating multi-Region DR for Terraform Enterprise with AWS FIS).

그들의 수정은 한 줄로 요약된다. “Remove recovery dependencies on the Region you are recovering from.” 실행 시점의 상태 조회는 미리 설정된 DNS 장애조치로 교체되었고, 복구는 가장 필요한 순간에 피해 지역을 읽지 않게 되었다.

의존이 실제일 때 고객 회고는 이렇게 생겼다.

Coinbase가 공개한 2026년 5월 7일 장애 보고서는 이 추상을 구체로 바꾼다. 매칭 엔진 노드 다섯 중 셋이 같은 배치 그룹에 있었고, 가용 영역이 사라지자 정족수도 사라졌다. “There was no automated cross-zone failover.” 여기에 관리형 Kafka의 제어 평면 결함이 파티션 리더 재선출을 막아 2개 영역과 3개 영역 클러스터 모두에 영향을 주었고, 장애는 수수료 계산과 호가 의존성을 타고 번졌다 (Coinbase, 2026년 5월 7일).

이 문서는 두 가지 손쉬운 독법을 허용하지 않는다. 지역 격리가 무너졌다는 증거가 아니다. 가용 영역 사건, 애플리케이션 계층의 집중 배치 선택, 관리형 서비스 결함은 버지니아 전체의 정지와 같지 않다. 동시에 책임을 전부 고객에게 돌릴 수도 없다. Coinbase는 지속 시간의 일부를 서비스 결함에 돌린다. 두 사실은 같은 문단에 있어야 하지만, 이사회에 도착하는 것은 대개 안심시키는 쪽 하나뿐이다.

출구는 있다. 다만 옵션이다.

AWS는 제어 평면 자체의 복구 경로도 기록한다. 공개 호스티드 영역에 대해 us-west-2를 경유하는 가속 복구가 있고, us-east-1 열화 감지 후 약 60분을 목표로 한다. 핵심은 제약이다. “Accelerated recovery is available only for public hosted zones.” 장애 전에 켜 두어야 하고, 사설 호스티드 영역은 대상이 아니며, 전환 중 사용할 수 있는 API 작업은 일부에 그친다 (Enabling accelerated recovery for managed public hosted zones). 호스티드 영역 생성과 삭제는 여전히 불가능하다.

여기에 운영자의 정직함과 한계가 한 문단에 함께 있다. 출구는 존재하고, 절차와 활성화 시점도 명시되어 있다. 그러나 그것은 기본값이 아니다. 필요해지기 전에 계약하고 설정한 조직에만 존재한다.

제3자의 해석과 그 한계.

Control Plane은 아이덴티티, DNS, 모니터링, 복구 작업이 공통 의존을 남긴다고 주장하며 이렇게 쓴다. “It doesn’t cover failures in layers every region shares.” (Control Plane, 2026년 10월 12일). CloudForge는 복구 의존을 애플리케이션이 직접 호출하는 서비스보다 넓게 지도화해야 한다고 보고 이렇게 결론짓는다. “Recovery that needs new resources is the riskiest recovery.” (CloudForge, 2026년 10월 8일). 둘 다 아키텍처 해석이며 사업자 내부 관측이 아니다. CloudForge는 AI 지원 조사와 집필을 명시한다.

한계는 셋이다. 첫째, 이 조사는 2026년에 us-east-1이 다른 AWS 지역보다 신뢰성이 낮았다는 것을 노출로 정규화한 비교로 제시하지 못했다. 둘째, 게시 연도와 사고 연도는 다르다. 2026년 분석은 2025년 10월의 AWS 장애를 다루며, 그 사건에 대한 운영자 자체 기록은 이번 조사에서 열지 않았으므로 메커니즘도 지속 시간도 영향 범위도 여기서 단정하지 않는다. 셋째, 독립 출판은 독립적 운영 증거가 아니다. 컨설팅 해석, 공급자 주장, 고객 회고는 각자의 출처 표기를 유지한다.

관련 기업 기록은 Amazon.com, Inc.에 있다.