Bedrock, Vertex, Foundry: pick the one whose spirit matches yours
Every comparison of the three hyperscaler AI platforms is a feature matrix that nobody reads twice. The actual decision is about which company's spirit your team can live with for the next five years — and that's a different question.
The most common piece of advice given to engineering leaders evaluating hyperscaler AI platforms in 2026 is “do a side-by-side feature comparison.” This advice is almost always wrong. By the time you finish the spreadsheet, two of the platforms will have shipped four new features each, and the spreadsheet will have answered the wrong question anyway.
The right question is not “which platform has feature X today.” It is “which platform’s spirit do I want my team’s habits and my buyer’s procurement reflexes shaped by for the next five years?” That question has a cleaner answer than the feature matrix does. Each of the three platforms has a strong organising thesis, and once you see the thesis, the choice gets easier.
This post tries to put the thesis of each platform on the page.
The shape of the three bets
Strip away the hundred-feature pages and each platform reduces to one sentence.
These are not marketing positions — they are observable in the roadmap. Bedrock keeps adding model providers; Vertex keeps integrating Gemini deeper into Google’s own products; Foundry keeps tying agents into Microsoft 365 surfaces. None of them is “behind” — they are running different races.
Bedrock: the supermarket that knows it is a supermarket
The thing that makes AWS Bedrock coherent is that AWS has made peace with not having a frontier model. Amazon’s own Nova / Titan family is a fine commodity option, but the real product is the shelf: the same API, the same auth, the same VPC endpoints, the same provisioned throughput contracts — applied to Anthropic’s Claude, Meta’s Llama, Cohere, Mistral, Stability, AI21, plus the Amazon in-house models.
For a large enterprise already running on AWS, this is enormously seductive for three reasons.
Procurement happens once. The buyer’s legal team has already approved an AWS contract. Bedrock model usage is billed through the existing AWS Enterprise Discount Program. There is no second vendor to onboard. For a Fortune 500 buyer, this single fact often dominates every technical consideration.
The blast radius of model swaps is small. A Bedrock app that calls Claude can swap to Llama 3 by changing a model ID string. Same SDK, same auth, same VPC routing. Real production teams do not swap models lightly, but having the option is what gets the architecture past the risk-management review.
Cross-region and data-residency stories are mature. Bedrock has inherited two decades of AWS regional infrastructure. If you need the model call to stay inside the eu-central-1 region for GDPR reasons, that is one IAM policy and one endpoint configuration away. The other platforms are catching up on this; Bedrock was born into it.
What Bedrock is not good at: it is not the place where the best new model arrives first. By the time Claude Opus 4.7 is on Bedrock, it’s been on Anthropic’s direct API for weeks. If you live on the bleeding edge, you are not a Bedrock-first team — you are a “Anthropic direct plus Bedrock for the boring stuff” team.
Vertex: the only platform with a coherent vertical stack
Vertex AI is what happens when the company that makes the model also makes the data warehouse, the serverless compute, the IAM system, and the observability stack. The result is the only one of the three platforms where the agent, the model, the data, and the auth all speak the same language without translation layers.
Concrete examples of the integration:
- BigQuery ML can call Gemini directly inside a SQL query. Your
analyst writes
ML.GENERATE_TEXTagainst a 50-billion-row table, and the warehouse handles batching, retries, and quota. This is not a thing on AWS or Azure — it is structurally a Google move. - Vertex AI Agent Engine runs agents inside the platform, with the model call, tool call, session state, and trace logging all emitting to the same Cloud Trace surface. You can see a single agent turn as a multi-span trace without writing any observability code.
- Gemini’s long-context window is built around Google’s own document, multimodal, and code corpus. A 1M-token context on Gemini behaves differently from a 1M-token context advertised elsewhere because it was trained on the kinds of content that fill long contexts in practice.
The cultural fit question: Vertex feels native to engineering teams that already think in terms of “data first, model second.” Teams whose production database is BigQuery, whose dashboards are Looker, whose compute is Cloud Run, will find that adding Gemini is a one-line config change. Teams whose existing stack is Snowflake + EC2 + custom auth will find that adopting Vertex means moving four other things too.
The honest weakness: Vertex is single-vendor in a way Bedrock is not. If you decide you need an Anthropic model, you can get it on Vertex via Model Garden — but the moment you do, the Vertex-native integrations (agent engine, BigQuery ML, etc.) work less smoothly than they do with first-party Gemini. The platform is built around its own models being the default.
Foundry: the platform built on a single distribution insight
Azure AI Foundry is the most misunderstood of the three. Engineers evaluating it on raw model quality, latency, or pricing tend to come away unimpressed and move on. They are evaluating it on the wrong axis.
The thing Foundry has, that the other two structurally cannot match, is Microsoft 365. Your enterprise customer’s employees already spend their day in Outlook, Teams, Word, Excel, SharePoint, and OneDrive. Foundry is the platform where an agent can become a first-class citizen inside those surfaces — appearing as a Copilot extension, a Teams app, a Word task pane, an Outlook compose-window action.
For a B2B software vendor, the implication is significant. Every B2B vendor has the same growth problem: how do you get the user to actually adopt your AI feature? On Bedrock or Vertex, the answer is “build a web app and convince the user to visit it.” On Foundry, the answer is “ship a Copilot extension and the feature shows up where they already work.” That is not a feature-list advantage — it is a go-to-market advantage that no amount of model improvement on the other platforms can replicate.
The other thing Foundry has, of course, is deep OpenAI integration under a Microsoft contract. GPT-5 and o-series reasoning models are available on Foundry under the same enterprise terms as Azure itself. For organisations whose Microsoft Enterprise Agreement already covers everything else, adding Foundry consumption is procurement-trivial in the same way Bedrock is for AWS-native shops.
The weakness, again to be honest: outside the Microsoft surfaces, Foundry feels more like a wrapper around OpenAI than a coherent platform of its own. The agent SDK, the evaluation framework, the observability — they all exist, they all work, but they are not the soul of the product. The soul of the product is Copilot distribution.
A working decision rule
Three rules of thumb, distilled from watching dozens of large organisations make this choice in 2024–25.
The non-obvious move is to be honest about the second tree node: your data and compute backbone. Teams routinely tell themselves “we’re multi-cloud,” look at the platform feature lists, and pick the one with the most features. Six months later, they discover that their event pipeline, their data warehouse, and their auth system were all on AWS or all on GCP, and the agent was the only thing on the other cloud. The cost of that mismatch is permanent egress fees, duplicate IAM, and a small but persistent productivity tax on every deploy.
The exception nobody plans for: direct provider APIs
The unspoken fourth option in 2026 is “don’t use a hyperscaler platform at all.” Anthropic’s direct API, OpenAI’s direct API, Google’s AI Studio for Gemini — all of them are first-class, often cheaper per token, and always the first place new model versions land.
Teams that ship the fastest tend to use the hyperscaler for boring production (existing enterprise customers, compliance, billing) and the direct provider API for interesting production (experimentation, new features, anything where being two weeks behind the model release is unacceptable). They build a thin internal abstraction so both endpoints look identical to the agent code. That abstraction is maybe 200 lines of Python. It is the most useful 200 lines you will write all year.
What to take away
- The right platform is the one whose spirit matches your existing stack and your buyer’s procurement reflexes. Run the spirit question first; run the feature comparison only to confirm.
- Bedrock is the supermarket. Pick it if you are AWS-native and your model strategy is “I want options.” It is not the place where cutting-edge models arrive first.
- Vertex is the vertical stack. Pick it if your data lives in BigQuery and you want the agent, the model, the data, and the IAM to all speak one language. The integration depth is unmatched.
- Foundry is distribution. Pick it if your users live in Microsoft 365 and you need to reach them inside Word, Teams, Outlook, SharePoint. The model is not the product — the surface is the product.
- Keep a direct-provider escape hatch. Build a 200-line abstraction so you can call Anthropic, OpenAI, and Google directly for experimentation while keeping the boring production stuff on the hyperscaler.
The teams that are doing well on AI in 2026 are not the teams who picked the best platform. They are the teams who picked the platform whose spirit they could live with — and then ignored the feature wars entirely and focused on shipping.
Further reading: AWS’s Bedrock model catalogue is the easiest way to see the supermarket thesis literally on the page. Google’s Vertex AI Agent Engine docs show the vertical stack. For the Microsoft distribution thesis, see the Copilot Studio overview.