Serverless Cost Optimization 2026: 4 Hidden Charges

Data Transfer: The Silent Budget Killer

Data transfer charges apply every time a function sends data out of its region or availability zone. Cross-region calls cost $0.02 per GB outbound, while same-region cross-AZ transfer runs $0.01 per GB in each direction. That sounds small until you multiply it by thousands of function invocations per hour.

A Lambda function in us-east-1 querying an RDS instance in eu-west-1 pays egress from us-east-1 and ingress to eu-west-1. If each query returns 500KB of data and you process 10,000 requests daily, that's 5GB transferred per day—about $3/day or $90/month just in transfer fees. The function execution might cost $15/month.

Same-region transfer between availability zones adds up too. Put your database in the same AZ as your functions when possible, or use read replicas in each AZ where functions run.

• Cross-region transfer: $0.02/GB outbound (10x compute costs for data-heavy workloads)
• Cross-AZ transfer: $0.01/GB each direction (often overlooked in multi-AZ setups)
• Internet egress: $0.09/GB for data leaving to external APIs or users
• VPC NAT Gateway: $0.045/GB processed plus $0.045/hour ($32/month baseline)

When Data Transfer Costs More Than Execution

Check your architecture for these patterns. Functions calling third-party APIs outside your cloud provider pay internet egress rates—the most expensive tier. A function that fetches 2MB from an external API per invocation and runs 50,000 times daily transfers 100GB monthly, costing $9 in egress alone.

VPC-based functions using NAT Gateways pay a flat hourly charge plus per-GB processing. One NAT Gateway costs roughly $32/month before any data moves through it. Then you pay $0.045/GB processed. If your functions transfer 500GB monthly, that NAT Gateway costs $32 + $22.50 = $54.50, likely exceeding your execution costs.

So what's the fix? Colocate resources in the same region and AZ when latency allows. Use VPC endpoints instead of NAT Gateways for AWS service calls (DynamoDB, S3, SQS). Cache external API responses in your region to avoid repeated egress charges.

Cold Starts: Frequency vs. Provisioned Concurrency Trade-off

Cold starts happen when a function hasn't run recently and the platform needs to initialize a new execution environment. Initialization time varies—Node.js and Python cold start in 100-500ms, Java and .NET in 1-3 seconds, especially with large dependencies.

The cost isn't just latency. Some platforms charge a small surcharge per cold start (typically 10-30% more than a warm start for the same duration). If your function normally executes in 200ms but cold starts take 800ms, you pay 4x the compute cost for those invocations.

Provisioned concurrency keeps a set number of instances warm and ready. You pay per instance-hour regardless of invocations. AWS Lambda charges about $0.000004 per GB-second for provisioned concurrency—roughly the same as execution, but continuous.

Calculating the Break-Even Point

Here's the math. Say your function runs 500,000 times monthly with 20% cold start rate (100,000 cold starts). Cold starts add 600ms overhead at 512MB memory. That's 60,000 extra seconds billed, costing about $1.25 at standard Lambda rates.

Provisioned concurrency for one instance at 512MB costs roughly $14.60/month (730 hours × $0.00002/hour). Unless your cold start overhead exceeds $14.60 per instance you want to keep warm, you lose money. For low-traffic functions, don't use provisioned concurrency.

The break-even point sits around 50,000-100,000 cold starts per month per instance. Below that threshold, accept the cold starts. Above it, provision just enough concurrency to handle your baseline traffic—not your peak.

• Low-traffic functions (<10,000 invocations/month): accept cold starts, optimize initialization code
• Medium-traffic (10,000-100,000/month): reduce package size, lazy-load dependencies, keep cold starts fast
• High-traffic (>100,000/month): provision concurrency for baseline load, let auto-scaling handle spikes
• Scheduled functions: use EventBridge to warm the function 1 minute before the scheduled run instead of 24/7 provisioned concurrency

API Gateway vs. Direct Invocation: Request Volume Math

API Gateway simplifies REST API deployment but charges per request on top of function costs. AWS API Gateway REST APIs cost $3.50 per million requests (first 333 million). HTTP APIs run $1.00 per million. Both bill independently of your function execution time.

