Which AWS Lambda do you actually need?

Lambda was one thing for over ten years. AWS celebrated its tenth birthday in 2024, and through all of it the basic idea held still: a function that runs when an event shows up. Features piled up around that idea. The idea itself didn't move.

Then it did. Managed Instances landed in November 2025, durable functions a month later, MicroVMs in June 2026 and Web Functions in October. Somewhere in there the original Lambda was renamed "Event Functions" so you could tell it apart from the new ones, which says something about how confusing it had gotten.

I wasn't building anything. I just watched the announcements show up one after another and never got around to understanding them. I knew Lambda as the thing that runs when an event shows up, and that was it. So I finally sat down with the docs and sorted them out. This is what came out.

Three kinds of Lambda

An Event Function is the one you know. Something happens, your code runs for up to 15 minutes, then it's gone. You pay per request and per GB-second, and when nothing's happening you pay nothing.

A Web Function is for when what you've actually got is a web server. Your Node.js app listens on a port, Lambda puts an HTTPS endpoint in front of it, and a single environment handles lots of requests at once.

A MicroVM is a small sealed computer for one user or one job. It can live for up to 8 hours and suspend itself when idle. AWS pitches it at code you don't trust, like something a user uploaded or an AI wrote.

Which one for which problem

Two questions got me most of the way. How long does one piece of work live? And who decides how much capacity is running: AWS per request, you renting EC2, or you per environment? Here's where they landed me.

If your problem is...	Reach for	Watch out for
Short work triggered by an event or API call	Event Function	Nothing. It's the default.
A whole web app or API you already run as a Node server	Web Function	Node.js only.
One isolated computer per user, or code you don't trust	MicroVM	You manage each one's lifecycle.
Work that waits for humans or runs past 15 minutes	Durable functions	Your code has to survive replay.
Steady, heavy traffic and a bill you want lower	Managed Instances	It bills while idle.
Cold starts hurting latency	SnapStart, then provisioned concurrency	SnapStart skips Node.js.

Durable functions are the one that adds a capability rather than trimming a bill. You write ordinary code with steps and waits. Lambda saves your progress, and a wait costs no compute, so a run can sit there for up to a year. The price is replay: after every pause your code runs again from the top, skipping finished steps, so anything with side effects has to live inside a step. If your workflow is mostly your own code, durable functions fit. If it's mostly gluing AWS services together, or someone wants a diagram, AWS's own guidance points to Step Functions.

Managed Instances is for when per-request pricing has stopped being a good deal. Traffic is steady and heavy, so you'd rather run on EC2 you can put a Savings Plan on. Lambda runs your functions on instances in your account, and one environment takes many requests at once. AWS adds a 15% fee on top of the EC2 price, and your EC2 discounts don't apply to that fee.

For cold starts, try SnapStart first. It snapshots the function after init, when you publish a version, and new environments start from the snapshot. It works for Java, Python 3.12 and later, and .NET 8 and later. It's free for Java and doesn't cover Node.js. If it isn't fast enough, provisioned concurrency keeps environments warm, and you pay for them whether anyone calls or not.

Where the idle money hides

I'd slow down here. A plain Event Function is the cook who turns up when the bell rings and goes home afterwards, so idle costs nothing. Nearly everything else on the list gets you something by giving that up.

Provisioned concurrency is cooks standing at the stove: ready instantly, and on the clock. Managed Instances doesn't scale to zero. By default it launches three instances and keeps at least three environments, so the kitchen's open before the first order. A Web Function bills CPU only while it's working, but it charges for memory the whole time an environment exists, quiet stretches included. A running MicroVM is a hotel room with the lights on. Suspend it and you pay for the snapshot. Terminate it and you pay nothing, so the idle policy is the cost control, not a nice-to-have.

None of that is a reason to avoid them. It's a reason to check before you pick one. A function that's busy ten hours a month doesn't belong on always-on capacity. Pay for idle where you've measured the latency you're protecting, or the steady load that covers it. Otherwise don't.

What I'd skip at first

Layers, extensions, container images, response streaming and the edge options are all real, and you'll find each one when its problem finds you. Containers when your dependencies outgrow a 250 MB zip. Streaming when responses are big or arrive in pieces.

Function URLs get one line. They give an Event Function a free HTTPS address, which is plenty for a webhook or a small API. If you catch yourself building a whole web app on one, go look at Web Functions.

What I'd do

Write the job down in one sentence, then walk the table. Most of the time it's an Event Function. When it isn't, it's usually one of three things: it's a web app, it's long or it waits, or the traffic is steady enough that the math changes. MicroVMs only make sense if you're handing out computers to other people's code.

I haven't built with any of the newer ones. They're months old, and what I've said about them comes from the docs, not from production. Check the current docs for runtime and Region support before you bet on any of them.

---

Sources: AWS Lambda Developer Guide: What is Lambda, Managed Instances, Durable functions, Durable functions or Step Functions, SnapStart, Web Functions, MicroVMs, Lambda quotas, AWS News Blog: AWS Lambda turns ten