AWS License Manager本番運用Vol1｜BYOLとLicense Asset Groups

1. ライセンス管理の本番課題とAWS License Managerの全体像

クラウド環境でのソフトウェアライセンス管理は、AWSにおいても無視できない運用上の課題です。オンプレミスで使用していたMicrosoftやOracle、SAPのソフトウェアをAWSに移行する場合や、AWS Marketplaceで提供されているライセンス込みのAMIを使用する場合、ライセンス数の管理・コンプライアンス維持・コストの最適化を手動で行うことには限界があります。

本セクションでは、ライセンス管理の本番課題を整理したうえで、AWS License Managerの全体像・ライセンスタイプ別の棲み分け・本記事全体の構成を説明します。

1-1. ライセンス管理の本番課題

AWSでソフトウェアライセンスを運用するうえで、実際に発生しやすい課題は以下のとおりです。

インベントリ把握の困難さ

AWSでは数百・数千台のEC2インスタンスを動的に起動・停止できます。このスケールで各インスタンスにインストールされているソフトウェアとそのライセンス数を手動で把握することは、現実的に困難です。特にSQL ServerやWindows Serverなど、vCPU単位やソケット単位で課金されるソフトウェアでは、インスタンスタイプの変更や自動スケーリングのたびにライセンス消費数が変動します。オートスケーリングによるインスタンスの追加・削除が頻繁に発生する環境では、リアルタイムのインベントリ追跡が不可欠です。

コンプライアンスリスク（過少ライセンス／過剰ライセンス）

ソフトウェアベンダーによるライセンス監査では、使用しているライセンス数が契約数を超えた場合（過少ライセンス）には、多額のペナルティを受けるリスクがあります。逆に契約数を大幅に上回るライセンスを購入している場合（過剰ライセンス）は、不要なコストが発生し続けます。クラウド環境では動的なスケーリングによってライセンス消費が変動するため、手動管理ではコンプライアンスの維持が困難です。

BYOLの要件管理

Microsoft SQL ServerやOracle Database、SAPのライセンスをAWSに持ち込む（BYOL: Bring Your Own License）ケースでは、ソフトウェアベンダーのライセンス条件を満たすためにEC2 Dedicated Hostsや特定のテナンシー設定が必要になることがあります。これらの要件を手動で管理・強制しようとすると設定ミスが生じやすく、コンプライアンス違反に直結するリスクがあります。

マルチアカウント環境での断片化

AWS Organizationsを採用したマルチアカウント構成では、ライセンス情報がアカウントごとに断片化し、組織全体のライセンス状態を一元的に把握できないという問題があります。各アカウントのライセンス消費を集約して組織全体のコンプライアンスを確認するには、専用の仕組みが必要です。アカウント数が数十・数百規模になると、手動での集約が現実的ではありません。

コスト最適化の難しさ

License Included（ライセンス込み）のAMIとBYOLのどちらがコスト面で有利かは、使用状況や既存のライセンス資産によって異なります。残余ライセンスの可視化がなければ追加購入の必要性を客観的に判断することも難しく、適切なコスト最適化を実施できません。

1-2. AWS License Managerとは

AWS License Manager（以下、License Manager）は、ソフトウェアライセンスの管理を一元化するAWSのマネージドサービスです。Amazon EC2、Dedicated Hosts、RDSなどのリソースに対するライセンス使用状況を追跡し、定義したルールに基づいてコンプライアンスを自動的に管理します。

2018年のGA（一般提供）以来、継続的に機能拡張が行われており、2025年には組織横断のライセンス可視化を実現する「License Asset Groups」が発表されるなど、現在も活発に進化しています。

License Managerが自動化・提供する主な機能:

• ライセンスルールの定義（ライセンス数の上限・カウント方式・ハード制限/ソフト制限の指定）
• EC2インスタンスやDedicated Hostsに対するライセンス使用状況のリアルタイム追跡
• ライセンス違反の検知とEventBridge/SNS経由のアラート通知
• ハード制限による予防的なライセンス超過阻止（上限超過時にインスタンス起動をブロック）
• AWS Organizations全体を横断したクロスアカウントのライセンス管理
• Systems Manager Inventoryと連携したオンプレミス・EC2のソフトウェア棚卸し
• License Asset Groups（2025）による組織横断のライセンス統合ビュー

License Managerの対象外（既存の専用サービスの領域）:

• AWSの利用料金の可視化・予算管理 → Cost Explorer / AWS Budgets
• インフラ構成のコンプライアンス確認 → AWS Config
• アプリケーションのデプロイ・リリース管理 → CodeDeploy / CodePipeline
• ランタイムでの動的な設定変更 → AWS AppConfig

License Managerは、ソフトウェアライセンス特化の管理ツールです。AWSのコスト全般やインフラ構成準拠は専用サービスに委ね、License Manager固有のライセンスコンプライアンスと追跡に集中することが重要です。

1-3. ライセンスタイプ別の棲み分け

License Managerが対象とするライセンスタイプは主に以下の3種類に分類されます。それぞれの特性を理解して適切に使い分けることが、効果的なライセンス管理の第一歩です。

自己管理ライセンス（Self-Managed License）

ソフトウェアベンダーから直接購入したライセンスをAWSで使用するケースです。Windows Server、SQL Server、Oracle Database、SAPなど、エンタープライズソフトウェアの多くがこのカテゴリに該当します。License Managerでは「ライセンス設定（License Configuration）」としてカウントルールと上限を定義し、EC2インスタンスやDedicated Hostsに関連付けて使用状況を追跡します。vCPU・物理コア・ソケット・インスタンス数など、ベンダーの課金体系に合わせたカウント方式を選択できます。

本記事のメイン領域であり、BYOLによる物理コア管理・使用状況追跡・違反検知の詳細は後続セクションで解説します。

付与ライセンス（Granted License）

AWS MarketplaceやISV（独立系ソフトウェアベンダー）から調達したライセンスで、License Managerを通じてアカウント間で付与・共有できます。購入したライセンスを組織内の別アカウントに付与する場合や、Marketplace製品のライセンスを集中管理する場合に使用します。Organizationsと組み合わせることで、付与ライセンスを組織内で適切に配布・追跡できます。

ユーザーベースサブスクリプション（User-Based Subscription）

Microsoft Remote Desktop Services（RDS）のSubscriber Access License（SAL）など、ユーザーアカウントを起点としたサブスクリプション型ライセンスです。デバイスやインスタンスではなく、ユーザー単位でライセンス消費を管理します。Active Directory統合や組織ユーザー数に基づくコンプライアンス管理が可能です。

なお、2025年には上記の各ライセンスタイプを横断して組織全体を統合管理する「License Asset Groups」が追加されました。ユーザー定義のルールでライセンスと関連リソースを集約し、AWS Organizations全体の統合ビューを提供します。詳細は後続セクションで解説します。

1-4. 本記事の対象読者と前提知識

本記事は以下の方を対象としています。

• AWSでMicrosoft、Oracle、SAPなどのエンタープライズソフトウェアを運用しているエンジニア・アーキテクト
• BYOLをAWSで実装し、Dedicated Hostsによる物理コア要件に対応したい方
• マルチアカウント環境でライセンスコンプライアンスを組織横断で管理したい方
• ソフトウェアベンダーの監査対応やライセンスコストの最適化を担当するクラウドエンジニア

前提知識として、AWSアカウントの基本操作（マネジメントコンソール・AWS CLI）およびEC2インスタンスの基本概念を把握していることを想定しています。AWS Organizations、Systems Manager（SSM）、IAMの詳細については本シリーズの各記事を参照してください。本記事はLicense Manager固有の運用に集中し、基盤サービスの再解説は最小限にとどめています。

1-5. License Manager導入のメリット

License Managerを導入することで、以下の3つの主要メリットが得られます。特にエンタープライズ環境での大規模なライセンス管理において、その効果が顕著です。

コンプライアンスの自動化と可視化

ライセンスルールをコードとして定義し、EC2インスタンスやDedicated Hostsへ自動で関連付けることで、手動管理に伴うヒューマンエラーを排除できます。ライセンス消費状況のリアルタイム可視化により、月次・四半期ごとの棚卸し作業の負荷を大幅に削減できます。ハード制限によるインスタンス起動の自動ブロックにより、過剰消費を事前に防ぐ予防的ガバナンスも実現します。

コスト最適化の基盤整備

残余ライセンス数の可視化により、過剰購入を抑制し適切な購入量を維持できます。BYOLとLicense Includedのコスト比較に必要なデータを提供し、適切なライセンス調達戦略の立案に役立ちます。Dedicated Hostsの稼働率監視と組み合わせることで、ライセンス関連コストの継続的な最適化が可能です。

監査対応の効率化

ライセンス消費レポートとCloudTrailを組み合わせることで、ソフトウェアベンダーの監査に必要な証跡を常に整備できます。License Asset Groupsを活用すれば、組織横断の統合ビューで監査対応データを一元収集でき、準備にかかる工数を削減できます。

これらのメリットにより、ライセンス管理の自動化・可視化・コスト最適化・監査対応を総合的に実現できます。

コスト全般の最適化はこちら（Cost Optimization本番運用 Vol1）

2. License Manager基礎 — ライセンス設定・カウントルール

2.1 ライセンス設定（License Configuration）の基本

AWS License Managerにおける「ライセンス設定（License Configuration）」は、ソフトウェアベンダーとの契約内容をAWS上で表現するための基本単位です。1つのライセンス設定に、ライセンス数（上限）・カウント方式・制限タイプ（ハード/ソフト）・対象プラットフォームを定義し、EC2インスタンスやAMIに紐付けることで使用状況の自動追跡を実現します。

License Managerが扱うライセンス設定には以下の3種類があります。

1. 自己管理ライセンス設定（Self-Managed License Configuration）: 企業が独自に購入したソフトウェアライセンス（Microsoft SQL Server・Oracle Database・RHELなど）を追跡・管理するための設定です。ベンダー契約のライセンス数・カウント方式・制限タイプをAWS上で表現し、EC2インスタンスやAMIに紐付けて消費状況を追跡します。
2. 付与ライセンス（Granted License）: AWS Marketplaceで購入したソフトウェアや、ISVから直接付与されたライセンスです。Marketplaceが自動的に登録・管理し、付与されたライセンスの消費状況をコンソールの「付与されたライセンス」セクションで確認できます。
3. ユーザーベースサブスクリプション（User-Based Subscription）: ユーザー単位で課金されるサブスクリプション型ライセンス（Microsoft Visual Studioなど）を管理します。Active Directoryとの連携が必要で、ユーザー数に応じた課金が発生します。

コンソールからのライセンス設定作成手順:

1. AWS License Manager コンソールにアクセスし、左ナビゲーションの「ライセンス設定」を選択します。
2. 「ライセンス設定を作成」ボタンをクリックします。
3. 以下の項目を順に設定します。
4. 名前: 後から識別しやすい名前を付けます（例: SQLServer-Enterprise-2022-Production）
5. 説明（任意）: ライセンスの詳細情報（購入日・ベンダー担当者・契約番号など）を記載します
6. 製品情報: AWSマネージドルールセットから対象製品を選択するか、カスタムルールを定義します
7. ライセンスカウント: ライセンスの上限数を設定します（例: SQL Server Enterprise 10 vCPU分）
8. カウント方式: vCPU/物理コア/ソケット/インスタンス数から選択します
9. 制限タイプ: ハード制限またはソフト制限を選択します
10. オプションとして、特定のAMIやEC2起動テンプレートと関連付けます。
11. 「ライセンス設定を作成」ボタンを選択して完了です。

AWS CLIからのライセンス設定作成例:

aws license-manager create-license-configuration \
  --name "SQLServer-Enterprise-2022-Prod" \
  --description "SQL Server Enterprise 2022 本番環境用 10 vCPU" \
  --license-counting-type vCPU \
  --license-count 10 \
  --license-count-hard-limit \
  --product-information-list '[{"ResourceType":"SSM_MANAGED","ProductInformationFilterList":[{"ProductInformationFilterName":"Application Name","ProductInformationFilterValue":["SQL Server*"],"ProductInformationFilterComparator":"BEGINS_WITH"}]}]' \
  --region ap-northeast-1

--license-count-hard-limit フラグを付けることでハード制限として設定されます。このフラグを省略するとソフト制限になります。作成後は list-license-configurations コマンドで確認できます。

aws license-manager list-license-configurations \
  --region ap-northeast-1 \
  --query 'LicenseConfigurations[*].{Name:Name,Count:LicenseCount,Type:LicenseCountingType}'

2.2 カウントルール設定の詳細

カウント方式の選択は、ライセンス管理において最も重要な設計判断のひとつです。ソフトウェアベンダーのライセンス契約書を必ず確認し、契約内容に合致するカウント方式を選んでください。誤ったカウント方式を設定すると、ライセンスの過少/過剰計上につながります。

カウント方式の種類と使い分け:

EC2インスタンスのvCPU数はインスタンスタイプごとに異なります。例えば m6i.xlarge は4 vCPU、m6i.2xlarge は8 vCPUです。ライセンス設定でvCPUカウントを選択すると、関連付けられたEC2インスタンスのvCPU数の合計が消費ライセンス数として計上されます。

aws license-manager list-usage-for-license-configuration \
  --license-configuration-arn arn:aws:license-manager:ap-northeast-1:123456789012:license-configuration:lic-XXXXXXXX \
  --region ap-northeast-1

出力の ConsumedLicenses フィールドで現在の消費数を確認できます。上限に近づいている場合は早めにライセンスを追加購入するか、使用量の最適化を検討してください。

物理コアをカウントするには、EC2の物理サーバーを専有する Dedicated Hosts を使用する必要があります。共有テナンシーのEC2インスタンスでは物理コア数を正確に把握できないため、物理コアカウント方式ではDedicated Hostsが実質必須となります。

AWSマネージドルールセットの活用:

自己管理ライセンス設定を作成する際、AWSが事前に用意しているマネージドルールセットを活用すると対象インスタンスの自動識別が容易になります。代表的な対応製品は以下の通りです。

• Microsoft SQL Server（Enterprise / Standard / Developer / Express）
• Microsoft Windows Server Datacenter Edition
• Red Hat Enterprise Linux（RHEL）
• SUSE Linux Enterprise Server
• Ubuntu Pro

マネージドルールセットを選択すると、SSM Inventoryが収集するインストール済みソフトウェア情報に基づいて対象インスタンスを自動的に識別し、ライセンス消費量に反映します。カスタムルールを定義する場合は、製品名・バージョン・パブリッシャーなどの条件を組み合わせて対象を絞り込みます。

2.3 ハード制限とソフト制限の違いと使い分け

License Managerでは、ライセンス上限の制限タイプとして「ハード制限」と「ソフト制限」の2種類を選択できます。どちらを選ぶかは、運用環境のリスク許容度とビジネス要件によって決まります。

ハード制限（Hard Limit）:

ライセンス上限を超えた場合、新しいEC2インスタンスの起動を自動的に阻止します。インスタンスの起動リクエストがAWS側で拒否され、エラーメッセージが返されます。

• 利点: ライセンス違反を完全に防止でき、ベンダー監査リスクをゼロに近づけられます。
• 注意点: 上限の設定が不適切な場合、本番インスタンスの起動を突然阻止してしまうリスクがあります。必ず実際の使用量に20〜30%程度の余裕を持たせた上限を設定してください。
• 推奨環境: 本番環境でライセンス違反を絶対に防ぎたい場合（Oracle DB・SQL Server Enterpriseなど）

ソフト制限（Soft Limit）:

ライセンス上限を超えた場合も、EC2インスタンスの起動は許可されます。超過状態が「違反（non-compliant）」として記録され、License Managerのダッシュボードで可視化されます。

• 利点: 一時的なキャパシティ増加にも対応でき、ビジネス継続性を確保しやすいです。
• 注意点: 違反状態を放置するとベンダー監査リスクが高まります。必ず通知設定を行い、違反発生後の対応フローを整備する必要があります。
• 推奨環境: まずは現状の使用量を把握してから対応したい場合、または開発/テスト環境

ソフト制限違反の通知設定例:

aws events put-rule \
  --name "LicenseManagerViolationAlert" \
  --event-pattern '{"source":["aws.license-manager"],"detail-type":["License Manager - License Configuration - Limit Breach"]}' \
  --state ENABLED

aws events put-targets \
  --rule "LicenseManagerViolationAlert" \
  --targets '[{"Id":"1","Arn":"arn:aws:sns:ap-northeast-1:123456789012:LicenseViolationAlert"}]'

制限タイプの選択指針:

2.4 ライセンス設定のAMIへの紐付けと起動テンプレート連携

ライセンス設定をAMI（Amazon Machine Image）に紐付けることで、そのAMIから起動されたすべてのEC2インスタンスが自動的にライセンス設定と関連付けられます。管理者が個別にインスタンスを追跡・登録する手間を省き、新規インスタンス起動時の自動的なライセンス追跡を実現します。

aws license-manager update-license-specifications-for-resource \
  --resource-arn arn:aws:ec2:ap-northeast-1::image/ami-XXXXXXXXXXXXXXXX \
  --add-license-specifications '[{"LicenseConfigurationArn":"arn:aws:license-manager:ap-northeast-1:123456789012:license-configuration:lic-XXXXXXXX"}]'

紐付け後は、このAMIから起動されたインスタンスが自動的にライセンス消費としてカウントされます。Organizations統合を有効にした状態では、共有AMIから別アカウントで起動されたインスタンスも元のライセンス設定との関連付けが維持されます。

EC2起動テンプレート（Launch Template）にライセンス設定を紐付けることも可能です。Auto Scalingグループ経由で起動されたインスタンスにも自動的にライセンスが関連付けられるため、スケールアウト時の追跡漏れを防止できます。

2.5 AWS Marketplaceとの統合と付与ライセンス管理

AWS Marketplaceで購入したソフトウェア製品は、「付与ライセンス（Granted License）」として自動的にLicense Managerに登録されます。追加購入・更新・取り消しはMarketplaceを通じて行い、License Managerへ自動的に反映されます。

aws license-manager list-received-licenses \
  --region ap-northeast-1 \
  --query 'Licenses[*].{Product:ProductName,Issuer:Issuer.Name,Status:Status}'

組織内でISVから受け取ったライセンスをメンバーアカウントへの再配布（Grant）も可能です。グラントされたライセンスの有効期限と使用状況は、受け取り側アカウントのコンソールから確認できます。

2.6 ユーザーベースサブスクリプションの設定と管理

ユーザーベースサブスクリプションは、EC2インスタンス単位ではなくユーザー単位で課金されるサブスクリプション型ライセンスをLicense Managerで管理する仕組みです。代表的な製品としてはMicrosoft Visual Studio（Enterprise/Professional）などがあります。

設定手順は以下の通りです。

1. License Managerコンソールの「ユーザーベースサブスクリプション」を選択します。
2. 「製品のサブスクライブ」で対象製品を選択します。
3. Active Directory（AWS Managed Microsoft ADまたはオンプレミスADのドメイン参加）との連携を設定します。
4. ライセンスを付与するユーザーを追加します（個別指定またはグループ指定）。
5. サブスクリプションの使用状況はダッシュボードでリアルタイムに確認できます。

ユーザーベースサブスクリプションは1時間単位で計測され、アクティブなユーザー数に応じてライセンス費用が計算されます。不要になったユーザーのライセンスを速やかに解除することが、コスト最適化の重要なポイントです。

aws license-manager-user-subscriptions associate-user \
  --username "user@example.com" \
  --instance-connector-id "lm-connector-XXXXXXXX" \
  --domain "example.com"

月末に未使用のサブスクリプションが課金対象になっていないかを定期的に確認し、不要なユーザーのライセンスを解除する運用サイクルを確立することを推奨します。以上がAWS License Managerの基礎となるライセンス設定・カウントルール・制限タイプの詳細です。

3. BYOL & 専有ホスト — Dedicated Hosts/ホストリソースグループ

BYOL（Bring Your Own License）は、企業がオンプレミスで保有するソフトウェアライセンスをそのままAWSクラウドに持ち込んで利用する仕組みです。Windows ServerやSQL Server、Oracle Database、SAP HANAなど、物理コアやソケット数に基づいて課金されるエンタープライズ製品では、BYOLを適切に管理することがコンプライアンスとコスト最適化の両方に直結します。

BYOLの基本概念と対象製品

BYOLが有効に機能する主な製品カテゴリは次のとおりです。

Windows Server
物理コアライセンスを持ち込む場合、Dedicated Hostsを使ってホストの物理コア数に対してライセンスを適用します。通常の共有型EC2ではライセンスの物理配置を保証できないため、Windows ServerのBYOLにはDedicated Hostsが必須です。Windows Serverは別途License Includedオプションも選択できるため、既存ライセンスのSA（Software Assurance）期限や数量によって経済的優位性が変わります。移行前にSAのカバレッジを必ず確認してください。

