Large cloud customers rarely pay list rates on a blank slate. They sign multi-year agreements that commit them to a minimum spend in exchange for discounts — and then every purchasing decision inside the company faces the same question: does this count toward the commitment? Claude usage is no exception. Because the four third-party platforms bill through different mechanisms, the same workload can either decrement your committed spend or sit outside it entirely, depending on which door you pick.
A quick refresher on the billing surfaces
Claude Platform on AWS and Claude in Microsoft Foundry both bill in Claude Consumption Units (CCUs) at $0.01 per CCU, metered hourly to their respective cloud marketplaces and invoiced monthly in arrears — AWS Marketplace for Claude Platform on AWS, Azure Marketplace for Foundry. Amazon Bedrock and Google Vertex AI bill per token directly on your AWS and Google Cloud bills. In all four cases, marketplace list prices match Anthropic's first-party list prices, and committed-use discounts are negotiated with the cloud provider, not with Anthropic.
The Azure side: MACC eligibility is documented
A Microsoft Azure Consumption Commitment (MACC) is a contractual promise to spend a certain amount on Azure over a term. Microsoft's documentation is explicit about how Claude interacts with it: the CCU meter on Foundry is MACC-eligible — Claude spend decrements your commitment like other Azure Marketplace consumption. Just as explicitly, Microsoft notes that CCU billed on other clouds does not. If your organization has an underused MACC and a deadline, Foundry has a structural head start regardless of what the engineering comparison says.
Negotiated Claude discounts on Azure arrive as Marketplace private offers, applied at the token-to-CCU conversion step, and can carry different rates per model — so your effective price and your commitment drawdown are both visible in the same CCU line in Azure Cost Management.
The AWS side: marketplace billing, two separate offers
On AWS you have two Claude routes, and their commercial plumbing is separate. Claude Platform on AWS bills CCUs through AWS Marketplace. Bedrock bills tokens as native AWS service usage, with the underlying model access running through an AWS Marketplace subscription that is auto-initiated the first time you invoke an Anthropic model. Critically, Anthropic's documentation warns that discounts and AWS Marketplace private offers do not transfer automatically between Bedrock and Claude Platform on AWS, and cannot be applied retroactively to usage that occurred before the offer was accepted. A negotiated Bedrock discount does nothing for your Claude Platform on AWS traffic, and vice versa — negotiate for the surface you will actually use, before you ramp.
How committed spend should (and shouldn't) steer platform choice
Let it break ties, not requirements. Because list prices are identical across platforms, the marginal dollar cost of a token is roughly the same everywhere; the commitment question changes which budget the dollar comes from, not how many dollars there are. That makes committed spend a legitimate tiebreaker between platforms that both meet your needs — and a terrible reason to land on a platform missing a feature you depend on. If your workload needs the Message Batches API or server-side web tools, Bedrock and Vertex AI can't run it no matter how attractive the commitment math looks; if it needs Anthropic's Managed Agents, only Claude Platform on AWS offers that among the 3P surfaces.
Watch the migration seam. Teams sometimes prototype on Bedrock (fastest path in an AWS shop) and later move to Claude Platform on AWS for feature parity. That move crosses a commercial boundary even though both live in AWS: separate marketplace offers, separate discounts, and a capacity pool separate from both the first-party API and Bedrock. Plan the commercial conversation alongside the technical one.
Multi-cloud enterprises: put the workload where the commitment is thirstiest — within reason. If you hold both a MACC and an AWS commitment, Claude is one of the few workloads portable enough to genuinely arbitrage between them, since the models and the Messages API are the same. The portability tax is operational (different auth, model-ID forms, and feature gaps), not contractual.
Where to go next
For turning the two billing shapes into one spend model, read normalizing costs across CCU and per-token billing. For the discount programs themselves, see committed-use discounts and Foundry marketplace billing.