はじめに
2026 年 9 月、AWS は root ユーザーのコンソールサインインを us-east-1（バージニア北部）だけに依存しない構成へ変更しました。
これは、バージニア北部リージョンで障害が起きても、最後の管理アクセス手段である root サインインを失いにくくするアップデートです。
ただし、これはアプリケーションを自動復旧する機能ではありません。
対象となるのは root の「ログイン経路」です。
本記事では、2025 年 10 月の us-east-1 障害を踏まえ、この変更が何を改善し、IAM ユーザーゼロの設計にどうつながるかを整理します。
3 行で分かる結論
- root ユーザーのサインイン処理が
us-east-1(バージニア北部)、us-east-2(オハイオ)、us-west-2(オレゴン) に分散された。 -
us-east-1単独障害なら、AWS が別の対応リージョンへ自動的に振り分けるため、root でログインできる可能性が高くなる。 - IAM ユーザーゼロ化の目的は、日常アクセスから長期認証情報をなくすこと。
- 今回の変更は、非常時に残す root 経路の可用性を上げることで、その設計を支える。
何が変わったのか
AWS root ユーザーのサインインは、現在、次の 3 リージョンで処理されます。
| リージョン | リージョンコード |
|---|---|
| 米国東部（バージニア北部） | us-east-1 |
| 米国東部（オハイオ） | us-east-2 |
| 米国西部（オレゴン） | us-west-2 |
利用者がリージョンを選んだり、ログイン URL を変えたりする必要はありません。AWS が処理先を自動選択します。
対象はすべての AWS アカウントです。
AWS の発表では、この変更により us-east-1 への依存を減らし、サービス障害時の耐障害性を高めると説明されています。
バージニア北部の障害で何が助かるのか
2025 年 10 月 20 日の us-east-1 障害では、同リージョンの AWS サービスでエラー率とレイテンシーが上昇し、us-east-1 エンドポイントに依存する機能にも影響が広がりました。
AWS は DynamoDB のリージョナルエンドポイントにおける DNS 解決の問題を発端として説明しています。
(AWS のイベント概要)
今回の変更後、同じように us-east-1 が単独で不安定になっても、root サインインの処理先が us-east-2 または us-west-2 になれば、管理者はコンソールへ入れる可能性があります。
これは障害時に次のような操作を始めるための重要な土台です。
- 別リージョンの DR 環境の状態確認と切り替え
- アカウント設定、請求、組織設定などの確認
- 事前に準備した緊急復旧手順の実行
一方、root でログインできても、us-east-1 にだけある EC2、RDS、EKS、データ、DNS 依存関係が回復するわけではありません。
ログイン経路の DR と、ワークロードの DR は別物です。
| 障害対象 | 今回のアップデートで改善するか |
|---|---|
us-east-1 の root サインイン処理 |
改善する |
us-east-1 上のアプリケーションやデータ |
改善しない |
| 外部 IdP、社内ネットワーク、root MFA の障害 | 改善しない |
| IAM Identity Center のプライマリリージョン障害 | 直接は改善しない |
IAM ユーザーゼロとの関係
IAM ユーザーゼロとは、単に IAM ユーザーを削除することではありません。
人とシステムが使う長期パスワード・長期アクセスキーをなくし、必要なときだけ IAM ロールの一時認証情報を使う設計です。
人: IAM Identity Center / 外部 IdP → IAM ロール
AWS ワークロード: EC2・ECS・Lambda・EKS の IAM ロール
CI/CD・SaaS: OIDC federation → IAM ロール
この設計では、日常の管理に root も IAM ユーザーも使いません。
通常は IAM Identity Center、フェデレーション、短期間だけ有効なロールでアクセスします。
ただし、障害時には「Identity Center または外部 IdP が使えない場合、誰が AWS に入るのか」という問いが残ります。
ここで、厳格に保護した root ユーザーが最後の手段になります。
今回のアップデートは、root を常用する理由にはなりません。
むしろ、通常は IAM ユーザーを残さず、root は最終手段として安全に保管するという役割分担を現実的にします。
目指したい非常時アクセスの設計
- 通常時: IAM Identity Center と IAM ロールでアクセスする。
- リージョン障害時: IAM Identity Center のマルチリージョン複製、または事前作成した緊急ロールでアクセスする。
- 最終手段: root を使う。root は MFA、二人承認、利用記録、保管場所の分離を前提にする。
IAM Identity Center には、追加リージョンへ複製する機能があります。
事前に割り当てた権限は、プライマリリージョン障害時にも利用できます。
ただし、外部 IdP 自体の障害や、障害発生後の権限追加までは救えない場合があります。(IAM Identity Center の耐障害性)
監査と検知で必ず確認すること
今回の変更で、root の ConsoleLogin イベントは us-east-1、us-east-2、us-west-2 のいずれかに記録されます。(CloudTrail の公式仕様)
そのため、以下を確認してください。
- CloudTrail をマルチリージョン Trail として設定している。
-
userIdentity.type = RootかつeventName = ConsoleLoginを検知している。 - 成功・失敗の両方を通知対象にしている。
- EventBridge ルールは、3 リージョンそれぞれのイベントバスを対象にしている。
- SIEM や CloudWatch Logs で、3 リージョンのログを横断して確認できる。
特に注意したいのは EventBridge です。
CloudTrail をマルチリージョン化しても、CloudTrail イベントは各リージョンの EventBridge イベントバスに届きます。
中央リージョンにだけルールがあると、root ログインの通知を取りこぼす可能性があります。(CloudTrail のリージョン動作)
まとめ
今回の更新は、us-east-1 障害時にも root サインインを使える可能性を上げる、重要な管理プレーンの改善です。
ただし、これはアプリケーション DR の代わりではありません。
アプリケーションとデータは別リージョンへ複製し、通常アクセスは IAM Identity Center とロールに寄せ、root は最後の手段として保護・監査する。この三層で考えると、IAM ユーザーゼロと可用性を両立しやすくなります。
最後まで読んでいただきありがとうございました。