Fundamentação Teórica: Deploy Virtual Machines to Availability Zones and Availability Sets

1. Intuição Inicial

Imagine que você é o responsável por manter três caixas eletrônicos em uma cidade. Se você colocar os três na mesma agência bancária, qualquer problema naquela agência (queda de energia, inundação, manutenção) deixa todos os três indisponíveis. A solução óbvia é distribuir os caixas em locais diferentes: se um local falhar, os outros dois continuam funcionando.

No Azure, o mesmo princípio se aplica. Quando você tem várias VMs servindo a mesma aplicação, precisa garantir que elas não fiquem todas no mesmo hardware físico ou no mesmo datacenter. Se ficarem, uma única falha pode derrubar tudo simultaneamente.

Availability Sets e Availability Zones são os dois mecanismos do Azure para distribuir VMs de forma inteligente, garantindo que falhas físicas ou manutenções planejadas não derrubem toda a sua aplicação de uma só vez.

A diferença essencial entre os dois está na escala da falha que eles protegem:

Availability Sets protegem contra falhas de hardware dentro de um único datacenter
Availability Zones protegem contra falhas de datacenters inteiros dentro de uma região

2. Contexto

O problema que esses mecanismos resolvem

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Importante: nenhum mecanismo protege contra falhas no nível da aplicação ou erros do sistema operacional. Esses mecanismos protegem especificamente contra falhas de infraestrutura física.

SLA (Service Level Agreement) e sua dependência

O SLA de uma VM isolada no Azure é de 99,9% (sem zona nem availability set). Com os mecanismos corretos:

Configuração	SLA
VM única sem AZ ou AS	99,9%
2+ VMs em Availability Set	99,95%
2+ VMs em diferentes Availability Zones	99,99%

A diferença de 99,95% para 99,99% pode parecer pequena, mas representa a diferença entre até 4 horas de downtime por ano e apenas 52 minutos por ano.

3. Construção dos Conceitos

3.1 Availability Sets: proteção dentro do datacenter

Um Availability Set é uma agrupação lógica de VMs que instrui o Azure a distribuir essas VMs em hardware físico separado dentro de um único datacenter, usando dois conceitos: Fault Domains e Update Domains.

Fault Domains (FDs)

Um Fault Domain é um grupo de hardware que compartilha uma fonte de energia e um switch de rede comum. É, essencialmente, um rack físico.

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Se o Rack A (FD0) perde energia, apenas VM1 e VM4 são afetadas. VM2 e VM3 continuam operando. O número máximo de Fault Domains é 3 no Azure.

Update Domains (UDs)

Um Update Domain representa um grupo de VMs que podem ser reiniciadas simultaneamente durante uma atualização planejada do host (manutenção do hypervisor, atualizações de plataforma).

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

O Azure atualiza um Update Domain por vez, aguardando 30 minutos entre cada um. Com 5 VMs distribuídas em 5 Update Domains, nunca mais de 1 VM é reiniciada simultaneamente durante manutenção. O número máximo de Update Domains é 20.

Como FDs e UDs interagem

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

O Azure distribui automaticamente as VMs entre FDs e UDs ao adicionar VMs ao Availability Set. Você não escolhe em qual FD ou UD cada VM vai.

3.2 Availability Zones: proteção entre datacenters

Uma Availability Zone é um datacenter fisicamente separado dentro de uma região Azure. Cada zona tem sua própria energia, resfriamento e rede, com conexão de fibra óptica de baixa latência entre elas.

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Se o datacenter da Zone 1 tiver uma falha total (corte de energia no prédio, por exemplo), VM-Web-2 e VM-Web-3 continuam operando nas Zones 2 e 3.

Regiões com suporte a Availability Zones: Nem todas as regiões Azure têm Availability Zones. Regiões maiores como East US, West Europe, Southeast Asia e brazilsouth têm suporte. Verifique antes de arquitetar.

3.3 Flexible Orchestration e Virtual Machine Scale Sets

Além de Availability Sets tradicionais, o Azure oferece Virtual Machine Scale Sets (VMSS) com dois modos de orquestração:

Uniform Orchestration: todas as VMs são idênticas, criadas a partir do mesmo modelo. Foco em scaling automático de instâncias idênticas.

Flexible Orchestration: permite VMs heterogêneas, equivalente funcional de um Availability Set moderno com suporte a Zones.

Para o AZ-104, o foco é em Availability Sets e Availability Zones com VMs individuais.

4. Visão Estrutural

Comparação estrutural: Availability Set vs. Availability Zone

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Arquitetura de referência: aplicação de 3 camadas com alta disponibilidade

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

5. Funcionamento na Prática

Ciclo de vida de um Availability Set

100%

Scroll para zoom · Arraste para mover · 📱 Pinch para zoom no celular

Comportamentos não óbvios

Uma VM não pode ser adicionada a um Availability Set depois de criada. O Availability Set é definido na criação da VM. Se você quiser colocar uma VM existente em um Availability Set, precisa deletar e recriar a VM. Os discos podem ser preservados.

Availability Set e Availability Zone são mutuamente exclusivos. Não é possível colocar uma VM simultaneamente em um Availability Set e em uma Availability Zone específica. São mecanismos alternativos. Para usar Availability Zones, você especifica a zone na criação da VM, sem Availability Set.

VMs em Availability Zones diferentes têm latência de rede de 1-2ms entre si. Zonas são datacenters diferentes conectados por fibra óptica. A latência entre zonas na mesma região é baixa o suficiente para a maioria das aplicações, mas aplicações extremamente sensíveis a latência (trading de alta frequência) devem considerar isso.

Discos gerenciados em Availability Zones têm escopo de zona. Uma VM na Zone 1 só pode usar discos gerenciados que também estão na Zone 1. Ao criar uma VM em uma zone específica, seus discos são automaticamente criados na mesma zone.

O Availability Set não garante distribuição entre zonas. Um Availability Set protege contra falhas de hardware dentro de um datacenter. Se o datacenter inteiro falhar, todas as VMs no Availability Set são afetadas. Para proteção em nível de datacenter, use Availability Zones.

Manutenção planejada notifica com antecedência. O Azure envia notificações antes de manutenções planejadas que afetarão VMs. Com Update Domains, a manutenção é escalonada, mas cada UD passará pela manutenção em sequência.

6. Formas de Implementação

Portal do Azure

Para criar Availability Set:

Portal > Availability sets > + Create
Definir nome, região, subscription, RG
Configurar: Fault domains (1-3) e Update domains (1-20)
Selecionar: Use managed disks (Yes - Aligned recomendado)
Create

Para criar VM em Availability Set:

Portal > Virtual machines > + Create
Aba Availability > Availability set
Selecionar o Availability Set existente
Concluir criação normalmente

Para criar VM em Availability Zone:

Portal > Virtual machines > + Create
Aba Availability > Availability zone
Selecionar Zone 1, Zone 2 ou Zone 3
Concluir criação normalmente

Azure CLI

# Criar Availability Set com configuração padrão
az vm availability-set create \
  --resource-group "rg-producao" \
  --name "as-web-tier" \
  --location "brazilsouth" \
  --platform-fault-domain-count 3 \
  --platform-update-domain-count 5

# Ver detalhes do Availability Set
az vm availability-set show \
  --resource-group "rg-producao" \
  --name "as-web-tier" \
  --output json

# Criar VM dentro de um Availability Set
az vm create \
  --resource-group "rg-producao" \
  --name "vm-web-01" \
  --availability-set "as-web-tier" \
  --image "Ubuntu2204" \
  --size "Standard_D2s_v5" \
  --admin-username "azureadmin" \
  --ssh-key-values ~/.ssh/id_rsa.pub

# Criar segunda VM no mesmo Availability Set
az vm create \
  --resource-group "rg-producao" \
  --name "vm-web-02" \
  --availability-set "as-web-tier" \
  --image "Ubuntu2204" \
  --size "Standard_D2s_v5" \
  --admin-username "azureadmin" \
  --ssh-key-values ~/.ssh/id_rsa.pub