SQL Server
SQL Server EnterpriseおよびStandardをDedicated Hosts上で使用する場合、物理コア数に基づいてライセンスをカウントします。SQL Server EnterpriseはAWS Marketplace経由のLicense Includedと比較してBYOLのコストメリットは大きくなるケースが多く、大規模環境ではDedicated Hostsを活用したBYOL構成が一般的です。Standard Editionでも、インスタンス単位からコア単位への変換が必要かを事前に確認してください。

Oracle Database
OracleはAWSを認定済みクラウド環境として認めており、Oracle Database Enterprise EditionをAWSで使用する場合にはハードパーティション要件への対応が必要です。Dedicated Hostsはハードパーティションとして認められるため、Dedicated Hosts上のvCPU数に基づいてOracle標準のライセンス換算式を適用できます。Dedicated Instances（専有インスタンス）はソフトパーティションとみなされる場合があるため、BYOLには必ずDedicated Hostsを使用してください。

SAP HANA
SAP HANAをAWSで動作させるには、AWSとSAPが認定したインスタンスタイプ（x1、x1e、u-シリーズ等）を使う必要があります。認定インスタンスタイプ以外での動作はSAPのサポート対象外になる場合があるため、インスタンスタイプ選定時にSAP認定リストを参照してください。ライセンス計算はメモリ単位が基本となる点がWindowsやOracleとは異なります。

License IncludedとBYOLの使い分け

AWSはEC2インスタンスにライセンスを含めて提供する「License Included」オプションを用意しています。BYOLとLicense Includedの使い分けは以下の観点で判断します。

小規模・短期利用であればLicense Includedが手軽であり、大規模・長期利用では既存ライセンス資産を活かしたBYOLのほうがTCO（総所有コスト）を削減できます。

Dedicated Hosts（専有ホスト）の設定手順

BYOLを適用するためのDedicated Hostsの設定は以下の手順で行います。

コンソールからの割り当て
EC2コンソールの「Dedicated Hosts」メニューから「Dedicated Hostsの割り当て」を選択します。インスタンスファミリー（例：c5、m5、r5）、可用性ゾーン、ホスト数量を指定して割り当てます。割り当て後にホストIDが発行されるため、このIDをライセンス管理台帳に記録してください。

CLIからの割り当て

aws ec2 allocate-hosts \
  --instance-type c5.xlarge \
  --availability-zone ap-northeast-1a \
  --quantity 2 \
  --auto-placement off \
  --tag-specifications \
 'ResourceType=dedicated-host,Tags=[{Key=CostCenter,Value=IT-Infra}]'

--auto-placement offを指定すると、インスタンス起動時に手動でホストを選択する必要があります。License Managerと連携する場合は、Host Resource Groupsへ追加してから自動割り当てを有効化するほうが運用効率は高まります。

テナンシー設定
EC2インスタンスをDedicated Hosts上で起動するには、インスタンス設定のテナンシーで「専有ホスト」を選択し、割り当て済みのホストIDを指定します。起動テンプレートにホストIDやホストリソースグループを設定しておくことで、Auto Scalingとの連携時にもDedicated Hostsへ自動配置できます。

Host Resource Groups（ホストリソースグループ）による自動管理

Host Resource Groups（ホストリソースグループ）は、License ManagerとEC2 Dedicated Hostsが連携して提供する自動管理機能です。複数のDedicated Hostsを1つのグループとして扱い、License Managerのルールに基づいてホストの割り当てと解放を自動化します。手動管理を排除することで運用負荷を大幅に削減できます。

主な機能

• 自動ホスト割り当て: インスタンス起動時に、グループ内の適切なDedicated Hostsへ自動配置します。空きホストがない場合は新しいホストを自動割り当てします。
• 自動ホスト解放: グループ内のDedicated Hostsが空（インスタンスなし）になった場合は自動解放してコストを削減します。
• License Managerルール連動: グループへ関連付けたライセンス設定に基づき、ライセンス消費を自動追跡します。

ホストリソースグループの作成（コンソール手順）

1. License Managerコンソールを開き「ホストリソースグループ」を選択します。
2. 「グループの作成」をクリックし、グループ名と説明を入力します。
3. インスタンスファミリー（例：c5）を選択してDedicated Hostsの種類を制限します。
4. 「ライセンス設定の関連付け」から対応するライセンス設定を選択します。
5. 既存のDedicated HostsをグループにインポートするかAuto-placementを有効化します。

ライセンス設定の作成と連携（CLI）

まずライセンス設定を作成し、その後ホストリソースグループと関連付けます。以下はSQL Server Enterprise（ソケット課金）の例です。

# ライセンス設定の作成（SQL Server Enterprise 16ソケット）
aws license-manager create-license-configuration \
  --name "SQL-Server-Enterprise" \
  --license-counting-type Socket \
  --license-count 16 \
  --license-count-hard-limit \
  --license-rules "#allowedTenancies=EC2-DedicatedHost"

ホストリソースグループを作成した後、EC2コンソールまたはCLIでDedicated Hostsをグループに関連付けます。インスタンスが起動するたびにライセンス消費が自動記録されるようになります。

ライセンス設定の紐付け手順

ホストリソースグループにライセンス設定を紐付けることで、グループ内すべてのDedicated Hostsがライセンス追跡の対象になります。

コンソールから紐付ける場合
License Managerの「ライセンス設定」ページから対象の設定を選択し、「ホストリソースグループの関連付け」を実行します。この操作により、該当グループ内のすべてのDedicated Hostsがライセンス追跡の対象として登録されます。

CLIから紐付ける場合

aws license-manager update-license-configuration \
  --license-configuration-arn \
 arn:aws:license-manager:ap-northeast-1:123456789012:license-configuration:lic-0a1b2c3d \
  --license-rules "#allowedTenancies=EC2-DedicatedHost"

allowedTenanciesルールをEC2-DedicatedHostに限定することで、共有テナンシーでの誤ったライセンス消費を防ぎます。Dedicated Hosts以外でのインスタンス起動時にライセンス違反として検知されるようになります。

オンプレミスからの移行時の注意点

オンプレミス環境からBYOLライセンスをAWSへ移行する際には、いくつかの重要な前提条件を確認してください。

Software Assurance（SA）の確認
MicrosoftのBYOLプログラム（ライセンスモビリティ）はSAを保有していることが条件です。SAなしのライセンスはクラウドへの持ち込みができません。AWSへの移行前に、保有ライセンスのSA有効期限とカバレッジを必ず確認してください。SAを保有していてもライセンスの種類によってモビリティが認められないものもあるため、Microsoft VLSC（Volume Licensing Service Center）で事前に確認します。

移行前の棚卸し手順

1. SSM Inventoryを使ってオンプレミスサーバーのインストール済みソフトウェアを一覧化します。
2. License ManagerでSSM Inventory統合を有効化します（コンソールの「Systems Managerインベントリとの統合」を有効化）。
3. 検出されたソフトウェアに対してライセンス設定を作成し、消費数を確認します。
4. オンプレミスの総ライセンス数とAWSへ持ち込む数量の計画を策定します。

ライセンス検証の手順
Microsoftの場合はMicrosoft Product Activation CenterまたはVLSCでSAを確認します。SAの有効期間中にAWSでの使用を開始し、SA失効前に更新しなければBYOLの条件を満たせなくなります。SA期限をEventBridgeのスケジュールイベントとして登録し、期限90日前に担当者へSNS通知を送る仕組みを構築することを推奨します。

Microsoft/Oracle/SAP特有の要件と注意点

各ベンダーごとに固有のDedicated Hosts利用要件があります。

Microsoft
Windows Server Datacenter Editionは物理コアライセンスで全仮想マシンを無制限に実行できますが、Dedicated Hosts上でのみ有効です。SQL Server EnterpriseはSA必須で、ライセンスモビリティを通じてDedicated Hosts上での物理コア単位のライセンス適用が可能です。SAの有効期間が切れると既存インスタンスはBYOLとして使用不可になるため、更新アラートをEventBridgeで自動化することを強く推奨します。

Oracle
Oracle Database Enterprise Editionは仮想コアの0.5コア分を1 Oracle Processor Licenseに換算します（Dedicated Hosts上のvCPU数 × 0.5）。Oracle Technology Network（OTN）ライセンスはクラウド使用を許可されないものが多く、Oracle ULA（Unlimited License Agreement）対象製品かどうかを事前に確認してください。Oracle RAC（Real Application Clusters）のDedicated Hosts上での動作には制限があるため、Oracle営業またはAWSサポートへの事前確認を推奨します。

SAP
SAP HANAはAWS上の認定インスタンスタイプ（x1.16xlarge、x1.32xlarge、x1e.8xlarge等）でのみSAPのサポートを受けられます。SAP on AWSではDedicated Hostsを使用するケースが多く、SAP Basis管理者とAWSアーキテクトが連携してライセンス計画を作成することを推奨します。認定インスタンスタイプの最新リストはSAP公式ページで確認してください。

4. トラッキング&コンプライアンス — 使用状況追跡・違反検知

4.1 使用状況ダッシュボード — ライセンス消費のリアルタイム可視化

License Managerのコンソールには、ライセンス設定ごとの消費状況を一覧できるダッシュボードが用意されています。ダッシュボードには「消費済みライセンス数」「上限(ライセンス総数)」「残余ライセンス数」の3指標がリアルタイムで表示されるため、過剰消費や残余の状況をひと目で把握できます。

ライセンス設定の詳細ページでは、設定に関連付けられたEC2インスタンスやDedicated Hostsのリソースインベントリを確認できます。各リソースのインスタンスID、リージョン、使用カウント数がリスト形式で表示されるため、「どのリソースが何ライセンスを消費しているか」を追跡できます。インベントリはほぼリアルタイムに更新されるため、新規インスタンス起動後も数分以内に反映されます。

ライセンス消費レポートを定期的にS3にエクスポートする設定も可能です。レポートはCSV形式で出力され、ライセンス設定名・アカウントID・リージョン・消費数・上限・違反フラグが含まれます。このレポートをAthenaやQuickSightと組み合わせることで、組織全体のライセンス消費トレンドを可視化できます。

4.2 ハード制限とソフト制限 — 制限動作の使い分け

License Managerのライセンス設定では「ハード制限(Hard limit)」と「ソフト制限(Soft limit)」の2種類の制限モードを選択できます。両者の動作の違いを正確に理解することが、コンプライアンスと運用安定性の両立の鍵です。

ハード制限は上限を超過した時点でEC2インスタンスの起動を強制的に阻止します。ライセンス上限が10であり、すでに10インスタンスが稼働している状態で11台目の起動を試みた場合、InvalidParameterCombination: You have exceeded your allowed license limit のエラーが返され、インスタンスは起動しません。ハード制限は過剰ライセンス消費を物理的に防ぐ予防的ガバナンスの仕組みとして機能します。ただし、バースト需要やAutoScalingと組み合わせる場合、制限値の設計を慎重に行わないと、本番インスタンスの起動を阻止してしまう運用リスクがあります。

