Lambda passa a detectar loops recursivos também em event buses customizados do EventBridge

A AWS anunciou em 14 de outubro de 2026 que a detecção de loop recursivo do Lambda (recursive loop detection) passou a cobrir os Custom event buses do Amazon EventBridge. O recurso identifica automaticamente quando uma função Lambda é invocada em círculo por um serviço suportado e interrompe a execução antes que ela vire uma fatura inesperada.

A novidade mira um cenário bem conhecido de quem monta automação orientada a eventos: uma regra no EventBridge aciona uma função Lambda e, por erro de configuração ou defeito no código, essa mesma função publica de volta um evento que casa com a regra original. O resultado é um ciclo que se realimenta sozinho, sem limite natural, consumindo invocações e gerando custo enquanto ninguém percebe.

O que muda na prática

Até este anúncio, a detecção de recursão do Lambda já cobria chamadas recursivas disparadas por outros serviços suportados pela AWS. A diferença agora é que os Custom event buses do EventBridge, usados para construir fluxos de automação e agendar tarefas recorrentes sem gerenciar infraestrutura, entram nessa lista.

O funcionamento é direto: quando o Lambda identifica que uma Event Function está sendo re-invocada recursivamente por uma regra em um Custom bus, ele interrompe o loop automaticamente. Em seguida, envia uma notificação pelo AWS Health Dashboard com instruções de troubleshooting, para que o time responsável consiga localizar a regra ou o trecho de código que causou a recursão.

Quem usa Lambda com EventBridge precisa saber disso

Para quem já arquiteta pipelines de eventos com EventBridge e Lambda, a mudança fecha uma lacuna real. Arquiteturas orientadas a eventos costumam ter várias regras publicando e consumindo no mesmo bus, e é fácil uma mudança de schema ou uma regra mal escrita fazer uma função republicar um evento que ela mesma deveria apenas processar.

Antes desta atualização, esse tipo de loop em um Custom bus podia rodar sem freio automático, multiplicando invocações do Lambda e, dependendo do volume de eventos, gerando uma conta de EventBridge e Lambda bem acima do esperado antes que alguém no time notasse o padrão nos logs ou no billing.

Em resumo: a proteção passa a existir por padrão, sem exigir instrumentação adicional, alarme de custo ou revisão manual de regras para quem já usa Custom event buses como gatilho de funções.

Como fica a configuração

O recurso está habilitado por padrão em todas as contas AWS, em todas as regiões comerciais onde os Custom event buses do EventBridge estão disponíveis. Não é preciso ativar nada: a cobertura passa a valer automaticamente para as Event Functions que recebem eventos desses buses.

Há, porém, casos legítimos de recursão intencional, como pipelines que reprocessam o mesmo evento em etapas controladas. Para esses cenários, a AWS disponibiliza a API PutFunctionRecursionConfig, que permite desligar a detecção de loop recursivo função por função:

• A configuração é feita por função Lambda, não para a conta inteira.
• A recomendação é só desligar nas funções onde o comportamento recursivo é parte deliberada do design, mantendo a proteção ativa no restante.

O que ainda fica em aberto

O anúncio da AWS não detalha limites de volume de eventos, latência até a detecção interromper o loop, nem se há algum custo cobrado pelas invocações que ocorrem entre o início da recursão e o momento em que o Lambda a identifica. Também não há, no material divulgado, lista completa de quais serviços de evento já eram cobertos antes do EventBridge Custom bus entrar nessa proteção.

Para quem administra funções Lambda acionadas por regras de EventBridge, vale revisar agora, mesmo sem nenhuma ação obrigatória, se alguma das Event Functions em produção depende de comportamento recursivo intencional: é nelas que a configuração via PutFunctionRecursionConfig precisa ser aplicada antes que a proteção padrão corte um fluxo que, neste caso, era proposital.

Fonte: AWS What's New