EventBridge ganha event bus customizado aprimorado, compartilhado entre contas da organização

A AWS anunciou, no AWS News Blog, um novo tipo de recurso dentro do Amazon EventBridge: o Custom event bus aprimorado, pensado para quem já passou do estágio de "uma equipe, uma conta, um bus" e está tentando fazer arquitetura orientada a eventos funcionar em escala, com dezenas de contas AWS e times publicando e assinando eventos uns dos outros. Quem desenha esse tipo de arquitetura, o arquiteto de soluções e o engenheiro de DevOps/SRE que mantém a malha de eventos no ar, vai reconhecer o problema que o anúncio descreve antes de chegar à solução.

O problema que gerou isso

A recomendação de boas práticas da própria AWS é estrutura multi-conta: cada time roda na sua conta. Só que, para rotear eventos entre contas, a solução até agora era multiplicar event buses customizados e conectá-los com regras cross-account ou configurações bus-to-bus. Isso recria exatamente a complexidade operacional que a arquitetura serverless deveria eliminar.

O texto da AWS é direto sobre as consequências desse padrão:

• Times de plataforma perdem visibilidade de quem está assinando qual evento
• As tarifas de roteamento cross-account e bus-to-bus se acumulam rápido conforme a malha cresce
• Times que precisam de ordenação de eventos ficam forçados a workarounds complexos ou a trocar de tecnologia

Um bus só, compartilhado via AWS RAM

A mudança central é organizacional antes de ser técnica: em vez de múltiplos buses interligados, o time de plataforma cria um único Custom event bus e compartilha com todas as contas da organização usando o AWS Resource Access Manager (AWS RAM). No console, isso aparece como a opção recomendada ao criar um bus, com o rótulo "New", ao lado da opção Custom event bus – classic, que continua existindo para quem já tem workloads rodando no modelo antigo.

O fluxo prático, descrito no blog, é configurar o compartilhamento marcando Enable event bus sharing e escolhendo Allow sharing only within your organization. O tipo de principal pode ser uma conta AWS específica, uma organização inteira, uma unidade organizacional ou um papel/usuário IAM. Não há necessidade de montar permissões cross-account nem rotas bus-to-bus manualmente: o RAM cuida disso.

Com isso, publishers enviam eventos sem precisar saber quem consome, e cada subscriber cria sua própria inscrição de forma independente, sem esperar provisionamento de infraestrutura. O time de plataforma mantém visibilidade central e controle fino de quem publica e quem consome. A cota padrão é de 10.000 Subscribers por bus (ampliável sob pedido), o que reduz a fragmentação que antes forçava a divisão em vários buses só por limite de assinantes.

Ordenação de eventos com EventGroupId

Arquitetura orientada a eventos costuma funcionar melhor quando o consumidor não depende da ordem de chegada. Mas há exceções reais: o exemplo que a AWS usa é uma aplicação de logística, em que atualizações de localização de motorista precisam chegar em sequência, porque eventos fora de ordem fazem o algoritmo de roteamento decidir com base em dado obsoleto.

O Custom event bus aprimorado suporta os dois padrões no mesmo bus. O publisher inclui um EventGroupId ao enviar o evento, e o EventBridge entrega em sequência, para os Subscribers que escolherem ordered delivery, tudo que compartilha o mesmo EventGroupId. Outros assinantes do mesmo bus continuam recebendo os eventos sem garantia de ordem, se for isso que precisam. Dá para manter o histórico de cada motorista em ordem correta sem reconstruir essa lógica na mão, enquanto o restante dos consumidores segue assíncrono.

Para sustentar esse processamento ordenado, o bus passa a oferecer invocação síncrona para alvos como o AWS Lambda: o EventBridge confirma o processamento bem-sucedido antes de reconhecer o evento como entregue. Isso elimina o padrão comum de colocar uma fila do Amazon SQS entre o event bus e o Lambda só para garantir confiabilidade de entrega.

Subscriber: um recurso em vez de três

