Bedrock and Vertex: choosing where Claude actually runs
Table of Contents
There are three ways to call Claude in production: Anthropic’s API directly, AWS Bedrock, or Google Cloud Vertex AI.
People treat this as a performance question. It is not. The model is the same model. Same weights, same output, same prompting.
What you are choosing is whose account gets billed, whose IAM decides who may make the call, and whose region it runs in. Every real trade-off falls out of that sentence.
The one thing worth understanding
A security review of a new vendor asks: who are you, where does our data go, what is your breach history, who are your sub-processors, what happens when we terminate. That is questionnaires, legal review and procurement. Months, at a large company.
A review of a new workload in an existing cloud account asks: which service, which region, which IAM role, which data. Often a form.
Running Claude through a customer’s own cloud converts the first conversation into the second. That is the entire value proposition, and it is organisational rather than technical.
It is also why the request usually arrives from someone who cannot explain the technical benefit. There often isn’t one. The benefit is that the shape is pre-approved.
How the three differ
| Aspect | Anthropic API | Bedrock | Vertex AI |
|---|---|---|---|
| Auth | Anthropic API key | AWS IAM, SigV4-signed | Google Cloud IAM / ADC |
| Billing | Anthropic | Your AWS bill | Your GCP bill |
| Data boundary | Anthropic | Your AWS account | Your GCP project |
| Quota | Anthropic account | AWS, per region | GCP, per project |
| New models | First | Follows | Follows |
Authentication is the real change
On the first-party API you hold one long-lived secret and send it as a header. Simple, and a credential you have to store, rotate and audit.
On Bedrock there is no Anthropic key at all. You authenticate to AWS the same way you authenticate to any other AWS service - the standard credential chain, resolving from environment, profile, instance role or container role - and requests are signed with SigV4 by the SDK. Permission is an IAM policy allowing model invocation.
On Vertex it is Application Default Credentials: your own login locally, an attached service account on a VM or in a container, with permission granted by IAM roles on the project.
Lead with this when you talk to a security team. An enterprise’s least favourite object is a long-lived API key in an environment variable - it gets committed, shared, logged and never rotated. Both cloud routes delete that object. Credentials become short-lived, automatically rotated, and tied to a workload identity governed by the joiners-and-leavers process they already run.
“You do not hold an API key for this” is a better opening than any latency number.
Model identifiers are not portable
You cannot move a call between providers by changing a base URL. The model identifier changes shape: a plain name on the first-party API, a fully-qualified identifier (often with a region or cross-region inference prefix) on Bedrock, a publisher-scoped name resolved within a project and region on Vertex.
Practical consequence: never hardcode a model ID in application logic. Put it in configuration, keyed by provider, behind a thin adapter. Discovering this late means touching every call site.
Quota moves to the cloud provider
On Bedrock and Vertex, rate limits are a cloud quota - per account or project, per region, raised through that cloud’s quota process rather than through Anthropic.
Two things catch teams out. A pilot’s quota does not become production quota automatically, and increases take time and paperwork, so raise them early. And quota is shared with everything else in that account, so a noisy neighbour workload can affect you.
Cost is structural, not per-token
Token pricing is broadly comparable. The differences that matter are elsewhere.
Consolidated billing is usually the point: spend lands on an existing bill, sometimes drawing down a negotiated cloud commitment, which can make it effectively cheaper at identical list price. Cost attribution uses the tagging and reporting the customer already runs. And if the workload sits in the same cloud, traffic may never leave their network - which some compliance regimes care about more than the cost.
Region and availability: check, never recite
Model availability differs by provider and region, and it changes.
Do not answer this from memory. If a customer needs a specific model in a specific region for a compliance reason, that is a checkable fact, and “let me confirm against current availability” is the correct professional answer. Reciting a stale list is how you lose a room.
What is worth internalising is the shape: not every model is in every region on every provider, new models typically reach the first-party API first, and some providers offer cross-region routing so a request can be served from a neighbouring region under load - which has obvious residency implications you should raise before the customer does.
What does not change
Worth stating, because people assume more differs than does.
Same models and same output quality. Same core request and response shape. Same prompting approach - nothing about prompt engineering changes. Tool use, streaming and system prompts all work.
The interesting part of the work is unaffected. The differences are auth, addressing, quota and billing.
When to say they do not need it
A startup with no regulatory obligation and no cloud commitment gets a slower path to new models, an extra auth integration and a quota process, in exchange for nothing they can name.
Say so. Recommending the simpler option when it is right is what buys you the credibility to be believed later, when you tell them something they do not want to hear.
The people who genuinely need it are recognisable: regulated industries with explicit residency rules, enterprises with a committed cloud spend agreement that procurement wants drawn down, and organisations whose security team has already approved one cloud and nothing else.
The questions to ask, in order
Do not lead with architecture. Lead with what forces the answer.
- What data touches this, and what class is it? Everything follows.
- Is the residency requirement contractual or regulatory? Contractual is negotiable. Regulatory is not. People conflate these constantly.
- Do you have a committed spend agreement with a cloud provider? Frequently decides it outright, and the engineers in the room often do not know.
- What has your security team already approved? The cheapest path is almost always the pre-approved shape.
- Who signs off, and what do they need to see? This is the difference between two weeks and two quarters. Then write the document they need.
The mental model
The model is the same. You are choosing whose account is billed, whose IAM decides who may call it, and whose region it runs in.
If you can derive the trade-offs from that sentence live in a meeting, you understand this well enough to be useful in one.
What to read next
- Enterprise deployment - SSO, SCIM and the rest of the security review this sits inside.
- Auth for agents - the identity model underneath.
- Approval gates - the control a security team will ask about next.