サイトにアクセスできない、APIエラーが急増した——そんなとき、AWS障害か自社環境の問題か、すぐに判断できるでしょうか。「どこを確認すればいいのか分からない」と焦った経験をお持ちの方も多いのではないでしょうか。

本記事では、AWS障害の確認先から切り分け、初動対応、復旧判断、再発防止までを体系的にご紹介します。

AWS障害を疑ったら最初に確認する2つの場所

ECサイトで注文処理に障害発生！最初に確認すべき場所は？
ある月曜日の朝9時過ぎ、自社ECサイトへの問い合わせが急増しました。「カートに商品を入れられない」「決済画面が表示されない」という声が複数の顧客から届いています。 情シス担当者はまず、社内のモニタリングツールでエラー率の急上昇を確認しました。しかし、直近でアプリケーションのデプロイは行っていません。「AWS側で何か起きているのでは」——そう考えたとき、最初に確認すべき場所はどこでしょうか。

AWS障害を疑ったら、まず以下の2点を確認しましょう。

その１：AWS全体で障害が発生していないか
その２：自社アカウントに影響が出ていないか

この2つは確認する目的が異なります。まずAWS全体の障害有無を確認し、その後に自社環境への影響を確認するのがおすすめです。

その1：AWS全体の障害を確認する（Service health）

AWS Health Dashboardの「Service health」では、AWS全体で発生している障害や機能低下の情報を確認できます。

例えば、東京リージョンのAmazon RDSやAmazon EC2で障害が発生している場合は、ここに影響範囲や発生状況が表示されます。

システムに問題が発生したら、まずService healthを確認し、AWS側で障害が起きていないかを確認しましょう。

その2：自社環境への影響を確認する（Account health）

AWS全体で障害が発生していなくても、自社のAWSアカウントや利用中のリソースだけに影響が出ていることがあります。

その場合は、AWS Health Dashboardの「Account health」を確認します。

Account healthでは、以下のような情報を確認できます。

• 利用中リソースへの影響
• AWSからのメンテナンス通知
• アカウント固有のイベント

Service healthに問題が表示されていなくても、Account healthに重要な通知が掲載されている場合があるため、必ずあわせて確認しましょう。

AWS障害とは何か｜影響範囲とよくある原因

AWS障害と一言で言っても、影響範囲や原因はさまざまです。ここを理解しておくと、初動での判断がぶれにくくなります。

リージョン障害・AZ障害・サービス障害の違いを理解する

AWSの障害は、大きく3つのレベルに分けられます。

• リージョン障害：東京リージョンなど、特定リージョン全体に影響が及ぶ障害
• AZ障害：アベイラビリティゾーン（データセンターの物理的な単位）単位での障害
• サービス障害：特定のAWSサービス（S3やRDSなど）に限定した障害

マルチAZ構成を取っている場合、AZ障害の影響は限定的になりますが、リージョン障害やサービス障害は広範囲に影響することがあります。例えば、特定のAZでネットワーク機器の不具合が発生した場合、そのAZに配置されたリソースのみが影響を受け、他のAZへフェイルオーバーできていれば、ユーザーへの影響を最小限に抑えられます。

一方で、S3やRoute 53のようにリージョン全体、あるいは複数リージョンにまたがるサービスで障害が起きた場合は、冗長化構成を組んでいても影響を避けにくいことがあります。自社が利用しているサービスがどのレベルの障害に弱いのかを、平常時から把握しておくことが望ましいでしょう。

自社側の要因との違いと責任の分かれ目を知る

AWS障害だと思っていた事象が、実は自社側の設定変更や依存サービスの障害だったというケースは少なくありません。AWSでは「責任共有モデル」という考え方があり、AWSがインフラ部分の運用を担う一方、OS以上の設定やアプリケーションの構成は利用者側の責任範囲です。

ただし、Amazon RDSのようなマネージドサービスでは、ゲストOSのパッチ適用や基盤の運用までAWS側が担うなど、責任範囲はサービスの形態によって異なります。

そのため、障害発生時は「AWS側の問題か、自社側の問題か」を機械的に切り分ける視点が欠かせません。次章のチェックリストが、この切り分けの助けになります。

AWS障害か自社設定ミスかを切り分ける方法

障害情報がない場合は何を確認する？
先述のECサイトの例では、Service healthで障害情報を確認できたため比較的早く判断できました。しかし、実際にはService healthに何も表示されていないのに、システムが正常に動かないというケースも少なくありません。 ここでは、Service healthに情報がない場合を想定し、どう切り分けを進めるかを見ていきます。