ソフト制限は上限を超過してもインスタンス起動を許可しますが、違反(License Violation)として記録します。インスタンスは正常に稼働しますが、License Managerのダッシュボードと違反リストに記録が残ります。EventBridgeとSNSに違反イベントが発行されるため、通知を受け取ってから対応できます。ソフト制限はビジネスクリティカルな本番環境で許容度を確保しながら、コンプライアンス状況を監視する用途に適しています。

どちらの制限モードを選ぶかは組織のリスク許容度と運用成熟度によって判断します。開発・検証環境ではソフト制限で違反状況を把握しながら運用し、本番環境の核となる基幹システムではハード制限で過剰消費を完全に防ぐ構成が一般的です。

4.3 違反検知と通知 — EventBridge・SNS・CloudWatchの連携

ライセンス違反が発生すると、License ManagerはAmazon EventBridgeにイベントを発行します。イベントのソースは aws.license-manager、詳細タイプは License Manager - License Configuration - Limit Breach です。このイベントをトリガーにSNSトピックへの通知やLambda関数の実行を設定することで、違反発生時の自動通知と自動対応を実現できます。

EventBridgeルールを使って違反イベントをSNSトピックに送信する設定例を示します。

{
  "source": ["aws.license-manager"],
  "detail-type": ["License Manager - License Configuration - Limit Breach"],
  "detail": {
 "licenseConfigurationARN": [
"arn:aws:license-manager:ap-northeast-1:123456789012:license-configuration:lic-xxxxxxxxxxxx"
 ]
  }
}

このEventBridgeルールとSNSトピックを組み合わせることで、ライセンス違反発生時に担当チームへのメール通知やSlackへのアラートを自動で配信できます。通知には違反が発生したライセンス設定名、関連リソースID、消費数、上限が含まれるため、即時の状況把握が可能です。

CloudWatchメトリクスを活用した監視も有効です。License ManagerはCloudWatchに LicenseUsage および LicenseViolation メトリクスを発行します。これらのメトリクスに対してCloudWatchアラームを設定し、残余ライセンス数が閾値を下回った時点でアラートを発行する構成で、違反発生の前段階での予防的通知が可能になります。例えば上限の80%に達した時点でWARNINGアラームを、100%に達した時点でCRITICALアラームを発行する2段階アラームを設定することで、余裕を持った対応が可能です。

4.4 AWS Systems Manager統合 — SSM Inventoryによる自動棚卸し

License ManagerとAWS Systems Manager(SSM)の統合機能は、EC2インスタンスおよびオンプレミスサーバーにインストールされているソフトウェアを自動的に検出し、ライセンス追跡に活用する仕組みです。

SSM Inventoryの設定手順

まずSSM Agentが稼働しているEC2インスタンスまたはオンプレミスサーバーをSSM管理対象インスタンスとして登録します。次にSystems ManagerのInventoryでデータ収集設定(Inventory association)を作成します。収集対象として「Software」を含めることで、インストール済みアプリケーション、名前、バージョン、パブリッシャー情報が定期収集されます。

# SSM Inventory associationの作成
aws ssm create-association \
  --name "AWS-GatherSoftwareInventory" \
  --targets "Key=InstanceIds,Values=*" \
  --schedule-expression "cron(0 0 * * ? *)" \
  --parameters '{"applications":["Enabled"]}'

収集されたInventoryデータはLicense Managerのコンソールから参照できます。License Managerの「Managed Instances」画面では、SSM管理対象インスタンスごとにインストール済みソフトウェアの一覧が表示され、ライセンス設定で追跡している製品が存在するかどうかを確認できます。

SSM統合の主な活用パターン

オンプレミスサーバーの移行計画における現状棚卸しに特に有効です。SSM Inventory経由でオンプレミスサーバーのインストール済みソフトウェアを収集し、現在保有するライセンス数と比較することで、AWSへの移行後に必要なBYOLライセンス数を正確に見積もれます。

既存のEnterprise契約やソフトウェアアシュアランスに基づいて組織全体で何本のSQL ServerやWindowsライセンスが稼働しているかを定期的に棚卸しする場合、SSM Inventoryの自動収集機能と連携することで手動集計の工数を大幅に削減できます。

また、SSM Inventory収集は管理対象インスタンスに対してスケジュール実行されるため、新規デプロイされたインスタンスも翌収集サイクルには自動的にインベントリに追加されます。これにより、手動での更新作業なしに常に最新のソフトウェア棚卸し情報を維持できます。

4.5 AWS CLI操作例 — ライセンス消費確認と違反リスト取得

License Managerの主要な操作はAWS CLIから実行できます。以下に代表的な操作例を示します。

ライセンス設定の一覧表示

aws license-manager list-license-configurations \
  --region ap-northeast-1

ライセンス消費状況の詳細確認

aws license-manager get-license-configuration \
  --license-configuration-arn \
 arn:aws:license-manager:ap-northeast-1:123456789012:license-configuration:lic-xxxxxxxxxxxx

このコマンドの出力には ConsumedLicenses（消費済みライセンス数）、LicenseCount（上限）、LicenseCountHardLimit（ハード制限の有無）が含まれます。

違反リストの取得

aws license-manager list-failures-for-license-configuration-operations \
  --license-configuration-arn \
 arn:aws:license-manager:ap-northeast-1:123456789012:license-configuration:lic-xxxxxxxxxxxx

ライセンス消費レポートの定期生成設定

License Manager ConsoleからS3バケットを指定してレポートを生成するほか、CLIでも実行できます。

aws license-manager create-license-manager-report-generator \
  --name "monthly-license-report" \
  --type LicenseConfigurationSummaryReport \
  --report-context \
 '{"licenseConfigurationArns":["arn:aws:license-manager:ap-northeast-1:123456789012:license-configuration:lic-xxxxxxxxxxxx"]}' \
  --report-frequency '{"value":1,"period":"MONTH"}' \
  --s3-location '{"bucket":"my-license-reports","prefix":"license-manager/"}'

関連リソースのインベントリ取得

aws license-manager list-resource-inventory \
  --filters \
 '[{"Name":"license-configuration-arn","Condition":"EQUALS","Value":"arn:aws:license-manager:ap-northeast-1:123456789012:license-configuration:lic-xxxxxxxxxxxx"}]'

4.6 CloudTrailによるAPI監査証跡

License ManagerのAPI操作はすべてAWS CloudTrailに記録されます。ライセンス設定の作成・変更・削除、ライセンスの関連付けと解除、使用状況レポートの生成といった操作が監査証跡として残るため、ソフトウェアベンダーの監査に対応する際の根拠として活用できます。

CloudTrailのイベントには eventSource: license-manager.amazonaws.com が含まれるため、CloudWatch Logs Insightsを使って特定のライセンス設定に対する変更操作を絞り込み検索できます。

# CloudTrailでLicense Manager操作の検索
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=EventSource,AttributeValue=license-manager.amazonaws.com \
  --start-time "2026-01-01T00:00:00Z" \
  --end-time "2026-06-01T00:00:00Z"

CloudTrail Lakeと組み合わせることで、90日を超える長期のLicense Manager操作履歴をSQL形式でクエリできます。「特定のライセンス設定が変更された日時と変更者」「過去1年間にわたるライセンス消費量の推移」などをさかのぼって分析する際に役立ちます。

4.7 違反発生時の対応フロー

ライセンス違反が検知された際の標準的な対応フローを示します。

即時対応

1. SNS/EventBridge通知を受信し、違反が発生したライセンス設定と関連リソースを特定します。
2. License Managerコンソールの「License configurations」→「Violations」タブで違反の詳細(違反リソース・消費数・発生時刻)を確認します。
3. 即座に対応が必要な場合(ハード制限で起動阻止が発生している場合)は、一時的にライセンス上限を引き上げるか、不要なインスタンスを停止してライセンスを解放します。

根本原因調査

1. CloudTrailで当該時間帯のEC2起動API(RunInstances)を検索し、誰が何台のインスタンスを起動したかを調査します。
2. 予期せぬAutoScalingによる急増であれば、スケーリングポリシーの上限設定と、ライセンス設定の上限が整合しているかを確認します。
3. タグやAMI関連付けの設定ミスで意図しないインスタンスがライセンス設定に関連付けられていないかを確認します。

再発防止策の実施

1. ライセンス上限値とAutoScaling最大数の整合を定期的にレビューするプロセスを確立します。
2. CloudWatchアラームで残余ライセンス数が80%消費時点でWARNINGアラームを発行するよう設定し、違反発生前に対処できる体制を整えます。
3. ハード制限とソフト制限の使い分けを見直し、バースト許容が必要なシステムにはソフト制限を適用します。
4. 月次または四半期ごとにライセンス消費レポートをレビューし、残余ライセンスの多いライセンス設定は上限を適切に調整してコストを最適化します。

5. License Asset Groups — 組織横断ライセンス可視化(2025新機能)

License Asset Groups とは

License Asset Groups は、2025年11月の AWS re:Invent で発表された AWS License Manager の新機能です。ソフトウェアライセンスと関連するAWSリソース（主にEC2インスタンス）を、ユーザー定義のルールに基づいて自動的に集約する「コンテナ」として機能します。AWS Organizations 配下の複数アカウント・複数リージョンを横断した統合ビューを提供し、組織全体のライセンス状態を一元的に把握できるようになりました。

従来の License Configuration（ライセンス設定）は、個別のアカウントやリージョン単位でライセンスのカウントルールを定義するものです。これに対し License Asset Groups は、複数のライセンス設定や付与ライセンスを横断的に集約し、組織レベルの可視化を実現する上位レイヤーとして位置づけられています。自己管理ライセンス設定（Self-Managed License Configuration）と付与ライセンス（Granted License）の両方を同一グループに取り込める点が大きな特徴です。

従来の課題と License Asset Groups による解決

大規模な AWS 環境では、ライセンス管理における可視性の断片化が長年の課題でした。典型的なマルチアカウント構成では、開発・ステージング・本番の各アカウントが独立して存在し、それぞれで License Configuration を設定していても、組織全体で「SQL Server ライセンスが何本消費されているか」を一目で把握することが困難でした。

License Asset Groups が登場する前は、以下のような問題が発生していました。

