はじめに
AWS を触り始めたばかりの頃にやらかした初歩的なミスをまとめたアドベントカレンダー、題して「AWS初歩ミス図鑑」の 7 日目です。
今回はAMI 作成時に sysprep を忘れサーバーにログインができなくなった話を書いていきます。
やっていたこと
社内の開発環境で使用していた Windows のインスタンス内にあるソフトウェアをアップデートし、その状態でAmazon Machine Image (AMI)を作成することで、最新のソフトウェアがインストールされた状態のインスタンスをお手軽に起動できるようにしたい！ という要望があり、作業を行っていました。
当時 AMI 作成は Linux インスタンスで何度かやったことがあったため、公式の手順を参考にしながらも「まあやったことあるしそんなに大きなミスはしないでしょう…」と高を括りまくっておりました。Windows と Linux という大きな違いには目を向けようともせず…。
結果
タイトル通り、Windows であるにもかかわらず sysprep することなく再起動を行ってしまったため、作成した AMI から新しいインスタンスを起動したところ、既存の Administrator ユーザーの認証情報で RDP からサーバーにログインできないという事態が発生しました。
失敗するわけがない、と驕り高ぶっていただけに、認証情報が取得できないうえ見たことのないエラーが表示されたときは夢かなと思いました。
幸い、検証環境であったことに加え、AMI のもととなったインスタンスを消さずに残していたため、作業を最初からやり直すことで解決ができました。
何を考えていたのか
Windows と Linux をほとんど同じだと考えていた、という知識の薄さは抜かせていただき、そもそもsysprepの存在を知りませんでした。（ドキュメントをよく読めば書いてあったのに…。）
Windows の AMI を作成する際は sysprep というツールを実行してからイメージを作成する必要があります。とても簡単に言うと、Windows を別の環境（今回の場合だと、別のインスタンス）で動作させるために必要な諸々の準備や初期設定を行ってくれるツールです。
sysprep を実行しないと、元のインスタンスの SID がそのまま複製されてしまい、新しいインスタンスで認証に問題が発生します。今回の問題はこちらが原因です。
まとめ
Windows の AMI を作成する際は、sysprep の実行が必須です。説得力皆無ですが、ぜったいに忘れてはいけません。
- Windows の AMI 作成前には必ず sysprep を実行する
- Linux と Windows では AMI 作成の手順が異なることを理解する
- いくら難解でも、公式ドキュメントはしつこいくらいに読む
以上が、今回のミスから得た学びです。
sysprepせずに停止してしまったインスタンスから作成した AMI をもとに作成したインスタンスを、さらにsysprepで停止してもう一度起動すればリカバリーできる、という噂もありますが、試したことはありません…。