障害情報から、業務への影響と次の確認を判断する
サービス全体の発表と、自社アカウント・構成への影響を照合します。公開の障害発表がないことだけでは、利用中のシステムの正常性を判断できません。
どんな時に使うか
公開ステータスだけでは、自社リソースに影響するすべてのイベントを把握できません。
順に確認して、次の対応を決める
症状と対象をそろえる
業務の症状、発生・最終成功時刻、AWSサービス、リージョンを記録する。時刻はタイムゾーンを添える。
判断すること別地域・別機能の発表を自分の原因と決めつけない。
公開イベントを照合する
稼働状況の一覧から対象サービスへ進み、イベントの影響範囲・更新内容・取得時刻を見る。
判断すること未取得や更新失敗は「障害なし」に読み替えない。
アカウント固有の情報を確認する
AWS Healthのアカウント情報と、対象リソース・予定変更を管理者と確認する。
判断すること公開発表に載らない個別の影響も判断材料にする。
自社側の兆候を合わせる
エラー率・遅延、接続先、直前の変更を照合する。提供元イベントとの時刻の一致だけでは原因を確定しない。
判断すること暫定原因と未確認事項を分け、回避・待機・切戻しを担当者が判断する。
確認の例
合成例:東京リージョンのAPIが10:05 JSTから遅延。公表イベントの開始時刻・対象機能と自社のエラー増加を並べ、アカウント固有情報を追加して影響範囲を絞る。
説明用の合成例です。実際の障害・顧客事例ではありません。
担当者へ渡す記録
業務影響、サービス・地域、時刻、イベントURL、確認時刻、自社ログ、暫定原因と次の更新時刻を残す。認証情報や顧客データは含めない。
根拠となる提供元の資料
資料確認・手順の編集:2026-10-10。当社が整理した確認手順です。