Overcoming stateless Lambda limits: Lambda MicroVMs as a third alternative

"We started out wanting to build something light and inexpensive with serverless, but partway through, stateful workloads emerged and stalled our progress. In the end, we had to offload just that part to containers, which split our operations into two separate tracks." When taking consultations for system development, confessions like this come up astonishingly often. The initial architectural decision was sound: building with Lambda avoids server maintenance, scales automatically with traffic spikes, and charges only for what you use. Yet as development deepens, workloads emerge that must retain state across user sessions or run heavier tasks that cannot finish in ten-odd minutes. The moment requirements step outside Lambda's core assumptions, the architecture quietly begins to unravel.

The workarounds adopted across engineering teams are well-known: either force a single workload into fragmented steps while offloading state to an external database, or spin out that specific piece into ECS or Fargate containers. Both approaches function. However, the former twists the logic solely to satisfy execution boundaries, making it unreadable, while the latter creates dual operations across serverless and container footprints—doubling monitoring, permissions, and deployment pipelines. What was supposed to be built cheaply ends up carrying the heaviest technical debt. Lambda MicroVMs, announced by AWS on June 22, 2026, offer a new alternative specifically targeted at this dilemma. Yet they are no silver bullet. This article dispassionately examines what they solve and what they leave unaddressed.

Why conventional Lambda hits a wall with state and long runtimes

First, let us examine why Lambda runs into barriers on these two fronts. This is not a design flaw, but rather the core design philosophy itself.

Lambda was designed around the premise that each invocation is ephemeral. A function spins up, processes the request, and is torn down along with its environment upon completion. That is precisely why it is fast, cost-effective, and automatically scalable. In exchange, it fundamentally cannot retain state across invocations. It is inherently unsuited for interactive sessions where users continue ongoing operations or workloads that hold intermediate computation states. Furthermore, execution time has hard limits, meaning long-running processes cannot fit without modification. Regarding isolation granularity, because the underlying execution environment is reused across calls, it can prove too coarse for scenarios requiring safe execution of untrusted, user-supplied code.

To work around these characteristics, teams offload state to DynamoDB or Aurora and stitch tasks together with fine-grained Step Functions workflows. While standard practice, scattering what was once continuous logic across external datastores and state machines makes codebases far harder to trace. The concept of modernizing datastores to handle externalized state is touched upon in Database Modernization with Aurora Serverless v4, but the intrinsic overhead of offloading state never entirely vanishes. Lambda MicroVMs tackle this challenge from a different angle.

What Lambda MicroVMs change: persistent execution environments

In short, Lambda MicroVMs deliver strongly isolated, stateful execution environments while preserving the simplicity and operational ease of serverless. AWS built this mechanism atop Firecracker, the same lightweight virtualization technology that underpins standard Lambda functions.

There are three primary highlights. The first is state retention. Once initialized, a MicroVM preserves memory, disk, and running processes across sessions, suspending with state intact during idle periods and resuming when new traffic arrives. AWS announcements indicate that state can be retained for up to eight hours. The second is isolation. Because each session receives a dedicated VM-level sandbox that shares neither kernel nor resources, it is ideally suited for safely executing code written by end users or generated by AI. The third is rapid startup. When building a MicroVM image from a Dockerfile and source code, its pre-initialized state is captured as a Firecracker snapshot; subsequent invocations resume directly from that snapshot, avoiding cold boots and launching virtually instantaneously.

Visualizing the build and deployment workflow makes evaluating the technology even simpler.

1. Dockerfile + コード（S3上のzip）を用意する
2. Lambda が Dockerfile を実行し、アプリを初期化
3. 初期化済みの状態を Firecracker スナップショットとして保存
4. 以降の起動・再開はスナップショットから復元（≒コールドブート回避）

Offered on the ARM64 architecture, each MicroVM scales up to 16 vCPUs, 32 GB of memory, and 32 GB of disk storage. Regional availability launched across US East (N. Virginia, Ohio), US West (Oregon), Europe (Ireland), and Asia Pacific (Tokyo). Having the Tokyo Region supported on day one is a direct advantage for teams evaluating custom development projects for the Japanese market.

Distinguishing suitable from unsuitable workloads

This is the core takeaway of this article: Lambda MicroVMs are not a drop-in replacement for conventional Lambda. Their intended targets are distinctly different.

The primary use case highlighted by AWS involves applications that safely run user- or AI-generated code within isolated, dedicated per-user environments. Concrete examples include browser-based interactive coding environments, data analytics platforms, AI coding assistants, vulnerability scanners, and game servers executing user scripts—workloads where you need to run untrusted code in an isolated, stateful sandbox for a moderate duration. They are also widely discussed as an ideal sandbox for AI agents executing arbitrary code.

