EC2障害対応の進め方｜初動から自動復旧の判断基準

EC2障害対応は、応答なし・ログイン不可・一時停止といった事象が起きた瞬間に、技術調査と事業判断を同時に進める必要があります。初動の切り分けや証跡保全を曖昧にしたまま復旧操作を進めると、原因究明が難しくなるだけでなく、説明責任や再発防止の設計が後手に回ります。特に障害宣言後の15分・30分で何を共有するかが決まっていないと、復旧作業が問い合わせ対応に押し流されがちです。以下では、EC2障害時の判断材料として初動の切り分けと復旧・自動復旧の設計ポイントを示します。

EC2障害対応の前提を整理

事業影響とRTO・RPOを先に置く

EC2障害では、技術調査に入る前に重要業務の特定と、当該業務の目標復旧時間（RTO）・目標復旧時点（RPO）を先に置いて判断します。参照資料でも、金融機関の決済業務のように処理の時限性がある業務では、RTOが事業継続マネジメント上の意思決定ファクターになるとされています。例えば「1か月以内に復旧しなければならない重要業務」のように期限が明確な場合、バックアップ方式（例：リアルタイムでのオフサイトバックアップ等）を含め、復旧戦略そのものが先に決まるべきです。

EC2障害の原因を4類型で見る

EC2の障害は、闇雲に復旧操作をするほど二次被害が起きやすいため、初動の切り分けを4類型で固定しておくと実務が安定します。加えて、参照資料が挙げるインシデント例（脆弱性悪用の不正侵入、ssh/ftp/telnetへのブルートフォース成功、キーロガー機能を持つマルウェア等）のように、「障害に見える事象」がセキュリティインシデントの入口である場合もあるため、技術原因の分類と並行して「不正利用の可能性」も同時に疑う設計が重要です。

EC2障害の初動対応

状況整理と関係者連絡を分ける

障害時は、状況整理（技術・証跡確保）と連絡（社内外調整）を分業します。同一人物が両方を抱えると、復旧判断が遅れるだけでなく、参照資料が指摘するように初期対応を誤ると原因究明ができなくなる、また取引先から証拠隠滅を疑われるリスクも上がります。特にセキュリティインシデントが疑われる局面では、復旧を急ぐほど「ログが上書きされる」「変更の履歴が追えない」といった実務上の損失が起こり得ます。

障害宣言から15分・30分で誰が何を報告するかを決める

障害宣言後は、15分と30分の報告を定型化しておくと、復旧の邪魔になる問い合わせを抑えられます。参照資料でも、インシデント対応では組織内の情報共有、および取引先などへの報告と情報の公表といった論点が並行して発生する前提で章立てされており、技術対応と同じくらい「報告設計」が重要であることが読み取れます。

EC2インスタンスの切り分け

ステータスチェックの意味を読む

ステータスチェックは、一次切り分けの最短ルートです。システムステータスチェックは主にAWS基盤側（ホスト、基盤ネットワーク等）の異常を示し、利用者がOS内部を操作しても改善しない局面があります。インスタンスステータスチェックは主にOS内部（起動不良、ドライバ/設定、リソース枯渇、ファイルシステム等）を示し、利用者側の調査・是正が必要になります。

また、単なる障害に見えても、参照資料が例示するsshへのブルートフォース攻撃のような不正アクセスが並行している場合、到達不能が「設定ミス」ではなく「遮断・遠断（アクセス制御）」の結果である可能性もあります。ステータスチェックの結果は、復旧操作の前に「何が壊れているのか」を短時間で言語化するための基礎情報として扱います。

直前変更がある障害でCloudTrail・IaC差分をどこまで追うか

直前まで正常だったのに障害化した場合、原因の多くは「変更」です。参照資料でも、攻撃者が窃取した認証情報を不正利用してクラウドサービス設定を変更するリスクが指摘されており、障害調査では意図しない設定変更の有無を一次論点として扱うのが安全です。

EC2復旧とバックアップ判断

ログイン可能時の調査項目を絞る

ログインできる場合でも、調査を広げすぎると復旧判断が遅れます。運用手順としては、リソース・ネットワーク・主要ログに絞り、RTOに間に合わないと判断したら「その場の復旧」から「作り直し/切替」に方針転換します。

