6
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@_miumiu
in

us-east-1 障害は ap-northeast-1 にどう波及するか

6
Last updated at Posted at 2026-05-11

はじめに

2025 年 10 月 20 日、us-east-1（バージニア北部）で大規模な障害が発生しました。発端は DNS 解決の失敗で、これに依存する EC2 / NLB / Lambda / STS など多数の AWS サービスへカスケードで影響が波及し、さらに IAM ユーザーや IAM Identity Center 経由でのサインインまで一時的に失敗する事態となりました。JST 10 月 20 日午後に始まり、翌朝にかけて影響が続く中で、X（旧 Twitter）のタイムラインは AWS の話題で埋め尽くされました。(個人的な観測範囲)

このとき、東京（ap-northeast-1）でワークロードを動かしている多くの運用者が「うちは大丈夫か？」と落ち着かなくなったと思います。私もその一人でした。

本記事のゴールは、こうした us-east-1 障害時に ap-northeast-1 へどのような影響が出るのかを、自分の言葉で説明できるようになる ことです。鍵となるのは次の 3 つの概念です。

  • コントロールプレーン（Control Plane）とデータプレーン（Data Plane） の違い
  • AWS Fault Isolation Boundaries が定義する Zonal / Regional / Global の階層構造と、Partition の概念
  • AWS Well-Architected Framework 信頼性の柱 の REL11-BP04 / REL11-BP05（コントロールプレーン非依存と静的安定性）

これらは独立したトピックに見えますが、すべては Design for failure で知られる概念に収束します。AWS CTO の Werner 先生が re:Invent 2012（2012/11/29、AWS 初の自社カンファレンス）の Day 2 Keynote "The next generation of application architectures in the cloud" で語った言葉 —

"Everything fails all the time"

「クラウド上のものは いつか必ず壊れる」。だからこそ「壊れる前提で設計する（Design for failure）」。そうすれば結果として、ユーザーから見ると 何も壊れない。本記事で扱う CP / DP の区別も、Fault Isolation Boundaries の階層理解も、REL11-BP04 / BP05 のベストプラクティスも、すべてはこの原則を 具体的な AWS の文脈 に落とし込んだものです。

JAWS DAYS 2026 でも同じテーマで登壇しましたが、本記事は時間の関係で触れなかった内容や、今回取り上げる技術的な要素の背景や設計判断の根拠の部分に踏み込み、文章として読み返せる形に再構成したものです。

登壇時に使用した、資料もあります。会場の様子も含めた登壇時の様子も運営スタッフが撮影、YouTubeにアーカイブしてくれていますので、そのこちらも合わせてご確認いただければと思います。以下に埋め込みで置いておきます。

↓SpeakerDeck

↓YouTube
（会場の観客含めての画角でアーカイブ残してくれているのが、イベントの様子まで含めて残っていて、最高です。ありがとうございます。）

補足や脱線で長文になってしまいましたが、ぜひお読みください。AIに食わせちゃうんでしょうけども。
以下、本編。

コントロールプレーンとデータプレーン

AWS の各サービスは、操作のレイヤーが大きく 2 つに分かれます。

コントロールプレーン（CP）
リソースの作成・変更・削除・管理を行う操作レイヤーです。いわゆる CRUDL 操作です。

  • CreateBucket / DeleteBucket
  • CreateRole / AttachRolePolicy
  • PutBucketPolicy / PutBucketVersioning
  • UpdateResourceRecordSet

データプレーン（DP）
実際のデータ処理・認証認可・トラフィック転送を行うレイヤーです。

  • S3 の GetObject / PutObject
  • IAM の認証（AuthN）・認可（AuthZ）の検証
  • Route 53 の DNS 名前解決
  • ELB のトラフィック転送

ここで重要なのは、コントロールプレーンの方が障害が起きやすい という事実です。CRUDL 操作はメタデータの整合性を取りながら処理する必要があり、複数の依存サービスを跨ぐため複雑になりがちです。一方データプレーンは「すでに作られた設定に従ってトラフィックを捌く」だけなので、各リージョン・各 AZ で独立して稼働でき、障害に強い構造になっています。

