※このサイトはTOKAIコミュニケーションズをスポンサーとして、Zenken株式会社が運営しています。
「今朝からシステムが遅い」「ログインできない」「監視のアラートが止まらない」。AWSを使っていると、原因が自社側なのか、AWS側のイベントなのか、切り分けに迷う瞬間があります。焦って手当たり次第に触るほど、復旧が長引くこともあるので、まずは見る場所と順番を決めておくのが近道です。この記事ではAWS障害の情報収集から、設計・運用での対策までを解説します。
AWSは冗長化された基盤を前提に設計されていますが、「障害が起きない」わけではありません。大事なのは、障害の有無そのものよりも、起きたときに業務影響を小さくできるか、復旧を速められるかです。たとえばリージョン内の一部サービスに影響が出るケースもあれば、ネットワーク経路やDNSまわりの要素が絡んで広く影響が見えるケースもあります。
ここで押さえておきたいのは、AWS側が事後に公開するPost-Event Summaryのような公式レポートがあり、どういう影響が出て、どう改善したかを追える点です。過去の事例を読んでおくと、「次に同じことが起きたら自社はどこが詰まるか」を具体的に想像できるようになります。
参照元：AWS公式HP（https://aws.amazon.com/jp/premiumsupport/technology/pes/）
AWS障害の学びは、サービス名を暗記するより、「どの層が止まると何が起きるか」を理解する方が役立ちます。たとえばコンピュートとストレージに影響が出ると、インスタンス自体は動いていてもディスクI/Oが詰まり、APIのタイムアウトやアプリの待ち行列が一気に増えることがあります。専用線接続の不調では、AWS側は正常でも拠点から到達できず「全滅」に見えることもあります。
このあと、東京リージョンの公式障害告知事例を2つ取り上げ、そこから逆算して対策に落とし込みます。
参照元：AWS公式HP（https://aws.amazon.com/jp/premiumsupport/technology/pes/）
2019-08-23に東京リージョンで発生したEC2とEBSのイベントは、ワークロードが「動いているように見えるのに処理が進まない」状態を引き起こしやすいタイプの事例です。アプリ視点では、レスポンス遅延、タイムアウト増加、リトライの連鎖、バックグラウンド処理の滞留などが起きやすく、単純にサーバ台数を増やしても改善しないことがあります。
対策に落とすときは、二つの切り口が現実的です。ひとつは「止まっても壊れない」ために、タイムアウトとリトライの設計、キューイング、キャッシュ、部分停止時の縮退動作を決めておくこと。もうひとつは「止まり方を限定する」ために、単一AZ依存を減らし、障害点を分散させる構成にしておくことです。障害時に被害が読めるよう、影響範囲をアカウントやVPC単位で整理しておくのも効きます。
参照元：AWS公式HP（https://aws.amazon.com/jp/message/56489/）
参照元：AWS公式HP（https://aws.amazon.com/jp/premiumsupport/technology/pes/）
Direct Connect系のイベントは、アプリやインフラの構成が良くてもつながらないという一点で業務が止まり得ます。特に社内システムが閉域網前提で、VPNやインターネット経路を想定していないと、AWS側の稼働状況に関係なくユーザー体験が途切れます。
対策の基本は、回線と終端を一系統にしないことです。複数ロケーションでの冗長化、異なるデバイス終端、BGPのフェイルオーバー確認、必要に応じたVPNフォールバックまで含めて、切替が本当に働くかを事前に試験しておくと安心です。AWSには、目標SLAに合わせて必要な接続数や構成を考えるためのResiliency Toolkitが用意されています。
参照元：AWS公式HP（https://aws.amazon.com/jp/message/17908/）
AWS障害っぽいと感じたら、切り分けの最初の一手は公式の健康状態と自社アカウントへの影響を分けて見ることです。ここを混ぜると、社内起因の障害でもAWSの情報を追い続けたり、逆にAWS側イベントなのに自社だけの問題として深掘りしてしまったりします。見る場所を固定して、確認順をチームで揃えておくと、初動が整いやすくなります。
参照元：マイナビエンジニアガイド（https://tenshoku.mynavi.jp/engineer/guide/articles/45377）
まずは、リージョン別・サービス別の状態が見られるAWS Health Dashboardを確認します。ここで「東京リージョンの特定サービスに影響が出ている」などの情報が出ていれば、原因の方向性が一気に絞れます。逆に何も出ていない場合でも、すぐにAWS起因ではないと断定せず、次にアカウント固有イベントや自社監視の事実を積み上げるのが安全です。
参照元：AWS公式ドキュメント（https://docs.aws.amazon.com/ja_jp/health/）
次に、AWSマネジメントコンソールのAWS Health Dashboardで「自社アカウントに影響するイベント」と「影響を受けるリソース」を見ます。ここが分かると、全体停止か、特定VPCや特定リソースだけの問題かが切り分けやすくなります。さらに、予定メンテナンスや変更通知が出ていないかも合わせて確認すると、原因が「障害」ではなく「変更イベント」だったケースも拾えます。
運用としては、HealthイベントをEventBridgeなどで受け取り、ChatOpsやメールに流して「見に行く」ではなく「届く」形にすると、夜間や兼任体制でも抜けが減ります。
参照元：AWS公式ドキュメント（https://docs.aws.amazon.com/ja_jp/health/）
Xは、障害の広がりや他社の体感をつかむ補助線として便利ですが、これだけで判断しない方が落ち着いて対応できます。検索で同じ症状の投稿が増えているなら、影響が局所ではない可能性を考え、公式ダッシュボードや自社アカウントイベントと突き合わせます。逆に、投稿が少なくても自社だけが影響を受けている障害や設定ミスはあり得るので、公式情報と自社の観測結果で結論を作るのが堅実です。
参照元：Stylez公式HP（https://stylez.co.jp/aws_columns/aws-failure/）
初動で迷わないために、手順を文章で固定しておくのがおすすめです。まずAWS Health Dashboardでリージョン・サービスの状態を確認し、次にAWS Health Dashboardのアカウント固有イベントで影響リソースを特定します。そのうえでCloudWatchのメトリクスやログ、ロードバランサのヘルスチェック、アプリのエラーレートを見て「いつから」「どこまで」「何が増えたか」を短時間で言語化します。
この時点で、デプロイや構成変更が直前に入っているなら一旦止め、二次障害を避けます。影響が広い場合は、縮退運転や機能制限を早めに決める方が、現場も問い合わせ対応も楽になります。最後に、状況に応じてAWSサポートへのエスカレーションや、社内向けの共有文面を整えて「今わかっていること」と「次の更新時刻」をセットで出すと、混乱が抑えられます。
参照元：マイナビエンジニアガイド（https://tenshoku.mynavi.jp/engineer/guide/articles/45377）
AWS障害対策は「止まらない構成」を目指すほどコストも運用も膨らみやすいので、先に守りたい業務を決めるのが近道です。たとえば「注文は止めたくないが管理画面は一時停止でも良い」のように優先順位が決まれば、縮退運転の設計、データ整合性の取り扱い、フェイルオーバーの範囲が具体化します。
設計の拠り所としては、Well-Architected Frameworkの信頼性の考え方が使いやすいです。障害を前提に、検知、復旧、変更管理、キャパシティなどを整理していくと、対策が散らかりにくくなります。
参照元：AWS公式ドキュメント（https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html）
Design for Failureは、部品が壊れる前提でアプリとインフラを組み立てる考え方です。具体的には、タイムアウトを短めに設け、リトライは回数や間隔を制御し、同じ処理を繰り返しても壊れないよう冪等性を意識します。外部依存が遅い時はサーキットブレーカーで呼び出しを止め、キューに積んで後で処理するなど、「待ち続けて全部が巻き込まれる」状態を避けます。
この手の工夫は、AWS障害だけでなく、急な負荷増や部分的な不調にも効きます。結果として、復旧時のスパイクやバックログの解消も計画しやすくなります。
参照元：AWS公式ドキュメント（https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html）
Multi-AZは、同一リージョン内の複数AZにまたがって配置し、片側が不調でもサービスを継続しやすくする基本策です。Web層ならロードバランサ配下のインスタンスを複数AZに分散し、Auto Scalingのヘルスチェックで不健全な個体を置き換えられるようにします。データベースは、RDSのMulti-AZのようにフェイルオーバーを含めた仕組みを選ぶと、運用の負担が読みやすくなります。
ここでの注意点は、Multi-AZにしても「同時に壊れる設計」になっていると効果が薄いことです。たとえば単一AZにしか存在しない依存サービス、AZ固定の設定、片側だけに偏る容量設計などがあると、切替時に詰まります。フェイルオーバー後の性能や制限も含め、平時から小さく確認しておくと安心です。
参照元：AWS公式ドキュメント（https://docs.aws.amazon.com/ja_jp/AmazonRDS/latest/UserGuide/Concepts.MultiAZ.html）
リージョン規模の障害や大規模災害を想定するなら、マルチリージョンが選択肢に入ります。ただし、コストも運用も増えるので、いきなり全面移行ではなく「重要機能だけ」「読み取り系だけ」「バックアップだけ別リージョン」といった段階的な設計が現実的です。Route 53のフェイルオーバールーティングのように、ヘルスチェックを起点に切替える仕組みを使うと、切替の入口が作れます。
マルチリージョンで難しいのはデータです。整合性、レプリケーション遅延、切替時の書き込み先、戻し手順まで含めて決めないと、復旧後にデータ不整合が残ります。RTOとRPOを先に言語化し、必要な範囲だけを二重化する設計が進めやすいです。
設計だけ整えても、実際に切替が動くかは別問題です。そこで有効なのが、意図的に失敗を起こして耐性を確かめる試験です。AWS Fault Injection Serviceは、AWS上のワークロードに対して障害注入実験を行うためのマネージドサービスで、影響を制御しながら弱点を見つける用途に向きます。
進め方のコツは、いきなり本番で大胆にやらないことです。まずは検証環境で、次に本番の一部だけで、最後に営業時間外の範囲拡大という順番にすると、関係者も納得しやすいです。停止条件と連絡体制を事前に決めておくと、実験が「事故」に見えにくくなります。
参照元：AWS公式ドキュメント（https://docs.aws.amazon.com/fis/latest/userguide/what-is.html）
Direct Connectを使う場合は、回線の冗長化が設計の中心になります。単に「2本引く」ではなく、別ロケーション、別デバイス終端、BGPの経路制御、必要ならLAGの考慮まで含めて同じ理由で一緒に落ちない形を目指します。さらに、VPNによるバックアップ経路を用意しておくと、閉域網のイベントでも業務継続の余地が残ります。
AWS Direct Connect Resiliency Toolkitは、目標とする回復性モデルに合わせて接続構成を案内し、フェイルオーバーテストの考え方にも触れています。設計のたたき台として使うと、必要な冗長度を関係者と合意しやすくなります。
障害時は「何が起きたか」より先に何が見えていないかが問題になります。CloudWatchのメトリクスやログはもちろん、外形監視、アプリのエラーレート、依存先のレイテンシーなど、観測点を分散させると切り分けが速くなります。加えて、AWS Healthのイベントを通知として受け取れるようにしておくと、「AWS側の変化」を見落としにくくなります。
通知の設計は、量を増やすより「誰が見て、どう判断し、誰に渡すか」を決めておく方が効果が出やすいです。アラート疲れを避けるために、障害時だけ通知レベルを上げる運用ルールを用意しておくのも手です。
参照元：AWS公式ドキュメント（https://docs.aws.amazon.com/ja_jp/health/）
対策を現場に落とすときは、チェックリストを増やすより「判断軸」を固定すると進めやすいです。たとえば、業務ごとにRTOとRPOを決め、必要な範囲だけMulti-AZやマルチリージョン、バックアップ、縮退運転を当てはめます。そのうえで、変更管理と復旧訓練をセットで回し、図面だけで終わらせないことが重要です。
AWS Resilience Hubは、アプリケーションのレジリエンスを評価し、改善のおすすめを提示する用途に使えます。設計レビューの材料として活用すると、「どこから手を付けるか」が決めやすくなります。
参照元：AWS公式ドキュメント（https://docs.aws.amazon.com/resilience-hub/latest/userguide/what-is.html）
AWS障害対策は、設計だけでなく運用設計、監視、訓練、改善サイクルまで含めて初めて効いてきます。そのため、社内に専任がいない、夜間対応が薄い、移行と運用を同時に回しているといった状況では、外部支援を組み合わせた方が前に進むケースがあります。
TOKAIコミュニケーションズは、導入計画から構築、運用管理までを支援するサービスを提供しており、24時間365日の運用管理やマルチリージョン構成の支援などがメニューに含まれています。Direct Connectなどネットワーク面の要件が強い案件では、回線や冗長化設計まで含めて相談できる体制があるかが、障害時の復旧力に直結します。
参照元：TOKAIコミュニケーションズ公式HP（https://www.cloudsolution.tokai-com.co.jp/service/operation.html）
参照元：TOKAIコミュニケーションズ公式HP（https://www.cloudsolution.tokai-com.co.jp/service/multi-region.html）
参照元：AWS公式HP（https://aws.amazon.com/jp/blogs/psa/aws-premier-tokai/）
AWS障害対策は、発生時の確認手順と、設計・運用の備えを両輪で揃えるほど効果が出ます。まずはAWS Health Dashboardとアカウント固有イベントで切り分けを速め、次にMulti-AZやネットワーク冗長化、縮退運転、復旧訓練で「止まり方」を制御します。過去のPost-Event Summaryを読み、同じタイプの事象が来たときに自社が詰まりそうな点を先回りで潰しておくと、いざという時に落ち着いて動けます。
参照元：AWS公式HP（https://aws.amazon.com/jp/premiumsupport/technology/pes/）
TOKAIコミュニケーションズは、AWS導入から設計・移行・運用までをワンストップで支援するクラウドの専門家。AWSプレミアティアサービスパートナーとして豊富な実績を誇り、 600社以上（2025年9月時点）の導入実績と高い技術力に裏打ちされたサポート体制で、クラウドに不安を抱える企業の心強いパートナーです。