AWS障害に備えるために今日中にできる3つのこと
2025年10月20日、大規模なAWS障害がありました。 対応に当たった皆様、本当にお疲れ様でした（AWSの皆様も含め）。
本記事は今回の障害に対する直接の対策を解説するものではありません。 しかし、最低限どのようなAWS障害に対してもまずはやっておくと、簡単にできる割に効果が大きいものを3つ紹介します。
1. Healthイベントの通知
AWS側で障害が発生した場合、AWSは AWS Health Dashboard に障害情報を掲載します。 ここに掲載される情報（AWS Health Event）を普段使っているメールやSlackで受信できるように通知設定を入れておきましょう。
これにより、主体的にダッシュボードを見に行かなくても、AWS側で障害が発生していることを把握できます。 多くの場合、まずはアプリケーションレイヤーの監視で利用者は障害を検知すると想定されます（影響を受けた場合）。 Health Dashboardの掲載には障害発生から時差があるためです。
その後、AWS Health Eventの通知が届けば、アプリレイヤーの障害なのかAWSレイヤーの障害なのか切り分けの迅速化に役立ちます。 主体的にダッシュボードを見に行く必要があると、この切り分けに手間取る可能性があります。
設定方法はいくつかあります。 一番お手軽な方法は AWSマネージド通知サブスクリプション に通知先を登録する方法です。
詳細は以下の公式ドキュメントを確認してください。
AWSマネージド通知サブスクリプションは設定は簡単ですが、障害の詳細情報は通知に含まれません。
AWSは Personal Health Dashboard という自分のAWSアカウントに対する影響をパーソナライズして掲載する機能も提供しています。 自分のAWSアカウントの中で影響を受けているリソースのIDやリソースのステータスといった詳細情報を教えてくれます。
このような詳細情報までメールやSlackで通知を受けられるようにするには、EventBridgeで aws.health をソースとするイベントをフィルタして通知します。
EventBridgeによる詳細情報の通知方法は以下の公式ドキュメントを確認してみてください。
その他、AWS組織全体のAWS Healthイベントを集約する方法もあります。 詳しくは以下の公式ドキュメントに記載されています。
AWS Healthイベントの通知設定は少なくとも本番アカウントではすべからく有効化しておくことをおすすめします。
ただし、前述の通り、障害の発生から情報掲載までには時差があります。 通知の仕組みも障害の影響を受けて機能しない可能性があります。 AWS Healthイベントより前に、Xで他のAWSユーザの投稿からAWS障害を疑うケースも少なくありません。 「Healthイベントが出ていないからAWS障害では無い」と早とちりすることの無いようにお気をつけください。
2. 適切なAWSサポートレベルの選択と権限付与
AWS障害が疑われる場合、対象のAWSアカウントからサポートケースを起票することでAWSサポートに自分たちのリソースの調査を依頼できます。
ただし、AWSサポートにはサポートプランの選択肢があり、応答時間など対応レベルが異なります。 サポートプランごとの違いは以下にまとめられています。
サポートプランを上げる操作にも当然権限が必要です。 障害発生時に混乱しないように、予め自分たちのワークロードにふさわしいサポートプランを選択しておくことをおすすめします。
また、サポートチケットを起票する操作にも権限が必要です。 必要な開発者・運用者には権限を予め付与しておきましょう。
AWSサポート関連の権限は以下の公式ドキュメントをご参照ください。
IAMのコントロールプレーンで障害が発生した場合、IAMの設定変更ができない可能性があります。 サポートチケットの起票に必要な権限は予め付与しておきましょう。
障害の状況によっては、AWSサポートへのケース起票すらできない可能性もあります。 エンタープライズサポートを契約すると担当のAWS TAM（Technical Account Manager）がつくため、個別にAWS社とコミュニケーションを取れる可能性があります。 ミッションクリティカルなワークロードに対してはエンタープライズサポートの契約も検討対象になります。
3. Break-Glassアカウントの作成
AWS障害発生時に通常使っているアクセス経路が使えなくなる可能性があります。 そのための代替経路として一時的なアクセス経路を用意しておきましょう。
例えば、普段はAWS IAM Identity Center経由でAWSアカウントにアクセスしていたとします。 AWS IAM Identity Centerはリージョンサービスなので、特定のリージョンの障害でこの経路が使えなくなる可能性があります。
そのような場合を想定し、緊急アクセス用のIAMユーザを作成しておくなど代替経路を予め準備しておきましょう。 なお、代替経路が不正に使用されたり常用されたりしてしまうと、統制・セキュリティ観点で別のリスクが発生してしまいます。 パスワードとMFAを適切な承認者のみが管理して一時的に払い出し、当該ユーザによるログインは自動検知・通知するといった統制プロセスも合わせて整備しておきましょう。
Break-Glassアカウントの作成については、AWS Well-Architected Frameworkでも言及されています。
最後に
どのようなAWS障害に対しても、最低限これだけは備えておいた方が良いという3点をご紹介しました。 まだ対応されていない方はぜひ参考にしていただけますと幸いです。
この3点を既に対応されている方は素晴らしいと思います。 もちろんこの3点だけで十分ではありませんし、設定がすべてではなく運用の整備や訓練も重要です。
Dr. Werner VogelsもAWS re:Invent 2024にて以下のように述べています（筆者意訳）。
"Everything fails, all the time" ばかり引用されるけど "...so plan for failure and nothing will fail" が重要だよ
この3点で満足せず、日々、障害への備えをしていきましょう。
以上