• アカウント間の断片化：各アカウントのライセンス消費状況を個別に確認し、手動で集計する必要がありました
• リージョン横断の不可視性：東京リージョンとバージニアリージョンのライセンス消費が別々に管理されており、全体像を把握しにくい状況でした
• 監査対応の工数増大：ソフトウェアベンダーの監査時に組織全体のライセンスデータをまとめる工数が大きくなっていました
• コンプライアンスリスクの潜在化：一部アカウントのライセンス超過を見逃すリスクが常に潜んでいました

License Asset Groups はこれらの問題を解決するために設計されており、ルールベースの自動グルーピングによって組織横断の統合ビューを自動的に構築します。管理者は単一のコンソール画面から組織全体のライセンス消費状況を確認でき、コンプライアンスリスクの早期検知と対応が可能になります。

License Asset Groups の仕組み

License Asset Groups の中核は「ルールベースの自動集約」です。グループ作成時にユーザーがルール（フィルタリング条件）を定義すると、そのルールに一致するライセンスとEC2インスタンスが自動的にグループに集約されます。

グループの主要構成要素：

• ライセンスソース：自己管理ライセンス設定と付与ライセンスの両方を取り込めます。混在環境での統合可視化が実現します
• リソースフィルター：タグ・アカウントID・リージョン・インスタンスタイプなどの条件でEC2インスタンスを絞り込みます
• 集約スコープ：Organizations 配下の全アカウント・全リージョンを対象にできます

AWS Organizations との連携が必須要件です。管理アカウントで License Manager の Organizations 統合を有効化し、クロスアカウントのリソース検出を許可することで、メンバーアカウントのリソース情報が自動的に収集されます。委任管理者アカウントを設定することで、管理アカウントへの権限集中を避けつつ、専用アカウントから組織全体を管理できます。

グループ内では消費状況のサマリービューが提供されます。ライセンス消費数・残余数・超過アラート状態が一覧で確認でき、どのアカウントでどれだけ消費しているかをドリルダウンして把握できます。

License Asset Groups の作成・管理手順

AWSコンソールでの作成手順：

1. AWS マネジメントコンソールで License Manager を開きます
2. 左ペインの「License Asset Groups」を選択します（Organizations 統合が有効な状態で表示されます）
3. 「グループを作成」をクリックします
4. グループ名と説明を入力します（例：SqlServer-Production-Group）
5. ライセンスソースの追加：「ライセンス設定を追加」または「付与ライセンスを追加」からライセンスを選択します。複数のライセンス設定を同一グループに追加できます
6. リソースフィルターの設定：タグ条件（例：Environment=Production）やアカウント範囲（特定のOUまたは全アカウント）を設定します
7. 確認画面でルール条件とスコープを確認し、「グループを作成」で完了です

作成後はグループのダッシュボードでライセンス消費状況がリアルタイムに反映されます。ルール条件に一致する新しいインスタンスが起動されると、自動的にグループに追加されます。

AWS CLI での操作例：

License Asset Groups に関連する既存 CLI コマンドの代表的な操作例を示します。

# ライセンス設定の一覧確認（グループに追加するソースを特定）
aws license-manager list-license-configurations \
  --query 'LicenseConfigurations[*].{Name:Name,ARN:LicenseConfigurationArn,Status:Status}'

# 付与ライセンスの一覧確認（Marketplace等から受け取ったライセンス）
aws license-manager list-received-licenses \
  --query 'Licenses[*].{ProductName:ProductName,Status:Status,ARN:LicenseArn}'

# Organizations統合の設定状況確認
aws license-manager get-service-settings \
  --query 'OrganizationConfiguration'

# ライセンス消費レポートの定期出力設定（S3への定期エクスポート）
aws license-manager create-license-manager-report-generator \
  --report-generator-name "SqlServer-Group-Weekly" \
  --type "LicenseConfigurationSummaryReport" \
  --report-context "licenseConfigurationArns=arn:aws:license-manager:ap-northeast-1:123456789012:license-configuration:lic-xxxxxxxxxxxxxxxx" \
  --report-frequency "value=7,period=DAYS" \
  --s3-location "bucket=my-license-reports,prefix=sql-server-weekly"

CLI コマンドの詳細パラメータは、AWS CLI リファレンスで最新版を確認することをお勧めします。License Asset Groups は 2025年11月 GA の新機能のため、GA 後に追加されたパラメータを含む場合があります。

既存ライセンスとの統合方法

License Asset Groups は、既存の License Configuration をそのまま活用できる設計になっています。新機能導入のために既存設定を変更する必要はなく、段階的に移行できます。

自己管理ライセンス設定との連携：

既存の License Configuration（カウントルール・ライセンス上限・ハード/ソフト制限）はそのまま動作を継続します。License Asset Groups は「可視化レイヤー」として既存設定の上に重ねる形で機能するため、既存のライセンス適用メカニズムへの影響はありません。既存の設定を入力ソースとして指定するだけで、組織横断の統合ビューが得られます。

付与ライセンスとの統合：

AWS Marketplace から購入したソフトウェアや、IAM Roles Anywhere 経由で付与されたライセンスも同一グループに取り込めます。自己管理ライセンスとマーケットプレイス調達ライセンスが混在する環境でも、単一のグループで統合管理が可能です。

段階的な導入アプローチ：

全ライセンスを一度に移行する必要はありません。以下の順序で段階的に拡大することを推奨します。

1. 第1ステップ：コストインパクトが大きい主要ライセンス（SQL Server Enterprise・Oracle DB 等）から Asset Group を作成し、可視化効果を確認します
2. 第2ステップ：本番環境のライセンスグループを整備し、CloudWatch アラームと連携させます
3. 第3ステップ：開発・ステージング環境を含む全ライセンスに拡大し、組織全体の統合ビューを完成させます

実際の活用シナリオ

シナリオ1：SaaS ライセンス一元管理

複数の開発チームが異なるアカウントで SQL Server 開発環境を構築している企業を例にします。開発・ステージング・本番が別アカウントに分散しているため、SQL Server ライセンス消費状況が見えにくい状況です。

License Asset Groups を活用することで、License=SQL-Server-Standard タグが付与されたすべてのインスタンスを Organizations 横断で自動集約できます。ライセンス管理者は単一の Asset Group ダッシュボードから全社の SQL Server ライセンス消費を確認でき、過剰消費の早期検知が可能になります。過去は手動集計に数時間かかっていた月次レポートを、ほぼリアルタイムで確認できるようになります。

シナリオ2：ユーザーベースサブスクリプションの追跡

Microsoft Remote Desktop Services のユーザーサブスクリプション（SAL）は、接続ユーザー数に基づいて課金されます。複数アカウントで EC2 ベースのリモートデスクトップ環境を提供している場合、アカウントをまたいだ実際のユーザー数の把握が困難でした。

License Asset Groups のユーザーベースサブスクリプション対応機能を使うと、Organizations 全体の接続ユーザー数を集約し、購入ライセンス数との整合性をリアルタイムで確認できます。サブスクリプション数の過不足を早期に発見し、ベンダー更新前に適切なサイジングが可能になります。

シナリオ3：四半期監査への迅速対応

四半期ごとにソフトウェアベンダーへ使用状況を報告する義務がある場合、License Asset Groups のレポート機能を活用することで対応工数を大幅に削減できます。S3 への定期レポート出力を設定しておくことで、監査依頼を受けた際に最新のライセンス消費データをすぐに提示できます。CloudTrail の API 監査ログと組み合わせることで、ライセンス変更履歴の証跡も整備できます。

シナリオ4：金融・医療系システムのコンプライアンス管理

金融機関や医療機関では、規制要件によりソフトウェアライセンスの正確な記録が義務付けられている場合があります。License Asset Groups で組織全体のライセンス状態を常に把握することで、内部監査や外部審査への対応コストを削減し、コンプライアンス違反リスクを最小化できます。

CloudWatch・Cost Explorer との連携

License Asset Groups 単体では金額情報は表示されませんが、関連サービスとの連携によってライセンスコストの可視化が実現します。

CloudWatch メトリクスとの連携：

License Manager は以下のメトリクスを CloudWatch に送信します。

• LicenseConfigurationConsumedLicenses：消費ライセンス数
• LicenseConfigurationAvailableLicenses：残余ライセンス数

これらのメトリクスに対してアラームを設定することで、ライセンス消費が閾値を超えた際に SNS 通知を受け取れます。Asset Group 単位でアラームを設計し、閾値超過を組織全体で一元管理することを推奨します。

# ライセンス消費が80%超過した際のアラーム設定例
aws cloudwatch put-metric-alarm \
  --alarm-name "SqlServerLicenseUsage80Pct" \
  --alarm-description "SQL Server license consumption exceeds 80 percent" \
  --namespace "AWS/LicenseManager" \
  --metric-name "LicenseConfigurationConsumedLicenses" \
  --dimensions Name=LicenseConfigurationARN,Value=arn:aws:license-manager:ap-northeast-1:123456789012:license-configuration:lic-xxxxxxxx \
  --statistic Maximum \
  --period 3600 \
  --threshold 80 \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --alarm-actions arn:aws:sns:ap-northeast-1:123456789012:LicenseAlerts \
  --treat-missing-data notBreaching

Cost Explorer との連携：

ライセンスコストは EC2 インスタンスコスト・Dedicated Hosts コスト・Marketplace サブスクリプションコストに内包されています。Cost Explorer でタグフィルタリングを活用し、License Asset Groups と同じタグ体系を適用することで、ライセンスコストを近似的に把握できます。

推奨のタグ設計として、LicenseProduct=SQL-Server-Standard などのライセンス専用タグを EC2 インスタンスに付与し、License Asset Groups のフィルター条件と Cost Explorer のフィルター条件を一致させます。これにより、同一のタグ軸でライセンス消費状況（License Manager）とコスト（Cost Explorer）を横断的に分析できます。

Control Tower の AWS Config ルールや Service Control Policy を活用して、ライセンス関連タグの付与を組織全体で標準化することで、Asset Groups と Cost Explorer の双方で一貫した分析が可能になります。コスト全般の分析手法については、既存のコスト最適化記事もあわせて参照してください。

6. マルチアカウント統合・運用・コスト

マルチアカウント環境でのライセンス管理は、License Managerの中でも特に重要な運用領域です。AWS Organizationsと連携することで、管理アカウントから組織全体のライセンス状態を一元管理し、各メンバーアカウントへの設定共有・監査・コスト最適化を実現できます。本セクションでは、Organizations連携の設定から委任管理・RAM共有・運用自動化・コスト管理まで、実践的な手順を解説します。

6-1. AWS Organizations連携の有効化

License Managerのマルチアカウント機能を使用するには、管理アカウントでOrganizations連携を有効化する必要があります。

マネジメントコンソールでの有効化手順:

1. AWSマネジメントコンソールに管理アカウントでサインインし、「Systems Manager」→「License Manager」を開きます。
2. 左側のナビゲーションから「設定（Settings）」を選択します。
3. 「AWS Organizations との統合」セクションで「組織でのリソース共有を有効化」をオンにします。
4. この設定により、管理アカウントがメンバーアカウントのライセンス使用状況を検出できるようになります。

CLIでの有効化:

aws license-manager update-service-settings \
  --enable-cross-accounts-discovery

Organizations統合を有効化すると、管理アカウントは組織内のすべてのメンバーアカウントに対してライセンス設定の共有と使用状況の追跡が可能になります。なお、この機能はRAM（Resource Access Manager）と連携してライセンス設定を共有します。

6-2. 委任管理アカウントの設定

ライセンス管理の権限をセキュリティ専用アカウントや管理専用アカウントに委任することで、管理アカウントへの権限集中を避けつつ、専門チームによる集中管理を実現できます。これはAWS Organizations全体のガバナンス設計の一環として推奨されるアプローチです。

委任管理者の設定（CLIコマンド例）:

管理アカウントで以下のコマンドを実行して、委任管理アカウントを指定します。

# 委任管理者の登録（管理アカウントで実行）
aws organizations register-delegated-administrator \
  --account-id 123456789012 \
  --service-principal license-manager.amazonaws.com

# 登録済みの委任管理者を確認
aws organizations list-delegated-administrators \
  --service-principal license-manager.amazonaws.com

委任管理アカウントに設定されたアカウントは管理アカウントと同等のLicense Manager権限を持ちます。組織全体のライセンス設定の作成・共有・使用状況の追跡が可能になり、管理アカウントへのアクセスを最小限に抑えながら運用できます。

委任管理アカウントに必要なIAMポリシー（最小権限例）:

{
  "Version": "2012-10-17",
  "Statement": [
 {
"Effect": "Allow",
"Action": [
  "license-manager:*",
  "organizations:DescribeOrganization",
  "organizations:ListAccounts",
  "ram:CreateResourceShare",
  "ram:AssociateResourceShare",
  "ram:ListResourceShares"
],
"Resource": "*"
 }
  ]
}

6-3. メンバーアカウントへのライセンス設定共有（RAM連携）

管理アカウントまたは委任管理アカウントで作成したライセンス設定は、RAM（Resource Access Manager）を通じてメンバーアカウントと共有できます。共有されたライセンス設定は、メンバーアカウントのEC2インスタンス起動テンプレートやAMIに関連付けることが可能です。

マネジメントコンソールでの共有手順:

1. License Managerのライセンス設定一覧から、共有したいライセンス設定を選択します。
2. 「アクション（Actions）」メニューから「共有（Share）」をクリックします。
3. RAMの「Resource Share」作成画面が開くので、共有対象としてOrganizations全体・特定のOU・または特定のアカウントIDを指定します。
4. メンバーアカウントでは、共有されたライセンス設定を自分のリソースへ関連付けられるようになります。

CLIでのライセンス設定共有（RAM経由）:

# Organizations全体にライセンス設定を共有するRAMリソース共有の作成
aws ram create-resource-share \
  --name "LicenseManagerOrgShare" \
  --resource-arns "arn:aws:license-manager:us-east-1:123456789012:license-configuration:lic-xxxxxxxxxxxxxxxxxx" \
  --principals "arn:aws:organizations::123456789012:organization/o-xxxxxxxxxx"

この設定により、組織全体で統一したライセンスルールを各メンバーアカウントに適用でき、ライセンス管理ポリシーの一元化が実現します。

6-4. RDS・Marketplace・ユーザーベースサブスクリプションとの連携

License Managerは、EC2以外の複数のAWSサービスやライセンス調達経路とも連携します。

Amazon RDSとの連携:

Amazon RDSではOracle Database、Microsoft SQL Server等のエンジンを提供しています。Oracle DatabaseのBYOLオプションを使用する場合、License Managerとの連携によりRDSインスタンスのライセンス消費をEC2と同様に追跡できます。RDS for Oracle BYOL構成では、ライセンス設定へ「Amazon RDS」を対象リソースとして追加し、インスタンスクラスのコア数に基づくカウントルールを設定します。

AWS Marketplaceとの連携（付与ライセンス）:

AWS Marketplaceで購入したISV製品のライセンスは「付与ライセンス（Granted License）」としてLicense Managerに取り込まれます。購入したライセンスを組織内のメンバーアカウントに付与（Grant）することで、組織全体のMarketplaceライセンス消費を一元管理できます。付与されたライセンスは受け取り側のアカウントで承認操作を行うことで有効化されます。

ユーザーベースサブスクリプションの管理:

Microsoft Remote Desktop Services（RDS）SAL等のユーザーベースサブスクリプションは、License Managerの「User-Based Subscriptions」機能で管理します。Active Directory（AD）と統合することで、AD上のユーザー数に基づいたライセンス消費を自動追跡できます。ユーザーが追加・削除されるたびに消費数が更新されるため、手動での棚卸し作業を省力化できます。

6-5. 運用自動化（EventBridge + Lambda / SSM Automation）

ライセンス違反を検知した際の対応フローを自動化することで、人手を介さないリアルタイムなコンプライアンス維持が可能になります。

EventBridgeでのライセンス違反通知設定:

License Managerはライセンス超過（ソフト制限）を検知したとき、EventBridgeへイベントを発行します。以下の設定でSNSへの通知とLambdaによる自動対応を組み合わせられます。

• イベントソース: aws.license-manager
• イベントパターン: License Manager - License Configuration - Limit Breach
• ターゲット候補: SNSトピック（担当者への通知）、Lambdaファンクション（自動対応処理）

SSM Automation活用例:

SSM AutomationのRunbookを活用することで、以下の定期的な運用タスクを自動化できます。

• 月次のライセンス消費レポートをS3に自動保存する定期ジョブの設定
• 違反を検知したインスタンスへのタグ付け（LicenseViolation: true）による可視化
• 四半期ごとのライセンス棚卸し結果をCloudWatch LogsまたはS3に記録

自動化フロー例:

ライセンス超過検知（License Manager）
  → EventBridge
 → Lambda（インスタンス情報の取得・Slackへの通知）
 → SNS（担当者へメール送信）
  → CloudWatch Logs（監査ログの永続化）

6-6. ライセンスコスト管理と最適化

ライセンスコストの最適化は、License Managerを活用した運用において重要な観点です。ライセンス特化のコスト観点を整理します。

Dedicated Hostsの稼働率最適化:

BYOLでDedicated Hostsを使用している場合、ホストの稼働率を最適化することでコストを削減できます。

• Host Resource Groupを使用してホストの自動配置を有効化し、インスタンスの分散配置による稼働率向上を図ります。
• 使用率の低いDedicated Hostsを定期的にリリースし、需要に応じて動的に確保するよう運用設計します。
• License Managerのダッシュボードで残余ライセンス数を可視化し、過剰購入を防ぎます。

License Included vs BYOLのコスト比較:

どちらが有利かはインスタンスサイズ・使用時間・既存ライセンスの残余によって異なります。Cost Explorerで実際の使用コストを比較検討したうえで判断することを推奨します。コスト全般の分析は既存のCost Optimization記事を参照してください。

Cost Explorerとのタグ連携:

ライセンス関連リソースにコスト配分タグを付与することで、Cost Explorerでライセンス関連コストを部門・プロジェクト単位で分析できます。

# ライセンス関連インスタンスへのタグ付与例
aws ec2 create-tags \
  --resources i-xxxxxxxxxxxxxxxxx \
  --tags Key=LicenseType,Value=SQLServer-Enterprise \
Key=CostCenter,Value=IT-Operations

6-7. 管理アカウントからの一元コンプライアンス確認

管理アカウント（または委任管理アカウント）からは、Organizations全体のライセンスコンプライアンス状態を一元的に確認できます。

License Managerダッシュボードでの確認ポイント:

• 「License Configurations」ビュー: 共有ライセンス設定ごとの消費状況・残余・違反数をリアルタイムで確認します。
• 「Inventory」ビュー: 各メンバーアカウントのEC2インスタンスとそれらに関連するライセンス設定の一覧を参照します。
• 「License Asset Groups」（2025）: 組織横断の統合ビューでライセンス状態をまとめて把握できます。

定期的なコンプライアンスレビューの運用サイクル:

組織規模でのライセンス管理は、以下の定期サイクルで運用することを推奨します。

この運用サイクルを継続することで、監査対応に必要な証跡を常に整備し、ライセンスコンプライアンスを維持できます。マルチアカウント基盤の設計・Organizations構成・委任管理の詳細は本シリーズのマルチアカウント基盤記事を参照してください。

7. 実戦統合パターン — BYOLコスト最適化と監査対応

BYOLライセンスをAWS環境で最大限に活用するには、コスト最適化・監査対応・CI/CDへの組み込みを一体的に運用することが重要です。以下では、License Managerを軸にした実戦的な統合パターンを解説します。

BYOLコスト最適化の実戦パターン

Dedicated Hostsコストとオンデマンドの比較計算
BYOLの経済的メリットは、License Includedインスタンスとの比較で判断します。以下は比較の際に使う代表的な指標です。

既存のライセンス資産（特にEnterprise版）を複数年保有している場合、BYOLはLicense Includedを大幅に下回るTCOを実現できます。License Managerの使用状況ダッシュボードで残余ライセンス数を定期的に確認し、過剰ライセンスがあれば購入計画を見直してください。

残余ライセンスの可視化と過剰購入の削減
License Managerの「ライセンス設定」ページには、割り当て済み数・消費数・残余数がリアルタイムで表示されます。残余が多い場合は以下のアクションを検討してください。

1. 未使用のDedicated Hostsを解放してコストを削減します。
2. ライセンス数上限を実態に合わせて見直します（ソフト制限への変更も含む）。
3. SA更新時にライセンス数量を調整して過剰購入を防ぎます。
4. Host Resource Groupsの自動解放機能を有効化して空のホストを即時解放します。

オンプレミスBYOLライセンスの移行時コスト設計
オンプレミスからAWSへBYOLで移行する際は、既存ライセンスのSAコストと新規Dedicated Hostsコストを合算したTCOを計算します。SQL Server Enterprise 16コアの移行であれば、Dedicated Hostsの時間コスト × 720時間（月）に、SA更新費用（月割り）を加算したものがBYOLの月間コストです。License Includedインスタンスの月間コストと比較し、損益分岐点（通常12〜24カ月）を算出した上で意思決定してください。

監査対応の準備

ソフトウェアベンダーの監査に即応するには、ライセンス消費の証跡を日常的に整備しておくことが必要です。

