Apresentando destinos entre contas para o barramento de eventos do Amazon EventBridge | Cloud Computing

Este blog post foi escrito por Anton Aleksandrov, arquiteto principal de soluções da Serverless e Alexander Vladimirov, arquiteto sênior de soluções de Serverless.

Hoje, o Amazon EventBridge está anunciando suporte para destinos entre contas para seu barramento de eventos. Esse novo recurso permite que você envie eventos diretamente para destinos, como Amazon Simple Queue Service (Amazon SQS), AWS Lambda e Amazon Simple Notification Service (Amazon SNS), localizados em outras contas.

Anteriormente, o EventBridge suportava a entrega de eventos entre contas de um barramento de eventos em uma conta para um barramento de eventos em outra conta. Esse lançamento amplia essa capacidade e permite que você configure o barramento de eventos de origem para entregar eventos diretamente a todos os destinos compatíveis com o EventBridge em outras contas, não apenas aos barramentos de eventos. Isso elimina a necessidade de um barramento de eventos adicional na conta de destino.

Visão geral

As arquiteturas orientadas a eventos criadas com o EventBridge permitem que você crie soluções abrangendo muitos departamentos e domínios de negócios da empresa, permanecendo assíncronas e fracamente acopladas. À medida que as soluções crescem, talvez seja necessário enviar eventos além dos limites da conta.

Por exemplo, você pode ter um conjunto de barramentos de eventos hospedados em várias contas que estão enviando eventos relacionados à segurança para uma fila do Amazon SQS hospedada em uma conta centralizada para processamento e análise assíncronos adicionais.

Anteriormente, as regras do EventBridge permitiam que você definisse destinos na mesma conta. O único tipo de destino que suportava a entrega de eventos entre contas era outro barramento de eventos. Se você quisesse enviar eventos além dos limites da conta, precisaria criar barramentos de eventos nas contas de origem e de destino. Depois, você configuraria uma regra no barramento de eventos de origem para enviar eventos para o barramento de destino e outra regra no barramento de eventos de destino para entregar o evento a um destino desejado na conta de destino. Como alternativa, uma função do Lambda ou um tópico do SNS pode ser usado como um mecanismo de ponte para enviar eventos entre contas.

O diagrama a seguir ilustra uma arquitetura de entrega de eventos entre contas antes do novo recurso. Um componente de “ponte”, como outro barramento de eventos, tópico do SNS ou função do Lambda, era necessário para enviar eventos de uma conta para outra.

Com esse novo recurso do EventBridge, você pode entregar eventos diretamente do barramento de eventos de origem para os destinos desejados em diferentes contas. Isso simplifica a arquitetura e o modelo de permissão. Também reduz a latência em suas soluções orientadas por eventos, pois tem menos componentes processando eventos ao longo do caminho da origem aos destinos.

Configurando regras de entrega de destinos do EventBridge para entrega de eventos entre contas

A ativação da entrega de eventos entre contas deve ser feita com a segurança em mente. Você deve estabelecer confiança mútua entre a origem e o destino. As regras de barramento de eventos de origem devem ter uma função do AWS Identity and Access Management (IAM) que lhes permita enviar eventos para destinos específicos. Isso é possivel anexando uma função de execução aos destinos da regra de entrega.

Os destinos de entrega de eventos hospedados em contas diferentes devem ter uma política de acesso a recursos que permita explicitamente receber eventos da função de execução usada na conta de origem. Devido a esse requisito, você pode habilitar a entrega de eventos entre contas somente para destinos que suportem políticas de acesso a recursos, como filas do Amazon SQS, tópicos do Amazon SNS e funções do AWS Lambda.

Ter uma função do IAM na conta de origem e uma política de recursos na conta de destino permite que você tenha um controle refinado sobre quais atores (“principals”) podem usar a ação putEvents e sob quais condições. Você pode definir políticas de controle de serviço (SCPs) para definir limites organizacionais que determinam quem pode enviar e receber eventos em sua organização.

Conforme ilustrado no diagrama a seguir, considere que a Equipe A é proprietária da conta de origem (Conta A). A equipe A é responsável por configurar o barramento de eventos de origem, sua função de execução, regras e destinos. As equipes B e C são proprietárias das contas de destino (Conta B e Conta C, consequentemente). Ambas as equipes gerenciam suas respectivas contas-destino. Por exemplo, criar destinos de entrega, como filas do SQS, e conceder permissões para aceitar eventos do barramento de eventos na conta de origem. Essa abordagem permite que a equipe A gerencie o barramento de eventos de origem centralizado para outras equipes e as equipes B e C controlem quem pode enviar eventos para seus destinos. Ele fornece alto grau de controle geral e governança.

