Multi-Cloud Agent Sandbox Comparison 2026

The four managed agent runtimes, side by side

Every major cloud now ships a managed execution environment aimed at production AI agents. None of them built it the same way. The The New Stack piece on cloud agent code sandboxes (July 24, 2026) was the first consolidated comparison; this article is the operational follow-on — the dimensions that actually matter when you are choosing one for a production fleet, and the migration contract if you have to move between them.

The four runtimes are:

• AWS Bedrock AgentCore Runtime — Firecracker-backed Lambda MicroVM sessions on the AWS Lambda plane, with an eight-hour hard cap and suspend/resume. Managed by AWS, integrated with IAM Roles Anywhere for identity and with CloudWatch + X-Ray for telemetry. AWS AgentCore docs.
• Google Vertex Agent Engine — gVisor-backed GKE Agent Sandbox plus a Cloud Run fallback for short-lived work. Identity via Google Cloud IAM, telemetry via Cloud Logging + Cloud Trace, with an OTel exporter optional. The Vertex Agent Engine overview now redirects to the Gemini Enterprise Agent Platform scale page.
• Azure Container Apps Dynamic Sessions — Hyper-V boundary isolation, Entra ID for identity, pool-managed concurrent-session quota. Azure Container Apps sessions docs.
• Cloudflare Sandboxes — VM-isolated sessions controlled through Workers and Durable Objects. Cloudflare Workers Analytics is the primary observability surface, OTel exporter available. Cloudflare Agents docs.

Each one runs an agent image with an isolation boundary, an identity primitive, an egress policy model, and a lifecycle cap. The choice between them is not "which is the best" — it is "which one matches the operational capacity your platform team already has, the identity model your enterprise already runs, and the multi-cloud posture your security team has already committed to." The article below covers the four dimensions that determine that match.

Late-2026 posture update: what changed since the original July 2026 cut

Three things have moved across the four runtimes since the original TNS comparison drove this article. None of them are breaking changes, but each one shifts the operational weight between the four clouds on a fleet that's currently making the production-agent decision.

• OpenTelemetry v2 spans now emit gen_ai.usage.cache_creation.input_tokens and gen_ai.usage.cache_read.input_tokens — the cross-cloud observability baseline moved. Until late August, the cache-token counts an OTel-only spend rollup used to derive cache cost were silently missing on LiteLLM's v2 emit; the four managed runtimes that sit behind LiteLLM as the proxy surface inherited the same gap. The LiteLLM 1.99.1 Docker-only release (Sept 2, 2026) closes the gap, which means an OTel-only spend dashboard wired against any of the four runtimes now reconciles cache-token accounting end to end — see the LiteLLM production monitoring 2026 guide for the per-call cost arithmetic and the LLM cost monitoring tools 2026 roundup for the broader rollup pattern.
• The CNCF agent-sandbox + agent-substrate SIG Apps pair graduated from announcement to early production usage — Lin Sun's July 7, 2026 piece on why sandboxing your agent is not enough was the announcement; the late-August 2026 update is the first multi-region production deployments. The CNCF pair is the OSS-first, Kubernetes-portable counterpart to the four managed runtimes, and the Agent Sandbox vs. Agent Substrate guide is the architectural breakdown of when each one fits.
• Cloudflare Workers AI added per-session KV durability for the agent-side state — Durable Objects moved from "cache the last response" to "durable per-session scratchpad" with the late-August update. For the four-managed-runtime comparison this means the Cloudflare option now handles stateful multi-turn agents without an external Redis, which moves the cost model closer to a Lambda-style per-request billing. The observability 2026 pillar covers the OTel-side pattern that lets you watch a Durable-Object agent the same way you watch a Bedrock agent.

The rest of this article is the wire-level comparison as it stood when the four runtimes all shipped; the three changes above are the operating deltas a platform team evaluating today should factor in alongside the four dimensions below.

Dimension 1: isolation primitive — what actually separates the agent from the host

The isolation primitive is the cheapest thing to under-specify and the most expensive thing to retrofit. The four clouds chose four different primitives, and the operational consequences diverge quickly.

