Agent Sandboxes on AWS: AgentCore, Lambda MicroVMs, and EKS
Isolated, stateful, ephemeral compute for AI agents — one primitive, several paths. What agent sandboxes are, how agents use them, and how to choose. The first post in a series on secure agent sandboxes on AWS.
Series: Agent Sandboxes on AWS (5 articles)
- 1Agent Sandboxes on AWS: AgentCore, Lambda MicroVMs, and EKS This article
Contents
- Introduction
- What an Agent Sandbox Is
- How Agents Use Sandboxes: Six Use Cases, One Primitive
- What Makes It a Sandbox: Five Universals, Two Dials
- The Four-Layer Sandbox Stack
- The AWS Landscape: One Primitive, Several Paths
- Who Owns Which Layer: Shared Responsibility
- Choosing an Approach
- The Series: Deep Dives
Introduction
AI agents are moving from answering questions to doing work. They run for minutes or days, keep state across steps, use tools, reach into systems, and increasingly act with real autonomy. A coding agent lives in a development environment. An enterprise agent runs an event-driven workflow that touches your internal systems. A computer-use agent drives a full desktop. And many agents generate and run code as they go. Across all of these, the agent needs somewhere to run — and that "somewhere" now has real requirements.
And these patterns are beginning to shift where compute happens — increasingly from the accelerators behind training and inference toward the general-purpose CPUs where agents actually run their work.
Two things make that runtime environment a genuine design problem rather than an afterthought. First, an agent's behavior is not fully trustworthy. It plans and adapts in ways no one reviewed in advance, so it can be accidentally wrong — and it can be deliberately steered wrong. Agents routinely ingest untrusted content — web pages, documents, emails, tool outputs — and a prompt-injection payload hidden in any of it can hijack the agent into taking attacker-chosen actions. Malicious actors may submit code built to break out or reach other tenants. Second, whatever the agent does executes on your infrastructure, often with a path to your network, your credentials, and your data. There is risk in an agent that's confidently wrong just as much as in a malicious actor trying to exploit it.
The answer isn't to make the agent perfect; it's to give it a place to run that is contained by design — isolated so it can't reach beyond its boundary, stateful so it can actually do multi-step work, and disposable so nothing it touches outlives the task. That place is an agent sandbox, and as agents move from demos into production, it's becoming a first-class compute concern.
This post is the starting point for a series. Here we define the primitive, show the range of ways agents use it, lay out a mental model for the stack underneath, and map the AWS options so you can choose. The deep-dive posts (linked at the end) then build real sandboxes on each path.
A note on scope: this series is about sandboxes for agent development and runtime use cases. Sandboxes show up in adjacent data-science workflows too — most notably reinforcement learning, where environments run generated code to score rollouts at massive fan-out — and while they share the same isolated-ephemeral-stateful DNA, their scale and lifecycle patterns are different enough to be out of scope here.
What an Agent Sandbox Is
Everything in this series hangs off one definition:
An agent sandbox is an isolated, stateful, ephemeral compute environment with a stable identity — purpose-built for AI agent runtimes, development environments, and running untrusted or AI-generated code.
Walking the adjectives:
- Isolated — it has its own security boundary, so one sandbox can't observe or affect another.
- Stateful — it accumulates files, packages, and context as it works (though some patterns are deliberately stateless).
- Ephemeral — it's created, used, and torn down; never reused across a trust boundary.
- Stable identity — an addressable endpoint the orchestrator can reach for the life of the session, one that survives even a suspend and resume.
Notice what's not in the definition: Kubernetes, or any particular product. That's intentional. This definition spans every use case and every AWS option we'll discuss.
How Agents Use Sandboxes: Six Use Cases, One Primitive
The organizing idea is simple: one primitive, two patterns. Either the code runs inside the sandbox while the orchestrator stays outside — or the agent itself runs inside the sandbox.
Across those two patterns, six use cases show up again and again:
- Coding agents — an agent works inside a persistent dev environment, writing, running, and fixing code until the tests pass.
- Code execution — you send generated code to run in isolation and get the result back. This includes programmatic tool calling (PTC), where the model writes code that orchestrates its own tools.
- Agent-in-a-sandbox — an always-on agent running continuously behind a stable endpoint.
- Enterprise autonomous agents — event-driven workflows that run for hours to days and reach internal systems over your VPC.
- CI/CD and AI-ops agents — validating, testing, and building on every commit.
- Computer-use agents — driving a full graphical desktop from inside the sandbox.
A closer look at Programmatic Tool Calling (PTC)
PTC is worth a moment because the deep-dive posts build on it. In a traditional agent loop, the model and the orchestrator take turns: the model picks a tool, the orchestrator runs it, the result goes back to the model, and the cycle repeats — one LLM round-trip per tool call. PTC inverts this: the model generates a program that invokes tools as ordinary function calls, using native loops, conditionals, and error handling. The program runs in a sandbox, and each tool call is relayed back to the orchestrator. The model is invoked once; all the branching over tool calls happens at code-execution time.
This is exactly why a sandbox has to do more than "run a script": it needs bidirectional communication (send a tool request out, get a result back, mid-execution), it must be long-lived enough to finish the whole program, and the orchestrator must mediate every tool call — the sandbox itself holds no credentials and reaches nothing directly.
All six use cases need the same three things: isolation, a stable identity, and a bounded lifetime. Where they differ is on three dials — how stateful they are, how long a session runs, and their network posture. Those dials are what we'll use at the end to route a workload to the right path.
What Makes It a Sandbox: Five Universals, Two Dials
One distinction saves a lot of confusion: what's universal about sandboxes versus what depends on the pattern.
Five things are true of every sandbox:
- Isolated — its own security boundary.
- Ephemeral — created, used, destroyed, and never reused across a trust boundary.
- Single-use — one session, then terminate.
- Addressable — a stable identity the orchestrator can reach for the life of the session.
- Resource-bounded — CPU, memory, storage, and run time are all capped to contain untrusted code.
Two things vary by pattern:
- Statefulness — a long-running agent runtime accumulates files and context; short-lived executions like tool calling are often completely stateless.
- Network posture — default-deny egress for untrusted code, but routable when the agent itself is serving traffic.
The takeaway: don't over-index on the one pattern you saw last. The five universals are the contract; the two variables are where the design decisions live.
The Four-Layer Sandbox Stack
Here's the mental model for the rest of the series — four layers, bottom to top, sitting on AWS's physical infrastructure (the Nitro System, regions, networking, and hardware):
- Compute — the raw substrate: EC2, EKS node groups, ECS workers, autoscaling.
- Isolation & Scheduling — where the strong-isolation guarantee lives. The isolation runtime (Firecracker, gVisor, Kata, and more), plus networking and egress control, storage and memory boundaries, and scheduling onto the right runtime. This is the most important layer for the sandbox story.
- Lifecycle Management — warm pools, atomic checkout and release, time-to-live leases, suspend and resume, fork and snapshot, and the rule of terminate-never-reuse.
- Workload — your code, your framework, your runtimes. This layer is always yours, no matter which option you choose.
The idea to plant here: you choose how much of this stack AWS runs for you. The boundary between what AWS manages and what you manage slides up and down these layers depending on your needs — which is exactly the shared-responsibility conversation below.
The AWS Landscape: One Primitive, Several Paths
So what can you actually run on AWS? These are complementary entry points to the same problem — running agents and untrusted or AI-generated code with strong isolation. They aren't competing products; you choose based on how much infrastructure you want to own.
- Amazon Bedrock AgentCore (Runtime + Code Interpreter) — the fully managed, API-and-SDK end. Your agent's sessions and code execution run in AWS-managed microVMs; you bring only your code.
- AWS Lambda MicroVMs — generally available today. A developer API: call launch, and you get a dedicated HTTPS endpoint almost instantly, with suspend, resume, and clone, and zero infrastructure to manage.
- Self-managed on Amazon EKS — run per-session sandbox pods on your own cluster with your choice of isolation runtime (Fargate task isolation, gVisor, or Kata Containers), and manage the lifecycle yourself or with the open-source
kubernetes-sigs/agent-sandboxproject.
A quick way to think about it: if you want a pure API with no infrastructure, that points to AgentCore or Lambda MicroVMs. If you're standardizing on Kubernetes and want to own the footprint, that points to self-managed EKS.
Who Owns Which Layer: Shared Responsibility
Lay those options onto the four-layer stack and you can see exactly where each draws the line. One row is constant: the workload is always yours. Isolation, compute, and lifecycle shift by option.
- AgentCore and Lambda MicroVMs — the fully managed end: AWS owns compute, isolation, and lifecycle; you bring only your code.
- EKS — isolation depends on the runtime. With Fargate, AWS manages the isolation for you. With gVisor or Kata, you build and maintain the node AMI with the runtime installed, so isolation is customer-managed. Compute follows the same line — AWS-managed in Auto Mode, customer-managed when you run custom AMIs (gVisor/Kata, or a third-party CNI like Cilium or Calico) — and the lifecycle is customer-managed today, via the open-source agent-sandbox project.
- EC2 — the build-it-yourself end: AWS provides the compute substrate and you own everything above it — your own isolation runtime, lifecycle controller, and workload. This is the path for teams building their own sandbox platform or frontier-model training infrastructure.
The pattern: the more managed the option, the higher the boundary climbs the stack — but the workload is always yours, and everything below it is where you decide how much AWS runs for you.
Choosing an Approach
There's no single right answer — it's one primitive with several paths. The fastest way to narrow them is to ask three questions in order: how much of the stack do you want to own, what does the workload actually need, and — if you land on Kubernetes — which isolation runtime fits.
Start with your operating model
The biggest fork is how much infrastructure you want to run yourself. In practice, teams cluster into three profiles, and each lands on a different part of the shared-responsibility spectrum from the last section:
- "Just give me an API." Application teams that don't want to think about infrastructure at all — create a sandbox, get an endpoint, run code, release. What they care about is developer experience (SDK quality, cold start, session management) and enterprise controls (egress filtering, audit logging). This points to the managed end: Bedrock AgentCore for a fully managed agent toolset, or Lambda MicroVMs for a developer API with no clusters to run.
- "We already run Kubernetes." Platform teams with deep EKS expertise who want the footprint in their own account and control over pool sizes, TTLs, templates, and workload images. This points to sandboxes on EKS.
- "We want everything above the metal." Teams building their own sandbox platform or frontier-model training infrastructure, who run their own isolation runtime and lifecycle controller. This points to lower-level EC2 building blocks — bare-metal instances and nested virtualization — with AWS providing the physical substrate and getting out of the way.
The rule of thumb: the more you want AWS to manage, the higher up the stack the boundary climbs — and the fewer moving parts you own.
Then match the workload's two dials
Within a path, the two variables from earlier decide the shape:
- Statefulness & session length. Short, stateless executions — tool calling, PTC, per-job CI runs — fit a pure serverless primitive well and often need no persistence at all. Long-lived, stateful runtimes — coding agents, autonomous workflows that run for hours to days — want first-class suspend/resume and session state that survives idle.
- Network posture. Default-deny egress for untrusted code; routable (public or VPC) when the sandbox is itself serving traffic or needs to reach private systems over your VPC.
A quick route by use case:
On EKS, pick the isolation runtime
If you land on EKS, one choice remains — the isolation runtime — and it trades startup speed against isolation strength and operational overhead. The startup figures below come from our own testing on EKS, detailed in the secure-sandboxes deep dive :
- Fargate — AWS-managed, serverless task-level isolation with no nodes to run; cold start was on the order of 30–45 seconds in our testing, so pair it with a warm pool.
- gVisor — a user-space kernel with the fastest startup (~3 seconds) and strong isolation, at a reported 5–15% overhead on syscall-heavy code; you own the node AMI.
- Kata Containers — a microVM per pod with VM-grade isolation and full syscall compatibility (~5-second start in our testing); you own the node AMI. This is the one for computer-use agents and anything that needs a real kernel.
Whichever you choose, a warm pool turned a ~45-second cold start into a sub-second checkout in our proof-of-concept — which is why lifecycle, not just isolation, is what makes a sandbox production-ready.
The bottom line matches the shared-responsibility picture: one primitive, several paths, and the right one comes down to how much of the stack you want AWS to run for you. The deep-dive posts take a concrete workload down each path.
The Series: Deep Dives
Each post below builds a real sandbox on one of these paths, reusing the concepts defined here:
- Implementing Programmatic Tool Calling on EKS with Fargate, gVisor, and Kata — three isolation runtimes on EKS, with a reference implementation of the PTC pattern (the code executor, the transport, the container, and the network architecture).
- Optimizing Sandbox Checkout Latency with Warm Pools on EKS Fargate — combining Fargate's serverless isolation with the
kubernetes-sigs/agent-sandboxoperator for fast, operationally simple checkout. - Implementing Programmatic Tool Calling on Serverless Lambda MicroVMs — Firecracker isolation as a developer API, with built-in lifecycle management and JSON-RPC over WebSockets for inline tool calling.
Series: Agent Sandboxes on AWS (5 articles)
- 1Agent Sandboxes on AWS: AgentCore, Lambda MicroVMs, and EKS This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article