AWSの本番環境で障害が起きたときの初動対応チェックリスト

AWS本番環境で突然アラートが鳴り響く。「何から確認すればいいか迷って、貴重な初動5分を無駄にした」という経験は、SREであれば誰でも一度は通る道です。

初動対応で最も大切なのは「速さ」ではなく「順序の正しさ」です。闇雲にログを掘り始めても根本原因には近づきません。まず影響範囲を把握し、ユーザー影響を止めることを優先する——このフレームを体に染み込ませておくことが、障害対応スキルの本質です。

この記事では、AWS本番環境で障害が発生した際の初動対応を、時系列のチェックリスト形式でまとめます。

この記事でわかること
– 障害発生から30分間にやるべきことの全体像
– フェーズ別（0〜5分、5〜15分、15〜30分）のチェックリスト
– AWSサービス別（CloudWatch・ALB・ECS/EC2・RDS）の確認ポイント
– 初動でやってはいけない行動

対象読者: AWSを使った本番環境の運用に関わるエンジニア。CloudWatchの基本操作、ECS/EC2/RDSの概念を理解していることを前提とします。

障害対応の基本思想：「影響範囲の特定」が最優先

チェックリストの前に、一つだけ原則を確認します。

障害対応で最初にやるべきことは「根本原因の特定」ではありません。「ユーザーへの影響範囲の把握と、暫定的な影響の遮断」 です。

根本原因を追うのは、ユーザー影響を止めた後です。この順序が逆になると、調査に時間をかけている間にもユーザーへのダメージが積み上がり続けます。

障害対応のフェーズは大きく4つです：

フェーズ1：検知・初期確認（0〜5分）

障害と気づいた最初の5分は、「何が壊れているか」の全体像を掴む時間です。細部に入り込まず、俯瞰することを意識してください。

✅ チェックリスト

• [ ] アラートの内容を確認する
• CloudWatchアラームの名前・メトリクス・閾値を確認

• 「いつから」アラートが鳴り始めたかを把握

• [ ] 影響しているサービスの数を把握する

• 1サービスだけか？複数サービスか？

• 複数なら「共通のコンポーネント（DB、ALB、VPCなど）」を疑う

• [ ] ユーザー影響の有無を確認する

• ステータスページ・外形監視（CloudWatch Synthetics等）でユーザー視点の死活を確認

• サポートチャンネルや問い合わせの急増がないか確認

• [ ] インシデントをSlack/チャットに宣言する

• 「今何が起きているか」「誰が対応しているか」を明示

• 例：「#incident-channel 本番環境でAPI 5xxが急増中。toma調査中。」

• [ ] コマンダー（インシデント指揮者）を決める

• 一人が複数作業を並列で担うと情報が散乱する
• 調査役・情報集約役・対外連絡役を分けることが理想

現場Tips: 最初の5分でSlackに状況を投げることを習慣化すると、「あのとき何をしていたか」のタイムラインが後のポストモーテムで非常に役立ちます。

フェーズ2：影響範囲の確定（5〜15分）

「だいたい何が壊れているか」がわかったら、次は数値で影響を可視化します。この段階で正確な影響範囲を数値化できると、暫定対応の判断が速くなります。

✅ チェックリスト

• [ ] エラー率・レイテンシを時系列で確認する
• CloudWatch Metricsで過去1時間・24時間のグラフを確認

• 「いつから」「どのくらいの割合で」エラーが増えたかを把握

• [ ] ALB/API Gatewayのアクセスログを確認する

• ステータスコード別のリクエスト数（4xx/5xxの割合）

• 特定のエンドポイントや地域に集中していないか

• [ ] ECS/EC2のリソース状況を確認する

• CPU使用率・メモリ使用率の急騰

• タスクの再起動（ECS）やインスタンスの異常終了がないか

• [ ] RDS/Aurora の状態を確認する

• DBコネクション数の異常増加
• Replication Lagがないか（Auroraリードレプリカ使用時）

• フェイルオーバーが発生していないか

• [ ] 最近のデプロイ・変更作業を確認する

• 直近30分〜2時間以内にデプロイやインフラ変更がなかったか

• 変更がある場合は「変更前後でメトリクスが変化した時刻」と一致するか確認

• [ ] 影響ユーザー数の概算を出す

• CloudWatch Logsで5xx件数、またはセッション数を把握
• エスカレーションの判断基準（例：1000ユーザー超で管理者へ報告）を満たすか確認

フェーズ3：暫定対応と意思決定（15〜30分）

影響範囲が把握できたら、暫定対応を実行します。「完全に直す」のではなく「影響を止める」ことが目標です。

✅ チェックリスト

• [ ] 暫定対応の選択肢を洗い出す
• ロールバック（直近デプロイが原因の場合）
• スケールアウト（リソース不足が原因の場合）
• 切り離し（障害のあるコンポーネントをトラフィックから除外）