• AWS Bedrock AgentCore: Firecracker microVMs. Firecracker (github.com/firecracker-microvm/firecracker) is a hardware-virtualized guest with a minimal Linux kernel; it boots in <125ms and runs the agent as the only user process. The blast radius of a successful exploit is one microVM; the host sees only block-device I/O and a small set of virtio-emulated devices. The cost is GPU passthrough complexity: Firecracker's KVM-based device assignment needs the GPU driver to be re-initialized inside the guest, which adds 5-15 seconds to cold start on the first invocation. For long-running agents the overhead amortizes; for bursty serverless invocations it dominates.
• Google Vertex Agent Engine: gVisor on GKE Agent Sandbox. gVisor is a user-space kernel (the Sentry) that intercepts every syscall and translates it before it reaches the host kernel. The host sees only the Sentry's syscalls. The blast radius is the same as Firecracker (a successful exploit is contained to the user-space kernel), but the cost is syscall throughput: gVisor adds 1-3 microseconds per syscall, and inference workloads are syscall-heavy. For the latency-critical inference path, gVisor is the wrong primitive; for the agent-orchestration path (where the agent makes a model call and waits), gVisor is the right cost point.
• Azure Container Apps Dynamic Sessions: Hyper-V boundary. Hyper-V is the same hardware-virtualization primitive as Firecracker, but with a full Windows-or-Linux guest kernel rather than Firecracker's minimal device model. Cold start is slower (2-6 seconds for a Dynamic Session pool instance), but the guest has a richer syscall surface which means broader compatibility with off-the-shelf agent images without recompilation. The cost is operational: each Hyper-V boundary is a heavier tenant than a Firecracker microVM, so concurrent-session density per host is lower.
• Cloudflare Sandboxes: VM-isolated sessions under Workers. Cloudflare's isolation story for agents is the same Firecracker-class microVM primitive AWS uses, but the control plane is Workers and Durable Objects rather than Lambda. The deployment mental model is fundamentally different: you ship a Worker that controls a Durable Object, and the Durable Object owns the agent sandbox lifecycle. The cost is the runtime capability — Workers can't run every agent framework, and the agent image has to fit Cloudflare's edge-runtime constraints. The benefit is the cost model: per-request, not per-session, with cold start dominated by the edge POP rather than the GPU driver.

Why does the isolation primitive matter for your choice? Because the blast radius of a successful exploit on a vLLM inference engine — see CVE-2025-9141 (CVSS 8.8) on Qwen3-Coder tool-call parsing, where Python's eval() was reachable from the model output — is the same on every cloud. The question is which isolation primitive your agent actually needs to be safe in. A coding agent with file-system access and shell-out wants Firecracker (or equivalent). A model-only agent that just calls a hosted model API is fine on gVisor. An agent that runs on Windows because of a legacy dependency is fine on Hyper-V. An edge-deployed webhook agent that needs sub-second cold start is fine on Cloudflare Workers. The right primitive is the one that matches the threat model, not the one with the most impressive isolation pedigree.

Dimension 2: lifecycle — what happens between cold start and shutdown

The lifecycle model is where the four runtimes diverge most operationally. The decision rule: stateful long-running agents and bursty webhook agents want different lifecycles, and the runtime you pick must match the agent you actually have.

Runtime	Max session	Suspend/resume	Cold start
AWS Bedrock AgentCore	8h hard cap	Yes (Lambda plane)	2-4s
Google Vertex Agent Engine	24h (GKE) / 60min (Cloud Run)	GKE yes, Cloud Run no	3-8s (GKE) / <1s (Cloud Run)
Azure Dynamic Sessions	Pool-managed	Pool-warm, no suspend	2-6s
Cloudflare Sandboxes	Per-Worker, no inherent cap	Durable Object state survives	<1s (edge POP)

The stateful-versus-bursty split that the Agent Sandbox vs. Agent Substrate guide walks through for the CNCF runtimes maps onto the managed runtimes too. A customer-success triage agent that holds an open conversation for two weeks is a stateful long-running workload: AWS Bedrock AgentCore's 8-hour cap is disqualifying, Google Vertex Agent Engine on GKE is the right answer if you are GCP-native, Azure Dynamic Sessions with a long-lived pool is the right answer if you are Azure-native, and Cloudflare Sandboxes only fits if the conversation state lives in a Durable Object rather than in the agent image itself. A webhook-triggered marketing agent that fires when a Stripe event arrives and dies five seconds later is the opposite: AWS Bedrock AgentCore (with the per-invocation cold start), Cloudflare Sandboxes (per-request, edge POP), or Google Cloud Run fallback (sub-second cold start on the parent instance's CPU/memory) all fit. The decision is about the lifecycle shape, not the brand.

