Amazon EventBridge ganha bus único para múltiplas contas, mas ainda não chega ao Brasil

A AWS↳AWS20 conteúdosE-mails de verificação com AWS SES + Lambda (Node.js) e Terraform: do zero ao envioDevSecOps · out 2025Codex na AWS: chegada do agente da OpenAI à nuvem da AmazonDevSecOps · abr 2026Salesforce e AWS ampliam colaboração em IA, CRM e marketplaceDevSecOps · nov 2023Ver tudo em DevSecOps → anunciou, no AWS News Blog, uma versão reforçada do custom event bus do Amazon EventBridge, pensada especificamente para o momento em que uma arquitetura orientada a eventos deixa de caber num time só. O anúncio parte de um diagnóstico que qualquer arquiteto que já escalou EventBridge além de uma squad reconhece na hora: o serviço nasceu redondo para um time, uma conta, um bus. Quando a organização cresce e adota a prática recomendada pela própria AWS de isolar cada time em sua própria conta, a solução vira um emaranhado de regras cross-account e configurações bus-to-bus que reintroduzem exatamente a complexidade operacional que a arquitetura serverless deveria eliminar.

O problema que o anúncio ataca

A descrição da AWS é direta: em cenários multi-conta, cada time acaba subindo seu próprio bus e conectando-os via regras cross-account ou roteamento bus-to-bus. O efeito colateral não é só burocracia de infraestrutura. O time de plataforma perde visibilidade sobre quem está assinando o quê, os custos de roteamento cross-account e bus-to-bus se acumulam rápido, e qualquer necessidade de ordenação de eventos força a equipe a construir gambiarras ou trocar de tecnologia. É o tipo de dívida técnica que só aparece depois que a arquitetura já está em produção e várias squads dependem dela, o que torna a migração cara e arriscada.

Como funciona o enhanced custom event bus

A proposta é um único bus compartilhado entre todas as contas de uma AWS Organization, com o compartilhamento resolvido via AWS Resource Access Manager (RAM). No console, ao criar um bus, agora existem duas opções: "Custom event bus" (a nova versão, recomendada) e "Custom event bus – classic", que mantém o comportamento atual baseado em regras e alvos. Ao ativar o compartilhamento, é possível liberar acesso por conta específica, por organização inteira, por unidade organizacional ou por role/usuário IAM, sem que o time de plataforma precise configurar permissões cross-account nem roteamento bus-to-bus manualmente.

Na prática, isso inverte o modelo mental: em vez de cada time abrir seu próprio bus e depender de integração ponto a ponto, publishers mandam eventos sem saber quem vai consumi-los, e cada subscriber cria sua própria assinatura de forma independente. O time de plataforma mantém visibilidade central e controle fino sobre quem publica e quem consome. O bus novo vem com quota padrão de 10.000 Subscribers, ajustável sob pedido, o que evita a fragmentação que hoje obriga a dividir a carga entre vários buses só por limite de assinantes.

Ordenação sem reinventar a roda

O ponto mais técnico do anúncio é a ordenação garantida, algo que o EventBridge clássico nunca ofereceu de forma nativa. A maioria dos sistemas orientados a eventos foi desenhada assumindo que ordem não importa, mas existem exceções relevantes: a própria AWS cita como exemplo uma aplicação de logística em que atualizações de localização de um motorista precisam chegar em sequência, porque eventos fora de ordem levam o algoritmo de roteamento a decidir com base em dado velho.

O enhanced bus resolve isso com um campo EventGroupId que o publisher inclui no evento. Eventos com o mesmo EventGroupId são entregues em sequência para os subscribers que optaram por entrega ordenada, enquanto outros subscribers no mesmo bus continuam recebendo os mesmos eventos de forma assíncrona, sem ordem garantida. É um detalhe de design interessante: ordenação deixa de ser propriedade do bus inteiro e passa a ser propriedade da assinatura, o que evita forçar todo mundo a pagar o custo de coordenação que só uma parte do sistema precisa.

Para sustentar esse modelo, o bus passou a suportar invocação síncrona em alvos como AWS Lambda, confirmando o processamento com sucesso antes de reconhecer o evento. Isso elimina o padrão comum de colocar uma fila do Amazon SQS entre o event bus e o Lambda só para garantir confiabilidade, um workaround que qualquer time que já operou EventBridge em produção provavelmente já implementou na unha.

Um recurso só em vez de três

