O blog da AWS

Arquitetura de failover orientada a eventos multi-região com Amazon EventBridge e Route 53

Por Napoleone Capasso e Fabio Frezza, Cloud Operations Architects na Amazon Web Services.

Arquiteturas orientadas a eventos permitem que aplicações respondam a eventos em tempo real, proporcionando escalabilidade e acoplamento fraco entre componentes. No entanto, garantir alta disponibilidade em múltiplas regiões AWS requer um design cuidadoso de mecanismos de failover. Este post demonstra como construir uma arquitetura resiliente orientada a eventos multi-região usando Amazon EventBridge, Amazon API Gateway e failover baseado em health check do Amazon Route 53.

Visão geral

Organizações que constroem aplicações orientadas a eventos precisam alcançar alta disponibilidade e capacidades de recuperação de desastres. Esta arquitetura fornece failover automático entre regiões AWS mantendo independência regional para processamento de eventos. A solução usa health checks do Amazon Route 53 para monitorar endpoints regionais do Amazon API Gateway e roteia automaticamente o tráfego para regiões íntegras sem intervenção manual.

A arquitetura oferece vários benefícios principais. A independência regional reduz a latência ao processar eventos na mesma região onde se originam. As tabelas globais do Amazon DynamoDB fornecem replicação automática de dados entre regiões, garantindo disponibilidade de dados durante falhas regionais. A solução fornece capacidades robustas de failover mantendo simplicidade arquitetural.

Organizações com requisitos rigorosos de disponibilidade podem achar esta solução particularmente valiosa. Todo o processamento de eventos permanece dentro das regiões AWS, e o failover ocorre automaticamente com base nos resultados das health checks. A arquitetura suporta tanto janelas de manutenção planejadas quanto interrupções regionais não planejadas, proporcionando flexibilidade para necessidades operacionais.

Visão geral da solução

A solução implementa uma arquitetura multi-região ativo-passivo onde eventos fluem através do Amazon API Gateway para event buses regionais do Amazon EventBridge. As health checks do Amazon Route 53 monitoram a região primária e roteiam automaticamente o tráfego para a região secundária durante falhas. Cada região processa eventos independentemente, enquanto as Tabelas Globais do Amazon DynamoDB replicam dados entre regiões.

O diagrama a seguir fornece uma visão geral da solução:

O diagrama acima representa a arquitetura multi-região executando em duas regiões AWS. O serviço DNS Route 53 serve como o ponto de entrada principal para a aplicação, com health checks monitorando ambas as regiões. Cada região contém uma stack idêntica com Amazon API Gateway, Amazon EventBridge, Amazon SQS e AWS Lambda. A Tabela Global do Amazon DynamoDB replica dados entre regiões automaticamente.

Implantação da solução

Para implantar esta solução, siga as instruções no repositório GitHub e clone o repositório. A solução é implantada em duas regiões AWS. Certifique-se de que certificados SSL válidos existam no AWS Certificate Manager (ACM) em ambas as regiões para o custom domain.

Pré-requisitos

Para este passo a passo, os seguintes recursos são necessários:

  • Conta AWS: Uma conta AWS com permissões para criar e gerenciar recursos do Amazon API Gateway, Amazon EventBridge, Amazon SQS, AWS Lambda, Amazon DynamoDB, Amazon Route 53, AWS IAM e AWS CloudFormation
  • AWS Serverless Application Model (SAM): A CLI do AWS SAM instalada, pois os templates usam a transformação SAM para definições de recursos Lambda e API Gateway
  • Nome de Domínio: Um domínio registrado com uma hosted zone no Route 53
  • Certificados SSL: Certificados ACM para o custom domain em ambas as regiões de implantação
  • AWS CLI: A AWS CLI instalada e configurada com credenciais para a conta AWS de destino
  • Seleção de Região: Duas regiões AWS para implantação

Passo a passo

Os templates do AWS CloudFormation do repositório GitHub de exemplo criam uma arquitetura segura multi-região que fornece failover automático para aplicações orientadas a eventos. Os templates provisionam endpoints regionais do API Gateway, event buses do EventBridge, filas SQS, funções Lambda e uma Tabela Global do Amazon DynamoDB. A solução estabelece monitoramento de integridade através de health checks do Route 53 e configura roteamento de failover DNS. Os templates usam a transformação AWS Serverless Application Model (SAM) para simplificar as definições de recursos Lambda e API Gateway.

Passo 1: Implantar a stack primária

A stack primária cria os recursos fundamentais na região primária. Isso inclui o event bus do Amazon EventBridge, Amazon API Gateway com custom domain, health check, função AWS Lambda, fila Amazon SQS e Tabela Global do Amazon DynamoDB. A stack cria um event bus do EventBridge que recebe eventos do API Gateway:

EventBus: 
Type: AWS::Events::EventBus 
Properties: 
Name: !Ref EventBusName

O API Gateway usa integração de serviço AWS para encaminhar eventos diretamente ao EventBridge:

x-amazon-apigateway-integration: 
type: "aws" 
uri: !Sub "arn:aws:apigateway:${AWS::Region}:events:path//" 
credentials: !GetAtt ApiGatewayEventBridgeRole.Arn 
httpMethod: "POST"

A health check monitora o endpoint do API Gateway para determinar a disponibilidade regional:

DomainHealthCheck: 
Type: AWS::Route53::HealthCheck 
Properties: 
HealthCheckConfig: 
Type: HTTPS 
ResourcePath: /Prod/health FullyQualified
DomainName: !Sub ${Api}.execute-api.${AWS::Region}.amazonaws.com 
Port: 443 
RequestInterval: 30 
FailureThreshold: 3

O registro DNS do Route 53 configura roteamento de failover com a designação PRIMARY:

ApiDnsRecord:
Type: AWS::Route53::RecordSet
Properties:
HostedZoneId: !Ref HostedZoneId
Name: !Ref CustomDomainName
Type: A
SetIdentifier: primary-region
Failover: PRIMARY
HealthCheckId: !Ref DomainHealthCheck

A Tabela Global do DynamoDB cria réplicas em ambas as regiões:

DataTable: 
Type: AWS::DynamoDB::GlobalTable 
Properties: 
BillingMode: PAY_PER_REQUEST 
Replicas: 
- Region: !Ref AWS::Region 
- Region: !Ref SecondaryRegion

Anote o valor de saída `DataTableName` para uso na implantação da stack secundária. A saída `CustomDomainURL` fornece o endpoint para invocar a solução.

Passo 2: Implantar a stack secundária

A stack secundária cria recursos idênticos na região secundária, exceto pela tabela Amazon DynamoDB que referencia a Tabela Global existente. A stack secundária cria seu próprio event bus do Amazon EventBridge, Amazon API Gateway, health check, função AWS Lambda e fila Amazon SQS. O registro DNS do Route 53 usa a designação SECONDARY

Passo 3: Fluxo de processamento de eventos

Os eventos fluem através do pipeline de processamento em cada região. O API Gateway recebe eventos e os encaminha ao EventBridge usando a API PutEvents. O EventBridge avalia regras de eventos e roteia eventos correspondentes para filas SQS. As funções Lambda fazem polling das filas SQS e processam eventos em lotes. O AWS Lambda grava dados processados na Tabela Global do DynamoDB, que replica entre regiões.

A função Lambda processa eventos da fila e grava no DynamoDB:

def handler(event, context): 
for record in event.get('Records', []): 
body = json.loads(record['body']) 
detail = body.get('detail', {}) 
event_id = body.get('id', '') 
item = { 'id': event_id, 'detail': detail, 'timestamp': datetime.utcnow().isoformat() } 
table.put_item(Item=item)

Testes

Obtenha a URL do custom domain e teste-a enviando um evento:

curl -X POST https://api.example.com \-H "Content-Type: application/json" \ -d '{ "Detail": { "IsHelloWorldExample": "true" }, "DetailType": "POSTED", "Source": "demo.event" }' -v

A resposta inclui um cabeçalho `X-Region` indicando qual região processou a solicitação. Em condições normais, isso mostra a região primária.

Para testar o failover:

  1. Remova o base path mapping para a região primária:
aws apigateway delete-base-path-mapping \ --domain-name api.example.com \ --base-path '(none)' \ --region {primary-region}
  1. Exclua o stage do API Gateway primário:

aws apigateway delete-stage \ --rest-api-id <primary-api-id> \ --stage-name Prod \ --region {primary-region}

  1. Aguarde 2-3 minutos para que a health check falhe. A health check do Route 53 realiza verificações a cada 30 segundos com um failure threshold de 3, exigindo 90 segundos para detectar a falha.
  2. Envie outra solicitação para o endpoint da API:
curl -X POST https://api.example.com \-H "Content-Type: application/json" \ -d '{ "Detail": { "IsHelloWorldExample": "true" }, "DetailType": "POSTED", "Source": "demo.event" }' -v
  1. Verifique o failover: O cabeçalho `X-Region` agora mostra a região secundária, confirmando o failover bem-sucedido.

Verifique o processamento de eventos na região secundária:

  1. Verifique os logs do Lambda para processamento bem-sucedido:

aws logs tail /aws/lambda/<secondary-lambda-name> --region {secondary region}

Você deve ver entradas de log semelhantes a:

Processing message: 
{"version":"0",
"id":"abc12345-...",
"source":"demo.event",
"detail-type":"POSTED",...} 
Event Source: demo.event
Detail Type: POSTED
Successfully wrote item to DynamoDB: abc12345-... 
Successfully read item from DynamoDB: 
{'id': 'abc12345-...', 
'source': 'demo.event', 
'detailType': 'POSTED', 
'detail': 
{'data': {'IsHelloWorldExample': 'true'}, 
...}, 
'timestamp': '2025-01-15T18:30:00.000000', 
'processed': True}
  1. Verifique os dados no Amazon DynamoDB:

aws dynamodb scan \ --table-name <table-name> \ --region {secondary region}

Os resultados da varredura devem incluir itens com os detalhes do evento:

{ "Items": 
[ { "id": {"S": "abc12345-..."}, 
"source": {"S": "demo.event"}, 
"detailType": {"S": "POSTED"},
"detail": 
{"M": {"data": 
{"M": 
{"IsHelloWorldExample": 
{"S": "true"}}}}}, 
"timestamp": {"S": "2025-01-15T18:30:00.000000"},
"processed": {"BOOL": true} } ], 
"Count": 1 }
  1. Restaure a região primária – recrie o stage:

aws apigateway create-stage \ --rest-api-id <primary-api-id> \ --stage-name Prod \ --deployment-id <deployment-id> \ --region {primary region}

  1. Restaure a região primária – recrie o base path mapping:

aws apigateway create-base-path-mapping \ --domain-name api.example.com \ --rest-api-id <primary-api-id> \ --stage Prod \ --region {primary region}

Você pode encontrar o “deployment-id” executando: aws apigateway get-deployments \ --rest-api-id <primary-api-id> \ --region {primary region}

Após 2-3 minutos, a health check passa e o Route 53 roteia o tráfego de volta para a região primária.

Limpeza

Para remover a solução e evitar cobranças contínuas, exclua as stacks do CloudFormation na ordem correta. Exclua a stack secundária primeiro, depois a stack primária. Esta ordem é importante porque a Tabela Global do Amazon DynamoDB pertence à stack primária. Aviso: A exclusão dessas stacks remove permanentemente todos os recursos incluindo a tabela global do Amazon DynamoDB e quaisquer dados de eventos armazenados nela. Faça backup de quaisquer dados que você precise antes de prosseguir. Esta ação não pode ser desfeita. Os seguintes recursos incorrem em custos enquanto implantados:

  • Amazon API Gateway (REST API)
  • Health checks e registros DNS do Amazon Route 53
  • Tabela global do Amazon DynamoDB (com replicação entre regiões)
  • Invocações e duração de função AWS Lambda
  • Operações de fila Amazon SQS
  • Armazenamento do Amazon CloudWatch Logs

Exclua a stack secundária:

aws cloudformation delete-stack --stack-name secondary-stack --region {secondary region}

Aguarde a conclusão da exclusão da stack secundária:

aws cloudformation wait stack-delete-complete --stack-name secondary-stack --region {secondary region}

Exclua a stack primária:

aws cloudformation delete-stack --stack-name primary-stack --region {primary region}

Aguarde a conclusão da exclusão da stack primária:

aws cloudformation wait stack-delete-complete --stack-name primary-stack --region {primary region}

Isso remove todos os recursos incluindo os event buses do Amazon EventBridge, Amazon API Gateways, funções AWS Lambda, filas Amazon SQS, Tabela Global do Amazon DynamoDB, health checks do Amazon Route 53, registros DNS e roles do IAM.

Conclusão

Este post demonstra como estabelecer uma arquitetura resiliente multi-região para aplicações orientadas a eventos usando Amazon EventBridge, Amazon API Gateway e Amazon Route 53. A solução usa failover baseado em integridade do Route 53, uma capacidade poderosa que roteia automaticamente o tráfego para regiões íntegras com base nos resultados das health checks. Esta arquitetura melhora significativamente a disponibilidade da aplicação ao fornecer failover automático durante interrupções regionais mantendo independência regional para processamento de eventos.

Este conteúdo foi traduzido do post original do blog, que pode ser encontrado aqui.

Autores

Napoleone Capasso é Cloud Operations Architect na Amazon Web Services.
Fabio Frezza é Cloud Operations Architect na Amazon Web Services.

Tradutores

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/
Nicolas Tarzia é Senior Technical Account Manager na AWS, com mais de 13 anos de experiência, com ampla experiência em arquitetura cloud, engenharia e design de software. Atualmente está habilitando empresas do ramo de ISV (Independent Software Vendors) simplificando a operação na nuvem e otimizando os custos em cloud. Sua área de interesse são tecnologias serverless.
https://www.linkedin.com/in/nicolastarzia