Serverless hosting tends to cost less for variable, spiky, or low-traffic workloads and more for consistently high-traffic ones, while traditional hosting offers more predictable performance without cold-start latency but requires paying for capacity whether it’s used or not. Neither wins the serverless vs traditional hosting comparison universally, and one of the most cited examples of this tradeoff comes from Amazon’s own engineering team choosing traditional hosting over serverless for a specific, high-scale workload.

That example matters because it cuts through a lot of the marketing noise around serverless being an unambiguous upgrade. This guide compares the two models on the two dimensions that actually drive most real decisions, cost and performance, with concrete numbers and a real case study rather than abstract tradeoffs, as part of the same DevOps and cloud solutions evaluation that should inform any hosting decision.

What Is Serverless Hosting?

Serverless hosting runs application code in provider-managed, ephemeral compute instances that scale automatically and are billed by actual execution time, with no servers for the development team to provision or maintain directly. AWS Lambda, Google Cloud Functions, and Azure Functions are the major examples, each charging based on requests and compute time consumed rather than for continuously running infrastructure.

What Is Traditional Cloud Hosting?

Traditional cloud hosting runs applications on virtual machines or containers that stay provisioned and running continuously, billed for the capacity reserved regardless of how much of it is actually used at any given moment. This includes standard EC2 instances, Azure VMs, or container-based hosting on services like ECS or a Kubernetes cluster, where the team retains more control over the runtime environment in exchange for taking on more of the operational responsibility.

Serverless vs. Traditional Hosting: Cost and Performance Compared

The pattern in this table is consistent with what most real cost analyses find: serverless economics favor unpredictability, while traditional hosting economics favor consistency. A workload that spends most of its time idle benefits from paying only for the moments it’s actually active. A workload running at consistently high volume often pays a premium for that same per-execution pricing model compared to a fixed-cost server handling the equivalent load.

Cost Model Deep Dive: Pay-Per-Execution vs. Fixed Capacity

When Serverless Is Cheaper

Serverless wins clearly for workloads with genuine idle time, an internal tool used a few hours a day, a webhook handler that fires occasionally, a batch job running once nightly. In these cases, AWS’s own Lambda pricing structure means you’re paying for milliseconds of actual execution rather than hours of a server sitting mostly idle, which can represent genuine, substantial savings for the right workload shape.

When Traditional Hosting Is Cheaper

Traditional hosting wins once traffic becomes consistently high enough that a workload is effectively “always on” in practice. At that point, per-execution serverless pricing accumulates against every single request around the clock, while a reserved or committed-use traditional instance spreads its fixed cost across that same continuous volume far more efficiently. The crossover point varies by workload, depending on request volume, execution duration, and memory allocation, but the general principle holds broadly across cost analyses from every major provider, and it’s worth modeling against your own specific numbers rather than relying on a generic rule of thumb from a blog post that was never analyzing your actual traffic pattern.

Performance Deep Dive: Cold Starts vs. Consistent Latency

Cost isn’t the only axis that matters, and performance characteristics differ just as meaningfully. Traditional hosting, once a server is running, delivers consistent latency; there’s no equivalent of a “cold start” penalty for a server that’s already up and handling requests. Serverless functions, by contrast, incur a real latency cost when a function hasn’t run recently and the platform needs to initialize a new execution environment before processing the request. For latency-sensitive workloads, a checkout flow, a real-time API, that inconsistency can matter more than the underlying cost difference, since a slow response has its own real cost in conversion and user experience, covered in more depth in our Core Web Vitals guide, where response time delays translate directly into measurable business impact regardless of what’s causing them underneath.

Real-World Case Study: When Prime Video Moved Away From Serverless

What Went Wrong

Amazon’s own Prime Video engineering team published a widely discussed case study on exactly this tradeoff. Their audio/video quality monitoring service, built as a distributed system using AWS Step Functions and Lambda, hit a hard scaling limit at around 5 percent of expected load, and the overall cost of the serverless building blocks was too high to justify at the scale they actually needed to operate.

What Changed

The team consolidated the distributed, serverless components into a single process running on Amazon ECS, eliminating the orchestration overhead and per-transition costs that Step Functions had been accumulating at high volume.

The Cost Reduction