• メンテナンスページの表示（全面停止が必要な場合）

• [ ] ロールバックの実行判断をする

• 直近デプロイが原因の場合、ロールバックが最速の回復手段
• ロールバック手順が整備されているか確認してから実行

• データスキーマ変更を含む場合はロールバックが困難な場合あり→慎重に判断

• [ ] スケールアウトを検討する

• ECS Auto ScalingまたはEC2 Auto Scalingが機能しているか確認
• 必要に応じて手動でタスク数・インスタンス数を増やす

• ただしDB接続数の上限に注意（スケールアウトがDBをボトルネックにする場合あり）

• [ ] CloudWatch Logsでエラーログを絞り込む

• Logs Insightsで5xx・Exception・Errorのパターンを抽出

• スタックトレースや「原因となる1行」を特定する

• [ ] 暫定対応の実施をSlackに記録する

• 「何を」「いつ」「誰が」行ったかを残す

• 複数人で対応している場合は「誰が今どの作業をしているか」を明示

• [ ] 改善傾向の確認

• 暫定対応後、エラー率・レイテンシが改善方向に向かっているかを数値で確認
• 改善しない場合は別の原因を疑って切り分けをやり直す

AWSサービス別：確認ポイント早見表

障害の原因はサービスによって確認すべき場所が異なります。AWSサービスごとの確認ポイントをまとめます。

CloudWatch

ALB（Application Load Balancer）

ECS（Elastic Container Service）

RDS / Aurora

初動でやってはいけないこと

チェックリストの「やること」と同じくらい重要なのが「やってはいけないこと」です。以下は現場でよく見られるアンチパターンです。

❌ 1. 原因が確定する前に変更を加える

「これが原因だと思う」という仮説段階で、本番環境に変更を入れるのは危険です。変更が状況を悪化させる可能性があり、後から「変更前後で何が変わったか」の追跡も困難になります。

原因を特定してから変更を入れる、または「確認のための変更」と「修正のための変更」を明確に分けてください。

❌ 2. 一人で黙って作業を続ける

孤独に調査を続けると、行き詰まったときに時間を浪費します。5分ごとにSlackに状況を投げる習慣をつけると、チームメンバーが別の視点から気づくきっかけになります。

❌ 3. ログを全件読もうとする

大量のログを上から読み始めると時間がかかりすぎます。CloudWatch Logs InsightsやAthena（S3ログ）を使い、エラーパターンで絞り込んでから確認してください。

-- Logs InsightsでECSコンテナの5xxエラーを絞り込む例
fields @timestamp, @message
| filter @message like /ERROR|Exception|5\d\d/
| sort @timestamp desc
| limit 50

❌ 4. アラートを止めることを最初の行為にする

「とりあえずアラートをサイレンスしよう」とする行動は問題の先送りです。アラートはユーザー影響のシグナルです。ユーザー影響が止まってからアラートを止めるのが正しい順序です。

❌ 5. 状況が改善したと思ってすぐに解散する

エラー率が下がってきたからといってすぐにインシデント解除するのは早計です。「暫定対応で下がっただけ」「他の場所に問題が移っただけ」という可能性があります。少なくとも15〜30分は安定状態が続いているか確認してから解散しましょう。

復旧後のアクション：次の障害を防ぐために

障害が復旧したら、その日のうちに以下を記録します。

• [ ] タイムラインを文書化する

• 「何時に何が起きて、何時に何をした」を5分刻みで記録

• [ ] 暫定対応と根本原因を区別して記録する

• 暫定対応：「とりあえずスケールアウトした」

• 根本原因：「新機能のN+1クエリがDBを圧迫した」

• [ ] ポストモーテムのドラフトを作成する

• 記憶が鮮明なうちに書くことが鉄則

• Blamelessな文化を意識し、「誰が悪いか」ではなく「何が起きたか」を書く

• [ ] アクションアイテムをチケット化する

• 「次回同じ障害を防ぐための具体的な改善タスク」をJiraやLinear等に登録
• 担当者・期限・優先度を設定する

まとめ

AWSの本番環境で障害が起きたときの初動対応を、時系列チェックリストとしてまとめました。

障害対応は「慌てず、順序どおりに」が基本です。このチェックリストをRunbookとして整備しておくことで、次回の障害時に迷わず初動を動けるようになります。

AWS・SRE実務をもっと深く学ぶなら

この記事で紹介した CloudWatch Logs Insights・ECS・RDS の監視設定・ポストモーテムの書き方・オンコール設計など、SRE実務に必要なAWS技術をハンズオン形式で体系的に学べるコースを用意しています。

現場で使えるレベルを目指したい方はぜひチェックしてみてください。

👉 【SRE実践】AWSで学ぶ監視・可観測性・障害対応（CloudWatch完全ガイド）