AWS Lambda gives you a way to invoke a piece of code with an events-based model, and to run it in an extremely small and quick to start VM based on Firecracker (which AWS created for this, and open sourced). It's a fantastic value proposition, and has been one of the main carriers of the serverless torch since 2014. But what if you needed the whole Firecracker as a Service runtime, on its own, without the Lambda execution model on top of it?

Let me introduce you to Lambda MicroVM, AWS's new compute primitive, launched on June 22, 2026. It lets you launch a Firecracker MicroVM in less than 2 seconds (just like Lambda), and it lets you fully manage that MicroVM (unlike Lambda). You can drop a web server in it and send as many requests as you want, it'll behave just like a server. You can pause and resume it, and it maintains memory and disk state. You can set it to auto-pause when idle, and auto-resume when it receives a request, and it'll start back up in less than 500 milliseconds (not a marketing claim from AWS, I've tested this thoroughly, my average was 412 ms).

All of that sounds great, but tools without a purpose are just toys. So let me dive into where Lambda MicroVM is a true differentiator, and the tech details you need to know. Spoiler: Lambda MicroVM is what powers AgentCore Runtime.

Palark, a holistic DevOps and SRE agency from Germany, just launched an affordable support service that works like a fire brigade for your cloud or server infra.

Similar to health or car insurance, DevOps insurance offers subscription plans with reasonable monthly fees and prompt assistance in case of infrastructure emergencies.

Personal opinion: I've reviewed this thoroughly, and it sounds like a fantastic idea for teams that can't afford on-call engineers due to their small size, and at the same time don't want to completely offload infrastructure management to an MSP that would provide 24/7 support as one more line item in a very large package. I've spoken with the Palark team and I'm confident they really know what they're doing.

Lambda MicroVM lets you create a dedicated environment that belongs to a single tenant, session, or job. It's a perfect fit for work that needs continuity inside an isolation boundary, such as an interactive workspace that installs packages, an analysis session that keeps local processes and intermediate files, a scanner that runs third-party code, or an agent that makes several tool calls against the same execution environment.

Lambda Functions are oriented toward event-driven, request-response execution. They provide isolation at the execution level, with each request or triggering event managing its own state. Some state is shared across invocations, such as database connections, but that's more an artifact of reusing resources and avoiding initialization delays, and less an intentional, conceptual shared boundary.

Lambda MicroVMs provide you with an isolated state that's meant to be shared across related events and requests, while still being fast enough to spin up and tear down that you can afford to launch a new environment for each conceptually separate session, job or set of events. Moreover, it gives you the degree of network and process isolation needed to protect other environments or other tenants from untrusted or potentially unsafe executions.

A great example of potentially unsafe executions is code ran by Generative AI. You want to provide a dedicated, tightly-controlled execution environment, with only the permissions it needs. Lambda MicroVM lets you do this, with startup times fast enough to not drag down an agent's response time. That's why AgentCore Runtime runs on Lambda MicroVM.

One important point is that the application now needs a durable relationship between its own identity model and the AWS resource it runs on. It must record which MicroVM belongs to a session, route requests to the correct endpoint, issue access tokens, decide when to suspend or terminate the environment, and persist any state that must outlive it. Your product’s control plane owns that mapping, because every later request and lifecycle operation depends on reaching the correct environment.

Capacity and delivery planning must also be done at the environment-level. Request volume alone does not describe the service footprint. Teams also need the number of running and suspended environments, baseline memory per environment, expected creation rate, idle policy, and maximum lifetime.

To run something in Lambda MicroVM, you upload a ZIP package with a Dockerfile and application artifacts to Amazon S3. Lambda starts a fresh MicroVM from a managed Amazon Linux 2023 base, runs the Dockerfile, starts the application, waits for readiness when that hook is configured, and captures a Firecracker snapshot. The snapshot includes the root filesystem, memory used by running processes, network connections, file descriptors, and other state present when the build completes. That snapshot is a Lambda MicroVM image, from which you launch MicroVMs. The image is versioned, and one image version can create multiple independent MicroVM resources.

The image establishes the initial state shared by every MicroVM created from that version. A MicroVM launched from that image resumes at the captured point, and will have all the common dependencies, background processes, compiled artifacts, and loaded application state from when the snapshot was created. Tenant-specific values belong after restoration because every new environment begins with an identical copy of the snapshot.

