Infraestrutura Global da AWS e Resiliência

Todo workload da AWS eventualmente responde a uma pergunta: onde ele roda, e o que acontece quando aquele lugar quebra? O exame chama isso de Domínio 3, Tarefa 3.2: "Definir a infraestrutura global da AWS", e é uma das tarefas de maior rendimento no CLF-C02, porque um único erro de vocabulário (Região versus Zona de Disponibilidade versus local de borda) pode lhe custar várias questões de uma vez. A própria formulação da AWS é direta: o CTO da Amazon, Werner Vogels, diz "Tudo falha, o tempo todo", e o Well-Architected Framework existe para que você "prepare seu workload para a falha" em vez de fingir que ela não vai acontecer.

Nesta lição você vai:

• separar Regiões, Zonas de Disponibilidade e locais de borda por definição, contagem e capacidade;
• explicar por que as Regiões são isoladas: tolerância a falhas, residência de dados e latência;
• escolher uma Região usando o conjunto de decisão conformidade, latência, preço e funcionalidades;
• aplicar a regra de projeto de AZ (a AWS entrega ≥3 AZs por Região; seu aplicativo usa ≥2);
• diferenciar CloudFront, Route 53 e Global Accelerator por seu plano de entrada;
• situar Local Zones, Wavelength, Outposts e Snow no contínuo híbrido de borda;
• definir com precisão resiliência, disponibilidade, tolerância a falhas, alta disponibilidade e recuperação de desastres;
• ler e calcular RTO e RPO, e ranquear as quatro estratégias de DR por custo versus velocidade de recuperação;
• estudar quatro estudos de caso de resiliência publicados pela AWS, dois deles adicionados nesta revisão;
• aprender o que a AWS de fato lançou entre 2025 e outubro de 2026: Regiões, Local Zones e planos anunciados mas ainda não abertos;
• praticar com 12 questões em formato de exame mais quatro verificações interativas.

---

1. Regiões, Zonas de Disponibilidade e locais de borda

1.1 As três definições, com as palavras da própria AWS

Três fatos sobre a relação fazem a maior parte do trabalho do exame:

1. Uma Região contém pelo menos três AZs: "Cada Região da AWS consiste em um mínimo de três AZs, isoladas e fisicamente separadas, dentro de uma área geográfica" (em outubro de 2026: 39 Regiões e 124 AZs no ar, com 7 AZs a mais e 2 Regiões a mais anunciadas para o Reino da Arábia Saudita e o Chile).
2. AZs não compartilham pontos únicos de falha. A Tarefa 3.2 no guia de exame exige explicitamente o conhecimento de que "Zonas de Disponibilidade não compartilham pontos únicos de falha."
3. Locais de borda são uma camada de entrega, não uma camada de computação. Os benefícios dos locais de borda, segundo o guia de exame, são latência e descarga para entrega: nunca "rode minha aplicação aqui".

1.2 Exemplo E1: reconciliando a contagem de AZs

O bloco de estatísticas da AWS diz 124 AZs (em outubro de 2026). As tabelas de AZ ID na documentação de infraestrutura global cobrem apenas as 34 Regiões que uma conta padrão pode ver. Reconcilie as duas:

A aritmética só fecha se o 124 publicado contar as Regiões que existem hoje, e não a Região da Arábia Saudita anunciada mas ainda não aberta. Adições anunciadas (+7 AZs, +2 Regiões) são planos, nunca fatos de lançamento, o exame não vai creditá-lo por tratar um anúncio como uma abertura.

1.3 Para que cada camada serve

• 📚 Você sabia? A AWS interconecta "todas as AZs ... com rede de alta largura de banda e baixa latência sobre fibra metropolitana dedicada, totalmente redundante", criptografa todo o tráfego entre AZs, e afirma que o desempenho "é suficiente para realizar replicação síncrona entre AZs". As AZs são "separadas fisicamente por uma distância significativa, muitos quilômetros" e contudo "todas ficam a menos de 100 km (60 milhas) uma da outra" (em outubro de 2026). Essa envelope apertada mas não minúscula é exatamente por que a replicação síncrona multi-AZ é possível e por que uma Região inteira ainda pode ser derrubada por um evento regional.

