One SQS consumer can empty a default Lambda concurrency pool in under four minutes

Climbing from five concurrent invocations to 1,000 at 300 a minute takes about three minutes and twenty seconds ^[1]. On a default account the shared pool is therefore gone before the event source mapping gets near its own ceiling of 1,250 concurrent instances ^[4]. The dev.to post puts the time to that ceiling at a little over four minutes ^[5]. That is 1,245 units of headroom divided by 300 a minute ^[4].

The 250-unit gap between the mapping ceiling and the default account limit is what makes a limit increase a partial fix ^[2]. One mapping cannot go past 1,250 ^[4]. Two unbounded poll consumers in the same Region need an account limit above 2,500 before anything is guaranteed for everything else ^[5].

The second failure does not need account-level scarcity at all. The database client is initialized outside the handler so it survives between invocations, which makes the connection count track the environment count: 1,250 environments hold 1,250 connections against a Postgres instance whose max_connections is 100 ^[7]. That is 12.5 times what the server will accept ^[3]. The queue drains for a few seconds, invocations fail on connection exhaustion, the batches go back to the queue, the backlog deepens, and Lambda scales harder ^[8].

Nothing in the handler explains any of it. The setting that would cap the scaling lives on the function's configuration and on the event source mapping ^[9], and the post reports that the handler and the batch handling can both be correct while the failure stands ^[19]. A reviewer reading the diff has nothing to object to. The post's framing is two contracts, trigger shape first and delivery and retry semantics second, and it argues a code assistant asked for a queue consumer gets `event.Records[0].body`, the loop and the error handling right while having no way to know the second contract, because the second contract is not in the repository ^[10].

Reading the reservation costs one API call per function, either `GetFunctionConcurrency` or the `Concurrency` block from `GetFunction` ^[18]. `ListFunctions` returns many functions per page ^[12]. A naive implementation turns a handful of list calls into one call per Lambda in the account, on every analysis ^[12]. The commit that finally closed the issue said so: "GetFunctionConcurrency is one call per function, which is why this sat unbuilt" ^[11].

The narrowing is the good engineering here. Unbounded scaling only has teeth on poll-based sources, so the filter runs before any per-function call: `const POLL_TRIGGERS = new Set(['sqs', 'kinesis', 'dynamodb', 'msk'])` ^[14]. A queue hands a function as much work as the source contains and there is no backpressure from the caller, because there is no caller; an API-triggered function's concurrency is bounded by whoever is calling the API ^[15].

Collecting the field is now cheap. Grading it is the unsolved half: the author wrote, "I could not justify the cost for a check I could not even grade properly once I had the data" ^[17], and reports that the cost problem had a clean answer while the grading problem did not, calling the grading problem the more important of the two ^[16]. Whether a missing reservation is a defect depends on the account limit and on what the downstream will accept. The scaling numbers are Lambda's defaults for a standard queue ^[3], so for the four-minute figure to describe a given account, the 1,000-execution limit has to be untouched ^[1].