Serverless Costs: Lambda, Functions, Cloud Run Pricing (2026)

Every major serverless platform charges on three dimensions simultaneously: request count, execution duration, and memory allocation. Understanding all three is necessary to predict costs — optimizing only one while ignoring the others is a common source of surprise bills.

Per-invocation charge

Every function call costs something regardless of how long it runs. AWS Lambda charges $0.20 per 1 million requests (after a 1M/month free tier). Azure Functions charges $0.20 per 1 million executions on the Consumption plan. Google Cloud Run charges $0.40 per 1 million requests. These headline rates look negligible — $0.20 for a million calls is $0.0000002 per call. But at 100M requests/month, that's $20 just in request fees before a single millisecond of compute.

Duration charge

This is the dominant cost for most workloads. Lambda charges $0.0000166667 per GB-second — the product of memory allocated (in GB) and wall-clock execution time (in seconds). A 512 MB function running for 200 ms consumes 0.5 GB × 0.2 s = 0.1 GB-seconds, costing $0.00000167. Multiply that by 10 million invocations and you get $16.70/month from duration alone — on top of $2 in request fees.

Duration is billed in 1 ms increments on Lambda (since 2020), 1 ms on Azure Functions, and 100 ms on Cloud Run (though Cloud Run bills CPU and memory separately rather than as a unified GB-second rate). The minimum billing increment matters: a function that takes 1 ms still gets billed for 1 ms, but a function that takes 101 ms on Cloud Run gets billed for 200 ms.

Memory allocation

Memory is the lever most developers ignore after initial setup. Lambda lets you allocate 128 MB to 10,240 MB in 1 MB increments. CPU scales proportionally: at 1,769 MB you get one full vCPU. Allocating more memory than your function uses is pure waste at $0.0000166667/GB-second. Allocating too little forces functions to run longer (increasing duration cost) and risks out-of-memory errors that trigger retries — paying twice or three times for the same work.

The practical rule: profile your function's actual memory usage in production, then add a 20–30% headroom buffer. Don't default to 128 MB out of habit; don't default to 1,024 MB out of caution. Both habits cost money unnecessarily.

The three dominant serverless platforms price similarly in structure but differ enough in rates, free tiers, and billing increments to matter at scale. Here is a side-by-side comparison using 2026 list prices.

Cloud Run's concurrency model is a meaningful differentiator. Lambda and Azure Functions spin up one instance per concurrent request — 500 simultaneous requests means 500 cold starts on a fresh deployment. Cloud Run can serve up to 1,000 requests per container instance, so a bursty workload that would cost $50 in Lambda cold-start compute might cost $5 on Cloud Run because fewer instances need to start. For I/O-bound workloads with natural concurrency (API proxies, webhooks, async tasks), Cloud Run's model wins on both cost and latency.

Azure Functions on the Consumption plan is functionally equivalent to Lambda in pricing and model. The main practical differences: Azure Functions integrates more tightly with Azure Service Bus and Cosmos DB triggers, while Lambda has deeper native integration with EventBridge, Kinesis, and DynamoDB Streams. If you're already paying for those adjacent services, pick the platform that reduces cross-service data transfer charges.

The fundamental economics of serverless vs containers come down to utilization. A container running at 5% CPU utilization wastes 95% of what you pay for. A serverless function running at 5% utilization costs 5% of equivalent continuous compute — you pay only for what runs. As utilization climbs toward 100%, containers become cheaper because the per-unit overhead of serverless request fees and billing granularity adds up.

The crossover calculation

A single t4g.small on AWS (2 vCPU, 2 GB RAM) costs $0.0168/hr on-demand — $12.10/month. That instance can serve roughly 1,000–5,000 requests per second depending on workload type. At 1M requests/day (11.6 req/sec average) with 200 ms average duration and 512 MB memory allocation, Lambda costs:

At 30M requests/month with 200 ms average duration, Lambda is already 4× more expensive than a single small EC2 instance on raw compute. Add API Gateway ($3.50/1M = $105/month) and the comparison is stark. The crossover in this scenario sits around 3–5M requests/month, not 30M — roughly 100K–170K requests/day.

