Entender a infraestrutura global da AWS é fundamental para decisões de arquitetura: escolha de região, alta disponibilidade e latência percebida pelo usuário.
🎯 Para a certificação
Questões sobre regiões/AZs costumam avaliar se você sabe diferenciar requisitos de disponibilidade, latência, custo e conformidade — e escolher a estratégia correta (multi-AZ vs multi-region, RPO/RTO, e qual dos 4 padrões de DR se aplica a cada cenário).
Resumo
- Região (Region): área geográfica isolada composta por múltiplas Zonas de Disponibilidade.
- Zona de Disponibilidade (AZ): data center (ou conjunto de data centers) isolado dentro de uma região, com rede de baixa latência entre AZs da mesma região. Toda região da AWS tem, no mínimo, 3 AZs.
- Edge Location: ponto de presença da AWS usado por CloudFront, Route 53 e outros serviços de borda para reduzir latência e entregar conteúdo globalmente.
- RPO e RTO: as duas perguntas que determinam qual estratégia de disponibilidade/DR faz sentido — "quanto dado posso perder?" e "quanto tempo posso ficar fora do ar?".
Principais decisões influenciadas por essa topologia:
- onde hospedar cargas críticas;
- estratégia de recuperação (Multi-AZ vs Multi-Region, e qual dos 4 padrões de DR);
- uso de CDN/Edge para reduzir latência global;
- requisitos legais ou de soberania de dados.
1. Regiões vs AZs: responsabilidades e garantias
Regiões existem para isolar falhas geográficas e oferecer escolha de localização. AZs existem para isolar falhas dentro da região, permitindo arquiteturas de alta disponibilidade sem atravessar regiões.
- Multi-AZ: padrão para alta disponibilidade dentro de uma mesma região (ex: RDS Multi-AZ replica dados em AZ distinta automaticamente).
- Multi-Region: necessário quando queremos proteção contra falhas regionais inteiras, requisitos legais de residência de dados ou reduzir latência para usuários muito distribuídos.
1.1 Latência e consistência de rede
AZs dentro da mesma região possuem links de baixa latência e alta largura; isso permite replicação síncrona/assíncrona dependendo do serviço. Entre regiões a latência e o custo de transferência aumentam.
Decisão prática: prefira Multi-AZ para disponibilidade local e Multi-Region para tolerância a desastre que cobre perda de uma região inteira.
2. Edge Locations e CDN
Edge Locations são usados por serviços de borda (principalmente CloudFront) para cache e entrega de conteúdo. Eles não hospedam recursos primários — são caches e pontos de presença.
Quando usar CloudFront/Edge Locations:
- conteúdo estático (imagens, JS/CSS, arquivos S3) para reduzir latência global;
- reduzir carga e custo de requests diretas ao backend/região principal;
- aplicar WAF e regras de segurança na borda.
Vale reforçar por que "aplicar WAF na borda" está na mesma lista de "reduzir latência" — os dois surgem da mesma característica das edge locations: elas são o primeiro ponto de contato entre o usuário e a AWS, antes de qualquer coisa alcançar sua origem. Assim como faz sentido responder um request de conteúdo estático ali mesmo (evitando a viagem até a região principal), também faz sentido filtrar tráfego malicioso ali mesmo — um AWS WAF associado ao CloudFront inspeciona e bloqueia requisições (SQL injection, XSS, rate limiting, bloqueio por país/IP) diretamente na edge location mais próxima do atacante, antes que esse tráfego sequer saia em direção ao seu ALB/EC2/S3. O resultado é o mesmo princípio de "resolver o mais cedo possível na jornada da requisição": sua origem nunca chega a gastar CPU, banda ou custo processando (e depois rejeitando) uma requisição que já podia ter sido descartada na borda.
2.1 Local Zones e Wavelength Zones
Além das Edge Locations (que só fazem cache/borda), a AWS tem duas extensões de infraestrutura mais recentes, que hospedam computação de verdade mais perto do usuário:
- AWS Local Zones: uma extensão de uma região, colocada fisicamente mais perto de grandes centros populacionais, onde você pode rodar recursos EC2/EBS reais (não só cache) — usado quando uma aplicação precisa de latência de milissegundos únicos para usuários de uma cidade/área metropolitana específica, mas não justifica abrir uma região inteira ali.
- AWS Wavelength Zones: infraestrutura de computação embutida dentro da rede de operadoras de telecomunicações 5G, permitindo latência ultrabaixa para aplicações que se conectam via rede móvel (ex: realidade aumentada, jogos em nuvem, veículos autônomos).
💡 Diferença-chave para a prova: Edge Location só faz cache/CDN, não roda sua aplicação. Local Zone e Wavelength Zone rodam computação real (EC2) mais perto do usuário.
3. Critérios para escolher uma região
Use os seguintes critérios ao escolher a região para hospedar sua aplicação:
- Proximidade do usuário / latência — regra prática: quanto mais perto, menor latência.
- Requisitos de conformidade e soberania de dados — escolha a região que atende leis e políticas de dados locais. Exemplos:
- Setor público / governo: contratos governamentais frequentemente exigem, por lei, que dados de cidadãos fiquem fisicamente dentro do país (ex: um sistema de saúde pública brasileiro pode ser obrigado a usar
sa-east-1, não podendo usarus-east-1mesmo que seja mais barata). - LGPD/GDPR — dados pessoais de usuários no Brasil ou na UE podem ter exigências de processamento/armazenamento dentro de determinadas fronteiras, independentemente do setor da empresa.
- Setor público / governo: contratos governamentais frequentemente exigem, por lei, que dados de cidadãos fiquem fisicamente dentro do país (ex: um sistema de saúde pública brasileiro pode ser obrigado a usar
- Serviços e recursos disponíveis — nem todas as regiões têm todos os serviços (verifique disponibilidade de serviços e quotas).
- Custo — preços de instâncias, transporte de dados, armazenamento e serviços podem variar por região.
- Redundância geográfica desejada — se precisar de tolerância a desastre regional, planeje multi-region.
- Latência entre regiões — avalie latência inter-regiões se a arquitetura exigir replicação entre elas.
- Dependências de parceiros e integrações — alguns parceiros (marketplace, SaaS) funcionam apenas em determinadas regiões.
Exemplo de decisão
Uma aplicação com usuários majoritariamente no Brasil provavelmente deve usar sa-east-1 (São Paulo) para reduzir latência. Se houver necessidade de DR (Disaster Recovery) para perda regional, planeje uma réplica em us-east-1 ou eu-west-1 conforme custo e conformidade.
4. RPO e RTO — as duas perguntas que definem sua estratégia de DR
Antes de escolher qualquer ferramenta de recuperação de desastre, é preciso responder duas perguntas de negócio, não de tecnologia:
- RPO (Recovery Point Objective): quanto dado você pode se dar ao luxo de perder? Medido em tempo — "RPO de 1 hora" significa que, no pior caso, você aceita perder até 1 hora de dados desde o último ponto de recuperação válido.
- RTO (Recovery Time Objective): quanto tempo o sistema pode ficar fora do ar até voltar a funcionar? "RTO de 30 minutos" significa que, a partir do desastre, o sistema precisa estar operacional de novo em até 30 minutos.
Esses dois números — definidos pelo negócio, não escolhidos livremente pela engenharia — é que determinam qual arquitetura de DR faz sentido. Quanto mais próximos de zero RPO e RTO precisam ser, mais cara e complexa a solução se torna.
5. O espectro de estratégias de Disaster Recovery
A AWS descreve 4 padrões, numa progressão de custo/complexidade crescente e RPO/RTO decrescente:
| Estratégia | RPO/RTO típico | Como funciona | Custo relativo |
|---|---|---|---|
| Backup & Restore | Horas | Backups/snapshots armazenados (e replicados para outra região); em caso de desastre, você recria a infraestrutura do zero a partir do backup | Mais barato |
| Pilot Light | Dezenas de minutos | Um núcleo mínimo da infraestrutura (tipicamente o banco de dados, já replicando dados continuamente) fica sempre ativo na região de DR; o restante (servidores de aplicação) é provisionado só na hora do desastre | Baixo-médio |
| Warm Standby | Poucos minutos | Uma versão reduzida, mas funcional, de todo o ambiente já roda continuamente na região de DR (menos capacidade que produção); em caso de desastre, ela é escalada rapidamente para capacidade total | Médio-alto |
| Multi-Site Active/Active | Próximo de zero | Ambiente completo rodando simultaneamente em múltiplas regiões, todas recebendo tráfego real o tempo todo; failover é quase instantâneo porque não há nada para "ligar" | Mais caro |
💡 Regra para a prova: o cenário vai te dar um RPO/RTO alvo (ou uma pista textual como "custo deve ser mínimo" ou "não pode haver perda de dado perceptível") — a partir disso, você escolhe a estratégia da tabela, não o contrário. Se o enunciado prioriza custo baixo acima de tudo, pense em Backup & Restore. Se menciona "tempo de recuperação em segundos, tolerância a perda de dado mínima", pense em Multi-Site Active/Active.
6. Ferramentas por estratégia — conectando o "o quê" ao "quando usar"
As ferramentas abaixo aparecem com frequência em cenários de DR multi-region. O objetivo aqui não é repetir a mecânica interna delas (isso está nos conteúdos dedicados de Route 53, S3, DynamoDB e RDS) — é situar onde cada uma entra no espectro de RPO/RTO da seção anterior:
- Route 53 (health checks + failover routing): o mecanismo que redireciona tráfego de usuários para a região de DR quando a primária cai — necessário em todas as estratégias acima de Backup & Restore, já que sem ele o failover não é automático. Detalhes de configuração no conteúdo dedicado de Route 53.
- Cross-Region Replication (CRR) do S3: mantém uma cópia de objetos em outra região continuamente — encaixa-se tipicamente em Backup & Restore (RPO na casa de minutos/horas, dependendo da frequência de sincronização) ou como parte de um Pilot Light.
- Data replication contínua (DynamoDB Global Tables, Aurora Global DB, RDS read replicas cross-region): mantém dados replicados quase em tempo real entre regiões, com RPO na casa de segundos — é o que viabiliza Warm Standby e Multi-Site Active/Active, onde a região de DR precisa ter dados atualizados o tempo todo, não só um snapshot antigo.
- Automated backups + snapshots replicados: a base da estratégia Backup & Restore — mais barato, mas com o maior RPO/RTO do espectro, porque envolve recriar infraestrutura do zero a partir do backup.
💡 Em resumo: quanto mais "à esquerda" na tabela de estratégias (Backup & Restore), mais a ferramenta é baseada em snapshot/backup periódico; quanto mais "à direita" (Multi-Site Active/Active), mais a ferramenta precisa ser de replicação contínua e quase síncrona.
7. Custos a considerar
- Transferência de dados entre regiões é mais cara que entre AZs na mesma região;
- CloudFront costuma reduzir custos de egress (saída) ao cachear conteúdo na borda;
- Operar multi-region aumenta custo operacional (replicação, testes DR, infraestrutura duplicada) — e, como visto na seção 5, esse custo cresce conforme você se move de Backup & Restore em direção a Multi-Site Active/Active.
Decisão de arquitetura deve balancear RTO/RPO desejados com custo aceito — não existe estratégia "certa" isolada do orçamento e da criticidade real do negócio.
8. Melhores práticas
- Escolha regiões que atendam requisitos de latência e conformidade antes de otimizar por preço.
- Use Multi-AZ por padrão para componentes gerenciados que oferecem essa opção.
- Defina RPO/RTO com o negócio antes de desenhar a arquitetura de DR — não o contrário.
- Teste planos de DR periodicamente (failover e failback) — uma estratégia nunca testada não é confiável.
- Use CloudFront para conteúdo público global e para reduzir carga sobre a origem.
- Monitore latência e throughput entre regiões/AZs com CloudWatch e runbooks prontos.
9. Como cai na certificação
- Cenário "tolerância a falha dentro de uma única região" → Multi-AZ.
- Cenário "continuidade após perda de região inteira" → Multi-Region + DNS failover (Route 53).
- Cenário "entrega global e redução de latência de leitura de conteúdo estático" → Edge Locations / CloudFront.
- Cenário "aplicação precisa rodar computação real (não só cache) muito perto de uma cidade específica" → Local Zone.
- Cenário "latência ultrabaixa via rede 5G" → Wavelength Zone.
- Cenário "custo deve ser o menor possível, RPO/RTO em horas é aceitável" → Backup & Restore.
- Cenário "recuperação em minutos, com núcleo de dados sempre replicado" → Pilot Light.
- Cenário "ambiente reduzido sempre ativo, escalando rapidamente no desastre" → Warm Standby.
- Cenário "failover quase instantâneo, sem perda de dado perceptível, custo não é o fator limitante" → Multi-Site Active/Active.
- Lembre-se de citar custos de cross-region e a implicação legal de residência de dados quando relevantes.
10. Exercícios conceituais
Estes exercícios não exigem conhecimento de EC2 ou de outros serviços de computação — o objetivo aqui é fixar os conceitos de infraestrutura global antes de avançar para os serviços que rodam sobre ela.
-
Explore o console: acesse o console da AWS e liste quantas AZs existem em
sa-east-1(São Paulo) e emus-east-1(Norte da Virgínia). Compare os dois números. -
Meça latência: use uma ferramenta como cloudping.info para comparar sua latência até 3 regiões diferentes. Anote qual região seria a melhor escolha para um usuário na sua localização.
-
Estudo de caso (escrito): uma empresa brasileira atende clientes no Brasil e na Europa, e precisa cumprir uma lei local de residência de dados na Europa. Escreva, em poucas linhas, qual estratégia de regiões você adotaria e por quê.
-
Diagrama conceitual: desenhe (no papel ou em uma ferramenta simples) uma arquitetura com 2 AZs na mesma região representando redundância local, e outra versão com 2 regiões representando redundância geográfica. Identifique em qual delas você usaria Multi-AZ e em qual usaria Multi-Region.
-
Mapeamento RPO/RTO: para cada uma das 4 estratégias de DR (Backup & Restore, Pilot Light, Warm Standby, Multi-Site Active/Active), escreva um exemplo de negócio real onde aquele nível específico de RPO/RTO seria aceitável — e um onde não seria.