A segunda mudança estrutural é o novo recurso Subscriber, que consolida filtro de eventos, configuração de alvo, política de retry e destino de dead-letter num único objeto gerenciável. Hoje, alcançar o mesmo resultado no EventBridge clássico exige configurar regras, alvos e políticas de retry como recursos separados, espalhados pela conta. Cada time de consumo passa a ter um único recurso que descreve o que ele quer receber, para onde entregar e como tratar falha, incluindo opções de horário de início variável, que facilitam tanto o onboarding de um novo consumidor quanto o replay de eventos para recuperar de erro de aplicação ou popular um sistema novo.

A AWS também adicionou deduplicação baseada em conteúdo: o publisher liga a opção e o EventBridge passa a fazer hash das partes relevantes do evento, descartando retentativas que cheguem dentro de uma janela de cinco minutos, sem que o time precise gerar e rastrear um ID de idempotência manualmente. Quem já stampa seu próprio token de idempotência não precisa trocar nada, essa opção é voltada para fontes que não conseguem garantir identificação confiável do mesmo evento numa retentativa.

Outra adição prática: subscribers agora podem usar expressões JSONata para reformatar um evento antes de entregá-lo, extraindo ou renomeando campos e computando valores quando a API de destino espera um formato diferente. E quem já produz eventos em Apache Avro ou Protocol Buffers ganha deserialização automática para JSON, permitindo filtragem e roteamento fino sobre o payload completo sem que o subscriber precise consumir, deserializar e descartar por conta própria.

O modelo de preço muda o cálculo

O enhanced bus troca o modelo por evento pelo modelo de throughput de ingress e egress: publishers pagam pelo volume ingerido, subscribers pagam pelo volume entregue. Isso substitui a cobrança por evento que, em arquiteturas multi-bus, se multiplicava a cada salto cross-account ou bus-to-bus. Para quem desenha a arquitetura, o efeito prático é que o custo de escala deixa de crescer com o número de saltos de roteamento e passa a ser função direta de volume publicado e volume consumido, o que facilita a atribuição de custo por time publicador e por time consumidor, algo que hoje exige planilha manual em qualquer organização com mais de dois ou três buses. Os detalhes de valor ficam na página de pricing do EventBridge, que a AWS não divulgou no próprio post.

O que muda para quem constrói no Brasil

Aqui está o ponto que qualquer time no Brasil precisa notar antes de comemorar: o enhanced custom event bus está disponível, por ora, em US East (Norte da Virgínia e Ohio), US West (Oregon), Europa (Irlanda, Frankfurt, Estocolmo, Espanha) e Ásia-Pacífico (Hong Kong, Malásia, Mumbai, Singapura, Sydney, Tailândia, Tóquio). A região São Paulo não está na lista. Quem opera sua carga principal em sa-east-1 por questão de latência ou de residência de dado vai continuar no bus clássico até a AWS expandir a disponibilidade, ou vai precisar avaliar se compensa centralizar o bus numa região fora do Brasil e pagar a latência extra de roteamento cross-region só para ganhar ordenação e Subscriber unificado.

Isso muda o cálculo de adoção: não é uma decisão de arquitetura pura, é uma decisão condicionada à geografia da infraestrutura. Times que já têm parte do stack em us-east-1 ou eu-west-1 por outros motivos (compliance, integração com parceiro, disponibilidade de serviço) têm caminho livre para pilotar o enhanced bus. Quem está 100% em São Paulo por exigência regulatória ou latência vai esperar, e essa espera não tem data anunciada pela AWS no post.

Quando vale a pena migrar, e quando não

O enhanced bus resolve um problema real de organizações grandes: visibilidade de quem consome o quê, custo de roteamento cross-account que se acumula, e ausência de ordenação nativa. Se a sua arquitetura já tem múltiplos buses conectados por regras cross-account só para simular um backbone único, ou se algum consumidor depende de ordem e hoje isso é resolvido com fila intermediária mais lógica de sequenciamento na aplicação, o novo modelo compensa a migração.

Se o seu EventBridge ainda é um bus só, de um time só, sem necessidade de ordenação, a mudança não traz ganho imediato: o bus clássico continua funcionando sem nenhuma alteração, e a AWS deixou claro que a adoção do enhanced bus é opcional e no ritmo de cada organização. Vale também considerar o novo modelo de preço por ingress/egress antes de migrar cargas de altíssimo volume: ele pode ser melhor ou pior que o modelo por evento dependendo do padrão de tráfego, e isso só se descobre comparando a fatura projetada com a página oficial de pricing, não com a promessa genérica de "economia em escala" do anúncio.

Fonte: AWS News Blog