ライセンス棚卸しレポートの自動生成
License ManagerはAWS Cost and Usage Report（CUR）との連携に加え、独自のレポート生成機能を持っています。EventBridge + Lambdaの組み合わせで月次レポートを自動化できます。

# ライセンス消費状況をJSON出力してS3に保存する例
aws license-manager list-usage-for-license-configuration \
  --license-configuration-arn \
 arn:aws:license-manager:ap-northeast-1:123456789012:license-configuration:lic-XXXX \
  --query 'LicenseConfigurationUsageList[*].{Resource:ResourceArn,Count:ConsumedLicenses}' \
  --output json

このコマンドの出力をS3に保存するLambda関数をEventBridgeのスケジュールイベント（月1回）から呼び出すことで、レポートを自動化できます。

AWS Configルールとの連携
AWS Configのec2-instance-managed-by-systems-managerルールと組み合わせることで、License Managerの管理外に置かれたインスタンスを検出できます。Lambda修復アクションを設定することで、未管理インスタンスを自動的にライセンス設定に関連付けることも可能です。

CloudTrail監査ログの保全
License Managerへのすべての操作（ライセンス設定の変更・関連付け・解除）はCloudTrailに記録されます。ライセンス設定のARNをCloudTrailのフィルタに設定し、監査証跡をS3に長期保管してください。

ベンダー監査への対応手順
監査通知を受け取った際は以下のステップで対応します。

1. License Asset Groupsで対象製品の全使用状況を組織横断で集計します。
2. SSM Inventoryのレポートと照合してオンプレミスとAWSの合算使用数を算出します。
3. CloudTrailログで過去の消費履歴を提示します。
4. ライセンス設定の設定内容（カウントルール・上限）を証拠としてエクスポートします。

CI/CDパイプラインへのライセンスコンプライアンスチェック組み込み

新しいEC2インスタンスをデプロイするCI/CDパイプラインにライセンスチェックを組み込むことで、ライセンス超過を事前に防止できます。

CodePipeline + Lambdaによる実装
パイプラインのApprovalステージ前にLambda関数を配置し、デプロイ予定のインスタンス数が残余ライセンス数を超えないかを確認します。

import boto3

def lambda_handler(event, context):
 lm = boto3.client('license-manager')
 lic_arn = 'arn:aws:license-manager:ap-northeast-1:123456789012:license-configuration:lic-XXXX'

 config = lm.get_license_configuration(LicenseConfigurationArn=lic_arn)
 consumed = config['ConsumedLicenses']
 limit = config['LicenseCount']
 new_instances = event.get('new_instance_count', 1)

 if consumed + new_instances > limit:
  return {'status': 'NG', 'message': f'ライセンス不足: 消費 {consumed}、上限 {limit}'}
 return {'status': 'OK', 'remaining': limit - consumed}

このLambdaをパイプラインのInvokeアクションとして使用することで、ライセンス不足状態での本番デプロイを防ぎます。

Terraform/CloudFormationとの連携
IaC（Infrastructure as Code）側でもライセンス設定の関連付けを必須化します。TerraformではEC2インスタンスリソースにlicense_specificationブロックを追加し、ライセンス設定ARNを指定することでデプロイ時に自動関連付けが行われます。CloudFormationでもLicenseSpecificationsプロパティで同様の設定が可能です。

Windows Server/SQL Server特有の運用パターン

ライセンスモビリティの注意点
Microsoftのライセンスモビリティには90日ルールがあります。同一ライセンスを別のサーバー（Dedicated Hosts間の移動を含む）に適用する場合、前のサーバーから少なくとも90日が経過していなければなりません。AWS上での再デプロイやホスト交換時にこのルールを忘れると、Microsoftの監査リスクが生じます。

90日ルールへの対応策は次のとおりです。
– License Managerの消費履歴とCloudTrailを照合してホスト変更の日時を記録します。
– Dedicated Hosts変更時はEventBridgeでアラートを設定して担当者に通知します。
– SA更新のタイミングで過去90日以内のホスト変更有無を確認します。

SQL Serverエディションの管理
SQL Server StandardとEnterpriseでカウントルールが異なります。エディション混在環境では、ライセンス設定を製品ごとに分けて作成し、SSM Inventoryの製品フィルタを使って自動識別することを推奨します。エディションの誤認識は過少ライセンスや過剰支払いの原因になるため、定期的なインベントリ確認を怠らないようにしてください。

SAP/Oracleライセンス管理の注意点

専有ホスト必須条件の確認
OracleとSAPはAWSの共有型ホスト（通常のEC2）ではBYOLが認められない場合もあります。Dedicated Hostsを使用していること、かつインスタンスのvCPU数に対してライセンス数が充足していることを、License Managerの使用状況ページで定期確認してください。

Oracleライセンス検証の手順

1. Oracle License Management Services（LMS）に事前確認を依頼します。
2. Dedicated Hosts上のvCPU数 × 0.5でOracle Processor License数を計算します。
3. License Managerの消費数と照合します（カウントルールに「物理コア」または「vCPU」を使用）。
4. Oracle ULAの場合は適用可否をOracle営業と事前に協議します。

SAP専有ホストの運用
SAP HANAを複数のAZにまたいで配置する場合は、各AZごとにDedicated Hostsを割り当てます。Host Resource Groupsに両AZのホストを追加してLicense Managerで一括管理します。SAP HANAのライセンス消費数を追跡するには、カウントルールをvCPU単位からメモリ単位に変更する必要があります。SAP固有の要件は変更されることがあるため、SAP on AWS公式ドキュメントで最新仕様を確認してください。

月次・四半期ライセンスレビューの運用フロー

定期的なレビューにより、ライセンスのコンプライアンスリスクとコスト無駄を継続的に低減できます。

月次レビューの実施内容

四半期レビューの実施内容

CloudWatch Alarmsによるライセンス閾値アラート
License ManagerのCloudWatchメトリクスに対してアラームを設定します。残余ライセンス数が20%を下回った段階でSNS通知を送り、事前に購入手続きを開始できるようにします。

aws cloudwatch put-metric-alarm \
  --alarm-name "LicenseNearLimit-SqlServer" \
  --namespace "AWS/LicenseManager" \
  --metric-name "LicenseConfigurationConsumedLicenses" \
  --dimensions \
 Name=LicenseConfigurationARN,Value=arn:aws:license-manager:ap-northeast-1:123456789012:license-configuration:lic-XXXX \
  --statistic Maximum \
  --period 86400 \
  --threshold 13 \
  --comparison-operator GreaterThanOrEqualToThreshold \
  --evaluation-periods 1 \
  --alarm-actions arn:aws:sns:ap-northeast-1:123456789012:LicenseAlerts

これらの月次・四半期運用フローを自動化・定型化することで、ライセンスコンプライアンスを継続的に維持しつつ、ベンダー監査にいつでも対応できる状態を保てます。

ガバナンス統合とハード制限による予防的管理

Organizations委任管理・Control Tower・SCPを組み合わせることで、ライセンスガバナンスを組織全体で標準化できます。

SCPによる予防的コントロール
Service Control Policy（SCP）を使って、特定のライセンス設定に関連付けられていないEC2インスタンスの起動を組織全体で禁止できます。ライセンス設定の関連付けが必須のワークロードに対してSCPを適用することで、プロビジョニング時点でのコンプライアンス確保が可能です。

ハード制限の設計指針
ハード制限（Hard Limit）をライセンス設定に設定することで、ライセンス数上限を超過したインスタンスの起動をプラットフォームレベルで阻止できます。AutoScalingと組み合わせる場合はAutoScalingの最大インスタンス数とライセンス上限を必ず整合させてください。AutoScalingの上限がライセンス上限を超えるとスケールアウト時にインスタンス起動が阻止されてサービス断が発生します。

マルチアカウント環境では組織全体のライセンス使用状況をLicense Asset Groupsで一元管理し、アカウントごとの使用状況を委任管理者アカウントから集中監視する構成を推奨します。この構成により、個別アカウントでのライセンス超過を組織全体として把握し、早期に対処できます。

マルチアカウント委任管理はこちら（マルチアカウント基盤 Vol2）

EC2/Dedicated Hosts基盤はこちら（Compute本番運用 Vol1）

8. つまずきポイント・アンチパターン・まとめ

8.1 つまずきポイント

実運用でよく遭遇する問題と、その対処法を以下にまとめます。

① ハード制限の安易な設定で本番インスタンスの起動が突然阻止される

• 症状: EC2インスタンスの起動時に「You have exceeded your allowed license limit」エラーが発生し、インスタンスが起動できない。AutoScalingグループが期待するキャパシティに達せず、本番サービスに影響が出る。
• 原因: ライセンス設定のカウント上限を実際の使用量ギリギリに設定したため、わずかな増加で上限に達してしまった。スケールアウト時の最大インスタンス数とライセンス上限の整合性を検討していなかった。
• 対処法: ライセンス設定の上限を実際の使用量より20〜30%の余裕を持って設定します。CloudWatchアラームでライセンス消費量が上限の80%を超えた時点で通知を受けるように設定し、事前に対処できる運用フローを整備してください。新機能や増設の際は、事前にライセンス設定を確認・更新するチェックリストを用意することを推奨します。

② ソフト制限のみで違反を放置し、ベンダー監査で超過が発覚する

• 症状: ベンダー監査の際、License Managerで記録された違反（non-compliant）履歴を提示され、追加ライセンス費用や違約金を請求される。
• 原因: ソフト制限を設定したまま違反通知を無視し続けた。EventBridgeやSNSへの通知設定を行っておらず、違反状態をリアルタイムで検知できなかった。
• 対処法: ソフト制限を使う場合は必ずEventBridge→SNSによる通知設定を行い、違反発生から48時間以内に対応するワークフローを整備してください。定期的に違反レポートを確認する運用サイクルも重要です。本番環境でコンプライアンスリスクが高いライセンスはハード制限への移行を検討してください。

③ カウント方式の誤り（vCPU vs 物理コア）でライセンス計算がずれる

• 症状: License Managerのダッシュボードと実際のライセンス保有数が一致しない。ベンダーとの計算方式が異なり、監査時に差異が発生する。
• 原因: ベンダー契約が物理コア単位であるにもかかわらず、License ManagerでvCPUカウントを選択してしまうケースです。または逆の設定ミスも起こります。カウント方式は作成後に変更できないため、誤設定に気づいてからの修正が困難になります。
• 対処法: ライセンス設定を作成する前に、ベンダーの契約書で「ライセンスカウントの単位」を必ず確認してください。不明な場合はベンダーのライセンス専門チームに問い合わせてから設定します。既存の設定を変更する場合は、旧設定を削除して新しい設定を作成する必要があります（カウント方式の後から変更はできません）。

