Organizations can automate private-pricing activation for third-party models on Amazon Bedrock through AWS License Manager, using either a one-time script or an event-driven AWS Cloud Development Kit (AWS CDK) deployment. The crucial step is grant activation: accepting a private offer and receiving an entitlement do not, by themselves, complete the path to negotiated pricing. AWS describes both automation approaches.
For platform engineers, the choice depends on whether they need to activate an existing set of trusted licenses or continuously process new agreements. It also depends on the trust controls required: the lightweight script has no seller allow-list, while the event-driven implementation checks sellers before creating and activating distributed grants.
How private offers become usable entitlements
AWS Marketplace Private Pricing Offers (MPPOs) let customers negotiate custom rates for third-party models available through Bedrock. Managed entitlements allow an organization to subscribe from a central account and distribute access across its AWS accounts, reducing the need to handle the same offer separately in each workload account.
According to AWS’s technical walkthrough, accepting an eligible private offer causes AWS Marketplace to create a license in AWS License Manager. In AWS Organizations with all features enabled, organization-level grants are automatically accepted, but remain Disabled until activated.
That distinction explains the purpose of the automation. An accepted agreement establishes the commercial arrangement; the grant still needs to reach the required state. AWS says negotiated pricing applies only after activation reaches ACTIVE or WORKFLOW_COMPLETED.
The operational implication is that an agreement-acceptance check alone is insufficient. Teams need to verify the resulting grant status as well. Otherwise, the procurement workflow can appear complete while the activation needed for negotiated pricing remains unfinished.
Choose between one-time activation and ongoing processing
AWS presents the two paths as alternatives for different operational needs:
| Consideration | Lightweight script | Event-driven CDK deployment |
|---|---|---|
| Intended use | One-time activation of trusted received licenses | Ongoing processing of Marketplace agreement events |
| Initial behavior | Lists received licenses and prints a dry-run plan | EventBridge invokes Lambda when a matching agreement event arrives |
| Seller control | No seller allow-list | Lambda verifies a seller allow-list |
| Execution model | Reviewed and explicitly applied by an operator | Automation deployed in the AWS management account |
| Outcome visibility | Review the plan and validate activation and billing afterward | CloudWatch Logs records processing outcomes; verify grant activation and billing |
The decision is therefore about both frequency and scope of trust. A one-time task can suit the script, but only if every received license in the management account is trusted. Recurring agreements and the need for seller filtering point toward the CDK implementation.
Path 1: review and activate trusted licenses
The lightweight path is a standalone script that lists received licenses and produces a dry-run plan. It gives operators a chance to inspect the licenses and their issuers before applying changes.
As described in The Chenab Times’ account of the implementation, the process starts with the sample repository, followed by a dry run, review, and a subsequent invocation with confirmation flags to activate organization-wide grants. The script’s lack of a seller allow-list is a material limitation: AWS explicitly restricts this path to situations where all received licenses in the management account are trusted.
For engineers evaluating the approach, reviewing the dry-run output is the central control. The trust assumption covers the received-license set, so the decision cannot rest solely on recognizing one expected license among the results.
After applying changes, validate the billing path to confirm that the negotiated discount is being applied. The source material recommends this verification after activation; a completed script run should not substitute for checking the result.
Path 2: process agreements through EventBridge and Lambda
The event-driven path uses AWS CDK to deploy automation in the AWS management account. AWS documents a specific event route: the stack listens on the default event bus in us-east-1, matching source aws.agreement-marketplace and detail type Purchase Agreement Created - Acceptor.
That EventBridge rule invokes an AWS Lambda function. The documented processing sequence is:
- Receive the Marketplace agreement event.
- Verify the seller against the allow-list.
- Discover the associated license.
- Create the distributed grant.
- Request activation with
CreateGrantVersion(Status=ACTIVE). - Log the outcome to Amazon CloudWatch Logs.
These identifiers describe AWS’s implementation; the activation expression is not a complete executable example. The important operational boundary is between requesting activation and confirming that the grant has reached the state required for negotiated pricing.
The seller check also changes the trust model relative to the script. Instead of relying on trust in every received license, the event-driven path checks the seller during agreement processing. CloudWatch Logs provides a record of outcomes for auditability.
The grants can target the entire organization, specific organizational units (OUs), or individual accounts, according to The Chenab Times. That makes distribution scope a deployment decision alongside the seller allow-list: engineers need to identify both which sellers are permitted and which parts of the organization should receive the grant.
Check prerequisites and scope before deployment
The reported prerequisites for the CDK path are the AWS Organizations management account, deployment in us-east-1, Python 3.12+, AWS CDK v2, and AWS Organizations with all features enabled. The region here describes the documented automation deployment and event listener; it should not be read as a statement about every Bedrock workload’s deployment region.
This automation applies to License Manager-backed Bedrock models. Software as a service (SaaS) products are explicitly outside its scope, so the workflow should not be generalized to every Marketplace purchase.
For an implementation review, the decisive checks are concrete: confirm that the product is in scope, choose the appropriate trust control, inspect the intended grant recipients, and verify the final activation state and billing outcome. The value of the automation is in carrying a negotiated agreement through entitlement activation. Its success should be assessed at that endpoint, rather than at offer acceptance or event delivery alone.