1.4 Onde as Regiões estão (em outubro de 2026)

Contar as Regiões lançadas por geografia dá uma verificação de sanidade útil para alegações de "alcance global", e mostra por que você não pode assumir que sua Região preferida existe:

Duas lições se seguem. Primeiro, "a AWS não tem Região em X" é uma resposta legítima no exame: a disponibilidade de serviços é um fator real de seleção de Região, não uma formalidade, porque um conjunto definido de serviços principais acompanha cada lançamento de Região, enquanto um nível adicional "geralmente é lançado em até 12 meses após o lançamento de uma nova Região". Segundo, as contagens mudam a cada trimestre: trate a tabela como um instantâneo carimbado em outubro de 2026, e verifique de novo as páginas de infraestrutura global da AWS antes de citar qualquer valor fora desta lição. (Esta pesquisa não conseguiu reconciliar cada entrada do mapa com a tabela de documentação da própria AWS, então a coluna "listadas" é uma contagem de mapa, não um total oficial.)

Atualizações de 2026 (em outubro de 2026)

A infraestrutura global não ficou parada enquanto você revisava. O que segue é toda adição de infraestrutura com data, publicada pela AWS, de 2025 to 26 encontrada neste ciclo de pesquisa: lançamentos carregam data, planos não, e apenas lançamentos contam:

• 📚 Você sabia? 2025 foi o ano mais denso para aberturas de Regiões neste ciclo de pesquisa, quatro Regiões em pouco mais de oito meses (Tailândia 2025-01-07, México 2025-01-14, Taipei 2025-06-06, Nova Zelândia 2025-09-02), e contudo o número principal publicado pela AWS em outubro de 2026 ainda era 39 Regiões e 124 AZs. Cada uma dessas aberturas vem com o mínimo de projeto da AWS de pelo menos três AZs isoladas, fisicamente separadas, e é por isso que a contagem de AZs e a de Regiões sobem juntas, em vez de independentemente.

---

2. Por que as Regiões são isoladas: tolerância a falhas, residência de dados, latência

2.1 Tolerância a falhas: domínios de falha separados de propósito

As Regiões são isoladas para que nenhum evento regional único possa derrubar tudo o que você roda. O mecanismo é o isolamento de falhas, a orientação prescritiva da AWS o define como restringir "o escopo do impacto a um contêiner de falha pretendido quando ocorre uma falha", e afirma que "Redundância, Tolerância a falhas é alcançada por meio de redundância que elimina pontos únicos de falha (SPOFs)."

A própria tolerância a falhas tem uma definição precisa: "a capacidade de resistir a falha de subsistema e manter disponibilidade (fazer a coisa certa dentro de um SLA estabelecido). Para implementar tolerância a falhas, os workloads usam subsistemas reserva (ou redundantes)." Reservas quentes custam dinheiro; esse custo é por que a tolerância a falhas fica acima da alta disponibilidade simples na escala de preço.

2.2 Residência de dados e soberania

Alguns workloads podem rodar legal ou contratualmente apenas em uma geografia específica. A AWS lhe dá três níveis aninhados de controle de residência:

1. Nível Região: escolha uma Região dentro da jurisdição exigida (e, quando necessário, um tipo de conta especial como AWS GovCloud (US) ou as Regiões AWS China);
2. Nível Local Zone: a AWS descreve as Local Zones como uma forma de "atender a requisitos de residência de dados" deixando você "controlar onde seus workloads rodam e onde seus dados residem" em uma metrópole específica;
3. Nível Wavelength Zone: os dados "permanecem dentro dos limites geográficos que você especifica" quando você coloca computação dentro de uma instalação 5G de uma operadora.

