Microsoft AZ-305: Alta Disponibilidade, Recuperação de Desastres e Continuidade de Negócios — Guia de estudos

By Laurynas Brazys · 11 August 2026 · #microsoft #az-305 #certification #exam-prep #study-guide

Faz parte do Microsoft Azure Solutions Architect Expert AZ-305 — Guia de estudos. Pratique com respostas verificadas no centro de exames da Microsoft, ou faça testes cronometrados no ExamRoll.io.

Visão Geral

A alta disponibilidade (HA), a recuperação de desastres (DR) e a continuidade de negócios (BC) no Azure exigem um projeto deliberado nas camadas de computação, dados e rede. A resiliência começa com metas claras de tempo de recuperação (RTO) e ponto de recuperação (RPO), e então compõe as capacidades da plataforma — Zonas de Disponibilidade, roteamento global, replicação de dados, backup e orquestração de failover — em uma estratégia testada e automatizada. O Azure fornece isolamento de falhas em zonas e regiões, distribuição global baseada em DNS e anycast, durabilidade de dados multirregional e backup/restauração orientados por políticas para atender a objetivos rigorosos, controlando ao mesmo tempo o custo e a complexidade operacional.

Arquitetura Orientada por RTO/RPO e Resiliência Zonal/Global

O projeto começa com RTO e RPO. O RTO dita a rapidez com que o serviço deve ser retomado após uma falha; o RPO dita a perda máxima de dados aceitável. Atender a um RTO baixo exige failover automatizado e capacidade pré-provisionada; atender a um RPO baixo exige replicação síncrona ou quase síncrona e pontos de recuperação consistentes e frequentes.

As Zonas de Disponibilidade (Availability Zones) são domínios de falha de datacenter independentes dentro de uma região. Serviços zonais (por exemplo, Virtual Machines, discos gerenciados, IPs públicos Standard) são fixados em uma única zona. Serviços com redundância de zona (por exemplo, front-ends com redundância de zona do Azure Load Balancer Standard, ofertas de armazenamento com redundância de zona e camadas do Azure SQL com redundância de zona) abrangem as zonas automaticamente. Um padrão resiliente típico implanta VMs zonais em pelo menos duas zonas, as coloca em uma única rede virtual e expõe um front-end de balanceamento de carga com redundância de zona. Isso elimina a falha de uma única zona como causa de tempo de inatividade (downtime).

Na borda global, escolha entre a distribuição de carga baseada em DNS e por proxy anycast:

O Azure Traffic Manager é baseado em DNS. Ele direciona os clientes para endpoints usando métodos de roteamento: Desempenho (menor latência), Ponderado (testes A/B e mudanças graduais de tráfego), Prioridade (failover ativo/passivo), Geográfico (atende usuários a partir de endpoints em conformidade regional), Multivalor (retorna múltiplos registros IPv4/IPv6 íntegros para clientes simples) e Sub-rede (mapeia faixas de IP de clientes para endpoints específicos). Por ser baseado em DNS, o Traffic Manager não acelera conteúdo nem atua como proxy de tráfego; os clientes se conectam diretamente ao endpoint escolhido e obedecem ao comportamento de cache de DNS local.
O Azure Front Door (Standard/Premium) é um proxy reverso HTTP/HTTPS anycast global com roteamento inteligente, descarregamento de TLS (TLS offload) e web application firewall (WAF) integrado. As regras de roteamento correspondem a domínio, caminho, método e cabeçalhos, e então roteiam para grupos de origem; as ações do mecanismo de regras podem reescrever URLs/cabeçalhos e forçar redirecionamentos. As sondas de integridade (health probes) avaliam continuamente a saúde da origem em um caminho e protocolo configuráveis; origens não íntegras são removidas da rotação. Os grupos de origem suportam distribuição por prioridade (ativo/passivo) e ponderada entre regiões. As políticas de WAF são anexadas no endpoint ou na rota, com conjuntos de regras gerenciadas, regras personalizadas e limitação de taxa (rate limiting) para mitigar ameaças OWASP e clientes abusivos. Use o Front Door quando precisar de balanceamento de carga global com aceleração, segurança de borda e failover com reconhecimento de aplicativo; combine-o com o Traffic Manager apenas quando precisar de endpoints não-HTTP ou controle no nível de DNS.

Na camada 4, o Azure Load Balancer fornece distribuição de carga de latência ultrabaixa para TCP/UDP. O Standard Load Balancer suporta front-ends zonais e com redundância de zona, portas de HA (HA ports), regras de saída e comportamento seguro por padrão (configuração explícita de NSG e do pool de back-end). As sondas de integridade (TCP/HTTP) determinam a saúde do back-end; uma falha remove as instâncias da rotação. O Basic Load Balancer não tem reconhecimento de zona, recursos avançados e SLA — evite-o para produção. O Cross-region Load Balancer adiciona um front-end anycast global que balanceia entre os Standard Load Balancers regionais, permitindo projetos multirregionais ativo/ativo para cargas de trabalho não-HTTP e fornecendo failover regional rápido com base na integridade.