How long can an agent session actually live on each runtime? The honest answer is "exactly as long as the runtime's hard cap allows, minus whatever the operational overhead of session migration costs you." AWS Bedrock AgentCore's 8-hour cap is the most aggressive — a multi-day coding agent has to migrate sessions, which means serializing session state into an external store and rebuilding it on the next microVM. Google Vertex Agent Engine on GKE Agent Sandbox has no inherent session cap (the StatefulSet keeps a pod warm), but you pay for the StatefulSet's resource reservations. Cloudflare Workers + Durable Objects has no inherent session cap either, but the agent image has to fit the Workers bundle size limit. Azure Dynamic Sessions is pool-managed — sessions are queued through a pool, and pool readiness determines effective max-session length. The right cap is the one that matches the agent's natural session shape; over-engineering for a multi-week session when your agent is actually a 5-second webhook handler is the most common mis-spec.

Dimension 3: identity — how the agent proves who it is

The identity primitive is where the four runtimes diverge in ways that determine the multi-cloud portability story. Each cloud has a different default identity model, and the choice you make on day one determines whether a year from now you can move workloads between clouds without re-issuing per-agent credentials.

• AWS Bedrock AgentCore: IAM Roles Anywhere. Per-session identity, bound to the AWS IAM plane. The agent presents an X.509 SVID at session start, the AgentCore control plane exchanges it for an AWS role session, and the agent makes downstream AWS API calls with that role. The cost is the AWS lock-in — the SVID exchange is AWS-specific, and a multi-cloud deployment has to run a parallel identity plane on each cloud.
• Google Vertex Agent Engine: Google Cloud IAM service accounts. Per-agent workload identity bound to the GCP project. SPIFFE-compatible in principle (GCP now publishes workload identity federation tokens in SPIFFE format), but the operational path is "service account JSON key file," not the SPIFFE workload API. Same multi-cloud cost as AWS — one identity plane per cloud.
• Azure Dynamic Sessions: Entra ID managed identities. Per-session managed identity bound to the Entra ID tenant. The cleanest identity story of the four for enterprises that already run on Entra, because the audit log and the conditional access policies the enterprise already has Just Work. The cost is the same multi-cloud cost, plus an Entra-specific lifecycle to manage.
• Cloudflare Sandboxes: Cloudflare Access + Durable Object identities. Per-Durable-Object identity, signed by Cloudflare's edge. The most portable identity model — the Durable Object identity is just an Ed25519 keypair that the Worker generates — but the operational cost is that Cloudflare's edge control plane is the trust root, not your enterprise IdP.

