What Is AWS Lambda in 2026? 5 Flavors Explained

I've been building with AWS Lambda for almost seven years now, and for most of that time, Lambda looked pretty much the same. You wrote a handler, wired it to an event, and let AWS worry about everything underneath, which made it the serverless poster child, for better or worse.

Then, in under two years, Lambda started running on managed EC2 instances, booting isolated microVMs, checkpointing workflows that can pause for months and, as of October 2026, acting as a full web server.

The word "Lambda" no longer tells you much about what you're getting, and the word "serverless" tells you even less. Somewhere along the way, serverless became a bit serverful, and honestly, I'm all for it.

In this post you will learn how AWS Lambda grew from one event-driven service into five compute flavors, when to use each, what the new Web Functions bring, and why the serverless name has outgrown its meaning.

Serverless in 2026: Looking Back at My 2024 Prediction

Back in July 2024, I wrote a reflection on the state of serverless and made a prediction:

"The serverless future will be bright; serverless is not going anywhere, and it's not dying." - Reflecting on Serverless, July 2024

Two years later, I stand by that prediction. Serverless isn't dead, but it took a path I didn't expect at all, and we have AI and AWS customers to thank for that.

The Many Flavors of AWS Lambda in 2026

When I count the distinct ways to run code under the Lambda brand today, I get five, and each one targets a different kind of workload with a different cost model. Let's start with the one we all know.

Classic AWS Lambda Functions: The Event-Driven Workhorse

The classic Lambda function is still here, and it's still the best tool I know for event-driven architectures. An HTTP request through API Gateway, an SQS message, a database stream record or any other event source triggers your handler, and Lambda runs it in an execution environment, a small isolated sandbox that holds your code and handles exactly one request at a time. Lambda scales out by adding environments as requests come in, and when the traffic stops, you pay nothing. The classic function also comes with a 15-minute limit and the cold starts we all love to complain about, which happen when Lambda has to create a new environment before it can serve a request.

Over the years, the classic function has quietly gained features such as function URLs for a quick HTTPS endpoint without API Gateway, response streaming, and tenant isolation mode, which gives each tenant its own execution environments in SaaS workloads. Tenant isolation mode isn't the whole isolation story, though, as I discuss in my post on whether Lambda tenant isolation mode is enough for SaaS. These are improvements to the same model rather than new flavors, so I won't count them separately. If you want to build classic functions the right way, my AWS Lambda handler cookbook repository shows all the best practices in one working project, and my AWS Lambda cookbook blog series explains them one by one, starting with logging.

AWS Lambda Durable Functions vs Step Functions: Workflows in Code

Lambda durable functions arrived at re:Invent 2025, and they solve a problem that used to send you straight to Step Functions. You write a multi-step workflow as regular code in Python, TypeScript or, since April 2026, Java, and Lambda checkpoints the progress between steps. The function can suspend while it waits for a manager to approve an order or for an external callback, for up to a year, without paying for idle compute, and then resume from its last checkpoint. It's still the Lambda programming model, but the execution has stretched from minutes into months, which makes it a natural fit for AI workflows that wait on slow models or on humans in the loop. Step Functions still has its place when you want a visual workflow or direct integrations with AWS services without writing code, but if your team prefers to express workflows in code, durable functions are now the more natural choice.

AWS Lambda Managed Instances: Lambda on Managed EC2

Lambda Managed Instances tackle a different pain: cost at scale. Your function code, event sources and IAM permissions stay the same, but the code runs on managed EC2 instances. You define the instance characteristics and scaling settings, and AWS provisions and operates the instances for you, handling patching, routing and scaling. Your function also runs inside a VPC by default. Each execution environment handles multiple concurrent invocations, and what that demands of your code depends on the runtime. Python gives each invocation its own OS process, so invocations stay isolated by design, while Node.js, Java and .NET run them as threads inside a single process, which means thread-safe code and careful handling of global state. The pricing moves from per-millisecond duration to requests plus EC2 pricing and a 15% management fee, so Compute Savings Plans, which are AWS discounts for committing to a fixed hourly spend over one or three years, apply as well.

Managed Instances are designed for high, steady traffic, such as a busy API that serves requests around the clock, where the classic Lambda duration bill keeps growing. The catch, as I covered in my Lambda Managed Instances impressions and tradeoffs post, is that they don't scale to zero, so you pay for a baseline of three execution environments even when nobody calls your function.

AWS Lambda MicroVMs: Isolated Sandboxes for the Agentic Era

Lambda MicroVMs are the flavor that feels the least like a classic Lambda function and the most like a product of its time. Each MicroVM runs on Firecracker, the same virtualization technology behind classic Lambda invocations, and gets its own kernel, memory and disk with no sharing between sessions. It keeps its full memory and disk state for up to 8 hours, suspends when idle so you don't pay for compute while it sleeps, and resumes on demand through its own dedicated URL. Billing is per second of vCPU and memory while it's awake, plus charges for snapshot reads, writes and storage. That's exactly what you need to run code that an AI agent or an untrusted user wrote, whether it's a coding assistant sandbox, a data analysis job or a CI pipeline step. I liked it enough to build an open-source CDK construct for Lambda MicroVMs in Python that packages your app, sets up least-privilege roles and produces a snapshotted VM image.

