Denshin / Blog / Engineering
Serverless math: when Lambda is cheaper than a server, and when it isn’t
The actual math we use to choose between AWS Lambda and a server: the idle-cost floor, the requests-per-second crossover, cold-start billing, and the operational cost nobody puts in the spreadsheet.
Denshin Engineering · Engineering Team · 25 June 2026 · 3 min read
Every few weeks a founder asks us whether they should be "on serverless", usually because they read that it's either dramatically cheaper or a trap that bankrupts you at scale. Both stories are told with great confidence and neither is the whole truth. Here's the actual math we use to decide, and where it stops being free.
The number that makes serverless obvious
A small always-on server has a floor. An t3.small EC2 instance running around the clock costs roughly $15-18 a month before it serves a single request. That's the rent, whether you have ten users or zero. AWS Lambda has no rent: you pay per request and per millisecond of compute, and an idle function costs nothing.
For the workload most of our clients actually have (an admin panel, a B2B dashboard, an early-stage SaaS with spiky, unpredictable traffic), that changes the picture completely. When utilization is low, it isn't close: Lambda is dramatically cheaper, and it scales from zero to a traffic spike with no capacity planning on your part. You don't predict load. You don't pre-provision. You don't get paged because a box fell over.
This is why our default for new client work is Lambda plus DynamoDB. We've explained why the boring stack wins for most projects, and "the database bill is three dollars and nobody got woken up" is a big part of it.
Where serverless stops winning
The crossover is real and worth knowing, but it's workload-specific, not a universal threshold. To make it concrete: a widely-cited Trek10 analysis found that a short 100 ms, 128 MB request had to sustain on the order of 80 requests per second, around the clock, before a dedicated instance beat Lambda. Change the request duration or memory and that number moves. The point stands: below your crossover Lambda wins, and above it a continuously-busy machine starts to look cheaper.
A few other places the serverless story gets more complicated than the brochure:
- Cold starts have a price now. Since August 2025, Lambda bills the initialization (cold-start) phase too. Cold starts are typically under 1% of invocations, so for lightweight Node or Python functions it's usually noise, but for heavier Java or C# runtimes with slow startup, or very spiky low-traffic functions, it's worth measuring.
- Steady, predictable load. If your traffic is flat and high (a video transcoder running all day, a service pegged at constant load), a reserved instance or container is usually cheaper. AWS even shipped Lambda Managed Instances in late 2025 precisely for steady-state workloads that still want the serverless developer experience.
- Long-running and stateful work. Anything that needs to run for minutes, hold a persistent connection, or keep large state in memory fights the function model. Use the right tool.
The real question isn't "serverless or servers." It's "is my traffic spiky and uncertain, or flat and predictable?" Spiky and uncertain (which describes almost every product before product-market fit) points at serverless. Flat and high points at a server.
The cost nobody puts in the spreadsheet
Pure compute cost is the easy comparison. The one that actually moves the needle for a small team is operational cost: the hours you don't spend patching an OS, sizing an instance, configuring autoscaling, or getting paged at 2am. For a studio our size and the teams we build for, that's frequently worth more than the difference on the AWS invoice. Our front end sits on S3 and CloudFront for the same reason: it's boring, it's cheap, and it doesn't wake anyone up.
Our rule of thumb
Start serverless. It's cheaper while you're small, it scales without drama, and it removes a whole category of operational work from a team that should be building product, not babysitting servers. Watch the metrics. If a specific workload becomes steadily, heavily utilized, move that workload, not your whole architecture, onto something with a flat rate. Most products never reach that point. The ones that do can afford the migration by the time they need it.
Want a second opinion on your architecture before you commit to a bill? Send us the shape of your workload and we'll tell you, honestly, which way the math points.
Tags: Serverless, AWS, Lambda, Cloud Cost, Architecture
All posts · Work with Denshin