AWSの認定試験の勉強などをしていると、最初にコントロールプレーンとデータプレーンという言葉に触れるのは、コンテナサービスの学習をした時ではないでしょうか。コンテナサービスを思い浮かべると掴みやすいです。Amazon EKS / Amazon ECS は コントロールプレーン（タスク定義の管理、サービスの作成・変更、デプロイの調停）で、Amazon EC2 / AWS Fargate (ECS マネージドインスタンスという選択肢も増えましたね。)は データプレーン（実際にコンテナが動く実行環境）にあたります。コントロールプレーン側に障害が出ても、すでに起動して動いているコンテナは継続して処理を捌きます。止まるのは新規デプロイや設定変更だけです。

us-east-1 で障害が起きたときに「東京は無事か？」を判断する第一歩は、自分が触っているのが CP なのか DP なのか を意識することです。
(これはどこで障害が起きても共通する考え方なので、リージョン跨いでなくても同様です)

Fault Isolation Boundaries — Zonal / Regional / Global / Partition

AWS が公式に出している AWS Fault Isolation Boundaries ホワイトペーパーの "AWS service types" 章 では、サービスを コントロールプレーンの居場所 で分類します。

分類 Control Plane Data Plane 代表例
Zonal services リージョン AZ Amazon RDS、Amazon EC2、Amazon EBS
Regional services リージョン リージョン Amazon S3、Amazon SQS、DynamoDB（一部例外あり）
Global services パーティションに 1 つ Global AWS IAM、Amazon Route 53、Amazon CloudFront

そしてその上位概念として Partition があります。AWS のリージョン群は次のパーティションに分かれています。

Global services はパーティションごとに 1 つだけコントロールプレーンを持ちます。aws パーティションでは、その「1 つ」が us-east-1 に置かれています。これが「us-east-1 障害が世界中の AWS ユーザーに波及する」と言われる構造的な理由です。

us-east-1 にコントロールプレーンが存在するサービス

aws パーティションでコントロールプレーンが us-east-1 に存在するサービスを列挙します。

出典: AWS Fault Isolation Boundaries Whitepaper -
Global services / Appendix A - Partitional service guidance

サービス 役割
AWS IAM 認証・認可の管理。ロール / ポリシー作成は us-east-1 経由
AWS Organizations マルチアカウント管理（SCP・OU 構造）
AWS Account Management アカウント情報の管理操作
Route 53 Public DNS パブリック DNS のレコード作成・変更
Route 53 Private DNS VPC 内プライベート DNS の管理
Amazon CloudFront CDN 設定・ディストリビューション作成
AWS WAF for CloudFront CloudFront 向け WAF ルール管理
ACM for CloudFront CloudFront 用 SSL 証明書
AWS Shield Advanced DDoS 保護の管理

つまり、us-east-1 のコントロールプレーンが落ちると、東京リージョンを使っていても新規 IAM ロール作成・Route 53 レコード変更・CloudFront 設定変更などができなくなる ということです。

一部例外: us-west-2 がコントロールプレーンのサービス

ややこしいのは「Global だけど us-east-1 ではなく us-west-2 がコントロールプレーン」というグループです。

  • Route 53 Application Recovery Controller (ARC)
  • AWS Network Manager
  • AWS Global Accelerator

これらは us-east-1 のコントロールプレーンが落ちても管理操作を継続できます。

調べたところ、 Amazon Route 53 ARC は CP を us-west-2 に置き、データプレーンを 5つのリージョナルクラスター（quorum モデル）に分散させた構造を持ち、Route 53 自体の CP（us-east-1）が使えない状況下でも DNS フェイルオーバーを発火できる ように設計されているそうです。Route 53 と ARC を組み合わせた DR メカニズムの構築パターンは、AWS 公式ブログ Creating Disaster Recovery Mechanisms Using Amazon Route 53 が出発点として参考になります。

リージョナルサービスだけど us-east-1 に依存している操作

何事にも例外はつきもの。ちょっと特殊なパターンです。基本的にはリージョナルなサービスだが、特定のコントロールプレーン操作は us-east-1 に依存する というケースが存在します。

Amazon S3 — バケット名はパーティション内でグローバルユニーク

S3 はリージョナルサービスですが、以下の CP 操作は us-east-1 依存です。

  • CreateBucket / DeleteBucket
  • PutBucketPolicy / PutBucketVersioning
  • PutBucketReplication / PutBucketEncryption
  • PutBucketLifecycle / PutBucketCors
  • PutBucketNotification / PutBucketLogging / PutBucketTagging
  • PutBucketObjectLockConfiguration

