What is going on with Lambda?
How AWS's flagship serverless service quietly abandoned its purist roots to conquer the agentic era
If you’ve read my previous piece, AWS who? Meet AAS , you know that every once in a while I like to take a step back from writing code and CDK stacks to look at the bigger picture. Unlike my usual hands-on technical breakdowns, these articles are not about how to configure a service — they are about business, economics, and AWS strategy. By looking at what AWS is building, how they price it, and who they are suddenly competing with, we can figure out where the cloud giant is heading next.
And right now, there is no better place to look than AWS Lambda.
For over a decade, Lambda was the poster child of the Serverless revolution. The rules were sacred, simple, and drilled into every Solution Architect’s head: functions are stateless, ephemeral, event-driven, handle a single request at a time, live for a maximum of 15 minutes, and charge you for wall-clock duration. If you needed state, long-running processes, port-listening web servers, or dedicated EC2 instances, AWS politely pointed you toward ECS, EKS, or EC2.
Well, throw that textbook out the window.
Over the past year — starting with the bombshells dropped at re:Invent 2025 and culminating in the October 2026 launches — AWS has fundamentally dismantled and rebuilt what Lambda is. Today’s Lambda is stateful. It runs on dedicated EC2 instances in your VPC. It listens on HTTP ports. It pauses and resumes virtual machines for hours, and orchestrates workflows for up to a year.
Seemingly overnight, Lambda is leaving its “serverless” origins behind. So… what on earth is going on with Lambda?!
The Great Schism: From One Function to Three Primitives
For eleven years, “a Lambda” meant one thing. As of October 2026, AWS has officially split Lambda into three distinct compute primitives (or “form factors”), all running on top of Firecracker microVM technology, alongside two massive structural add-ons that completely break the old serverless rules.
Let’s look at all the new flavors of Lambda on the menu today — including a bonus one you might have missed — and see what they actually do.
1. Lambda Event Functions (The Artist Formerly Known as Lambda)
First, the rename. What we used to call “a Lambda function” is now officially rebranded as Lambda Event Functions .
Nothing changes in your code or deployments here. It is the classic, single-concurrent handler model: an event comes in from S3, SQS, or EventBridge, a single execution environment processes that one event in isolation, and you pay for wall-clock time from start to finish.
Why rename it? Because when a service starts doing everything, the original thing needs a label. By calling traditional functions “Event Functions,” AWS is subtlety telling us that event-driven glue code is now just one third of Lambda’s identity.
2. Lambda Web Functions (Goodbye, API Gateway Tax)
For years, running a standard web app on Lambda felt like shoving a square peg into a round, expensive hole. You had to wrap your Express or Fastify app in custom adapters, front it with API Gateway, suffer through cold starts on traffic spikes because each concurrent request spun up a separate execution environment, and — worst of all — pay for 100% of the wall-clock time while your function sat completely idle waiting for a database query or an LLM API response.
Enter Lambda Web Functions .
With Web Functions, your code is just a standard HTTP server listening on a port (
Express, Hono, Fastify, Next.js—no adapters required). You deploy it with a single CLI command (aws lambda-web deploy), and you get native multi-region replication and latency-based routing out of the box.But the real revolution here is under the hood:
- Multi-concurrency: A single warm execution environment can handle up to 128 concurrent requests simultaneously. Cold starts? Virtually eliminated for steady traffic.
- Active CPU Billing: Instead of paying for wall-clock duration, you pay for the active CPU time your code actually consumes (plus the memory footprint of the warm environment). Waiting 15 seconds for Bedrock to stream tokens back to your user? That idle I/O wait costs you almost nothing in CPU.
3. Lambda MicroVMs (Stateful Sandboxes for the Agentic Era)
If Web Functions bent the serverless rules, Lambda MicroVMs shattered them completely.
Introduced in mid-2026, Lambda MicroVMs give you dedicated, Firecracker-isolated virtual machines with full OS capabilities (Amazon Linux 2023 or your own Dockerfile), dedicated HTTPS endpoints supporting HTTP/2, gRPC, and WebSockets, and — wait for it — state persistence and customer-managed lifecycles.
Instead of AWS deciding when your environment dies, you control the lifecycle. You can spin up a MicroVM for a user session, let an AI agent install packages, write files to disk, and run untrusted code, then suspend the MicroVM when the user goes idle, preserving both memory and disk state for up to 8 hours, and resume it almost instantly when the next prompt arrives.
That is not a stateless function. That is a serverless pet VM.
4. Lambda Durable Functions (“Step-Lambdas”)
I wrote a full hands-on technical overview of Lambda Durable Functions right after re:Invent 2025, where I dubbed them “Step-Lambdas".
Previously, if you wanted multi-step orchestration, human-in-the-loop callbacks, or retries that spanned hours, you had to brave the complexity (and pricing) of Step Functions. Durable Functions bake a checkpoint-and-replay engine directly into your Lambda code. Using simple decorators and calls like
context.step() and context.wait_for_callback(), your function can pause execution, terminate the underlying container so you pay zero compute while waiting, and resume right where it left off—for up to one full year.And in 2026, AWS quietly supercharged Durable Functions: increasing maximum durable operations per run from 3,000 to 30,000, and quadrupling checkpoint payloads to 1 MB — just enough to store an entire LLM agent conversation history between steps. Coincidence? Not a chance.
5. Lambda Managed Instances (Putting the “Server” Back in Serverless)
Perhaps the most ironic name in AWS history: Lambda Managed Instances (LMI) .
LMI lets you run your Lambda functions on dedicated EC2 instances provisioned inside your own AWS account and VPC. AWS still manages the OS patching, routing, and scaling, so the developer experience feels like Lambda. But under the hood, it runs on EC2 Nitro using container isolation instead of shared-fleet Firecracker microVMs.
With Managed Instances, you get multi-concurrency per environment, access to Graviton4 hardware, custom CPU-to-memory ratios, extended timeouts (up to 90 minutes!), zero cold starts on warm fleets, and the ability to slash your bill using EC2 Savings Plans and Reserved Instances.
6. Bonus: Lambda Tenant Isolation Mode
Did I miss any? While not a separate compute primitive, Lambda Tenant Isolation Mode (launched late 2025 and expanded across SQS, Kinesis, and EventBridge in 2026) deserves a mention.
Historically, multi-tenant SaaS builders had a nasty dilemma: share execution environments across customers (risking memory leaks or cross-tenant data bleed) or deploy duplicate Lambda functions per customer (an operational nightmare). Now, you pass a
tenant-id header or event property, and Lambda guarantees at the compute layer that an execution environment warmed up for Tenant A will never be reused for Tenant B.“Legacy” Lambda vs. The New Lambda Pantheon
When you line all of these up next to the classic Lambda we’ve used since 2014, the contrast is wild. Every single constraint that used to define “serverless” has been systematically inverted:
Look at that table. If someone showed you the right-hand column three years ago and asked which AWS service it described, you would have guessed a mashup of EC2, ECS Fargate, Step Functions, and App Runner. You certainly wouldn’t have said Lambda.
Follow the Money: Why Is AWS Doing This?
So why is AWS turning its purest serverless service into a stateful, port-listening, EC2-backed Swiss Army knife?
As I explored in The Token Based Economy , cloud architecture shifts are almost always driven by unit economics and market defense. When we look at the business strategy behind Lambda’s transformation, three motives become crystal clear.
1. Legacy Lambda Was Broken for AI and Agents
In AWS who? Meet AAS , I argued that AWS is repositioning its entire portfolio around Amazon Agentic Services (AAS).
Here is the dirty secret of the AI boom: “Legacy” Lambda is terrible for LLM and agentic workloads.
- If an AI app calls Amazon Bedrock and waits 25 seconds for a reasoning model to decode tokens, classic Lambda charges you for 25 seconds of wall-clock compute while your CPU sits at 0.1% utilization. Web Functions fixes this with Active CPU billing and native HTTP response streaming.
- If an autonomous agent needs to plan, call tools, wait three hours for a human approval, and loop 500 times, classic Lambda times out at 15 minutes. Durable Functions fixes this with 1-year checkpointed workflows and free waits.
- If a coding agent (like Claude Code or an internal enterprise assistant) needs to write and execute Python scripts, install npm packages, and inspect files across a 30-minute debugging session, classic Lambda is too locked down and stateless. Lambda MicroVMs fixes this by giving every agent session its own persistent, isolated sandbox.
AWS didn’t just add random features to Lambda — they retrofitted Lambda to be the default runtime for the Agentic era.
2. Crushing the Niche Cloud Disruptors
Over the last few years, a wave of specialized, developer-first cloud platforms started eating into AWS’s mindshare by solving the exact pain points Lambda ignored:
- Vercel and Cloudflare won over frontend and full-stack developers with zero-config deployments, edge routing, and fluid compute that doesn’t charge for I/O wait. AWS’s answer? Lambda Web Functions.
- Temporal, Inngest, and Cloudflare Workflows became the darling orchestrators for resilient microservices and AI agents. AWS’s answer? Lambda Durable Functions.
- E2B, Modal, and Fly.io captured the booming market for fast-booting AI code sandboxes and stateful microVMs. AWS’s answer? Lambda MicroVMs.
Instead of spinning up five brand-new AWS services with confusing names that nobody can remember (and let’s be honest, AWS naming has never been their strong suit), AWS packed all of these capabilities directly under the Lambda umbrella — a brand every developer already knows and trusts.
3. Stopping the “Serverless Graduation” Bleed
Finally, there is the enterprise retention play. For years, the lifecycle of a successful startup on AWS looked like this: start on Lambda because it’s fast and free at low volume; hit massive scale; realize your Lambda bill is now higher than your payroll; and spend six months rewriting everything into containers on EKS or EC2.
That migration moment is dangerous for AWS. When a company is forced to re-architect from scratch to escape the “serverless tax,” that is the exact moment Google Cloud, Azure, or bare-metal providers swoop in with a competing offer.
With Lambda Managed Instances and Web Functions, AWS removes the reason to ever “graduate” off Lambda. Hitting massive, predictable scale? Don’t rewrite your code for Kubernetes — just flip your Lambda to run on Managed Instances in your VPC and slap an EC2 Savings Plan on it.
The Verdict: Serverless Is Dead, Long Live Lambda
So, is Lambda leaving its serverless origins?
If you define “serverless” by the rigid technical dogmas of 2014 — stateless, single-concurrency, 15-minute event handlers — then yes, Lambda has left the building.
But if you look at it through a strategic lens, AWS is doing something much smarter. They realized that developers never actually cared about religious purity around “functions.” Developers cared about abstraction — writing business logic without managing undifferentiated heavy lifting, while getting a billing model that matches their workload.
Lambda is no longer a Functions-as-a-Service (FaaS) product. It has evolved into AWS’s universal compute abstraction layer. Whether you are processing an S3 event, serving a global Next.js app, orchestrating a month-long AI agent workflow, spinning up an isolated Linux sandbox for untrusted code, or saturating Graviton4 EC2 instances at enterprise scale — AWS wants your entry point to be Lambda.
The name on the console button still says “Lambda.” Underneath, it’s a whole new offering from AWS.
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article