Bedrock vs Azure AI Foundry vs Vertex AI for LLM Apps

Most comparison articles on this topic were written a year or two ago and contradict each other on which models live where. The catalogues have moved a lot since. I checked each vendor's own documentation in November 2026 and wrote down only what those pages say, with links, so you can re-check before you commit.

The short answer: start from where your data and contracts already are

The deciding factors for an LLM app are usually not the model list. They are where your customer data is allowed to go, which identity system your security team trusts, and which cloud bill already carries a committed spend. Moving data across clouds to reach a model adds egress, a second security review and a second set of credentials.

So my default on client work is simple:

• If the app and its data live on AWS, start with Bedrock.
• If the organisation runs on Microsoft 365 and Azure, start with Foundry.
• If the data sits in BigQuery or the team builds on Google Cloud, start with Google's Agent Platform.
• If none of these apply, a provider's first-party API is often the simplest place to begin, and a cloud can come later.

The rest of this post is about the cases where that default is not enough: a specific model, a residency rule or a cost profile that pushes you elsewhere.

Which models can you use on each platform?

All three now host models from several providers, but each has a home family that arrives first and gets the deepest integration.

Two corrections to things you will still read elsewhere.

First, Vertex AI has a new name. Google's release notes for 22 April 2026 say "Vertex AI is now part of Gemini Enterprise Agent Platform". The APIs and URLs still say vertex-ai and aiplatform, so your code does not change, but the console and docs use the new name.

Second, Claude on Azure is no longer a gap. Microsoft's Claude page lists two hosting versions: one hosted on Anthropic infrastructure and one hosted on Azure, with the Azure-hosted models all generally available. Opus 5.5, Sonnet 5.5 and Haiku 5.5 are GA on both. That page also notes Claude deployments need an Azure Marketplace subscription and bill in Claude Consumption Units.

How does pricing differ between Bedrock, Foundry and Google?

Per-token list prices for the same third-party model tend to track the provider's own price, so the real differences are in the pricing tiers around them.

Sources: Bedrock pricing, Foundry deployment types, Gemini batch inference.

One detail matters a lot for Claude. Anthropic's pricing page says that on Bedrock and on Google's platform, regional and multi-region endpoints carry a 10 percent premium over global endpoints for Sonnet 4.5 and later models. On Foundry, the US Data Zone deployment applies the same 1.1x multiplier as US-only inference on Anthropic's own API. If you need data to stay in one geography, budget that 10 percent from day one.

Microsoft's own advice is to start with Global Standard because it gets new models first, has the lowest price and the broadest regions, and to move only when you have a reason such as residency, reserved throughput or batch work.

How do they handle data residency and security?

All three let you pin processing to a geography, but each does it with different words and different guarantees.

• Bedrock. AWS's data protection page explains that each model runs in a deployment account operated by the Bedrock team, and model providers "don't have access to Amazon Bedrock logs or to customer prompts and completions". Cross-region inference profiles let you route within a geography (US, EU and so on) or globally.
• Foundry. Deployment types spell out processing location: Global may process in any Azure region, Data Zone keeps processing within the US, EU or APAC zone, and Standard keeps it within an Azure geography, according to the deployment types page.
• Google. The locations page is blunt: "Endpoints don't guarantee data residency or in-region ML processing", and you should not use the global endpoint if you have processing-location requirements. Multi-region endpoints exist to keep processing within the US or EU.

If you work in a regulated sector, read the exact wording for your model and deployment type, not a summary. The EU AI Act timeline adds its own obligations on top; I covered those in the EU AI Act deadline for AI builders.

What is the developer experience like on each?

The biggest day-to-day difference is the API you write against and how much setup stands between you and a first response.

Bedrock gives you two styles. The Converse API "provides a consistent API that works with all Amazon Bedrock models that support messages", so you can switch models without rewriting request code, per the Converse docs. Model access is now enabled on first use for most models, as long as the caller has the AWS Marketplace permissions; Anthropic models also need a one-time use-case form per account or organisation, according to the model access page.

Foundry puts OpenAI models behind the familiar Responses and Chat Completions APIs, and serves Claude through the Anthropic Messages API on a Foundry endpoint, so you can use Anthropic's own SDK. Microsoft also offers instant access in preview, where you call supported models by name without creating a deployment first.

Google serves partner models as serverless managed APIs, and you can call Claude there with Anthropic's SDK. The trade-off to know is the endpoint choice: global for availability, multi-region or regional for residency, at a price difference.

For a broader view of how I wire any of these into an existing product, see how to add AI to your existing app.

How hard is it to switch later?

Switching the model call is easy; switching everything around it is not. If your code talks to a provider through an internal service and a standard message format, moving from one platform to another is mostly a new client, new credentials and new model IDs. What takes longer is the rest: IAM roles or managed identities, private networking, logging pipelines, quota requests, and the security review that approved the first platform.

So I treat the platform as a two-to-three-year decision and the model as a decision I can revisit every few months. That is another reason to choose by data location and contracts rather than by this quarter's model leaderboard.

How I would choose for a new LLM app

When a client asks me to pick, I run through four questions in order and stop as soon as one decides it.

• Where do the data and the committed spend already sit? That cloud wins unless something below rules it out.
• Is there a model the product cannot do without? Gemini means Google. A GPT model means Foundry or Bedrock. Claude works on all three, or on Anthropic's own API.
• Does processing have to stay in one geography? Check that the model you want is offered in the right Data Zone, geographic profile or multi-region endpoint, and add the residency premium to the budget.
• How much of the work can wait? Anything that runs overnight, such as tagging, summarising or evaluation runs, belongs on batch pricing at half price on all three.

Then I prototype against the provider SDK through a thin internal service, so the cloud choice stays a configuration detail rather than something baked into product code. That is the same "beside, not inside" approach I use for any AI feature.

Work with me

I help teams pick the right cloud and model for an LLM feature, then build it beside the existing product with sensible cost and residency controls. See AI integration and full-stack development, or look through my work and book a scoping call.