That crossover shifts dramatically based on function duration. A function averaging 50 ms instead of 200 ms costs one-quarter as much on duration. The same 30M/month workload at 50 ms and 256 MB costs:

Short-duration, lightweight functions remain cost-competitive with containers well beyond 1M requests/day. Long-duration, memory-hungry functions cross over much earlier — sometimes below 100K requests/day.

When serverless wins

• Bursty, unpredictable traffic with long idle periods (nightly jobs, webhook handlers, cron tasks)
• Event-driven pipelines where individual items take under 100 ms to process
• Infrequent background tasks — data exports, report generation, notification dispatch
• Dev and staging environments that don't justify dedicated instances
• Workloads under ~1–5M requests/month depending on duration and memory

When containers win

• Sustained high-traffic APIs with predictable load above 1M requests/day
• Long-running compute — ML inference, video processing, anything over 5 seconds average
• Workloads sensitive to cold-start latency that would require expensive Provisioned Concurrency
• Stateful workloads that need in-process caching or local disk
• Microservice meshes where inter-service calls are frequent (cross-function invocation costs add up)

Use our serverless cost calculator to model your specific invocation count, duration, and memory against equivalent container costs. The crossover is not universal — it depends on your exact parameters.

The raw Lambda compute line is only part of what serverless workloads actually cost. In production, three categories of additional charges consistently catch teams off guard.

1. API Gateway

Most Lambda functions exposed as HTTP endpoints route through API Gateway. The REST API flavor charges $3.50 per 1 million API calls — 17.5× the Lambda request fee. At 10M calls/month, API Gateway costs $35 vs Lambda's $2 in request fees. The HTTP API flavor is cheaper at $1.00/1M calls but lacks some features (WebSocket support, usage plans, caching). The difference is material: choosing REST API over HTTP API for a 30M call/month workload costs an extra $75/month for the same traffic.

Alternative: API Gateway charges can be avoided entirely by using an Application Load Balancer (ALB) as a Lambda trigger. ALB charges $0.008/LCU-hour plus $0.008 per 1 million Lambda invocations — usually 60–80% cheaper than API Gateway for Lambda-only backends. The trade-off is a more complex setup and less built-in request validation. For the full REST/HTTP/WebSocket pricing breakdown, tiered rate tables, caching costs, and PrivateLink pricing, see our API Gateway pricing guide.

2. CloudWatch Logs

Lambda writes structured logs to CloudWatch Logs by default and you cannot disable it without removing all observability. CloudWatch charges $0.50/GB ingested and $0.03/GB/month stored. A high-volume function logging 500 bytes per invocation at 30M calls/month generates 15 GB of logs — $7.50/month in ingestion alone. Functions with verbose logging (request/response payloads, stack traces) can generate 2–5 KB per invocation, pushing log costs to $30–75/month on the same volume.

The fix: set structured log levels and gate verbose output behind a LOG_LEVEL environment variable. Use log sampling for high-volume functions — log 1 in 100 successful requests in full, 100% of errors. CloudWatch Logs Subscription Filters can route to S3 at $0.023/GB/month instead of keeping logs in CloudWatch at $0.03/GB/month, saving 23% on storage.

3. Cold starts and retries

Cold starts don't appear as a line item, but their cost shows up in duration. A Lambda cold start adds 100–1,000 ms to the first invocation of a new container. For a Node.js function that normally runs in 80 ms, a cold start adds 200 ms — 3.5× the normal duration for that one invocation. At 1% cold start rate across 10M invocations, that's 100,000 cold-start invocations with inflated duration, adding a few dollars. For JVM or .NET functions with cold starts of 1–3 seconds, the cost is more significant.

More expensive than cold starts themselves are cold-start-induced timeouts. A function with a 3-second timeout that cold-starts at 2.5 seconds occasionally hits the timeout and triggers an automatic retry. If your downstream caller also retries, a single logical operation can bill as 3–5 Lambda invocations. Check your Lambda function error rate and retry patterns — timeout-induced double-billing is a consistent hidden cost in production systems.

