AWS License Manager

解決する課題

• WindowsやSQL Server、Oracleなどを BYOL（持ち込みライセンス） で動かしているが、実際の利用量が見えない → 利用状況を一元追跡したい
• インスタンスを増やしすぎてライセンス契約のコア数・ソケット数を 超過 してしまう → 上限超過を未然に防ぎたい
• ベンダー監査で「契約どおりに使っているか」を証明する根拠を手作業で集めるのが大変 → コンプライアンスを継続的に把握したい
• 物理サーバー単位のライセンス条件（専有ホストへの固定など）を守りながらクラウドで使いたい → 配置制約をルールで強制したい

主要概念と用語

• ライセンス設定（License Configuration）: ライセンス条件をAWS上で表現したルールの集合。カウント単位や上限、配置制約、強制可否などを定義する
• カウント種別（License Counting Type）: 何を数えるかの単位。vCPU、物理 コア、ソケット、インスタンス などから選ぶ。BYOLの契約条件に合わせる
• 強制ルール（Enforced / ハードリミット）: 上限を超える起動を ブロック する設定。これを無効にすると上限超過は警告のみで許可される（ソフトリミット）
• AMI・ローンチテンプレートへの関連付け: ライセンス設定をAMIやローンチテンプレートに紐づけ、そこから起動するインスタンスを自動でカウント対象にする
• 検出ルール（自動検出）: Systems Managerのインベントリ情報を使い、対象ソフトウェアが入ったインスタンスを自動で発見してライセンス設定に紐づける仕組み
• 専有ホスト（Dedicated Host）との連携: 物理ホスト単位の課金が必要なライセンスに対し、ホストへの割り当てや配置を管理する機能
• 委任管理者（Delegated Administrator）: AWS Organizationsで組織全体のライセンスを一元管理するために指定する管理アカウント
• 使用状況レポート（利用量の追跡）: 関連付けられたリソースの起動・停止に応じて消費ライセンス数を増減させ、現在の消費量と残量を把握する

仕様・制限・クォータ

• リージョン単位 で利用するが、AWS Organizationsと連携すると 複数アカウント・複数リージョン の利用状況を委任管理者アカウントへ集約できる
• カウント種別は ライセンス設定の作成時に決める。後からカウント単位を変えるのではなく、条件に合った設定を用意する考え方になる
• 強制ルールを有効にした場合、上限を超える起動は API・コンソールのどちらからでも拒否 される。無効なら超過しても起動は通り、超過分が記録される
• 自動検出はSystems Manager（SSMエージェントとインベントリ）に依存するため、対象インスタンスが SSM管理下 にある必要がある
• 1アカウントあたりのライセンス設定数などにクォータがあり、必要に応じて上限緩和を申請できる場合がある
• サービス自体の利用に追加料金はかからないのが基本だが、連携するSystems Managerなど周辺サービスの費用は別途発生しうる

内部の仕組み

License Managerでは、まず契約条件を ライセンス設定 として登録します。ここで「何を（カウント種別）」「いくつまで（上限）」「どこで動かすか（配置制約）」「超過を許すか（強制ルール）」を定義します。

次に、このライセンス設定を AMI や ローンチテンプレート に関連付けます。関連付けたリソースからインスタンスが起動するたびに、License Managerは消費ライセンス数を加算し、停止・終了で減算します。これにより 現在の消費量と残量 がリアルタイムに近い形で追跡されます。

強制ルール（ハードリミット）が有効な場合、上限を超える起動要求は起動の段階で 拒否 されます。無効な場合は起動を許可しつつ、超過状態を記録して可視化します。

既存環境やオンプレミスについては、Systems Managerのインベントリ が収集したソフトウェア情報をもとに、対象ソフトウェアが入ったインスタンスを 自動検出 してライセンス設定に紐づけられます。物理ホスト単位のライセンスでは 専有ホスト と連携し、ホストへの割り当てや再利用期間（ライセンス保持期間）を管理して、ベンダー条件を満たしながら配置を最適化します。

