AWS Lambda Still Matters in 2026: Glue, Burst, and Honest Trade-offs

I have spent most of my career running things that boot. Bare metal, VMs, containers, Kubernetes — boxes that come up, hold state, and need somebody to think about their lifecycle. AWS Lambda is the opposite of that mental model, and for a long time I treated it the way a lot of old-school infrastructure people treat it: useful for toy apps, fine for a Slack bot, not a serious tool.

I was wrong about it, and I have been wrong about it for a while.

Lambda turned eleven in November 2025. The 2026 version of the service has very little in common with the 2014 one I first dismissed, and the trade-offs are different enough that I want to write down where I’ve actually landed, including the parts cloud-native evangelists under-sell and the parts on-prem die-hards refuse to acknowledge.

What Lambda actually is, stripped of marketing

Lambda runs your code in a managed execution environment in response to an event. You hand AWS a zip file or a container image, you point an event source at it (HTTP request, queue message, S3 upload, EventBridge schedule, anything that emits an event in the AWS world), and the service spins up an isolated environment, runs your code, and tears it down again.

You don’t pick an instance type. You don’t manage an OS. You don’t patch anything. You pay per invocation plus per GB-second of memory allocated, billed at 1 ms resolution. No idle cost.

That’s it. The rest is plumbing.

The mental shift is that the unit of deployment is a function, not a server. For someone who has spent twenty years thinking in terms of nodes, this took me longer than I want to admit to internalise.

Where it genuinely earns its keep

I am not a cloud-native purist. I run an on-prem RKE2 cluster and a media server on a Raspberry Pi 4 at home, and I will happily put a workload on a long-lived VM when that’s the right call. But Lambda earns its keep in a handful of categories that are, in my experience, under-rated by infrastructure people:

Glue code that runs on events you don’t control. S3 uploads, DynamoDB streams, SQS messages, EventBridge rules, SNS topics, IoT ingestion. The “I need a thing to fire when this other thing happens” problem is exactly what Lambda is for. The alternative is a long-lived consumer process you have to monitor, scale, and patch, and which idles 99% of the time. Lambda just bills you for the 1%.

Scheduled jobs that used to live in cron. EventBridge Scheduler plus a Lambda function is the cleanest replacement I’ve found for the “one server somewhere whose only job is to run cron” pattern. No box to keep alive, no logs to rotate, no SSH key to rotate, no surprise when the box dies and nobody noticed for three weeks.

Bursty workloads with unpredictable shape. Image resizing, PDF generation, webhook receivers, OAuth callback handlers, anything where traffic is shaped like spikes rather than a steady line. Lambda’s scale model — thousands of concurrent executions within seconds, no pre-provisioning — is genuinely hard to replicate on container platforms without a lot of HPA and Karpenter tuning.

Real-time stream processing. Kinesis and DynamoDB Streams have first-class Lambda integration. You write the transformation, AWS handles the parallelism, checkpointing, and retry semantics. The alternative is a Flink cluster, which is a wonderful tool and a considerably more expensive operational commitment.

Web backends for small-to-medium services. API Gateway plus Lambda is a perfectly viable production architecture for backends that don’t need WebSockets, don’t need long-running connections, and don’t have absurd cold-start sensitivity. I am not telling you to put your trading platform on it. I am telling you that the internal CRUD API your platform team keeps asking for is probably a better fit for Lambda than for a 24/7 ECS service.

What changed in 2025-2026

The cold-start argument is the thing people keep recycling from 2018 benchmarks. It’s mostly out of date now. Three changes matter:

SnapStart, especially for Java and Python. SnapStart snapshots the initialised execution environment after the runtime and your code’s init phase have run, then restores from that snapshot on cold invokes. For JVM-based Lambdas, this turns 5-10 second cold starts into sub-200 ms. Python SnapStart shipped in late 2024 and lands similar improvements. If you’re still avoiding Lambda for Java because of cold starts, you’re solving last decade’s problem.

Graviton3 (arm64) as the default. AWS now quotes up to 34% better price/performance versus x86 Lambdas, and for most workloads the migration is one line of CloudFormation or Terraform. If your function is in Python, Node, Go, or Java and you haven’t flipped it to arm64 yet, you are leaving money on the floor.

Response streaming. Lambda can now stream a partial response back to the caller through API Gateway, CloudFront, or a function URL before the function has finished executing. The practical use case is LLM proxies and any long-running aggregation that wants to TTFB-first rather than wait-for-complete. This used to be the canonical “this is why we can’t use Lambda” argument. It isn’t anymore.

