Cost Curves and Crossovers
Cost curves and crossovers are a way to compare deployment options by modelling how their costs change with traffic. They show where a usage-billed service, such as serverless, stops being cheaper than fixed always-on capacity, by separating per-request charges from costs paid before any request arrives.
The problem is that deployment pricing rarely moves in a straight, obvious way. Serverless looks cheap when traffic is low because most cost is tied to requests and execution time. Containers look expensive at first because capacity, load balancers, networking, and logging may be running while idle. But as request volume, runtime, memory, or concurrency rises, the cheaper option can flip.
A cost curve makes that flip visible. For serverless, estimate the cost per request from the request charge plus execution time multiplied by configured memory and the provider’s compute unit price. For always-on containers, estimate the monthly baseline from running instances, hours, load balancers, NAT, and logs. The crossover is the request volume where the serverless total equals the container total.
The trade-off is that the model is only as good as its assumptions. Average traffic can hide peak concurrency, which may force more pods or instances. Long-running requests make serverless more expensive because execution cost grows with duration. Free tiers, regional prices, log volume, private networking, and minimum connector capacity can move the crossover substantially.
Engineers meet cost curves when choosing between Lambda and ECS or EKS, Cloud Run and GKE, Vercel functions and an always-on Node service, or Kubernetes and managed instance groups. The common mistake is comparing only compute. In production, fixed costs such as load balancers, NAT gateways, VPC connectors, nodes, and log ingestion often decide the real crossover.
Common questions
- Is serverless always cheaper at low traffic?
- Usually, but not automatically. A function that can run without private networking or always-allocated resources may have almost no compute cost while idle. If it needs NAT, a VPC connector, heavy logging, or other fixed infrastructure, there can be a real monthly bill before the first application request.
- What is the most common mistake in crossover analysis?
- The most common mistake is comparing a serverless per-request price with only the container’s instance price. Real container deployments may include load balancers, NAT, log ingestion, and multiple replicas. Real serverless deployments may include VPC access or long runtimes. Leaving those out makes the crossover look precise but wrong.
- Should I model average requests or peak traffic?
- It depends on what sets capacity. Serverless cost mostly follows actual invocations and duration, though concurrency limits still matter. Container cost is often set by the capacity needed during busy periods, not the monthly average. If peak load requires more pods or instances, that higher baseline belongs in the curve.