{"slug": "introducing-lambda-microvms-isolated-stateful-sandboxes-for-running-untrusted-on", "title": "Introducing Lambda MicroVMs - Isolated, Stateful Sandboxes for Running Untrusted Code on AWS", "summary": "AWS launched Lambda MicroVMs on June 22, 2026, a new compute primitive that provides dedicated Firecracker virtual machines per user or session for running untrusted code with strong isolation, fast startup, and persistent state. Unlike Lambda functions, MicroVMs are stateful, support HTTP/2, gRPC, or WebSockets, and require developers to manage the fleet lifecycle themselves. The service addresses the need for sandboxed environments in coding assistants, AI agent platforms, and multi-tenant notebooks.", "body_md": "👋 Hey there, Tech Enthusiasts!\n\nI'm Sarvar, a Cloud Architect who loves turning complex tech problems into simple solutions. I've worked with AWS, Azure, DevOps, Data, Analytics, Generative-AI and Agentic-AI building real systems for real companies. In this article series, I'll share what I've learned in a way that's easy to follow, whether you're experienced or just getting started.\n\nLet's get into it! 🚀\n\nOn June 22, 2026, AWS launched Lambda MicroVMs. It is a new compute primitive inside Lambda that gives you a dedicated Firecracker virtual machine per user or session. It is not an update to Lambda functions. It is a different thing with a different model, different pricing, and different use cases.\n\nIf you are building anything where users or AI agents execute arbitrary code and you need strong isolation, fast startup, and persistent state this is what you reach for now.\n\nBefore this launch, if you needed to sandbox untrusted code on AWS, you had three options. Each one forced a compromise.\n\n**EC2 instances** give you full VM isolation and persistent state. But they are not fast enough for interactive use. Between AMI boot, instance initialization, and user data scripts, you are looking at 30 seconds to several minutes before a user can do anything. That kills the experience for coding assistants or on-demand sandboxes.\n\n**Containers (ECS/Fargate)** start faster and keep state while running. But containers share a kernel with the host. That shared kernel is a security boundary you cannot fully trust when running code from strangers on the internet. You can layer security on top, but the fundamental model is weaker.\n\n**Lambda functions** give you real VM-level isolation (they already run on Firecracker) and start in milliseconds. But they die after 15 minutes. They are stateless between invocations. They follow a request/response model. You cannot give a user a persistent environment where they write code, run it, see the output, install a package, and run again all within the same session.\n\nTeams building coding assistants, AI agent sandboxes, or multi-tenant notebook platforms had to stitch together custom solutions. EC2 with a lifecycle manager. ECS with heavy security configuration. Running Firecracker directly on bare metal. All of it was operational overhead solving a problem that should have had a managed answer.\n\nLambda MicroVMs is that managed answer.\n\nYou package your application code and a Dockerfile into a zip archive, upload it to S3, and call the Lambda API to create a MicroVM image. Lambda executes your Dockerfile, starts your application, and captures a snapshot of the fully initialized environment.\n\nWhen you need a sandbox for a user, you call `run-microvm`\n\n. Lambda launches a MicroVM from that snapshot with rapid startup.\n\nEach MicroVM gets:\n\nUsers connect over HTTP/2, gRPC, or WebSockets. Authentication is handled through bearer tokens you generate via the `CreateMicrovmAuthToken`\n\nAPI.\n\nThis is important: Lambda MicroVMs is not request/response.\n\nWith Lambda functions, a request comes in, your code runs, it returns a response, the invocation ends. Scaling is automatic. You think in terms of individual invocations.\n\nWith Lambda MicroVMs, you spin up a persistent VM for a user or session. It stays alive. It has a dedicated URL. Multiple requests hit the same VM. State accumulates. The user installs a package, it is still there on the next request.\n\nYou manage the fleet yourself. You decide when to create a MicroVM, which user it belongs to, and when to tear it down. There is no automatic horizontal scaling. Your application owns that logic.\n\nThis is closer to managing a pool of servers than it is to writing Lambda functions. The difference is you do not manage the infrastructure underneath no AMIs, no instance types, no patching, no capacity planning for the host.\n\nHere is the basic workflow using the AWS CLI. *Command names below follow the API naming convention. Check the CLI reference for your SDK version.*\n\n```\n# Step 1: Upload your application package (Dockerfile + code) to S3\naws s3 cp my-sandbox-app.zip s3://my-bucket/my-sandbox-app.zip\n\n# Step 2: Create a MicroVM image from your package\naws lambda create-microvm-image \\\n  --image-name my-sandbox \\\n  --s3-bucket my-bucket \\\n  --s3-key my-sandbox-app.zip\n\n# Step 3: Launch a MicroVM for a user session\naws lambda run-microvm \\\n  --image-name my-sandbox \\\n  --memory-size 2048\n\n# Step 4: Generate an auth token for the user to connect\naws lambda create-microvm-auth-token \\\n  --microvm-id mvm-abc123\n\n# Step 5: When session ends, terminate\naws lambda terminate-microvm \\\n  --microvm-id mvm-abc123\n```\n\nThe user connects to the dedicated HTTPS endpoint returned by `run-microvm`\n\nusing their auth token. From there, they interact over HTTP/2, gRPC, or WebSockets depending on what your application exposes.\n\nFor shell access (giving users a terminal inside the VM):\n\n```\naws lambda create-microvm-shell-auth-token \\\n  --microvm-id mvm-abc123\n```\n\nThis returns credentials that connect directly to a pseudo-terminal inside the MicroVM. AI coding tools use this to provide real terminal experiences to end users.\n\n**Startup:** MicroVMs launch from pre-initialized snapshots, similar to how Lambda SnapStart works. This skips application initialization entirely your environment is already warm when it starts.\n\n**Duration:** Up to 8 hours per session. After that, the MicroVM is terminated.\n\n**Suspend/Resume:** When no traffic hits a MicroVM, it suspends automatically based on an idle timeout you configure (how long it waits with no inbound traffic before suspending). You stop paying for compute. When a request arrives, it resumes with memory and disk state fully intact. You can also trigger suspend and resume programmatically via `suspend-microvm`\n\nand `resume-microvm`\n\nAPIs. Resume latency is not a full cold start it restores from a memory snapshot, which is significantly faster than booting from scratch. AWS has not published exact resume latency numbers at launch, so expect to benchmark this for your specific workload.\n\n**Vertical scaling:** You configure a baseline (default is 2 GB memory / 1 vCPU, allocated in a 2:1 memory-to-CPU ratio). During peak activity, the MicroVM can burst to 4x that baseline automatically. For example, a 2 GB / 1 vCPU baseline can burst to 8 GB / 4 vCPU. An 8 GB / 4 vCPU baseline can burst to 32 GB / 16 vCPU. You only pay for the burst resources during the time they are actually consumed.\n\n**Shell access:** Full pseudo-terminal (`/dev/ptmx`\n\n) support. The `CreateMicrovmShellAuthToken`\n\nAPI lets you give users a real terminal inside their VM. This is how AI coding tools provide interactive terminal experiences.\n\n**Docker inside:** You can run containers inside your MicroVM. Full OS capabilities are available installing system packages, mounting filesystems, running nested containers. One gotcha: outbound UDP is blocked by default, which breaks DNS resolution inside nested containers. Community workarounds exist for this.\n\n**Architecture:** ARM64 (Graviton) only at launch.\n\n**Regions:** US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Ireland), Asia Pacific (Tokyo).\n\nLambda MicroVMs pricing has three components: compute, snapshots, and data transfer.\n\n**Compute** (US East, ARM/Graviton):\n\n**Snapshots:**\n\n**Concrete example - coding assistant platform:**\n\n100 developers, each using a 2 GB / 1 vCPU MicroVM for 2.5 hours per day over 20 working days. Each environment suspends 6 times per day during idle periods. Monthly cost: approximately $1,241 total, or about $12.41 per developer per month.\n\n**Concrete example - CI/CD job runner:**\n\n10,000 jobs per month, each running for 10 minutes in an 8 GB / 4 vCPU environment. No suspend/resume (jobs run to completion). Monthly cost: approximately $1,124 total, or about $0.11 per job.\n\nThis pricing is closer to Fargate economics than Lambda function economics. You are paying for dedicated compute time, not per-invocation.\n\nUse Lambda MicroVMs when:\n\nDo not use Lambda MicroVMs when:\n\nBoth services run on Firecracker. Both support 8-hour sessions. Both have shell access. But they solve different problems.\n\n**AgentCore Runtime** is a managed agent platform. You deploy your agent code, AWS handles session routing, scaling, teardown, agent communication protocols, and authentication. You do not think about VMs. Your users talk to your agent through a managed endpoint.\n\n**Lambda MicroVMs** is a raw compute primitive. You get the VM. You manage which user gets which VM. You handle lifecycle, cleanup, and routing. You have full control of what runs inside.\n\nThe analogy: AgentCore Runtime is to Lambda MicroVMs what Fargate is to EC2. Same isolation technology underneath, different level of abstraction on top.\n\nIf you are building an AI agent and want managed hosting AgentCore. If you are building a platform where each user gets their own isolated environment to run whatever they want Lambda MicroVMs.\n\nYou can provision Lambda MicroVMs through the AWS Console, CloudFormation, CDK, or the [Agent Toolkit for AWS](https://github.com/aws/agent-toolkit-for-aws/tree/main/skills/specialized-skills/serverless-skills/aws-lambda-microvms).\n\nThe developer guide is here: [Lambda MicroVMs Guide](https://docs.aws.amazon.com/lambda/latest/dg/lambda-microvms-guide.html)\n\nAPI reference: [MicroVM API](https://docs.aws.amazon.com/lambda/latest/microvm-api/API_Operations.html)\n\nLambda MicroVMs fills a gap that has existed since serverless became mainstream. The question \"how do I safely run someone else's code?\" finally has a straightforward answer on AWS that does not involve stitching together three services and writing a custom orchestrator.\n\nIt is not magic. You still have to manage your fleet of MicroVMs, handle routing, and build the lifecycle logic. But the hard part fast, isolated, stateful VMs without managing infrastructure is handled for you.\n\nFor teams building AI-powered developer tools, this is probably the most relevant compute launch of 2026 so far.\n\nThanks for reading! If this was helpful:\n\n**Follow me for more on:** AWS architecture, FinOps, DevOps, and AI Infrastructure.\n\n👉 ** Visit my website** |\n\n**Happy Learning** 🚀", "url": "https://wpnews.pro/news/introducing-lambda-microvms-isolated-stateful-sandboxes-for-running-untrusted-on", "canonical_source": "https://dev.to/aws-builders/introducing-lambda-microvms-isolated-stateful-sandboxes-for-running-untrusted-code-on-aws-5chf", "published_at": "2026-06-30 13:42:54+00:00", "updated_at": "2026-06-30 13:48:54.698062+00:00", "lang": "en", "topics": ["developer-tools", "ai-agents", "ai-infrastructure"], "entities": ["AWS", "Lambda MicroVMs", "Firecracker", "EC2", "ECS", "Fargate", "S3", "Sarvar"], "alternates": {"html": "https://wpnews.pro/news/introducing-lambda-microvms-isolated-stateful-sandboxes-for-running-untrusted-on", "markdown": "https://wpnews.pro/news/introducing-lambda-microvms-isolated-stateful-sandboxes-for-running-untrusted-on.md", "text": "https://wpnews.pro/news/introducing-lambda-microvms-isolated-stateful-sandboxes-for-running-untrusted-on.txt", "jsonld": "https://wpnews.pro/news/introducing-lambda-microvms-isolated-stateful-sandboxes-for-running-untrusted-on.jsonld"}}