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 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で最も大規模な連鎖的障害の一つ が発生しました。
複数サービスにまたがる障害が発生したことで、依存システム間に連鎖的な障害が生じました。Cognito、RDS、S3といった主要コンポーネントが同時に停止した際、これらに依存する他サービスが例外を発生させ、処理のタイムアウトを引き起こしました。多くの本番環境では、1つのAPI呼び出しの失敗が全体のワークフロー崩壊につながり、リトライ処理がさらなる負荷を生み出してシステム全体へ障害が拡大しました。
今回の障害では、複数サービス間でデータ整合性の乱れが確認されました。RDSとElastiCache間の連携が途絶したことでキャッシュの無効化問題が発生し、DynamoDB Global Tablesではリージョン間のレプリケーション遅延が生じました。また、S3やCloudFrontではエッジロケーションから不整合なアセットが返却され、古いコンテンツの配信やデータ同期の破損が見られました。
Cognito、IAM、Secrets Manager、KMSなどの認証基盤が影響を受け、ログイン、トークン更新、データ復号処理が停止。結果として、計算リソースが正常でもユーザー認証が行えないケースが多発しました。
Eコマース：注文処理や支払いAPIがタイムアウト。確認メール送信の失敗により決済フローに支障。
SaaS／アプリ：Cognito認証の停止でログイン不能。Snapchat、Slack、Fortniteなどで影響。
メディア／配信：CloudFrontやS3遅延による再生停止や遅延。
データ分析／AI：GlueやSageMakerのジョブ中断によりETL処理や推論処理が失敗。
業務ツール：ZoomやCanvaなども一時的に性能低下。
本件は、同一リージョン内の「マルチAZ」構成のみでは十分な耐障害性を確保できないことを示しました。重要ワークロードはリージョン間フェイルオーバーや独立した認証・データ経路の設計が必要であります。
今回のus-east-1リージョン障害では、クラウド運用における既知の信頼性ギャップが改めて浮き彫りとなった。具体的には、単一リージョンへの依存、分離層（Isolation Layer）の不足、そして事後対応型の監視体制などが挙げられます。以下では、より高い可用性を実現するための主要な教訓と実践的アプローチを整理します。
最大の教訓のひとつは、単一リージョンに依存した構成はもはや許容できません。多くの開発チームは長年にわたり、us-east-1を「標準的な稼働拠点」として扱ってきました。サービスの豊富さやコストの優位性、応答速度などの理由からです。しかし、その利便性が裏目に出た形で、当該リージョンが停止した際には多くのシステムが連鎖的に停止しました。
対策としては、複数リージョンにまたがる冗長構成の設計が必要です。アクティブなワークロードを少なくとも2リージョンで稼働させ、重要データを非同期で複製し、リージョン障害時に自動でフェイルオーバーできるルーティング設計を行うことが推奨されます。これにより、稼働時間の確保だけでなく、企業の信用・法令遵守・事業継続性の保護にもつながります。
今回の障害では、1つの依存サービスの停止が全体に波及する脆弱性が明らかとなりました。サービス間の結合度が高い場合、1つの障害がリトライの集中やタイムアウトを引き起こし、結果的に全体を巻き込むことがあります。
このような事態を防ぐには、サーキットブレーカー（Circuit Breaker）パターンを活用し、一定回数のエラーを検知した時点で不安定なサービスへの呼び出しを一時停止する仕組みを導入することが有効です。また、AWS App MeshやIstioなどのサービスメッシュを併用することで、こうした回復ポリシーをマイクロサービス全体に統一的に適用でき、アプリケーションコードを変更せずに耐障害性を強化できます。
システムの一部が停止しても、全体を停止させない設計が重要であります。重要機能のみを維持し、優先度の低い機能を一時的に停止させることで、完全停止を回避できます。
そのためには、事前にフェールバック経路を用意することが求められます。データベースが利用できない場合にはキャッシュを活用し、書き込みが失敗した場合には読み取り専用モードに切り替えるなど、柔軟な制御が有効であります。これにより、ユーザー信頼とサービス継続性を保つことができます。
多くのチームが障害を把握したのは、監視ツールではなくユーザーからの報告でありました。これにより対応が遅れ、復旧までに多くの時間を要します。
問題を防ぐには、AWS標準のCloudWatchだけに依存せず、Prometheus、Grafana、Datadogなど外部ツールと組み合わせ、メトリクス・トレース・ログを横断的に分析することが重要です。また、アラートは静的閾値ではなく異常検知ベースで発報されるべきであり、監視データは障害リージョン外に保持しておく必要があります。
今回の障害では、手動対応に依存することの非効率さも浮き彫りになりました。広範囲な障害時には、人手による復旧では時間がかかり、影響が拡大します。
信頼性の高いシステムでは、問題を自動検出し、即座に復旧ワークフローを実行できる仕組みが必要であります。CloudWatchアラームやStep Functions、内部ヘルスチェックを活用し、自動再起動やスタンバイDB昇格、トラフィックの再ルーティングを自動化することが推奨されます。さらに、これらの自動化は継続的に検証・改善していくべきです。
加えて、定期的な「Chaos Testing（障害シミュレーション）」の実施により、実際の障害発生時に復旧ロジックが機能するかを確認することが有効です。
今後30日以内
単一リージョンに集中しているワークロードを洗い出し、依存状況を整理
外部からのレイテンシ・エラー率・可用性監視を導入
インシデント対応手順書（プレイブック）の整備
小規模フェイルオーバーテストの実施
今後3〜6か月
重要ワークロードのマルチリージョン展開
重要データの非同期レプリケーション導入
自動復旧・フォールバック動作のテスト
自己修復型ワークフローの部分導入
今後6〜12か月
ベンダー・リージョンリスク低減のためのマルチクラウド・ハイブリッド構成の検討
レイテンシに敏感な用途向けにエッジコンピューティングを活用
AIを活用した異常検知・自動アラート機能の強化
技術面と業務面を含む包括的な事業継続計画（BCP）の策定
Haposoftは、AWS環境における信頼性設計・テスト・スケーリング支援において、長年の実務経験を有しています。
今回のような障害を踏まえ、インフラの耐障害性を高めたい企業に対して、当社エンジニアが設計・検証・運用の各段階で技術的支援を提供することが可能です。
クラウド障害は避けられないが、重要なのは「発生時にどれだけ準備ができていますか」。Haposoftは、事前の備えと継続的な改善を通じて、より堅牢で信頼性の高いシステム基盤の構築を支援しています。
今回のAWS us-east-1リージョン障害は、クラウドシステムの脆弱性を改めて示しました。完全な無停止は現実的ではありませんが、事前準備と設計上の工夫によって被害を最小限に抑えることは可能です。
クラウド障害は今後も発生し得るが、重要なのは「どれだけ備えられていますか」。継続的な改善と検証こそが、信頼性を構築する鍵となります。