Direct function URLs or Application Load Balancer integration charge based on data processed, not request count. ALB costs about $0.0225/hour ($16.20/month) plus $0.008 per LCU-hour. One LCU handles roughly 25 new connections per second or 3,000 active connections. For most web APIs, this works out to $0.20-0.40 per million requests depending on payload size.

At 10 million requests monthly, API Gateway REST costs $35. HTTP API costs $10. ALB costs about $18-20 ($16.20 base + $2-4 in LCU charges). The difference becomes significant above 20-30 million requests monthly—you save $15-20/month by switching to ALB.

When API Gateway Makes Sense

API Gateway includes built-in features that ALB doesn't: request validation, API keys, usage plans, and per-method throttling. If you need those features, the per-request charge might be worth it. But many teams enable API Gateway for a simple proxy and pay $35/month for features they never use.

Function URLs work for simple HTTP endpoints without routing or authentication. They're free beyond function execution costs. Good for webhooks, health checks, or internal service-to-service calls.

So compare your monthly request volume. Under 5 million requests, the cost difference is negligible—pick what's easiest to maintain. Between 5-20 million, HTTP API saves money over REST API. Above 20 million, ALB or direct function URLs usually win unless you actively use API Gateway features.

• API Gateway REST: $3.50/million requests, includes auth, throttling, usage plans, request validation
• API Gateway HTTP: $1.00/million requests, simpler feature set, faster routing, lower cost
• ALB + Lambda: ~$0.20-0.40/million requests, better for high-volume traffic, requires separate auth layer
• Function URLs: free (execution cost only), no routing, best for single-endpoint services or webhooks

Logging and Observability: Ingestion Plus Storage

Every console.log or print statement in your function sends data to a logging service. CloudWatch Logs charges $0.50 per GB ingested and $0.03 per GB per month for storage. Application Insights, Datadog, and other observability platforms charge similarly or more.

Verbose logging kills budgets fast. A function logging 5KB per invocation at 1 million invocations monthly sends 5GB of logs. That's $2.50 ingestion plus $0.15 monthly storage (grows over time if you don't set retention policies). If you have 50 functions doing this, logging costs $130+/month—often more than all your execution costs combined.

Check your logs right now. Look for JSON request/response bodies logged at info level, stack traces printed on every error (even handled ones), and debug statements left in production. I've seen functions logging 20KB per invocation because someone dumped entire HTTP headers and response objects 'just in case.'

Practical Log Optimization Strategy

Set log retention to 7-14 days unless compliance requires longer. CloudWatch defaults to never expire—logs accumulate forever. A year of verbose logs at 5GB/month costs $1.80 in storage alone, and that's per function.

Use structured logging with log levels. Debug and trace logs should only fire when explicitly enabled via environment variables. Info logs should contain just enough context to correlate with traces—not the full request payload. Error logs need stack traces, but handled errors (like validation failures) don't need traces at all.

Sample high-volume functions. Log 1% of successful requests and 100% of errors. CloudWatch and most observability platforms support sampling. For a million-request function, this cuts log ingestion from 5GB to 50MB—$0.025 instead of $2.50.

• Set retention policies to 7-14 days for non-production logs, 30-90 days for production
• Remove debug logs from production or gate them behind an environment variable
• Sample successful executions (1-10% depending on traffic), log all errors
• Avoid logging full request/response bodies—log request ID and size instead
• Use structured JSON logs with consistent fields for easier searching and lower storage needs

Prioritizing Optimizations by Impact

Start with your actual bill. Most cloud providers let you break down costs by service. Identify which of these four categories consumed the most money last month. If data transfer was 60% of your bill, fix that before worrying about cold starts.

The highest-impact optimization depends on your architecture. Cross-region function-to-database calls waste more money than API Gateway charges. Provisioned concurrency on 20 low-traffic functions costs more than cold starts ever would. Verbose logging at 50 million invocations monthly dwarfs execution costs.

Test one change at a time in staging. Move one database to the same region as its functions. Switch one high-traffic API from REST API Gateway to HTTP API. Cut log retention from indefinite to 14 days. Measure the savings, then apply the pattern to other resources.