Proteção de Dados e Recuperação de Desastres: Azure Backup e Site Recovery

O Azure Backup fornece recuperação point-in-time; o Azure Site Recovery (ASR) fornece replicação de cargas de trabalho e failover orquestrado. Eles atendem a necessidades complementares e são frequentemente combinados.

Opções de cofre do Azure Backup:

O cofre dos Serviços de Recuperação protege VMs do Azure, SQL Server em VMs do Azure, SAP HANA em VMs do Azure, Azure Files e agentes MARS/MABS. Ele se integra com políticas de Backup que definem agendamentos, retenção e backups consistentes com a aplicação, onde houver suporte.
O cofre de Backup é o cofre modernizado para cargas de trabalho mais recentes, como backup de Azure Disks e backup de Azure Blobs, oferecendo RBAC granular e armazenamento de cofre com redundância de zona em regiões com suporte. Escolha o tipo de cofre alinhado com a carga de trabalho e o modelo de governança.

As políticas de backup governam quando os backups são executados, suas camadas de retenção (diária/semanal/mensal/anual) e configurações de consistência. A exclusão reversível (soft delete) adiciona uma janela de segurança durante a qual os itens de backup excluídos podem ser recuperados, protegendo contra exclusão acidental ou mal-intencionada. A restauração entre regiões (cross-region restore) permite restaurações a partir da região secundária quando o armazenamento do cofre usa opções com redundância geográfica; ela deve ser habilitada e está sujeita ao suporte do recurso na região e à prontidão do plano de dados.

O Azure Site Recovery replica cargas de trabalho entre zonas ou regiões e orquestra a DR de ponta a ponta:

As políticas de replicação definem a frequência dos snapshots, a retenção dos pontos de recuperação, a cadência de snapshots consistentes com a aplicação e os limites de alerta de RPO. As políticas equilibram a largura de banda da replicação, os custos de armazenamento e a precisão da recuperação.
Os planos de recuperação fornecem failover ordenado de aplicações de várias camadas com grupos (ex: banco de dados, API, web), etapas de pré e pós-execução e automação via runbooks do Azure Automation, scripts ou ações manuais. Integre alterações de DNS, atualizações de endpoint do Traffic Manager/Front Door e configuração da aplicação no plano.
O failover de teste executa uma recuperação isolada usando uma VNet de não produção ou uma rede de teste para validar runbooks, ordem de inicialização e a saúde da aplicação sem impactar a produção ou a replicação. Testes regulares são essenciais para validar o RTO.
O failback retorna as cargas de trabalho para o site ou região original quando estiverem íntegros. Após o failover, proteja novamente a carga de trabalho na nova direção primária, sincronize as alterações, agende uma janela de failback planejada e verifique a replicação pós-failback. Para cenários Azure-para-Azure, você normalmente faz o failover entre regiões emparelhadas e reverte a replicação para restaurar a topologia original quando estiver pronto.

Continuidade da Camada de Dados: Azure SQL, Replicação de Armazenamento e Cosmos DB

Cada serviço de dados expõe semânticas distintas de durabilidade e failover que devem estar alinhadas com os requisitos de consistência da aplicação.

Azure SQL Database e Azure SQL Managed Instance:

A replicação geográfica ativa cria até quatro secundários legíveis para bancos de dados individuais ou pools elásticos. Ela oferece replicação em nível de banco de dados com failover manual ou orientado por API, permitindo read-scale e DR. É apropriada quando você precisa de controle por banco de dados e orquestração personalizada.
Os grupos de failover automático criam um grupo de bancos de dados (ou uma instância gerenciada inteira) que fazem failover juntos com um endpoint de ouvinte (listener). Isso simplifica o failover entre regiões e o gerenciamento de connection strings, e suporta failover automático após um período de carência. Use grupos de failover para aplicações com múltiplos bancos de dados que exigem failover coordenado e conectividade de cliente simplificada.
A redundância de zona posiciona réplicas entre zonas em uma região para sobreviver a falhas de zona sem recuperação entre regiões. Habilite-a para as camadas que a suportam para melhorar a disponibilidade local sem alterar os perfis de latência.

Opções de replicação do Azure Storage:

O GRS (armazenamento com redundância geográfica) replica dados de forma assíncrona da região primária (três cópias) para uma região secundária emparelhada (três cópias). Durante a operação normal, as leituras e gravações são direcionadas para a primária.
O RA-GRS adiciona acesso de leitura ao endpoint secundário para cenários como relatórios de emergência ou análises quando a região primária está degradada.
O GZRS (armazenamento com redundância de zona geográfica) combina o ZRS na região primária para durabilidade zonal com replicação assíncrona para a região secundária, melhorando a resiliência local e regional.
O RA-GZRS adiciona acesso de leitura ao secundário para contas GZRS. Se a região primária estiver irrecuperável, você pode iniciar um failover de conta para a secundária. Após o failover, a conta de armazenamento se torna primária na região secundária e normalmente reverte para redundância local (até que você a reconfigure). Espere algum RPO (replicação assíncrona); as aplicações devem lidar com idempotência e reconciliação após o failover.

Azure Cosmos DB:

A escrita em várias regiões (multi-region writes) permite gravações em qualquer região configurada com políticas de resolução de conflitos (a última gravação prevalece por meio de uma propriedade designada, estratégias personalizadas ou multi-master). Isso reduz a latência de gravação e aumenta a disponibilidade.
O failover automático usa uma lista de regiões priorizadas para promover uma nova região de gravação em caso de interrupção. Combinado com os níveis de consistência escolhidos (de Forte a Eventual), você gerencia o trade-off entre disponibilidade e consistência.
Os SLAs cobrem disponibilidade, throughput, latência e consistência. Com escritas em várias regiões, o Cosmos DB oferece até 99,999% de disponibilidade para leituras e gravações, assumindo a configuração correta de várias regiões. Projete os clientes usando o SDK com descoberta de endpoint e novas tentativas (retries) para se beneficiar totalmente dessas garantias.

Juntando Tudo: Atendendo a Objetivos de Recuperação Específicos

Mapeie cada camada ao seu mecanismo de continuidade, guiado por RTO/RPO e domínios de falha:

Disponibilidade intrarregional: Use Zonas de Disponibilidade. Implante a computação zonal em pelo menos duas zonas; use front-ends com redundância de zona (Standard Load Balancer, Application Gateway v2 com redundância de zona ou Front Door na borda). Habilite a redundância de zona do SQL onde for compatível e use GZRS para armazenamento que precisa de resiliência tanto zonal quanto regional.
DR entre regiões: Para camadas com estado (stateful), prefira a georreplicação nativa (grupos de failover automático do SQL, contas multirregionais do Cosmos DB, Storage GRS/GZRS) para um RPO baixo. Para IaaS com estado ou cargas de trabalho sem replicação nativa, use o Azure Site Recovery com políticas de replicação e planos de recuperação bem ajustados. Para computação efêmera, reidrate a partir de imagens ou VM Scale Sets, usando Infraestrutura como Código.
Roteamento e failover globais: Para HTTP/S, o Azure Front Door oferece failover orientado por sondas de integridade, ciente da aplicação, e proteção WAF. Para protocolos não HTTP ou mistos, adicione o Traffic Manager (DNS) ou o Cross-region Load Balancer (anycast L4) conforme apropriado. Use o roteamento por prioridade para metas de RTO ativo/passivo estritas; use o roteamento ponderado para lançamentos em fases (staged rollouts) e o de desempenho para experiências de usuário com a menor latência.
Backups como última linha de defesa: Mesmo com replicação, mantenha o Azure Backup com políticas de retenção que atendam à conformidade, habilite a exclusão reversível (soft delete) para proteger contra eventos de exclusão definitiva (purge) e configure a restauração entre regiões para cofres que usam armazenamento com redundância geográfica. Os backups protegem contra corrupção lógica, ransomware e erro do operador — riscos que a replicação pode propagar.

Testar não é negociável. Agende failovers de teste regulares do ASR, realize testes de simulação de integridade (health drill tests) do Front Door/Traffic Manager, valide o comportamento do grupo de failover do SQL sob carga e execute simulações de failover de armazenamento em um ambiente de sandbox. Instrumente as medições de RTO e automatize o rollback/failback com runbooks. Documente e ensaie os runbooks operacionais para que a equipe de plantão possa executá-los de forma consistente sob pressão.

Cenário de Problema Prático

O Expedia Group precisa modernizar sua plataforma global de reserva de viagens para atender a um RTO ≤ 15 minutos e um RPO ≤ 5 minutos para as funcionalidades principais de reserva, ao mesmo tempo que sustenta picos de tráfego de 10x durante grandes eventos de viagem. A plataforma atende a clientes web e móveis em todo o mundo com cargas de trabalho mistas de HTTP e não HTTP.

Construir resiliência zonal em uma região primária

