Serverless Cost Pitfalls: The Expenses Nobody Warns You About

A serverless cost pitfall is any charge that grows without a matching growth in useful work: capacity kept warm while idle, invocations repeated by retries or loops, or supporting services billed per hour or per gigabyte beside the function itself. None of these is hidden in the provider’s pricing; they are simply easy to overlook when the headline promise is paying per request.

1. Warm capacity that never goes cold

AWS Lambda provisioned concurrency is billed for the concurrency you configure, from the moment you enable it until you disable it, rounded up to the nearest five minutes, in addition to requests and duration. The Lambda free tier does not apply to functions that use it. Google Cloud Run bills minimum instances at an idle rate when they are not serving requests, and Azure Functions always-ready instances bill a memory baseline with no free grant. Each is a fixed hourly cost attached to a pay-per-use service. Check whether test and staging environments carry the same warm settings as production.

2. Initialisation code on the meter

Lambda duration includes initialisation code declared outside the handler, not only the handler itself. With provisioned concurrency, initialisation code runs when environments are allocated and again as Lambda periodically recycles them, and Lambda bills that initialisation even if the environment never serves a request. Heavy imports and start-up work therefore cost money on every cold start.

3. Memory set by guesswork

Lambda’s default memory is 128 MB, the lowest setting, and anything from 128 MB to 10,240 MB can be configured. Duration is priced per GB-second, so doubling memory doubles the price of each millisecond; because CPU scales with memory, it may also shorten the run. Set memory from measured peak usage and duration, not from a value copied from another function.

4. Timeouts longer than the work

A timeout is not billed in itself, but an invocation that hangs is billed until it returns or is terminated, up to the configured timeout, which can be as long as 900 seconds. A timeout far above observed duration turns every stuck call into the most expensive call the function can make.

5. Retries you did not ask for

For asynchronous invocations that return an error, Lambda by default tries the function two more times, waiting one minute and then two minutes between attempts. A function failing on bad input can therefore cost three executions per event. Configure retry attempts and a failure destination deliberately.

6. Recursive loops

A function that writes to a queue, topic, or bucket that triggers the same function can loop. AWS warns that unintentional recursive loops can cause unexpected charges and consume all of an account’s available concurrency. Lambda detects certain loop types shortly after they occur and, by default, stops the invocations and notifies you; not every pattern is covered, so design triggers to avoid self-invocation.

7. Logging volume

Lambda logs add no Lambda charge, but standard CloudWatch Logs charges apply to what you write and keep. Debug logging left on in a busy function, plus logs retained indefinitely, can outgrow the compute cost.

8. The NAT gateway behind a VPC function

A VPC-connected Lambda function that needs internet access reaches it through a NAT gateway. NAT gateways are billed for each hour they are provisioned, with partial hours billed as full hours, plus a charge for every gigabyte processed and standard data transfer. That hourly charge continues whether or not the function runs.

9. The API in front

API Gateway charges for the API calls received and data transferred out, and optional caching is billed hourly by cache size. For small, fast functions the per-request API charge can exceed the function’s own cost.

Catching them

Review warm settings per environment, set alarms on invocation counts and error rates, cap retries, set log retention, and report cost per workload including its API, logs, and networking. ZopNight flags Lambda functions with almost no invocations and functions whose peak memory stays well below their configured size, and treats an oversized timeout as a no-dollar hygiene finding because timeouts themselves are not billed.

Related: serverless cost management, data transfer costs, and the Lambda resource page.