18 articles on lambda — what drives the cost, how it is priced, and where the savings actually are.
Cold starts are usually discussed as a latency problem, but they also change what you pay. Initialization time, runtime choice, package size, and burst shape all land on the invoice. Here is the arithmetic.
Provisioned concurrency trades a usage bill for a capacity bill. There is a clean break-even point based on utilization, and most teams sit on the wrong side of it. Here is how to compute yours.
More Lambda memory means more CPU, so a bigger function can be cheaper than a smaller one. The relationship is not linear and the sweet spot is workload-specific. Here is how to find it with numbers.
A function on a one minute schedule runs 43,200 times a month whether or not there is work to do. Polling schedules are the quietest source of waste in a serverless estate. Here is the arithmetic.
Resizing images in functions looks trivially cheap per image until you count storage, egress, ephemeral disk, and the variants you generate. Here is the full pipeline cost for a real workload.
When one function calls another synchronously, you pay for both at once. Chains of waiting functions are the most expensive common anti-pattern in serverless, and they are easy to spot.
Lambda is cheap for spiky, low-utilization workloads and expensive for steady, high-utilization ones, where an EC2 instance running full-time wins. The breakeven depends on request volume, duration, and how busy the compute would be. Here is how to find the crossover.
Lambda cost per million invocations depends on two levers, the flat per-request fee and the per-GB-second duration charge, and the duration part usually dominates. Working through real numbers shows exactly where the cost goes and which lever to pull. Here is the breakdown.
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.
Running Lambda functions on ARM-based Graviton instead of x86 costs about 20 percent less per unit of compute, and many functions run just as fast or faster. Here is how the savings work, what to check before switching, and how to migrate.
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.
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.
RDS Proxy bills per vCPU of the database it fronts, continuously, whether or not connections flow. Here's how the charge works, when it pays for itself, and when it's overhead you can skip.
Lambda wins for sporadic and event-driven workloads. Containers win for steady high-volume traffic. The crossover is around 2-3M requests/day for typical APIs. Here's the math, the workload archetypes, and a decision framework.
Lambda is the most mis-estimated AWS service. Here's why cost tools show $0 by default, what data to feed them for accurate numbers, and the four optimization levers that actually move the bill.
Cold starts are mostly a latency problem, not a cost problem (except for Java). Here's when they matter, what each runtime's typical cold start looks like, and when Provisioned Concurrency or SnapStart pay for themselves.