Alta disponibilidade (HA) é sobre projetar seu serviço para estar "quase sempre" disponível, enquanto recuperação de desastres (DR) é sobre restaurá-lo rapidamente caso ele caia. O exame AZ-305 testa com frequência sua capacidade de escolher a camada certa e o serviço adequado para cada objetivo. Neste guia, vamos percorrer os serviços principais um a um e esclarecer os critérios de seleção que mais confundem os candidatos.
---
RTO, RPO e design de continuidade de negócios
Todo design de recuperação de desastres começa com dois números: RTO e RPO.
RTO (Recovery Time Objective) é o tempo máximo que seu serviço pode ficar fora do ar antes de precisar voltar. Se o seu RTO é de quatro horas, você deve restaurar o serviço em até quatro horas após uma falha. Um RTO menor exige uma infraestrutura de failover mais rápida — e, portanto, maior custo.
RPO (Recovery Point Objective) é a perda de dados máxima tolerável, expressa como uma janela de tempo. Um RPO de 24 horas significa que você pode perder até 24 horas de dados. Esse valor determina diretamente a frequência com que você precisa fazer backups ou replicar dados. Com backups diários, seu RPO é de no máximo 24 horas. Mudando para backups horários, o RPO cai para uma hora.
Um dos erros mais comuns no exame é confundir período de retenção com RPO. O período de retenção responde à pergunta "até que ponto no tempo posso restaurar?" — por exemplo, 12 meses de backups mensais significa que você pode restaurar um snapshot de 10 meses atrás. O RPO responde uma pergunta completamente diferente: "quanto dado eu poderia perder se uma falha ocorresse agora?" Com backups diários, essa resposta ainda é de até 24 horas, independentemente de por quanto tempo você mantém esses backups.
O princípio central do design de continuidade de negócios é alinhar sua estratégia de recuperação com seus objetivos de RTO e RPO. Metas mais flexíveis — digamos, RTO de 12 horas e RPO de 24 horas — geralmente podem ser atendidas apenas com uma boa estratégia de backup. Metas rígidas — RTO de minutos e RPO de segundos — exigem replicação contínua e failover automático.
---
Availability Zones e Availability Sets
O Azure oferece duas formas fundamentais de proteger cargas de trabalho contra falhas em um único datacenter.
Um Availability Set distribui as VMs em diferentes racks físicos dentro do mesmo datacenter. As VMs são espalhadas entre fault domains (caminhos independentes de energia e rede) e update domains (janelas de manutenção escalonadas), de modo que uma falha de hardware ou um ciclo de manutenção planejado nunca derrube todas as suas VMs ao mesmo tempo. O SLA é de 99,95%.
Um Availability Zone vai além. Dentro de uma única região do Azure, cada zona é um datacenter fisicamente separado com sua própria infraestrutura independente de energia, refrigeração e rede. Mesmo que uma zona inteira sofra uma queda de energia, as VMs nas outras zonas continuam funcionando. O SLA é de 99,99%.
As Availability Zones protegem contra falhas dentro de uma região. Se a região inteira ficar indisponível, as Availability Zones não são suficientes — você precisa de uma arquitetura multi-região.
Regra prática para o exame: falha de rack ou host em um único datacenter → Availability Set; falha no nível de zona dentro de uma região → Availability Zone; falha de toda a região → design multi-região.
!Availability Zone vs Availability Set
Region Pairs e arquitetura multi-região
O Azure agrupa certas regiões em pares geograficamente próximos, conhecidos como Region Pairs. Por exemplo, Korea Central está emparelhada com Korea South.
Os Region Pairs têm três propriedades importantes:
As atualizações da plataforma Azure nunca são implantadas nas duas regiões do par ao mesmo tempo, o que distribui o risco de interrupções relacionadas a atualizações. Se você configurar GRS (armazenamento com redundância geográfica) ou restauração entre regiões (CRR), seus dados são automaticamente replicados para a região emparelhada. O Azure Key Vault realiza failover automático para a região emparelhada durante uma interrupção regional e opera em modo somente leitura. A recuperação de chaves existentes, criptografia e descriptografia continuam funcionando, mas criar ou modificar chaves não é possível durante o período de failover.
Para cargas de trabalho que precisam sobreviver a uma interrupção regional completa, existem dois padrões multi-região principais:
O primeiro é Active-Active ou Warm Standby — manter infraestrutura idêntica na região secundária o tempo todo. Isso mantém RTO e RPO extremamente baixos, mas você paga pela infraestrutura secundária continuamente.
O segundo é Cold Standby — manter apenas dados replicados na região secundária e provisionar infraestrutura sob demanda quando ocorre uma falha. É mais eficiente em custo, mas resulta em um RTO um pouco maior. O DR de VMs baseado em Azure Site Recovery é o exemplo clássico desse padrão.
Para back-ends web baseados em VMSS, o padrão recomendado é implantar um VMSS idêntico na região secundária e configurar o failover global usando Front Door. O Front Door sonda a integridade do backend a cada 30 segundos e redireciona o tráfego automaticamente para a região secundária se a principal ficar indisponível.
---
Estratégia de Azure Site Recovery e Backup
Azure Backup e Azure Site Recovery parecem similares, mas servem propósitos muito diferentes.
O Azure Backup armazena snapshots dos seus dados em um ponto específico no tempo dentro de um Recovery Services Vault. Você pode configurar níveis de retenção diários, semanais, mensais e anuais, com retenção de até 99 anos. Para fazer backup de arquivos e pastas de um Windows Server local diretamente no Azure sem um servidor de backup separado, você instala o MARS Agent (Microsoft Azure Recovery Services Agent). O MARS Agent envia arquivos, pastas e estado do sistema para o Recovery Services Vault de forma independente — pode ser executado junto ao Windows Server Backup existente sem conflitos.
O Azure Site Recovery (ASR) replica continuamente os discos das VMs para uma região secundária, alcançando um RPO de alguns minutos a cerca de 15 minutos. Em operação normal, nenhuma VM está em execução na região secundária — apenas os dados de replicação são mantidos — o que minimiza os custos. Quando ocorre uma falha, as VMs são provisionadas automaticamente na região secundária, permitindo recuperação com um RTO inferior a uma hora. O ASR suporta cenários de local para local, local para Azure e Azure para Azure. Os Recovery Plans permitem definir a ordem de failover e gerenciar dependências automaticamente. O recurso Test Failover permite validar seu plano de DR em uma rede isolada sem nenhum impacto na produção.
O Recovery Services Vault é o armazenamento central tanto para o Azure Backup quanto para o Azure Site Recovery. Ativar o Immutability Lock impede que os dados de backup sejam excluídos ou modificados, sendo sua principal defesa contra ataques de ransomware. Com GRS e restauração entre regiões (CRR), você pode restaurar da região secundária mesmo durante uma interrupção regional. Como um Vault está vinculado à região onde foi criado, ambientes multi-região exigem um Vault separado por região. Para monitorar vários Vaults a partir de um único painel, use o Backup Center.
Para aplicar uma política de backup padronizada a centenas de VMs em lote, vincule uma Azure Policy à política de backup do seu Recovery Services Vault. As novas VMs que estiverem dentro do escopo da política são automaticamente inscritas, mantendo seu estado de conformidade sem intervenção manual.
---
Tabela comparativa de serviços
A tabela abaixo compara os principais componentes do Azure para alta disponibilidade e recuperação de desastres por escopo de proteção, SLA e RTO/RPO.
| Componente | Escopo de proteção | SLA | RPO | RTO | Características principais | |------------|-------------------|-----|-----|-----|---------------------------| | Availability Set | Racks e hosts dentro de um datacenter | 99,95% | N/A | N/A | Distribuição por fault domain, sem custo extra | | Availability Zone | Datacenters independentes dentro de uma região | 99,99% | N/A | N/A | Energia e refrigeração físicas separadas | | Region Pair + GRS | Replicação de armazenamento entre regiões | 99,99%+ | Minutos a 1 hora | Horas | Redundância geográfica na camada de armazenamento | | Azure Backup | Retenção de dados em ponto no tempo | - | Horas a 24 horas | Horas a 12 horas | Retenção de longo prazo, PITR | | Azure Site Recovery | Replicação de VMs entre regiões | - | Minutos a 15 minutos | Menos de 1 hora | Failover automático, eficiente em custo | | SQL Auto-Failover Group | Azure SQL DB entre regiões | 99,99% | Menos de 5 segundos | Menos de 1 hora | Endpoint único, comutação automática | | Always On AG + ILB | SQL Server em VMs | 99,99%+ | 0 segundos (síncrono) | Segundos | Ambiente IaaS, baseado em WSFC |
---
Critérios de seleção que mais confundem no exame
Aqui está um resumo dos cenários e regras de decisão que aparecem com mais frequência no exame real.
Cenário 1: RTO de 12 horas, RPO de 24 horas, a infraestrutura secundária não pode funcionar continuamente, a eficiência de custo é prioridade. Escolha Azure Backup com PITR. Você não precisa manter VMs em execução na região secundária, e os backups diários entregam o RPO requerido de 24 horas. Active Geo-Replication é muito caro para esse requisito.
Cenário 2: Failover automático em caso de interrupção regional, o serviço deve retomar sem alterar a string de conexão da aplicação (Azure SQL Database). Escolha Auto-Failover Group. Ele fornece dois endpoints DNS fixos — um Primary Listener (leitura/escrita) e um Secondary Listener (somente leitura) — portanto a string de conexão nunca precisa mudar após um failover. Active Geo-Replication suporta apenas failover manual e requer gerenciamento separado de endpoints.
Cenário 3: SQL Server em VMs IaaS, failover autom