AWS障害と自社環境の問題を切り分けるには、複数の観点から症状を確認する必要があります。以下のチェックリストに沿って、上から順に確認していきましょう。

ログとメトリクスから症状と変更履歴を確認する

まず確認したいのが、Amazon CloudWatchとAWS CloudTrailです。CloudWatchはリソースの稼働状況を数値で可視化する監視サービスで、CPU使用率やエラー数の急変を検知できます。CloudTrailはAWSアカウント内の操作履歴を記録するサービスで、「誰が」「いつ」「何を」変更したかを追跡できます。

例えば、あるチームでは「S3へのアクセスエラーが急増した」という事象に対し、CloudTrailを確認したところ、前日の夜間にバケットポリシーが変更されていたことが判明しました。Service healthには何も表示されていなかったため、CloudTrailの変更履歴が唯一の手がかりとなったケースです。

確認手順：

1. CloudWatchで異常なメトリクスがないか確認する
   1. CPU使用率、メモリ使用率、ディスクI/Oの急変を確認
   1. エラー数（5xx系レスポンスなど）の増加時刻を特定
   1. アラームの発火履歴を時系列で確認
2. CloudTrailで直近の変更履歴を確認する
   1. 障害発生時刻の前後30分〜1時間の操作ログを確認
   1. セキュリティグループ、IAMポリシー、ネットワーク設定の変更有無を確認
   1. デプロイやCI/CDパイプラインの実行履歴と突き合わせる

判断基準：

• 変更履歴と障害発生時刻が一致する → 自社側要因の可能性が高い
• 変更履歴がなく、Service healthにも障害情報がある → AWS側要因の可能性が高い
• どちらにも該当しない → 依存サービスや外部要因を疑う

ネットワークと認証の経路を確認する

次に確認すべきは、ネットワークと認証の経路です。VPC（AWS上に作る仮想的なプライベートネットワーク）の設定変更、DNSの名前解決異常、IAM（AWSリソースへのアクセス権限を管理する仕組み）やSTS（一時的な認証情報を発行する仕組み）のトラブルは、見た目上「AWS障害」のように見えることがあります。

確認手順：

1. ネットワーク経路の確認
   1. セキュリティグループ・NACL（ネットワークACL）のインバウンド／アウトバウンドルールを確認
   1. ルートテーブルの変更有無を確認
   1. VPCピアリングやTransit Gatewayを利用している場合、経路上の疎通を確認
2. DNS解決の確認
   1. nslookup や dig コマンドで対象ドメインの名前解決を確認
   1. Route 53のヘルスチェックのステータスを確認
   1. TTLが長すぎて古い情報を参照していないか確認
3. 認証・権限エラーの確認
   1. CloudTrailで AccessDenied エラーの発生有無を確認
   1. IAMロールやポリシーの直近の変更履歴を確認
   1. STSトークンの有効期限切れがないか確認

判断基準：

• 特定の送信元IPやポートだけ通信できない → セキュリティグループ・NACLの設定変更を疑う
• 社内から名前解決できるが応答が遅い・古い → DNSのTTLやヘルスチェック設定を疑う
• 特定の操作だけ権限エラーになる → IAMポリシーの変更を疑う

依存サービス別に確認すべきポイント（RDS／S3／ELB／Route 53）

自社システムが依存しているAWSサービスごとに、確認ポイントは異なります。

RDSの確認ポイント：

• フェイルオーバーが発生していないか（イベント通知・CloudWatchのメトリクスで確認）
• 接続数が上限に達していないか（DatabaseConnections メトリクスを確認）
• レプリカの遅延が発生していないか

S3の確認ポイント：

• 対象リージョンのService healthステータス
• リクエストのレスポンスコード（403、503など）の傾向
• バケットポリシーやIAMポリシーの直近の変更有無

ELB（ALB／NLB）の確認ポイント：

• ターゲットグループのヘルスチェック結果（Healthy／Unhealthyの比率）
• リスナールールの変更有無
• アクセスログでの5xxエラーの発生状況

Route 53の確認ポイント：

• ヘルスチェックのステータスと、フェイルオーバー設定の動作状況
• TTLの設定値と、実際の切り替わりまでの時間
• ルーティングポリシー（加重・レイテンシーベースなど）の設定変更有無

これらを個別に確認することで、AWS障害と自社設定のどちらが原因かをより正確に見極められます。