Managed instances for steady-state traffic. Announced at re:Invent 2025. Lambda functions can now be backed by managed long-lived instances when traffic is steady, with AWS handling the lifecycle and you keeping the Lambda programming model. This blurs the line between Lambda and Fargate in a useful way — the function model survives, the cold-start tax disappears for steady traffic, and you don’t have to manually configure provisioned concurrency.

The honest comparison

Here’s the table I actually use when I’m deciding where a workload should live. None of these are “best” in the abstract; they win at different things.

The two numbers I keep coming back to are idle cost and steady- state cost per request. Lambda wins decisively on the first and loses decisively on the second. The break-even point depends on memory and request shape, but a useful rule of thumb: if your service sustains more than roughly 1,000 requests per second for 24 hours a day, you are paying more for Lambda than for an equivalently-sized Fargate task or EC2 box.

Where Lambda will bite you

I’d rather tell you these now than have you discover them at 3 AM.

Cold starts still exist for languages that don’t have SnapStart (or that have it but you haven’t turned it on), for VPC-attached functions on cold ENIs, and for functions you haven’t touched in a while. They’re shorter than they used to be. They are not gone.

The 15-minute execution limit is a hard wall. No exceptions, no “please sir can I have some more”. If your job might take longer than that — batch processing, large data exports, anything involving slow external APIs — Lambda is the wrong shape. You want Step Functions orchestrating multiple Lambdas, or you want Fargate.

Cost at scale is real. I have seen teams move a steady-state workload from EC2 to Lambda for “scalability” reasons and triple their bill. Lambda’s pricing is wonderful for spiky traffic and brutal for flat traffic. Run the math before you migrate.

Vendor lock-in is the highest in AWS. EC2 you can lift-and-shift. Containers you can move to any cloud or on-prem. Lambda functions are written against AWS event shapes, AWS SDK clients, AWS IAM, and the Lambda runtime contract. Moving them to Cloud Functions or Azure Functions is a rewrite, not a migration.

Local development is awkward. SAM CLI and LocalStack help. They do not eliminate the fact that the production environment is genuinely different from your laptop. You can dev-loop a container locally in ways you cannot dev-loop a Lambda.

Observability is its own ecosystem. CloudWatch Logs, CloudWatch Metrics, X-Ray, and increasingly OpenTelemetry. None of it is bad — all of it is different from the Prometheus + Grafana + Loki stack you probably already run for your containers. Plan for the second observability pipeline.

My personal heuristic

The way I decide, in two questions:

1. Does this workload have meaningful idle time? If yes, Lambda is on the table. If it’s running flat-out 24/7, put it on a container or VM and stop paying the Lambda premium.

2. Is it event-driven by AWS services I already use? S3, SQS, EventBridge, DynamoDB Streams, Kinesis — Lambda’s integration with these is so tight that fighting it feels foolish. If the event source is external (Kafka I run myself, GitHub webhooks, anything HTTP), the case for Lambda is weaker and a small Go service on Fargate is often cleaner.

I also use Lambda Power Tuning — the open-source step-function- based tool — on anything I deploy. It runs your function across a matrix of memory configurations and picks the price/performance sweet spot. Lambda’s pricing makes “more memory” sometimes cheaper than “less memory” because CPU scales with memory and shorter execution beats lower allocation. Power Tuning surfaces that automatically and it has paid for itself the first time I ran it on every account I’ve managed.

Where I’ve landed

I like Lambda when it fits. I don’t like it when it’s used as a hammer for problems that aren’t nails — long-running services, steady high-RPS APIs, anything that wants a real debugger and a tight dev-loop.

The 2026 version of the service is materially better than the one I dismissed a decade ago. SnapStart, Graviton3, response streaming, and the managed-instances announcement at re:Invent 2025 have closed enough of the historical gaps that “I don’t use Lambda because cold starts” is no longer a serious technical objection — it’s nostalgia.

But it’s still a tool, not a religion. The fact that AWS would love to put every workload on Lambda is, by itself, a reason to be clear-eyed about when the model fits and when it doesn’t.

Question for you

What’s the workload you keep meaning to put on Lambda but haven’t, and what’s actually stopping you? Cold starts? Cost? Lock-in? The fact that your team would rather run another container?

I’m curious where the real friction is in 2026, because the technical objections from 2018 mostly aren’t the answer anymore.