AWS unlocks Lambda MicroVMs: up to 8 hours, Firecracker isolation, and new AI guardrails

AWS just quietly expanded what “Lambda” can mean in practice: Lambda MicroVMs can run isolated Linux containers for up to eight hours, built on AWS Firecracker. That directly targets the 15-minute runtime limit in Lambda functions, which has been a persistent pain point for teams trying to run longer tasks without abandoning the serverless model.

The new MicroVM flow is also more hands-on than many serverless patterns. Developers provide a Dockerfile plus application artifacts, upload them to Amazon S3, and AWS builds that into a Firecracker snapshot that can be run with multiple instances if needed. AWS’s headline use case is isolation, including scenarios like inspecting potentially malicious packages, scanning for vulnerabilities, or running AI-generated code while guarding against prompt injection and insecure output. In plain English: AWS is aiming to let you execute things you do not fully trust, but do it in an environment that is still fast to spin up and pay for like serverless.

This matters because “sandboxing” is no longer a niche security checkbox. It has become part of the operating model for modern software delivery and AI experimentation. MicroVMs are positioned as a complement to Lambda functions rather than a replacement, which signals AWS is trying to capture workloads that do not behave well under short-lived function constraints. For example, the source notes that MicroVMs can be used for CI/CD, such as running code as part of pipelines, and developers are already pointing to broader uses: “run anything you like and for up to 8 hours all while giving you full shell access to the VM and unopinionated HTTP ingress,” while still benefiting from SnapStart and true consumption-based pricing rather than wall-time pricing. That combo is not just a developer convenience. It can reduce the operational split between “serverless for webhooks” and “VMs for everything else.”

AI is the other big reason this feature lands. AWS describes MicroVMs as suited for AI agents, and it explicitly ties them to security concerns like prompt injection and insecure output. The source also notes a wrinkle: AWS already offers AgentCore Runtime, which resembles MicroVMs and has a maximum lifetime of eight hours as well. The key distinction in the source is generality and control. MicroVMs are more generalized, and unlike AgentCore Runtime, a MicroVM can be suspended and resumed. That operational flexibility becomes a lever for boards and executives because it can reduce idle cost and improve utilization without forcing teams into a rigid agent runtime model.

AWS says MicroVMs are part of Lambda itself as a “new core feature.” It describes MicroVM states including running, suspended, and terminated. It can automatically scale up to four times the base specification, and it can automatically suspend when there is no traffic. When it resumes, for example in response to a new network request, the state is preserved. That preservation detail is a big deal operationally. Many teams build around stateless function assumptions. Preserving state lets you run longer sessions or maintain working context, while still treating the environment as ephemeral in the broader lifecycle.

Pricing also reflects the “serverless but longer” strategy. MicroVM pricing is based on per-second usage of vCPU and RAM, snapshot storage, and data transfer. RAM is provisioned in a 2:1 GB ratio to vCPU, and when a MicroVM is suspended, compute charges cease. The source highlights a specific second-order effect that decision-makers will care about: the higher compute price is mitigated because when nothing is happening, the system can drop to snapshot storage costs. Translation: if your workload has bursts of activity and long quiet periods, the cost profile can look much closer to true consumption than wall-time compute.

There are constraints too, and executives should pay attention because constraints shape adoption curves. At the time of writing, MicroVMs appear limited to US East, US West, Tokyo, and Ireland regions, and only Arm-based AWS Graviton instances are supported. That can affect procurement, architecture choices, and even vendor lock-in planning for distributed systems that currently target x86 fleets. Also, while a MicroVM is an isolated VM, the source cautions that isolation alone is only one element of AI security, especially if the workload needs network access to other resources. In other words, MicroVMs help contain the execution environment, but security still depends on what the code can reach once it has network connectivity.

Finally, this feature is a response to a very specific and ongoing demand: teams want to run containers on Lambda longer than 15 minutes. With MicroVMs, AWS is offering a serverless, ephemeral environment that can handle relatively long-running tasks or even “a full day of coding,” while using suspension, snapshotting, and consumption-based charging to keep it economically sane. For AWS competitors and peers in cloud-native orgs, the strategic stake is clear: the boundary between “serverless” and “managed VMs or batch jobs” is moving. If you are an engineering leader or finance partner supporting workloads that are currently too long, too stateful, or too security-sensitive for standard functions, AWS has just built a new bridge. The question for decision-makers is whether to redesign around it now, or risk being stuck with duplicated infrastructure while the definition of serverless keeps expanding.