VPC-attached Lambda functions deserve special mention. Placing Lambda in a VPC to access RDS or ElastiCache adds NAT Gateway charges for any external traffic the function makes ($0.045/GB processed + $0.045/hr = $32.40/month just to exist). See our AWS bill breakdown for a full accounting of NAT Gateway costs and how VPC endpoints eliminate them. Building a mobile app? See our mobile app backend cost breakdown.

The table below models total Lambda cost (compute only — no API Gateway) for a 512 MB function with 200 ms average duration. Free tier is excluded to show true marginal cost. All figures use us-east-1 2026 list prices.

At 10M invocations/month the Lambda compute bill is $18.67 — reasonable. But adding REST API Gateway ($35) and CloudWatch Logs (~$7.50 at 500 bytes/invocation) brings the real number to $61.17. That's 3.3× the headline compute figure. This pattern — raw compute being a fraction of total serverless cost — repeats at every scale.

At 100M invocations/month with API Gateway, the total bill exceeds $500/month. At that scale, a fleet of four t4g.medium instances behind an ALB costs approximately $140/month with far better latency consistency. The architectural pivot pays for itself quickly. For help modeling your specific numbers, use the serverless cost calculator or review our cloud cost optimization checklist for cross-cutting reduction strategies.

The highest-leverage serverless optimizations target the cost components that scale with volume — API Gateway choice, log verbosity, memory tuning — rather than the compute rate itself, which you cannot negotiate.

1. Switch from REST API Gateway to HTTP API or ALB

For most Lambda backends, HTTP API ($1.00/1M) or ALB ($0.008/1M) is a direct substitute for REST API ($3.50/1M). If you don't need REST API-specific features (request validation schemas, usage plans, WAF integration, caching), switch. At 10M calls/month the saving is $25/month. At 50M calls/month it's $125/month. This is a configuration change, not an architectural one.

2. Right-size memory allocation with Lambda Power Tuning

AWS's open-source Lambda Power Tuning tool runs your function at every memory configuration from 128 MB to 10,240 MB and reports actual duration and cost at each level. Functions often run fastest — and cheapest — at a setting other than their current allocation. A function set to 1,024 MB might complete in 180 ms, while at 512 MB it takes 400 ms. At $0.0000166667/GB-s:

Run Lambda Power Tuning on your top five functions by invocation count. The results frequently reveal 10–30% savings with no code changes.

3. Use ARM64 (Graviton2) architecture

Lambda on ARM64 costs 20% less per GB-second than x86: $0.0000133334 vs $0.0000166667. Most Node.js, Python, and Go functions run without modification on ARM64. Java and .NET functions require rebuilding. For a function spending $50/month on duration, switching to ARM64 saves $10/month — immediately, with a single configuration change and a redeployment. The only reason not to make this change is a dependency that doesn't have an ARM64 build.

4. Reduce log verbosity and set retention

Default Lambda log groups have no retention policy — logs accumulate indefinitely at $0.03/GB/month. Set a 30-day or 7-day retention policy on all Lambda log groups. AWS CloudFormation and CDK let you set this at deployment time. For a function generating 1 GB/month of logs, uncapped retention grows storage costs by $0.36/month every month indefinitely. At 12 months without cleanup that's $21.60 in accumulated log storage for one function.

5. Batch event processing

For queue-driven workloads (SQS, Kinesis), increasing the batch size reduces the number of Lambda invocations for the same throughput. Processing 10 SQS messages per invocation instead of 1 reduces request fees by 10× and amortizes cold starts across 10 items instead of one. Duration cost increases proportionally, so the saving comes purely from reduced invocation count and cold-start overhead. This works particularly well for workloads where the per-message processing time is short relative to function initialization time.

6. Use Compute Savings Plans for predictable Lambda spend

If your Lambda invocation count is predictable (not bursty), Compute Savings Plans apply to Lambda duration charges and provide 17% savings compared to on-demand rates in us-east-1. A 1-year, no-upfront Compute Savings Plan that covers $100/month of Lambda duration saves $17/month — $204/year. This is often overlooked because Savings Plans are mentally associated with EC2, but they apply to Lambda too.