加えて、セキュリティ観点では「ログを取れていないと変更箇所の特定・復旧ができない」ため、参照資料が示すように平時から監査・ログ取得を準備しておくことが前提になります。

ログイン不可時はネットワークから見る

ログイン不可は、まず「経路」を疑います。セキュリティグループ、ルートテーブル、NACL、踏み台/VPNなどの前提経路を、変更履歴と合わせて確認します。参照資料にも、システム管理者が把握していない外部接続経路（例：VPN）が存在し得る旨があり、想定外経路は痕跡の有無に関わらず即時遮断が望ましいとされています。障害対応でも同様に、把握していない経路は「復旧の盲点」になりやすいです。

再起動と停止・起動の差で選ぶ

再起動と停止・起動は同じ「再稼働」に見えても意味が違います。再起動は原則として同一ホスト上でOSを立ち上げ直す操作であり、ホスト障害には効きにくいです。停止・起動は、結果として別ホストに載り替わることで改善するケースがあります。

一方で、参照資料が挙げるインシデント（不正侵入等）が疑われる場合、拙速な再起動や停止・起動は証跡（ログ）の欠落や上書きにつながり得ます。復旧を急ぐ局面でも、最低限「EBSスナップショット等で保全してから操作する」判断を組み込みます。

EBS・AMIで復旧を進める

EBS保全後に代替インスタンスを起動

復旧不能・長期化が見えたら、まずEBSを保全してから代替インスタンスへ移ります。参照資料でも、初期対応を誤ると原因究明が困難になり得る点や、外部から証拠隠滅を疑われ得る点が指摘されており、技術的にも説明責任の観点でも「保全→復旧」の順序が安全です。

復旧・作り直し・ロールバックを選ぶ

選択肢は「復旧」「作り直し」「ロールバック」です。RTO/RPOに照らして、どれが最も事業影響を抑えるかで選びます。参照資料にある例のように、重要業務で「1か月以内に復旧」といった期限が置かれるなら、その期限を満たす手段（調査に時間を掛けない、切替を先行する等）を優先します。

バックアップ方針とリストア手順を決める

バックアップは「取る」だけでは足りず、リストア（戻す）手順が実行可能であることが必要です。参照資料でも、ログや監査設定が事前準備として重要（デフォルトでは取得無効でログが取れていない可能性がある）とされており、復旧時に必要な情報が欠ける状態は避けるべきです。

AWSの自動復旧と監視設計

Auto Recoveryの条件と限界を知る

Auto Recovery（簡易自動復旧）は、主にAWS基盤側の障害（物理ホスト故障、電源喪失、物理的なネットワーク断など）で効果を発揮します。一方で、参照資料が挙げるような不正侵入や、OS内部の設定ミス・メモリ枯渇など「インスタンス内要因」には効かないことがあります。

また、復旧を自動化するほど「意図しない設定変更」を見落としやすくなるため、参照資料の復旧チェック観点（監査ログ取得、高権限アカウントの利用状況の定期監視、2要素認証の導入等）も含め、復旧と監視をセットで設計します。

CloudWatch監視と自動復旧を設計する

CloudWatchは、検知と復旧の自動化に有効ですが、設計次第で「復旧はしたが、原因が追えない」状態になります。参照資料が述べるとおり、変更箇所の特定・復旧のためには事前に監査設定が必要で、デフォルトではログ取得が無効で「取れていない可能性」があります。自動復旧を強化するほど、監査・ログ設計も同じ優先度で整備します。

Auto Scalingで単一障害点を減らす

単一障害点（1台死んだら止まる）を減らすにはAuto Scalingが有効です。加えて、参照資料で強調される「設定上の不備を作らない」という観点からも、手作業の復旧を減らし、テンプレート化した構成で置換する設計は、人的ミスの低減に直結します。

運用体制と耐障害性を整える

マルチAZとリージョン設計を考える

マルチAZは「ゾーン障害」までの耐性を上げ、リージョン冗長は「広域障害」まで視野に入れた設計です。重要業務の復旧期限が厳しい場合（参照資料の例：1か月以内に復旧しなければならない重要業務など）、復旧手段を運用で頑張るのではなく、構成で担保する必要が出ます。