2.3 Latência: proximidade é um insumo de projeto

A documentação de Regiões da AWS é direta: "você pode reduzir a latência de rede quando seleciona uma Região próxima à maioria dos seus usuários" (em outubro de 2026). A consequência prática é uma regra de dois níveis:

• Computação que precisa estar perto dos usuários → escolha a Região mais próxima que tenha os serviços de que você precisa, ou uma Local Zone / Wavelength Zone naquela metrópole;
• Conteúdo que pode ser armazenado em cache → deixe o workload em uma única Região e deixe os mais de 750 PoPs do CloudFront (em outubro de 2026) encurtarem o caminho para todos os outros.

2.4 Exemplo E2: redundância multiplica disponibilidade

A documentação de confiabilidade da AWS mostra a aritmética de componentes independentes. Dois componentes que estão cada um 99,9% disponíveis, falhando independentemente, se combinam como:

$$1 - (0.001 \times 0.001) = 1 - 10^{-6} = 0.999999 = \mathbf{99.9999\%}$$

Essa é a promessa por trás de rodar em duas AZs: a probabilidade de falha de cada AZ é (aproximadamente) independente da outra, então o par está vastamente mais disponível do que qualquer membro. A mesma fórmula explica o lado de baixo: três dependências duras que estão cada uma em 99,99% limitam o workload inteiro a:

$$0.9999^3 = 0.9997 = \mathbf{99.97\%}$$

Uma fraqueza abaixa o teto de uma arquitetura de outra forma excelente. Essa é a aritmética de resiliência favorita do exame: a redundância só ajuda quando as partes redundantes são genuinamente independentes (AZs diferentes, não dois servidores em um único rack).

---

3. Escolhendo uma Região: conformidade, latência, preço e funcionalidades

3.1 Os quatro fatores (mais dois que você esquece)

A ordem importa mais do que a lista: no exame, um limite legal ou regulatório enunciado vence todos os outros fatores, e "é mais barato em outro lugar" nunca vence quando residência está em jogo. A própria formulação da AWS para o fator de custo é condicional: implante em uma Região mais cara apenas quando latência, residência ou soberania o exigir.

3.2 Exemplo E3, o orçamento anual de disponibilidade

Porcentagens de disponibilidade são orçamentos anuais, não garantias por indisponibilidade. 8.760 horas em um ano:

Leia como um orçamento: um workload prometido em 99,9% já gastou um terço de sua cota anual após 2 horas 55 minutos de inatividade. É por isso que um requisito de negócio de "quatro noves ou melhor" muda sua arquitetura: ele o empurra de AZ única para multi-AZ, e eventualmente de uma Região para duas.

Faça o gráfico da mesma tabela e a forma do orçamento é inconfundível: cada nove extra é aproximadamente um corte de dez vezes na inatividade que você tem permissão para ter:

• 📚 Você sabia? A AWS opera "quase 20 milhões de quilômetros" de fibra de rede em outubro de 2026, e o preço de Região não é uniforme: o pilar de custo do Well-Architected diz explicitamente para você "Identificar diferenças de custo regionais" em vez de assumir uma lista de preços global. Os recursos de Local Zone também são precificados acima da Região pai (em outubro de 2026): proximidade custa dinheiro. Qualquer opção que afirme "preços idênticos em toda Região" está errada de cara.

3.3 Exemplo E4: por que "39 Regiões" não é o que sua conta vê

Três totais diferentes de Região circulam na documentação da AWS, e apenas um deles é o que seu console mostra (todos em outubro de 2026):

Confira a aritmética: $39 - 2 - 2 - 1 = 34$, e $34 - 17 = 17$. O exame usa isso para testar se você confunde lançadas, visíveis e habilitadas:

Se uma questão diz "todas as 39 Regiões estão disponíveis para todo cliente por padrão", está errada em dois pontos ao mesmo tempo: tipo de conta e status de opt-in.