Implantar microsserviços sem estado (stateless) como VM Scale Sets zonais em duas ou mais Zonas de Disponibilidade com front-ends com redundância de zona do Standard Load Balancer. Isso remove o risco de falha de uma única zona e garante tráfego intrarregional de baixa latência.
Usar o Azure SQL Database com grupos de failover automático e redundância de zona habilitada. Os grupos de failover automático fornecem failover de banco de dados coordenado e um ouvinte (listener) estável, atendendo ao RTO de 15 minutos com carga operacional mínima.
Armazenar artefatos de sessão e imagens em contas de armazenamento GZRS para combinar a durabilidade zonal com a proteção regional assíncrona. Isso atende ao RPO de 5 minutos quando combinado com a idempotência no lado da aplicação.

Adicionar DR entre regiões com leituras ativo/ativo

Configurar as origens da web/API de reserva em duas regiões emparelhadas por trás do Azure Front Door Standard. Sondas de integridade e roteamento por prioridade permitem um failover rápido com base na saúde da aplicação, enquanto o anycast acelera o tráfego do usuário. Políticas de WAF com conjuntos de regras gerenciadas e limitação de taxa (rate limiting) protegem contra ataques volumétricos e de camada de aplicação, o que é crucial durante picos de tráfego.
Habilitar escritas multirregionais no Cosmos DB para os serviços de itinerário e personalização para reduzir a latência de escrita para usuários globais e fornecer 99,999% de disponibilidade. O failover automático prioriza a região secundária, preservando um RTO baixo sem intervenção manual.
Usar grupos de failover automático do SQL nas mesmas duas regiões para reservas transacionais, permitindo a escala de leitura (read-scale) nos secundários para relatórios, ao mesmo tempo que garante um failover rápido e coordenado.

Proteger o estado e suportar a recuperação de corrupção

Usar cofres dos Serviços de Recuperação (Recovery Services vaults) para backups de VMs do Azure (consistentes com a aplicação, onde suportado) e SQL em VM, se algum componente legado permanecer. Aplicar políticas de backup com retenção em camadas (tiered retention) e habilitar a exclusão reversível (soft delete) para proteger contra exclusões acidentais ou maliciosas.
Para Azure Disks que hospedam cargas de trabalho especializadas, adicionar o Backup de Disco do Azure (Azure Disk Backup) baseado em cofre de backup para capturar snapshots incrementais independentes dos agentes do SO convidado. Isso diversifica as opções de recuperação.
Habilitar a restauração entre regiões em cofres que usam armazenamento com redundância geográfica, permitindo restaurações do plano de dados (data-plane) a partir da região secundária durante interrupções parciais do plano de controle (control-plane).

Orquestrar o DR e validar o RTO

Configurar o Azure Site Recovery para quaisquer serviços sem replicação nativa (por exemplo, serviços legados do Windows). Criar planos de recuperação que sequenciam a prontidão do banco de dados, depois da API, depois da web, e incluir runbooks do Azure Automation para atualizar referências do Key Vault, limpar caches de CDN por meio de regras do Front Door e alternar a prioridade do Traffic Manager para endpoints não HTTP.
Agendar failovers de teste trimestrais para VNets isoladas usando dados mascarados para verificar os runbooks, medir a duração real do failover e refinar as reservas de capacidade. Após os testes, limpar os artefatos e revisar as métricas em relação à meta de RTO de 15 minutos.

Roteamento global para protocolos mistos

Para HTTP/S, o Front Door lida com o failover orientado pela integridade e a segurança na borda. Para protocolos não HTTP (por exemplo, integrações TCP de parceiros), implante o Cross-region Load Balancer com Standard Load Balancers regionais como endpoints filhos. As sondas de integridade removem regiões com falha instantaneamente, mantendo a conectividade sem dependências de TTL de DNS. Onde a geolocalização em nível de DNS for necessária (endpoints regulatórios), adicione uma camada de roteamento Geográfico do Azure Traffic Manager antes dos endpoints específicos da região.

Por que esses serviços

As Zonas de Disponibilidade e os front-ends com redundância de zona eliminam falhas de zona única com impacto mínimo na latência. Os grupos de failover do Azure SQL abstraem o gerenciamento de conexões e automatizam o failover, alinhando-se ao RTO de 15 minutos. As escritas multirregionais do Cosmos DB atendem aos requisitos de altíssima disponibilidade e baixa latência de escrita globalmente. As opções GZRS e RA fornecem durabilidade zonal mais regional com trade-offs de RPO controlados. O Front Door oferece aceleração global, failover ciente da aplicação e WAF na borda. O Cross-region Load Balancer e o Traffic Manager cobrem as necessidades de roteamento não HTTP e geográfico. O Azure Backup e o ASR fornecem caminhos de recuperação independentes — desde restaurações pontuais (point-in-time) até o failover completo da pilha — garantindo que a plataforma possa se recuperar tanto de falhas de infraestrutura quanto de corrupção lógica de dados.

← Redes e Conectividade · Todos os domínios · Arquitetura de Segurança e Zero Trust →

Pratique estas questões → · Prática cronometrada no ExamRoll.io →