東京リージョンで使っていてもバージニア北部に依存しているもの

はじめに

2025年10月20日、us-east-1(バージニア北部)で大規模な障害が起きました。
東京リージョンでシステムを動かしている人にも影響が出ました。

一方で、AWS の設定には
「ロググループは us-east-1 に作ること」
のように、東京で使っていても us-east-1 を指定する箇所がいくつかあります。

この2つは別々の話に見えますが、原因は同じです。
この記事では、AWS の公式ドキュメントと障害の事後報告を読み、次の3点を整理します。

• 東京で使っていても us-east-1 に置く必要があるログと監視データ
• その理由になっている、コントロールプレーンとデータプレーンの分担
• us-east-1 で障害が起きたときに、東京近郊の利用者に何が起きるか

なお、今回は検証用の環境は作っていません。
内容はすべて、公式ドキュメントと AWS が公開した情報に基づいています。

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

AWS のサービスは、内部が2つの部分に分かれています。

• コントロールプレーン: リソースの作成・変更・削除・一覧表示を受け付ける管理機能
• データプレーン: 実際の処理を担う部分(DNS の応答、コンテンツの配信、認証情報の検証など)

ほとんどのサービスは、両方がリージョンごとに独立しています。
東京リージョンの EC2 であれば、管理機能も実際の処理も東京にあります。

一方、グローバルサービス(特定のリージョンに属さないサービス)は事情が違います。
AWS の公式ホワイトペーパー「AWS Fault Isolation Boundaries」によると、グローバルサービスの多くは、コントロールプレーンが1つのリージョンだけにあります。
データプレーンは、世界中に分散しています。

この分担と、us-east-1 で障害が起きたときの違いを、フロー図にまとめました。

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

ホワイトペーパーの表から、コントロールプレーンが us-east-1 にあるサービスを抜き出しました。
表の「エッジ」は、世界中に置かれた配信拠点(PoP)を指します。

同じ表で、次の3つはコントロールプレーンが us-west-2(オレゴン)にあると書かれています。

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

us-east-1 にしかないサービス

グローバルサービスとは別に、us-east-1 でしか提供されていないサービスもあります。

• 請求・コスト管理(Cost Explorer、Cost and Usage Reports、Data Exports など)
• AWS Billing Conductor
• AWS Marketplace の一部 API(Catalog API、Commerce Analytics、Entitlement Service)

東京で使っていても us-east-1 に置くログ

ログの置き場所が us-east-1 になるのは、そのサービスのコントロールプレーンが us-east-1 にあるためです。
公式ドキュメントで確認できたものを、サービスごとに並べます。

Route 53 のクエリログ

パブリックホストゾーンのクエリログを CloudWatch Logs に出す場合、次の2つを us-east-1 に作る必要があります。

• ロググループ
• Route 53 に書き込みを許可するリソースポリシー

API で設定するときに渡すロググループの ARN も、us-east-1 のものになります。

arn:aws:logs:us-east-1:111111111111:log-group:/aws/route53/example.com

コンソールから設定する場合は、Route 53 がこれらを自動で作ります。

CloudFront 用の AWS WAF のログ

AWS WAF のログの送り先は、Web ACL と同じリージョン、同じアカウントに作る決まりです。CloudFront 用の Web ACL は us-east-1 にあるため、送り先も us-east-1 になります。

• CloudWatch Logs に送る場合は、ロググループを us-east-1 に作る
• Data Firehose に送る場合は、配信ストリームを us-east-1 に作る
• どちらも、名前は aws-waf-logs- で始める

東京の ALB に付けた Web ACL であれば、送り先は東京でかまいません。

CloudFront の標準ログ(v2)

CloudFront の標準ログ(v2)は、CloudWatch Logs の配信の仕組みを使って届けられます。

• API で設定するときは、送り先が他のリージョンでも us-east-1 に対して呼び出す
• Data Firehose に送る場合、配信ストリームは us-east-1 に作る
• S3 に送る場合は、東京などのリージョンのバケットも使える

CloudWatch Logs に送る場合のロググループのリージョンは、CloudFront の公式ページに明記がなく、この記事では確認できていません。

CloudTrail のグローバルサービスイベント

2021年11月22日以降、IAM、AWS STS、CloudFront のイベントは us-east-1 で記録されるようになりました。

• 東京だけの単一リージョンの証跡では、これらのイベントを受け取れない
• 受け取るには、全リージョンを対象にした証跡にする
• 全リージョン対象の証跡なら、ログファイル自体は東京の S3 バケットに保存できる

CloudTrail コンソールのイベント履歴では、イベントが起きたリージョンに表示されます。IAM の操作を見るときは、リージョンを us-east-1 に切り替えます。

東京の単一リージョン証跡だけで IAM の操作を監査しているつもりでも、実際には記録が届いていないことになります。

請求額のメトリクス

ログではなくメトリクス(数値の監視データ)ですが、請求額のメトリクス(EstimatedCharges)も us-east-1 にだけ保存されます。
全世界の利用分をまとめた値なので、請求アラームは us-east-1 で作ります。

us-east-1 の障害で東京の利用者に起きること

ホワイトペーパーでは、コントロールプレーンのあるリージョンで障害が起きると、作成・変更・削除・一覧表示の操作ができなくなる可能性があると説明しています。
データプレーンは分散しているため、すでに動いているものは基本的に動き続けます。

基本的に動き続けるもの

• 東京リージョンで稼働中の EC2、Lambda、RDS など
• Route 53 の名前解決、CloudFront の配信
• 発行済みの認証情報による認証