---

4. A regra de projeto de Zona de Disponibilidade

4.1 Dois números diferentes, ambos corretos

Esta é a distinção examinada de forma mais confiável no Domínio 3, e os candidatos a erram ao fundir duas regras que respondem a perguntas diferentes:

Então: a AWS lhe dá ≥3; você deve usar ≥2. Uma questão descrevendo sua arquitetura com sub-redes de apenas uma AZ está descrevendo um ponto único de falha: independentemente de quantas AZs a Região por acaso contenha. A AWS também observa que você pode "rodar em múltiplas AZs para alcançar tolerância a falhas ainda maior", ou seja, três estão disponíveis se seu orçamento e tolerância a complexidade permitirem.

4.2 AZ IDs versus códigos de AZ

Uma armadilha sutil que apareceu em exames reais:

• Códigos de AZ (us-east-1a, us-east-1b) são relativos à conta: em Regiões mais antigas, a letra que uma conta vê é mapeada para um data center físico diferente para contas diferentes (contas criadas antes de novembro de 2025).
• AZ IDs (euw1-az1, use1-az1) identificam o mesmo local físico em toda conta da AWS, o identificador seguro para regras entre contas, landing zones e network peerings.

Em outubro de 2026, as tabelas de AZ ID listam 109 AZ IDs nas 34 Regiões padrão. Regra prática para o exame: se uma questão envolve duas contas, a resposta envolve AZ IDs, não letras.

4.3 Exemplo E5: seu projeto usa as AZs que você recebeu?

Uma Região com 3 AZs (em outubro de 2026, a configuração mais comum) executa um aplicativo com um ALB cujas sub-redes ficam todas em uma AZ, uma instância do EC2 e um banco de dados sem standby:

Corrija em ordem de prioridade: (1) adicione sub-redes e instâncias em uma segunda AZ (mínimo do ALB, remove o ponto único de falha da AZ); (2) habilite um deploy de banco de dados multi-AZ (standby síncrono na segunda AZ); (3) apenas então considere uma segunda Região com uma estratégia de DR para falha regional. O passo 1 custa menos e remove a falha sobre a qual o exame pergunta com mais frequência.

---

5. Serviços de borda: CloudFront, Route 53 e Global Accelerator

Os três ficam na frente das suas Regiões, e os três aparecem na Tarefa 3.2 como benefícios dos locais de borda. O exame os diferencia por plano de entrada: respostas de DNS, conteúdo em cache, ou um endereço IP anycast estático.

5.1 Amazon CloudFront, o plano de cache/CDN

• "Reduza a latência entregando dados por meio de mais de 750 Pontos de Presença (PoPs) dispersos globalmente": mais de 750 PoPs em mais de 100 cidades em mais de 50 países, mais mais de 1.140 PoPs embutidos em mais de 300 cidades dentro de ISPs, e 15 caches de borda regionais que ficam dentro de uma Região (todos em outubro de 2026).
• Mecânica: o DNS resolve o usuário para o PoP mais próximo → em um cache hit o PoP responde → em um cache miss ele busca da sua origem (Amazon S3, um ALB, uma origem de mídia) e armazena o resultado em cache.
• SLA: pelo menos 99,9% de tempo de atividade mensal (em outubro de 2026).
• Uso no exame: armazenar em cache e entregar conteúdo perto dos usuários, mais failover de origem como uma alavanca documentada de deslocamento de tráfego para DR.

5.2 Amazon Route 53, o plano de DNS

• "O Route 53 usa uma rede global de servidores DNS em uma série de locais em todo o mundo para oferecer alta disponibilidade e desempenho aumentado."
• Políticas de roteamento que o exame nomeia: latência, geoproximity, baseada em IP, failover e weighted: mais health checks, que é como o failover de DNS automatizado é alcançado.
• SLA: indisponível "apenas se todos os quatro servidores de nomes virtuais atribuídos à Hosted Zone falharem em responder a todas as consultas DNS"; créditos de serviço começam abaixo de 100% de tempo de atividade (em outubro de 2026).
• A pegadinha que você precisa memorizar: as respostas de DNS são armazenadas em cache por resolvedores conforme o TTL, então um failover pode demorar tanto quanto o TTL que você configurou.

