【注意】Office付きのAMIから作成したEC2のバックアップには制約があります

記事タイトルとURLをコピーする

さとうです。

EC2にOfficeをインストールして使いたいケースで、AWSのSPLAの利用制限によりOffice付きのAMIからのデプロイを検討される方が多いのではないかと思います。

このEC2のバックアップ運用には大きな制約があるので、まとめておきたいと思います。

blog.serverworks.co.jp

結論

License Managerの仕様上、Office付きのAMIのバックアップ実行前にSysprepによる一般化が必須となります。

Sysprepされていない状態で取得されたバックアップからリストアされたEC2は、ライセンスのアクティベーション処理に失敗してしまうためLicense Managerが自動的に終了させる仕様になっています。

Office付きAMIの仕組み

制約を理解する前提として、Office付きAMIのデプロイの仕組みをまとめます。

デプロイの前提条件

以下の記事の「事前準備」にあるように、License ManagerでOfficeのライセンス管理を行う都合上、デプロイにあたりAWS Managed Microsoft ADが必須(セルフホストのADは不可)であるなど様々な制約が発生します。

blog.serverworks.co.jp

記事より引用

ライセンス管理の仕組み

上記の環境においてOffice付きのAMIからEC2をデプロイすると、以下のような流れでライセンスのアクティベーションが行われます。

なお、公式ドキュメントには断片的な記載しかないのでこちらは検証に基づき確認した内容です。正確さを保証するものではないのでその点ご注意ください。

  • ①: License ManagerがEC2に UserSubscriptions : AWSLicenseManager タグを付与する
  • ②: (タグをトリガーに?)SSM Run Commandで2つのPowerShellスクリプトが順次実行される

    (1) License Managerに関連付けたManaged ADのドメインに参加するスクリプト (2) Officeのライセンスのアクティベーション処理を行うスクリプト

  • ③-1: 2つのスクリプトが正常に終了後、License Managerからユーザーの関連付けが可能になる

  • ③-2: スクリプトの実行に失敗した場合はLicense ManagerがEC2を終了させる

引用した図に書き足し

問題になるポイント

問題なのは、Office付きのAMIをベースにしたカスタムAMIを使用する場合はSysprepを行うことが前提となっていることです。

公式ドキュメントには以下のような記載があります。

License Manager でのユーザーベースのサブスクリプションのトラブルシューティング - AWS License Manager

ユーザーベースのサブスクリプション製品 AMI をベースイメージとして使用するカスタム AMI からインスタンスを起動する場合は、カスタム AMI で Sysprep ステップを実行して、起動時に一意のコンピュータ名を確保する必要があります。/generalize で Sysprep を実行する前に、マシンがドメインから削除されていることを確認してください。

「起動時に一意のコンピュータ名を確保する必要があります。」 とあるので、これは裏を返すと「バックアップからのリストアのような一意の識別子を維持した状態でのデプロイを想定していない」という意味になります。

なので取得したEBS SnapshotからEC2をリストアしてもスクリプトの実行に失敗してしまい、License ManagerはEC2を終了させようとします。

恐らくADへのコンピューターオブジェクトの登録やOfficeのアクティベーション処理における重複や不整合を回避するための措置かと思います。

※SysprepはWORKGROUP端末であることが実行の前提なので、実行時にドメイン離脱が行われる仕様になっています。

Sysprep (システム準備) の概要 | Microsoft Learn

解決策

上記の仕様に基づくと、以下いずれかまたは両方の対策が必要になります。

①: アプリ領域専用のEBSを作成し、OS領域のEBSをステートレスにする

OS領域とは別のEBSを作成し、そちらのEBSに対してバックアップを取得する方法です。

リストア時には新規で作成したEC2に対して、上記のEBSをアタッチした上でOS上でマウントします。

ドライブの利用目的がファイルの共有などであればこの方法で十分かもしれませんが、OS領域に保持される環境変数やレジストリなどは保持されないのでアプリのインストール領域として使用する場合には注意する必要があります。

②: Sysprepしてゴールデンイメージを作成する

定期的にSysprepを実行した上でゴールデンイメージを作成し、EC2を再デプロイするという方法です。

この方法ではユーザープロファイルやイベントログが都度初期化されてしまうことが想定されるので、上記の①の方法と合わせて別領域に保持するなどの措置が必要となります。

(補足): 終了保護について

デプロイ時にEC2の終了保護を有効化すると、License ManagerはEC2を終了させることができないようです。

ただしこの方法でEC2を無理やり残存させた上で解決を試みても、事前にSysprepが必要な旨がドキュメントに明記載されている以上はAWSのサポート対象外になることが想定されますので、終了保護で対処することは避けるようにしてください。

まとめ

EC2はバックアップをセットで考えることが殆どかと思いますので、上記の制約を事前に把握した上で使用するようにしましょう。

佐藤 航太郎(執筆記事の一覧)

エンタープライズクラウド部 クラウドモダナイズ課
2025年1月入社で何でも試したがりの雑食系です。