The runtime hooks separate common initialization from environment-specific work. The /run hook receives the MicroVM identifier and can receive a payload of per-environment data such as a tenant ID, session token, signed URL, or Secrets Manager path. The /suspend hook can be used to flush writes and close resources before checkpointing. The /resume hook can refresh credentials, re-establish connections, and validate restored state. The /terminate hook can perform final cleanup before Lambda releases the environment.

Image versioning also becomes part of application delivery. Updating code, configuration, hooks, capabilities, or the managed base produces a new image version. Versions have independent build and activation states, so a platform can validate a build before allowing it to create environments. The runtime remains session-oriented, but the release unit is the image version from which those sessions start.

RunMicrovm restores the image snapshot, assigns a unique ID, creates an endpoint, and moves the resource into its running state after the /run hook succeeds. Suspension checkpoints memory and disk, resume restores that checkpoint, and termination is final. The snapshot that reduces repeated initialization also copies initial state across environments and adds restore transitions to the application lifecycle.

The maximum duration parameter can be set from one second to 8 hours, and Lambda terminates the MicroVM when that limit is reached while the resource is running or suspended. If you need an environment that needs to survive beyond 8 hours, you have to persist its durable state elsewhere and continue in a new MicroVM. Lambda team, if you're reading this, please increase this limit to 30 days for re:Invent!

Automatic suspension uses endpoint traffic as its activity signal. When no request reaches the endpoint for the configured idle period, Lambda can suspend the MicroVM. A background process may still be doing useful work while the endpoint remains quiet, so asynchronous jobs need to disable automatic suspension.

Auto-resume adds a user-visible transition. Lambda holds the first inbound request while it restores the suspended state and runs the /resume hook. The delay depends on the checkpoint and the hook, and a failed resume returns 502 Bad Gateway. Products with interactive latency targets need to test this first request explicitly and define retry behavior for resume failures.

Each MicroVM also receives a unique service-managed HTTPS endpoint. The endpoint supports HTTP/1.1, HTTP/2, WebSockets, gRPC, and Server-Sent Events, which gives interactive products several ways to maintain direct communication with the assigned MicroVM. Every request requires an encrypted JSON Web Encryption token scoped to a specific MicroVM, allowed ports, and an expiration time.

A coding environment can keep its toolchain and working directory alive while it works or waits. An analysis session can retain local results and a running process while it finishes. An agent can execute several steps in one isolated environment while its orchestration layer remains elsewhere, providing full containment and isolating any unexpected behavior. In each case, the session keeps its state, receives traffic directly, and stays separated from other sessions without you needing to manage the virtualization layer.

One thing to keep in mind is that Lambda MicroVM doesn't autoscale horizontally. New capacity comes from additional RunMicrovm calls, and every MicroVM has its own endpoint. Lambda does not place several MicroVMs behind one shared endpoint, since MicroVMs are meant to be stateful. It does autoscale vertically though, as you'll see in the next section.

Compute uses a baseline-and-peak model. The image sets baseline memory, with vCPU allocated at 2 GB per vCPU. During higher demand, the environment can use up to four times its baseline, and billing covers the baseline while the MicroVM runs plus the active duration of memory and CPU consumed above it. As of July 31, 2026, ARM64 pricing in US East (N. Virginia) is $0.0000276944 per vCPU-second and $0.0000036667 per GB-second, equivalent to approximately $0.0997 per vCPU-hour and $0.0132 per GB-hour. Available configurations range from 0.5 GB and 0.25 vCPU at baseline to 8 GB and 4 vCPUs, with peak resources reaching 32 GB and 16 vCPUs. The service currently supports only ARM64 and is available in five AWS Regions: US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Ireland), and Asia Pacific (Tokyo).

Suspending a MicroVM stops compute charges, but snapshot-related charges continue. In US East (N. Virginia), AWS charges $0.00155 per GB read when a MicroVM starts or resumes, $0.0038 per GB written when it suspends, and $0.08 per GB-month for MicroVM image and suspended-state storage. MicroVM image storage has a one-week minimum retention period. AWS also charges standard data-transfer rates, including applicable traffic between a MicroVM and an Amazon VPC. The cost model therefore depends on baseline size, time above baseline, active duration, image and checkpoint size, suspend frequency, retained duration, and network path.

For example, consider a developer environment in US East (N. Virginia) with a 2 GB and 1 vCPU baseline. It runs for 2 hours per day on 20 working days, reaching the full 8 GB and 4 vCPU peak for 30 minutes each day. It also spends four hours suspended each day, with one launch and one suspend/resume cycle. Assuming a 2 GB image, a 2 GB suspend checkpoint, 720 hours per month, and no data transfer:

The resulting monthly cost is approximately $9.28, excluding data transfer. The image-storage charge is shared by every MicroVM launched from that image, so its effective per-environment cost decreases as the image is reused

A Lambda MicroVM has separate configurations for traffic coming in and traffic going out. Inbound requests use the unique service-managed HTTPS endpoint described above, while outbound connections use an egress network connector selected when you call RunMicrovm. The two paths are independent, so routing a MicroVM through your VPC does not move its endpoint into that VPC or change how clients reach it. Network connectors are attached when the environment starts and cannot be changed while it is running, so moving a session to a different network policy means launching a new MicroVM.

By default, Lambda MicroVMs can reach the public internet. Lambda provides a managed INTERNET_EGRESS connector for this, so the environment can download packages, call a model provider, reach a SaaS API, or send telemetry without you configuring a VPC or NAT gateway. That's convenient for a coding environment or an agent, but it's also an important part of the security model. Isolating untrusted code from other tenants does not stop that code from sending data somewhere on the internet, so public egress should be an explicit decision rather than a default you accept without thinking about it.

To reach private resources, you create a Lambda Network Connector with the subnets, security groups, and either IPv4 or DualStack configuration from one of your VPCs. Lambda provisions elastic network interfaces (ENIs) for the connector, and the resource moves through PENDING before it becomes ACTIVE. You then pass its ARN in the egressNetworkConnectors parameter when calling RunMicrovm. A connector is meant to be reused across many MicroVMs, not created for every session. Connector creation can take up to 10 minutes while Lambda provisions the ENIs, so it belongs in your platform infrastructure, not in the hot path that launches an environment for a user.

Once the VPC connector is attached, outbound traffic follows the routing and security controls of those subnets. The MicroVM can connect to resources such as RDS, ElastiCache, internal APIs, and systems reachable through Direct Connect or a VPN, as long as the route tables, security groups, network ACLs, and the destination itself allow it. If the MicroVM also needs public internet access, the VPC must provide that path, typically through a NAT gateway for IPv4 or an egress-only internet gateway for IPv6. If the subnets have no internet route, AWS SDK calls to public service endpoints also need the corresponding VPC endpoints, such as an interface endpoint through AWS PrivateLink or a gateway endpoint for S3 and DynamoDB.

One thing to keep in mind is that the VPC connector only controls egress. The MicroVM still receives inbound requests through its Lambda-managed HTTPS endpoint, using the JWE token and allowed-port rules described earlier. It does not become directly addressable through the private IP space of your VPC. If an environment does not need inbound traffic, Lambda also provides a NO_INGRESS connector, which is a better fit for a worker that communicates only through outbound requests or external state.

The inbound endpoint also has its own bandwidth limit. Request and response bandwidth scales with the baseline size, from 1 MB per second for a 0.5 GB MicroVM to 16 MB per second for an 8 GB MicroVM. That limit covers traffic passing through the service-managed endpoint, which means a small environment that streams large responses, transfers artifacts, or maintains several active connections can become network-bound before it becomes CPU-bound.

Networking and IAM solve different problems. The execution role passed to RunMicrovm controls which AWS API operations the code is authorized to perform, while the network connector controls which destinations it can reach. Routing traffic into a VPC does not grant permission to read a secret or access an S3 object, and granting an IAM permission does not create a route to a private database. A production environment needs both layers to agree: the packet needs a valid network path, and the request still needs authorization.

Suspension adds one more wrinkle. A checkpoint can preserve the in-memory object that represents a database client, HTTP connection, or WebSocket, but the remote side may close that connection while the MicroVM is suspended. The /suspend hook should flush writes and close connections that should not cross the checkpoint, while the /resume hook should recreate them, refresh credentials, and validate restored state.

Lambda MicroVM lets you maintain an assigned environment for a bounded session or job, with memory, disk, processes, endpoint access, suspension, and resumption built into the service. It's essentially Firecracker MicroVM as a Service, or Lambda Functions without the Functions part.

Apps that use Lambda MicroVM should be designed around which state belongs in the image, which state must be unique per environment, how the control plane maps users to endpoints, what the workload can reach, how resume affects latency, how long the environment may live, and when its cost should end.

It's a game changer for running code you don't trust, such as when building or using agents. But it's also a really exciting new compute primitive, with a lot of potential!