Bedrock vs Vertex AI vs Foundry: a decision matrix.

The decision frame

Eight times out of ten, the choice between Bedrock, Vertex AI, and Foundry is settled before you sit down to evaluate them. The deciding factor is your existing cloud footprint, not the feature checklist. AWS-native shops should run inference in AWS. GCP-native shops should run it in GCP. Microsoft-native shops should run it in Azure. The auth, audit, billing, and procurement benefits of staying in your existing cloud are larger than they look on paper, and they compound across every team that has to operate the thing.

The other 20% of the time, the deciding factor is one of three things, in order:

1. The model you specifically need. This matters less than it did a year ago. Claude now runs on all three, and OpenAI's frontier models run on Bedrock as well as Foundry. If you must have Gemini in production, Vertex is the only path. If you must have new OpenAI releases the day they ship, Foundry is still first. If you want Claude with the least friction, any of the three works, so your footprint decides.
2. A binding compliance constraint. US federal workloads push toward GovCloud or Azure Government. Specific EU residency contracts push toward whichever sovereign-cloud surface your contract names.
3. The team's operational competence. The platform that matches your existing skill profile ships fastest. A team fluent in IAM and CloudWatch will be productive on Bedrock in days. The same team will spend weeks getting comfortable with Entra and Azure Monitor before they ship anything on Foundry.

If none of those three apply and you genuinely have a clean slate, the choice opens up. That's the case this page is built for: when the decision is actually live, here's how to make it efficiently. For the deeper background on each platform, the cloud platforms field guide covers the model lineups, agent frameworks, and pitfalls in detail. This page is the head-to-head; that one is the encyclopedia.

What "existing footprint" actually means

The phrase gets thrown around without precision. What I mean by it: where does your team already have an organizational AWS / GCP / Azure account with billing, IAM, audit, and a security review pipeline that someone trusts? A pile of personal AWS accounts on a credit card does not count. A single project in GCP that one person owns does not count. The signal is whether your security and finance teams can answer the question "who owns this account, and what's already approved to run in it" without a meeting.

That bar matters because the cloud platform's value proposition is auth, audit, residency, and procurement. If you don't already have those three plumbed into one of the hyperscalers, you're not getting value from running inference there; you're paying for the privilege of standing them up. That's a fine choice when you have a compliance constraint forcing the issue. It's a bad choice when you're picking a platform for a prototype that hasn't shipped yet.

At a glance

One paragraph per platform, plus the strongest case for each. If one of these obviously fits your situation, you can probably stop reading and skim the matrix below to confirm.

Side-by-side matrix

The dimensions that actually move decisions. There is no overall winner; there is a winner per row, and the right pick is whichever set of rows lines up with your constraints.

The shorthand I use, repeated from the field guide because it actually holds up: Bedrock for breadth and IAM, Vertex for Gemini and Google's agent stack, Foundry for Microsoft integration and Azure-first OpenAI. Each is the obvious choice in its primary lane and a respectable second choice in the others. The lanes are wider than they were: in 2026 model exclusivity mostly went away, and Gemini is the only major family still tied to one platform.

What's not in the matrix (and why)

Three things people ask about that I deliberately left out. Raw model quality benchmarks: every platform now hosts roughly the same Claude, Llama, and Mistral; benchmark differences come from the model and the prompt, not the platform underneath. List-price token cost: the per-token rates for the same model are within a few percent of each other across platforms, and the total bill is dominated by your usage shape (provisioned vs on-demand, regional spread, RAG vs not) rather than the headline rate. Latency: all three are fine; none beat going direct to the source vendor; the difference between them on the same model is usually within noise.

Things that do matter and didn't fit cleanly in a table: the maturity of the docs (Bedrock ahead; Foundry and Vertex both mid-rebrand, with old names everywhere), the size of the practitioner community (AWS largest, Azure second, GCP third by a clear margin), and how often the product surface gets renamed (Foundry the most volatile, Vertex a close second after the Agent Platform rebrand, Bedrock the most stable). Weight those by how much they'll actually affect your team's day-to-day.

Strongest case for each

One paragraph per platform on who should actually pick what. Honest, not balanced.

You should pick Bedrock if

