Serverless in Practice: Where It Saves Money and Where It Quietly Doesn't
The cost curve crosses at a knowable point
Per-invocation pricing is dramatically cheaper than a running server at low and spiky volumes, and dramatically more expensive at sustained high volume. The crossover for a typical API workload tends to arrive somewhere in the region of continuous moderate traffic — at which point a modest always-on container costs less than the equivalent function invocations. Model your own crossover with real request volumes and durations before committing; it is arithmetic, not ideology, and it takes an hour.
Where serverless is clearly the right call
Event-driven glue: reacting to file uploads, queue messages, database changes, scheduled jobs. Sporadic internal tools and admin utilities. Webhook receivers. Traffic with extreme peaks — a campaign, a ticket release, a monthly billing run — where provisioning for peak would waste capacity all month. In these cases the operational savings compound with the compute savings, because there is no cluster to patch, scale or monitor.
Where it becomes a burden
Long-running processes, heavy computation, workloads needing large memory footprints, and services with strict tail-latency requirements where cold starts are unacceptable. Also applications with many chatty internal calls, where per-invocation cost and per-hop latency multiply. And anything with a heavy local development story — teams lose real productivity when running the system locally requires emulating half a cloud provider.
Cold starts are manageable but not free
Runtime and package size are the main levers, and modern runtimes have improved substantially. Provisioned concurrency solves the problem and reintroduces the always-on cost you were trying to avoid, so use it selectively on the user-facing paths that need it rather than everywhere. Measure at the percentile your users experience — a median that looks fine can hide a 99th percentile that is generating support tickets.
The hidden costs are in the surrounding services
Compute is often the smallest line. API gateways, per-request logging, tracing, queues, and the data transfer between all these components add up, and each is priced per unit in a way that scales with traffic. Teams frequently discover that logging costs more than the functions. Set log retention deliberately, sample traces, and check the full bill by service rather than assuming compute is the story.
Mix deliberately
The strongest architectures we build use containers for the steady core of an application and functions for the event-driven edges. That gets predictable cost and performance where traffic is constant, and elasticity where it is not. Choosing one model for the whole system because it is the house style is how organisations end up paying a premium in one half of their workload to keep the architecture diagram tidy.
Have a project that needs this kind of thinking?
Let's talk through what you're building — free consultation, no commitment.
Get in Touch