理由は、バケット名がパーティション内でグローバルユニークである必要があり、名前空間の整合性管理が us-east-1 の CP に集約されているため、バケットそのものに関しての操作に関しては別の扱いとなっています。データプレーンの GetObject / PutObject は東京リージョンで完結する ので、既存バケットへの読み書きは問題なく継続できます。

DynamoDB Global Tables と Regional endpoint の DNS 管理

これまた一部例外が含まれているのがDynamoDB。 通常テーブルは完全にリージョナルですが、Global Tables のコントロールプレーンは us-east-1 依存 です。

  • 新規 Global Table の作成・削除
  • レプリカリージョンの追加・削除
  • スループット設定変更
  • DynamoDB Streams の設定変更

加えて、DynamoDB の Regional endpoint（例: dynamodb.us-east-1.amazonaws.com）の DNS 登録は、以下のドキュメントによると、DNS Planner（plan 生成）と DNS Enactor（Route 53 への適用）という AWS 内部システムで管理されています。これは Global Tables 専用ではなく、DynamoDB エンドポイント全般に対する管理レイヤーです。2025/10/20 障害は、まさにこの DNS Enactor の race condition によって dynamodb.us-east-1.amazonaws.com の IP が Route 53 から すべて削除されたこと が起点でした（AWS が公開している障害事後報告 Post-Event Summary (PES) — Summary of the Amazon DynamoDB Service Disruption。）

「Global サービスではないのに CP が us-east-1 に依存」するサービス群

これは例外というか依存関係ですね。
Route 53 Public / Private DNS のコントロールプレーンが us-east-1 にあるため、外部公開 URL を Route 53 で管理しているサービスは新規登録系で影響を受けます。

  • Amazon API Gateway (REST / HTTP)
  • Amazon ELB / ALB / NLB（作成時）
  • AWS PrivateLink VPC エンドポイント
  • AWS Lambda Function URLs
  • Amazon ElastiCache
  • Amazon OpenSearch Service
  • Amazon CloudFront（CP 経由）
  • Amazon MemoryDB / Neptune
  • Amazon DAX
  • Amazon ECS（DNS-based Service Discovery）
  • Amazon EKS Kubernetes コントロールプレーン

ポイントは「既存リソースのデータプレーン処理（実際のトラフィック転送）は無事」「新規作成や設定変更ができなくなる」というところです。

AWS Well-Architected Framework 信頼性の柱

ここまでの整理を踏まえて、どう設計すべきか。AWS Well-Architected Framework 信頼性の柱には、まさにこの問題への 2 つのベストプラクティスが書かれています。

REL11-BP04: 復旧時はコントロールプレーンではなくデータプレーンを利用する

CP は CRUDL 操作。障害時に CP を呼ぶと可用性がさらに低下する。復旧手順から CP 操作を排除する。

実装例:

  • Route 53 DP のヘルスチェック自動フェイルオーバーで手動変更を不要に
  • 事前プロビジョニング済み EC2 / ALB を用意し、CreateInstance / CreateLoadBalancer を不要にする
  • break-glass ユーザーを平時に作成・保管し、障害時の CreateRole を不要にする

手順書の各ステップに CP 操作が含まれていないかをレビューする のがチェックポイントです。

REL11-BP05: 静的安定性 (Static Stability) を使ってバイモーダル動作を防ぐ

バイモーダル動作（bimodal behavior） とは、平常時と障害時で振る舞いが変わる設計を指します。たとえば「AZ 障害が起きたら別 AZ に新しいインスタンスを起動する」という設計は、障害時にだけ RunInstances という CP 操作を実行することになり、まさにバイモーダルです。

静的安定性 は「平時から全 AZ に必要数を稼働させ、ELB / Route 53 で自動切替させる」設計です。障害時に何も新しい操作をしない。これが statically stable な状態です。AZ 数を増やせば必要スペアキャパシティの比率は減っていくので、可用性とコストはトレードオフとして調整できます。

REL11-BP04 と組み合わせると、「障害時に いつもと違う動き をしない設計」が実現できます。

【補足】2025/10/20 障害における DNS Planner / DNS Enactor — CP / DP 整理

ここで、先ほども紹介した障害のPESについて深掘りしてみましょう。他にもいろいろ書いてあるので、AWSの内部が気になる方はぜひ。後述しますが、AWSユーザーとしても参考になる話が出てきます。

