Denial of wallet in serverless: caps that limit the bill

Denial of wallet means abusing an auto-scaling service so the owner pays for the load. Serverless is exposed because it scales on demand and bills by use. The defenses are caps: concurrency limits, usage quotas, authentication before expensive work, and alerts on spend and throttling.

Why this is a serverless problem

A fixed server falls over under heavy traffic, which is bad but bounded in cost. A function platform keeps scaling. An attacker, or a bug such as a function that triggers itself, can drive large volumes of paid executions. The harm is financial, and sometimes a downstream system gives out first, such as a database with a connection limit.

Caps the documentation describes

AWS Lambda reserved concurrency. It sets the maximum simultaneous executions for a function. AWS says it can be used to limit concurrency and avoid overwhelming downstream resources, and that you can set it to 0 to intentionally throttle a function. Configuring it costs nothing. See reserved concurrency as a safety limit.

Azure Functions usage quotas. Microsoft suggests setting a usage quota for functions on a Consumption plan. When you set a daily limit in GB seconds on total execution of the function app, execution stops when the limit is reached. The page notes this could help protect against malicious code executing your functions.

Both are blunt tools. When the cap is hit, legitimate requests fail along with hostile ones. That is the trade: a bounded loss instead of an unbounded one.

Cheaper than the cap: do less work for strangers

1. Authenticate before the expensive step. Put identity checks first and keep the unauthenticated path small.
2. Validate cheaply and early. Reject oversized or malformed input before parsing or calling other services.
3. Avoid open public endpoints. A function URL with no auth or an unauthenticated Cloud Run service is reachable by anyone who finds the address.
4. Break self-trigger loops. Check that a function's output does not retrigger its own input, for example writing back to the bucket it reads from.
5. Bound timeouts and memory. Do not give every function the maximum.

Detection

Caps limit damage, alerts shorten it. Alert on:

• invocation count much above normal for the hour,
• throttle events from a concurrency cap,
• spend against a budget,
• a sudden rise in errors from a downstream dependency.

Decide in advance who gets the alert and what they may do, such as setting concurrency to zero on the offending function.

A checklist

1. Rank functions by cost per invocation and by exposure.
2. Set a concurrency cap or usage quota on the top of that list.
3. Add a budget alert at the account level.
4. Write the stop procedure in the runbook.
5. Test it once in a non-production account.

Quick check

Sources

• Configuring reserved concurrency for a Lambda function, AWS documentation
• Securing Azure Functions, Microsoft Learn

Last reviewed: 19 October 2026.