「AWSで障害が起きているのか、それとも自社側の不具合なのか」をまず切り分けたい——そんな場面で最短の答えを出せるように、この記事はAWS障害を今すぐ確認する方法から整理します。そのうえで、2025年10月20日に起きた大規模障害を最新の実例として原因・影響・復旧を振り返り、過去の障害に共通するパターンと、企業がとるべき備えまでを実務目線でまとめました。
まとめ｜AWS障害はまず「確認」、そのうえで「備え」
- 今すぐ確認：公式のAWS Health Dashboardでサービス状況を、DowndetectorやXでユーザー側の異常報告を確認する。自社アカウント固有の影響はサインイン後のHealth Dashboardで見る。通知の自動化までを組むならAWS Health Dashboardの使い方とEventBridge通知の実装を参照。
- 直近の大障害：2025年10月20日、米国東部（us-east-1）でDynamoDBのDNS障害が発生し、約15時間にわたり世界中のサービスへ波及した。
- 原因の型：単一のDNSの不具合が基盤サービスを止め、そこへ依存する多数のサービスが連鎖停止した。過去の大規模障害もus-east-1に集中している。
- とるべき対策：AWSでも障害は起きる前提で、マルチAZ・マルチリージョン構成、監視による早期検知、us-east-1への過度な依存の見直しを進める。
AWS障害が起きているか今すぐ確認する方法
障害対応の初動でまず必要なのは、原因の切り分けです。次の3ソースを上から順に見れば、「AWS側の障害か／自社側の不具合か」をおおむね判断できます。
AWS Health Dashboard（公式・最優先で見る）
AWSが公式に障害情報を出す一次情報源がAWS Health Dashboardです。全ユーザー共通の公開イベント（Service health）は、サインインなしで各サービス・各リージョンの稼働状況と過去履歴を確認できます。自社のアカウントやリソースに固有の影響（対象のEC2やRDSなど）は、サインイン後の「Your account health」に表示されるため、運用者はこちらも合わせて確認します。復旧の見込みや対応状況もこのダッシュボードで更新されます。
DowndetectorとXによるユーザー側異常の把握
公式ダッシュボードへの反映には数分〜数十分のタイムラグが出ることがあります。ユーザーからの異常報告が急増していないかは、Downdetectorの障害マップや、X（旧Twitter）で「AWS 障害」「AWS 落ちてる」と検索して把握します。国内向けにはリージョン別の稼働情報を機械的に流すアカウント（例：@awsstatusjp_all）もありますが、これらは非公式の集約情報である点に注意し、最終判断は公式ダッシュボードで裏取りしてください。
自社サービスの不調がAWS障害か切り分ける手順
自社サービスが重いとき、原因がAWSとは限りません。次の順で確認すると切り分けが速くなります。
- Health Dashboardで、自社が使うリージョン・サービス（多くはus-east-1やap-northeast-1）に障害イベントが出ていないか。
- DowndetectorやXで、同じサービスの利用者が同時多発的に困っていないか（自社だけなら自社側の可能性が高い）。
- 自社の監視（CloudWatchアラームやAPM）で、エラーがAWSの特定サービス呼び出しに集中していないか。
2025年10月20日のAWS大規模障害で何が起きたか
直近で最も影響が大きかったのが、2025年10月20日の障害です。AWSは公式に「Amazon DynamoDB Service Disruption in the Northern Virginia (US-EAST-1) Region」として報告しました。
発生日時と影響範囲（us-east-1・約15時間）
影響は米国太平洋時間で10月19日23時48分（日本時間10月20日の午後）に始まり、主要な復旧は10月20日14時20分（同）に完了しました。断続的な影響を含めると、正常化までにおよそ15時間を要しています。震源となったのは、AWS最大かつ多くのグローバル機能の制御を担う米国東部（us-east-1）リージョンでした。
影響を受けた主なサービスと国内への波及
基盤サービスであるDynamoDBが停止したことで、EC2・Lambdaなど多数のAWSサービスに波及し、その上で動くWebサービスが世界規模で停止しました。国内外でSNS・決済・ゲーム・スマート家電まで影響が及び、日常利用にも支障が出たのが特徴です。
| 分野 | 影響を受けた例 |
|---|---|
| SNS・コミュニケーション | Snapchat、Reddit ほか |
| ゲーム | Fortnite、Roblox ほか |
| IoT・スマートホーム | Alexa、Ring ほか |
| 金融・決済 | 一部の銀行・決済アプリ |
| AWS基盤 | DynamoDB、EC2、Lambda など |
復旧までのタイムライン
DynamoDBのDNS障害が起点となり、AWSはまずDNS側を復旧させ、続いてDynamoDBへの依存で新規起動が滞っていたEC2などを段階的に回復させました。基盤の回復後も、滞留した処理の消化やキューの正常化に時間がかかり、部分復旧から完全復旧まで数時間の追加を要しています。AWSは米国太平洋時間10月22日に、一連の障害の概要と再発防止策をまとめたページを公開して謝罪しました。
AWS障害の原因｜DNSの競合状態がDynamoDBを止めた仕組み
今回の根本原因は、DynamoDBの自動DNS管理システムに潜んでいた競合状態（レースコンディション）でした。DNSレコードを管理する2つの自動処理（DNS Enactor）が競合し、片方が古いレコードの適用に時間がかかっている間に、もう片方が最新レコードを適用してクリーンアップを開始。遅延していた処理がチェックをすり抜けて古いレコードで上書きした直後に、クリーンアップが古いレコードを削除したため、リージョンのエンドポイントにIPアドレスが1つもない空のDNSレコードが残りました。結果としてDynamoDBへ接続できなくなり、そこに依存する多数のサービスが連鎖的に停止したのです。EC2の新規インスタンス起動がDynamoDBを利用していたことや、内部のネットワーク負荷分散の健全性チェックにも波及したことが、被害を広げました。AWSは対策として、DNSの自動化（DNS Planner／DNS Enactor）を全世界で一時停止し、競合状態を修正したうえで、不正確なDNSプランの適用を防ぐ保護策を追加するとしています。
過去に起きたAWSの大規模障害の一覧
AWSの大規模障害は初めてではありません。過去の主な事例を見ると、いずれもus-east-1（北バージニア）で起き、単一の不具合が基盤サービスを止めて広範囲に波及するという共通のパターンが浮かびます。
| 発生時期 | リージョン | きっかけ | 主な波及 |
|---|---|---|---|
| 2017年2月 | us-east-1 | オペミスでサーバー過剰停止 | S3停止・多数のWebに影響 |
| 2020年11月 | us-east-1 | Kinesisのスレッド上限超過 | Cognito・CloudWatch等へ波及 |
| 2021年9月 | 東京 | ネットワーク機器OSの不具合 | Direct Connectが約6時間停止 |
| 2025年10月 | us-east-1 | DynamoDBのDNS競合状態 | DynamoDB起点で世界規模に波及 |
us-east-1はAWSで最も古く規模が大きいリージョンで、IAMやグローバルサービスの制御機能の一部もここに集約されています。そのため、us-east-1の障害は他リージョンにも間接的に影響が及びやすく、大規模化しやすい構造的な事情があります。
AWS障害に備えて企業がとるべき対策
「AWSなら落ちない」という前提は成り立ちません。クラウドは自社運用より高い可用性を実現しますが、それでも障害はゼロにならない——だからこそ、起きる前提で被害を抑える設計が実務の勘所になります。
単一障害点を避ける構成（マルチAZ・マルチリージョン）
まず、1つのAZやリージョンが落ちてもサービスが継続するよう、重要なシステムはマルチAZを基本とし、事業影響の大きいものはマルチリージョンまで検討します。リージョン間のフェイルオーバーを制御する仕組みとして、Amazon Application Recovery Controller (ARC)のようなサービスを使うと、切り替えの判断と実行を安全に自動化できます。ただしマルチリージョンはコストと運用負荷が増えるため、全システムに一律で適用せず、停止許容時間（RTO/RPO）に応じて対象を絞る判断が現実的です。
CDNのCloudFrontに固有の切り分け手順（レスポンスヘッダの読み方・5xxエラー率の監視・オリジンフェイルオーバー）は、CloudFront障害の確認方法と備えで扱っています。
障害を早く検知する監視の設計
初動を速めるには、AWSの障害を「ユーザーからの問い合わせで知る」状態は避けたい。CloudWatchのアラームでAWSサービス呼び出しのエラー率・レイテンシを監視し、分散トレーシングで「どのAWSサービスで詰まっているか」を可視化しておきます。仕組みはAWS X-RayとCloudWatchの違いや、ダッシュボードのAmazon Managed Grafana、マルチクラウドを横断するTerraformによるDatadog管理などを組み合わせて整えます。
us-east-1への依存とグローバルサービスの罠
過去の大規模障害がus-east-1に集中している以上、us-east-1にワークロードやグローバルサービスの設定を無自覚に寄せていないかは、一度棚卸しする価値があります。主に日本国内向けのサービスであれば、可能な範囲でap-northeast-1（東京）を主軸に据え、us-east-1でしか設定できないグローバル機能に依存する箇所を把握しておくと、いざという時の影響範囲を読みやすくなります。
よくある質問
AWS障害とは何ですか？
AWSが提供するクラウドサービス（EC2・S3・DynamoDBなど）が、一時的に停止・遅延して正常に使えなくなる状態を指します。特定のサービス・リージョンに限られる小規模なものから、2025年10月のように基盤サービスの停止が多数のサービスへ連鎖する大規模なものまで幅があります。
AWS障害が今起きているか、どこで確認できますか？
公式のAWS Health Dashboardが一次情報です。ユーザー側の異常はDowndetectorやXで補完し、自社アカウント固有の影響はサインイン後のHealth Dashboardで確認します。
AWS障害で損害が出た場合、補償はありますか？
AWSの各サービスにはSLA（サービスレベル合意）があり、月間の稼働率が定められた基準を下回った場合にサービスクレジットが提供されます。ただし自動付与ではなく、原則として期限内の申請が必要で、逸失利益などの間接損害は対象外です。適用条件は利用サービスごとに異なるため、公式のSLA文書で確認してください。
AWSの大規模障害はどのくらいの頻度で起きますか？
世界規模に波及するレベルの障害は数年に一度の頻度ですが、特定サービス・リージョンに限られた小規模な障害はより高い頻度で発生します。過去の事例がus-east-1に集中している点をふまえ、頻度の低さに安心せず「起きる前提」で備えるのが実務的です。こうした備えが想定どおり働くかは、AWS Fault Injection Serviceで意図的に障害を起こして平時に検証できます。
