Diagrama de arquitetura AWS multi-região de alta disponibilidade

A maioria dos diagramas de arquitetura AWS multi-região falha do mesmo jeito: duas caixas idênticas com os rótulos us-east-1 e eu-west-1, lado a lado, sem nada entre elas. Parece alta disponibilidade, mas não responde a nenhuma das perguntas que um revisor ou quem está de plantão vai fazer. Para onde vão as escritas? Em que direção os dados são replicados? O que move o tráfego quando uma região degrada, e quem ou o que decide isso? Este post mostra o que o diagrama precisa conter, como active-active e active-passive se diferenciam no papel e como desenhar tudo no Archboard a partir de um exemplo gratuito.

O que um diagrama de arquitetura AWS multi-região precisa mostrar

Leia o diagrama de cima para baixo, no caminho que uma requisição percorre.

1. Entrada global: Route 53 e CloudFront

• Amazon Route 53 fica acima das duas regiões, não dentro de uma delas. Coloque a política de roteamento no rótulo da aresta: failover (registros primário e secundário ligados a health checks), latency-based (cada usuário vai para a região de menor latência) ou weighted. Desenhe também os health checks: o roteamento de failover só funciona se eles existirem.
• Amazon CloudFront fica na frente das origens regionais. Se você usa um origin group com origin failover, desenhe as duas origens e marque qual é a primária. O origin failover do CloudFront vale para requisições GET, HEAD e OPTIONS; escritas precisam de um caminho próprio.

2. Entrada regional: Application Load Balancer

Um ALB é um recurso regional que abrange as Availability Zones que você habilita para ele. Desenhe um por região, dentro do limite da região, com alvos em pelo menos duas AZs.

3. Compute distribuído entre Availability Zones

Serviços do Amazon ECS, node groups do Amazon EKS ou grupos do EC2 Auto Scaling, o que rodar a sua aplicação, distribuídos em dois ou três frames de AZ. O diagrama precisa deixar um ponto claro: a perda de uma AZ é tratada dentro da região, e a perda de uma região é tratada pela camada global.

4. A camada de dados, com setas

É aqui que a maioria dos diagramas fica em silêncio. Cada armazenamento de dados tem seu próprio modelo de replicação, e a direção da seta conta a história inteira.

Acrescente uma nota: as regras de replicação do S3 se aplicam a objetos novos; objetos que já existiam antes da regra precisam do S3 Batch Replication. Alguém vai perguntar.

5. Segredos e configuração

O AWS Secrets Manager pode replicar um segredo para outras regiões, e o AWS KMS suporta chaves multi-Region. O Systems Manager Parameter Store é regional. Desenhe de onde cada região lê seus segredos e sua configuração. Um failover que funciona até a aplicação não conseguir descriptografar a senha do banco não é um failover.

6. Observabilidade e plano de controle

Mostre o que detecta uma falha e o que age sobre ela: health checks do Route 53, alarmes do CloudWatch em cada região, canaries sintéticos e um dashboard entre regiões. Se o failover é disparado por routing controls do Amazon Application Recovery Controller (ARC) ou por um runbook, coloque isso no diagrama também. O pilar de confiabilidade do AWS Well-Architected recomenda contar com operações do plano de dados, e não com mudanças no plano de controle, durante a recuperação. O failover de DNS guiado por health checks é um exemplo do primeiro tipo, e o diagrama é o lugar certo para mostrar de qual você depende.

Active-active vs active-passive

A AWS descreve quatro estratégias de recuperação de desastres. Três delas rodam algo numa segunda região, e cada uma muda o que o diagrama precisa dizer.

Os números são definidos por você. Escreva suas metas de RTO e RPO no canvas, ao lado da estratégia, para que o diagrama e o requisito de negócio possam ser conferidos um contra o outro.

Active-active não é automaticamente melhor. Ele elimina a etapa de promoção, mas obriga você a decidir como cada armazenamento lida com escritas concorrentes. No Aurora Global Database só uma região escreve por vez, então um design active-active construído sobre ele continua tendo uma única região de escrita. Desenhe isso com sinceridade.

Deixe o caminho de failover explícito

Use três estilos de aresta e explique-os numa legenda:

• Caminho de requisições: setas contínuas dos usuários passando por DNS, CDN, ALB e compute.
• Replicação: setas tracejadas entre armazenamentos de dados, com direção e modo (async, multi-active).
• Failover: um caminho separado e rotulado que mostra para onde o tráfego vai quando a região primária não está saudável.

Depois numere a sequência de failover numa nota no canvas:

1. Route 53 health check on primary ALB fails
2. Route 53 failover record answers with the secondary region
3. Aurora secondary cluster is promoted to writer (global database failover)
4. ECS service / Auto Scaling group in the secondary region scales out
5. Alarms confirm traffic and error rates in the secondary region

Se uma etapa é manual, diga quem a executa. Se uma etapa depende de uma API do plano de controle, marque-a.

Erros comuns

• Uma região desenhada duas vezes sem fluxo de dados. Duas cópias da mesma stack sem setas de replicação não dizem nada sobre recuperação.
• Esconder o plano de controle. Health checks, routing controls e runbooks decidem se o failover acontece. Sem eles, o diagrama descreve um sistema que não consegue fazer failover.
• Nenhuma seta de failover. O caminho de requisições em operação normal é só metade da história.
• Serviços globais desenhados dentro de uma região. Route 53 e CloudFront são globais; colocá-los dentro de um frame de região sugere uma dependência que não existe, ou esconde uma que existe.
• Sem AZs. Redundância no nível de região não substitui redundância no nível de AZ; mostre as duas.
• Estado esquecido. Caches, filas e armazenamentos de sessão também são regionais. Mostre onde ficam e o que acontece com eles.

Como montar no Archboard

No Archboard você monta isso com nós dos packs Cloud e Network: nós de primeira classe com portas, que você rotula com os nomes dos serviços da AWS. Assim, cada caixa mostra tanto o seu papel quanto o serviço exato. Veja como montar o diagrama.

1. Estude o modelo gratuito. Abra /examples/multi-region-cloud-ha. Ele mostra uma CDN, um load balancer em duas regiões, compute e um banco de dados gerenciado entre regiões. Use-o como referência ou copie-o para o seu espaço de trabalho com Usar este exemplo e depois amplie com as camadas acima.
2. Crie os limites de região e de AZ. Adicione dois frames Region do pack Cloud com os rótulos us-east-1 (primary) e eu-west-1 (secondary). Dentro de cada um, adicione elementos Frame do pack Core para as AZs.
3. Coloque a camada global acima das regiões. Internet do pack Network para os usuários, DNS do pack Network com o rótulo Route 53 (failover routing) e CDN do pack Cloud com o rótulo CloudFront.
4. Preencha cada região. Cloud LB do pack Cloud com o rótulo ALB, nós Compute em cada frame de AZ com ECS service ou EC2 Auto Scaling group (ou um nó Kubernetes Cluster para EKS), nós Managed DB com Aurora (writer) e Aurora (secondary, read-only), outro para DynamoDB global table, e Object Storage com o rótulo S3.
5. Conecte as portas e rotule cada aresta. Caminho de requisições, direção e modo de replicação, caminho de failover. Use os rótulos das arestas para a política de roteamento e o tipo de replicação.
6. Adicione o plano de controle e as notas. Nós Box do pack Core para Secrets Manager, CloudWatch e health checks; uma Note com a sequência de failover numerada; um bloco Markdown com suas metas de RTO e RPO e a estratégia escolhida.

Conte seus nós antes de começar: um mapa completo de duas regiões costuma passar dos 15 nós de diagrama por diagrama do plano Free (notas e textos contam à parte, até 150), então o Pro é a escolha natural, com nós ilimitados, incorporação no seu site de documentação e exportação em PDF. Mais padrões estão na página do caso de uso de cloud.

Perguntas frequentes

Posso usar os ícones oficiais da AWS no Archboard? Os nós Cloud e Network tipados do Archboard são independentes de provedor, mas você pode adicionar logos da AWS pesquisando no Iconify com o nó Icon do pack Core (por exemplo logos:aws-route53) ou enviar os AWS Architecture Icons oficiais como imagens. Rotule cada nó com o nome do serviço da AWS, como Route 53 ou Aurora Global Database, e o diagrama fica claro para qualquer pessoa que conheça a AWS.

Devo desenhar regiões e AZs? Sim. As AZs mostram como você sobrevive à falha de uma zona; as regiões, como você sobrevive a uma falha regional. São modos de falha diferentes, com mecanismos diferentes.

Active-active ou active-passive? Comece pelas suas metas de RTO e RPO e pelo seu modelo de dados. Se o seu banco principal tem uma única região de escrita, active-passive (pilot light ou warm standby) costuma ser o design mais simples e mais fiel à realidade. Escreva a decisão no diagrama.

Como compartilho? Exporte em SVG ou PNG (com marca d'água no Free), compartilhe um link público ou incorpore na sua documentação com o Pro.

Comece grátis — um assento, sem cartão de crédito