手順書・権限・サポート活用を整える

復旧の成否は、技術力だけでなく「手順」「権限」「外部支援」で決まります。参照資料が示す復旧の観点では、(1) ログオン可能なIPや機器の制限、(3) 監査ログ取得、(4) 2要素認証などが挙げられており、障害対応でも「誰が何をできるか」と「後から追えるか」を平時に作っておくことが重要です。

よくある質問

EC2インスタンスが応答しない場合、まず何を確認すべきですか？

まずステータスチェックを確認し、「AWS基盤側か、インスタンス内部か」を分けます。加えて、参照資料が挙げるようにssh等へのブルートフォース成功による不正侵入が起点になることもあるため、「障害」だけでなく「侵害の可能性」を同時に疑い、直前の設定変更やログの有無も確認します。

EC2 Auto Recoveryを有効にできないインスタンスはありますか？

あります。実装上の制約により、構成・インスタンスタイプ等によってAuto Recoveryが前提どおりに機能しない場合があります。そのため、参照資料が示す「クラウドの問題はサービス側ではなく利用者側の設定不備で起こり得る」という前提に立ち、機能可否を思い込みで判断せず、対象環境ごとに要件確認が必要です。

また、Auto Recoveryでカバーできない場合は、CloudWatchアラーム等で検知・通知・復旧アクションを設計し、復旧と同時に「監査ログが残る運用」も合わせて整備します。

CloudWatchだけで自動復旧まで完結させることは可能でしょうか？

可能ですが、前提として「復旧させる」だけでなく「後から追える」ことが必要です。参照資料では、変更箇所の特定・復旧のために事前の監査設定が重要で、デフォルトでは取得無効でログが取れていない可能性がある点が指摘されています。自動復旧の設計時点で、アラーム発報時の記録（対象、時刻、実行アクション、結果）と監査ログの取得範囲をセットで整備します。

障害調査でAWSサポートへ問い合わせるのはいつですか？

初動（ステータスチェック確認、到達性、直前変更の確認、可能な範囲のログ確認）を行っても原因が絞れず、特にAWS基盤側が疑われる場合に早期に問い合わせます。参照資料が指摘するように、初期対応を外すと原因究明が困難になるため、問い合わせ時は「発生時刻」「影響範囲」「対象」「ここまでに実施した操作と結果」を時系列で整理し、調査の前提を揃えます。

EC2障害対応への対応で次にすべきこと

EC2障害対応は、RTO/RPOを起点に復旧方針を決め、原因を4類型で切り分けたうえで、証跡保全と復旧操作の順序を崩さないことが要点です。初動は「状況整理」と「関係者連絡」を分け、障害宣言後の15分・30分の定型報告で、影響範囲と暫定方針を継続的に更新できる形にしておくと運用が安定します。復旧手段は再起動／停止・起動、EBS・AMIを使った代替起動、ロールバックをRTO/RPOに照らして選び、侵害の可能性がある局面では先にEBSスナップショット等で保全します。自動復旧を強化するほど、監査・操作ログや直前変更の追跡（CloudTrail/IaC差分）を同じ優先度で整備し、「復旧はしたが原因が追えない」状態を避けることが重要です。個別環境の制約（Auto Recovery可否、権限設計、重要業務の期限など）が判断に影響するため、運用・セキュリティ・経営判断の責任者を交え、平時の手順書と監視設計からすり合わせます。

Baseconnect株式会社
サイト運営会社

本メディアは、「企業が経営リスクを正しく知り、素早く動けるように」という想いから、Baseconnect株式会社が運営しています。

当社は、日本最大級の法人データベース「Musubu」において国内1200万件超の企業情報を掲げ、企業の変化の兆しを捉える情報基盤を整備しています。

加えて、与信管理・コンプライアンスチェック・法人確認を支援する「Riskdog」では、年間20億件のリスク情報をAI処理、日々4000以上のニュース媒体を自動取得、1.8億件のデータベース等を活用し、取引先の倒産・不正等の兆候の早期把握を支援しています。

運営会社情報ページへ