# Criar terceira VM no mesmo Availability Set
az vm create \
  --resource-group "rg-producao" \
  --name "vm-web-03" \
  --availability-set "as-web-tier" \
  --image "Ubuntu2204" \
  --size "Standard_D2s_v5" \
  --admin-username "azureadmin" \
  --ssh-key-values ~/.ssh/id_rsa.pub

# Verificar em quais FDs e UDs as VMs foram distribuídas
az vm show \
  --resource-group "rg-producao" \
  --name "vm-web-01" \
  --query "{Name: name, FD: platformFaultDomain, UD: platformUpdateDomain}" \
  --output json

# Criar VM em Availability Zone específica
az vm create \
  --resource-group "rg-producao" \
  --name "vm-web-z1" \
  --zone 1 \
  --image "Ubuntu2204" \
  --size "Standard_D2s_v5" \
  --admin-username "azureadmin" \
  --ssh-key-values ~/.ssh/id_rsa.pub \
  --location "brazilsouth"

# Criar VM em Zone 2
az vm create \
  --resource-group "rg-producao" \
  --name "vm-web-z2" \
  --zone 2 \
  --image "Ubuntu2204" \
  --size "Standard_D2s_v5" \
  --admin-username "azureadmin" \
  --ssh-key-values ~/.ssh/id_rsa.pub \
  --location "brazilsouth"

# Criar VM em Zone 3
az vm create \
  --resource-group "rg-producao" \
  --name "vm-web-z3" \
  --zone 3 \
  --image "Ubuntu2204" \
  --size "Standard_D2s_v5" \
  --admin-username "azureadmin" \
  --ssh-key-values ~/.ssh/id_rsa.pub \
  --location "brazilsouth"

# Listar VMs com suas zonas
az vm list \
  --resource-group "rg-producao" \
  --query "[].{Name: name, Zone: zones[0], Size: hardwareProfile.vmSize}" \
  --output table

# Verificar quais regiões suportam Availability Zones
az account list-locations \
  --query "[?metadata.supportsAvailabilityZones=='true'].name" \
  --output table

# Verificar regiões que suportam zonas (incluindo metadados)
az provider show \
  --namespace Microsoft.Compute \
  --query "resourceTypes[?resourceType=='virtualMachines'].zoneMappings[].location" \
  --output table

Azure PowerShell

# Criar Availability Set
New-AzAvailabilitySet `
  -ResourceGroupName "rg-producao" `
  -Name "as-web-tier" `
  -Location "brazilsouth" `
  -PlatformFaultDomainCount 3 `
  -PlatformUpdateDomainCount 5 `
  -Sku "Aligned"  # Aligned = Managed Disks

# Criar VM em Availability Set
$avSet = Get-AzAvailabilitySet -ResourceGroupName "rg-producao" -Name "as-web-tier"
$cred = Get-Credential -Message "Admin credentials"

$vmConfig = New-AzVMConfig -VMName "vm-web-01" -VMSize "Standard_D2s_v5" `
  -AvailabilitySetId $avSet.Id

$vmConfig = Set-AzVMOperatingSystem -VM $vmConfig -Linux -ComputerName "vm-web-01" -Credential $cred
$vmConfig = Set-AzVMSourceImage -VM $vmConfig -PublisherName "Canonical" -Offer "UbuntuServer" -Skus "20.04-LTS" -Version "latest"
$vmConfig = Add-AzVMNetworkInterface -VM $vmConfig -Id $nicId

New-AzVM -ResourceGroupName "rg-producao" -Location "brazilsouth" -VM $vmConfig

# Criar VM em Availability Zone
$vmConfig = New-AzVMConfig -VMName "vm-web-z1" -VMSize "Standard_D2s_v5" -Zone "1"

# ... completar configuração
New-AzVM -ResourceGroupName "rg-producao" -Location "brazilsouth" -VM $vmConfig -Zone "1"

# Ver distribuição de VMs em FDs e UDs
Get-AzVM -ResourceGroupName "rg-producao" |
  Select-Object Name, `
    @{N="Zone"; E={$_.Zones[0]}}, `
    @{N="FD"; E={$_.PlatformFaultDomain}}, `
    @{N="UD"; E={$_.PlatformUpdateDomain}} |
  Format-Table

