Claude on AWS, Azure or Google Cloud: Which to Pick?

Enterprises often have to buy software through the cloud they already pay for, and Claude is now sold through every major one. What is less obvious is that most clouds offer Claude in two different ways, with different operators, feature sets and data terms. I went through Anthropic's and each cloud's documentation in early 2027 to map the routes; this post is the summary I wish clients had when they ask "can we use Claude on our cloud?"

How many ways can you buy Claude?

There are seven routes as of early 2027, grouped by who runs the inference stack.

Sources: Claude in Amazon Bedrock, Claude Platform on AWS, Claude Models on Google Cloud, Claude in Microsoft Foundry.

The split that matters is the operator. When AWS or Google operates the model, your data stays under that cloud's data terms. Anthropic's Bedrock page describes Claude in Amazon Bedrock as running on AWS-managed infrastructure "with zero operator access", so Anthropic staff cannot reach it. When Anthropic operates it, even if a cloud handles login and billing, Anthropic is the data processor; the Claude Platform on AWS page says so directly.

What features do you lose on each cloud?

Cloud-operated routes get new features on the cloud's release schedule, and several API features are not available at all. Anthropic publishes the gaps.

On Claude in Amazon Bedrock, the unsupported list includes URL sources for images and documents, the Files API, server-side tools (code execution, web search, web fetch, advisor), Agent Skills, the MCP connector, programmatic tool calling, the Message Batches API and Claude Managed Agents. The Google-managed offering lists almost the same gaps. On the Bedrock side, AWS runs its own batch inference for select Anthropic models at 50 percent off on-demand prices, so overnight work is still possible through Bedrock's API.

On Microsoft Foundry, the Anthropic-hosted version supports more than the Azure-hosted one. The Foundry guide lists code execution, newer web search and web fetch versions, Agent Skills, programmatic tool calling and the Files API as unavailable when hosted on Azure, and the Message Batches and Admin APIs as unavailable on Foundry in general.

The Anthropic-operated cloud routes sit closest to the Claude API. Claude Platform on AWS describes its feature availability as "typically same-day as Claude API", with beta features passed through by header.

If your product depends on server-side tools such as web fetch or code execution, that table decides for you. If it only needs messages, streaming, tools you run yourself and caching, every route works.

How does pricing compare across clouds?

Token prices are close across routes; the differences are in billing mechanics and residency premiums.

• Anthropic-operated marketplace routes. Claude Platform on AWS and Claude in Microsoft Foundry bill in Claude Consumption Units through the cloud marketplace. Anthropic's pricing page says usage is rated at standard per-model rates and converted at $0.01 per CCU, metered hourly and invoiced monthly in arrears.
• Cloud-operated routes. Bedrock and the Google-managed offering are priced on the cloud's own pricing pages, which the same Anthropic page links to.
• Residency. On Bedrock and the Google-managed offering, regional and multi-region endpoints cost 10 percent more than global ones for Sonnet 4.5 and later. On the Claude API, Claude Platform on AWS and the Google Anthropic-managed offering, US-only inference applies a 1.1x multiplier, and Foundry's US Data Zone deployment applies the same multiplier.

As a reference point, Anthropic lists Claude Sonnet 5.5 at $2 per million input tokens and $10 per million output tokens on the Claude API. Check the cloud's page for its current figure before you budget.

The practical point for procurement: if the company has a committed spend with AWS, Google or Microsoft, marketplace billing can count Claude usage against it. Ask your account team to confirm for your contract, because that depends on the agreement, not on the docs.

Data, compliance and regions

The compliance question is really "whose data terms apply". Cloud-operated routes follow the cloud's terms: Anthropic's Bedrock page sends you to Amazon Bedrock data protection, and its Google-managed page sends you to Google's data governance terms. Anthropic-operated routes follow Anthropic's data use terms, with zero data retention available on request for Claude Platform on AWS.

Regions and quotas differ too:

• Bedrock. Global, geographic (US, EU, JP, AU and others) and in-region endpoints, with a default quota of 2 million input tokens per minute on Claude in Amazon Bedrock.
• Google managed. Global, US or EU multi-region, and regional endpoints, though regional endpoints only serve Sonnet 4.6 and earlier.
• Foundry. Global Standard for all Claude models and US Data Zone Standard for the Azure-hosted ones, per Microsoft's Claude page. Microsoft also notes that Foundry does not apply built-in content filtering to Claude at deployment time, so plan your own safety checks.

If you sell into the EU, residency is only one part of the picture; the obligations in the EU AI Act deadline post apply whichever route you take.

Common mistakes when buying Claude through a cloud

Most problems I see come from assuming every route behaves like the Claude API. A few to check before you build:

• Assuming feature parity. Code that uses web fetch, code execution or the Files API will fail on the cloud-operated routes. Check the unsupported list for your route before you design the feature.
• Using the wrong client. On Google Cloud, the two offerings use different SDK clients: AnthropicVertex for the Google-managed one and AnthropicGoogleCloud for the Anthropic-managed one, according to Anthropic's Google Cloud overview. They also use different request formats.
• Upgrading the SDK blindly on older Bedrock models. Anthropic's legacy Bedrock page warns that the latest SDK sends a newer API version by default, which the ARN-versioned models on Bedrock do not support, so requests can fail with a 400 error. Pin the SDK version for those models.
• Paying the residency premium by default. Regional endpoints cost more. Use them because a rule requires it, not because they sound safer.
• Forgetting account setup. Bedrock needs a one-time Anthropic use-case form, and Foundry needs an Azure Marketplace subscription before the first deployment.

A decision guide for teams

Work through these in order:

• Does security require the cloud to operate the model, with no Anthropic access? On AWS, use Claude in Amazon Bedrock. On Google Cloud, use the Google-managed offering. Accept the feature gaps.
• Must you buy through a cloud marketplace but want Anthropic's full feature set? On AWS, Claude Platform on AWS. On Google Cloud, the Anthropic-managed offering. On Azure, Foundry, choosing Anthropic-hosted if you need code execution or the Files API.
• No procurement constraint? Use the Claude API. You get new models and features first and the simplest setup.
• Then check residency and price. Pick global endpoints unless a rule forbids it, and add 10 percent if it does.

Whichever you pick, keep model calls behind one internal service. Anthropic's SDKs support every route listed here, so switching is mostly a client constructor and a model ID. For a worked AWS example, see how to deploy a Next.js AI app on AWS Bedrock, and for the wider cloud comparison, Bedrock vs Foundry vs Google's Agent Platform.

Work with me

I help teams choose the right Claude route for their cloud and compliance needs, then build the integration so switching later stays cheap. See AI integration and AI agent development, look through my work, and book a scoping call.