３つの単語を理解すると、公式 PES でのDynamoDB周りの障害について何が起きたのか解像度が上がります。

  • DNS Planner: DynamoDB のロードバランサー健全性・キャパシティを監視し、各エンドポイントの DNS plan を定期生成する社内システム
  • DNS Enactor: 生成された plan を Route 53 に適用 する（= Route 53 への CP 操作）。3 AZ で冗長動作し、自身の依存を最小限にするよう設計されている
  • race condition（競合状態）: 複数のプロセスやスレッドが共有リソースに並行アクセスするとき、実行タイミングの違いによって意図しない最終状態が生じる現象。今回は複数の DNS Enactor が同時に動く構造の中で、一方が遅延しているうちにもう一方が古い plan の clean-up を始めるタイミングが噛み合い、Route 53 上のレコードが「IP なしの空状態」で残ってしまった

複数の DNS Enactor が並行動作する構造で race condition が発生し、遅延していた Enactor が古い世代の plan で endpoint を上書き、続いて別 Enactor の clean-up process がそれを削除したことで、dynamodb.us-east-1.amazonaws.com の DNS レコードが空（IP なし） という状態が Route 53 に残されました。PES の表現を借りれば、

"customers and other AWS services with dependencies on DynamoDB were unable to establish new connections to the service"

つまり、DynamoDB の DP（GetItem / PutItem 等）自体は稼働していたものの、DNS 解決で IP が返らないため新規接続を確立できなかった という間接障害です。

CP / DP の観点で整理すると:

  • 故障原因は CP 側にある — DNS Enactor の race condition により、Route 53 への CP 操作が 誤った最終状態（空レコード）を残したまま完了 してしまった
  • DP 側に壊れた箇所はない — Route 53 の DNS 応答（DP）は CP 操作の結果（空レコード）を忠実に返したに過ぎず、DynamoDB の DP（GetItem 等）もそれ自体は稼働していた

つまり「CP 側の自動化が race condition で誤った最終状態を作り、それを DP が忠実に反映した結果、新規接続経路が失われた」というのが正確な構図です。

ここで CP / DP の本質的な違いに目を向けると、CP 操作は共有状態への書き込みを伴うため、並行実行時の順序問題（race condition）に構造的に弱い 一方、DP 操作は既存の状態を独立に消費するだけなので、並行性の問題が起きにくい という非対称性が見えてきます。本記事冒頭で触れた「CP のほうが障害が起きやすい」という性質は、まさにこの 並行性に起因する脆さ に支えられているわけです。

ここから REL11-BP04 / BP05 の意味が読み取れます。CP に頼った復旧手順は、AWS 側ですら race condition のような並行性問題で壊れることがある以上、「障害が起きてから新しい CP 操作を実行する」設計は構造的に脆い。代わりに、平時のうちに CP で必要な状態を作っておき、障害時はその状態を DP で動かす（= 静的安定性）。これが REL11 が言っていることの実体です。今回の障害は、AWS 自身もこの脆さから完全には逃れられないことを示した実例として、REL11 の重みを具体的に見せてくれています。

AWSさんの例を詳細に調べてみたところで、話を戻します。障害発生を見越して、どんな形で構えておけばいいのか、という話に戻りましょう。

障害訓練（Game Day）で検証する

これらの設計が机上の空論で終わっていないかは、Game Day や障害訓練の場で検証 できます。本番の us-east-1 障害が来てから慌てるのではなく、平時に「もし us-east-1 が落ちたら自分たちの復旧 Runbook のどのステップが止まるか」をシミュレートしてみてください。UpdateResourceRecordSet / CreateRole / UpdateDistribution などの CP コールが手順書に紛れていれば、訓練の段階で炙り出せます。バイモーダル動作を見つけたら、平時準備に書き換えるチャンスです。

ケーススタディ

DR フェイルオーバー

バイモーダル（NG パターン） 静的安定（推奨）
ユーザーが UpdateResourceRecordSet で Route 53 レコードを書き換える（CP 操作） Route 53 のヘルスチェックと Failover routing policy を平時に設定しておき、障害発生時は 何も操作せずに自動フェイルオーバー させる（DP のみ）

レコードを変更する操作はコントロールプレーンですが、ヘルスチェックとフェイルオーバールーティングはデータプレーンです。特別な操作をしない ことがバイモーダル回避になります。

オリジン障害対応（CloudFront）