Bicep

// Availability Set
resource availabilitySet 'Microsoft.Compute/availabilitySets@2023-03-01' = {
  name: 'as-web-tier'
  location: 'brazilsouth'
  sku: {
    name: 'Aligned'  // Aligned = Managed Disks
  }
  properties: {
    platformFaultDomainCount: 3
    platformUpdateDomainCount: 5
  }
}

// VM em Availability Set
resource vmInAvSet 'Microsoft.Compute/virtualMachines@2023-03-01' = {
  name: 'vm-web-01'
  location: 'brazilsouth'
  properties: {
    availabilitySet: {
      id: availabilitySet.id
    }
    hardwareProfile: {
      vmSize: 'Standard_D2s_v5'
    }
    // ... resto das propriedades
  }
}

// VM em Availability Zone
resource vmInZone 'Microsoft.Compute/virtualMachines@2023-03-01' = {
  name: 'vm-web-z1'
  location: 'brazilsouth'
  zones: ['1']  // Zone 1
  properties: {
    hardwareProfile: {
      vmSize: 'Standard_D2s_v5'
    }
    // ... resto das propriedades
  }
}

// Disco em Availability Zone (deve ser mesma zona da VM)
resource diskInZone 'Microsoft.Compute/disks@2022-07-02' = {
  name: 'vm-web-z1-datadisk'
  location: 'brazilsouth'
  zones: ['1']  // Mesma zone da VM
  sku: {
    name: 'Premium_LRS'
  }
  properties: {
    creationData: {
      createOption: 'Empty'
    }
    diskSizeGB: 128
  }
}

7. Controle e Segurança

Azure Policy para enforçar alta disponibilidade

# Auditar VMs sem Availability Zone ou Availability Set
az graph query -q "
Resources
| where type == 'microsoft.compute/virtualmachines'
| where isnull(zones) and isnull(properties.availabilitySet)
| project name, resourceGroup, location, subscriptionId
| order by location"

# Policy que audita VMs sem mecanismo de HA
# Criar custom policy que verifica se VM tem zone ou AS
az policy definition create \
  --name "audit-vm-ha-config" \
  --display-name "VMs devem ter Availability Zone ou Availability Set" \
  --rules '{
    "if": {
      "allOf": [
        {"field": "type", "equals": "Microsoft.Compute/virtualMachines"},
        {"field": "zones", "exists": "false"},
        {"field": "properties.availabilitySet.id", "exists": "false"}
      ]
    },
    "then": {"effect": "Audit"}
  }' \
  --mode "All"

Considerações de rede para alta disponibilidade

Load Balancers e Application Gateways também precisam ser configurados para alta disponibilidade:

Standard Load Balancer é compatível com Availability Zones e pode ser configurado como zone-redundant
Basic Load Balancer não suporta Availability Zones (use Standard)
Para VMs em Availability Zones, o Load Balancer deve ser zone-redundant ou span múltiplas zones

8. Tomada de Decisão

Availability Set vs. Availability Zone

Situação	Escolha	Motivo
Região sem suporte a AZ (ex: algumas regiões menores)	Availability Set	Única opção disponível
SLA máximo de 99,99% necessário	Availability Zone	Único modo de atingir esse SLA
Aplicação crítica em região com suporte a AZ	Availability Zone	Proteção contra falha de datacenter completo
Custo é restrição e região tem suporte a AZ	Availability Zone	Mesmo custo que VM única, SLA melhor que AS
Já existem VMs em AS e mover é custoso	Manter AS	Migração para AZ requer recriar VMs
Banco de dados com Always On Availability Group	VMs em zonas diferentes	Replicas em zonas separadas para DR
Aplicação stateless com muitas instâncias	Availability Zone	Distribui VMs em 3 datacenters separados

Número de instâncias e FDs/UDs

Número de VMs	FDs recomendados	UDs recomendados	Motivo
2 VMs	2	2	Garante que as 2 estão em FDs diferentes
3 VMs	3	3	Uma por FD, uma por UD
5 VMs	3	5	Distribuição ótima para manutenção escalonada
10 VMs	3	10	3 FDs máximo, 10 UDs para escalonamento granular
20+ VMs	3	20	Máximos do Azure

