Lambda Now Comes in Three Shapes
Explore AWS Lambda's Event Functions, Web Functions, and MicroVMs. Compare architecture, pricing, concurrency, and real-world use cases.
For about a decade, "Lambda" meant one thing: a handler that receives an event, processes it, and returns a result.
In 2026, that changed.
What changed
Lambda now has three form factors, all built on Firecracker isolation. Your existing functions are now called Event Functions, which is a naming change only. No code changes or redeployments are needed.
- Lambda MicroVMs came first. AWS announced them on June 22, 2026 as a compute primitive for running user or AI-generated code with VM-level isolation, near-instant launch and resume, and state preservation.
- Lambda Web Functions followed on October 12. They let you run a standard HTTP server (Express, Hono, Fastify, Next.js) on Lambda without rewriting it as an event handler.
The important distinction isn't just how you write the code. It's how each model handles concurrency, state, scaling, isolation, and billing.
The three shapes at a glance
| Event Functions | Web Functions | MicroVMs |
|---|---|---|---|
What you write | A handler that receives an event | A standard HTTP server that listens on a port | Any app packaged with a Dockerfile |
Unit of work | One invocation | One HTTP request, many at once per environment | A session: one VM per user, agent or job |
State | Nothing to rely on | In memory, but environments come and go | Memory, disk and processes kept for up to 8 hours |
Concurrency | One request per environment | Many requests per environment | One VM per session |
Runtime limit | 15 minutes per invocation | Scales to zero when idle | Up to 8 hours per MicroVM |
You pay for | Requests and duration | Requests, active CPU time, and memory while the environment exists | Baseline vCPU and memory per second, plus snapshot storage while suspended |
Languages | Many | Node.js 24 only, at launch | Anything that runs on Linux ARM64 |
All three sit on Firecracker. The difference is what AWS hands you on top of it.
Event Functions: the original Lambda model
Event Functions are what most developers already know as AWS Lambda.An event source triggers a function, the handler processes the event, and execution finishes.
Typical use cases include:
- Processing S3 uploads.
- Consuming messages from SQS.
- Scheduled background jobs.
- Event-driven automation.
- Lightweight API backends.
An execution environment handles one invocation at a time. Lambda can create additional environments to handle concurrent invocations.A single invocation can run for up to 15 minutes.
Billing is based on the number of requests and execution duration, measured in GB-seconds according to the configured memory.
One important clarification: Lambda environments can be reused, but you should never depend on that reuse for durable application state. Use services such as DynamoDB, S3 or RDS when state must survive execution environments.
For most event-driven workloads, this model remains a straightforward and effective choice.
Web Functions: your HTTP server, running on Lambda
Web Functions introduce a different programming model.
Instead of writing a Lambda handler, you write a standard Node.js HTTP server that listens on a port and handles requests directly.
You can use familiar frameworks such as:
- Express
- Hono
- Fastify
- Next.js
There is no Lambda-specific handler adapter or wrapper required.
Lambda provides an HTTPS endpoint, manages execution environments, and scales your application with incoming traffic, including scaling to zero when idle.
You deploy your application as a .zip package using the Lambda Web Functions deployment tooling.
Two design choices matter most
1. Concurrency inside one execution environment
This is probably the biggest architectural difference.
An Event Function environment processes one invocation at a time. A Web Function environment can handle multiple concurrent HTTP requests.
The
maxConcurrencyPerEnvironment setting accepts values from 1 to 128, with a default of 64. Lambda dynamically adjusts actual concurrency based on resource utilization.
This changes how you should think about application-level state.
For example, a global variable holding request-specific information, an unsafe shared cache, or a mutable singleton can introduce race conditions when multiple requests are running concurrently.
Shared clients and connection pools can still be reused, provided they are designed for concurrent access.If you're migrating an existing Express application, review shared state and test concurrent requests before deploying it.
2. Billing follows active CPU usage, not simply wall-clock time
Web Functions introduce active CPU billing.
You pay for:
- Requests.
- CPU time actively consumed by your application and runtime.
- Memory consumed over the lifetime of the execution environment.
- Applicable data transfer.
For example, when an application waits for a database query or an external API response, it consumes little CPU during that waiting period. However, memory continues to be billed while the environment exists.
This makes Web Functions interesting for workloads such as:
- API backends.
- Server-side rendering.
- Applications with I/O-heavy requests.
- Streaming responses, including AI-generated responses.
However, this doesn't mean Web Functions are automatically cheaper. CPU-heavy applications and environments that remain idle for extended periods need their own cost analysis.
MicroVMs: an isolated machine for every session
MicroVMs solve a different problem. Think of a platform where a user's or an AI agent's code must run safely, such as a coding assistant, a notebook product or a vulnerability scanner.
Examples include:
- AI coding assistants.
- Online coding environments.
- Interactive notebooks.
- Vulnerability scanners.
- Isolated development and testing environments.
You need more than a short-lived function. You need an isolated environment with its own memory, disk and running processes.
This is where Lambda MicroVMs fit.
Each MicroVM provides VM-level isolation through Firecracker. Unlike ordinary containers, separate MicroVMs have their own virtualized kernels.
How it works
The execution model is based on pre-initialized images and snapshots.
- Package your application code and Dockerfile and upload the artifacts to S3.
- Lambda builds a MicroVM image by executing your Dockerfile and initializing your application.
- Lambda captures a snapshot of the initialized memory and disk state.
- When you launch a MicroVM, it resumes from that snapshot.
- Each MicroVM receives its own HTTPS endpoint.
- When idle, it can suspend while preserving memory and disk state, then resume when needed.
A MicroVM can have a maximum execution duration of eight hours, including its suspended time.
Limits and engineering considerations
1. CPU, memory and disk
MicroVMs support both ARM64 and x86_64 architectures.
The baseline configuration can scale vertically up to:
- 16 vCPUs.
- 32 GB memory.
- 32 GB disk.
The actual available resources depend on the baseline configuration and its corresponding peak limits.
2. Snapshot lifecycle
Snapshots preserve the application's initialized memory and disk state.
This creates an important consideration: anything computed during image initialization can be present in every MicroVM launched from that image.
For example:
- Random seeds.
- Temporary credentials.
- Open network connections.
- Cached external data.
- Initialization timestamps.
These may become stale or inappropriate when an instance resumes.
Use the available lifecycle hooks to perform per-instance initialization and refresh state after resume.
3. Individual lifecycle management
MicroVMs aren't an automatically scaled fleet behind one shared endpoint.Each MicroVM has its own endpoint, and AWS doesn't provide load balancing across multiple MicroVMs through a single endpoint.You manage individual session instances through APIs, including launching, suspending, resuming and terminating them.Idle policies can automate suspension and resumption, but your application still needs to manage session-to-MicroVM mapping.
4. Authentication
Requests use short-lived authentication tokens through the
X-aws-proxy-auth header.If you're building a browser-based application, your frontend or backend needs a secure approach to obtaining, refreshing and attaching those tokens.A small control plane can manage session creation, authentication and MicroVM lifecycle operations.
5. Network security
Network access needs deliberate planning, especially when executing untrusted code.Use appropriate egress controls and VPC network connectors when accessing private resources. Don't assume that VM-level isolation alone provides complete application security.
Regional availability
MicroVMs launched in five AWS Regions in June 2026.
AWS subsequently added five Regions in August and four more in October, bringing availability to 14 Regions as of November 7, 2026.AWS also added x86_64 architecture support on November 5, 2026, alongside ARM64.These are good examples of why launch announcements should not be treated as permanent service limits. Always check the latest AWS documentation before designing around regional or architectural availability.
Understanding the cost differences
The three models have different billing structures.
Model | Main billing components |
|---|---|
Event Functions | Requests and execution duration |
Web Functions | Requests, active CPU, environment memory and data transfer |
MicroVMs | Running compute, snapshot storage, snapshot reads/writes and data transfer |
The important point is that each model charges for a different unit of work.
For Web Functions, an application that spends considerable time waiting on external services may benefit from active CPU billing.
For MicroVMs, suspending idle environments can reduce compute costs, but snapshot storage and read/write operations still incur charges.A MicroVM left running continuously isn't automatically an economical solution.
Before adopting any of these models, calculate costs using your actual workload, memory requirements, request patterns and regional pricing.
How I'd choose
What if you're using Python, Java or .NET?
Web Functions currently support Node.js runtimes only. Don't force an incompatible application into this model. Consider Event Functions, containers or other compute services depending on the architecture.
These models can also work together
One interesting aspect of AWS's approach is that these execution models don't have to compete with each other.
Imagine an AI-powered coding platform:
- Event Functions process background tasks, notifications and asynchronous workflows.
- Web Functions handle the user-facing API and application backend.
- MicroVMs provide isolated environments where users or AI agents execute code.
Each model handles the part of the application it is designed for.That's a more useful way to think about the evolution of Lambda than simply asking which new option is better.
What I'd validate before adopting them
Before using these models in a production architecture, I'd validate the following:
- Regions: the lists above are from launch material and have already grown for MicroVMs.
- Quotas: Web Function environments are bounded by your regional vCPU quota, and MicroVM fleets count against memory quotas.
- Pricing: rerun the numbers with your own request shape using the current AWS Lambda pricing page.
- Concurrency safety: for Web Functions, test with parallel requests, not just a single curl.
- Lifecycle behaviour: for MicroVMs, test suspend and resume deliberately, including expired credentials and stale data
Final thoughts
The useful change is not that Lambda got more features. It is that the word "Lambda" now
refers to three different execution models with different billing and different failure
modes. Picking the right one comes down to three questions: is the work event-driven, is
it an HTTP server, or does each user need their own persistent machine?
These are new services and the details will keep changing. This article reflects what I
could confirm from official AWS sources as of November 2026. If you have run either one
in anger, I would like to hear what surprised you.
This is an independent technical overview intended to help AWS practitioners understand the differences between Lambda's execution models and make informed architectural decisions.
If you've experimented with either of the newer execution models, I'd be interested to hear about your experience, especially around concurrency, suspend/resume behavior and real-world cost.
References
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article