Six axes carry the decision — feature lists do not
Lesson 1 of 5 in Choosing a Cloud for Agents: A Decision You Can Defend.
Three modules ago you did not know what AgentCore Runtime, Foundry hosted agents, or Agent Runtime on Google Cloud were. Now you do — and that knowledge is close to useless on its own, because the feature lists have converged. All three will run your framework code in an isolated per-session sandbox, broker credentials for tools, emit traces and run evaluations; AWS and Google Cloud additionally sell a service that derives long-term memory from conversations, and AWS and Foundry both front tools behind an MCP-compatible endpoint while on Google Cloud MCP arrives as an ADK tool type. Anything one of them ships, the other two tend to ship within a couple of quarters.
So a feature-by-feature comparison cannot decide this. What decides it is the shape of your organisation: where your data already sits, who issues your identities, where your users expect to meet the agent, what boundary your regulator drew, what you have already committed to, and what your team can actually operate at 3 a.m. This lesson turns those into six weighted axes and — just as important — tells you which loud inputs are not axes at all.
Weight the axes before you look at any platform. That ordering matters: a team that reads three vendor pages first will unconsciously score the axes so that its favourite wins. Write the weights down, then gather evidence — a query against your own inventory, a screenshot of your identity provider, last quarter’s bill — not opinions.
One rule keeps this honest: an axis earns weight only if a plausible answer to it would rule a platform out. "Nice developer experience" never rules anything out; "conversation history must remain in resources inside our own tenant, in the EU" rules out any setup that cannot demonstrate it.
Key terms: data gravity, data residency, agent identity, lock-in, egress control, least privilege
| Axis | Evidence to gather (not opinions) | Typical weight | How it rules a platform out |
|---|---|---|---|
1 · Data gravity — where the systems of record already live | List the top ten data sources the agent must read or write, with sizes and owners. Where do they physically sit today? | Highest. Usually decisive on its own. | An agent whose corpus is 8 TB of documents in one cloud, running in another, pays egress and latency on every retrieval and needs a second identity plane to reach it. Gravity rarely moves; the agent does. |
2 · Identity provider — who issues the principal the agent acts as or on behalf of | Name the IdP for employees and for customers. Name the authorization system the downstream APIs actually check. | Very high. Identity wiring is the least portable layer you will build. | Each platform’s agent-identity story is native to its own directory: Entra agent identities with OAuth 2.0 on-behalf-of on Foundry, IAM-based agent identity on Google Cloud, AgentCore Identity with workload tokens plus an IAM execution role on AWS. Fighting your own IdP here costs quarters. |
3 · Delivery surface — where users meet the agent | Ask ten intended users where they would expect to use it: a web app you own, Teams, Slack, an API, a support console. | High when the answer is a first-party surface; low when it is your own app. | If adjusters live in Microsoft Teams, Foundry’s documented publish path to Microsoft 365 Copilot and Teams (with an admin-approval step for org-wide scope) is a capability the others do not hand you. If the surface is your own React app, this axis drops to near zero. |
4 · Boundary constraints — residency, keys, private networking, egress | Get the actual clause, from the actual contract or regulator. Then map it component by component: runtime, memory, tool calls, traces, evaluation data. | Binary. Either satisfiable or fatal. | All three publish controls in this space — Foundry standard setups require bring-your-own Storage, AI Search and Cosmos DB so agent data stays in your tenant, plus injected virtual networks and private endpoints; Google Cloud lists VPC Service Controls, CMEK and data residency at rest across Runtime, Sessions, Memory Bank and Code Execution; AWS runs sessions in dedicated microVMs with encrypted credential storage and namespace-isolated memory. The trap is component coverage, not headline support. |
5 · Commitments and landing zone — spend, support, and the guardrails you already run | Last four quarters of cloud spend by provider, committed-spend agreements, and where your org’s account-vending, network and policy tooling already works. | Medium-high, and honest about it: this is a real cost, not a bias. | A platform outside your landing zone means new accounts or subscriptions, new network peering, new policy baselines and a new audit story. That work is measured in months of platform-team time — count it in the comparison instead of pretending it is free. |
6 · Team skills and on-call — what you can operate under pressure | Which languages ship to production today, whether you already run containers or Kubernetes, and who is on the rotation. | Medium — and it moves the managed-versus-self-hosted choice more than it moves the vendor choice. | Language surface is a real filter: ADK publishes Python, TypeScript, Go, Java and Kotlin SDKs; Foundry hosted agents accept a container image or a source zip with several frameworks; AgentCore is framework- and model-agnostic. A team with no container practice should not choose the option whose happy path is a Dockerfile. |
Interactive sorting exercise: Ten things a real selection meeting says out loud. Which axis does each one actually load — and which are noise dressed up as evidence?
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.