5.3 AWS Global Accelerator, o plano de IP anycast

• "Melhore o desempenho de rede das suas aplicações em até 60%" e forneça "failover rápido para arquiteturas multi-Região e multi-AZ" com "roteamento determinístico ao remover dependências de cache de DNS" (alegações em outubro de 2026).
• Dá ao seu aplicativo endereços IP estáticos anunciados via anycast pela rede de borda da AWS: clientes conectam a um IP fixo, e o tráfego é direcionado na borda para endpoints saudáveis.
• 130 Pontos de Presença em 95 cidades em 53 países (em outubro de 2026).
• Uso no exame: workloads não-HTTP ou sensíveis a allowlist de IP e failover que não pode esperar pelo TTL de DNS.

5.4 A comparação dos três planos

• 📚 Você sabia? Os três serviços podem ser empilhados em vez de escolhidos isoladamente: o Route 53 resolve um nome amigável, o CloudFront serve o front-end em cache do mais próximo de mais de 750 PoPs (em outubro de 2026), e o Global Accelerator carrega o tráfego de API em IPs anycast estáticos para duas Regiões com failover por health check. O whitepaper de recuperação de desastres da AWS lista exatamente esses três, Route 53, Global Accelerator e failover de origem do CloudFront, como o kit de ferramentas de gerenciamento de tráfego para deslocar usuários durante a recuperação.

5.5 Exemplo E6: a janela do DNS TTL faz parte do seu tempo de failover

Suponha que um registro de failover do Route 53 tenha TTL de 300 segundos, e que o endpoint primário falhe em t = 0. Um resolvedor recursivo que pediu a resposta 240 segundos antes da falha ainda mantém uma resposta em cache válida:

Nada aqui condena o failover de DNS, os health checks e o roteamento de failover do Route 53 são uma alavanca documentada de gerenciamento de tráfego de DR, e para política de DNS global (latência, geoproximity, weighted) é a resposta correta. O ponto examinável é aritmética sobre os seus próprios objetivos: se o RTO enunciado é 60 segundos e o TTL do seu registro de failover é 300 segundos, a camada de DNS sozinha pode estourar o orçamento, e o enunciado está apontando você para o Global Accelerator (IPs anycast estáticos, "roteamento determinístico ao remover dependências de cache de DNS") ou para encurtar o TTL. Sempre trate o TTL como um componente invisível do tempo de recuperação, em outubro de 2026 a AWS não publica um tempo de failover padrão, então o número que você configura é o número que você tem.

---

6. O contínuo híbrido de borda: Local Zones, Wavelength, Outposts e Snow

Nem todo workload pertence ao núcleo de uma Região. A AWS oferece um contínuo de totalmente operado pela AWS, bem dentro de uma Região até hardware no seu próprio prédio, o exame testa se você consegue situar cada opção nesse contínuo.

Três esclarecimentos que as questões de exame adoram borrar:

• Local Zones são implantadas pela AWS; Outposts são implantadas pelo cliente. Ambas apresentam as mesmas APIs da AWS, então a frase decisiva do enunciado é "em uma metrópole operada pela AWS" (Local Zone) versus "no meu data center" (Outposts).
• Wavelength é embutida na operadora: você não a escolhe só por residência; você a escolhe quando o workload precisa ficar ao lado de uma rede 5G/telecom.
• Snowball é um dispositivo de transferência, não um destino de computação, e a AWS publicou uma data dura: "Em 31 de dezembro de 2026, a AWS encerrará o suporte aos dispositivos AWS Snowball em todas as Regiões comerciais da AWS" (Storage Optimized e Compute Optimized), enquanto clientes de GovCloud e da Região ADC com jobs Snow ativos não são afetados (anúncio em outubro de 2026).

