「もしもクラウド障害が発生したら……」10月に起きたAWS障害から、ユーザー企業がすべき“備え”を整理する
サービス停止に陥った企業と継続できた企業の明暗を分けた「Design for Failure」
2025年10月20日、AWSの米国東部（us-east-1）リージョンで発生した障害は、AmazonやSlack、Zoom、任天堂など、世界中のシステムに長時間の通信障害をもたらした。直接の要因は「Amazon DynamoDB」のDNS設定における名前解決の問題だが、障害はEC2の起動システムやNLBへとドミノ倒しのように連鎖。最終的には「AWS Lambda」「Amazon Redshift」など主要サービスへも波及した。舞台となったus-east-1は、AWSで最も古く、グローバルサービスの管理機能が集約された「デフォルトリージョン」である。その構造上、一度トラブルが起きると被害が拡大・長期化しやすい。一方で、Netflixなどの一部企業はこの状況下でも運用を継続できていた。彼らは「クラウド障害は必ず発生する」という前提でシステムを構築していたからだ。クラウドの障害は今後も避けられない。ビジネスへの影響を最小化するために、企業は何をすべきか。AWS最上位パートナーであるアイレットのクラウドスペシャリスト、後藤和貴氏と廣山豊氏に、有事に備えるための知見を伺った。
長い一日となった「10月20日」何が起こったのか
まずはあらためて10月20日にus-east-1で何が起こったのか整理したい。AWSの公式発表[1]によれば、us-east-1でサービス障害が発生した期間は日本時間で10月20日15時48分から10月21日6時20分にかけてのことだ。以下、公式発表をもとに障害の影響が大きかった3つのサービス「DynamoDB」「Amazon EC2」「NLB」に関してそれぞれ時系列でイベントを振り返ってみたい。
DynamoDB
15:48 |
DynamoDBにおいてAPIエラー率が上昇。これによりDynamoDBユーザーやDynamoDBに依存する他のAWSサービスへの新規接続を確立できなくなる→AWSエンジニアが調査を開始 |
|---|---|
16:38 |
調査の結果、DynamoDBのDNSの状態が障害の原因（DynamoDBのエンドポイントにおける名前解決の失敗）であることを特定 |
17:15 |
一時的な緩和策を適用し、一部の内部サービスのDynamoDBへの接続が復旧。さらに重要な内部ツールの修復により回復作業が進む |
18:25 |
すべてのDNS情報が復元、DynamoDBエンドポイントの名前解決ができるようになり、正常な接続を確立→復旧完了 |
Amazon EC2
15:48 |
EC2 APIのエラー率上昇、レイテンシの増加、インスタンス起動の失敗が発生→DynamoDBのDNSに起因することが判明（EC2をホストする物理サーバー〔ドロップレット〕の状態管理にDynamoDBが使われているため） |
|---|---|
18:25 |
DynamoDB APIの復旧にともない、ドロップレットを管理するDWFM(DropletWorkFlow Manager)は個々のドロップレットとのリースを再確立しようと試みるが、ドロップレットの数が多すぎて作業がタイムアウト前に完了できず、DWFMは輻輳状態に陥る→AWSエンジニア「この状況に適した、確立された運用回復手順が存在しなかったため、慎重な対応が必要だった」 |
20:14 |
受信作業をスロットリング（リクエストの制限）、DWFMホストの選択的な再起動を開始→DWFMのキューがクリア、処理時間が短縮し、ドロップレットリースの確立が可能に |
21:28 |
us-east-1リージョン内のすべてのドロップレットとリースを確立、新規インスタンスの起動が徐々に成功し始める（スロットリングの影響でまだほとんどのリクエストがエラー状態）。同時にEC2インスタンスのネットワーク状態を管理するNetwork Managerが、新しく起動されたインスタンスとイベント中に終了したインスタンスに対して更新されたネットワーク設定の伝播を開始（DWFMの問題によりネットワーク状態伝播も遅延していたため、変更情報の膨大なバックログが発生していた） |
22:21 |
ネットワーク伝播時間の増加を観測、新規EC2インスタンスが起動できてもネットワーク状態伝播の遅延により必要なネットワーク接続が確立できない状態に→Network Managerの負荷を軽減してネットワーク設定伝播時間に対処 |
2:36 |
ネットワーク設定伝播時間が通常のレベルに回復、新規EC2インスタンスの起動も正常に戻る |
3:23 |
完全な復旧に向けてスロットリングの緩和を開始 |
5:50 |
すべてのEC2 APIと新規EC2インスタンスの起動が正常に動作することを確認 |
Network Load Balancer（NLB）
21:30 |
us-east-1を利用する一部のユーザーの環境でNLB接続エラーが増加。EC2インスタンスを監視し、不健全なノードをサービスから除外するNLBヘルスチェックサブシステムのヘルスチェック機能が、ターゲットが正常であるにもかかわらず失敗するケースが発生。失敗と成功が交互に繰り返す→NLBノードとバックエンドターゲットが除外と復帰を繰り返すことでNLBの負荷が増大、アプリケーション接続エラーも増加 |
|---|---|
22:52 |
監視システムがヘルスチェックの失敗を検知、ヘルスチェックサブシステムが新しいEC2インスタンスをサービスに組み込む際に、それらのインスタンスのネットワーク状態が完全に伝播されていなかったことが原因と判明→EC2のネットワーク状態伝播の大量のバックログ発生に起因 |
1:36 |
自動DNSヘルスチェックフェイルオーバー機能を無効化し、正常なノードとバックエンドターゲットをすべてサービスに復帰、接続エラーの増加を解決 |
6:09 |
EC2回復直後に自動DNSヘルスチェックフェイルオーバーを再度有効化 |
DynamoDBのDNS設定に起因した今回の大障害は、AWSが提供する実に141ものサービスに影響を与えた。最後に復旧したイベントはコンテナ関連のサービスである「Amazon ECS」「Amazon EKS」「AWS Fargate」におけるコンテナ起動の失敗とクラスタのスケーリングの遅延で、10月21日6時20分に回復している。発生から復旧まで約15時間、AWSとus-east-1にとって本当に長い1日となった。
前述したように、us-east-1はAWSにとって特別なデフォルトリージョンである。AWSだけでなく、AWSをベースにサービスを展開するサードパーティベンダやAPI提供サービスも「まずはus-east-1」からデプロイを始めることが多い。また、歴史的経緯からIAMやRoute 53といったグローバルサービスのバックエンドがus-east-1に集中しており、このアーキテクチャをあらためて分散化することは非常に困難な作業となる。us-east-1への一極集中の危険性は以前から指摘されており、AWSも細かな改善を繰り返しているものの、20年もの歴史があるリージョンだけにその依存構造が解消されるまでにはまだ長い時間がかかるとみられる。
この記事は参考になりましたか？
- 五味明子の『エンプラIT Round-up』連載記事一覧
-
- 「もしもクラウド障害が発生したら……」10月に起きたAWS障害から、ユーザー企業がすべき“...
- 医師の負担軽減へ──地域医療機関が“院内生成AI”による「退院時サマリ」自動作成をオンプレ...
- 2025年上半期のバズワード「MCP」はデファクトスタンダードになりうるのか？Red Ha...
- この記事の著者
-
五味明子（ゴミ アキコ）
IT系出版社で編集者としてキャリアを積んだのち、2011年からフリーランスライターとして活動中。フィールドワークはオープンソース、クラウドコンピューティング、データアナリティクスなどエンタープライズITが中心で海外カンファレンスの取材が多い。
Twitter(@g3akk)や自身のブログでITニュース...※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です
この記事は参考になりましたか？
この記事をシェア