O exemplo a seguir descreve a configuração da entrega de eventos entre contas em uma fila do SQS. Você também pode aplicar a mesma técnica a outros tipos de destino, como funções do Lambda ou tópicos do SNS.

Consulte o diagrama a seguir para ver um layout arquitetônico conceitual e uma ordem de criação de recursos.

Supondo que o barramento de eventos de origem já exista, há três etapas gerais na configuração da entrega de eventos entre contas:

1. Conta de destino — crie o destino de entrega, como uma fila SQS.
2. Conta de origem — configure uma regra para entrega de eventos entre contas. Defina o ARN da fila SQS de destino da regra e anexe uma função de execução com permissões para enviar mensagens à fila SQS de destino.
3. Conta de destino — aplique uma política de recursos à fila SQS de destino, permitindo que a função de execução do barramento de eventos de origem envie eventos.

Mostrando a entrega entre contas em ação

Siga as instruções neste repositório do GitHub para provisionar a amostra em suas contas da AWS usando o AWS Serverless Application Model (AWS SAM). Uma regra de barramento de eventos na conta de origem envia eventos diretamente para uma fila SQS, uma função Lambda e um tópico do SNS em uma conta de destino. Você deve ter duas contas para que a amostra funcione.

Certifique-se de inserir um endereço de e-mail válido como valor SNSSubscriptionEmail e confirmar sua assinatura de e-mail quando a pilha de destino for implantada.

Após a implantação, abra o console do EventBridge na conta de origem. Navegue até o barramento de eventos recém-criado, que tem “SourceEventBus” em seu nome. Use a funcionalidade Enviar eventos para publicar eventos de amostra, conforme mostrado na captura de tela a seguir. Certifique-se de que a fonte de seus eventos esteja configurada como “teste”.

Valide se os eventos foram entregues com sucesso aos três destinos de várias contas. Abra a conta de destino em um navegador diferente ou em uma janela anônima:

1. Navegue até o console SQS. Abra a fila recém-criada, que tem “targetSQSqueue” em seu nome.
2. Escolha Enviar e receber mensagens e, em seguida, escolha Sondagem de mensagens. Você pode ver os eventos enviados na etapa anterior.

   

   Figura 7: Recebendo o evento de teste com o SQS

3. Navegue até o Amazon CloudWatch Logs. Abra o grupo de logs  da função Lambda recém-criada, que tem “targetLambdaFunction” em seu nome. Ele mostra os eventos enviados na etapa anterior.

   

   Figura 8: Recebendo o evento de teste com o Lambda

4. Verifique seu e-mail. Se você confirmou a assinatura do tópico do SNS durante a implantação do código de exemplo, ela mostra os eventos enviados na etapa anterior.

Conclusão

O novo recurso do EventBridge permite que você entregue eventos diretamente a destinos fora dos limites da conta. Esse recurso ajuda a simplificar suas arquiteturas orientadas a eventos, bem como a melhorar a latência, reduzindo o número de componentes que processam seus eventos enquanto eles viajam dos barramento de eventos para seus destinos.

Consulte a página de preços do EventBridge para saber mais sobre os custos de entrega de eventos entre contas.

Para obter documentação adicional, consulte a documentação do Amazon EventBridge. Obtenha o código de amostra usado neste blog neste repositório do GitHub.

Para obter mais recursos de aprendizado sem servidor, visite Serverless Land.

Este blog é uma tradução do conteúdo original em inglês (link aqui).

Autores

Tradutor

Daniel Abib é Arquiteto de Soluções Sênior e Especialista em Amazon Bedrock na AWS, com mais de 25 anos trabalhando com gerenciamento de projetos, arquiteturas de soluções escaláveis, desenvolvimento de sistemas e CI/CD, microsserviços, arquitetura Serverless & Containers e especialização em Machine Learning. Ele trabalha apoiando Startups, ajudando-os em sua jornada para a nuvem. https://www.linkedin.com/in/danielabib/

Revisor

Rodrigo Peres é arquiteto de soluções na AWS, com mais de 20 anos de experiência trabalhando com arquitetura de soluções, desenvolvimento de sistemas e modernização de sistemas legados.