Table of contents
AWS Lambda MicroVMs: An Honest Guide to Pricing and Tradeoffs
If you’re building a product where users or AI agents run arbitrary code, you’ve probably hit the same wall every team eventually hits: isolating that code safely is expensive to build and easy to get wrong. AWS Lambda MicroVMs, which became generally available on June 22, 2026, are AWS’s answer. It gives you a dedicated, stateful execution environment you can launch, suspend, resume, and terminate on demand, without owning the underlying virtualization layer yourself.
What Are Lambda MicroVMs?
AWS Lambda MicroVMs is a serverless compute primitive built on Firecracker, the same virtualization technology that already runs every standard Lambda function. A MicroVM is a dedicated execution environment with a unique HTTPS endpoint that you explicitly launch, suspend, resume, and terminate, rather than a function that fires once and disappears. Each MicroVM can hold memory and disk state across a session and exposes lifecycle hooks (/run, /suspend, /resume, /terminate) that your application uses to manage that state cleanly (AWS Compute Blog).
How Lambda MicroVMs Differ From Regular Lambda
Here’s a distinction worth getting right, because it’s easy to state wrong. Regular Lambda functions already run inside Firecracker microVMs. That has been true since 2018. So the difference between a standard Lambda function and a Lambda MicroVM isn’t “container isolation versus VM isolation.” It’s execution model and lifecycle.
A standard Lambda function is invocation-oriented: it starts, does one unit of work, and the environment is recycled or frozen behind the scenes, mostly outside your control. A Lambda MicroVM is a resource you explicitly own for a stretch of time. You decide when it launches, when it suspends, when it resumes, and when it’s gone. That’s a fundamentally different mental model, closer to a disposable server you provision on demand than to a function you invoke.
Why AI Agents Need Isolated Execution
Five years ago, “run untrusted code safely” was a niche problem mostly owned by browser-based IDEs and a handful of security vendors. Today it’s becoming a common architecture question for teams building AI coding agents, notebook products, CI platforms, and other products where AI or users generate and execute code on your infrastructure. A coding agent might need to install a library mid-session or keep a process warm for twenty minutes, in ways a stateless invocation never could. Companies like Northflank, E2B, and Modal built businesses around exactly that gap. AWS is now competing for it directly, using virtualization it already owned.
What MicroVMs Actually Solve
What problem do AWS Lambda MicroVMs solve for AI teams?
It removes the need to build your own snapshot-based lifecycle management for isolated, stateful execution. Before this, teams either accepted slow cold starts to get strong isolation, or gave up persistent state to get fast, disposable sandboxes. MicroVMs combine hardware-level VM isolation, snapshot-based launch and resume, and state retention across a session, so an AI agent or an untrusted user can run real code without one tenant’s crash touching another’s session, and without your team owning the orchestration layer that makes that possible.
That’s a genuine engineering win for teams building coding assistants, notebooks, or multi-tenant sandboxes, and it’s worth taking seriously instead of defaulting to “we’ll build our own container orchestration.”
What They Don't Solve
MicroVMs remove infrastructure work. They don’t remove architecture, security, or cost-accounting work, and three constraints are worth knowing before you commit.
Session continuity is the first. A MicroVM can run for up to 28,800 seconds (8 hours) across its running and suspended states combined, and that limit isn’t adjustable (AWS Lambda quotas). If your workload can exceed that, your application has to manage continuity across MicroVM lifecycles itself, using the runHookPayload to carry session or tenant context into a new MicroVM. AWS doesn’t stitch that continuity together for you. The same boundary also means a single long user interaction can span multiple MicroVM lifecycles: AWS gives you infrastructure usage and billing data, but mapping that cleanly to your own customers or tenants is an application-level accounting problem you build yourself, from day one, not after your first confusing invoice.
Security is the second. Strong VM isolation is a real boundary, but it’s one layer. AWS’s own guidance for AI agent workloads still points to least-privilege IAM, scoping network access to only what the workload needs, and routing tool access through policy enforcement rather than trusting the model’s own judgment (AWS Compute Blog). Isolation limits blast radius. It doesn’t replace permissions, secrets management, or the rest of your security architecture.
Architecture is the third. MicroVMs currently run on ARM64 (Graviton) only, so anything in your stack that assumes x86 needs a migration plan before you commit. AWS also applies account-level memory quotas and API rate limits for launching, resuming, suspending, and terminating MicroVMs. Those quotas are adjustable in many cases, but teams planning high-concurrency workloads should model them before assuming burst capacity will scale indefinitely.
The Pricing Model
This is the part most coverage glosses over, so it’s worth being precise. MicroVM pricing has three components: compute, snapshot operations and storage, and data transfer.
While running, you pay for baseline compute continuously, billed per second. Your MicroVM can also vertically scale up to 4x its configured baseline during peak activity, with the additional memory and vCPU billed only for the active duration they’re consumed.
While suspended, compute charges stop entirely. You still pay for snapshot storage and for the snapshot read and write operations involved in suspending and resuming, at per-GB rates that are small individually but compound across thousands of sessions. As of August 2026, AWS lists MicroVM snapshot and image storage at $0.08 per GB-month (AWS Lambda pricing). AWS pricing changes, so use the current pricing page for production estimates rather than the number above.
Once terminated, charges stop completely. No ongoing compute or storage cost.
That’s directionally simple, but it means “how much does this cost” depends on your session shape: how long sessions run, how often they suspend and resume, and how large the memory and disk footprint is at each snapshot.
Why "More Expensive" Is the Wrong Frame
The instinct to say dedicated infrastructure is more expensive than shared infrastructure is reasonable, but too broad here. Whether MicroVMs cost more or less than a self-managed alternative depends on session duration, baseline memory, concurrency, and how aggressively you suspend idle sessions, not on some inherent tax for using AWS’s managed primitive. What’s true, and worth planning for, is that MicroVMs make cost directly attributable to each isolated environment instead of blending it into a shared server’s utilization curve. That’s useful for accountability, but only if you actually track it.
Lambda MicroVMs vs EC2 vs Specialist Sandbox Vendors
Building on raw EC2 or Firecracker directly gives you full control, but you own the entire lifecycle layer: snapshotting, suspend and resume logic, scaling. Lambda MicroVMs gives you that layer as a managed primitive and shifts the work to session continuity, cost attribution, and security. Specialist vendors such as E2B, Modal, and Northflank can abstract more of the sandbox orchestration and runtime management, depending on the product and plan, at a premium worth pricing against your own build time.
Build, Rent, or Buy: A Decision Framework
The right path depends on where your actual constraint sits. Building and owning more of the stack still makes sense if isolated code execution is your core product differentiator and you have the team to carry it long term. For most teams already deep in the AWS ecosystem, with sessions that fit a standard shape, Lambda MicroVMs is the practical default, and it also works well when you need isolated execution running fast without unusual runtime requirements. A specialist vendor earns its premium when you need workflow-specific tooling for billing or orchestration already built in, or when you’re running heavy custom orchestration across many concurrent sessions, since that’s exactly the layer you’d otherwise be building yourself. Self-managed infrastructure is still the honest answer if you need an unusual runtime, x86 support, or full control over the stack. One thing cuts across all three paths: if your sessions regularly exceed 8 hours, that’s a signal to rethink the session architecture itself before you pick a provider, not after.
Before picking a path, get honest answers to three questions. How long do your real sessions run, not your demo sessions? Who is generating the code that needs isolating, your users, your AI agent, or both? And who on your team owns cost attribution once this is live, because someone has to. If you can’t answer the third one yet, that’s the signal you’re not ready to commit to any of these paths, and it’s the kind of question worth working through with an engineering partner who has made this call before rather than alone against a pricing page.
Frequently Asked Questions
What is AWS Lambda MicroVMs used for?
It’s used to run long-lived, stateful, isolated compute sessions, most commonly for AI coding agents, browser-based IDEs, data notebooks, CI/CD build environments, and any product where users or AI systems execute arbitrary code that needs strong isolation between tenants.
How are AWS Lambda MicroVMs different from a regular Lambda function?
Both run on Firecracker virtualization. The difference is execution model: a regular Lambda function is invocation-oriented and short-lived, while a MicroVM is a dedicated environment you explicitly launch, suspend, resume, and terminate, holding state across a session for up to 8 hours.
Do AWS Lambda MicroVMs cost more than building my own sandbox environment?
It depends on your session volume, duration, and how aggressively you suspend idle sessions, not on a fixed premium for using a managed service. Renting removes the upfront engineering cost of building isolation infrastructure, but you’re responsible for the application-level work of mapping AWS’s usage and billing data to your own customers or tenants, since AWS doesn’t do that for you.
Is AWS Lambda MicroVMs safe for running AI-generated code?
It provides a strong isolation boundary, which is a meaningful layer for code you don’t fully trust. But isolation alone isn’t a complete security architecture. AWS’s own guidance still recommends least-privilege IAM, scoped network access, and policy-enforced tool access on top of the sandbox itself.
Should a startup use AWS Lambda MicroVMs or a dedicated sandbox vendor?
If you’re already on AWS, your sessions fit within the 8-hour limit, and you’re willing to build your own cost-attribution and session-continuity logic, MicroVMs are a solid default. If a specialist vendor’s product already abstracts more of that orchestration and the premium is worth the convenience, it can get you to market faster.
The Takeaway
AWS didn’t eliminate the sandboxing problem. It turned a large infrastructure problem into a smaller application architecture problem. That’s a genuinely good trade for most teams. But it means the real question isn’t whether Lambda MicroVMs is good technology. It’s whether your product should own execution infrastructure as part of its architecture at all, and if so, whether you’re prepared to own session continuity, security, and cost attribution once the infrastructure part gets easier.
Lambda MicroVMs is also now available in ten AWS regions, including Mumbai, Singapore, Sydney, Frankfurt, and Stockholm, as of an expansion on August 19, 2026 (AWS), which matters if you’re serving Indian users or have data-residency constraints that ruled out the initial five-region launch.
If you’re weighing this decision for an AI product you’re building right now, PedalsUp is happy to think through the actual tradeoffs with you, not just the AWS pricing page.
