Serverless hosting is cheaper for low-to-moderate, spiky traffic; traditional hosting (a VM or dedicated instance) is cheaper once traffic is high and steady. The crossover generally sits somewhere around 500,000 to 1 million requests a day for a typical API workload — below that, you're usually paying for idle server time under traditional hosting; above it, per-request serverless billing starts to cost more than a fixed-price server doing the same job.
Here's what that actually means in dollars, and how to tell which side of the line your web application or API sits on.
Why This Question Gets Asked Too Late
Most teams don't choose a hosting model deliberately — they inherit whatever a tutorial, a starter template, or a previous developer defaulted to, and only revisit the decision once a bill spikes unexpectedly or a server starts timing out under load. That's backwards. Hosting model is an architecture decision, not an afterthought, and it's far cheaper to get right at the start than to migrate later once application code has quietly grown dependent on assumptions (always-on state, long-running connections) that only one of the two models supports well.
The Core Difference, in Practice
Traditional hosting means renting a server (a VM, a dedicated instance, a droplet) that runs continuously, whether it's handling requests or sitting idle. You pay a fixed monthly rate regardless of usage. Serverless — AWS Lambda is the dominant example — runs your code only when a request comes in and charges per invocation and per millisecond of execution. There's no server to patch, size, or pay for while it's idle, but the pricing model flips from fixed to variable.
What Each Model Actually Costs
| Scenario | Traditional hosting | Serverless (AWS Lambda) |
|---|---|---|
| Low traffic, spiky (a few thousand requests/day) | ~$4–$15/month, but paying for idle capacity most of the day | Often $0–$5/month — Lambda's free tier covers 1M requests and 400,000 GB-seconds monthly |
| Moderate, steady traffic (~1M requests/month) | ~$15–$30/month on a small reserved instance | Roughly $5–$10/month once past the free tier |
| High, sustained traffic (100M+ requests/month) | Cost stays flat as traffic grows within instance capacity | Cost scales linearly per request and can exceed an equivalent server's cost |
Per AWS's own published pricing, beyond the free tier Lambda charges $0.20 per million requests plus $0.0000166667 per GB-second of compute — numbers that make individual requests essentially free at low volume, but that add up in a genuinely linear way as volume climbs, unlike a server's flat monthly rate. The same pattern holds on competing platforms: Google Cloud Functions' pricing page and Microsoft's Azure Functions consumption plan use the same per-invocation, per-compute-second model, so the traditional-vs-serverless math below applies regardless of which cloud you're on.
When Serverless Is the Right Call
- Traffic is unpredictable or spiky — a marketing campaign, a seasonal business, or an internal tool used a few times a day
- You want to avoid managing server patching, scaling, and capacity planning entirely
- Your workload is naturally event-driven: processing an upload, responding to a webhook, running a scheduled job
- You're pre-product-market-fit and don't yet know what your real traffic pattern will look like
When Traditional Hosting Is the Right Call
- Traffic is high and consistently steady — you're not paying for idle capacity because there isn't much idle time
- You need long-running processes (background jobs over 15 minutes, persistent WebSocket connections) that serverless platforms aren't built for
- Cold starts (the 100ms–2s delay when a serverless function spins up after being idle) are unacceptable for your latency requirements
- You want predictable, flat monthly costs for budgeting rather than usage-based variability
The Cost Nobody Budgets For: Operational Time
The sticker-price comparison above misses the biggest real-world factor: engineering time spent on operations. A traditional server needs patching, scaling configuration, and monitoring setup — hours that have a real cost even when the server bill itself looks cheap. Serverless removes most of that operational burden by design, which is often worth more than the per-request pricing difference either way. If your team doesn't have dedicated DevOps capacity, that operational cost should weigh at least as heavily as the raw hosting bill — see our cloud & DevOps work for what ongoing infrastructure management typically involves either way, and our custom software development team factors hosting model into the initial architecture rather than bolting it on after the build is finished.
What This Looks Like for a Real Application, Not Just a Function
Most of the comparisons above talk about a single function or endpoint, but few real applications are that simple. A typical business app is a mix: some parts (webhooks, scheduled jobs, image processing) are naturally event-driven and suit serverless well; others (the main API serving steady, predictable traffic) may suit a container or server better. Treating the whole application as one binary choice is usually the wrong frame — the more common and more cost-effective pattern is splitting the architecture by workload type, running the spiky parts serverless and the steady parts on a container or reserved instance, rather than forcing one hosting model to fit everything.
A Middle Path: Containers
Between the two sits container hosting (AWS Fargate, Google Cloud Run) — you get some of serverless's operational simplicity (no server patching) with more predictable pricing than pure per-request billing, and none of Lambda's execution-time limits. For workloads that have outgrown serverless's sweet spot but don't yet justify a dedicated server, this is frequently the right answer, and it's worth asking any vendor why they didn't propose it before assuming the choice is binary.
How Pingal IT Approaches Hosting Decisions
We default new, low-traffic projects to serverless or containers, not a dedicated server, because most new products don't know their real traffic pattern yet and a $0–$10/month starting bill beats provisioning capacity for traffic that may never arrive. We move clients to dedicated or reserved infrastructure once traffic is genuinely steady and the math clearly favors it — and we tell clients directly when we see a serverless bill creeping toward what a reserved instance would cost, rather than leaving it running on the more "modern" option out of inertia. This has meant, more than once, telling a client their bill would go down by moving off the architecture we originally recommended — which is a harder conversation than staying quiet, but it's the one that keeps the relationship honest past the first invoice.
Checklist: Which Model Fits Your Workload?
- Is your traffic steady or spiky? Steady favors traditional hosting; spiky favors serverless.
- Do you have any process that needs to run longer than 15 minutes continuously? That rules out standard serverless functions.
- Is cold-start latency (up to ~2 seconds on a cold function) acceptable for your use case?
- Do you have in-house DevOps capacity, or would you rather pay slightly more to avoid managing servers?
- Model your actual request volume against both pricing structures before committing — don't guess
- If your application is a mix of workload types, have you considered splitting hosting models by workload rather than picking one for everything?
If infrastructure costs are already a concern beyond just hosting model, our cloud cost optimization guide covers the broader picture, and our case studies show real infrastructure decisions across recent projects.
FAQs
Is serverless always cheaper than traditional hosting?
No — only below a certain traffic threshold, generally in the range of 500,000 to 1 million requests per day for typical workloads. Above that, the per-request cost of serverless can exceed a comparably-sized traditional server's flat rate.
What are cold starts and do they matter?
A cold start is the delay (roughly 100ms to 2 seconds, depending on runtime) when a serverless function spins up after being idle. It matters for latency-sensitive applications but is often invisible for internal tools, webhooks, or async processing.
Can I run a full web application on serverless?
Yes — modern approaches package an entire framework (Flask, Express, Django) into a Lambda function behind an API Gateway, which can run a standard web app for a few dollars a month at low traffic. It's a legitimate pattern, not just for small utility functions anymore.
What's the biggest hidden cost of traditional hosting?
Paying for idle capacity. A server provisioned for peak traffic sits mostly unused the rest of the time, and you pay the same flat rate regardless — this is exactly the inefficiency serverless pricing is designed to eliminate.
What's the biggest hidden cost of serverless?
Underestimating growth. A workload that starts small and scales past the crossover point can end up costing more per month on serverless than the equivalent server would have, if nobody re-evaluates the hosting model as traffic grows.
Should a brand-new product start on serverless or a server?
Serverless or containers, in most cases — you don't yet know your real traffic pattern, and starting with near-zero fixed cost avoids paying for capacity you may not need. Revisit the decision once traffic is established.
