Serverless Cost Management: Lambda, Cloud Run and Functions
Pay-per-use until someone switches on warm capacity. Managing serverless cost is mostly managing those switches.
Serverless cost management is the practice of tracking and controlling spend on services where the provider runs the compute and bills by activity: invocations, execution time, and configured memory. There is no idle server to turn off, so the work shifts to the settings that multiply every invocation and to the options that reintroduce always-on cost.
How the three main platforms bill
AWS Lambda charges for the number of requests and for duration, measured in GB-seconds and rounded up to the nearest millisecond. You choose memory between 128 MB and 10,240 MB in 1 MB steps, and Lambda allocates CPU in proportion; at 1,769 MB a function has the equivalent of one vCPU. Ephemeral storage above the included 512 MB is billed separately. Provisioned concurrency, which keeps environments initialised, is charged for the concurrency you configure from the time you enable it until you disable it, rounded up to five minutes, on top of requests and duration, and the free tier does not apply to functions that use it. Reserved concurrency, by contrast, is a limit and incurs no charge.
Google Cloud Run defaults to request-based billing: an instance is billed only while it processes requests, rounded up to 100 milliseconds. Minimum instances kept warm are billed at an idle rate. Instance-based billing charges for the whole lifetime of each instance.
Azure Functions on the Flex Consumption plan, which Microsoft recommends for new serverless apps, bills on-demand instances for memory provisioned while executing (GB-seconds) and for executions, each after a monthly free grant. Always-ready instances are billed for their baseline memory as well as execution, with no free grants. The Premium plan keeps at least one instance warm per plan at all times.
The settings that matter
| Setting | Effect on cost |
|---|---|
| Lambda memory | Scales the price of every millisecond; also scales CPU, so a larger size can finish faster |
| Timeout | A ceiling, not a charge; it bounds the cost of a hung invocation |
| Provisioned concurrency, minimum instances, always-ready instances | Fixed hourly cost regardless of traffic |
| Reserved concurrency | Free; caps how far a function can scale |
The table explains why memory tuning is not simply “go smaller”. AWS advises finding the right memory setting by monitoring functions with CloudWatch, and notes that more memory can dramatically improve the performance of CPU-, network-, or memory-bound functions. Shorter duration offsets part of the higher per-millisecond price, so measure cost per invocation rather than picking the smallest size.
Governing serverless spend
- Inventory functions across every account and region, including ones with no recent invocations.
- Attribute cost per function and per owner with tags, because one account can host functions owned by several teams.
- Review warm capacity per environment. Provisioned concurrency or minimum instances in a test environment are fixed cost for latency nobody measures.
- Count the services around the function. Lambda logs go to CloudWatch Logs at standard CloudWatch Logs rates; API Gateway charges per API call and for data transferred out; a VPC-connected function that needs internet access goes through a NAT gateway, billed per hour and per GB processed.
What ZopNight checks
ZopNight discovers Lambda functions and prices them, and its rules include an idle-function check that flags functions averaging under one invocation per day over the window, a memory check that fires when peak memory stays below half of the configured size and prices the saving only from the duration component, and a timeout check that is deliberately a no-dollar hygiene finding because timeouts are not billed. ZopNight can also stop a Lambda function on a schedule by throttling its concurrency, which AWS documents as setting reserved concurrency to zero.
For the costs that surprise teams most, see serverless cost pitfalls; for containers, see container cost optimization and the Lambda resource page.