AWS Lambda revolutionised cloud computing when it launched, giving us the power to run code without thinking about servers. But over the last couple of years, AWS has radically expanded what ‘Serverless’ actually means. We now have three distinct flavours of Lambda compute: Standard or Classic Lambda Functions, Lambda Managed Instances, and the recently launched Lambda MicroVMs.
While they all share the Lambda name, they are built for entirely different architectures. If you are confused about when to use which, this guide breaks down exactly what these features mean, how they differ, and the pros and cons of each.
1. Standard Lambda Functions: The Event-Driven Classic
What it means: Standard Lambda is the classic serverless offering. Upon receiving an event, AWS spins up an execution environment which are Firecracker microVMs, on its fully-managed, shared bare-metal fleet to run your code.
How it differentiates: It relies on a strict 1:1 concurrency model. One execution environment processes exactly one request at a time. If you get a sudden spike of 1,000 users, AWS instantly spins up 1,000 isolated environments. It is stateless and highly ephemeral.
Pros
- No Infrastructure Management: You write code, and AWS completely abstracts the underlying hardware.
- Instant Scaling: It reacts to traffic spikes in milliseconds, scaling from zero to thousands of concurrent executions seamlessly.
- Pay per Execution: You only pay for the exact compute duration your code is running; it scales perfectly to zero when idle.
Cons
- Cost at Scale: Paying for thousands of individual execution environments becomes highly expensive for massive, continuous workloads.
- The “Cold Start” Penalty: Sudden traffic spikes can cause latency delays as AWS provisions new execution environments from scratch.
- Hard Limitations: Executions are strictly capped at a 15-minute timeout.
When to use it: Use Lambda functions for unpredictable traffic, cron jobs, microservices, and asynchronous event-driven pipelines (like processing SQS queues or DynamoDB streams).
2. Lambda Managed Instances (LMI): High-Throughput EC2 Power
What it means: AWS Lambda Managed Instances (LMI) lets you run Lambda functions on selected Amazon EC2 instance types while preserving the standard Lambda programming model. You configure a capacity provider, and AWS handles the OS patching, routing, and auto-scaling of those EC2 instances inside your VPC.
How it differentiates: The biggest shift here is multi-concurrency. Unlike Lambda functions, LMI allows a single execution environment to process multiple requests simultaneously. This dramatically improves resource utilisation.
Pros
- Massive Cost Savings: Because it utilises EC2 pricing models (including savings plans), LMI is significantly cheaper for high-traffic, steady-state workloads.
- Hardware Control: You can specifically select memory-optimised, compute-optimised, or ARM-based Graviton instances tailored to your workload.
- Better Utilisation: Multi-concurrency ensures your CPU isn’t sitting idle while waiting for an external database query to resolve.
Cons
- Thread-Safety Required: Because global variables and shared resources are accessed concurrently, your application code must be strictly thread-safe.
- Slower Scaling: Lambda monitors CPU utilisation to scale EC2 instances up or down. This is asynchronous and takes much longer to scale than standard Lambda functions.
When to use it: LMI is perfect for high-volume APIs, predictable enterprise workloads, and heavy data processing tasks where standard Lambda becomes too expensive.
3. Lambda MicroVMs: Stateful Sandboxes
What it means: Lambda MicroVMs introduce a completely new compute primitive. Instead of waiting for an event, your application calls the ‘run-microvm’ API when it needs a dedicated, isolated execution environment for a specific user, agent, or task.
How it differentiates: MicroVMs are built for stateful sessions, not short invocations. They run as tiny virtual machines inside a Docker container, accessed via dedicated HTTPS endpoints. Most importantly, they preserve memory and disk state for up to eight hours, pausing when idle and resuming near-instantly when needed.
Pros
- True Isolation: Every session gets its own dedicated, Firecracker-powered VM with no shared kernel or state between users.
- Instant Warm Starts: Because the VM preserves its state, resuming a paused MicroVM takes milliseconds, entirely bypassing cold starts.
- Automatic Bursting: During peak activity, a MicroVM can vertically scale up to 4x its configured baseline automatically.
Cons
- High Complexity: You are responsible for lifecycle management. You must track session endpoints, route users correctly, and explicitly terminate environments when they are no longer needed.
- Pricing Model: You pay for a baseline while the machine is running, plus snapshot storage fees when it is suspended.
When to use it: MicroVMs are designed for building AI agents, interactive browser-based IDEs, data analysis sandboxes, and complex multi-tenant applications that require strict isolation. Lambda MicroVMs are used as a sandbox for Claude Managed Agents.
Summary Comparison
Feature | Standard Lambda | Managed Instances (LMI) | Lambda MicroVMs |
Best For | Event-driven architecture | Steady, high-volume APIs | AI agents and isolated sessions |
Concurrency | 1:1 (One request per env) | Multi-concurrency | Custom (Full OS environment) |
State | Stateless (Ephemeral) | Persistent EC2 Uptime | Stateful (eight-hour Suspend/Resume) |
Scaling | Instant (Milliseconds) | Slower (EC2 Instance boot) | Manual API and 4x Vertical Burst |
Pricing | Pay per execution | EC2 pricing / Savings plans | Baseline and snapshot storage fees |
Conclusion
AWS Lambda has evolved into a versatile compute platform, and choosing the right option depends entirely on balancing your workload’s scalability, cost-efficiency, and statefulness requirements.
For most event-driven needs, start with standard Lambda to benefit from its instant scaling and simplicity. As your architecture matures, consider migrating high-volume, steady-state APIs to Lambda Managed Instances (LMI) for significant cost optimisation. For complex, stateful applications like AI agents or isolated sandboxes, explore the dedicated power of Lambda MicroVMs.
If you designed your Lambda architecture a few years ago, it is worth revisiting those decisions now. The workarounds many teams built to cope with cold starts, concurrency limits, or short-lived execution, custom warming schedules, over-provisioned concurrency, entire services rearchitected around 15-minute timeouts, may no longer be necessary. Reassessing these newer options can uncover meaningful cost savings, simpler and more reliable operations, and better performance, without a full rebuild.
Saborni Bhattacharya
Lead Cloud Consultant, Scale Factory
