The thing that nearly stopped us from using Claude at all was not the model. It was our security and procurement teams, who were not going to approve a new vendor, a new bill, and a new data path on my timeline. The model was ready; the paperwork was not. Then I learned Claude runs on Bedrock, which meant it ran inside the AWS account, the contracts, and the compliance review we had already cleared, and the blocker evaporated.
That is what running Claude through a cloud platform is really about: meeting the model where your compliance and billing already live. This guide covers the platforms Claude runs on, why a team would choose one, and what actually differs from the direct API so you are not surprised.
Same model, your platform
The first thing to be clear on: it is the same Claude. Running it through Amazon Bedrock, Google Vertex AI, or Microsoft Foundry does not give you a different or lesser model, it gives you the same model reached through a different front door. The intelligence is identical; the wrapper around it is what changes.
What that wrapper carries is billing, compliance, data residency, and authentication. Through a cloud platform, your Claude usage shows up on your existing cloud bill, runs under your existing agreements, and authenticates with your existing cloud credentials. The model is the constant; the surrounding platform is the variable.
Why run Claude through a cloud platform
The reasons are almost never about the model and almost always about the organization around it. Billing: your Claude spend rolls into a cloud bill and commitment you already have, instead of a separate vendor invoice. Compliance: it runs under the security review and agreements your team already approved for that cloud. Data residency: you can keep data within regions and boundaries your policies require.
Add authentication and access control that plug into your existing cloud identity, and the picture is clear. A cloud platform is how a larger or more regulated organization says yes to Claude without redoing all the governance work, because the governance is inherited from a platform already blessed. That is the whole value, and it is a big one at scale.
There is a speed-of-adoption angle too, which is really a speed angle. Getting a brand-new vendor through security, procurement, and a data-privacy review can take months at a larger company. Reaching Claude through a cloud you have already cleared collapses that to a configuration change, so the difference between using Claude this quarter and next is sometimes just which door you walk through.
Amazon Bedrock
Bedrock is AWS's managed service for foundation models, Claude among them. If your stack lives in AWS, this is often the path of least resistance: Claude usage on your AWS bill, access controlled by the same identity system as the rest of your infrastructure, data kept within your AWS setup. For an AWS-native team, it turns adopting Claude into a configuration change rather than a vendor onboarding.
That was our path. The reason it worked was not that Bedrock's Claude was better, it was that Bedrock was already inside the fence our security team had built. The model came along for free with a platform that was already approved.
Google Vertex AI
Vertex AI is Google Cloud's equivalent, and the logic is the same for a Google-native team. Claude runs through Vertex, billed to your Google Cloud account, under your existing Google Cloud governance and identity. If your data and your tools already live in Google Cloud, reaching Claude through Vertex keeps everything in one place.
The pattern across all of these is consistency: you use the model the same way you use everything else in that cloud, so it inherits the operational habits, the access controls, and the billing your team already runs on. The best platform is usually just the one you are already in.
Microsoft Foundry
Foundry is Microsoft's platform for running models, and it plays the same role for organizations centered on Microsoft and Azure. Claude through Foundry means Microsoft-native billing, identity, and compliance, so a company standardized on Microsoft can adopt Claude without stepping outside the ecosystem its governance is built around.
Three clouds, one idea: whichever platform your organization has already standardized on, Claude is likely available there, and running it that way keeps procurement, compliance, and billing where they already work. The choice among them is mostly which cloud you are already in.
What differs from the direct API
The important caveat is that these are not always identical to the direct Anthropic API. New features and new models tend to arrive on the direct API first and reach the cloud platforms afterward, so a capability you read about may not be on your platform yet. Model identifiers also differ by platform, so the string you use to call a model on Bedrock is not the same as on the direct API.
Authentication differs too, since each platform uses its own credentials and SDK conventions rather than an Anthropic API key. None of this is a barrier, it is just a set of details to get right per platform, and the docs for each are the place to confirm current models, identifiers, and available features before you build.
One more practical difference: support and quotas run through the platform. Rate limits, quota increases, and billing questions go to your cloud provider's process rather than Anthropic's, which is usually a plus if you already have a relationship and a support tier there. It is one more thing that lives where your team already operates.
TipDo not assume feature or model parity across platforms. Confirm the current models, identifiers, and available features in your chosen platform's docs before you build on a capability.
How to choose
The decision is usually made for you by where your stack already is. If your infrastructure, data, and governance live in AWS, use Bedrock; in Google Cloud, Vertex; in Microsoft, Foundry. Running Claude where your compliance and billing already work is almost always worth more than chasing the newest feature a day early.
The exception is when you want the latest capabilities the moment they ship, or you have no strong cloud commitment pulling you one way. Then the direct Anthropic API is the simplest path and the first to get new features. So: direct API for simplicity and the cutting edge, your cloud platform for inheriting governance you already have.
Where it goes wrong
The most common surprise is assuming parity, expecting a feature or model from the direct API to be present on your cloud platform, and building on it before checking. Verify availability on your platform first, because the gap is real and moves over time. The related trap is model identifiers: the same model has different names across platforms, and using the wrong string is a fast, confusing failure.
The other is regions and residency. A cloud platform lets you control where things run, which is a feature, but it also means a model or feature might not be available in the specific region your policy requires. Check that the platform, the region, and the capability line up before you commit, rather than discovering a gap late.
- Assuming feature or model parity with the direct API; confirm on your platform first.
- Using a direct-API model identifier on a cloud platform, where the name differs.
- Overlooking that a feature or model may not be in your required region.
- Choosing a platform for a feature, when the real driver should be where your governance lives.
The GTM version
For GTM this matters the moment your automation has to touch real customer data at an organization with a security team. The research agent, the enrichment pipeline, the scoring job, if they handle customer records, running Claude through the cloud your company already trusts is often what makes them approvable at all. The model was never the hard part; the data path and the paperwork were.
So the practical move is to meet the model where your compliance already lives. If your GTM data and governance are in AWS, run Claude on Bedrock and inherit the approval you already have. Is the thing blocking your Claude project the model, or the procurement path around it?
How to set it up
Start from where your stack already lives
Pick the platform by your existing cloud, not by feature chasing. AWS-native, Bedrock; Google Cloud, Vertex AI; Microsoft, Foundry; no strong commitment or you want the newest features first, the direct Anthropic API.
Confirm models, identifiers, and features on that platform
Before building, check the platform's docs for the current model identifiers and which features are available, since these differ from the direct API and from each other.
TipThe model name that works on the direct API is not the one that works on Bedrock or Vertex. Get the platform-specific identifier from its docs before your first call.
Authenticate with the platform's own credentials
Use the cloud's identity and SDK rather than an Anthropic API key. This is the point: access runs through the same credentials and controls as the rest of your infrastructure there.
Verify region and residency line up
Confirm the platform, your required region, and the model or feature you need are all available together before you commit, so a residency requirement does not surface as a blocker late.
Frequently asked questions
Which cloud platforms run Claude?
Amazon Bedrock, Google Vertex AI, and Microsoft Foundry, in addition to the direct Anthropic API. It is the same model reached through each platform's own front door.
Is Claude on a cloud platform the same model?
Yes. The model is identical; what changes is the wrapper around it, billing, compliance, data residency, and authentication, which run through your cloud account instead of directly with Anthropic.
Why would I run Claude through Bedrock or Vertex?
To inherit governance you already have: your existing cloud bill, security agreements, data residency controls, and identity. It is how a larger or regulated org adopts Claude without redoing all the procurement and compliance work.
What differs from the direct Anthropic API?
New features and models usually reach the direct API first, model identifiers differ by platform, and authentication uses each cloud's own credentials. Confirm current models and features in the platform's docs before building.
How do I choose a platform?
Usually by where your stack already is: AWS to Bedrock, Google Cloud to Vertex, Microsoft to Foundry. Choose the direct API for simplicity and the newest features when you have no strong cloud commitment.
Will every feature be available on my cloud platform?
Not necessarily. Feature and model availability can lag the direct API and vary by region, so verify that the platform, your region, and the capability you need all line up before you commit.
Do I use my Anthropic API key on Bedrock?
No. Each platform uses its own credentials and SDK, so you authenticate with your cloud's identity system, not an Anthropic API key. The model call is a similar shape, but the client and identifiers differ.
Why does this matter for GTM?
Because automation that touches customer data at an organization with a security team often has to run where governance is already approved. Running Claude through your existing cloud is frequently what makes a GTM project approvable at all.
Sources & further reading
Claude ships fast. This page was last reviewed Aug 23, 2026; verify time-sensitive details against the official docs above before relying on them.