RDS SALとOfficeライセンスをAWS License Managerで管理する上での注意点

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

こんにちは、スマホの着信音がナイトライダーのCS2課畑野です。 昨今のAIブームによりK.I.T.T.のようにクールな人工知能が登場するのを待ちわびています。

さて今回はAWS License ManagerでRDS SALとOfficeライセンスを管理する上での注意点をまとめてみました。 2025年10月よりAWSのパートナー企業などが独自のSPLAライセンスでMicrosoft製品をAWS上で利用できなくなったことに伴うライセンス管理方法の1つとしてご案内します。 AWS上でRDS SALやOfficeライセンスを利用する際の候補になるかと思います。

構成

構成図例

ライセンスはRDS SALとMicrosoft Office LTSC Professional Plus 2021を利用します。 Active Directoryドメイン例は下記の表の通りです。

ドメイン名 用途
hatano.local セルフマネージドAD(EC2)、一般ユーザーが所属するドメイン
office.local マネージドAD(AWSのDirectory Service)、Office EC2用ドメイン

詰まったポイントと回避策

構成はまとまりましたが実際に構築していく上で登録するActive Directoryドメインや許可する通信要件の理解が必要でした。

特にAWS License Managerを設定するときに作成されるENIは自動でVPCデフォルトのセキュリティグループが割り当てられるため、環境によってはインバウンド/アウトバウンドのルールが何もない状態で通信がまったく通らない可能性があります。 対象のENIは説明欄に『AWS created network interface for LicenseManager d-xxx』のような表記のものです。初期構築時はセキュリティグループがdefaultです。

Officeライセンスを利用する場合のActive Directoryドメイン

Officeを利用する場合、AWS上でOfficeライセンスを含むAMIからEC2を起動する必要があり、制約としてマネージドADのドメイン参加が必須となります。*1

「重複した請求が発生する可能性があります」という怖い注釈
Officeライセンスを利用する場合、AWS License Managerに登録するActive DirectoryはマネージドADになります。 セルフマネージドADは登録せず、Active Directoryの機能を使用して、マネージドADと相互信頼関係を結びます。 ライセンスの2重請求を避けるためこのような構成となります。

信頼関係を結ぶ際、マネージドADの信頼関係の条件付きフォワーダーでセルフマネージドADのDNSサーバIPアドレスを設定します。 セルフマネージドAD側も同様にはDNSマネージャーで条件付きフォワーダーでマネージドADのドメイン名とDNSサーバIPアドレスを指定します。 これでお互いのドメインの名前解決ができるようになり、信頼関係を相互に結べるようになります。

セキュリティグループ

参考として、許可が必要なセキュリティグループを以下にまとめました。 実際の設計は通信要件に沿って、許可する通信元を適切にご指定下さい。

対象 インバウンドルール アウトバウンドルール 構成図のセキュリティグループNo.
マネージドADのENI タイプ: 自動作成(AD関連通信を許可), ソース: VPC CIDR タイプ: すべてのトラフィック, ソース: 0.0.0.0/0 Sg1
セルフマネージドADのENI タイプ: すべて, ソース: マネージドADのセキュリティグループ タイプ: すべてのトラフィック, ソース: 0.0.0.0/0 Sg2
License ManagerのENI(RdsSalEni) タイプ:自動作成(AD関連通信を許可), ソース:0.0.0.0/0 タイプ: すべてのトラフィック, ソース: 0.0.0.0/0 Sg3
License ManagerのENI タイプ:すべて, ソース: VPC CIDR*2 タイプ: すべてのトラフィック, ソース: 0.0.0.0/0 Sg4
License ManagerのVPCエンドポイント タイプ: TCP/1688, ソース: VPC CIDR タイプ: すべてのトラフィック, ソース: 0.0.0.0/0 Sg5

Officeライセンスを含むAMIからEC2の起動時のマネージドADのドメイン名前解決

Officeライセンスを含むAMIからEC2を起動する場合、ドメイン結合ディレクトリを指定出来ませんでした。 起動時に自動的にドメイン参加処理が実行されるのですが2つポイントがあります。

  1. マネージドADのドメインの名前解決はVPC内DNSサーバで行なえないこと
  2. マネージドADのAdminユーザー*3のパスワードにシングルクォーテーションを含めると、Officeライセンスを含むEC2の起動に失敗し、インスタンスが自動終了する

1の解決策として、Route 53 Resolver アウトバウンドエンドポイントを作成し、マネージドADドメインの名前解決を行えるようにしました。 VPCのDHCPオプションセットでマネージドADのDNSサーバを指定する方法もありますが、VPC全体の名前解決への影響が大きいためこの方法としました。 他にはUserDataの処理でhostsファイルにマネージドADの名前解決を仕込んでおくアイデアも考えられますが、まだ試せていません。

2の原因は推測となりますが、EC2起動後のRDS SAL登録処理でRunCommandからPowershellを実行し、Adminユーザーのパスワード(Secret Managerのシークレットを参照します)を展開する際に パスワード内文字列のシングルクォートが、意図しない引数の分割で構文エラーが発生するためと考えられます。結果、EC2は正常に起動出来ず、強制的に終了します。

Office EC2用のユーザー

Office EC2起動後、Adminユーザー以外にユーザーを登録してRDP接続する場合、マネージドADでユーザーを作成する必要があります。

マネージドADの仕様上、管理者ユーザーをDomain Adminsグループにユーザーを登録出来ないため、AWS Delegated Administratorsを指定するとDomain Admins相当の権限を付与できるかと思います。*4

RDS SALユーザー

AWS License ManagerでRDS SALを発行する場合、ユーザーはActive Directoryドメインに所属する必要があります。 ローカルユーザーに対してライセンスを発行出来ないのでご注意下さい。

RDS SALの一括登録

GUIとCLI (aws license-manager-user-subscriptions start-product-subscription)での登録が可能です。 ただし、いずれもAPIのスロットリングが発生します。

CLIの場合、 StartProductSubscription API が実行され、ThrottlingExceptionが発生しますが、しきい値は公開されていません。*5

GUIの場合、最大20ユーザーを一括登録可能ですが、500ユーザー程度を登録する場合、頻繁に登録失敗が発生したためしきい値は低いと考えられます。 期末期初等で大量に登録や解除する場合はバッチ処理にするのが無難そうです。

費用削減

Office EC2起動後は、インスタンスが1台であることと、費用削減のため、OSが参照するDNSサーバをマネージドADのIPアドレスに変更し、Route 53 Resolver アウトバウンドエンドポイントを削除することとしました。*6

課金条件

RDS SALを解除する場合は、先にActive Directoryからユーザーを削除してから解除しないと最大60日間課金が続きます。タイミングによっては2~3か月課金されることになります。*7

9月半ばに登録したユーザーをActive Directoryから削除してから解除すると月内で課金が停止されました。

最後に

9月に慌てて検証しつつ、設計を進めたのですが思わぬハマりポイントに引っ掛かったので今後、License Managerを導入される際、K.I.T.T.(きっと)どなたかのご参考になるはずです。

参考

blog.serverworks.co.jp

独自SPLAライセンスを利用出来なくなった経緯の説明です。

blog.serverworks.co.jp

AWS License Managerの設定方法が記載されています。シークレットの命名規則等の詳細が説明されています。