--- title: "AWS障害の確認方法と原因・対策｜2025年10月の大規模障害から学ぶ実務ガイド" url: "https://www.issoh.co.jp/tech/details/9464/" published: 2025-10-24 updated: 2026-09-27 categories: ["AWS"] publisher: "株式会社一創" --- # AWS障害の確認方法と原因・対策｜2025年10月の大規模障害から学ぶ実務ガイド 「AWSで障害が起きているのか、それとも自社側の不具合なのか」をまず切り分けたい——そんな場面で最短の答えを出せるように、この記事はAWS障害を**今すぐ確認する方法**から整理します。そのうえで、2025年10月20日に起きた大規模障害を最新の実例として原因・影響・復旧を振り返り、過去の障害に共通するパターンと、企業がとるべき備えまでを実務目線でまとめました。 ## まとめ｜AWS障害はまず「確認」、そのうえで「備え」 - **今すぐ確認**：公式の[AWS Health Dashboard](https://health.aws.amazon.com/health/status)でサービス状況を、[Downdetector](https://downdetector.jp/shougai/aws-amazon-web-services/)やXでユーザー側の異常報告を確認する。自社アカウント固有の影響はサインイン後のHealth Dashboardで見る。通知の自動化までを組むなら[AWS Health Dashboardの使い方とEventBridge通知の実装](https://www.issoh.co.jp/tech/details/17732/)を参照。 - **直近の大障害**：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](https://health.aws.amazon.com/health/status)です。全ユーザー共通の公開イベント（Service health）は、サインインなしで各サービス・各リージョンの稼働状況と過去履歴を確認できます。自社のアカウントやリソースに固有の影響（対象のEC2やRDSなど）は、サインイン後の「Your account health」に表示されるため、運用者はこちらも合わせて確認します。復旧の見込みや対応状況もこのダッシュボードで更新されます。 ### DowndetectorとXによるユーザー側異常の把握 公式ダッシュボードへの反映には数分〜数十分のタイムラグが出ることがあります。ユーザーからの異常報告が急増していないかは、[Downdetector](https://downdetector.jp/shougai/aws-amazon-web-services/)の障害マップや、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)](https://www.issoh.co.jp/tech/details/4611/)のようなサービスを使うと、切り替えの判断と実行を安全に自動化できます。ただしマルチリージョンはコストと運用負荷が増えるため、全システムに一律で適用せず、停止許容時間（RTO/RPO）に応じて対象を絞る判断が現実的です。 CDNのCloudFrontに固有の切り分け手順（レスポンスヘッダの読み方・5xxエラー率の監視・オリジンフェイルオーバー）は、[CloudFront障害の確認方法と備え](https://www.issoh.co.jp/tech/details/17826/)で扱っています。 ### 障害を早く検知する監視の設計 初動を速めるには、AWSの障害を「ユーザーからの問い合わせで知る」状態は避けたい。CloudWatchのアラームでAWSサービス呼び出しのエラー率・レイテンシを監視し、分散トレーシングで「どのAWSサービスで詰まっているか」を可視化しておきます。仕組みは[AWS X-RayとCloudWatchの違い](https://www.issoh.co.jp/tech/details/6812/)や、ダッシュボードの[Amazon Managed Grafana](https://www.issoh.co.jp/tech/details/4540/)、マルチクラウドを横断する[TerraformによるDatadog管理](https://www.issoh.co.jp/tech/details/10105/)などを組み合わせて整えます。 ### 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](https://health.aws.amazon.com/health/status)が一次情報です。ユーザー側の異常はDowndetectorやXで補完し、自社アカウント固有の影響はサインイン後のHealth Dashboardで確認します。 ### AWS障害で損害が出た場合、補償はありますか？ AWSの各サービスにはSLA（サービスレベル合意）があり、月間の稼働率が定められた基準を下回った場合にサービスクレジットが提供されます。ただし自動付与ではなく、原則として期限内の申請が必要で、逸失利益などの間接損害は対象外です。適用条件は利用サービスごとに異なるため、公式のSLA文書で確認してください。 ### AWSの大規模障害はどのくらいの頻度で起きますか？ 世界規模に波及するレベルの障害は数年に一度の頻度ですが、特定サービス・リージョンに限られた小規模な障害はより高い頻度で発生します。過去の事例がus-east-1に集中している点をふまえ、頻度の低さに安心せず「起きる前提」で備えるのが実務的です。こうした備えが想定どおり働くかは、[AWS Fault Injection Service](https://www.issoh.co.jp/tech/details/15636/)で意図的に障害を起こして平時に検証できます。 ## 関連記事 - [Amazon Application Recovery Controller (ARC) とは？概要と目的](https://www.issoh.co.jp/tech/details/4611/) - [AWS X-Rayとは｜CloudWatchとの違いとOpenTelemetry移行後の使い方](https://www.issoh.co.jp/tech/details/6812/) - [Amazon Managed Grafanaとは？機能・料金・データソースと始め方](https://www.issoh.co.jp/tech/details/4540/) - [TerraformでDatadogを管理する方法｜Provider設定・モニター・AWSインテグレーション](https://www.issoh.co.jp/tech/details/10105/) --- 出典: [AWS障害の確認方法と原因・対策｜2025年10月の大規模障害から学ぶ実務ガイド]()（株式会社一創）