9. Boas Práticas

Prefira Availability Zones a Availability Sets para novas arquiteturas. Availability Zones oferecem proteção superior (nível de datacenter vs. nível de rack) e o mesmo custo. Availability Sets existem principalmente para compatibilidade com regiões sem suporte a Zones e para workloads legados.

Distribua VMs de cada tier em todas as zonas disponíveis. Para uma aplicação com 3 instâncias de web server, coloque uma em cada zona (Z1, Z2, Z3). Não coloque 2 em Z1 e 1 em Z2, pois se Z1 falhar você perde 2/3 da capacidade.

Use Standard Load Balancer, não Basic, para arquiteturas com zonas. O Standard LB pode ser configurado como zone-redundant, garantindo que o balanceamento de carga continue mesmo se uma zona falhar. O Basic LB não suporta Availability Zones.

Configure alertas de health do Azure Monitor para VMs em HA. Mesmo com múltiplas instâncias, monitore a saúde de cada uma. Uma instância falhada pode passar despercebida se as outras estiverem absorvendo a carga, criando um cenário de "disponível mas vulnerável".

Availability Sets devem usar Sku: Aligned para Managed Disks. O SKU Aligned garante que os discos gerenciados de uma VM estejam no mesmo Fault Domain que a VM. Com o SKU Classic (legado), discos e VMs podem estar em FDs diferentes, comprometendo a proteção contra falhas.

Planeje a manutenção com base nos Update Domains. Em janelas de manutenção programadas, saiba quantos UDs você tem e que o Azure sequencia a manutenção com 30 minutos entre cada UD. Uma AS com 5 UDs e 5 VMs levará ~2 horas para completar a manutenção de todos os UDs.

10. Erros Comuns

Erro	Por que acontece	Como evitar
VM adicionada ao AS depois de criada	Não saber que AS é imutável pós-criação	Planejar e criar com AS desde o início
VM em AS e Zone ao mesmo tempo	Mutuamente exclusivos	Escolher um ou outro na criação
Todas as 3 VMs no mesmo FD por falta de AS	VM criadas individualmente sem AS ou Zone	Sempre usar AS ou Zone em produção
AS com SKU Classic e Managed Disks	Configuração incompatível	Usar SKU Aligned para AS com Managed Disks
Usar Basic LB com VMs em Availability Zones	Basic LB não suporta AZ	Usar Standard LB sempre
Uma zone com 2 VMs e outra com 1	Distribuição desequilibrada	Distribuir igualmente: 1 por zona
Não verificar suporte a AZ na região antes de arquitetar	Assumir que todas as regiões têm AZ	Verificar suporte antes de definir arquitetura
Disco na Zone 1, VM na Zone 2	Tentativa de uso cross-zone	Discos devem estar na mesma zone que a VM

O erro mais crítico

Não usar nenhum mecanismo de HA em VMs de produção, confiando apenas no SLA de 99,9% de uma VM única. Matematicamente, isso significa até 8,7 horas de downtime por ano. Para uma aplicação com 5 VMs sem qualquer mecanismo de distribuição, se estiverem todas no mesmo rack e o rack falhar, a aplicação cai completamente. O custo de adicionar Availability Zones é zero: VMs em Availability Zones custam o mesmo que VMs sem zonas.

11. Operação e Manutenção

Verificar distribuição de VMs em FDs e UDs

# Ver distribuição de todas as VMs em um Availability Set
az vm list \
  --resource-group "rg-producao" \
  --query "[?availabilitySet != null].{
    Nome: name,
    FD: platformFaultDomain,
    UD: platformUpdateDomain,
    AS: availabilitySet.id
  }" \
  --output table

# Via Resource Graph: todas as VMs com zone e AS
az graph query -q "
Resources
| where type == 'microsoft.compute/virtualmachines'
| project 
    name,
    resourceGroup,
    location,
    zone=tostring(zones[0]),
    availabilitySet=tostring(properties.availabilitySet.id),
    faultDomain=tostring(properties.platformFaultDomain),
    updateDomain=tostring(properties.platformUpdateDomain)
