これまで何度か Windows インスタンスを作っては壊しを繰り返してきたが、その中で時々ライセンス認証が通らなくなるという謎の現象に悩まされてきていた。このたび、ようやく再現手順を特定してサポートに問合せることができ、やっと疑問が氷解した。
今回の原因は、以下のところに書いてあるとのこと。
インスタンスのルートデバイスボリュームのスナップショットがある場合、AWS マネジメントコンソールまたはコマンドラインを使用して、そのスナップショットから AMI を作成できます。
Important
Red Hat Enterprise Linux (RHEL) や SUSE Linux Enterprise Server (SLES) などの一部の Linux ディストリビューションは、AMI に関連付けられた Amazon EC2 の billingProduct コードを使用して、パッケージの更新に関するサブスクリプションのステータスを確認します。EBS スナップショットから AMI を作成すると、この請求コードが保持されないため、このような AMI から起動したそれ以降のインスタンスはパッケージ更新インフラストラクチャに接続できません。
同様に、スナップショットから Windows AMI を作成することはできますが、AMI からインスタンスを正常に起動することができません。
一般的には、AWS はスナップショットから手動で AMI を作成することをお勧めします。
Windows AMI の作成、または正常に機能する AMI 請求コードを保持する必要がある Linux オペレーティングシステム用の AMI の作成についての詳細は、「インスタンスからの Linux AMI の作成」を参照してください。
「一般的には、AWS はスナップショットから手動で AMI を作成することをお勧めします。」とのところがちょっと文脈的にどうかと思うが、原文でもこうなっていた。ここは記述の順序をもう少し考えてほしいところ。
要は、「一般的な手順としては、AMI はスナップショットから作成するのが AWS としてのオススメ。ただし、Windows のように個別にライセンス認証が必要な OS については、スナップショットを経由すると請求コードの情報が失われるので、そこから派生したインスタンスではライセンス認証が通らなくなる。なので、インスタンスから直接『イメージの作成』で AMI を作成してね。」ということらしい。
Windows だけでなく、有償の Linux ディストロでも同じようになるらしいです。皆さん気をつけてください。