【初心者向け】EC2インスタンスの作成でハマりがちな3つの罠

こんにちは、カスタマーサクセス部の塚下です。

みなさん快適なAWSライフはお過ごしでしょうか。

AWSを代表するサービスのひとつと言えばEC2ですね。 AWSでEC2を使ってサーバーを立てるのは、慣れると数クリックで完了するほど簡単です。

しかし簡単ゆえに思わぬ落とし穴が潜んでいるものです。 特にWindows Serverを扱う際には、Linuxとは少し違う「お作法」があり、知らずにいると思わぬトラブルにハマってしまうことも…

そこで今回は、私が実際にハマった経験をもとに、 WindowsのEC2インスタンスを作成するときに特に気をつけたい3つのポイントを解説したいと思います！

罠①：AMIから復元したWindowsインスタンスにキーペアでログインできない！？

こちらについてはご存じの方も多いかと思います。

バックアップやサーバーの複製で非常に便利な AMI (Amazonマシンイメージ)の作成。既存のインスタンスからAMIを作成し、そこから新しいインスタンスを複製、という操作はよくあると思います。

しかし、ここで一つ大きな問題があります。それは、カスタムAMIから作成したWindowsインスタンスは、元のキーペアや、作成時に指定した新しいキーペアではログインできないという点です。

実際にAMIから復元したWindowsインスタンスにログインするためにキーペアを使ってパスワードを復元しようとすると次のようなメッセージが表示されパスワードの復元が行えません。

なぜログインできないの？

Windows Serverの初期パスワードは、インスタンスの初回起動時にWindows Server 2016以降ではEC2Launch、Windows Server 2012 R2以前ではEC2Configサービスによってランダムに生成され、キーペアで暗号化されます。

しかし、カスタムAMIからインスタンスを起動する場合、元のインスタンスの設定状態がそのまま引き継がれるため、新しいパスワード生成プロセスが実行されません。

そのため、新しいキーペアを指定してもパスワードの暗号化・取得ができず、結果として「パスワードが取得できない → ログインできない」という状況に陥るのです。

どうすればいいの？

• 対策1：Windows 管理者パスワードをリセットする（推奨）
  AWS Systems Manager Session Manager を使える状態であれば、キーペアなしで安全にインスタンスに接続できます。 この状態でAWSのドキュメントを参考にユーザーのパスワードをリセットを実施する事により、パスワードを使ってログインする事ができます。
  Amazon EC2 インスタンスの Windows 管理者パスワードを変更する
  ※ AWS Systems Manager Session Managerを使うには、インスタンスにAmazon SSM Agentがインストールされ、適切なIAMロールが設定されている必要があります。
• 対策2：AMI作成前にパスワードを設定しておく
  AMIを取得する元のインスタンスで、あらかじめユーザーに推測されにくい固定のパスワードを設定しておきましょう。そうすれば、AMIから復元したインスタンスにも同じパスワードでログインできます。
• 対策3：EC2Rescue for Windows Serverを使う
  もしログインできなくなってしまった場合は、「EC2Rescue for Windows Server」というツールを使って、オフラインでパスワードをリセットすることも可能です。 ただし、この手順は大掛かりな復元手順となるためここでは割愛します。

罠②：IPアドレスを引き継ぎたいのにENIをデタッチできない！

こちらはWindowsに限らずEC2インスタンス共通のお話となります。

サーバーを新しく入れ替える際、「IPアドレスは前のサーバーのものをそのまま使いたい」というケースはよくありますよね。

そんなとき、ネットワークインターフェイス（ENI）を古いインスタンスからデタッチして、新しいインスタンスにアタッチすれば簡単！

…と思いきや、プライマリENI（eth0）をデタッチしようとするとエラーが発生し、付け替えができません。

なぜデタッチできないの？

これはAWSの仕様であり、EC2インスタンスでは、プライマリネットワークインターフェイスのデタッチがサポートされていないのです。

ネットワークインターフェイスの概念

