Loop recursivo no Lambda: quatro guardrails comparados no Sovereign Cloud

Partição isolada: o European Sovereign Cloud é uma partição própria (aws-eusc), com uma única região, eusc-de-east-1, na Alemanha, operada por residentes da UE. Não é 'mais uma região': é um ambiente logicamente separado, com dois Availability Zones em vez de três e cerca de 90 serviços no lançamento de janeiro de 2026. Quem chegou lá vindo de eu-central-1 descobre rápido que ferramentas do dia a dia faltam: IAM Identity Center, Security Hub, Inspector, CloudFront, e que aumento de quota costuma passar por ticket de suporte.

Por que isso importa para loop recursivo: em uma partição com menos serviços de segurança e menos automação de quota, a rede de segurança que você tinha na partição comercial encolhe. Cost Anomaly Detection e alarmes de billing continuam sendo a sua defesa de último recurso, mas cada um precisa ser verificado na própria partição, não assumido. A detecção nativa do Lambda chegou ao EUSC quase três anos depois de estrear nas regiões comerciais (julho de 2023 para SQS, SNS e Lambda; outubro de 2024 para S3). Esse intervalo é a lição: paridade de feature em partição soberana não é automática. Uma carga que dependia de um guardrail gratuito e invisível na partição comercial passou meses sem ele no EUSC sem ninguém perceber. É por isso que comparo quatro mecanismos e não recomendo apenas o que acabou de chegar.

Mesma mecânica, mesmo limite: a documentação em docs.aws.eu traz a mesma tabela de SDK mínimo e o mesmo teto de aproximadamente 16 invocações por cadeia. O que difere é o entorno.

Mecanismo: o Lambda pega carona no header de trace do X-Ray. Quando SQS, SNS ou S3 entregam um evento, ele vem anotado com um primitivo Lineage, um hash do recurso mais um contador, algo como Lineage=43e12f0f:5. Quando a função grava esse evento de volta em um serviço suportado usando um SDK suportado, o contador incrementa. Ao chegar a aproximadamente 16 invocações na mesma cadeia, o Lambda descarta a próxima e devolve RecursiveInvocationException. Não precisa ativar tracing do X-Ray e não há cobrança.

Três limites que a página de anúncio não enfatiza:

1. Cobertura por serviço. Só Lambda, SQS, SNS e S3. Se o loop passa por DynamoDB Streams, EventBridge, Kinesis ou Step Functions, o contador não viaja e nada é cortado. A própria documentação diz isso em uma frase, merecia um parágrafo.
2. Cobertura por SDK. O contador só propaga se a função usa versão mínima do SDK: Node.js 3.105.0 (v3), boto3 1.24.46, Java 2.20.81 no runtime 17, Go v2 1.57.0. Uma função Python que empacota um boto3 antigo no deployment package sai da proteção em silêncio.
3. Profundidade, não largura. O contador mede quantas vezes aquele evento invocou a função. Um loop de fan-out, uma invocação que gera três objetos, cada um gerando outra invocação, tem 16 níveis de profundidade, mas cada nível multiplica a largura. Dezesseis saltos com fator 3 são dezenas de milhões de invocações antes do corte. A detecção limita a cadeia; não limita a árvore.

O atraso do aviso: a notificação no Health Dashboard e o e-mail podem levar até 3,5 horas, e o e-mail é no máximo um por função a cada 24 horas. A métrica RecursiveInvocationsDropped sai na hora, é nela que o alarme tem que estar.

Cenário: função de 512 MB, 200 ms por execução, disparada por ObjectCreated no mesmo bucket em que grava. Sem reserved concurrency, o Lambda escala até a quota da conta: 1.000 de concorrência padrão em região comercial; no EUSC, confirme o valor na sua conta, porque quota lá costuma passar por ticket. Uso preço de lista das regiões comerciais como proxy; o EUSC tem tabela própria e você deve conferir antes de fechar o número.

Sem guardrail nenhum: 1.000 execuções concorrentes de 200 ms são 5.000 invocações por segundo. Cada uma custa cerca de US$ 0,0000019 em compute mais US$ 0,000005 de PutObject no S3, o PUT custa mais que a função. São cerca de US$ 0,035 por segundo, ou US$ 125 por hora. Nas 3,5 horas que o Health Dashboard pode levar para avisar, a conta chega a US$ 440. Em uma noite de sexta, passa de US$ 1.500 antes de alguém abrir o e-mail. Não é catastrófico para um banco; é o suficiente para virar item de auditoria e pergunta do CFO.

Só com detecção nativa: o loop simples morre em 16 invocações, centavos. O loop de fan-out não: 16 níveis com fator 3 são 3^16 ≈ 43 milhões de invocações, e a detecção corta cada cadeia individual só quando ela chega ao nível 16. A conta volta ao cenário anterior, agora limitada pelo tempo até a árvore se esgotar.

Com reserved concurrency de 50: o pior caso cai para 250 invocações por segundo: US$ 6 por hora. As 3,5 horas de atraso custam US$ 22. É esse número que me deixa dormir: a detecção nativa corta a cadeia; a concorrência reservada limita a largura; nenhuma das duas sozinha limita o custo.

A lição: cada guardrail atua em uma dimensão, profundidade, largura ou existência do loop. Empilhar os três não é redundância; é cobrir três eixos diferentes do mesmo problema.

Estado da detecção como código: PutFunctionRecursionConfig aceita Allow ou Terminate, e o padrão é Terminate. Declare explicitamente em SAM ou CloudFormation e coloque um SCP ou uma policy de pipeline negando lambda:PutFunctionRecursionConfig fora do papel de plataforma. Quem precisar de Allow, um crawler que se reenfileira de propósito, justifica em ADR e recebe reserved concurrency baixa como contrapartida. Lembre que com Allow a métrica RecursiveInvocationsDropped não é emitida: você perde o sinal junto com a proteção.

Alarme na métrica certa: RecursiveInvocationsDropped com Statistic: Sum, período de 60 segundos, threshold >= 1, uma avaliação. Não espere o Health Dashboard. Ao lado, ConcurrentExecutions por função com threshold em 80% da reserved concurrency, é o alarme que pega o fan-out e o loop via DynamoDB que a detecção não vê.

SQS como fonte: configure a DLQ na fila fonte, não na função. A DLQ da função vale só para invocação assíncrona. E entenda a interação: após a detecção, o RecursiveInvocationException incrementa o receiveCount a cada retentativa, então a mensagem só vai para a DLQ quando o maxReceiveCount da redrive policy estoura. Um maxReceiveCount de 1.000 mantém a mensagem batendo na porta por horas: 5 é razoável para a maioria dos casos.

S3 como fonte: prefixo de entrada e prefixo de saída distintos, com o filtro de notificação apontando só para o de entrada. Bucket separado quando o compliance permitir; prefixo quando não. Nunca a mesma variável de ambiente para os dois, foi exatamente isso que me derrubou.

SDK: trave a versão mínima no package.json/requirements.txt e faça o pipeline falhar abaixo dela. É a única forma de a proteção não sumir em silêncio.