設計パターン / ベストプラクティス

• 契約条件をそのままルール化: ベンダー契約のカウント単位（コア／ソケット／vCPU）と一致するカウント種別を選び、契約と乖離しない設定にする
• AMI・ローンチテンプレートへ標準で関連付け: BYOL用のゴールデンAMIにライセンス設定を紐づけておけば、そこから起動する全インスタンスが自動的に追跡対象になる
• まずソフトリミットで可視化: いきなり強制ブロックにせず、最初は強制ルールを無効にして実際の消費量を観測し、適切な上限値を見極めてから強制に切り替える
• 自動検出で棚卸し: Systems Managerのインベントリと連携し、把握できていないBYOLソフトウェアを洗い出して未管理のライセンスをなくす
• 組織での一元管理: AWS Organizationsで委任管理者を設定し、アカウントをまたいだライセンス消費を1か所で集約・統制する
• 物理ライセンスは専有ホストで: ホスト単位課金のソフトウェアは専有ホストに固定し、配置制約とライセンス保持期間を活用してコンプライアンスとコストを両立する

運用・監視

• 消費量と残量のダッシュボード を定点観測し、上限に近づいたら早めにライセンス追加や利用見直しを判断する
• 上限超過や強制ブロックの発生を EventBridge 経由で通知し、運用チームが即座に対応できるようにする
• 自動検出の結果を定期的に確認し、新たに増えたBYOLインスタンスが正しく追跡対象になっているかを点検する
• 強制ルールを有効にしている経路では、起動失敗のアラートを監視し、スケーリング障害とライセンス起因を切り分けられるようにする
• 利用状況レポートを監査・契約更新のタイミングで出力し、実消費に基づいてライセンス数を調整する

コスト

License Manager自体の追跡・制御機能は 基本的に追加料金なし で利用できます。コスト面の本質的な価値は、ライセンス費用そのものの最適化にあります。利用量を可視化することで 過剰なライセンス購入 を避け、逆に超過による 追徴やペナルティ のリスクを下げられます。一方で、自動検出に使うSystems Managerや、専有ホスト・連携先サービスには個別の費用が発生する場合があります。最新かつ正確な料金は公式の料金ページで確認してください。

セキュリティ

• ライセンス設定の作成・変更権限は 最小権限 に絞る。上限や強制ルールを誰でも変更できると、超過防止の仕組みが形骸化する
• 強制ルールの 有効・無効の切り替え は影響が大きいため、操作を限られたロールに限定し、変更をCloudTrailで追跡する
• 自動検出はSystems Managerの情報を参照するため、SSMの権限とインベントリ収集範囲を適切に管理する
• License Managerはコンプライアンス維持の仕組みであり、ソフトウェア自体の脆弱性対策やパッチ適用は別途各サービスで実施する

Well-Architected の観点

• コスト最適化: ライセンス消費を可視化して過不足を是正し、不要な購入や超過コストを抑える。BYOL資産を無駄なく活用できる
• 運用上の優秀性: 契約条件をルールとして仕組み化し、手作業の棚卸しや監査対応を自動化・継続化する

試験で問われるポイント

関連サービス・比較

ハンズオン / CLI例

# ライセンス設定を作成（コア数を上限とし、超過時はブロック）
aws license-manager create-license-configuration \
  --name "sql-server-core-byol" \
  --license-counting-type Core \
  --license-count 16 \
  --license-count-hard-limit

# 既存のライセンス設定を一覧表示
aws license-manager list-license-configurations

# 指定ライセンス設定の現在の消費量・残量を確認
aws license-manager get-license-configuration \
  --license-configuration-arn <ライセンス設定のARN>

# AMIにライセンス設定を関連付け（起動を自動カウント対象にする）
aws license-manager update-license-specifications-for-resource \
  --resource-arn <AMIのARN> \
  --add-license-specifications LicenseConfigurationArn=<ライセンス設定のARN>