AWS Lambda Web Functions: Express and Fastify Without an Adapter

The fifth flavor launched in October 2026, and it's the one I'm most excited about.

Lambda Web Functions turn Lambda into a web server. Instead of writing a handler that receives an API Gateway event, you write a regular Node.js HTTP server with Express, Fastify, Hono or plain Node, and Lambda routes HTTPS traffic straight to it. To appreciate why this matters, look at my AWS Lambda MCP cookbook template, where I had to add the AWS Lambda Web Adapter as an extension layer, run a Starlette app behind uvicorn and put API Gateway in front of it, all to make a function behave like a server. With Web Functions, the server is the function: no extension layer, no adapter, and no ECS cluster just to host a web app.

At launch, Web Functions support only Node.js 24 on Arm64, so Python developers like me will have to wait. Each environment gets 2 vCPUs and 2 GB of memory and serves many requests at once, 64 by default and up to 128, while Lambda tunes the actual number dynamically, and each request can run for up to 15 minutes. Every deployment creates an immutable revision that you can roll back to, and a VPC is optional rather than required.

The pricing is where you need to pay attention. You pay for requests and for active CPU time, so time spent waiting on I/O costs very little, but memory is billed for as long as an environment exists, including the idle time between requests. The good news is that Web Functions do scale to zero, so when traffic stops, Lambda removes the environments and the memory bill stops with them, at the price of a cold start on the next request. The AWS team covers endpoints, multi-Region routing and authentication in their Web Functions launch blog and the Web Functions developer guide, so I won't repeat it here.

There's one mindset shift you can't skip, though. Because one environment serves dozens of requests at the same time on a single Node.js event loop, request data stored in global variables can leak between concurrent requests, CPU-heavy or synchronous code blocks every other request in that environment, and unbounded caches eat into the shared 2 GB. The libraries and patterns you built for classic Lambda, which assume one request per environment and an event-based handler, don't fit here either, and any native dependency has to be built for Arm64. This is just a regular web server, so treat it like one, with request-scoped state, async I/O and the same discipline you'd apply on any Node.js server.

Scaling also behaves differently, because Lambda adds environments ahead of demand, but once you hit your scaling limits, extra requests get an HTTP 429 instead of waiting in a queue. The upside of being a regular web server is portability. If you run a Node.js service on Fargate or ECS with nginx in front of it today, that same server code can move to Web Functions with very few changes and back to a container tomorrow, although the deployment, observability and IAM wiring around it will need to be redone in either direction.

Here's my honest take: I wouldn't even call this a Lambda. It's a managed, auto-scaling web server that happens to live under the Lambda brand, and the same goes for MicroVMs. I don't mean that as criticism, because it's the abstraction many of us have been hacking together with adapters for years, and now it's a first-class product.

Which AWS Lambda Flavor Should You Use?

Now that we've covered all five flavors, choosing between them is simpler than it looks. Start from your workload, find the row that describes it, and you have your flavor.

If two rows fit, let cost decide. Classic and durable functions win when traffic is spiky or low, while Managed Instances win when traffic is steady enough to keep environments busy.

What About Containers? Lambda vs Fargate, ECS and EKS

Where does all of this leave containers? Right where they were. Lambda and containers are two different ecosystems, each with its own tooling, deployment model, observability and operational know-how, and not every team has the capacity to master both. If your team already runs on ECS, Fargate or Kubernetes through EKS, with its own pipelines and platform expertise, none of these Lambda flavors is a reason to migrate, and the same is true in reverse for a team that knows Lambda inside out. As I wrote in 2024, "Choose the solution that fits the problem requirements and constraints the BEST, period," and your team's knowledge and experience are part of those constraints. Having more options is great, up to a degree, since it also makes choosing harder.

Is Serverless Dead? What AWS Lambda Means in 2026

"I'm an AWS Serverless Hero, but maybe I should be called a Serverful Hero, or a Managed Hero."

That thought kept coming back to me while writing this post, because the flavors above don't look very serverless anymore. So, is serverless dead? Not at all, but it did change its face. What we care about has never been the absence of servers. We care that someone else manages them, that they scale, ideally down to zero, and that we pay only for what we use, so "managed, scale to zero, pay for what you use" is a far more accurate name, even if it will never fit on a conference t-shirt.

As I mentioned earlier, this new face came from two places. The first is AWS customers, who kept asking for fixes to Lambda's two classic pains. Cold starts, which I covered in my post on what cold starts are and how to fix them, are now a tuning decision rather than a dead end, thanks to SnapStart and fast runtimes like Rust, and cost at steady scale has an answer in Managed Instances. I applaud AWS for turning so many of those requests into real products.

The second is AI. With the old pains largely addressed, the focus has shifted to building AI on top of a mature serverless foundation, which is exactly where MicroVMs, durable functions and Amazon Bedrock AgentCore, AWS's managed runtime for AI agents, come in. My own blog analytics tell the same story, with my agentic AI posts outpacing my serverless ones, and I spend most of my days learning and writing about AI anyway. Serverless changed its face, and so did I. Maybe I'm an AI Hero after all.