バイモーダル（NG パターン） 静的安定（推奨）
UpdateDistribution でオリジンを書き換える、または CreateBucket で代替バケットを作成（いずれも CP） CloudFront の Origin Group に Primary / Failover Origin を平時に設定。オリジン障害時は CloudFront が自動的にフェイルオーバー（DP）

オリジンの書き換えや追加はコントロールプレーンですが、設定済みの Origin Group のフェイルオーバーはデータプレーンです。

【ちょっと脱線】IAM Identity Center (旧 AWS SSO) の us-east-1 集中問題と Break-glass User

ここまでの話は「設計でバイモーダル動作を防ぐ」という、運用で対処できる話でした。一方で、運用設計ではどうにもならない構造的依存 が存在していました。代表例が AWS の認証基盤 — IAM Identity Center（旧 AWS SSO）です。SNSでは、この話と us-east-1 の障害の話がごっちゃになっている人が散見されたので、違う視点の話ではあるんですが、触れておきたいです。後述する Break-glass User は関連する話ではありますが、、（JAWS DAYSで用意していたけど、がっつり削除した部分はこの部分）

そもそも、IAM ユーザーや恒久的なアクセスキーではなく IAM Identity Center で temporary credentials を使うこと は、AWS Security Maturity Model v2 で Quickwins レベルの Identity Federation として、また Foundational レベルの Use Temporary Credentials として明確に推奨されています。「IAM ユーザーや access key の利用は避けるべき」という業界推奨に従うほど、組織のアクセス基盤は IdC に集約されていきます。

裏返すと、その IdC が止まると 代替ログイン経路がほとんどない ということでもあります。だからこそ、コラムの後半で触れる Break-glass User（緊急時のみ使う別系統の認証経路）の準備が、平時のうちに必要になります。

歴史的背景: 単一リージョン構成だった IdC

AWS SSO（後の IAM Identity Center）は長らく シングルリージョン構成のサービス でした。組織が IdC を有効化した最初のリージョンが "ホームリージョン" となり、他リージョンには複製されません。

日本でも、us-east-1 をホームリージョンとしている組織が多い背景には、サービスの提供リージョンが段階的に拡大してきた歴史 があります。

つまり 2017 年 12 月から 2020 年 8 月までの約 2 年 9 ヶ月間、東京リージョンをホームリージョンとして選択することはできませんでした。この時期に IdC を導入した東京拠点の組織は、選択肢として us-east-1（または当時利用可能だった他リージョン）を選ばざるを得ませんでした。IdC のホームリージョン変更は事実上できない（インスタンスを一度削除して再作成する必要がある）ため、現在も us-east-1 をホームリージョンとして運用している東京拠点の組織が多く存在します。

結果として、「IdC の停止 = AWS への運用者アクセスが止まる」というシナリオが us-east-1 障害時に世界中の運用者に重くのしかかる構造になっていました。これは マネジメントコンソールに限らず、CLI / SDK 経由の SSO ログイン（aws sso login）も含めて新規セッションが止まります。

つまり us-east-1 障害が起きると:

  • マネジメントコンソール: SSO ポータルからのログイン不可
  • CLI / SDK: aws sso login での新規セッション取得不可。ただし、すでに発行済みの短期クレデンシャル（通常 1〜12 時間有効）が残っていれば、その期間内は操作継続可能
  • IDE プラグイン / その他ツール: SSO ベースの認証はすべて影響を受ける

東京リージョンしか使っていない組織でも、運用者が AWS にアクセスできない という形で間接的に影響を受けるわけです。アプリケーションのデータプレーンは無事でも、それを操作する手段が断たれます。

2025/10/20 障害で起きたこと

実際、2025 年 10 月 20 日の us-east-1 障害では、X（旧 Twitter）の AWS 関連タイムラインに「AWS コンソールに入れない」「SSO で認証が通らない」「普段使っているのは東京なのに、ログインできないから手が出せない」といった声が相次ぎました。DynamoDB の DNS 競合状態を起点に、IAM 認証を含む複数のグローバルサービスに波及し、Snapchat / Fortnite / Duolingo / Signal / Ring など世界中のアプリケーションが影響を受けたことが報じられています。インシデント対応をしようにも、コンソールに入れなければ何もできません。

これは 「静的安定性」とは別の問題 です。バイモーダル動作の有無にかかわらず、認証基盤そのものが落ちている。アプリケーションの設計でカバーできる範囲を超えています。

AWS の応答: IAM Identity Center Multi-Region Replication GA（2026/02）

