要約

  • 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 のコントロールプレーン欠陥がパーティションリーダーの再選出を妨げ、2AZ 構成と 3AZ 構成の両方に影響した。障害は手数料計算と気配値の依存を通じて伝播した（Coinbase, 2026年5月7日）。

この文書は二つの安易な読み方を許さない。リージョン分離が破れた証拠にはならない。ゾーン障害、アプリ層の集中配置の選択、マネージドサービスの欠陥は、バージニア全体の停止と同じではない。同時に、責任をすべて顧客に押し付けることもできない。Coinbase は継続時間の一部をサービス欠陥に帰している。両方を同じ段落に書かねばならないが、取締役会に届くのは安心できる方だけになりがちだ。

出口はある。ただしオプションだ。

AWS はコントロールプレーン自身の復旧路も記録している。パブリックホストゾーン向けに us-west-2 経由の accelerated recovery があり、us-east-1 の劣化検知後およそ 60 分での復旧を目標とする。要点は制約の側にある。「Accelerated recovery is available only for public hosted zones.」障害前の有効化が前提で、プライベートホストゾーンは対象外、切り替え中に使える API 操作は一部に限られる（Enabling accelerated recovery for managed public hosted zones）。ホストゾーンの作成と削除は行えない。

ここに事業者の誠実さと限界が同時にある。出口は存在し、手順と有効化のタイミングが明示されている。だがそれは既定値ではない。誰かが障害前に契約し、設定した場合にだけ存在する。

第三者の読み方と、その限界。

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. にある。