The result was a 90 percent reduction in infrastructure cost for that specific service, alongside improved scaling capability, a striking number precisely because it came from Amazon’s own team using Amazon’s own serverless tools, not a competitor’s cost analysis with an agenda.

The Lesson, Not the Rule

The Prime Video team was explicit that this wasn’t a verdict against serverless generally, it was a decision specific to a workload with extremely high, continuous transaction volume where per-execution billing stopped making economic sense.

Example: Applying the Lesson to a Smaller-Scale Team

A small team running a handful of infrequent background jobs would see the opposite conclusion from the same analysis, serverless remains the more cost-efficient choice at that scale, since the Prime Video case study’s conclusion was specific to extremely high, sustained transaction volume, not a general argument against serverless for any workload.

Hybrid Approaches: Not an All-or-Nothing Decision

The framing of “serverless vs traditional hosting” can suggest a business has to pick one model for its entire application, when in practice the strongest architectures frequently mix both. A core API handling steady, predictable traffic might run on traditional hosting, while specific event-driven pieces, image processing, scheduled reports, webhook handlers, run as serverless functions alongside it. This mirrors the same architectural thinking covered in our SaaS web app architecture guide, applying the right execution model to each individual workload rather than forcing an entire system into a single approach, which is closer to how the Prime Video team’s broader application actually works today, a hybrid of microservices and monolithic components, not a wholesale rejection of serverless everywhere.

Security Considerations in Both Models

Cost and performance dominate this comparison, but security posture differs between the two models in ways worth knowing before deciding. Serverless functions benefit from a smaller attack surface by default; there’s no persistent server to patch or harden, since the provider manages the underlying operating system entirely. Traditional hosting puts more security responsibility on the team operating the servers, patching, hardening, and monitoring an OS that persists over time, but it also offers more direct control over network isolation and security configuration than a serverless environment typically allows. Neither model is inherently more secure, the OWASP API Security Top 10 vulnerability patterns, broken authentication, excessive data exposure, apply equally to an API running on either model, since these are application-level issues that infrastructure choice alone doesn’t solve.

This same infrastructure-level thinking applies to how we architect any web app, since the hosting model chosen for a backend directly shapes what security responsibilities a team takes on versus what the provider handles automatically.

How to Decide for Your Specific Application

The honest answer requires actual traffic data, not intuition. Estimate real request volume and how consistently that volume is distributed across a day or week, then model both pricing structures against that specific pattern rather than assuming either model is inherently better. Workloads with genuine idle time favor serverless. Workloads running consistently near capacity favor traditional hosting. And latency-sensitive workloads need to weigh cold start risk against cost savings, since the cheaper option on paper isn’t the right choice if it degrades an experience where speed directly affects revenue.

Common Mistakes in the Serverless vs. Traditional Decision

Teams frequently choose serverless by default because it’s the more actively marketed, more discussed option, without modeling their actual traffic pattern against real pricing, exactly the assumption the Prime Video case study challenges directly. Others assume traditional hosting is always the “safe” choice and over-provision capacity for traffic that never materializes, paying for idle servers the way serverless was specifically designed to avoid.

Cost comparisons frequently use list pricing without accounting for reserved capacity discounts on the traditional side or provisioned concurrency costs on the serverless side, both of which meaningfully shift a real comparison and can flip which option actually comes out cheaper for a given workload. And architecture decisions get treated as permanent, when the right answer, as the Prime Video case study itself demonstrates, can and should change as a workload’s actual traffic pattern evolves over time, revisiting a hosting decision periodically is a sign of engineering maturity, not a sign the original choice was wrong.

How The Apps Developers Approaches This Decision

We model actual traffic patterns against both pricing structures as part of the same API and backend development scoping conversation that shapes any infrastructure decision, rather than defaulting to whichever model is more discussed in the industry at a given moment.

This same evidence-based approach extends to the cost-performance comparisons covered in our native vs. cross-platform mobile development guide, since the underlying principle, matching the technical choice to actual, measured requirements rather than a default assumption, applies just as directly to hosting decisions as it does to mobile platform decisions.

If you’re not sure whether your current hosting model actually fits your traffic pattern, or you’re scoping a new application and want the decision grounded in real numbers, that’s worth a direct conversation. You’re welcome to talk to our team about what the cost and performance tradeoffs actually look like for your specific workload.

Frequently Asked Questions