この構造問題に対する AWS 側の応答かの様に発表されたのが、2026 年 2 月 3 日に GA となった IAM Identity Center Multi-Region Replication です。プライマリリージョン以外の追加リージョンにアイデンティティと権限情報を自動レプリケートし、プライマリリージョンの障害時にも別リージョン経由で AWS アカウントへのアクセスを継続できる ようになりました。商用 17 リージョンで利用可能、外部 IdP（Okta など）に接続している Organization インスタンスが対象です。

us-east-1 をホームリージョンにしている組織は、ap-northeast-1 等を追加リージョンとして設定しておく価値が大いにあります。

Break-glass User: 認証基盤に依存しない緊急アクセス

ただし、IdC Multi-Region Replication があっても、「IdC そのものが何らかの理由で使えない」 シナリオは残ります。外部 IdP（Okta、Entra ID 等）側の障害、レプリケーション設定不備、Organization 単位の権限設定変更ミスなど。

そこで重要なのが Break-glass User パターンです。

  • 平時に 緊急用の IAM ユーザー（多要素認証必須）を作成し、認証情報を物理金庫 / Password Manager の特権ボールトに厳重保管
  • 障害時にのみ 取り出して使う。使用ログを記録し、使用後は認証情報をローテーション
  • IdC が落ちていても、AWS のルート認証系（IAM）が動いていれば緊急対応が可能

Break-glass は 某勇者がファイナルフュージョン承認された時に、ガラスごとパリンってボタン押すアレです。

AWS 公式の参考実装として awslabs/aws-break-glass-role、aws-samples/aws-cross-account-break-glass-example が公開されています。

これは前述の REL11-BP04（復旧時に CP に依存しない）と地続き の話です。「障害発生後に CreateRole する」のではなく「平時に作成・保管しておく」ことで、コントロールプレーンに依存しない緊急アクセスを実現します。break-glass user の準備は、認証基盤の単一リージョン依存に対する アプリケーション開発者側でできる数少ない手当て であり、IdC Multi-Region Replication と組み合わせて二段構えにしておくのが堅実です。

このコラムの位置付け

Fault Isolation Boundaries の Whitepaper だけ読んでいると、IdC は「Identity 系の Global サービス」として他のサービスと一括りにされがちです。しかし 運用者ログインの導線 という観点で見ると、影響の質が違います。本記事で整理した「影響範囲のマップ」に、「IdC ホームリージョン依存」というレイヤー が乗ることを意識してください。

IAM Identity Center を使用している方が多いと思いますが、今一度リージョン周りどうなっているのか、障害発生時どうするのか、点検してみてはいかがでしょうか。

いろいろと話があっちゃこっちゃしてしまいましたが、無理やりJAWS DAYSの登壇と同じ流れにして、締めようと思います。

セルフチェック: 200 字で説明できますか？

これは JAWS DAYS 2026 の登壇でも実際に会場に投げかけた問いと同じものです。

問: us-east-1 での障害発生時、ap-northeast-1 でどのような影響が考えられますか？ 200 字以内で説明しなさい。

ヒント: 「データプレーン」と「コントロールプレーン」

一回、生成 AI に聞かずに考えてみてください。ここまでの内容を踏まえて、たまには時間をかけて書き出してみましょう。

模範解答（クリックで展開）

us-east-1 での障害時、ap-northeast-1 のデータプレーンは通常稼働しますが、コントロールプレーンに影響が出ます。IAM や Route 53 などグローバルサービスのコントロールプレーンが us-east-1 依存のため、ap-northeast-1 でもリソース作成や設定変更が不可能になります。ただし既存の EC2 や Lambda などデータプレーン処理は正常動作し、実行中アプリケーションへの直接影響は限定的です。

これを自分の言葉で書けたなら、本記事のゴールは達成です。書けなかった部分があれば、その箇所のセクションに戻って読み直してみてください。

まとめ — 影響範囲の "地図" は AWS が決め、"実害" は自分が決める

タイトルの問いに立ち返ります。us-east-1 障害が ap-northeast-1 にどう波及するか。本記事で整理した内容を 3 段でまとめます。

1. 技術的構造としての答え: 影響は限定的

