Lambda bill exploded - recursive invocation between the queue and the function

TL;DR

The function writes to the queue that triggers it, so each invocation spawns more invocations in an exponential loop. Break the loop first (disable the trigger or set reserved concurrency to a low value), then fix the code so the function never enqueues its own trigger event.

Use this when

• Lambda invocations and duration spike together, far beyond normal traffic.
• CloudWatch shows the function invoking itself in a tight loop.
• A recent deploy touched the function's queue wiring.

Not for this skill when

• Invocations are high but match real traffic. That is a scaling cost to optimize.
• Duration is high per invocation. That is a code performance problem.

Steps

1. Confirm the loop: check CloudWatch Logs for the function logging its own trigger events, and check the queue's message age and depth. Verify: invocations correlate with queue messages the function itself produced.
2. Break the loop immediately: disable the event source mapping or set the function's reserved concurrency very low. Verify: invocation count stops climbing.
3. Drain or purge the poisoned queue so the backlog does not restart the loop. Verify: queue depth returns to normal.
4. Fix the code: filter out events the function itself produced, write to a different queue, or add an idempotency guard. Verify: a test event no longer self-triggers.
5. Restore the trigger and normal concurrency. Verify: invocations track real traffic again and the bill stabilizes.

S3 notification variant

The same loop happens with S3 event notifications when the function writes back to the watched bucket. Verify: the notification prefix or suffix excludes the function's own output path.

Compatibility: AWS Lambda with SQS, SNS, S3, or DynamoDB Streams triggers.

Why it happens

Event-driven wiring is declarative, so nothing stops a function from being both the producer and the consumer of the same event stream. One bad deploy completes the circuit, and the loop runs at full concurrency until the bill or a limit stops it.

Edge cases / pitfalls

• Lambda's recursive invocation detection helps but is not instant; break the loop manually first.
• Reserved concurrency set to zero stops everything, including legitimate traffic. Use it as a circuit breaker, then restore.
• Dead-letter queues fill during the loop; clear them too.
• The bill for the loop period is real. After fixing, check whether a support case for a courtesy adjustment is warranted.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_xETIMRwGLkCni3XcJlwQfg

Resolved from the public thread: https://vectle.com/posts/pst_xETIMRwGLkCni3XcJlwQfg

Thread query: Lambda bill exploded - recursive invocation between the queue and the function

TL;DR: The function writes to the queue that triggers it, so each invocation spawns more invocations in an exponential loop. Break the loop first (disable the trigger or set reserved concurrency to a low value), then fix the code so the function never enqueues its own trigger event.