On 2025 年 10 月 20 日世界最大のクラウドプロバイダーであるAmazon Web Services（AWS）は、 US-EAST-1地域（バージニア州北部）で大規模な障害が発生 世界中で約24時間にわたりサービスを中断させたこの災害は、現代のインターネットインフラが単一のクラウドプロバイダーに大きく依存していることを浮き彫りにし、レジリエンス（回復力）、冗長性、そしてマルチクラウド戦略に関する議論を再燃させました。
事件の概要
イベント： エラー率とレイテンシの増加
地域： US-EAST-1（バージニア州北部）
期間： 10月19日午後11時49分～10月20日午後3時01分（PDT）
重大度： 混乱した
主な根本原因: DynamoDB エンドポイントでの DNS 解決の失敗
影響を受けるサービス: EC2、Lambda、S3、DynamoDB、CloudWatch、Redshift など 140 を超える AWS サービス。
タイムラインと根本原因分析
停電は遅くに始まった 2025 年 10 月 19 日エンジニアが複数のAWSサービスでエラー率の増加を検知した際に、最初の調査で Amazon DynamoDBは、多数の社内および顧客アプリケーションを支えるコアデータベースサービスです。 12：26 AM PDTAWSは、この問題が 誤ったDNS更新 これによりエンドポイントの解決が妨げられ、サービスを宛先に誘導する「電話帳」が事実上壊れてしまいました。
DNS 障害により、次のような一連の依存システム エラーが発生しています。
- EC2インスタンスの起動 DynamoDB の依存関係により停止しました。
- ネットワークロードバランサのヘルスチェック 失敗し、Lambda、SQS、CloudWatch などのサービス間で接続が失われました。
- IAM アップデート and DynamoDB グローバルテーブル また、影響を受けた地域への依存により遅延も発生しました。
AWSのエンジニアは、DNSキャッシュのフラッシュ、EC2インスタンスの起動の抑制、そしてネットワーク接続の段階的な回復といった緩和策を並行して適用しました。 2：24 AM PDT主要なDNSの問題は解決しましたが、ネットワークとEC2サブシステムの問題は朝まで残りました。 ネットワークロードバランサのヘルスサブシステム 完全に回復した 9：38 AM PDT最終的なサービス正常化は 午後3時PDT.
影響範囲
その影響は広範囲に及び、世界中の企業向けサービスと一般的な消費者向けプラットフォームの両方に影響を与えました。 140 の AWS サービス 以下を含む障害が発生しました:
- コンピューティングとネットワーク: EC2、ECS、EKS、Elastic Load Balancing
- データとストレージ: DynamoDB、S3、RDS、Redshift、ElastiCache
- サーバーレス： Lambda、EventBridge、SQS、Step Functions
- セキュリティと管理: IAM、AWS Organizations、CloudTrail、Config
- 開発者ツール： CodeBuild、Amplify、AppSync、CloudFormation
障害の影響はAWSの顧客だけにとどまりませんでした。 スナップチャット、フォートナイト、ロブロックス、コインベース、ベンモ、さらに Amazon独自のプライムビデオとリングサービス 混乱が生じた。ロイズやハリファックスなどの金融機関はログインに問題を抱え、政府のポータルは一時的にオフラインになった。AWSは約 世界のクラウドインフラ市場シェアの33%この出来事の波及効果は前例のないものでした。
クラウド依存の教訓
このインシデントは、現代のクラウド アーキテクチャにおける重要な課題を示しています。 単一地域依存AWSのマルチアベイラビリティゾーン設計にもかかわらず、多くのグローバルシステムは地域的に固定されたままであり、特に 米国東部1多数のコントロール プレーンとグローバル API エンドポイントをホストします。
サイバー攻撃は発生しなかったものの、この事件により、単一の基盤サービス（この場合は DNS）における内部構成エラーが、依存するシステム全体に伝播し、世界的な業務に支障をきたす可能性があることが明らかになりました。
RELIANOIDの視点：GSLBによる真の高可用性の実現
At RELIANOIDクラウド環境におけるレジリエンスは、単一のプロバイダー内での冗長性を超える必要があると考えています。 グローバル サーバー ロード バランシング (GSLB) このソリューションは、主要なクラウド プロバイダーまたはリージョンで障害が発生した場合でも継続的な可用性を保証します。
認定条件 RELIANOID GSLBはこのような停電を防ぐのに役立ちます
- マルチクラウドとマルチリージョンの継続性: GSLB は、独立したリージョンまたはプロバイダー (AWS、Azure、GCP、オンプレミスなど) 全体にトラフィックをインテリジェントに分散し、リージョンまたはプロバイダー レベルの障害発生時にもサービスの継続性を確保します。
- リアルタイムのヘルスモニタリング: 継続的なエンドポイント チェックにより、トラフィックを正常なノードに自動的に再ルーティングできるため、DNS または API エンドポイントの障害などのイベント発生時のダウンタイムが最小限に抑えられます。
- インテリジェント DNS ロード バランシング: RELIANOIDの DNS ベースの GSLB は、クライアントのリクエストを最適なデータ センターに動的に解決し、DNS の誤った構成や伝播の遅延に関連するリスクを軽減します。
- シームレスなフェイルオーバーとリカバリ: GSLB は、加重ラウンドロビン、レイテンシベースのルーティング、地理位置情報の認識などのポリシーを使用して、複雑なマルチリージョン展開でもサービスの一貫性を維持し、中断を最小限に抑えます。
より広範な高可用性戦略の一環としてGSLBを実装することで、ビジネスクリティカルなアプリケーションを単一プロバイダーの運用依存から切り離すことができます。問題の原因がDNS解決、ネットワークヘルスチェック、内部API障害のいずれであっても、GSLBは自動フェイルオーバーと継続的なユーザーエクスペリエンスを実現する透過的なメカニズムを提供します。
結論
その 2025年10月のAWS US-EAST-1の停止 これは、最も先進的なクラウドインフラであっても障害が発生する可能性があることを強く示唆しています。真のレジリエンスには、アーキテクチャの独立性、プロアクティブなフェイルオーバーメカニズム、そしてインテリジェントなグローバル負荷分散が必要です。
RELIANOIDの GSLB はこの回復力を実現し、次の混乱がどこで発生しても、組織が稼働時間、信頼性、信用を確保できるように支援します。
関連ブログ