Hoje, no modelo clássico, atingir o mesmo resultado que um Subscriber entrega exige configurar regra, target e política de retry como recursos separados. O novo Subscriber combina filtro de eventos, configuração de destino, política de retry e destino de dead-letter numa única unidade gerenciável. Cada consumidor passa a ter um recurso que define o que ele quer receber, para onde mandar e como tratar falha.

Os Subscribers também trazem opções de horário de início variável, o que facilita onboarding de novos consumidores ou replay de eventos para recuperar aplicações de erros ou popular (hydrate) aplicações novas sem reprocessar manualmente o histórico.

Deduplicação por conteúdo e reshape com JSONata

Publishers podem ativar deduplicação baseada em conteúdo: o EventBridge detecta e descarta retries do mesmo evento a partir do próprio payload, sem exigir que a fonte gere e rastreie um ID de deduplicação. O serviço faz hash das partes relevantes do evento e colapsa correspondências que chegam dentro de uma janela de cinco minutos, entregando semântica de exactly-once onde o padrão do EventBridge é at-least-once. Quem já carimba token de idempotência próprio não precisa trocar nada; o recurso serve para fontes que não conseguem identificar com segurança se um evento é retry do anterior.

Do lado do consumo, Subscribers podem usar expressões JSONata para reformatar um evento antes de ele chegar ao destino, extraindo campos, renomeando ou calculando valores novos quando a API de downstream espera um formato diferente. Para quem já produz eventos em Apache Avro ou Protocol Buffers, o EventBridge consegue desserializar esses payloads para JSON, permitindo filtragem e roteamento fino sobre o payload completo sem que o consumidor tenha que desserializar e descartar por conta própria.

O novo modelo de preço

A cobrança muda de modelo por evento para throughput de ingresso e egresso: publishers pagam pelos eventos ingeridos, subscribers pagam pelos eventos entregues. Isso substitui o esquema em que tarifas de roteamento cross-account e bus-to-bus se acumulavam em arquiteturas multi-bus. A AWS não detalhou valores no próprio post, remetendo à página de preços do EventBridge para os números atualizados.

Em resumo: quem hoje paga roteamento cross-account múltiplas vezes para o mesmo evento tende a ver economia ao consolidar em um bus só, mas o cálculo real depende do volume de subscribers simultâneos e vale a pena simular antes de migrar.

Onde já dá para usar, e onde ainda não dá

O recurso está disponível desde o anúncio (30 de outubro de 2026) nas regiões US East (N. Virginia, Ohio), US West (Oregon), Europe (Ireland, Frankfurt, Stockholm, Spain) e Asia Pacific (Hong Kong, Malaysia, Mumbai, Singapore, Sydney, Thailand, Tokyo). São Paulo (sa-east-1) não está na lista. Para quem opera infraestrutura AWS no Brasil e mantém o bus na região local por latência ou por exigência de residência de dados, isso significa esperar expansão de região antes de adotar o Custom event bus aprimorado em produção, ou rodar o bus em outra região enquanto o restante da stack fica em sa-east-1, o que tem custo de latência entre regiões a considerar.

As classic buses existentes continuam funcionando exatamente como antes, sem nenhuma mudança exigida, e passam a aparecer no console como Custom event bus – classic. O novo é um recurso à parte que se adota no próprio ritmo, via console, AWS CLI ou API do EventBridge.

Para quem vale a migração agora

Faz sentido avaliar o Custom event bus aprimorado para quem já opera mais de dois ou três event buses interligados por regras cross-account, sente dor real de visibilidade de quem assina o quê, ou precisa de ordenação de eventos e hoje resolve isso com fila na frente do Lambda só para garantir sequência. Para quem tem um único time, uma única conta e um bus clássico que nunca bateu limite de subscribers, a complexidade adicional de configurar RAM e revisar Subscribers provavelmente não compensa ainda, especialmente fora das regiões onde o recurso já está disponível.

Fonte: AWS News Blog