Compare 2026 serverless pricing for AWS Lambda, Azure Functions, and GCP Cloud Run. Detailed quotas, memory tiers, and cost-saving CLI commands. Read now.
How Serverless Pricing Actually Works Across the Big Three
AWS Lambda, Azure Functions, and GCP Cloud Run all bill on the same core idea: you pay for the compute you consume while a request runs, not for idle capacity. But the units differ enough to change your architecture decisions. Lambda meters invocations plus GB-seconds of memory-time. Azure Functions on the Consumption plan works similarly, combining execution count with a memory-weighted duration. Cloud Run, being container-based, charges for allocated CPU and memory for the lifetime of a request, with an option to keep instances warm.
The practical takeaway is that "cost" is never a single number. Two functions with identical logic can cost very differently depending on how much memory you provision, how long each call runs, and whether you pay for cold-start-avoiding idle instances. Model your workload as invocations × duration × memory tier before comparing providers.
Memory Tiers and the CPU That Comes With Them
Memory is the single knob that most affects both price and performance. On Lambda and Azure, CPU is allocated proportionally to the memory you select, so raising the memory tier also gives you more CPU. That means a higher tier can sometimes finish work fast enough to cost less overall, because you pay for fewer GB-seconds even at a higher per-second rate. Cloud Run lets you set CPU and memory more independently, which helps for CPU-bound or memory-heavy containers.
- Under-provisioning saves per-millisecond but stretches duration and worsens latency.
- Over-provisioning cuts duration but may pay for headroom you never use.
- The sweet spot is found empirically: sweep a few memory tiers under real traffic and compare total cost, not just per-invocation cost.
Quotas, Concurrency, and the Limits That Bite in Production
Every platform caps concurrent executions, request duration, payload size, and deployment package size. These quotas rarely matter in testing and always matter under load. If your account hits a concurrency ceiling, new requests are throttled or queued regardless of budget, so treat concurrency limits as a first-class capacity plan, not an afterthought. Long-running or streaming workloads also run into per-request timeout ceilings, which is often the deciding factor between a function and a container-based service.
Before committing, list the hard limits for your target platform and check them against your peak: expected simultaneous requests, longest single request, largest payload. Request quota increases early, since approval is not instant.
CLI Commands to Keep Costs Honest
Most cost surprises come from configuration drift, not from the pricing tables. Use the provider CLIs to inspect and right-size before and after deploy. Query each function's configured memory and timeout, confirm they match what the workload actually needs, and pull usage metrics to see real duration and invocation counts rather than guessing.
A useful habit is to script three checks into your deploy pipeline: dump current memory and timeout settings, compare them against a known baseline, and fetch recent duration metrics so you can retune memory tiers when traffic patterns shift. Automating these reads means you catch an oversized function or a runaway invocation count from a log or dashboard instead of from the monthly bill.