Multi-Cloud AI

Claude on Bedrock, Vertex AI or Foundry: where should each agent run?

Teams ask which platform has the best Claude. The question that decides where an agent should run is where its data, its users’ identities and its compliance boundary already are.

As of October 2026, Anthropic lists Claude on its own Claude API, on Amazon Bedrock, on Claude Platform on AWS, on Google Cloud’s Vertex AI and in Microsoft Foundry. The model family is the same across them. What differs is who operates the service, which features are available, and how it plugs into the rest of your estate.

Anthropic’s feature availability by platform

Start with the three things that are hard to move

Data

Agents spend most of their time reading. Running the model next to the records it reads cuts latency, avoids copying regulated data, and keeps your existing access controls in charge. If the system of record lives in one cloud, that is the default home for the agent that works on it.

Identity

Every agent action should be traceable to a person or service account your organisation already manages. An agent that runs where your identity provider is native inherits single sign-on, groups and audit trails. One that runs elsewhere needs that plumbing rebuilt.

Compliance boundary

Data residency, retention and approved-vendor lists are set per environment. Place the agent inside the boundary its data is already approved for, rather than seeking a fresh approval for a new home.

Then check the features the agent needs

Feature availability differs by platform, and it changes. Anthropic’s own feature table shows, for example, that batch processing and the MCP connector are not offered on every platform, and that on Microsoft Foundry some features depend on the hosting option chosen.

So list what the agent actually depends on, such as tool use, prompt caching, batch processing, web search or a managed MCP connection, and check each against the provider’s current documentation on the day you decide. Do not rely on a comparison article, including this one, for a feature list.

A placement rule that lasts

Put the agent where its data, identity and compliance boundary already live. Use the feature table to rule platforms out, not to pick one in.

Regional and global endpoints

Where an agent’s requests are processed matters as much as which platform it uses. On Amazon Bedrock, for example, Anthropic’s documentation describes global endpoints that route for availability and regional endpoints that keep processing in a chosen geography, the latter at a 10 per cent premium. If an agent handles records with residency rules, budget for the regional option from the start.

When one agent spans two platforms

Some workflows cross boundaries: an agent that reads records held in one environment and writes a summary into a dashboard hosted in another. Split the work at the boundary rather than stretching one agent across it. Each half runs where its data lives, and the two exchange results through a narrow, logged interface.

Keeping tools portable helps. When an agent reaches internal systems through MCP servers you own, the same tools can serve an agent on any platform, and moving the agent later does not mean rebuilding its integrations.

How we build MCP servers for Claude agents

Model choice inside a multi-cloud estate

Placement and model choice are separate decisions. Within a platform, pick the model per task: a smaller, faster model for classification and routing, a larger one for drafting and reasoning. Measure it on your own cases before you commit, because the right answer depends on your documents, not on a leaderboard.

Where Focus20 fits

We map which agent workloads belong where before anything is built, then design the control layer that keeps identity, logging and evaluation consistent across platforms. It is the same kind of architecture work we are currently doing for the Maharashtra Pollution Control Board.

Why agentic AI needs more than one cloud

Questions we get

Is Claude the same model on every platform?

The model family is the same, but model versions, features and endpoints can arrive at different times on different platforms. Check the specific model and features you need on the platform you plan to use.

Can we move an agent to another platform later?

Yes, if the model call, the tools and the logging sit behind your own interfaces. Agents wired directly into one platform’s proprietary services are the ones that are expensive to move.

Which platform is cheapest?

It depends on the model, the endpoint type and your existing commitments with each provider. Compare current prices on each provider’s own pricing page for your actual workload.

One control layer for agents across clouds