AWS AgentCore vs Google Vertex vs Microsoft Foundry: the cloud agent platforms compared

AWS AgentCore vs Google Vertex vs Microsoft Foundry: the cloud agent platforms compared

We have written each platform up on its own: Amazon Bedrock AgentCore, Google’s Vertex AI, and Microsoft Foundry Agent Service. This piece is the comparison those three were building towards.

The three, in one line each

The names moved around in 2026, so pin them down first:

• AWS - Bedrock AgentCore. A set of composable managed services (Runtime, Gateway, Memory, Identity, Observability, Browser, Code Interpreter) for running agents in production. Framework- and model-neutral.
• Google - Vertex AI Agent Engine. The managed hosted runtime for agents, part of Vertex AI Agent Builder - which Google folded into the Gemini Enterprise Agent Platform brand at Cloud Next 2026. The platform underneath is the same; see our Vertex AI guide on the rebrand.
• Microsoft - Foundry Agent Service. The agent runtime inside Microsoft Foundry (formerly Azure AI Foundry), with a free orchestration tier for native agents and a paid container runtime for hosted ones.

Three different names for the same idea: bring your agent, get a managed place to run it.

The shared pattern (what they have in common)

Before the differences, the common ground - because it is real and it is most of the picture:

• Bring your framework. All three run agents built with external frameworks. LangGraph works on all three. Each also pushes a first-party SDK: AWS has Strands, Google has ADK (Agent Development Kit), Microsoft has the Microsoft Agent Framework (its Semantic Kernel + AutoGen convergence).
• Managed, isolated runtime. Each gives you a session-isolated place to run an agent without standing up your own EC2/GKE/AKS cluster, with autoscaling and (on AWS and Azure) scale-to-zero so idle agents cost little or nothing.
• Consumption billing. No “agent platform licence.” You pay for what the agent consumes - compute while active, plus memory, tools, and so on.
• Model inference is separate - and usually the biggest line. On all three, the tokens your agent sends to a model are billed apart from the runtime, through Bedrock / Vertex Model Garden / Foundry Models. At real traffic, inference typically dwarfs the runtime cost. This is the single most important thing to understand about all three bills.

So the platform choice is rarely what sets your total agent cost. That is set by model and volume. The platform choice is about fit, lock-in, and - as we are about to see - how easily you can even find out what it costs.

Side-by-side

Rates below are list prices for the managed agent runtime, as of October 2026, and change by region and over time. Model inference and supporting services are extra on all three. Verify on each vendor’s pricing page before you budget.

The pricing-transparency asymmetry (the part worth reading twice)

Look again at the “published runtime rate” row. Two of the three vendors publish a number you can put in a spreadsheet; one does not.

• AWS publishes AgentCore’s rates openly - $0.1276 per vCPU-hour, $0.0169 per GB-hour, the Browser and Code Interpreter rates too. You can estimate an AgentCore agent’s runtime cost from the public page before you ever log in.
• Google publishes Agent Engine’s rate openly - about $0.0864 per vCPU-hour, with a free monthly allowance that covers light use outright. Again, estimable from the public page.
• Microsoft does not publish Foundry Agent Service’s per-unit figures. The pricing page shows the cost structure - native agents free, hosted agents billed on container compute, tools metered - but the actual per-vCPU-hour and per-GiB-hour numbers sit behind region and currency selection and a sign-in. To get them you run the Azure pricing calculator or talk to a sales specialist.

This is not a knock on the platform, and it is not a claim that Foundry is more expensive - we genuinely do not know, because the number is not on the open page. But it is a real difference in the cost of evaluation. If you are doing a quick three-way back-of-envelope before picking a direction, you can do it for AWS and GCP from their public pages and you cannot do it for Azure. For a vendor-neutral team that matters, and most “X vs Y vs Z” comparisons quietly skip it because it is unflattering to one side. We are not skipping it.

The honest practical upshot: do not try to rank the three on runtime price alone. You can compare AWS and GCP directly (GCP’s list rate is lower per vCPU-hour, and the free tier helps light workloads); for Azure you have to model it yourself. And remember the runtime is the small line - inference is where the money goes on all three.

Which fits when

Because the platform choice is mostly about ecosystem gravity, the useful question is not “which is best” but “where does your team already live.”

In practice the decision is usually made for you by where your identity, data, and team already sit. A team with everything in BigQuery and Looker will not move to AWS to save a fraction of a cent per vCPU-hour, and shouldn’t. The platforms are close enough on capability that ecosystem fit, not a feature scoreboard, is the right tiebreaker.

What this comparison does NOT settle

• Your actual bill. Runtime rate is the small part. Model inference tokens dominate at real traffic, and that is a model choice (Gemini vs Claude vs an open-weight model), not a platform choice. Two teams on the same platform can have wildly different bills.
• Memory and tool costs. Each platform meters memory and tools differently; at scale these add up and are easy to under-budget. The per-vCPU-hour rate is not the whole runtime story.
• Lock-in and migration cost. Moving an agent between these runtimes is not free - the first-party SDKs differ, and the identity/memory/tool integrations are platform-specific. LangGraph portability softens this but does not remove it.

When to bring in a partner

• The cross-cloud choice itself. If you are genuinely cloud-agnostic, the right platform depends on a sober look at where your data, identity, and team already are - and the switching cost if that changes.
• TCO across three billing models. Comparing per-component consumption (AWS), per-vCPU-hour-plus-free-tier (GCP), and free-native-but-gated-hosted (Azure) is not a one-line calculation - and Azure’s numbers are behind the calculator.
• The Azure “numbers behind the sign-in” problem. If Foundry is a contender, someone has to do the calculator and sales-conversation work to get real figures. That is exactly the kind of legwork a partner does before you commit.

Summary

AWS AgentCore, Google Vertex AI Agent Engine, and Microsoft Foundry Agent Service are the same core offering from three clouds: a managed, isolated runtime where you bring your framework and run agents in production. Three things to hold onto:

1. They converge on the pattern, differ on the details. Same bring-your-framework managed runtime; different first-party SDKs (Strands / ADK / Microsoft Agent Framework), memory models, and ecosystems.
2. Pricing transparency is not equal. AWS and Google publish per-vCPU-hour runtime rates; Azure keeps Foundry’s behind the calculator. You can back-of-envelope two of the three; the third needs the calculator.
3. The platform is not what sets your cost. Model inference dominates the bill on all three. Pick on ecosystem gravity, then manage the model-and-volume spend - that is where the money actually is.

Frequently asked questions

Choosing an agent platform across AWS, GCP, or Azure?

Book a free 30-minute call. We help teams pick between AgentCore, Vertex Agent Engine, and Foundry on the honest criteria - ecosystem fit, real TCO across three billing models, and the Azure numbers that live behind the calculator.

Book a call Send a message