| order by location, zone"

# Contar VMs por zona em uma região (para verificar distribuição)
az graph query -q "
Resources
| where type == 'microsoft.compute/virtualmachines'
| where location == 'brazilsouth'
| summarize count() by zone=tostring(zones[0])
| order by zone"

Monitorar saúde das instâncias

# Ver status de cada VM em um Availability Set
for vm in vm-web-01 vm-web-02 vm-web-03; do
  echo "=== $vm ==="
  az vm get-instance-view \
    --resource-group "rg-producao" \
    --name "$vm" \
    --query "instanceView.statuses[].{Code: code, DisplayStatus: displayStatus}" \
    --output table
done

# Configurar alerta para quando uma VM fica indisponível
az monitor activity-log alert create \
  --name "alerta-vm-indisponivel" \
  --resource-group "rg-monitoramento" \
  --condition \
    category=ResourceHealth \
  --scope "/subscriptions/<sub-id>/resourceGroups/rg-producao"

Limites importantes

Recurso	Limite
Fault Domains por Availability Set	3 (máximo)
Update Domains por Availability Set	20 (máximo)
VMs por Availability Set	Sem limite definido (prático: centenas)
Availability Zones por região	3 (padrão, algumas regiões têm mais)
VMs por Availability Zone	Limitado por quota de vCPU

12. Integração e Automação

Deploy de VMs distribuídas em zonas via Terraform

variable "vm_zones" {
  default = ["1", "2", "3"]
}

resource "azurerm_linux_virtual_machine" "web" {
  count = 3

  name                = "vm-web-z${var.vm_zones[count.index]}"
  resource_group_name = azurerm_resource_group.prod.name
  location            = azurerm_resource_group.prod.location
  size                = "Standard_D2s_v5"
  zone                = var.vm_zones[count.index]  # Z1, Z2, Z3

  # ... resto das configurações

  tags = {
    Zone = "zone-${var.vm_zones[count.index]}"
  }
}

# Load Balancer zone-redundant
resource "azurerm_lb" "main" {
  name                = "lb-web"
  resource_group_name = azurerm_resource_group.prod.name
  location            = azurerm_resource_group.prod.location
  sku                 = "Standard"  # Standard = suporte a AZ

  frontend_ip_configuration {
    name                          = "frontend"
    public_ip_address_id          = azurerm_public_ip.lb.id
    zones                         = ["1", "2", "3"]  # Zone-redundant
  }
}

Azure Policy para garantir distribuição em zonas

# Custom Policy: VMs de produção devem estar em Availability Zones
az policy definition create \
  --name "require-vm-availability-zone" \
  --display-name "VMs de producao devem usar Availability Zones" \
  --rules '{
    "if": {
      "allOf": [
        {"field": "type", "equals": "Microsoft.Compute/virtualMachines"},
        {"field": "tags.Environment", "equals": "Production"},
        {"field": "zones", "exists": "false"}
      ]
    },
    "then": {"effect": "Deny"}
  }' \
  --mode "All"

# Atribuir a policy ao RG de produção
az policy assignment create \
  --name "enforce-az-producao" \
  --policy "require-vm-availability-zone" \
  --scope "/subscriptions/<sub-id>/resourceGroups/rg-producao"

13. Resumo Final

Pontos essenciais:

Availability Set distribui VMs entre Fault Domains (racks físicos) e Update Domains (grupos de manutenção) dentro de um único datacenter. Protege contra falhas de hardware e manutenção planejada.
Availability Zone distribui VMs entre datacenters fisicamente separados dentro de uma região. Protege contra falhas de datacenter completo.
Máximo de 3 Fault Domains e 20 Update Domains por Availability Set
O Azure distribui as VMs automaticamente entre FDs e UDs ao adicionar ao AS; você não controla em qual FD cada VM vai
Uma VM não pode ser adicionada a um AS após sua criação; o AS é imutável pós-deploy
AS e Availability Zone são mutuamente exclusivos: escolha um ou outro na criação da VM
Discos gerenciados em AZ devem estar na mesma zona que a VM

