52 articles on serverless — what drives the cost, how it is priced, and where the savings actually are.
Cloud Run offers two CPU allocation modes, one that bills CPU only during requests and one that keeps CPU always allocated, and the choice changes both cost and behavior. Here is how each is priced and which fits your workload.
Cloud Functions 2nd gen runs on Cloud Run and Eventarc under the hood, which changes its pricing from the 1st gen model. Here is how 2nd gen bills, how it differs from 1st gen, and how to keep function cost low.
Serverless functions cost nothing when idle and scale to zero, but their per-request price is high; a VM costs a flat hourly rate no matter the load. There is a clear crossover in request volume where a VM becomes cheaper. Here is how to find it.
Serverless databases scale capacity automatically and bill per use, costing nothing when idle; provisioned databases reserve fixed capacity at a flat rate. The crossover is utilization, and it decides which is cheaper. Here is the math with numbers.
Event-driven architectures trade steady servers for pay-per-event components like queues, functions, and streams, which changes the cost shape entirely. Here is where event-driven spend concentrates and how to estimate it.
Hosting an API can cost almost nothing at low volume with serverless, or a predictable monthly amount on a small server, and the crossover depends entirely on request volume. Here is how to estimate API hosting cost and pick the cheaper model.
Lambda bills on requests and on compute measured as memory times duration, with memory also determining CPU. Understanding that model reveals why right-sizing memory, cutting duration, and choosing ARM are the levers that control serverless cost. Here is the full picture.
Lambda memory controls both cost and CPU, so the cheapest setting is not always the lowest. Right-sizing memory to minimize cost per invocation, factoring in faster execution, is a real optimization. Here is how to tune it.
SQS, SNS, and EventBridge all move messages between services but price differently, per request, per publish and delivery, and per event with routing. Which is cheapest depends on your fan-out and routing needs. Here is the comparison.
AWS Step Functions bills the Standard workflow type per state transition, so a workflow with many steps or high execution volume can cost more than expected. The Express type prices differently. Here is how to keep orchestration cheap.
AWS API Gateway offers REST APIs and HTTP APIs at very different prices. HTTP APIs are substantially cheaper per million requests but drop some features. Here is the price gap, the feature tradeoffs, and how to choose.
Managed message queues like SQS, Pub/Sub, and Azure Service Bus bill per request or per message, sometimes plus data and features. Here is how queue pricing works, what drives the bill, and how to keep messaging cost low.
Amazon EventBridge charges mostly per event published, with extras for schema discovery, replay, and cross-Region routing. The default event bus receiving AWS service events is free. Here is how EventBridge pricing works and how to keep it cheap.
Provisioned concurrency keeps Lambda instances warm to eliminate cold starts, but you pay for that capacity around the clock whether it runs or not. Here is how the pricing works and when it is worth it.
Lambda charges per request and per GB-second and scales to zero; Fargate charges per vCPU and GB by the second for continuously running tasks. The cheaper option depends entirely on your traffic pattern. Here is how to choose.
Cloud Run jobs bill per vCPU-second and memory-GiB-second while the job runs, with no idle cost since jobs run to completion and stop. It suits batch and scheduled work. Here is how the model works and how it differs from Cloud Run services.
Edge compute (Cloudflare Workers, Lambda@Edge, and others) runs code at CDN edge locations, priced by requests and compute time, often cheaply. It cuts origin load and latency but has constraints. Here is the cost model.
Google Cloud Workflows bills per step executed, with internal steps very cheap (and a free tier) and external HTTP calls slightly more, so orchestration itself is nearly free. The real cost is what the steps call. Here is the model.
Cloud Scheduler bills per job per month (the first three free, then about $0.10 each), making it one of the cheapest ways to run cron in the cloud. The real cost is the work each job triggers, not the scheduler. Here is the model.
Serverless cold starts add latency; mitigating them with provisioned concurrency or minimum instances means paying for warm capacity around the clock. Whether that trade is worth it depends on traffic and latency needs. Here is the cost math.
AWS Lambda, Azure Functions, and Google Cloud Functions all bill invocations plus compute (memory times duration), with a free tier. The models are close; the real cost differences come from configuration and the surrounding services. Here is the comparison.
Serverless bills only for what you use, which can be cheap or expensive depending on memory, duration, invocation volume, and idle provisioned capacity. This is a practical guide to keeping Lambda, Fargate, and serverless databases economical.
Cloud Functions 2nd gen runs on Cloud Run, so rates converge, but Cloud Run's concurrency lets one instance serve many requests, making it cheaper for request-heavy workloads. Here's how to choose.
Standard workflows bill $0.025 per 1,000 state transitions; Express bills per request + duration. For high-volume workflows the gap is 50-100x. Here's which to use and why high-frequency Standard workflows blow up.