The portable identity answer is SPIFFE — the CNCF agent-sandbox project uses SPIFFE per-agent, and the runtime identity is the same SVID regardless of which cloud hosts the workload. None of the four managed runtimes ship SPIFFE as the default identity model in 2026 (Google's workload identity federation is the closest), but AgentCore on AWS is the only one with first-class SPIFFE interop via IAM Roles Anywhere. For a multi-cloud posture, plan to run a SPIFFE control plane (e.g. SPIRE) on top of whatever cloud-native identity the runtime ships, and exchange the SVID for the cloud-native credential at the workload boundary. The cost is operational complexity; the benefit is that a year from now you can move a workload without re-issuing credentials.

Dimension 4: OTel portability — can you actually observe the agent the same way on each runtime?

The OTel portability question is the one that determines whether you can roll out a fleet of agents across multiple clouds with the same observability story. Each of the four runtimes ships a cloud-native observability surface (CloudWatch + X-Ray, Cloud Logging + Cloud Trace, Azure Monitor, Cloudflare Workers Analytics), and each one ships an OTel exporter as the portable path. The exporter coverage is uneven, and the OTel attributes that surface from each runtime are different enough to matter.

The provider-neutral telemetry fields that every runtime should emit, regardless of which cloud's OTel exporter is in use:

• agent.runtime — string identifying the managed runtime: aws-bedrock-agentcore, google-vertex-agent-engine, azure-dynamic-sessions, cloudflare-sandboxes. Lets you filter "show me only AWS AgentCore spans" without depending on a cloud-specific resource attribute.
• agent.session.id — string identifying the agent session. Per-Durable-Object on Cloudflare, per-Lambda-activation on AWS, per-GKE-pod on Google, per-pool-instance on Azure. The semantic is the same (one agent invocation), the implementation differs.
• agent.identity — string carrying the SPIFFE SVID or the cloud-native identity alias. The join key for cross-cloud audit queries.
• agent.cold_start_ms — number, duration of the cold-start phase. On Cloudflare this is dominated by the edge POP latency; on AWS by the Firecracker boot; on Google by the GKE pod scheduling or the Cloud Run warm-pool hit; on Azure by the Dynamic Sessions pool readiness.
• gen_ai.* — the standard OpenTelemetry GenAI semantic conventions (gen_ai.system, gen_ai.request.model, gen_ai.usage.input_tokens, gen_ai.tool.name). The four runtimes all emit these when the agent makes a model call, but the coverage on tool calls and agent-loop spans is uneven. AWS AgentCore emits the full set via the CloudWatch + X-Ray OTel exporter; Google Vertex Agent Engine emits the inference spans but not the agent-loop spans; Azure Dynamic Sessions ships an OTel exporter that covers the model-call side but not the orchestration side; Cloudflare Workers Analytics emits the inference spans natively, with an OTel exporter for the rest.

Can you observe a multi-cloud agent fleet through one pane of glass? Yes — every runtime ships an OTel exporter, and the provider-neutral attributes above let you join spans across clouds without depending on a cloud-specific resource attribute. The minimum viable setup is an OTel Collector that receives from each cloud's exporter, normalizes the four provider-neutral fields above, and fans out to your trace store (Tempo or ClickHouse) and your metric backend. The cost is that you own the Collector-side normalization — none of the four clouds ship a pre-normalized multi-cloud OTel pipeline. For the storage trade-off (Tempo vs ClickHouse vs HyperDX for trace-store selection), the State of Observability 2026 guide covers the trace-store-vs-column-store positioning; for the per-agent cost-attribution side of the observability stack, the Coding Agent Cost Observability guide has the per-engineer token-cost schema the multi-cloud fleet needs to roll up against.

The migration contract: what moves and what doesn't

If you pick a managed runtime today and need to move workloads between clouds in 12 months — either for cost, or for a procurement-mandated multi-cloud posture, or because a runtime sunset happens (Cloudflare has already shipped and de-shipped edge-runtime features in the past; the same is true of Lambda's container support) — the migration contract is the OTel attribute set above plus the agent image format. The agent image has to be portable across the four runtimes: a container image that runs on Firecracker, on gVisor, on Hyper-V, and on Workers. In practice this means:

• No Lambda-specific layers (no Lambda runtime API calls in the agent image). On AWS Bedrock AgentCore the agent runs as a Lambda invocation, but the image format is a regular container.
• No GKE-specific deployment manifests. The agent image is a container, the deployment topology is the runtime's responsibility.
• No Windows-specific code paths in the agent. The four runtimes are all Linux-based; an agent that requires Windows is a special case that needs a different migration story.
• No Cloudflare Workers-specific bindings in the agent. The agent image is a container, not a Worker script.

The migration cost is roughly 1-2 engineer-weeks per workload if the agent image is portable and the OTel attributes are normalized. The migration cost balloons to 4-6 engineer-weeks if the image has Lambda-specific layers or if the observability stack is wired to CloudWatch rather than to a portable OTel Collector. The right call on day one is to commit to the portable OTel attributes and the portable container image format. The cost is a small upfront tax on the platform team; the benefit is that you can move workloads without a re-platforming project. For the cost arithmetic that drives the multi-cloud posture decision, the LLM API Cost Calculator turns the per-token cost of a cross-cloud agent fleet into the spend baseline the migration has to beat; for the broader FinOps posture across clouds, the LLM FinOps 2026 guide walks through the rollup patterns the multi-cloud posture needs.

Decision tree: which runtime for which agent

1. Is the platform team unwilling to operate Kubernetes for the agent runtime, but the rest of the stack is OSS / multi-cloud? Move to Docker Sandboxes (the closed-source managed counterpart, see the Agent Sandbox vs. Agent Substrate guide for the full comparison). The dev loop runs the same Dockerfile, the OTel pipeline is the same, and the platform team gets to claim "we don't operate the control plane" without surrendering the portability story. The cost is per-session cold-start latency — accept 2-4 seconds per invocation and the dev loop is fine.
2. Is the platform team on AWS end-to-end, with an explicit "no second control plane" mandate? Move to AWS Bedrock AgentCore Runtime. The IAM Roles Anywhere identity plane is the AWS-native equivalent of SPIFFE, and the 8-hour cap is the right shape for the multi-day agent workload if you can serialize session state to an external store. The cost is the AWS Lambda lock-in.
3. Is the platform team on GCP-native, with explicit "we want the Google agent primitives" buy signal? Move to Google Vertex Agent Engine. The GKE Agent Sandbox + Cloud Run fallback pattern is the Google-native equivalent of the CNCF primitives. The cost is the same multi-cloud lock-in as AgentCore — choose this and the agent runtime is on Google, not on yours.
4. Is the platform team on Azure-native, with Entra ID as the enterprise identity root? Move to Azure Container Apps Dynamic Sessions. The Entra ID managed identity is the cleanest identity story of the four for enterprises that already run on Entra, and the Dynamic Sessions pool-managed concurrent-session quota is the right shape for bursty enterprise agents that hit the same MCP servers. The cost is the Hyper-V cold start and the Azure lock-in.
5. Is the agent workload edge-native (latency-sensitive, ephemeral, low-cost per-request)? Move to Cloudflare Workers + Durable Objects. The per-request cost model is the right answer for very-high-throughput, low-cost agents. The cost is the runtime capability — Workers can't run every agent framework, and the audit trail is Cloudflare-native, not OTel-native.
6. Is the platform team operating a CNCF agent-sandbox or agent-substrate deployment already? Stay there. The four managed runtimes are not replacing the CNCF primitives — they are the closed-source managed counterparts for teams that explicitly choose to outsource the control plane. The CNCF primitives are the answer when Kubernetes portability matters more than outsourcing lifecycle operations; the four managed runtimes are the answer when the platform team has a hard "no second control plane" mandate.

The decision is sequential, not point-based. The first question that matches wins. The right answer is the one that matches the operational capacity the platform team already has — the runtimes are not ordered by capability, they are ordered by who owns the control plane. For the broader OTel-side observability story that the four runtimes are the wire form of, the Agent Observability at 1,200+ Agents guide covers the per-tenant visibility window the multi-cloud fleet needs to keep open; for the incident-response side when a multi-cloud agent goes sideways, the Agentic Incident Harness guide walks through the 4-layer postmortem framework the multi-cloud fleet needs.

Where this stacks against the CNCF primitives

The four managed runtimes are the closed-source managed counterparts to the CNCF agent-sandbox and agent-substrate projects. The CNCF primitives are the canonical OSS-first, multi-cloud-portable answer; the four managed runtimes are the answer when the platform team has a hard requirement that the agent runtime not be a second control plane the team operates. The full comparison table is in the Agent Sandbox vs. Agent Substrate guide; the short version is that the CNCF primitives give you Kubernetes portability, the four managed runtimes give you "we don't operate the control plane," and the choice between them is the same choice the rest of the stack has been making for the last decade (Datadog vs OSS Grafana, Snowflake vs Postgres, etc.).

For the deeper evaluation criteria — the per-step span correlation pattern that makes the agent runtime observable at production scale, the distributed-feedback primitive that agent-substrate makes a first-class concept, and the runtime-vs-postmortem harness sandwich — the Agent Sandbox vs. Agent Substrate guide covers the CNCF side, and the four-runway matrix above covers the managed counterpart. The CNCF primitives and the managed runtimes are sibling options along the same axis; pick the one that matches the operational capacity the platform team already has, and pay the lock-in tax only when the alternative is worse.