各インスタンスにはプライマリネットワークインターフェイスと呼ばれるデフォルトのネットワークインターフェイスがあります。プライマリネットワークインターフェイスをインスタンスからデタッチすることはできません。

どうすればいいの？

IPアドレスを維持したままインスタンスを入れ替えるには、少し複雑な手順が必要です。以下はIPアドレスの引き継ぎ手順の一例です。

1. 間違って完全に削除してしまわないように、古いインスタンスの画面で「インスタンスの設定」>「終了保護を変更」を有効にします。
2. 古いインスタンスからAMIを作成します。
3. 先ほど設定した「終了保護」を無効にし、古いインスタンスを「終了（Terminate）」します。
   • インスタンスが終了処理に入ることで、そのインスタンスに割り当てられていたプライベートIPアドレスが解放され、他のインスタンスが使用できる状態になります。
4. 先ほど作成したAMIから新しいインスタンスを起動します。この時、ネットワーク設定で古いインスタンスと全く同じプライベートIPアドレスを指定します。
5. 古いインスタンスにElastic IP addressが紐付いていた場合は新しいインスタンスの起動が完了したら、Elastic IP addressを手動で新しいインスタンスに付け替えます。

この手順により、安全にIPアドレスを引き継ぐことができます。

罠③：カスタムAMIで復元したインスタンスのホスト名がUserDataで変更されない！

インスタンス起動時にスクリプトを実行できる UserData は非常に便利です。ホスト名を自動で設定したいと考え、以下のようなスクリプトをUserDataに記述することがあります。

<powershell>
Rename-Computer -NewName "NewServerName" -Force -Restart
</powershell>

しかし、カスタムAMIから起動したインスタンスの場合、このUserDataが実行されず、ホスト名が変わりません。

実際にサーバーにログインしたり、セッションマネージャーなどで確認するとホスト名が変更されていないことが分かります。

> hostname
OldServerName

なぜ反映されないの？

これも一つ目の罠と同じで、UserDataの実行は基本的にインスタンスの「初回起動時」に行われるからです。

AMIから起動したインスタンスでは、EC2の初期化プロセス（EC2LaunchやEC2Config）が再度実行されない設定になっているため、UserDataも無視されてしまうのです。

ユーザーデータの実行

デフォルトでは、すべての AWS Windows AMI で初回起動時のユーザーデータの実行が有効になっています。次にインスタンスが再起動されたときにユーザーデータスクリプトが実行されるように指定できます。また、インスタンスが再起動するたびにユーザーデータスクリプトが実行されるように指定することもできます。

どうすればいいの？

• 対策1：手動で変更する インスタンス起動後にログインし、手動でホスト名を変更するのが最もシンプルです。
• 対策2：AWS Systems Manager Run Commandを使う AWS Systems Manager Run Command を使えば、起動後のインスタンスに対してリモートでPowerShellコマンドを実行できます。ホスト名変更のコマンドをここから実行するのがスマートな方法です。
• 対策3：SysprepでAMIを一般化する（上級者向け） AMIを作成する前にSysprepというツールでOSを「一般化」しておくと、そのAMIから起動したインスタンスは初回起動扱いとなり、UserDataが実行されるようになります。ただし、インスタンスの設定は初期化されてしまう上に手順が少し複雑になるため、まずはAWS Systems Manager Run Commandなどを試すのが良いでしょう。

まとめ

いかがでしたか？今回はEC2のWindowsインスタンスを中心に初心者がハマりがちな3つの罠について解説しました。

• AMIからの復元時はキーペアに頼らず、SSMや事前パスワード設定でログインする
• IPアドレスの引き継ぎはENIのデタッチではなく、インスタンスの終了と再作成を行う
• カスタムAMIからの起動ではUserDataが効かないので、AWS Systems Manager Run Commandなどを活用する

一見すると些細なことですが、知らないと原因調査に多くの時間を溶かしてしまいます。AWSのちょっとした「クセ」を理解して、快適なクラウドライフを送りましょう！