関連するソリューション
マネージドサービス（運用・保守）
セキュリティサービス
IDアメリカ
ハムザ・アフメッド
本稿で描くのは、あるクラウド障害の一夜です。
オンコールのエンジニア、混乱する現場、そして判断を迫られる経営層。
ここに描かれる出来事は、実際に起きた出来事、もしくはそれに非常に近い事例をもとに構成されています。
23:43
ほとんどのエンジニアはすでに眠りについており、トラフィックも徐々に落ち着き始めています。1日の終わりが近づいている時間帯です。今夜のオンコール担当であるあなたは、就寝前にいつものようにシステムの健全性を確認しています。特に緊急性のある兆候は見当たりませんでしたが、しばらくするといくつかのアラートが表示され始めます。APIのレイテンシが徐々に上昇し、カスタマーサポートからは「ログイン時に断続的な不具合が発生している」という連絡が入ります。
ダッシュボードを確認すると、エラー率は上昇しているものの、完全に停止しているサービスはまだありません。しかし、対応を開始するには十分な兆候です。
直近のデプロイをロールバックし、機能フラグを無効化します。Infrastructure as Code のジョブが実行中でないか、定期メンテナンスが走っていないかも確認します。構成上の問題は見当たりませんが、状況は改善しません。
影響範囲を広げて調査を進めます。
EC2 インスタンスの起動が失敗し、オートスケーリングが機能していません。マネージドサービスはタイムアウトを起こしています。AWS のコントロールプレーンに依存する処理が、軒並み不安定な挙動を示していました。
午前2時頃、インシデントの重大度を引き上げ、正式なインシデントチケットを起票します。 Teams に専用チャンネルを作成し、SRE やバックエンドエンジニアが呼び出しを開始します。
もはや通常のアラート対応ではありません。
目覚ましの通知
2:15
スマートフォンが緊急アラートで鳴り響きます。長い1週間を終え、疲労がたまった状態で半分眠りながらも、けたたましい通知音が一気に意識を覚醒させます。リードバックエンドエンジニアであるあなたが Teams を確認すると、新しく作成されたチャンネルにはすでに大量のメッセージが流れています。数十件の通知、部分的な障害、食い違う症状、そして高まる不安。
オンコールのバックエンドエンジニアとして、周囲はあなたの判断を求めています。
ノートパソコンを開き、システムにログインします。
一見すると、多くのサービスは稼働しているように見えます。しかし詳細を確認した瞬間、はっきりと理解します。
すでに存在しているものは動いているが、新しいものは何も作れない。
障害が発生しているサービスを、ログを見ながら再起動してみますが、復旧しません。別のエンジニアからも同様の報告が入り、あなたはすぐに再起動を中止します。そしてチャンネルにメッセージを送信します。
「正常に稼働しているサービスは再起動しないでください。
リソースの削除や再作成は行わないでください。
一度落ちると、戻ってこない可能性があります。」
もはや問題を「修正する」段階ではありません。
これ以上悪化させないことが最優先となります。
5時に不都合な現実を突きつけられます。これは自分たちで解決できる問題ではありません。
調査を進めると、原因は AWS 自体、しかもコントロールプレーンの深い部分にある可能性が高いことが分かりましたが、正確な原因は誰にも分かりません。AWS サポートからの回答は曖昧で、ステータスページには「調査中」としか記載されていません。
そこで方針を切り替えます。
目標は「復旧」ではなく「封じ込め」です。
健全なインスタンスを誤って停止させないよう、自動ヘルスチェックを無効化します。タイムアウト値を延ばし、既存のキャパシティを何よりも優先して保護します。バックグラウンドジョブは停止され、不要な機能は無効化され、CI/CD も凍結されます。
7時頃、パートナー企業のエンジニアとも連絡を取り、同じ症状が発生していることを確認します。異なるアプリケーション、異なるアーキテクチャ。しかし、障害の発生パターンは同一です。
これは自社だけの問題ではありません。
経営層向けにサマリーを作成します。原因は AWS にある可能性が高く、復旧の見通しは立っていません。数分で戻るかもしれないし、数時間かかるかもしれません。
7:34
会社の役員として目を覚ましたら、メールを確認するのが日々のリズムです。一瞬で眠気が吹き飛びます。カスタマーサポート、IT、オペレーション部門から緊急の連絡が次々と届いています。ベッドから起き上がる頃には、すでにほとんどのエンジニアが対応に入っています。
IT 部門の責任者に電話をかけ、状況を確認するとシステムは非常に不安定な状態にあり、AWS 側に障害が発生している可能性が高く、完全復旧の時期は分からないとの説明を受けます。
当然の質問を投げかけます。
「復旧の見込みは？」
返事：「30分後かもしれませんし、もっと長引く可能性もあります。」
電話を切り、この日の自分の役割が明確になります。
ダメージコントロールの開始です。
10:54
カスタマーサポートのシフトに少し早めに出社します。普段よりも騒がしく、電話の本数も多く、緊張感が漂っています。
簡単なブリーフィングを受けたところ、顧客には慎重に言葉を選びながら、「インフラ全体で大きな障害が発生しており、エンジニアが対応中です。当面はオフラインモードを利用してください」と伝える方針です。
この会社は、小売店や飲食店向けの POS システムを提供しています。
多くの顧客にとって「オフラインモード」は馴染みのないものです。
電話は鳴り止みません。
理解を示す顧客もいれば、怒りをぶつける顧客もいます。しかし、全員が不満と不安を抱えているのが伝わります。
何度も同じ質問を受けます。
「いつ直るのですか？」
しかし、明確な答えがいまだありません。
13:16
ようやく電話を切り、システムをオフラインモードに切り替えました。飲食店の店長として、なぜこの障害が起きているのかは正直どうでもよく、ただランチタイムのピークにレジが思うように動かないという現実だけがあります。
注文は手書きに切り替わり、スタッフは混乱し、客は苛立っています。
電話口の担当者を責める気にはなりません。声から疲労が伝わってきました。しかし被害は現実です。失われる売上、疲弊する従業員、張り詰めた店内の空気。
これがディナータイムまで続かないことを祈ります。
15:44
長い一日を経て、これが長期化するのではないかという不安が頭をよぎります。IT 部門の責任者として、「Azure へ移行すべきではないか」という議論が避けられずに持ち上がります。短時間ではありますが、真剣に検討されます。しかしすぐに現実が見えてきます。この規模のシステムを移行し、現状と同等の状態に戻すには数週間を要します。インフラ、ツール、運用ノウハウのいずれも準備が整っていません。
さらに重要なのは、自社システムは単独で成り立っていないという点です。多くの外部サービスに依存しており、それらの多くも同じ障害の影響を受けています。全社・全業界が同時に移行しない限り、クラウドを切り替えても意味のある復旧にはなりません。
残された行動は待つことのみです。
やがて、水面下で AWS の復旧が始まります。
新しいインスタンスが再び起動できるようになり、スケーリングがゆっくりと戻り始めます。システムは一気に回復することはなく、少しずつ、這うように戻っていきます。キューは解消され、ヘルスチェックは安定し、エンジニアたちは慎重に、段階的に機能を再有効化していきます。
技術的に「復旧した」と言える頃には、その日の業務はすでに終わっていました。
エンジニアは記録を残し、経営陣は説明の準備をし、サポートチームは追加の問い合わせに備えます。
今日を乗り切ることが、最大の成果でした。
現実
冒頭でも述べましたが、本シナリオは、実際に起きた出来事、もしくはそれに非常に近い事例です。2025年10月19日、AWS の us-east リージョンにおいて大規模な障害が発生しました。このリージョンは非常に多くのサービスやワークロードを抱えているため、影響は広範囲に及び、深刻なものとなりました。障害はおおよそ11時40分から15時頃まで続き、その間、多くの AWS サービスが部分的または全面的に利用できない状態となりました。復旧後、AWS は障害の原因と経緯を詳細にまとめた公式の事後報告書を公開しています。
原因（簡易説明）
AWS が公開した事後報告書によると、本障害の原因はサイバー攻撃や利用者側の設定ミスではなく、AWS 内部のソフトウェアに起因するものでした。具体的には、us-east-1 リージョンにおける DynamoDB の DNS 管理を自動化する仕組みで、稀な不具合が発生しました。DynamoDB は、リクエストを正しいインフラに振り分けるため、サービスのエンドポイント情報を自動的に管理しています。しかし、特定のタイミング条件が重なったことで、この自動処理が一時的に重要な DNS 情報を削除してしまい、DynamoDB のエンドポイントを正しく解決できない状態が発生しました。その結果、多くのシステムが DynamoDB に接続できなくなりました。
DynamoDB は AWS 内部の多くのサービスから利用される基盤的なサービスであるため、この影響は短時間で他のサービスにも波及しました。DNS の問題自体は比較的早期に修正されたものの、依存関係を持つサービスの復旧には数時間を要しました。結果として、一つの内部的な不具合が、リージョン全体に影響する大規模障害へと発展したのです。
より詳しい技術的背景については、AWS が公開している公式の事後報告書をご参照ください。
対策
AWS の内部的な不具合を利用者側で直接修正することはできません。しかし、今回のようなリージョン単位の障害が発生しても、事業全体が停止しないようにシステムを設計することは可能です。本インシデントから得られる重要な教訓は、「単一サーバーや単一 AZ の障害対策だけでは不十分である」という点です。リージョン全体の障害を前提に設計する
多くのシステムは、単一のデータセンター障害を想定した Multi-AZ 構成を採用しています。しかし、今回の障害はリージョン全体で共有されるサービスに影響を及ぼしました。ミッションクリティカルなシステムについては、リージョン全体が利用できなくなる可能性を前提に設計する必要があります。その方法としては、複数リージョンで同時にサービスを稼働させる、あるいは待機用のセカンダリーリージョンを用意し、必要に応じて切り替えられる構成が考えられます。実際、本インシデントでは DynamoDB をマルチリージョン構成で利用していた一部の顧客は、性能低下はあったものの、別リージョンでサービスを継続できました。
DNS やサービスエンドポイントを重要な依存関係として扱う
今回の障害は DNS に起因するものでしたが、DNS は通常意識されにくく、正常時には存在感がそれほどありません。しかし、エンドポイントの解決に失敗した場合、その影響は非常に大きくなります。アプリケーションをエンドポイント障害が発生した際にも過剰なリトライによって状況を悪化させない設計とし、必要に応じてトラフィックを切り替えられるようにすることが重要です。ルーティング変更の手順や、適切なタイムアウト設定を事前に整備しておくことで、小さな障害が大規模障害へと発展するのを防ぐことができます。
すべてを一つのリージョンに集約しない
多くの組織では、認証基盤、バックグラウンドジョブのキュー、CI/CD パイプラインなど、重要な共通サービスが無意識のうちに単一リージョンへ集中しています。そのリージョンが障害を起こした場合、復旧は極めて困難になります。これらの共通サービスを複数リージョンに分散させる、もしくはリージョンごとに独立して動作できる設計にすることで、リスクを大幅に低減できます。マルチクラウド戦略も一つの選択肢ですが、事前に設計・検証されていなければ、障害発生時に有効な手段とはなりません。
障害は「起きる前」に練習する
システムの耐障害性は、技術だけでなく人の対応力にも大きく左右されます。定期的な障害対応訓練、明確に整備されたランブック、依存関係を可視化する仕組みがあれば、実際の障害発生時にも冷静に対応できます。リージョン障害やマネージドサービスの停止を想定した訓練を事前に行っておくことで、本番環境で初めて重大な判断を迫られる状況を避けることができます。
最後に
組織が IT インフラへの依存度を高めるにつれ、今回のようなインシデントがもたらす影響は、ますます広範かつ深刻なものになってきています。本シナリオが示しているように、大規模な障害は必ずしもサイバー攻撃や悪意ある行為によって引き起こされるわけではありません。時に、内部的なソフトウェアの小さな不具合一つが、現場を混乱させ、組織全体を機能不全に陥らせることもあります。今回は影響が AWS の単一リージョンに限定されましたが、将来的により大規模、あるいはグローバルな障害が発生する可能性を否定することはできません。このリスクは、システムの高度化と密結合が進むにつれて、さらに高まっていくと考えられます。この現実に備えるためには、障害を「防ぐ」ことだけでなく、「障害が起きた状態でも事業を継続する」視点が不可欠です。耐障害性の高いアーキテクチャを構築し、最悪の事態を想定した計画を立て、訓練やシミュレーションを通じて定期的に対応力を磨くことが求められます。いずれ、大きな障害は必ず起こります。その時、準備ができているかどうかが、一時的な混乱で済むか、長期的なダメージを受けるかを分けることになるでしょう。
IDグループでは、こうしたクラウド障害や運用リスクに備えるため、セキュリティ監視から運用・復旧までを一体で支えるマネージドサービスを提供しています。
クラウド環境の安定運用や事業継続に課題を感じている方は、以下のサービスもご参照ください。
・セキュリティコンサルティング
https://www.idnet.co.jp/service/security_ps.html
・Smart運用サービス
https://www.idnet.co.jp/service/smart_system_operation.html
当サイトの内容、テキスト、画像等の転載・転記・使用する場合は問い合わせよりご連絡下さい。
エンジニアによるコラムやIDグループからのお知らせなどを
メルマガでお届けしています。
