TL;DR
- AI agents can run across AWS, Azure, and GCP today. AWS AgentCore, Microsoft Foundry Agent Service, and Vertex AI Agent Engine each give you a capable managed runtime.
- The hard part isn’t deployment. It’s maintaining one identity model, one observability view, and one policy set once agents exist in three separate clouds.
- Each cloud solves identity, monitoring, and lifecycle differently: AWS through workload identities in AgentCore Identity, Azure through Entra Agent IDs in Foundry Agent Service, and Google through SPIFFE-based agent identity in Vertex AI IAM.
- Azure Arc unifies Kubernetes infrastructure across clouds, but it doesn’t govern agent identity, agent-to-agent communication, or agent-level audit trails.
- A cloud-agnostic Control Plane sits above the three runtimes to provide the one thing none of them provide on its own: a single governed view of the entire agent estate.
Yes, AI agents can run across AWS, Azure, and GCP. In fact, getting an agent up and running in each cloud is becoming less of a challenge.
The real challenge is what happens after that. How do you make agents running in three different environments behave like one consistent, governed system instead of three separate deployments that happen to do similar things?
That’s the question more enterprise teams are starting to face as they explore agent infrastructure. Do we run agents wherever our workloads already live, or standardize on a single cloud? The answer is that you can do either, and you can run agents across all three. But running an agent is one problem. Managing its identity, access, policies, behavior, and lifecycle across clouds is another.
Can AI Agents Run on AWS, Azure, and GCP at the Same Time?
AWS, Azure, and Google Cloud have each shipped a serious, production-grade agent runtime in the last year, and none of them are toys.
AWS: AgentCore Identity
AWS runs agents through Amazon Bedrock AgentCore, with a dedicated identity and credential layer called AgentCore Identity. Amazon Bedrock AgentCore Identity is an identity and credential management service designed specifically for AI agents and automated workloads, providing secure authentication, authorization, and credential management capabilities that enable agents and tools to access AWS resources and third-party services on behalf of users. AWS treats this as distinct from human identity from the ground up. Agent identities in AgentCore Identity are implemented as workload identities with specialized attributes, and unlike traditional service accounts that are tied to specific infrastructure, agent identities are designed to be environment-agnostic and can support multiple authentication credentials simultaneously.
Azure: Foundry Agent Service
Azure’s equivalent is Foundry Agent Service, part of what’s now called Microsoft Foundry. Foundry runs your code with a managed endpoint, automatic scaling, a dedicated Microsoft Entra identity, session-level state persistence, and end-to-end observability. Microsoft has been direct about why this exists. When you build agentic applications using open-source frameworks, you typically manage many cross-cutting concerns including containerization, security, memory persistence, scaling, instrumentation, and version rollbacks, and these tasks become even more challenging in heterogeneous cloud environments. Foundry hosted agents also get private networking. You can run agents with Entra Agent ID, private networking options including bring-your-own VNet with no public egress, and flexible authentication for tool access, then trace, evaluate, and enforce guardrails.
Google Cloud: Vertex AI Agent Engine
Google’s answer runs through Vertex AI Agent Engine. Agent identity provides a per-agent identity that enables a least-privilege approach and is tied to the lifecycle of the agent, making agent identity a more secure principal than service accounts, and existing access management controls through IAM support agent identity to enable strong governance. Underneath, that identity is cryptographic and built on an open standard rather than a proprietary scheme. Agent Identity provides a strongly attested, cryptographic identity for each agent that is based on the SPIFFE standard, and access tokens generated for Google Cloud are cryptographically bound to the agent’s unique X.509 certificates to prevent token theft.
Individually, these are well-built systems. Read them one at a time and each cloud looks like it has solved the agent problem. The trouble starts when an enterprise has all three running at once, because none of them were built to talk to the other two. Teams evaluating this from a platform-engineering lens will recognize the pattern already covered in Lyzr’s guide to enterprise AI agent deployment and scale: the runtime is rarely the bottleneck. The operating model around it is.
Why Multi-Cloud AI Agents Break Down in Production
Here’s the scenario every platform team ends up in eventually. Agent A lives on AWS and handles document intake. Agent B lives on Azure and does policy checks against Entra-governed data. Agent C lives on GCP and runs the analytics step. Each one works. Each one is monitored, versioned, and secured inside its own cloud.
Now a single customer request has to move through all three.
Identity breaks first. AWS workload identities, Entra Agent IDs, and Vertex’s SPIFFE-based identities are not interchangeable credentials. There’s no shared trust anchor that says “this AWS agent is allowed to call that Azure agent on behalf of this user.” You either build custom trust brokering between three IAM systems, or you grant broader access than you’d like just to make the handoff work. Neither is a governance posture you want to explain to an auditor.
Communication breaks second, and it’s less solved than most teams assume. The Agent2Agent protocol was built for exactly this kind of cross-boundary handoff. The Agent-to-Agent protocol, introduced by Google in 2025, addresses a complementary challenge to that solved by MCP: whereas MCP standardises the connection between an agent and its tools, A2A standardises communication between AI agents built on different frameworks, enabling them to discover one another’s capabilities and collaborate on complex tasks. The two protocols sit at different layers by design. MCP is vertical, model to tools and data. A2A is horizontal, agent to agent.
They are complementary, not competing. Microsoft’s own hosted agent platform reflects the same split. Foundry Agent Service supports the OpenResponses and Activity Protocols for Microsoft 365 publishing, an Invocations protocol for flexible endpoint integration with custom apps and services, and the A2A protocol for agent-to-agent communication. That’s a clean story inside one cloud. It gets considerably messier once Agent A’s AWS-issued credentials need to be trusted by an A2A handshake initiated from Azure.
Observability breaks third, and it’s the one platform teams feel first. Azure Monitor gives you a real, end-to-end view, but only of the resources Azure knows about. Azure Monitor provides end-to-end observability for your applications, infrastructure, and network. CloudWatch does the same for AWS. Cloud Logging does the same for GCP. None of them see past their own cloud boundary. When a request fails somewhere in a three-hop, cross-cloud chain, someone is manually correlating timestamps across three different logging systems to find out where it actually broke.
Policy and audit fragment the same way, for the same underlying reason. Each cloud’s IAM console, policy engine, and audit log were built to govern resources inside that cloud. None of them were designed to answer a cross-cloud question like “show me everything Agent C did across all three environments last week.” It’s not a compute problem. AWS, Azure, and GCP each built a governance model for their own agents, and none of the three were built to recognize the other two.
How Identity and Observability Differ by Cloud
| Cloud | Agent Identity Model | Native Observability | Governance Boundary |
| AWS | Workload identities via AgentCore Identity | Amazon CloudWatch | Scoped to AWS account and IAM policy |
| Azure | Dedicated Microsoft Entra Agent ID via Foundry | Azure Monitor and Application Insights | Scoped to Azure tenant and Entra policy |
| Google Cloud | SPIFFE-based Agent Identity via Vertex AI IAM | Google Cloud Logging and Cloud Monitoring | Scoped to GCP project and IAM policy |
Native Cloud Tools vs. Kubernetes: Do Either Solve Multi-Cloud Agent Governance?
Faced with that fragmentation, platform teams generally reach for one of two fixes.
Lean harder into each cloud’s native tooling. This is the path of least resistance, and it’s genuinely fine for a single-cloud estate. But it doubles down on the exact problem you’re trying to solve. Every cloud-native feature you adopt is a feature you now have to reconcile against two other clouds’ equivalents. You end up with three governance models that each work well in isolation and don’t add up to one. It’s the same underlying dynamic covered in Lyzr’s look at how enterprises escape AI vendor lock-in: the more deeply you commit to one vendor’s opinionated stack, the more expensive it becomes to unwind later.
Standardize on containers and run everything on Kubernetes. This buys you a consistent compute layer. An agent packaged as a container behaves similarly whether it’s on EKS, AKS, or GKE. Azure Arc extends this further by letting you manage clusters outside Azure from inside Azure. Azure Arc is a bridge that extends the Azure platform to help you build applications and services with the flexibility to run across datacenters, at the edge, and in multicloud environments. Azure Arc simplifies governance and management by delivering a consistent multicloud and on-premises management platform, providing a centralized way to manage entire environments by projecting existing non-Azure and on-premises resources into Azure Resource Manager.
That’s a real capability, and it’s worth using for what it’s built for. It’s also not an agent governance answer. Arc gives you one control plane for Kubernetes infrastructure: clusters, nodes, policies about the compute layer. It has nothing to say about which agent identity is allowed to call which other agent, what an agent’s telemetry looked like across a cross-cloud hop, or whether Agent C’s last thousand actions match the policy your compliance team signed off on. Arc governs the box the agent runs in. It doesn’t govern the agent.
What Is a Cloud-Agnostic AI Agent Control Plane?
Once you strip away the tooling, the open question is simple: who governs all three?
Not “who hosts the agents.” Each cloud already answers that. The open question is who owns a single identity model that spans AWS, Azure, and GCP; a single observability view that shows a request’s full path regardless of which cloud it touched; and a single policy engine that enforces the same rule whether the agent runs on AgentCore, Foundry, or Agent Engine.
That layer is a Control Plane, and it’s architecturally distinct from a gateway. An Agent Gateway is a data-plane concern. It routes a request, handles the handshake, moves traffic from one agent to another. A Control Plane is a management-plane concern. It decides what’s allowed, records what happened, and holds the policy that the gateway enforces. You can build the first without the second. You cannot govern anything with only the first.
Lyzr’s Control Plane as a Service is built to occupy exactly this layer: cloud-agnostic governance sitting above the runtimes rather than replacing them.
How Lyzr’s Control Plane Governs Agents Across AWS, Azure, and GCP
Lyzr’s Control Plane doesn’t ask you to move agents off AWS, Azure, or GCP. It’s cloud agnostic, deploying into AWS Bedrock AgentCore or Google Cloud’s Vertex AI Agent Engine so that agents run inside the customer’s own environment, which keeps data privacy and sovereignty intact. The agents stay where your teams already put them. What changes is what sits above them.
It also treats framework choice as a non-issue. The Control Plane is framework agnostic, accepting agents built with LangGraph, CrewAI, Strands, the Lyzr SDK, or proprietary code, all moving through the same path and appearing in one shared catalog. Concretely, that means agents built on different runtimes and different frameworks are treated as one estate rather than three separate ones each with their own rules.
The reason this matters shows up in how agent programs actually stall. Research from Forrester and Anaconda, supported by IDC, indicates that roughly 88 percent of AI agent pilots never reach production. Fragmented governance across three clouds is a large part of why. Teams can build an agent. What breaks the handoff to production is proving, consistently, who that agent is, what it did, and whether it stayed inside policy while doing it.
Before an agent reaches production traffic, it runs through checks rather than shipping straight from prototype to live. The step most relevant to risk teams is what happens before an agent reaches live traffic, since agents are never deployed straight to production. This is the gate between non-prod and production: an automated evaluation suite runs against the live non-prod agent, and if evaluations pass, a Pull Request is automatically created to the production branch with the configured approvers. That’s the same gate, applied the same way, whether the agent in question is sitting on AgentCore, Foundry, or Agent Engine.
For platform engineering teams building this out, or CIOs weighing where to place accountability for a cross-cloud agent estate, the practical questions are less about which runtime to standardize on and more about who owns the policy that has to hold across all of them. That’s the conversation Lyzr’s platform teams resources are built around, and it’s the same conversation Lyzr’s CIO-focused guidance addresses from the accountability side.
Control Plane for Hyperscalers
The Bottom Line on Multi-Cloud AI Agent Governance
Multi-cloud agent deployment will keep getting easier. AWS, Microsoft, and Google are all investing heavily in their respective runtimes, and each one will keep closing gaps in identity, tooling, and observability inside its own boundary.
None of that solves the boundary problem. AWS will make AgentCore better at being AWS. Azure will make Foundry better at being Azure. Google will make Agent Engine better at being Google Cloud. Improving three separate systems doesn’t merge them into one.
The enterprises that get multi-cloud agent governance right won’t be the ones that pick a single cloud to avoid the problem, and they won’t be the ones that bolt together custom identity bridges between three IAM systems and hope it holds. They’ll be the ones that put a governance layer above all three from the start, so that adding a fourth agent, on any cloud, doesn’t mean building a fourth set of rules.
If your team is past the pilot stage and staring down a second or third cloud’s worth of agents, the question worth sitting with isn’t which runtime to standardize on. It’s whether you currently have one policy that would survive being applied to every agent you run, regardless of which cloud it’s on. If the honest answer is no, that’s the gap a Control Plane is built to close.
Frequently Asked Questions
Yes. Each cloud provider now offers a managed, production-grade agent runtime: AWS Bedrock AgentCore, Microsoft Foundry Agent Service, and Vertex AI Agent Engine. The limitation isn’t technical capability inside any one cloud. It’s maintaining one consistent identity, observability, and policy model once agents span all three.
Native runtimes are worth using for the workloads that already sit in that cloud. AWS AgentCore, Foundry Agent Service, and Vertex AI Agent Engine each handle scaling, session state, and basic observability well. The mistake is assuming that adopting all three natively gives you a unified operating model. It gives you three good ones that don’t talk to each other.
Each cloud issues its own agent identity: AWS uses workload identities through AgentCore Identity, Azure assigns a dedicated Microsoft Entra ID per agent through Foundry, and Google uses a SPIFFE-based cryptographic identity through Vertex AI IAM. None of these are natively interchangeable, which is why cross-cloud agent calls typically require a governance layer that maps identity consistently across all three.
Cross-agent communication generally runs through the Agent2Agent protocol, which handles task delegation between agents, while the Model Context Protocol handles an agent’s connection to its own tools and data. A2A works cleanly within a single cloud’s ecosystem; extending that trust across cloud boundaries is where a governance layer becomes necessary.
Native tools like Azure Monitor, Amazon CloudWatch, and Google Cloud Logging each give strong visibility inside their own cloud, but none extend past it. Centralized monitoring across all three requires a layer that aggregates telemetry from each runtime into one trace, rather than three separate logging consoles.
Avoiding lock-in means keeping the governance layer, identity model, and policy engine separate from any single cloud’s native tooling. A Control Plane that sits above AWS, Azure, and GCP runtimes lets you add or shift cloud providers without rebuilding your security and compliance model each time.
Yes, containerizing agents on Kubernetes gives you a consistent compute layer across EKS, AKS, and GKE. It solves runtime consistency, not governance. You still need a separate answer for cross-cluster identity, unified policy enforcement, and centralized audit logging.
No. Azure Arc unifies Kubernetes infrastructure management across clouds and on-premises environments, but it operates at the infrastructure layer. It doesn’t govern agent-level identity, agent-to-agent communication, or agent-specific audit trails, which is where multi-cloud agent governance actually breaks down.
If your agent estate spans more than one cloud, a separate control plane is what provides a single identity model, unified observability, and consistent policy enforcement across all of them. Without it, each cloud’s native governance tools stay siloed to that cloud, and cross-cloud agent interactions go ungoverned.
Book A Demo: Click Here
Join our Slack: Click Here
Link to our GitHub: Click Here