初動対応｜被害拡大を防ぐ優先順位

障害の原因が判明する前でも、被害拡大を防ぐための初動対応は並行して進める必要があります。優先順位を明確にしておくことで、混乱した状況でも落ち着いて対応できます。

状況整理と影響範囲の特定

初動でまず整理すべきは、「いつから」「どのサービスで」「どの範囲のユーザーに」影響が出ているかです。以下の項目を、できるだけ早い段階で埋めていきましょう。

状況整理シートの項目例：

• 発生時刻（気づいた時刻と、実際の発生時刻の両方）
• 影響を受けているサービス・機能
• 影響範囲（全ユーザーか、一部ユーザーか、特定リージョンのみか）
• 現在の症状（アクセス不可、レスポンス遅延、エラー発生など）
• Service health／account healthの該当有無

時系列と影響範囲を整理することで、以降の対応判断がスムーズになります。

社内共有とエスカレーションの基準

状況が整理できたら、社内共有用のテンプレートに沿って関係者に連絡します。あらかじめ「どの規模の障害でエスカレーションするか」の基準を決めておくと、初動対応の判断が遅れません。

影響レベル	基準	連絡先
レベル1（軽微）	一部機能に軽度な遅延、影響ユーザー数が少数	担当チーム内で共有
レベル2（中程度）	主要機能の一部が利用不可、影響ユーザー数が中規模	管理者・関連部署へエスカレーション
レベル3（重大）	サービス全体が停止、または顧客影響が大規模	経営層・顧客窓口まで即時連絡

社内共有時に含めるべき情報：

• 障害の第一報は「事実」と「対応状況」を分けて伝える
• 「現在調査中」であることも含めて、分かっている範囲を正直に共有する
• 続報を出すタイミング（30分後、1時間後など）をあらかじめ伝えておく

トラフィック制御・フェイルオーバー・証跡確保の優先順位

影響を最小化するために、トラフィック制御や機能制限、メンテナンス表示への切り替えを検討します。

トラフィック制御の選択肢：

1. メンテナンス表示への切り替え：影響を受けている機能のみアクセス制限し、他機能は継続稼働させる
2. トラフィックの迂回：Route 53のフェイルオーバー設定やALBのターゲットグループ切り替えで、正常な環境へ迂回させる
3. 機能の一時停止：負荷の高い機能を一時的に停止し、コア機能を優先的に維持する

冗長構成があれば、フェイルオーバーの実行も選択肢に入ります。フェイルオーバーを実行する際は、データの整合性（特にRDSのようなステートフルなサービス）に注意が必要です。

証跡確保で保全すべきもの：

• CloudTrailの操作ログ（該当時間帯のエクスポート）
• CloudWatchのメトリクス・ログ（スクリーンショットやエクスポート）
• 障害対応中のチャットログや対応記録

同時に、後の原因分析に使う証跡はできるだけ早い段階で保全しておきましょう。時間が経つほどログが失われたり、状況の再現が難しくなったりするためです。

復旧を早めるための判断材料

初動対応が済んだら、復旧に向けた優先順位を判断するフェーズに移ります。実際の現場では「どのシステムから戻すか」で意見が割れることも少なくありません。あらかじめ判断基準を整理しておくことで、こうした場面でも迷わず意思決定できます。

復旧の優先順位をどう決めるか

復旧の判断では、システム全体を一度に戻す「全面復旧」と、重要な機能から段階的に戻す「部分復旧」のどちらを取るかを検討します。この判断基準になるのがRTO（目標復旧時間）とRPO（目標復旧時点、どの時点までのデータ復旧を目指すか）です。

例えば、ECサイトを運営している場合、決済機能はRTO1時間・RPO数分以内といった厳しい基準を設定し、商品レビュー機能のような付随的な機能はRTO半日程度でも許容する、という形で機能ごとに濃淡をつけるのが一般的です。事前にRTO／RPOを重要システムごとに定めておくと、障害発生時に迷わず優先順位をつけられます。

部分復旧の判断で確認したいポイント：

• 顧客への影響が大きい機能（決済、ログイン認証など）から優先的に復旧する
• 復旧の難易度（設定変更のみで戻せるか、データ復元が必要かなど）を加味する
• 一部機能を停止したまま運用を継続できるか、業務影響を確認する

AWSサポートに問い合わせる前に整理すべき情報

