All four major clouds now offer a managed place to run code generated by an agent. They agree on the product shape and disagree on almost everything underneath it.
AWS gives each session a Firecracker-backed Lambda MicroVM. Google offers gVisor-backed GKE Agent Sandbox and a lighter Cloud Run sandbox. Azure Container Apps Dynamic Sessions uses Hyper-V isolation. Cloudflare controls VM-isolated containers through Workers and Durable Objects.
The selection question is not which logo your company already buys. It is where the security boundary sits, how long state must survive, which resource limit fails first, and who governs credentials after the code is contained.
The four-cloud comparison
| Cloud | Product shape | Isolation boundary | Lifecycle | Operational constraint |
|---|---|---|---|---|
| AWS | Lambda MicroVM session | Firecracker microVM | Up to eight hours with suspend/resume | Graviton and regional availability constrain portability |
| Google Cloud | GKE Agent Sandbox or Cloud Run sandbox | gVisor on GKE; sandbox process inside a Cloud Run instance | Pod/session on GKE; process lifetime on Cloud Run | Cloud Run sandbox shares parent CPU and memory |
| Microsoft Azure | Container Apps Dynamic Sessions | Hyper-V boundary | Ephemeral session pool | Pool sizing and session readiness become capacity controls |
| Cloudflare | Sandboxes controlled by Workers and Durable Objects | VM-isolated container | Durable Object coordinates sandbox state | Runtime is coupled to Workers control-plane patterns |
The New Stack reported that Google started and stopped 1,000 Cloud Run sandboxes at an average of 500 milliseconds each, and that Microsoft Copilot consumes more than 400,000 Dynamic Sessions per day. Those figures describe different workloads and should not be treated as a head-to-head benchmark.
Pick the isolation boundary first
Firecracker and Hyper-V put a virtual-machine boundary around a session. gVisor intercepts system calls between the workload and the host kernel. Cloud Run's sandbox is launched inside the resources already assigned to the service instance. Cloudflare exposes a container-like runtime but isolates each sandbox in a VM.
None of these boundaries decides what credentials generated code receives. A perfectly isolated process can still delete production data if it is handed a privileged token and unrestricted network access. Containment limits blast radius on the host. Identity, egress policy, tool authorization, and audit logging govern what the code can do.
For code that handles untrusted packages or arbitrary shell commands, start with a per-session VM boundary. For narrowly scoped transformations inside an existing service, a lower-overhead sandbox can be reasonable if CPU contention and network policy are explicit.
Choose lifecycle based on state
Long-running coding agents need a workspace that survives several tool calls, package installs, and pauses for human review. AWS's suspend/resume model fits that shape, subject to its eight-hour cap. Azure session pools also fit repeated work when the pool is warm and session cleanup is enforced.
Cloud Run's approach fits short code execution attached to an existing request path. It avoids a separate sandbox bill, but the code competes with the parent service for CPU and memory. A runaway job can degrade the API that launched it.
Cloudflare's Workers and Durable Objects pairing is useful when global request routing and state coordination already live at the edge. It is less attractive when the agent requires a conventional VM filesystem, large local dependencies, or a cloud-neutral control plane.
If state must persist for days, a managed execution sandbox is not the whole runtime. Put durable state in a governed store and make the sandbox disposable. The CNCF agent sandbox versus substrate guide covers that higher-level choice between long-running stateful agents and bursty invocations.
Resource limits are product behavior
A sandbox limit is not a footnote. It defines which agents the platform can run.
Track maximum session duration, CPU architecture, memory, disk, process count, network egress, package-install support, concurrent session quota, startup latency, and cleanup guarantees. Test the failure response for each limit. An agent should receive a typed timeout or quota error, not a partial file and a successful status.
The provider comparison should also include noisy-neighbor behavior. Cloud Run sandboxes borrow parent resources. Session pools reserve capacity ahead of demand. MicroVMs add stronger boundaries but carry startup and memory overhead. Edge-controlled sandboxes reduce control-plane latency but may constrain runtimes and storage.
Governance is separate from containment
Use a dedicated workload identity per session. Issue short-lived credentials after the sandbox is created, scope them to the exact tool or data set, and revoke them when the session ends. Do not bake cloud keys into the image or pass them in generated code.
Deny network egress by default. Allow named destinations through a gateway that records the session ID, agent identity, destination, and policy decision. If an agent needs database access, prefer a narrow API or MCP tool over raw database credentials.
Keep the control plane outside the sandbox. The workload should not be able to change its own time limit, network policy, identity, or audit settings. Treat its stdout, generated files, and tool payloads as untrusted data.
A cloud-neutral observability contract
Emit one trace per sandbox execution and keep provider details in resource attributes:
agent.sandbox.provider = aws | gcp | azure | cloudflare
agent.sandbox.runtime = lambda-microvm | gke-gvisor | cloud-run | dynamic-session | workers-sandbox
agent.sandbox.session.id = opaque-id
agent.sandbox.cold_start_ms = 487
agent.sandbox.cpu_arch = arm64 | amd64
agent.sandbox.termination_reason = completed | timeout | quota | policy | crash
Add child spans for package install, code execution, network calls, and tool use. Record resource peaks and the policy decision that allowed each credential or destination. Do not put source code, secrets, or raw tool results in span attributes.
This contract makes migrations measurable. Run the same synthetic workload on two clouds and compare cold-start distribution, task completion, timeout rate, peak memory, network policy denials, and cost per successful session. Average startup time alone is not enough.
Migration playbook
Package the agent workspace and runner separately. The runner handles lifecycle signals, telemetry, and artifact upload; the workspace contains the task files. Keep durable state in object storage or a database rather than a provider-specific local disk snapshot.
Define a provider adapter with create, execute, suspend, resume, terminate, and collect-artifacts operations. Not every provider supports every operation. Return an explicit unsupported result instead of pretending suspend is terminate-and-recreate.
Rehearse credential rotation, timeout, network denial, artifact upload failure, and cleanup after a control-plane crash. The expensive migration bug is usually not starting the sandbox. It is proving that no credentials, disks, or sessions remain after failure.
Decision tree
Use AWS when a dedicated microVM, resumable session, and AWS identity integration matter more than x86 portability or sessions longer than eight hours.
Use GKE Agent Sandbox when the agent already runs on Kubernetes and gVisor plus cluster policy is the desired boundary. Use Cloud Run sandbox for short tasks that should reuse an existing service allocation and can tolerate shared resource pressure.
Use Azure Dynamic Sessions when the organization already governs identities through Entra and can operate a warm pool around predictable session demand.
Use Cloudflare when Workers and Durable Objects already form the agent control plane and global placement matters more than a conventional VM environment.
Use a cloud-neutral CNCF runtime when provider portability and Kubernetes control are the priority, accepting that your platform team owns more of the lifecycle.
The provider is only one layer. The agentic incident harness shows how to preserve evidence when a session fails, and MCP monitoring covers the tool boundary that often carries the sandbox's external access.
Source: AWS, Google Cloud, Microsoft Azure, and Cloudflare now all offer agent sandboxes, The New Stack, July 24, 2026.
Solo.io's Agentgateway is the LLM gateway that sits in front of agent sandboxes across clouds — per-agent cost attribution, model fallback, and the audit log every session needs. CNCF Sandbox project.