Quick take
Lambda is useful. The hype around it isn’t. Know the five questions that tell you whether it fits your workload, or walk away.
I’ve been using AWS Lambda at the fintech startup for a few specific tasks – processing incoming financial data events, running lightweight transformations on S3 uploads, firing off notifications when certain market thresholds trigger. It works well for those. Really well.
What I haven’t done is rewrite our entire backend in Lambda functions. And if you listen to the conference circuit right now, that apparently makes me a dinosaur.
The hype is exhausting
Lambda has been generally available for about a year. In that time, the narrative has gone from “interesting compute primitive” to “servers are dead, long live serverless.” I’ve watched otherwise reasonable engineers pitch rewriting stable, well-understood services into chains of Lambda functions because… the future? Because ops is hard and this makes it someone else’s problem?
Ops doesn’t disappear because you stopped managing EC2 instances. It changes shape. You still need to think about permissions, packaging, deployment, monitoring, and failure modes. You just think about them differently. Anyone who tells you Lambda eliminates operational complexity is selling something.
Where Lambda actually earns its keep
Event-driven, short-lived, bursty. That’s the sweet spot.
At the fintech startup we use it for processing webhook payloads from data providers. A payload arrives, Lambda transforms it, writes to DynamoDB, done. The function runs for a few hundred milliseconds and costs nearly nothing. Running a dedicated service for that would be waste.
S3 triggers are another clear win. File lands, thumbnail gets generated, metadata gets extracted. No process sitting idle waiting for uploads that might come once an hour or once a second. Lambda scales both directions without intervention.
Glue logic between services. Translating payloads, orchestrating a couple of API calls, reformatting data. The kind of thing that doesn’t justify a full service but still needs to run somewhere. Lambda is perfect for this.
Prototyping. When I’m validating an idea and the last thing I want is to provision infrastructure, Lambda lets me focus on behavior. Ship the function, see if the concept works, decide later if it needs a real service behind it.
Where it falls apart
The five-minute execution limit is real. I’ve seen teams try to break long-running jobs into chains of Lambda invocations with S3 or SQS as coordination layers. Congratulations, you just built a worse version of a worker process. With more failure modes.
Cold starts. If your function hasn’t run recently, the runtime initializes from scratch. That adds latency – sometimes hundreds of milliseconds, sometimes more depending on the runtime and package size. For internal event processing, nobody cares. For a user-facing API where you promised sub-100ms responses? That’s a problem you can’t hand-wave away.
Statelessness is a feature until it isn’t. Every invocation starts clean. You can store state in DynamoDB or S3, but now you have added network round-trips and consistency concerns to what was supposed to be a simple function. If your logic needs in-memory state or connection pooling, Lambda will fight you the entire way.
Cost math flips at steady load. Lambda pricing is great when traffic is spiky and idle time dominates. When traffic is steady and predictable, dedicated compute is cheaper. I’ve run the numbers for our heavier workloads at the fintech startup. Reserved instances win by a wide margin once utilization stays above 30-40%.
The question I actually ask
Before putting anything on Lambda, I run through five questions:
- Can it finish in under two minutes without contortions?
- Does it tolerate variable latency on cold starts?
- Is the traffic pattern spiky or unpredictable?
- Can it run stateless without bolting on coordination infrastructure?
- Is it simple enough that debugging through CloudWatch logs won’t make someone quit?
Mostly yes? Lambda. More than one firm no? Traditional service. This isn’t complicated.
The right architecture is boring
The best setup I’ve built combines both. Lambda handles event processing, glue, and bursty workloads. Go services on EC2 handle the steady, latency-sensitive, stateful work. They coexist fine. There’s no ideological conflict.
The “serverless everything” crowd treats this like a binary choice. It isn’t. It’s engineering. You pick the tool that fits the constraint. Sometimes that’s Lambda. Sometimes it’s a process on a server you manage. The goal is a system that works, not a system that impresses people at meetups.
Lambda is genuinely useful technology. I just wish the discourse around it matched the reality of what it’s good at instead of what people want it to be.