自社での切り分けが難しい場合は、AWS Supportへの問い合わせも選択肢になります。問い合わせ前に、以下の情報を整理しておくと、AWS側とのやり取りがスムーズに進みます。

問い合わせ前に準備する情報：

• 発生時刻とタイムゾーン（UTCと日本時間の両方があると親切）
• 影響を受けているリージョン・サービス・リソースID
• Service health／account healthで確認した内容
• CloudTrailで確認した直近の変更履歴の有無
• すでに実施した切り分け・対応の内容

これらをあらかじめテンプレート化しておくと、緊急時でも抜け漏れなく情報を伝えられます。また、サポートプランによって問い合わせ時の対応時間や優先度が異なるため、自社が契約しているサポートプランの内容を事前に確認しておくことも大切です。重大な障害が疑われる場合は、電話やチャットなど即時性の高い手段で連絡することも検討しましょう。

復旧後に必ず行う事後対応

システムが復旧したあとも、再発防止につなげるための事後対応が欠かせません。ここでの整理が甘いと、同じ障害が形を変えて再発するリスクが残ります。

タイムライン作成と根本原因の整理

まず、障害発生から復旧までの時系列（タイムライン）を作成します。いつ何を確認し、どの対応を行ったかを記録することで、根本原因の分析がしやすくなります。

時刻	事象・対応	状態
09:05	顧客からの問い合わせ増加を検知	調査開始
09:12	Service healthでRDS障害情報を確認	原因の見当がつく
09:20	社内へ第一報を共有	エスカレーション実施
09:45	フェイルオーバー完了を確認	復旧作業中
10:05	全機能の復旧を確認	復旧完了

根本原因の整理では、「なぜその事象が起きたのか」を1段階だけでなく、複数段階掘り下げる（なぜなぜ分析）ことで、表面的な原因だけでなく構造的な課題も見えてきます。

顧客・社内向け報告に必要な情報

タイムラインが整理できたら、顧客や社内向けの報告書を作成します。報告には、以下の要素を含めると説明責任を果たしやすくなります。

報告書に含めるべき項目：

• 発生時刻・復旧時刻
• 影響範囲（対象サービス・対象ユーザー数の目安）
• 原因（判明している範囲。断定できない場合は「調査中」と明記する）
• 実施した対応の概要
• 再発防止に向けた今後の方針

顧客向け報告では、専門用語を避け、影響と対応を簡潔に伝えることが信頼維持につながります。一方、社内向け報告では、技術的な詳細（CloudTrailで確認した変更内容など）も含めて共有し、今後の改善に活かせる形にしておきます。

コスト影響と残課題の確認

障害対応の過程で発生したコスト（一時的なリソース増強など）や、対応の中で見えた残課題も整理しておきましょう。例えば、フェイルオーバーのために一時的にインスタンスサイズを上げた場合は、復旧後に元の構成へ戻す作業も忘れずに行う必要があります。

なお、利用料金の補償やサービスクレジットについては、後述のよくある質問で詳しく解説しています。

再発防止策｜設計・運用・監視をどう見直すか

事後対応が終わったら、同様の障害を繰り返さないための見直しに進みます。ここで得られた気づきを放置せず、具体的なアクションに落とし込むことが重要です。

単一障害点をなくす冗長化の考え方

システムの中に、故障すると全体が止まってしまう箇所（単一障害点、SPOF）がないかを見直します。具体的には、同一リージョン内の複数のAZにリソースを分散する「マルチAZ構成」や、リージョンをまたいで冗長化する「マルチリージョン構成」が代表的な対策です。

冗長化を進める際は、以下のようなステップで段階的に取り組むと着手しやすくなります。

1. 現状把握：どのリソースがシングルAZ・単一構成になっているかを棚卸しする
2. 優先順位付け：影響が大きいシステムから、冗長化の対象を絞り込む
3. 段階的な冗長化：まずはデータベースのマルチAZ化から着手し、次にコンピューティング層の冗長化に進める
4. 検証：冗長化した構成が実際にフェイルオーバーするか、疑似的に障害を起こして確認する

監視と変更管理をどう見直すか

再発防止には、監視体制と変更管理の見直しも重要です。監視面では、システムの健全性を示す指標（SLI）と、その指標に対する目標値（SLO）を定めることで、異常の早期検知につながります。

例えば、「可用性99.9%を目標にする」という場合、月間の許容ダウンタイムは約43分となります。この数値を基準に、CloudWatchのアラーム閾値を設定しておくと、目標から外れそうな兆候を早期に捉えられます。

