交渉済みのモデル価格が、そのままワークロードで使える価格とは限らない。AWSが10月13日に公開した管理対象エンタイトルメントの説明は、対象となる第三者製Amazon Bedrockモデルのこの問題を扱う。Marketplaceの非公開オファーを受け入れるとライセンスが作られるが、組織に配布したgrantは受諾済みでも無効のままの場合がある。
AWSは二つの方法を示した。Pythonスクリプトは、受領ライセンスを管理者が一度確認して有効化する。イベント駆動のCDKサンプルは、反復する契約を販売者確認、grant作成、有効化、再試行、ログで処理する。どちらも値引き交渉をするものではなく、導入だけで節約が証明されるわけでもない。
中央の商用契約を、開発、本番、事業部、地域の各アカウントで利用できる条件へ変えるのが狙いだ。同時に、販売者や対象範囲の誤りの影響も大きくなる。調達承認、技術的有効化、請求確認は別の出来事である。
ライセンス、grant、請求を分ける
AWS Marketplace Private Pricing Offers、略してMPPOは、交渉済みの商用条件を定める。License Managerに対応する対象Bedrockモデルでは、オファー受諾からライセンスが生まれ、管理対象エンタイトルメントはgrantを通じて組織、指定組織単位、個別アカウントへ権利を配る。
AWS Organizationsの全機能を有効にすると、組織向けgrantは自動受諾されるが、有効化が必要だ。AWSは料金適用の状態としてACTIVEまたはWORKFLOW_COMPLETEDを挙げる。受諾済みオファーと設定済み対象が見えても、対象利用が交渉料金の経路に入っていない可能性がある。
全機能なしの一括請求では受領側による手動受諾が必要だ。中央請求と完全な組織統合は同じではない。ライセンス制御リソースはus-east-1で管理され、Bedrockの呼び出しが別の対応地域でも変わらない。
grant先の利用は元のサブスクリプションアカウントに請求され、各受領者が独立契約する形ではない。可視性は集中するが、内部配賦は残る。タグ、費用区分、責任者はショーバックやチャージバックに必要で、ライセンス状態、実際の呼び出し、実効料金も別々に観測する。
スクリプトは範囲を限定した人の操作
単独Pythonツールは管理アカウントの受領ライセンスを一覧化する。既定はdry-run計画で、grant作成や有効化はしない。担当者が発行者、ライセンス、対象範囲を調べ、--applyと管理アカウントIDを明示して実行する。
選択した受領ライセンスに組織全体のgrantを作成して有効化するため、既知の滞留や低頻度の契約に適する。常設CDKは不要だが、継続的なポリシーエンジンではない。
重要なのは販売者許可リストがないことだ。担当者が発行者を調達記録と受諾済み契約に照合することが信頼境界になる。新着を何でも無人で繰り返し処理すれば、その境界を維持するのではなく取り除いてしまう。
組織全体の対象にも明確な承認が必要だ。規制業種では臨床本番と研究を分けたり、承認済みの開発・本番単位にモデルを限ったりする。有効化が技術的に成功しても、業務上の認可を超えることはある。
実行後はLicense Manager状態を確認し、Cost Explorerにデータが来てから代表的な対象料金を調べる。AWSは請求表示に数時間から数日かかる場合があるとする。有効なgrantは処理完了の証拠であり、即時の請求保証ではない。割引確認ツールの発行者とアカウント入力も実契約に合わせる必要がある。
CDKが受けるのは契約イベント
反復処理はEventBridge、Lambda、DynamoDB、License Manager、CloudWatchを組み合わせる。us-east-1の既定イベントバスの規則は、ソースaws.agreement-marketplace、詳細タイプPurchase Agreement Created - Acceptorを照合する。
LambdaはDynamoDBの販売者許可リストを確認し、承認済みなら関連ライセンスを探す。設定対象のgrantを作り、CreateGrantVersionでactive状態への変更を要求する。
契約イベントは下流の準備完了を保証しない。新規grantが直ちに有効化可能とは限らないため、サンプルはLicense Managerの処理を待って再試行する。CloudWatchは有効化、延期、スキップを記録するが、販売者や対象を認可した承認記録の代わりではない。
デプロイ元はOrganizations管理アカウント、地域はus-east-1、組織は全機能有効、オファーはLicense Manager対応Bedrockモデルである必要がある。SaaSは対象外で、Marketplaceの全非公開オファーを処理する汎用品ではない。
License ManagerとMarketplaceの両方で信頼されたアクセスとサービスリンクロールが必要だ。ブートストラップツールは前提を確認し、アカウント明示確認後のapplyで統合有効化とロール作成ができる。構成は組織ID、検証済み販売者、通知、任意対象を含む。対象未指定なら全組織に配布し、組織単位や個別アカウントで狭められる。
販売者と対象範囲が制御境界
AWSは販売者許可リストを安全上の境界と説明する。表示名だけではなく、受諾契約または受領ライセンスから販売者アカウントIDを確認すべきだ。未確認または広すぎる登録は、全対象への意図しないgrantを許し得る。
ただしモデルが企業データへ無制限にアクセスできるわけではない。IAM、サービス制御、モデル権限、アプリ設計が実利用を管理する。エンタイトルメントは商用条件の適用資格と請求集中を変える重要な仕組みだが、全データ権限と同一ではない。
組織単位なら既存階層に合わせられる。個別アカウントは狭い一方、新規追加時に保守が必要だ。全組織は中央基盤には便利でも、規制環境では環境別・データ分類別の承認が必要になる。
販売者ID、組織ID、対象の変更はレビューと管理された配備を通す。失敗と反復延期に通知を設け、イベント配信とライセンス準備を別に扱う。遅延、重複、欠落を想定し、静かなログから完了を推測してはいけない。
照合は受諾契約、受領ライセンス、承認対象、有効grantを比べる。未有効契約、想定外対象、現行承認契約のないgrantを見つけられる。スクリプトによる復旧も自動基盤と担当を共有し、重複や範囲競合を防ぐ。発行者対応表、承認、復旧手順は障害時にも参照可能にする。
中央購買は契約判断を置き換えない
調達は契約、基盤担当は配布と有効化、安全担当は信頼と範囲、FinOpsは料金と配賦を担う。責任不明確なら小さなアカウントごとの遅れが中央の遅れに置き換わる。
顧客Heidi Healthは、第三者基盤モデルで週数百万件の診療相談を支えると説明する。基盤責任者Marcus Lauは、非公開料金がアカウントや組織単位ごとの利用と条件の把握に役立ち、モデル追加時の自動grantが重要だと述べた。顧客の見解であり、独立した節約実証ではない。
更新、新契約、組織再編には確認が必要だ。自動化は契約範囲、修正、発効日を解釈しない。将来発効する受諾契約は新条件の即時利用を意味せず、モデル、地域、製品の追加も既存契約で自動的に覆われない。
成功には三種類の証拠が一致する必要
第一に契約イベントから有効状態までを測り、販売者拒否、発見遅延、延期、手動介入も含める。第二に更新やアカウント変更後の契約、ライセンス、対象、grantを照合する。第三に請求表示後、代表利用の条件、発行者、請求責任者を確認する。
導入はdry-runと一つの確認済みライセンスから始め、少数販売者と狭い対象でイベント処理を試す。ログ、状態、請求が一致してから拡大する。未知販売者、欠落イベント、有効化遅延、想定外請求の復旧を用意する。
スクリプトは人が確認できる限定的で信頼済みの作業に、CDKは安全に方針をコード化できる反復契約に向く。問うべきは自動化の量ではなく、各契約の正確な販売者、認可対象、期待状態、請求責任者が明確かどうかだ。