Conversely, conventional Lambda's strong suit—short-lived event-driven processing, API backends, transformations triggered by file uploads, and scheduled batch job kickoffs—remains best served by plain Lambda functions. Bringing MicroVMs into those spaces merely introduces unnecessary isolation and state-retention overhead, increasing both cost and architectural complexity. The evaluation criterion is straightforward: is this a workload you can discard after every invocation, or one where you must preserve sessions and isolate third-party code? The former belongs on plain Lambda; the latter is the domain of MicroVMs. Just as migrating HTTP applications to serverless is cleaner using Migration with Lambda Web Adapter, technology choices should always be assigned according to the nature of the workload.

A fundamentally different cost model from Lambda

A point frequently overlooked by project decision-makers is that the billing model differs from conventional Lambda. Estimating budgets with a traditional Lambda mindset will result in discrepancies.

Conventional Lambda charges purely on a per-request, per-millisecond pay-as-you-go basis, where paying strictly for the moments of execution is a major benefit. Lambda MicroVMs align more closely with the capacity planning of continuously running containers on Fargate. Billing is calculated per second, requiring teams to define a baseline configuration, estimate burst capacity above that baseline, and model a representative session from startup to suspension and termination. On the other hand, idle suspended MicroVMs incur snapshot storage charges but do not accrue active compute charges. For interactive workloads that require ongoing availability without continuous compute utilization, this can curb waste compared to always-on containers.

Embarking on development assuming "it's serverless, so it must be cheap" without understanding this cost structure can lead to higher expenses than anticipated. Conversely, migrating well-suited workloads from always-on containers can uncover tangible savings. Quantifying and evaluating cloud costs based on workload characteristics is an ongoing discipline, as explored in Cost Visibility with AWS FinOps Agent.

Case study: unifying an analytics sandbox previously offloaded to containers

Consider a concrete example. A SaaS provider with around 60 employees (company name withheld) consulted us with a challenge: "We offer an in-app feature that executes arbitrary analysis scripts against user-uploaded data, but operating it has become an operational burden." While their primary API was built on Lambda, this analytics feature required running user-authored code safely for extended durations, which exceeded Lambda's boundaries and forced them to spin out a dedicated, always-on container on ECS.

This introduced two major problems. First, containers remained active during late-night hours when there was zero usage, incurring compute charges 24/7. Second, maintaining a bifurcated architecture—serverless for core APIs and containers for analytics—doubled deployment procedures, monitoring systems, and IAM permissions, dividing operational focus. Every new feature release added subtle cognitive overhead across both stacks.

We began by analyzing two weeks of operational logs for this analytics workload. The data revealed that script runs were concentrated during weekday business hours, with virtually zero activity at night or over weekends. Individual analytics sessions lasted at most ten-odd minutes, well beneath the eight-hour retention limit. We concluded that this profile matched Lambda MicroVMs cleanly: spin up an isolated, stateful environment on demand, and suspend it during idle periods. We migrated the analytics sandbox to MicroVMs in the Tokyo Region while leaving the primary API on standard Lambda. As a result, compute charges during idle night and weekend hours disappeared, and eliminating always-on container operations allowed deployments and monitoring to unify around the Lambda stack. The most effective factor was avoiding a wholesale migration and instead drawing a clean line based on workload nature: plain Lambda here, MicroVMs only there. By avoiding trends for their own sake and applying the technology only where appropriate, overall operations actually became lighter.

Before jumping in: categorizing your workloads into two buckets

While Lambda MicroVMs provide a compelling new capability, the entry point for evaluation is not researching feature specs. It begins with auditing and categorizing your organization's workloads.

First, verify whether your business actually has workloads requiring state retention or third-party code isolation. Without interactive sessions, user- or AI-generated code execution, or long-running analytics, MicroVMs are unnecessary, and standard Lambda remains the optimal choice. Second, if you currently offload tasks to containers, examine operational logs to determine whether they truly require continuous uptime or experience substantial idle time. For idle-heavy interactive workloads, suspendable MicroVMs offer strong potential to trim waste. Conversely, workloads running under constant heavy load may be better off remaining on traditional architectures. Because this is a newly released feature, validating behavior and cost models on a small footprint prior to production rollout remains indispensable.

Whether you hit a wall with stateful serverless processing and fell back to containers, saw operations become unwieldy across split architectures, or want an objective evaluation of where Lambda MicroVMs fit into your systems, reach out through GleamHub's Development, AI, and Automation consulting desk. We will review your current architecture and real workload activity, provide a candid assessment including cost estimates on what to keep on plain Lambda, what to move to MicroVMs, and what to leave on conventional infrastructure, and partner with you through migration and operational consolidation.

Sources

• Run isolated sandboxes with full lifecycle control: AWS Lambda introduces MicroVMs － AWS News Blog
• AWS introduces Lambda MicroVMs for isolated execution of user and AI-generated code － AWS What’s New
• AWS Lambda MicroVMs － AWS
• AWS debuts Lambda MicroVMs with up to 8 hours runtime － The Register
• What you need to know about Lambda MicroVMs － theburningmonk.com