Lambda recursive loops: four guardrails compared in the Sovereign Cloud

Isolated partition: the European Sovereign Cloud is its own partition (aws-eusc), with a single region, eusc-de-east-1, in Germany, operated by EU residents. It is not 'one more region': it is a logically separate environment, with two Availability Zones instead of three and roughly 90 services at the January 2026 launch. Anyone arriving from eu-central-1 quickly finds everyday tools missing — IAM Identity Center, Security Hub, Inspector, CloudFront — and that quota increases usually go through a support ticket.

Why this matters for recursive loops: in a partition with fewer security services and less quota automation, the safety net you had in the commercial partition shrinks. Cost Anomaly Detection and billing alarms remain your last-resort defense — but each one has to be verified in the partition itself, not assumed. Native Lambda detection reached the EUSC almost three years after it debuted in commercial regions (July 2023 for SQS, SNS and Lambda; October 2024 for S3). That gap is the lesson: feature parity in a sovereign partition is not automatic. A workload that relied on a free, invisible guardrail in the commercial partition ran for months without it in the EUSC and nobody noticed. That is why I compare four mechanisms rather than recommending only the one that just arrived.

Same mechanics, same limit: the docs.aws.eu documentation carries the same minimum-SDK table and the same ceiling of approximately 16 invocations per chain. What differs is the surroundings.

Mechanism: Lambda piggybacks on the X-Ray trace header. When SQS, SNS or S3 deliver an event, it arrives annotated with a Lineage primitive — a resource hash plus a counter, something like Lineage=43e12f0f:5. When the function writes that event back to a supported service using a supported SDK, the counter increments. At approximately 16 invocations in the same chain, Lambda drops the next one and returns RecursiveInvocationException. No X-Ray active tracing is required and there is no charge.

Three limits the announcement page does not emphasize:

1. Coverage by service. Only Lambda, SQS, SNS and S3. If the loop runs through DynamoDB Streams, EventBridge, Kinesis or Step Functions, the counter does not travel and nothing gets cut. The documentation says this in one sentence — it deserved a paragraph.
2. Coverage by SDK. The counter only propagates if the function uses a minimum SDK version: Node.js 3.105.0 (v3), boto3 1.24.46, Java 2.20.81 on the 17 runtime, Go v2 1.57.0. A Python function that bundles an old boto3 in its deployment package silently leaves the protection.
3. Depth, not breadth. The counter measures how many times that event invoked the function. A fan-out loop — one invocation producing three objects, each producing another invocation — is 16 levels deep, but every level multiplies the width. Sixteen hops at factor 3 is tens of millions of invocations before the cut. Detection bounds the chain; it does not bound the tree.

The alert delay: the Health Dashboard notification and the email can take up to 3.5 hours, and the email is at most one per function every 24 hours. The RecursiveInvocationsDropped metric is emitted immediately — that is where the alarm has to sit.

Scenario: a 512 MB function, 200 ms per execution, triggered by ObjectCreated on the same bucket it writes to. Without reserved concurrency, Lambda scales to the account quota — 1,000 default concurrency in a commercial region; in the EUSC, confirm the value on your account, because quotas there usually go through a ticket. I use commercial-region list prices as a proxy; the EUSC has its own price table and you should check it before closing the number.

With no guardrail at all: 1,000 concurrent executions of 200 ms are 5,000 invocations per second. Each costs roughly US$ 0.0000019 in compute plus US$ 0.000005 for the S3 PutObject — the PUT costs more than the function. That is about US$ 0.035 per second, or US$ 125 per hour. In the 3.5 hours the Health Dashboard may take to warn you, the bill reaches US$ 440. On a Friday night it passes US$ 1,500 before anyone opens the email. Not catastrophic for a bank; enough to become an audit item and a CFO question.

With native detection only: the simple loop dies at 16 invocations — cents. The fan-out loop does not: 16 levels at factor 3 is 3^16 ≈ 43 million invocations, and detection cuts each individual chain only when it reaches level 16. The bill goes back to the previous scenario, now bounded by how long the tree takes to exhaust itself.

With reserved concurrency of 50: the worst case drops to 250 invocations per second — US$ 6 per hour. The 3.5-hour delay costs US$ 22. That is the number that lets me sleep: native detection cuts the chain; reserved concurrency bounds the breadth; neither alone bounds the cost.

The lesson: each guardrail acts on one dimension — depth, breadth or the loop's existence. Stacking the three is not redundancy; it is covering three different axes of the same problem.

Detection state as code: PutFunctionRecursionConfig accepts Allow or Terminate, and the default is Terminate. Declare it explicitly in SAM or CloudFormation and add an SCP or pipeline policy denying lambda:PutFunctionRecursionConfig outside the platform role. Whoever needs Allow — a crawler that deliberately re-enqueues itself — justifies it in an ADR and gets low reserved concurrency in return. Remember that with Allow the RecursiveInvocationsDropped metric is not emitted: you lose the signal along with the protection.

Alarm on the right metric: RecursiveInvocationsDropped with Statistic: Sum, a 60-second period, threshold >= 1, one evaluation. Do not wait for the Health Dashboard. Next to it, ConcurrentExecutions per function with a threshold at 80% of reserved concurrency — that is the alarm that catches the fan-out and the DynamoDB loop that detection cannot see.

SQS as source: configure the DLQ on the source queue, not on the function. The function DLQ only applies to asynchronous invocation. And understand the interaction: after detection, the RecursiveInvocationException increments receiveCount on every retry, so the message only lands in the DLQ when the redrive policy's maxReceiveCount is exceeded. A maxReceiveCount of 1,000 keeps the message knocking for hours — 5 is reasonable for most cases.

S3 as source: distinct input and output prefixes, with the notification filter pointing only at the input one. A separate bucket when compliance allows; a prefix when it doesn't. Never the same environment variable for both — that is exactly what took me down.

SDK: pin the minimum version in package.json/requirements.txt and make the pipeline fail below it. It is the only way the protection does not silently vanish.