できなくなる可能性があるもの

• IAM のユーザー・ロール・ポリシーの作成や変更
• Route 53 のレコード変更、CloudFront の設定変更
• AWS Organizations の操作

東京で呼び出しても us-east-1 に依存する操作

ホワイトペーパーには、リージョンを指定して呼び出す操作でも、内部で us-east-1 に依存するものが挙がっています。

• S3 のバケット作成・削除(バケット名が全世界で重複しないことを確認するため)
• S3 のバケットポリシー、ライフサイクル、レプリケーション、暗号化などの設定変更
• API Gateway のエッジ最適化エンドポイントの作成(CloudFront を使うため)

ELB や RDS のように、リソースを作るときに DNS レコードを登録するサービスも、Route 53 のコントロールプレーンに依存しています。
ホワイトペーパー(2026年10月時点)によると、このうち一部のサービスは、us-east-1 の障害時に使う内部の復旧用エンドポイントを持っています。

• 復旧用エンドポイントを使う: ELB、RDS、ElastiCache、CloudFront など
• 使わない: EKS、API Gateway、Lambda の関数 URL、OpenSearch Service など

ログと監視への影響

前の章で挙げたログや監視データは、送り先が us-east-1 にあります。
障害中の挙動までは公式ドキュメントで確認できていませんが、us-east-1 の障害の影響を受けうる構成です。

障害の調査に使いたいログが、障害の起きているリージョンにあるという点は、運用手順を考えるうえで押さえておく必要があります。

2025年10月の us-east-1 障害で起きたこと

AWS が公開した事後報告(Post-Event Summary)の内容です。

• 期間: 米国太平洋夏時間 2025年10月19日 23:48 〜 10月20日 14:20(日本時間 10月20日 15:48 〜 10月21日 6:20)
• 発端: DynamoDB の DNS を管理する仕組みに潜在的な競合状態(2つの処理がぶつかって不整合を起こす不具合)があり、dynamodb.us-east-1.amazonaws.com の DNS レコードが空になった
• 波及: DynamoDB に依存する EC2 の起動、NLB のヘルスチェック、Lambda、ECS/EKS/Fargate、STS などに影響が連鎖した

us-east-1 の外にも出た影響

事後報告には、us-east-1 以外のリージョンに出た影響も書かれています。

• コンソールのサインイン: ルートユーザーと、signin.aws.amazon.com を使うフェデレーションユーザーが、us-east-1 以外のリージョンでもサインインできなかった
• Redshift: IAM の認証情報を使ったクエリが全リージョンで失敗した(us-east-1 にある IAM の API を使う不具合のため)
• DynamoDB のグローバルテーブル: 他のリージョンのレプリカは使えたが、us-east-1 との間の複製が遅延した
• AWS Support Center: 別のリージョンへの切り替えは行われたが、一部の利用者がケースを作成できなかった

東京の利用者が影響を受ける経路

構造から整理すると、東京の利用者が us-east-1 の障害の影響を受ける経路は3つあります。

• 使っている Web サービスやアプリ自体が us-east-1 で動いている
• 自社システムは東京でも、依存している SaaS や外部 API が us-east-1 で動いている
• コンソールのサインインや IAM の API のように、グローバルな機能を通じて影響を受ける

東京で運用するときの備え

ホワイトペーパーが勧めている考え方は、静的安定性(依存先の管理機能が止まっても、何も変更せずに動き続けられる性質)です。
グローバルサービスのコントロールプレーンを、復旧の手順に組み込まないことが基本になります。

復旧の手順

• 障害時に IAM ロールを新しく作る、Route 53 のレコードを書き換える、といった手順を前提にしない
• フェイルオーバー(待機系への切り替え)は、Route 53 のヘルスチェックや ARC のルーティングコントロールのような、データプレーンの機能で行う
• 障害時に S3 バケットを作る手順がある場合は、決まった名前が使える前提にしない

なお、2025年12月から、Route 53 のパブリックホストゾーンのレコードは、us-west-2 にあるスタンバイ用のコントロールプレーンエンドポイントからも作成・更新・削除できるようになっています。

エンドポイントの選び方

• STS は、グローバルエンドポイント(sts.amazonaws.com)ではなく、東京のリージョナルエンドポイント(sts.ap-northeast-1.amazonaws.com)を使う
• コンソールは、前回使ったリージョンへ転送するグローバルの入口ではなく、リージョンを指定した URL から開く

ログと監視

• IAM の操作を監査するなら、CloudTrail は全リージョン対象の証跡にする
• us-east-1 に置いているログや請求アラームが、障害中に見られない・届かない可能性を、運用手順に入れておく

東京リージョンを選んでいても、IAM、Route 53、CloudFront を使っている時点で、us-east-1 との関係は残ります。
ログを us-east-1 に置く必要があることと、us-east-1 の障害が東京に届くことは、どちらもこの関係から来ています。

最後まで読んでいただきありがとうございました。

参考資料

ホワイトペーパーと障害報告です。

• AWS Fault Isolation Boundaries: Global services
• Summary of the Amazon DynamoDB Service Disruption in the Northern Virginia (US-EAST-1) Region

ログの設定に関するドキュメントです。

• Route 53 CreateQueryLoggingConfig
• AWS WAF: CloudWatch Logs へのログ送信
• AWS WAF: Amazon Data Firehose へのログ送信
• CloudFront 標準ログ(v2)の設定

記録と監視に関するドキュメントです。

• CloudTrail の概念(グローバルサービスイベント)
• CloudWatch で請求アラームを作成する