変更管理の面では、インフラの構成をコード化して管理する「IaC（Infrastructure as Code）」を導入することで、変更履歴の追跡やロールバックがしやすくなります。権限変更についても、承認プロセスを設けておくと、意図しない変更による障害を防ぎやすくなります。

監視・変更管理の見直しポイント：

• 主要な指標（応答時間、エラー率、可用性など）にSLI／SLOを設定する
• インフラの変更はコード化し、変更履歴をバージョン管理する
• 本番環境への変更には承認フローを設け、変更内容を記録に残す

これらの取り組みは、一度にすべてを導入しようとすると現場の負担が大きくなりがちです。まずは影響範囲の大きいシステムから、監視指標の設定とIaC化を優先して進め、徐々に対象を広げていくアプローチが現実的です。

GameDayとBCP／DR訓練で備えを検証する

設計や運用を見直したら、実際に機能するかを検証する場も必要です。AWSでは、障害を意図的に発生させて対応を訓練する「GameDay」という取り組みがあります。また、事業継続計画（BCP）や災害復旧計画（DR）の手順も、定期的に訓練しておくことで、実際の障害時に落ち着いて対応できます。

社内で始めやすい小規模な訓練としては、まず特定のインスタンスを意図的に停止させ、フェイルオーバーが想定通り機能するかを確認するところから始めるとよいでしょう。慣れてきたら、複数のコンポーネントを同時に停止させるなど、シナリオを徐々に複雑にしていくことで、実践的な対応力を養えます。

よくあるAWS障害ケース別の対処例

代表的な症状ごとに、確認ポイントと対処の方向性を整理しました。いずれのケースも、まずService health／account healthでの確認と、CloudTrailでの変更履歴確認を並行して行うことが切り分けの近道です。

症状	確認ポイント	対処
EC2に到達できない	セキュリティグループ・NACLの設定、SSM接続の状況	該当設定の見直し、SSM経由での復旧対応
RDSに接続できない	フェイルオーバーの発生状況、接続数の上限、DNSの解決状況	フェイルオーバー完了の確認、接続プールの見直し
S3でエラー・遅延が発生	対象リージョンの状況、リトライ処理の設計	リトライ設計の見直し、データ整合性の確認
DNSが正しく切り替わらない	TTL設定、ヘルスチェックの状況	TTLの短縮、ヘルスチェック設定の見直し

いずれのケースも、まずは「AWS側の障害か、自社設定の問題か」を切り分けたうえで対処に進むことが基本です。特にDNSの切り替わりについては、TTLの値によって反映まで時間差が生じる点に注意が必要です。障害発生時にTTLが長いままだと、設定を修正しても利用者側のキャッシュが残り、復旧が遅れて見えることがあります。平常時からTTLを短めに設定しておくと、いざというときの切り替えがスムーズになります。

AWS障害でよくある質問

Q.AWS障害時に利用料金の補償やサービスクレジットはあるか

A.AWSでは、サービスごとに定められたSLA（サービス品質保証）の基準を下回った場合、利用者からの申請に基づきサービスクレジットが提供される仕組みがあります。適用条件や申請方法はサービスごとに異なるため、AWS公式のSLAページで詳細を確認することをおすすめします。

Q.東京リージョンなど特定リージョンの障害はどう確認するか

A.特定リージョンの障害状況は、AWS Health DashboardのService healthページでリージョンを指定して確認できます。東京リージョンなど、自社が利用しているリージョンを普段からブックマークしておくと、障害発生時に素早く確認できます。

Q.障害通知を自動で受け取るにはどうすればよいか

A.Amazon EventBridgeを活用すると、AWS Healthのイベントをトリガーにして、SlackやEmail、社内システムへの自動通知を設定できます。また、AWS User Notificationsを使うことで、複数の通知先をまとめて管理することも可能です。障害発生を待つのではなく、通知を仕組み化しておくことで、初動対応のスピードが変わってきます。

まとめ

AWS障害への対応では、障害発生時の初動だけでなく、原因特定や再発防止までを含めた運用体制の整備が重要です。まずは、自社システムの監視体制や冗長化設計、障害発生時の対応フローが適切に整備されているかを確認しましょう。

テクノプロでは、AWS環境の障害対応をはじめ、監視体制の構築、BCP／DR対策、冗長化設計、運用改善まで幅広く支援しています。AWS運用に不安や課題がある場合は、お気軽にご相談ください。