serverless aws finops claude-curated
Serverless pricing trades a low marginal cost per request for a high cost-per-second of sustained compute. Knowing where the break-even sits — and which “hidden” line items dominate at scale — keeps the bill predictable.
Lambda
Two charges:
- Requests — flat per-million invocation fee.
- Duration —
memory_GB × duration_mssummed and billed in GB-seconds, rounded to the nearest millisecond.
Provisioned concurrency adds a per-hour charge for pre-warmed containers. SnapStart adds caching and restore charges for Java functions.
CPU scales with memory (AWS Lambda), so for CPU-bound functions raising memory often reduces cost: duration falls more than the per-ms cost rises.
API Gateway
Per million requests, with HTTP API roughly 70% cheaper than REST API. WebSocket APIs charge per message and per connection-minute.
REST API also bills for cache (per hour, by cache size) and for data transfer out.
DynamoDB
Two billing modes:
- On-demand — pay per request (RRU/WRU). Best for unpredictable or spiky traffic. ~5–7× the per-request unit cost of provisioned at full utilisation.
- Provisioned — buy capacity (RCU/WCU) per second. Cheap if you can predict utilisation; with auto-scaling it adapts to traffic, with a few-minute lag.
Other charges: storage per GB-month, GSI/LSI traffic, point-in-time recovery, streams, global tables (per replicated write).
Lambda vs ECS Fargate
Both are “no-EC2” compute. Pricing styles differ:
| Lambda | Fargate | |
|---|---|---|
| Granularity | Per ms | Per second (1 min minimum) |
| Idle cost | Zero | Full task cost while running |
| Cold start | Yes | No (long-running tasks) |
| Max duration | 15 min | Unbounded |
A useful frame: Lambda dominates for small, intermittent workloads; Fargate (or EC2) wins for sustained high-throughput ones.
Break-even heuristic
A rough rule for picking between Lambda and a long-running container: if a function ends up running for more than ~40% of every minute of every hour, you’re paying enough Lambda duration that an always-on Fargate task with the same memory/CPU is cheaper. Below that threshold Lambda’s “pay only for invocations” model wins.
The real number depends on memory size, region, and which discounts (Compute Savings Plans, Spot) you can apply to Fargate. Compute the actual break-even before committing.
Hidden costs
Things that surprise teams:
CloudWatch Logs
Lambda writes everything console.log/print-ed to CloudWatch Logs. Charges:
- Ingestion — per GB of logs written. The dominant line item for chatty Lambdas.
- Storage — per GB-month, retained until the log group’s retention setting expires.
- Insights queries — per GB scanned.
Mitigations: set log retention (default is “Never expire”), drop debug logs in production, ship to S3 via subscription filter for archival.
NAT Gateway egress
A VPC-attached Lambda calling external APIs goes through NAT. NAT Gateway bills per GB processed — for a high-throughput Lambda this can exceed Lambda compute cost. Mitigations: VPC endpoints for AWS services, regional service endpoints, or pulling functions out of the VPC if they don’t actually need it.
Data transfer
Cross-AZ traffic between Lambda and RDS/ElastiCache, S3 reads cross-region, CloudFront origin pulls — all metered.
X-Ray, Cognito, Secrets Manager
Per-trace, per-MAU, per-secret. Small individually, real at scale.
Burst vs steady traffic
Serverless shines when load is bursty — you pay nothing during quiet hours and don’t get paged when a spike arrives. It’s expensive when load is steady and high because you’re paying the per-invocation premium 24/7.
Look at the load curve before committing:
- Spiky / unpredictable → Lambda + DynamoDB on-demand.
- Steady high throughput → Fargate / EC2 + DynamoDB provisioned (or RDS, OpenSearch, Aurora).
- Hybrid → Lambda for the long tail of endpoints, a container for the hot one.