④ Dedicated Hosts未使用で物理コアBYOL要件を満たせない

• 症状: Oracle DatabaseやSAP HANAをEC2（共有テナンシー）で実行しているが、物理コアベースのBYOLライセンス要件を満たせず、ライセンス違反となる。ベンダー監査で追加費用が発生する。
• 原因: BYOLで物理コア単位のライセンスを持ち込む場合、物理コアの可視性を確保するためにDedicated Hostsが必要であることを見落としていた。
• 対処法: 物理コア単位のBYOLライセンスを使用する場合は、必ずDedicated Hostsを使用してEC2インスタンスを起動します。Dedicated HostsとHost Resource Groupsを組み合わせてLicense Managerによる自動管理を設定してください。既存インスタンスの移行は、メンテナンスウィンドウを設けて段階的に実施することを推奨します。

⑤ Organizations統合なしでクロスアカウントのライセンス検出ができない

• 症状: マルチアカウント環境で各アカウントのライセンス消費を一元的に確認できず、組織全体のライセンス状況が把握できない。アカウントごとに個別に確認が必要で、全体像が掴めない。
• 原因: AWS Organizations統合を有効にせず、各アカウント独立でLicense Managerを運用していた。クロスアカウントのリソース検出が設定されていなかった。
• 対処法: License ManagerでAWS Organizations統合を有効化します。管理アカウントのLicense Managerコンソールから「Organizations設定」→「クロスアカウントリソース検出を有効化」を設定します。License Asset Groupsを活用することで、Organizations全体のライセンス状態を一元的な統合ビューで管理できるようになります。

⑥ SSM Inventory未設定でオンプレミスのソフトウェア棚卸しが漏れる

• 症状: オンプレミスサーバーにインストールされたソフトウェアがLicense Managerに反映されず、ハイブリッド環境でのライセンス管理が不完全になる。オンプレの実態が不明なままライセンスを購入・調整していた。
• 原因: Systems Manager Agentのインストールとマネージドインスタンスとしての登録が完了していない。またはSSM Inventoryが有効化されていなかった。
• 対処法: オンプレミスサーバーにSSM Agentをインストールし、SSM Hybrid Activationsを使ってマネージドインスタンスとして登録します。State Managerの関連付けでSSM Inventoryを定期実行し、収集したインベントリデータをLicense Managerのライセンス追跡に活用してください。

⑦ 委任管理者未設定で管理アカウントへの権限が集中する

• 症状: ライセンス管理担当者が管理アカウントへの直接ログインを余儀なくされており、最小権限の原則を逸脱した運用となっている。管理アカウントへのアクセス者が増え、セキュリティリスクも高まっている。
• 原因: License Managerの委任管理者（delegated administrator）機能を活用せず、管理アカウントで直接すべての操作を担当していた。
• 対処法: Organizations管理アカウントから、ライセンス管理用アカウントをLicense Managerの委任管理者として設定します。委任管理者アカウントから組織全体のライセンス状況を参照・管理できるようになり、管理アカウントへの直接アクセスを不要にできます。

⑧ License Asset Groupsのルール設計ミスで集約が漏れる

• 症状: License Asset Groupsで作成したグループにリソースが集まらない、または期待しないリソースが含まれてしまう。ライセンス状態の統合ビューが不正確になる。
• 原因: フィルタールールの設定（タグ・製品情報・アカウント条件など）が不正確で、対象リソースを適切に絞り込めていなかった。タグ設計が整備されていなかったことも原因のひとつです。
• 対処法: License Asset Groupsのルール設定前に、対象リソースのタグ設計を整備してください。タグベースのフィルタリングが最も確実な方法です。ルール設定後は「プレビュー」機能で対象リソースを確認してから保存することを推奨します。

8.2 アンチパターン → 正解

実運用でよく見られるアンチパターンとその正解パターンを以下にまとめます。

8.3 運用チェックリスト

License Managerの安定運用に役立つ定期チェックリストを以下に示します。

月次チェック:

• [ ] ライセンス消費レポートを確認し、消費数・残余数・違反フラグを確認する
• [ ] 違反（non-compliant）リソースがある場合、根本原因を調査して対応する
• [ ] ユーザーベースサブスクリプションの付与ユーザー一覧をレビューし、不要なライセンスを解除する
• [ ] Dedicated Hostsの稼働率を確認し、空きホストのコスト最適化を検討する

四半期チェック:

• [ ] ライセンス設定の上限値と実際の最大使用量を比較し、適切な余裕が確保されているかを確認する
• [ ] Organizations全体のライセンス消費をLicense Asset Groupsで集約確認し、アカウント間の偏りを把握する
• [ ] SSM Inventoryによるオンプレミス棚卸し結果をレビューし、ライセンス設定と整合していることを確認する
• [ ] CloudWatchアラーム設定を見直し、閾値が現在の運用状況に合っているかを確認する

年次チェック（ベンダー契約更新時）:

• [ ] ライセンス設定の上限数をベンダー契約の更新内容に合わせて修正する
• [ ] 不要になったライセンス設定を削除または無効化してクリーンアップする
• [ ] BYOLライセンスのロールとLicense IncludedのAMIを比較し、コスト最適な構成を維持できているかを評価する
• [ ] 委任管理者アカウントの権限設定が最小権限を維持しているかを確認する

8.5 よくある質問（FAQ）

License Managerの導入・運用でよく寄せられる質問と回答をまとめます。
設定ミスや誤解が生じやすいポイントを中心に、実運用に役立つ情報を提供します。
サービス設計・移行・日常運用の各フェーズで参照してください。
より詳細な情報はAWS公式ドキュメントも合わせてご確認ください。

Q1. ライセンス設定のカウント方式（vCPU/物理コア/ソケット等）は後から変更できますか？

A. できません。カウント方式はライセンス設定の作成時のみ設定可能で、作成後の変更は不可です。誤設定に気づいた場合は、AMI・インスタンスとの関連付けをすべて解除した後に旧設定を削除し、正しいカウント方式で新しいライセンス設定を作成し直す必要があります。設定前にベンダー契約書でカウント方式を確認することが重要です。

Q2. AWS Organizations統合を有効にすれば、メンバーアカウントのリソースが自動でライセンス設定に追跡されますか？

A. 「検出・参照」は可能になりますが「自動関連付け」はされません。Organizations統合は管理アカウントから各メンバーアカウントのライセンス消費状況を横断的に参照できるようにする機能です。メンバーアカウントへのライセンス設定の関連付け自体は、Grant機能による再配布または各メンバーアカウント内での個別設定が引き続き必要となります。

Q3. License Manager単体でライセンスコンプライアンスは法的に保証されますか？

A. 保証されません。License Managerはライセンス使用状況の追跡・制限を自動化するサービスです。法的コンプライアンスはソフトウェアベンダーとの契約に基づくものであり、License Managerに設定するカウントルールと上限がベンダー契約の条件を正確に反映していることが前提です。設定内容はベンダーのライセンス担当者と事前に照合し、定期的に見直すことを強くお勧めします。

Q4. ユーザーベースサブスクリプションに登録したユーザーが退職した場合、ライセンス割り当ては自動解除されますか？

A. 自動解除されません。Active Directoryでのユーザー無効化・削除後も、License Managerのサブスクリプション割り当ては手動で解除するまで残り続けます。退職者対応プロセス（HR通知→AD無効化→License Managerサブスクリプション解除）を定型化し、ライセンスの空き枠を確実に回収する運用フローを整備してください。

Q5. AMIにライセンス設定を関連付けた場合、関連付け前に起動済みのインスタンスも自動で追跡されますか？

A. 関連付け前に起動済みのインスタンスは自動追跡の対象外です。AMIへの関連付けは、それ以降に起動するインスタンスにのみ適用されます。既存の稼働中インスタンスについては、EC2コンソールの「アクション」→「ライセンス設定の変更」またはCLI（modify-instance-license-specification）を使ってインスタンスに直接ライセンス設定を関連付けてください。

Q6. License Managerで追跡できるのはAWSリソース（EC2等）のみですか？

A. いいえ。SSM AgentとSSM Hybrid Activationsを使ってオンプレミスサーバーをマネージドインスタンスとして登録し、SSM Inventoryと連携することで、オンプレミス上のソフトウェアもLicense Managerで追跡できます。AWSとオンプレミスを統合したハイブリッドライセンス管理が実現でき、単一のダッシュボードで組織全体のライセンス状況を把握できます。

8.4 まとめ

AWS License Managerは、Microsoft・Oracle・SAPなどのソフトウェアライセンスをAWS上でルール化し、使用状況の追跡・違反検知・コンプライアンス管理を自動化するマネージドサービスです。

本記事で取り上げた主な内容:

• ライセンス設定: 自己管理ライセンス・付与ライセンス・ユーザーベースサブスクリプションの3種類。カウント方式（vCPU/物理コア/ソケット/インスタンス数）はベンダー契約に合わせて選択します。
• ハード/ソフト制限: ハード制限は違反を完全に防止しますが、上限設定に余裕が必要です。ソフト制限は柔軟性がありますが、必ず違反通知を設定して放置しない運用が求められます。
• BYOL & Dedicated Hosts: 物理コア/ソケット課金のBYOLにはDedicated Hostsが必須です。Host Resource Groupsで自動管理を実現できます。
• トラッキング & コンプライアンス: SSM Inventoryとの統合でハイブリッド環境のソフトウェアを検出し、EventBridge通知で違反を即座に把握できます。
• License Asset Groups（2025年新機能）: Organizations全体のアカウント・リージョンを横断した統合ビューを提供し、断片的な可視性の課題を解消します。
• マルチアカウント統合: Organizations統合と委任管理者の組み合わせで、組織全体のライセンスを中央集権的かつセキュアに管理できます。

License Managerが解決する3つの課題:

1. コンプライアンス: ハード制限とソフト制限でライセンス違反を予防・検知し、ベンダー監査に対応できる証跡を整備できます。
2. 可視性: ダッシュボード・License Asset Groups・消費レポートでライセンス使用状況をリアルタイムに把握し、過剰/過少ライセンスを即座に発見できます。
3. コスト最適化: BYOLとDedicated Hostsの組み合わせでLicense Included AMIより大幅なTCO削減が可能です。残余ライセンスの可視化で過剰購入を防止できます。

Vol2では、マルチアカウントの高度な委任管理・ライセンス消費の自動レポート生成・Terraformを使ったライセンス設定のIaC管理など、より実践的なトピックを取り上げる予定です。
ライセンス管理のさらなる自動化に向けて、ぜひVol2もご参照ください。