• 📚 Você sabia? A página de produto das Local Zones da AWS descreve "mais de 30 metrópoles em todo o mundo" em seis continentes (em outubro de 2026), enquanto o bloco de estatísticas de infraestrutura global da AWS publica um valor diferente para Local Zones e sua página de locais lista mais títulos de cidades do que qualquer um dos dois; esta pesquisa não conseguiu reconciliar essas contagens, então trate qualquer total de Local Zone como não verificado e confira de novo antes de citá-lo. A mesma cautela se aplica às Wavelength Zones (o bloco de estatísticas e os códigos de zona contados discordam). Contagens mudam; relações não mudam.

---

7. Vocabulário de resiliência: tolerância a falhas, alta disponibilidade, recuperação de desastres

7.1 Cinco termos, cinco significados

A página "o que é alta disponibilidade" da AWS acrescenta a fronteira que o exame testa literalmente: "Sistemas de alta disponibilidade não fazem parte da recuperação de desastres … A recuperação de desastres trata de colocar seus sistemas de volta no ar se seus sistemas de HA existentes falharem." Em outras palavras: a HA mantém no ar; a DR traz de volta. A tolerância a falhas é o primo mais caro da HA: ela não apenas se recupera rapidamente, ela nunca para visivelmente.

7.2 RTO e RPO: os dois números pelos quais um plano de DR vive ou morre

Ambos são definidos pela sua organização, e não pela AWS (em outubro de 2026):

• RTO: Recovery Time Objective: "o atraso máximo aceitável entre a interrupção do serviço e a restauração do serviço." → por quanto tempo você tem permissão para estar fora do ar.
• RPO: Recovery Point Objective: "a quantidade máxima aceitável de tempo desde o último ponto de recuperação de dados." → quanto dado você tem permissão para perder.

Direção é onde os candidatos perdem pontos: RTO = inatividade, RPO = perda de dados. Uma janela de RPO maior é pior (mais dados perdidos); um RTO maior é pior (indisponibilidade mais longa). Para medição, o RTO se comporta como o MTTR, e o RPO sempre fica antes do desastre na linha do tempo.

7.3 Exemplo E7: lendo RTO e RPO em uma linha do tempo

Um banco de dados falha às 12:00. O backup utilizável mais recente foi escrito às 09:00, e o serviço foi restaurado às 14:00.

$$RPO = 12{:}00 - 09{:}00 = \mathbf{3\ hours\ of\ acceptable\ data\ loss}, \qquad RTO = 14{:}00 - 12{:}00 = \mathbf{2\ hours\ of\ downtime}$$

Agora inverta em um requisito: o negócio declara RTO ≤ 1 minuto, RPO ≤ 1 segundo para o checkout. Um RPO de 3 horas e um RTO de 2 horas falham em ambas as metas por ordens de grandeza: a resposta é uma estratégia com replicação contínua (warm standby ou multi-site ativo-ativo), e não um melhor agendamento de backup. E se o negócio em vez disso declarar RTO ≤ 24 horas, RPO em horas, backup e restauração podem satisfazê-lo com o menor custo das quatro estratégias.

7.4 Disponibilidade, tolerância a falhas e DR são três perguntas diferentes

7.5 Transformando o enunciado de uma questão no termo certo

A maneira mais rápida de pontuar em vocabulário é ler a forma temporal do enunciado em vez de seus substantivos:

Duas frases fecham o circuito do vocabulário: "A HA mantém um workload rodando rodando; a tolerância a falhas continua servindo através de uma falha; a DR restaura um workload que caiu." E a frase de fronteira da própria AWS, "Sistemas de alta disponibilidade não fazem parte da recuperação de desastres", significa que uma questão oferecendo "nosso projeto multi-AZ satisfaz nossos requisitos de DR" está oferecendo uma armadilha: multi-AZ cobre uma AZ falhando, não a Região inteira.