Your org runs on AWS and you want Claude in production. That alone is enough. Bedrock keeps Claude inside the AWS security boundary (Claude Platform on AWS is the alternative when you'd rather have full API parity than the boundary), the IAM integration removes a whole class of credential management, and Converse is still the cleanest unified chat surface across vendors. Add in Bedrock AgentCore for production agents (the framework-agnostic Runtime, Memory, Identity, and Observability primitives are genuinely better than what the other two ship), the breadth of the model catalog (OpenAI, Llama, Mistral, Nova, Cohere, AI21 all in one place), and global routing that dodges throttling at no premium. The pieces that bite are the one-time Anthropic access form, having two Claude endpoints with different feature sets, the per-model region matrix once you need residency, and the verbose API. None of those are disqualifying.

You should pick Vertex AI if

Your org runs on GCP, or your org runs Google Workspace and wants its inference path to read Workspace data through the Google security boundary instead of through a third-party connector. Vertex is the only enterprise-controlled path to Gemini, and Gemini is genuinely the right model for several workload shapes (long-context document analysis, anything that needs to ground against Drive or Gmail, and multimodal tasks where Gemini's vision quality leads). The MLOps tooling is the strongest of the three; if you have any kind of training, monitoring, or experiment-tracking workload alongside inference, Vertex slots in cleanly where the others would force you into a separate product. The pieces that bite are GCP-only deployment, narrower model breadth than Bedrock, and the sprawling product surface (AI Studio vs Agent Studio vs the Agent Platform services vs Vertex AI Search), made more confusing by the April 2026 rename.

You should pick Foundry if

Your org runs on Microsoft 365 and Entra, and you want OpenAI's models first, with the Azure compliance certifications. That's the case Foundry was built for, and it executes it well. Entra ties auth to identities your org already manages, Purview classifies the data flowing through, Sentinel catches anomalies, and the Microsoft 365 Copilot plumbing lives on the same surface if you want to extend it. Claude now sits in the same catalog, billed through the Azure Marketplace, and the Foundry Catalog covers the open-weight tail with the broadest selection of the three. The pieces that bite are Limited Access gates on the newest OpenAI models, a feature gap between Claude Hosted on Azure and Hosted on Anthropic, docs still catching up to two renames, and the most fragmented region matrix of any of the three platforms. If you're not already in the Microsoft ecosystem, Foundry is harder to justify now that Bedrock also carries OpenAI.

The and-not-or pattern

Most teams I work with end up using more than one. The question is rarely which platform; it's which is the primary one. — TWD

The pure single-platform team is rarer than the slide decks suggest. By the time a team has a real production AI footprint, it usually has at least two of these three in some form. The patterns I see most often:

• Bedrock primary, Foundry for one OpenAI workload. The shop runs on AWS and uses Claude on Bedrock for almost everything. There's one specific feature (a task a GPT model happens to do better, or a customer request that needs OpenAI specifically) that has run on Foundry. Since OpenAI's models arrived on Bedrock in 2026, that workload can often come home to AWS; the teams that keep Foundry do it for day-one access or for Azure's compliance scope.
• Vertex primary, a second cloud for one model family. The shop runs on GCP and uses Gemini for the workloads that benefit from Workspace integration or long context. Claude on Vertex now runs on global and multi-region endpoints, so the old reason to keep a separate AWS account for Claude capacity has mostly gone; when a second cloud exists today, it's usually for OpenAI models, on Bedrock or Foundry.
• Foundry primary, Vertex for Gemini-specific tasks. The shop runs on Microsoft and uses OpenAI models on Foundry for the bulk of inference. A small Vertex footprint exists for the one workflow that needs Gemini's specific capabilities (often a multimodal or long-document task). Costs are dwarfed by the Azure spend; the Vertex line is a rounding error.
• Direct vendor APIs alongside any of the above. Nearly universal. Anthropic, OpenAI, and Google AI Studio direct keys exist in the prototyping bench and in the eval harness even when production runs entirely on a cloud platform. The friction of standing up a new model on a cloud platform is high enough that nobody does it for sketches.

The implication for your design: build the model choice behind a clean abstraction from the start. Converse on Bedrock, the Vertex SDK with the model parameter, the Foundry SDK on Azure, and the vendor SDKs direct. If your application calls out to a single function that takes a model identifier and a message list, swapping platforms or adding a second one later is a configuration change, not a refactor. Skip that abstraction and you're paying for it the day procurement asks for the OpenAI workload to move to Azure.

The version-lag bite

The part of the cloud-platform story that gets undersold in the marketing: the cloud platforms can lag the source vendor's direct API by days to weeks, and features lag longer than model names. A new Claude generation lands on Anthropic's direct API on launch day; it lands on Bedrock anywhere from same-day to a couple of weeks later, depending on the release. A new GPT version ships on the OpenAI API; it shows up on Foundry the same day or soon after (sometimes behind a Limited Access gate), on Bedrock a few days later, and the regional rollout spreads over more weeks. A new Gemini drops on AI Studio; the Vertex production endpoints follow on a similar lag (shorter, because it's Google's own product, but real).

That gap matters less than it used to. In 2024 it was often months; by September 2026 the headline launches are often same-day (Claude Opus 5.5 was on all three platforms the day it launched; GPT-6 Astra reached Foundry on launch day and Bedrock five days later). But it isn't zero, and it bites in three specific ways:

• Feature lag, not just version lag. Even when the model name lands on the cloud platform on the same day, the feature surface around it sometimes lags. Prompt caching, a new tool-use shape, a new reasoning mode, a new long-context ceiling: those can land on the direct API first and on the platform later. If your application depends on a brand-new feature, check the platform's release notes alongside the vendor's, not just the model availability page. As I write this, Claude on Bedrock and Vertex still lacks the Files API, batches, and server-side code execution that the direct API has.
• Quota lag. Even when the model and feature are both available on the platform, default per-account quotas for new models start low and grow over weeks as the platform observes usage. Production workloads that tried to flip to the new version on day one have hit throttle-induced outages because the quota wasn't there yet.
• Behavior drift on minor versions. The cloud platforms occasionally pin to a slightly older minor version even when the model name matches. Default safety filters can also be more aggressive than on the direct API, causing refusals you didn't see in prototype. If you're seeing a behavior gap between your prototype (direct API) and production (cloud platform), log both responses and diff them; the difference is usually a parameter default, a guardrail intercept, or a minor-version pin rather than the model itself.

What this means for production planning: do not assume "we'll be on the new model on day one" if your production path is a cloud platform. Build the assumption into your roadmap that production lags the prototype by one to four weeks for a major release, and longer if you also need a quota increase. The teams that get burned here are usually the ones that promised a customer the new model on launch day based on the press release, not on the actual platform availability.

Which platform handles the lag best

Vertex is the strongest on this dimension for one specific reason: when the model in question is Gemini, there is effectively no lag (it's Google's own product, shipped on Google's own platform). For Claude, all three platforms have been day-one for recent launches; the lag is in features, not model names, and Claude Platform on AWS or Foundry's Hosted on Anthropic option are the ways to close it. For OpenAI, Foundry is first by contract (new products ship Azure-first) and Bedrock follows within days; the catch on Foundry is the Limited Access gate on the newest models. If your roadmap depends on a specific model on a specific date, the answer is to verify against the source vendor first and the platform second, every single time.

A decision-flow recipe

Six scenarios, with the call I'd make for each. If your situation matches one of these, the answer is probably the matching call. If it doesn't, the frame in Part 01 is the path to your own answer.

If you walked through these six and none of them match cleanly, you're in the genuine slate-and-paper case. Reread Part 01 with your specific constraints in hand, work through the three follow-up questions, and the answer usually presents itself within an afternoon. The worst outcome is overthinking this; the platforms are converging fast enough that the wrong pick is rarely catastrophic, and the abstraction in Part 05 makes switching costs bounded.

One closing observation

The choice between these three is more durable than it feels in the moment. Once your team has IAM patterns, audit pipelines, and CI/CD wired into one cloud's inference platform, switching is a real project, not a refactor. That's not a reason to agonize over the pick; it's a reason to make the obvious one and move on. The obvious pick is almost always your existing cloud footprint. If that pick gives you 80% of what you need on a given workload, ship it; the remaining 20% goes on a second platform, kept small and stable, with a clean abstraction between them.

And if any of this is out of date by the time you read it, the deeper coverage in the cloud platforms field guide updates on the same cadence as this page. The model names and version numbers in here will go stale faster than the framing will; the framing is the part that's been holding up across the last two years of platform churn.

One last note on the local models field guide: if your decision is actually "cloud platform vs running models in our own data center," that's a different question with a different answer, and the local-models guide is where to start. This page assumes you've already decided that managed inference is the right shape; the local-vs-cloud question is upstream of everything here.