us-east-1 で障害が発生しても、ap-northeast-1 のデータプレーン（実際のトラフィック処理）は通常稼働します。影響を受けるのは:

  • コントロールプレーンが us-east-1 に集中するグローバルサービス: 新規 IAM ロール作成、Route 53 レコード変更、CloudFront 設定変更など
  • リージョナルサービスのうち us-east-1 依存の CP 操作: S3 バケット作成、DynamoDB Global Tables 管理、Route 53 に依存する新規リソース作成（API Gateway / ELB / Lambda URLs 等）

裏返すと、既存リソースの DP 処理は無事。Fault Isolation Boundaries のマップを読めば、どこまで波及するかは事前に設計図に書けます。

2. ただし「限定的」で済むかどうかは、自分の設計次第

「影響は限定的」と言い切れるのは、あなたのワークロードが Well-Architected REL11 を守っている前提があってこそ です。

  • 復旧 Runbook に UpdateResourceRecordSet や CreateRole などの CP 操作が紛れていれば、その操作自体が us-east-1 障害下で失敗する。部分的な障害で済んだはずの状況に、自分の手でトドメを刺すことになる
  • DR フェイルオーバーで Route 53 レコードを書き換える運用にしていれば、その操作自体が us-east-1 障害時に失敗する
  • 平時に静的安定な構成を組んでいなければ、障害時に「新しい動き」をしようとして二次障害を起こす

REL11-BP04（復旧時に CP に依存しない）と REL11-BP05（静的安定性でバイモーダル動作を防ぐ）は、まさにこの「実害」を自分の側でゼロに近づけるためのベストプラクティスです。

影響範囲の "地図" は AWS が決め、影響の "実害" は自分の運用設計が決める。 これが本記事のキーメッセージです。

3. 設計でカバーできない構造的依存には、別軸の備えを

一方、コラムで触れた IAM Identity Center（旧 AWS SSO）の us-east-1 集中問題 のように、アプリ設計ではどうにもならない構造的依存も存在します。これには:

  • AWS 側の進化に乗る: 2026/02 GA の IdC Multi-Region Replication で追加リージョンに複製する
  • 自分側の手当てをする: break-glass user を平時に準備し、IdC が落ちても緊急アクセス経路を確保する

の二段構えで備えるのが堅実です。これも「平時に準備して障害時の CP 操作を不要にする」という意味で REL11-BP04 と地続きです。

4. 結局のところ — "Everything fails all the time"

冒頭で触れた Werner 先生の "Everything fails all the time" に立ち戻ります。全てのものは必ず壊れる。だから壊れる前提で設計する（Design for failure）。本記事で見てきた具体策は、すべてこの原則の派生です。

  • CP / DP の区別 → CP は並行性問題に弱く壊れやすい、DP は強い。復旧経路は DP 側に寄せる
  • Fault Isolation Boundaries → AWS 側が「どこまで共倒れになるか」の境界を引いている。その境界を知った上で影響範囲を見積もる
  • REL11-BP04 / BP05 → 復旧手順から CP 操作を排除し、平時に準備した DP の状態で動かす（静的安定性）
  • Break-glass User / IdC Multi-Region → アプリ設計でカバーできない領域には、別軸の備え（緊急アクセス経路・複製）を平時に用意する

「障害が起きないように設計する」のではなく、「障害が起きても影響を最小化できる設計」をする。これが Werner 先生の原則の本質であり、AWS が 2012 年以降一貫して伝えてきたメッセージです。2025/10/20 のような大規模障害が起きても、ap-northeast-1 で運用するアーキテクトが「うちは想定通りに静的安定で動いた」と言える状態 — それが、この原則の実利です。

us-east-1 で何かが起きたとき、自分のシステムが受ける影響範囲を自分の言葉で説明できる こと、そして 「いつもと違う動きをしない」 設計が習慣として組み込まれていることが、ap-northeast-1 で運用するアーキテクトの最低限の装備だと思います。本記事がその助けになれば幸いです。

参考資料

上位概念

  • Werner Vogels — re:Invent 2012 Day 2 Keynote "The next generation of application architectures in the cloud"（"Everything fails all the time" を語った keynote。本記事で扱う Design for failure の原型）: https://www.youtube.com/watch?v=PW1lhU8n5So

Fault Isolation Boundaries / Well-Architected

IAM Identity Center / Break-glass（コラム）

2025/10/20 us-east-1 障害（公式 PES と第三者報道）

なお、本記事と同じテーマで JAWS DAYS 2026（Track D）に登壇しました。スライドと録画は以下から。

6
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
6
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?