Diferenças críticas:

Fault Domain vs. Update Domain: FD protege contra falhas físicas (rack/energia); UD controla manutenção planejada (sequenciamento de reinicializações)
Availability Set vs. Availability Zone: AS protege dentro do datacenter (rack); AZ protege entre datacenters (building/prédio)
SLA: VM única = 99,9%; 2+ VMs em AS = 99,95%; 2+ VMs em AZ = 99,99%
SKU Aligned vs. Classic para AS: Aligned é necessário para Managed Disks; Classic é legado

O que precisa ser lembrado para o AZ-104:

Para criar VM em AS: --availability-set <name> no CLI
Para criar VM em Zone: --zone <1|2|3> no CLI
Número de FDs padrão no portal: 2 (configurável até 3)
Número de UDs padrão no portal: 5 (configurável até 20)
Basic Load Balancer não suporta Availability Zones; use Standard LB
Availability Zones não estão disponíveis em todas as regiões; verificar antes de arquitetar
VMs em AS recebem SLA de 99,95%; VMs em AZ diferentes recebem 99,99%
A fórmula do SLA combinado de N VMs independentes: 1 - (1 - SLA_individual)^N

1. Intuição Inicial​

2. Contexto​

O problema que esses mecanismos resolvem​

SLA (Service Level Agreement) e sua dependência​

3. Construção dos Conceitos​

3.1 Availability Sets: proteção dentro do datacenter​

Fault Domains (FDs)​

Update Domains (UDs)​

Como FDs e UDs interagem​

3.2 Availability Zones: proteção entre datacenters​

3.3 Flexible Orchestration e Virtual Machine Scale Sets​

4. Visão Estrutural​

Comparação estrutural: Availability Set vs. Availability Zone​

Arquitetura de referência: aplicação de 3 camadas com alta disponibilidade​

5. Funcionamento na Prática​

Ciclo de vida de um Availability Set​

Comportamentos não óbvios​

6. Formas de Implementação​

Portal do Azure​

Azure CLI​

Azure PowerShell​

Bicep​

7. Controle e Segurança​

Azure Policy para enforçar alta disponibilidade​

Considerações de rede para alta disponibilidade​

8. Tomada de Decisão​

Availability Set vs. Availability Zone​

Número de instâncias e FDs/UDs​

9. Boas Práticas​

10. Erros Comuns​

O erro mais crítico​

11. Operação e Manutenção​

Verificar distribuição de VMs em FDs e UDs​

Monitorar saúde das instâncias​

Limites importantes​

12. Integração e Automação​

Deploy de VMs distribuídas em zonas via Terraform​

Azure Policy para garantir distribuição em zonas​

13. Resumo Final​

1. Intuição Inicial

2. Contexto

O problema que esses mecanismos resolvem

SLA (Service Level Agreement) e sua dependência

3. Construção dos Conceitos

3.1 Availability Sets: proteção dentro do datacenter

Fault Domains (FDs)

Update Domains (UDs)

Como FDs e UDs interagem

3.2 Availability Zones: proteção entre datacenters

3.3 Flexible Orchestration e Virtual Machine Scale Sets

4. Visão Estrutural

Comparação estrutural: Availability Set vs. Availability Zone

Arquitetura de referência: aplicação de 3 camadas com alta disponibilidade

5. Funcionamento na Prática

Ciclo de vida de um Availability Set

Comportamentos não óbvios

6. Formas de Implementação

Portal do Azure

Azure CLI

Azure PowerShell

Bicep

7. Controle e Segurança

Azure Policy para enforçar alta disponibilidade

Considerações de rede para alta disponibilidade

8. Tomada de Decisão

Availability Set vs. Availability Zone

Número de instâncias e FDs/UDs

9. Boas Práticas

10. Erros Comuns

O erro mais crítico

11. Operação e Manutenção

Verificar distribuição de VMs em FDs e UDs

Monitorar saúde das instâncias

Limites importantes

12. Integração e Automação

Deploy de VMs distribuídas em zonas via Terraform

Azure Policy para garantir distribuição em zonas

13. Resumo Final