---

8. Estratégias de recuperação de desastres: custo versus velocidade de recuperação

8.1 As quatro estratégias e suas faixas publicadas

O Pilar de Confiabilidade do Well-Architected (REL13-BP02) publica as faixas de objetivo, e o whitepaper de DR publica a forma de custo/complexidade (todos em outubro de 2026):

A frase que decide a maioria das questões de pilot light versus warm standby: "pilot light não pode processar requisições sem uma ação adicional tomada primeiro, enquanto warm standby pode lidar com tráfego (em níveis de capacidade reducidos) imediatamente." (Um warm standby executado em capacidade total é frequentemente chamado de hot standby.)

8.2 Exemplo E8: qual estratégia se encaixa no objetivo?

O negócio publica estes objetivos (todos em outubro de 2026):

Custo e recuperação se movem juntos: conforme você demanda RTO/RPO menores, você compra mais capacidade ociosa. O padrão do exame é entregar um número ("RTO em dezenas de minutos") e pedir a estratégia: dezenas de minutos é a assinatura do pilot light; RPO em segundos com RTO em minutos é warm standby; quase zero / potencialmente zero é ativo-ativo.

8.3 Deslocamento de tráfego e testes: a mecânica de DR

A recuperação é inútil se os usuários não conseguem alcançar a cópia restaurada. O whitepaper de DR da AWS nomeia explicitamente o kit de ferramentas de gerenciamento de tráfego:

E a disciplina que torna qualquer uma das coisas real: "avalie e teste regularmente sua estratégia de recuperação de desastres." O AWS Resilience Hub existe para validar seus alvos de RTO e RPO declarados contra sua arquitetura real (em outubro de 2026). Um plano de DR não testado é uma hipótese, não uma estratégia.

• 📚 Você sabia? O pilar de confiabilidade da AWS publica uma tabela de aritmética de disponibilidade que você pode reusar literalmente: 99% → 3 dias 15 horas, 99,9% → 8 horas 45 minutos, 99,95% → 4 horas 22 minutos, 99,99% → 52 minutos, 99,999% → 5 minutos de inatividade por ano (em outubro de 2026). Combine-a com as faixas de DR e você pode converter qualquer SLA de negócio em uma estratégia: quatro noves de disponibilidade não podem ser atendidos por uma restauração uma vez por dia, e cinco noves essencialmente mandam warm standby ou ativo-ativo mais recuperação automática.

8.4 Ativo/passivo, quente/morno, e as três perguntas a fazer primeiro

O vocabulário de DR tem dois eixos extras que as questões de exame deslizam sem aviso:

Antes de qualquer estratégia ser escolhida, o whitepaper de DR da AWS faz você acertar três decisões:

1. Quais são os RTO e RPO numéricos? Ambos são "definidos pela organização": sem números, toda estratégia "qualifica" e nenhuma é justificada.
2. Qual é a topologia de escrita? Ativo-ativo só faz sentido quando escritas podem ser tratadas entre Regiões (globais, locais ou particionadas): um workload majoritariamente de leitura e um globalmente particionado têm custos completamente diferentes.
3. Quanto custará a capacidade ociosa, e a estratégia foi testada? O whitepaper da AWS instrui as equipes a "avaliar e testar regularmente sua estratégia de recuperação de desastres", e o AWS Resilience Hub valida os alvos de RTO e RPO declarados contra a arquitetura (em outubro de 2026).

Uma heurística de exame útil: se o enunciado lhe dá números e um orçamento, desça a escada a partir de ativo-ativo até que os objetivos ainda sejam atendidos ao menor custo; se o enunciado lhe dá números e diz que custo não é objeto, a resposta é a estratégia mais rápida que os atende.

---

9. Projeto para falha: os princípios operacionais

9.1 Os princípios de design de confiabilidade do Well-Architected

