AWS Activate credits and Marketplace spend: check the uncovered line items

Classify AWS Activate charges using both the promotional-credit terms and the programme-specific exception. Marketplace spending is generally excluded unless authorized, while current Activate terms specifically address third-party foundation-model spend on Amazon Bedrock.

Split a planned bill by charge type

Create separate rows for compute, storage, support, upfront commitments, Marketplace subscriptions and model usage. Include seller, service identifier and procurement route. A single architecture dependency can create multiple charge types, so do not classify an entire stack from one product name. Capture the credit’s applicable products and expiry from the account. The public AWS credit terms define exclusions, while an actual award can impose additional conditions. Keep the source and date beside each coverage decision so a later reviewer can distinguish verified eligibility from an assumption made during estimation.

Current primary documentation

Read the general rule and the specific exception together

AWS’s promotional terms exclude Marketplace and upfront fees such as Savings Plans or Reserved Instances unless authorized. The current Activate terms, updated 22 January 2026, make Marketplace an eligible service solely for the described Bedrock third-party model spend. That exception is not a blanket Marketplace allowance. Check the exact model route and the actual credit configuration before budgeting an offset. A third-party subscription outside that route cannot be relabeled as inference to make it covered. Approval, account access and model availability remain separate questions from the programme’s permitted credit use.

Model the uncovered portion without promised reimbursement

In a synthetic bill, compute costs 100 units, an upfront commitment costs 200 and a Marketplace add-on costs 50. Treat the 250 units as cash exposure unless the applicable terms establish authorization; even the compute offset needs the credit’s product and timing confirmation. These invented units are a classification example, not vendor prices. Add a separate row for an eligible Bedrock model route if the team actually plans one, rather than changing the add-on’s classification. A budget that only shows the net total can hide the precise line that will remain payable.

AWS Activate terms: specific Bedrock Marketplace exception

Review provider and procurement changes

A model name alone may not tell the full billing story. Record whether access is through the intended AWS service, a Marketplace product or a direct external subscription. Recheck coverage when changing a provider, purchasing route or commercial agreement. Keep a bounded support question ready when the award terms and planned route are unclear. Do not create a purchase to test an unapproved financial assumption. The coverage worksheet is most useful before the team adopts a dependency that is expensive to remove or commits to a term extending beyond the credit expiry.

Reconcile consumption after an authorized rollout

Compare the first relevant bill with credit application history and retain the account-specific result. A successful model response proves technical access for that request, not a future billing offset or an unlimited allowance. Preserve uncovered costs in the post-credit forecast and give each experiment an owner and shutdown condition. This guide made no AWS purchase and claims no reimbursement entitlement. The operational outcome is an explainable classification record that can be updated when programme terms, credit configuration or the product’s billing route changes.

AWS Activate credits readiness

Cloud credits versus cash runway

Bring the planned charge lines and actual award terms to review post-credit operating exposure.

B2B SaaS development: scope and acceptance