AWS運用でストレージ (EBS) を救う方法

AWS(クラウド)のサーバーは基本的にリモート接続して操作することが前提となっています。
どこからでもアクセスできるのはとてもメリットが大きいですが、うっかり設定を変えてしまったり、パスワード等の接続に必要な情報を忘れてしまった場合、接続できなくなってしまいます。
オンプレミス環境のサーバーであればサーバールームに行って直接対応することもできるかもしれませんが、AWS ではそのようなことができません。
AWS ではそのような状況になったサーバー(ストレージ)を復旧させるツール「EC2Rescue」があります。
今回は EC2 の Windows Server を対象に復旧方法をご紹介します。
目次
AWS運用 ストレージを検証用に設定変更
今回は Windows Server ですので、RDP(リモートデスクトッププロトコル)接続ができなくなるような状況を再現します。

[システムのプロパティ] → [リモートデスクトップ] → [このコンピューターへのリモート接続を許可しない] を選択して適用します。

適用直後からRDP接続が切断され、以降復旧まで接続できなくなりました。
AWS運用 ストレージを復旧
RDP接続できないインスタンスを復旧するためには2つ、前提条件があります。
- EC2Rescue を実行するための作業用の EC2 インスタンス(Windows Server)を同じアベイラビリティゾーンに作成する必要がある
- 復旧対象の EC2 インスタンスを停止する必要がある
※パブリックIPが自動割当の場合、変更されるので注意
復旧時にスムーズに対応できるよう、作業用 EC2 インスタンスを作成するためのサブネットを決めておいたり、パブリックIPが変動すると問題となる場合は Elastic IP を利用しておくと良いかもしれません。
それでは実際に復旧していきます。

まずは作業用 EC2 インスタンスにRDP接続し、EC2Rescue をダウンロードします。
ブラウザ等からダウンロードすることも可能ですが、PowerShell で下記コマンドを実行することで直接デスクトップにダウンロードできます。
Invoke-WebRequest https://s3.amazonaws.com/ec2rescue/windows/EC2Rescue_latest.zip -OutFile $env:USERPROFILE\Desktop\EC2Rescue_latest.zip
ZIPファイルを解答すると複数ファイルがありますが、今回は「EC2Rescue.exe」のみ使用します。

次に EBS ボリュームをデタッチするため、復旧対象の EC2 インスタンスを停止します。

復旧対象にアタッチされていた EBS ボリュームをデタッチします。
※最後に再びこのインスタンスにアタッチし直すので、デバイス名(画像の場合 /dev/sda1 )をメモしておきます。

デタッチした EBS ボリュームを作業用インスタンスにアタッチします。
※この際デバイス名はデフォルトで問題ありません。

[サーバーマネージャー] → [ファイルサービスと記憶域サービス] → [ボリューム] → [ディスク] からアタッチした EBS ボリュームが存在することを確認します。
気持ち的にはボリュームをオンラインにしたくなりますが、「オフライン」の状態で復旧作業する必要があります。

ZIPの中にある「EC2Rescue.exe」を実行し [I Agree] を選択します

[Next] を選択します

[Offline instance] を選択します。
Current instance は起動中の EC2 インスタンスに対して調査をするための選択肢なので、今回は使用しません。

復旧対象のストレージを選択して [Next]

再確認画面なのでそのまま続行します。

[Diagnose and Rescue] を選択します。
今回はRDP接続できなくなった原因が明確なのでそのまま復旧していますが、原因不明な場合は Capture logs で状況確認することをおすすめします。

次の画面では診断結果が表示されます。
Windows Firewall 関係全てと RDP で問題が起きていることがわかります。
確認できたら [Next] を選択

どの項目を修正するか選択します。
Windows Firewall と RDP の4項目にチェックを入れて [Next] を選択します
EC2Launch は Administrator ユーザのパスワードリセットです。
パスワード忘れの場合はこの項目を選択しますが、今回はパスワードは忘れていないので選択していません。

意図した項目を選択できているか確認して [Rescue] を選択します

最終確認なのでそのまま続行します。

全て緑のマークになっていれば問題なく修正できているので [Next] を選択します

完了画面なので [Finish] を選択して終了です。
この画面で audit ログが確認できるので、必要であれば残しておくとより良いかと思います。
OS上での作業はこれで全てです。

AWS コンソールへ戻り、EC2Rescue で修正した EBS ボリュームをデタッチします。

最後に元々アタッチされていた EC2 インスタンスにアタッチして復旧作業は完了です。
AWS運用 ストレージ復旧に関する便利機能
今回はRDP接続に関する復旧を試してみましたが、EC2Rescue には様々な機能があります。
一部ですが、今回対応した方法(Offline instance)であれば以下のような内容の検出・対応ができます。
- RealTimeisUniversal レジストリキーが有効かどうか検出、不備があれば対応
- RDPサービスが有効か検出、起動してなければ起動
- 管理者(Administrator)パスワードを生成
- OSが確認できている最後のブート可能状態でインスタンスを起動
- 「 \Windows\System32\config\RegBack 」からレジストリを復元
- DHCP が有効か検出、不備があれば対応
AWS運用 ストレージ復旧まとめ
全ての状況で復旧できるかわかりませんが、簡単な手順で絶望的な状況を回避できる可能性があるので避難訓練的に一度試してみるといいと思いました。
今回ご紹介したストレージの復旧をはじめ、ターン・アンド・フロンティアでは、AWSをご利用されているお客様のサーバーを24時間365日監視し、必要に応じて復旧させる運用も任せていただいています。
「AWSにしたのにサーバーに何かあれば結局対応しなければならないので大変だ…」
とお嘆きの方も、本来の業務に集中できるようにサポートできますので、ご興味のある方はお気軽にご相談ください。

元記事発行日: 2021年09月23日、最終更新日: 2024年02月28日