ハポソフトの​​ブログへようこそ

2025年10月20日、​Amazon Web Services​（AWS）の​米国東部​（バージニア北部）​リージョン​「us-east-1」で​大規模な​障害が​発生し、​EC2、​S3、​Cognito、​SageMakerなど​60以上の​サービスが​停止しました。​世界中の​企業や​アプリケーションに​影響が​及び、​クラウドアーキテクチャや​監視体制、​リカバリ戦略の​見直しが​求められる​事態と​なりました。​ 障害の​概要 2025年10月20日、​AWSの​米国東部​（バージニア北部）​リージョン​「us-east-1」で​大規模な​障害が​発生しました。​us-east-1は​AWSの​グローバルネットワークに​おいて​最も​利用が​集中し、​依存度の​高い​リージョンの​一つです。​本件は​数時間に​わたり基盤となりクラウドインフラを​寸断し、​世界中で​数百万の​ユーザーおよび​数千の​依存プラットフォームに​影響を​与えました。​ AWSに​より、​障害の​原因は​EC2環境内の​ネットワークロードバランサーの​健全性を​監視する​内部​サブシステムの​不具合に​起因する​ものです。​この​障害が​DNS解決エラーを​引き起こし、​DynamoDB、​Lambda、​S3など​複数の​主要サービス間の​通信が​停止しました。​結果と​して、​多数の​APIが​タイムアウトや​エラーを​返し、​広範囲に​わたる​接続障害が​発生しました。​ 影響は​EC2、​S3、​RDS、​CloudFormation、​Elastic Load Balancing、​DynamoDBなど、​60以上の​サービスが​数時間に​わたり​部分的または​完全に​利用不能と​なりました。​AWSは​本件を​「複数サービスに​影響する​運用障害​（Multiple Services Operational Issue）」と​して​分類します。​暫定的な​回避策を​適用した​後、​完全復​旧までに​ほぼ1日を​要しました。​ 発生時刻と​影響範囲 項目 詳細 発生日時 2025年10月20日 07:11 UTC​（約 UTC+7 14:11）​ 完全復​旧日時 10:35 UTC​（約 UTC+7 17:35）​頃、​一部​遅延は​その​後も​継続 影響リージョン us-east-1​（米国バージニア北部）​ 影響サービス数 64以上​（コンピューティング、​ストレージ、​ネットワーク、​データベース層など）​ 影響レベル 高​（グローバルな​APIトラフィックに​影響する​複数サービス障害）​ ステータス 同日夜​（UTC+7）までに​主要サービスは​回復 障害発生中、​Snapchat、​Fortnite、​Zoom、​WhatsApp、​Duolingo、​Ringなどの​主要オンラインサービスで​機能停​止や​性能低下が​報告されました。​ 影響を​受けた​主な​AWSサービス 障害は​複数層に​波及し、​特に​基盤インフラに​おいて​影響が​顕著でありました。​ カテゴリ サブ領域 影響サービス コアインフラ コンピュート/サーバーレス AWS Lambda, Amazon EC2, Amazon ECS, Amazon EKS, AWS Batch ストレージ/データベース Amazon S3, Amazon RDS, Amazon DynamoDB, Amazon ElastiCache, Amazon DocumentDB ネットワーク/セキュリティ Amazon VPC, AWS Transit Gateway, Amazon CloudFront, AWS Global Accelerator, Amazon Route 53, AWS WAF AI/データサービス 機械学習 Amazon SageMaker, Amazon Bedrock, Amazon Comprehend, Amazon Rekognition, Amazon Textract データ処理 Amazon EMR, Amazon Kinesis, Amazon Athena, Amazon Redshift, AWS Glue ビジネス系サービス 通信 Amazon SNS, Amazon SES, Amazon Pinpoint, Amazon Chime ワークフロー Amazon EventBridge, AWS Step Functions, Amazon MQ, Amazon API Gateway セキュリティ認証 AWS Secrets Manager, AWS Certificate Manager, AWS Key Management Service (KMS), Amazon Cognito 複数の​層が​順次障害を​起こした​ことで、​サービス間の​依存関係が​断裂し、​顧客は​デプロイ、​認証、​データ処理などの​基本機能を​複数リージョンに​わたって​行えない​状況に​陥りました。​ 障害が​クラウド運用に​与えた​影響 us-east-1 が​ダウンした​とき、​影響は​一部の​サービスにとどまらず、​システム全体に​広がりました。​ コアシステムが​次々と​障害を​起こし、​それらに​依存する​すべての​サービスが​ 動作の​遅延、​タイムアウト、​または​ 不整合な​データの​返却を​引き起こしました。​ その​結果、​近年の​AWSで​最も​大規模な​連鎖的障害の​一つ​ が​発生しました。​ 1. 連鎖的障害の​発生 複数サービスに​またがる​障害が​発生した​ことで、​依存システム間に​連鎖的な​障害が​生じました。​Cognito、​RDS、​S3と​いった​主要コンポーネントが​同時に​停止した際、​これらに​依存する​他サービスが​例外を​発生させ、​処理の​タイムアウトを​引き起こしました。​多くの​本番環境では、​1つの​API呼び出しの​失敗が​全体の​ワークフロー崩壊に​つながり、​リトライ処理が​さらなる​負荷を​生み出して​システム全体​へ​障害が​拡大しました。​ 2. データ​整合性の​問題 ​今回の​障害では、​複数サービス間で​データ​整合性の​乱れが​確認されました。​RDSと​ElastiCache間の​連携が​途絶した​ことで​キャッシュの​無効化問題が​発生し、​DynamoDB Global Tablesでは​リージョン間の​レプリケーション遅延が​生じました。​また、​S3や​CloudFrontでは​エッジロケーションから​不整合な​アセットが​返却され、​古い​コンテンツの​配信や​データ同期の​破損が​見られました。​ 3. 認証・認可の​不安定化 Cognito、​IAM、​Secrets Manager、​KMSなどの​認証基盤が​影響を​受け、​ログイン、​トークン更新、​データ復号処理が​停止。​結果と​して、​計算リソースが​正常でも​ユーザー認証が​行えない​ケースが​多発しました。​ 4. 業界別影響事例 Eコマース：注文処理や​支払い​APIが​タイムアウト。​確認メール送信の​失敗に​より​決済フローに​支障。​ SaaS／アプリ：Cognito認証の​停止で​ログイン不能。​Snapchat、​Slack、​Fortniteなどで​影響。​ メディア／配信：CloudFrontや​S3遅延に​よる​再生停止や​遅延。​ データ分析／AI：Glueや​SageMakerの​ジョブ中断に​より​ETL処理や​推論処理が​失敗。​ 業務ツール：Zoomや​Canvaなども​一時​的に​性能低下。​ 本件は、​同一リージョン内の​「マルチAZ」​構成のみでは​十分な​耐​障害性を​確保できない​ことを​示しました。​重要ワークロードは​リージョン間フェイルオーバーや​独立した​認証・​データ経路の​設計が​必要であります。​ 主な​教訓と​対策 今回の​us-east-1リージョン障害では、​クラウド運用に​おける​既知の​信頼性ギャップが​改めて​浮き彫りと​なった。​具体的には、​単一リージョンへの​依存、​分離層​（Isolation Layer）の​不足、​そして​事後対応型の​監視体制などが​挙げられます。​以下では、​より​高い​可用性を​実現する​ための​主要な​教訓と​実践的アプローチを​整理します。​ 1. 単一リージョン依存の​回避 最大の​教訓の​ひとつは、​単一リージョンに​依存した​構成はもは​や許容できません。​多くの​開発チームは​長年に​わたり、​us-east-1を​「標準的な​稼働拠点」と​して​扱ってきました。​サービスの​豊富さや​コストの​優位性、​応答速度などの​理由からです。​しかし、​その​利便性が​裏目に​出た形で、​当該リージョンが​停止した​際には​多くの​システムが​連鎖的に​停止しました。​ 対策と​しては、​複数リージョンに​またがる​冗長構成の​設計が​必要です。​アクティブな​ワークロードを​少なくとも​2リージョンで​稼働させ、​重要データを​非同期で​複製し、​リージョン障害時に​自動で​フェイルオーバーできるルーティング設計を​行うことが​推奨されます。​これに​より、​稼働時間の​確保だけでなく、​企業の​信用・法令遵守・事業継続性の​保護に​もつながります。​ 2. サーキットブレーカーと​サービスメッシュに​より​障害分離 今回の​障害では、​1つの​依存サービスの​停止が​全体に​波及する​脆弱性が​明らかと​なりました。​サービス間の​結合​度が​高い​場合、​1つの​障害が​リトライの​集中や​タイムアウトを​引き起こし、​結果​的に​全体を​巻き込むことがあります。​ このような​事態を​防ぐには、​サーキットブレーカー​（Circuit Breaker）​パターンを​活用し、​一定回数の​エラーを​検知した​時点で​不安定な​サービスへの​呼び出しを​一時停止する​仕組みを​導入する​ことが​有効です。​また、​AWS App Meshや​Istioなどの​サービスメッシュを​併用する​ことで、​こうした​回復ポリシーを​マイクロサービス全体に​統一的に​適用でき、​アプリケーションコードを​変更せずに​耐障害性を​強化できます。​ 3. 段階的劣化​（Graceful Degradation）の​設計 システムの​一部が​停止しても、​全体を​停止させない​設計が​重要であります。​重要機能のみを​維持し、​優先度の​低い​機能を​一時的に​停止させる​ことで、​完全停止を​回避できます。​ その​ためには、​事前に​フェールバック​経路を​用意する​ことが​求められます。​データベースが​利用できない​場合には​キャッシュを​活用し、​書き込みが​失敗した​場合には​読み取り専用モードに​切り替えるなど、​柔軟な​制御が​有効であります。​これに​より、​ユーザー信頼と​サービス継続性を​保つことができます。​ 4. 可​観測性​（Observability）と​プロアクティブな​監視強化 多くの​チームが​障害を​把握したのは、​監視ツールではなく​ユーザーからの​報告でありました。​これに​より​対応が​遅れ、​復旧までに​多くの​時間を​要します。​ 問題を​防ぐには、​AWS標準の​CloudWatchだけに​依存せず、​Prometheus、​Grafana、​Datadogなど​外部​ツールと​組み合わせ、​メトリクス・トレース・ログを​横断的に​分析する​ことが​重要です。​また、​アラートは​静的閾値ではなく​異常検知ベースで​発報される​べきであり、​監視データは​障害リージョン外に​保持しておく​必要が​あります。​ 5. 自動復旧と​耐障害性テストの​実装 今回の​障害では、​手動対応に​依存する​ことの​非効率さも​浮き彫りに​なりました。​広範囲な​障害時には、​人手に​よる​復旧では​時間が​かかり、​影響が​拡大します。​ 信頼性の​高い​システムでは、​問題を​自動検出し、​即座に​復旧ワークフローを​実行できる​仕組みが​必要であります。​CloudWatchアラームや​Step Functions、​内部ヘルスチェックを​活用し、​自動再起動や​スタンバイDB昇格、​トラフィックの​再ルーティングを​自動化する​ことが​推奨されます。​さらに、​これらの​自動化は​継続的に​検証・​改善していく​べきです。​ 加えて、​定期的な​「Chaos Testing​（障害シミュレーション）」の​実施に​より、​実際の​障害発生時に​復旧ロジックが​機能するかを​確認する​ことが​有効です。​ 今後の​行動計画 今後​30日以内​ 単一リージョンに​集中している​ワークロードを​洗い出し、​依存状況を​整理 外部からの​レイテンシ・エラー率・​可用性監視を​導入 インシデント対応手順書​（プレイブック）の​整備 小規模フェイルオーバーテストの​実施 今後​3〜6か​月 重要ワークロードの​マルチリージョン展開 重要データの​非同期レプリケーション導入 自動復旧・フォールバック​動作の​テスト 自己修復型ワークフローの​部​分導入 今後​6〜12か​月 ベンダー・リージョンリスク低減の​ための​マルチクラウド・ハイブリッド構成の​検討 レイテンシに​敏感な​用途向けに​エッジコンピューティングを​活用 AIを​活用した​異常検知・​自動アラート機能の​強化 技術面と​業務面を​含む包括的な​事業継続計画​（BCP）の​策定 Haposoftは、​AWS環境に​おける​信頼性設計・テスト・スケーリング支援に​おいて、​長年の​実務経験を​有しています。​ 今回のような​障害を​踏まえ、​インフラの​耐障害性を​高めたい​企業に​対して、​当社エンジニアが​設計・検証・運用の​各段階で​技術的支援を​提供する​ことが​可能です。​ クラウド障害は​避けられないが、​重要なのは​「発生時に​どれだけ準備が​できていますか」。​Haposoftは、​事前の​備えと​継続的な​改善を​通じて、​より​堅牢で​信頼性の​高い​システム基盤の​構築を​支援しています。​ 結論​ 今回の​AWS us-east-1リージョン障害は、​クラウドシステムの​脆弱性を​改めて​示しました。​完全な​無停止は​現実的では​ありませんが、​事前準備と​設計上の​工夫に​よって​被害を​最小限に​抑える​ことは​可能です。​ クラウド障害は​今後も​発生し得るが、​重要なのは​「どれだけ​備えられていますか」。​継続的な​改善と​検証こそが、​信頼性を​構築する​鍵と​なります。