CloudCostCompare
JA

このページはまだ日本語で提供されていないため、以下の本文は英語です。 英語のページを開く

ガイド

Serverless or servers: how to compare the cost fairly

Rohit Athaide · 2026年11月3日 公開

“Serverless” means you do not manage servers and are billed for what your code does, not for machines waiting. It is often the cheaper choice for light or spiky traffic and the dearer one for steady heavy traffic. Knowing why lets you find the crossover for your own workload.

How each is billed

Servers. You pay per hour for a machine whether it is busy or idle. The price is fixed for the month. Ten requests or ten million, the bill is the same until the machine is full.

Serverless functions. You pay per request, plus for the time and memory your code uses each time it runs. Between requests, nothing is billed. Most clouds include a monthly free allowance of requests and compute time. The product names are AWS Lambda, Azure Functions, Google Cloud Run functions and Oracle Functions.

Serverless containers. A middle option, where you run a container and pay for the time it handles requests, scaling to zero when idle. Examples are AWS App Runner and Fargate, Azure Container Apps and Google Cloud Run.

Why the answer changes with traffic

A server has a fixed cost and a ceiling. A function has no fixed cost and a cost per unit of work. So at low traffic the function wins, because the server’s fixed cost is mostly idle. As traffic rises, the function’s cost rises in a straight line while the server’s stays flat, until they cross. Above the crossover, the server is cheaper.

The crossover depends on three things: how many requests, how long each runs and how much memory it needs. A request that takes 20 milliseconds is cheap; one that takes 5 seconds is not.

Other costs that matter

  • Data transfer. Both pay it.
  • The services around it. A function often needs an API gateway or load balancer in front, billed per request, and a database, which is the same either way.
  • Cold starts. A function that has been idle takes longer to start, which affects latency, and some vendors charge to keep instances warm.
  • Limits. Maximum run time, memory and concurrency differ, and design around them.
  • Operations. A server needs patching and scaling logic. Serverless removes some of that work, and that has a value that is not on the invoice.

Finding your crossover

  1. Estimate monthly requests, the average run time of each and the memory it needs.
  2. From the vendor’s price page, compute the function cost: requests times the request price, plus compute time times the memory price, minus the free allowance.
  3. Get the monthly price of the smallest server that handles your peak. See choosing a cloud VM size.
  4. Add the extras for each side: a gateway for functions, a load balancer for servers.
  5. Compare the totals at your expected traffic, and at ten times that.

Do the arithmetic at your growth rate, because a design that is cheaper today can be dearer next year.

What we do and do not price

Our estimators price servers, a load balancer, databases and storage. They do not model functions, because the cost depends on code behavior that a form cannot capture. The web app estimate shows the always-on side, so you can set it against your function calculation. For containers on a managed cluster, see containers and Kubernetes costs.