Escolhas de infraestrutura só compensam quando pareadas com hábitos operacionais. Os princípios de design de confiabilidade do Well-Architected (em outubro de 2026) são curtos o bastante para memorizar:

O blog de arquitetura da AWS destila a mentalidade na frase de Vogels, "Tudo falha, o tempo todo", e acrescenta que "nós deveríamos projetar com a falha em mente … O AWS Well-Architected Framework foi projetado para ajudar você a preparar seu workload para a falha." A lente de mobilidade conectada enuncia o corolário como um requisito duro: "A arquitetura deveria garantir que não haja nenhum ponto único de falha."

9.2 Os anti-padrões que o exame chama de errados

---

Casos Reais

A AWS publica como esses padrões aparecem na produção. Todo valor abaixo é afirmação do cliente ou da AWS, não auditado, citado para que você possa conferir a fonte, o ponto examinável é o padrão (qual domínio de falha estava sendo protegido, qual serviço fez o deslocamento, qual objetivo se moveu), não o número de marketing.

Caso A, Capital One: failover regional automatizado (resiliência multi-Região)

Lição de exame: a página de resiliência da Capital One é uma história multi-Região, enquanto sua página de migração é uma história de custo/agilidade: não misture os números delas (o tempo de teste de DR −70% e o ambiente de dev 3 meses → minutos da página de migração pertencem a uma página de caso diferente). O que torna isto um caso de resiliência é a combinação de failover automatizado + deslocamento de tráfego do Route 53 + testes contínuos.

Caso B, Amazon Prime Video: seis Regiões para uma transmissão ao vivo (resiliência em escala global)

Lição de exame: isto é o que "uso de múltiplas Regiões" (Tarefa 3.2 do guia de exame) parece quando o motivo é alcance global e baixa latência, não soberania. Note que seis Regiões foram usadas para entrega e processamento, enquanto o CloudFront ainda carregava a última milha: a camada de borda e a camada de Região resolvem partes diferentes do mesmo problema.

Caso C, Bangkok Flight Services: recuperação de desastres multi-AZ para um manuseador de cargas

Lição de exame: esta é a regra de projeto de aplicativo ≥2 AZs comprada como um resultado de negócio. Sem site de DR on-premises, o primeiro movimento de resiliência da AWS foi multi-AZ dentro de uma Região: alta disponibilidade e isolamento de falhas, não recuperação de desastres multi-Região. Se o enunciado pergunta o que protege contra uma AZ falhando, Bangkok é a forma da resposta; se pergunta sobre a Região inteira falhando, este projeto sozinho não é suficiente.

Caso D, NASA JPL / Perseverance: escala tolerante a falhas para uma missão que você não pode repetir

Lição de exame: o Perseverance é o par do Well-Architected "escale horizontalmente para aumentar a disponibilidade agregada do workload" e "pare de adivinhar a capacidade" em produção: um surto de telemetria é absorvido por mais unidades pequenas em vez de uma maior, e o Spot é acessível porque o trabalho é tolerante a falhas e interrompível: que é exatamente como a AWS enquadra para quais workloads o Spot serve. Note a data do blog: uma história de missão de 2021 com data de acesso de outubro de 2026, nunca apresentada como um valor fresco.

O que os quatro casos têm em comum

• 📚 Você sabia? Os quatro casos se empilham em uma única escada de domínios de falha: o Bangkok Flight Services protege a AZ (multi-AZ dentro de uma Região), a Capital One protege a Região (failover regional automatizado, horas → minutos), o Prime Video protege a entrega global (seis Regiões mais a borda do CloudFront), e o NASA JPL protege a própria capacidade (Auto Scaling sobre Spot e On-Demand, 4,4 TB de telemetria por dia). Diferentes degraus, mesma regra: combine o degrau com a falha que o enunciado descreve, e nunca pague por um degrau mais alto do que aquele sobre o qual você foi perguntado.

---

Perguntas de Prática (Practice Questions)