Fundamentação Teórica: Deploy and Configure an Azure Virtual Machine Scale Sets

1. Intuição Inicial

Imagine que você administra um call center. Durante dias úteis de horário comercial, você precisa de 50 atendentes. Nos fins de semana, 10 são suficientes. Durante promoções sazonais, você pode precisar de 200. Contratar 200 funcionários fixos para cobrir o pico seria absurdamente caro. A solução real é ter um pool de funcionários temporários que você chama conforme a demanda.

No Azure, um Virtual Machine Scale Set (VMSS) é exatamente esse pool: um grupo de VMs idênticas que pode crescer ou diminuir automaticamente com base na demanda, criando e deletando instâncias conforme necessário, sem intervenção manual.

Enquanto criar VMs individuais e configurá-las manualmente funciona para ambientes pequenos e estáticos, o VMSS é a solução para workloads que variam com o tempo e precisam de scaling automático, gerenciamento centralizado de configuração e alta disponibilidade distribuída.

2. Contexto

Por que VMSS existe como conceito separado de VMs individuais

Gerenciar 50 VMs individuais significa: 50 atualizações de imagem manuais, 50 reinicializações para aplicar patches, 50 regras de Load Balancer para configurar, e o processo inteiro repetido cada vez que a demanda muda.

O VMSS resolve isso com um único objeto que gerencia todas as instâncias como uma unidade. Você define o modelo (imagem, tamanho, configuração de rede) uma vez, e o VMSS garante que todas as instâncias estejam em conformidade com esse modelo.

O que depende do VMSS

Load Balancer ou Application Gateway: para distribuir tráfego entre as instâncias
Auto scaling rules: para definir quando criar ou destruir instâncias
Azure Monitor: como fonte de métricas para decisões de scaling
Managed Disks: cada instância tem seus próprios discos
VNet e subnets: onde as instâncias são provisionadas

3. Construção dos Conceitos

3.1 Modos de Orquestração

O VMSS tem dois modos de orquestração com filosofias diferentes:

100%

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

Para o AZ-104 e para a maioria dos cenários práticos de scaling automático, o foco é no Uniform Orchestration.

3.2 Componentes principais de um VMSS Uniform

Instance Model (modelo de instância): define como cada VM será criada. Inclui tamanho, imagem de SO, configuração de rede, extensões e scripts de inicialização. Todas as instâncias são idênticas a este modelo.

Capacity: o número atual de instâncias. Pode ser fixo (manual scaling) ou variável (auto scaling).

Upgrade Policy: define como novas versões do modelo são aplicadas às instâncias existentes.

Scaling Rules: condições baseadas em métricas que determinam quando criar ou destruir instâncias.

3.3 Upgrade Policies

Quando você atualiza o modelo do VMSS (nova imagem de OS, nova configuração), a Upgrade Policy define como essa atualização se propaga:

Policy	Comportamento	Caso de uso
Automatic	Azure atualiza instâncias automaticamente em lotes, sem intervenção	Ambientes de dev/test, workloads tolerantes a reinicializações
Rolling	Atualiza um percentual de instâncias por vez, com verificações de saúde entre lotes	Produção onde não pode derrubar tudo de uma vez
Manual	Instâncias não são atualizadas; você atualiza manualmente instância por instância	Máximo controle, cenários especiais

Rolling Upgrade é o modo recomendado para produção pois combina automação com segurança:

100%

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

3.4 Auto Scaling: como funciona

O auto scaling no VMSS tem dois componentes: scale-out (adicionar instâncias) e scale-in (remover instâncias), cada um com suas regras independentes.

Uma regra de scaling define:

Métrica: o que medir (CPU, memória, comprimento de fila, etc.)
Threshold: o valor que dispara a ação
Operator: maior que, menor que, igual a
Action: adicionar ou remover N instâncias (ou N%)
Cooldown: período de espera após uma ação antes de avaliar novamente

100%

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

3.5 Scale-in Policy

Quando o VMSS precisa remover instâncias, a Scale-in Policy define quais instâncias são escolhidas para remoção:

Policy	Comportamento
Default	Remove instâncias nas zonas com mais instâncias, priorizando as mais antigas
OldestVM	Remove sempre a instância mais antiga (independente de zona)
NewestVM	Remove sempre a instância mais recente

OldestVM é útil para forçar atualização gradual: instâncias antigas (com modelo desatualizado) são removidas primeiro quando ocorre scale-in.

3.6 Instance Protection

Você pode marcar instâncias individuais para proteção contra scale-in ou contra atualizações do modelo:

Protect from scale-in: instância nunca é removida automaticamente
Protect from scale-set actions: instância não recebe atualizações do modelo

Útil para instâncias que estão executando processos de longa duração que não devem ser interrompidos.

3.7 Overprovisioning

Quando o VMSS cria novas instâncias (scale-out), ele pode criar mais do que o solicitado para garantir que o número alvo seja atingido mesmo se algumas falhem na inicialização. O Azure deleta as instâncias extras após confirmar que o número alvo foi atingido com saúde.

Por padrão, o overprovisioning cria ~20% a mais. Isso acelera o scaling mas pode gerar cobranças breves por instâncias extras que são deletadas em minutos.

4. Visão Estrutural

Arquitetura completa de um VMSS

100%

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

Ciclo de vida de uma instância VMSS

100%

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

5. Funcionamento na Prática

Health Probes e Application Health Extension

Para que Rolling Upgrades e auto scaling inteligente funcionem, o VMSS precisa saber se cada instância está saudável. Há dois mecanismos:

Load Balancer Health Probe: o LB verifica periodicamente se a instância está respondendo na porta configurada. Simples mas verifica apenas conectividade de rede.

Application Health Extension: uma extensão instalada na VM que verifica a saúde da aplicação via HTTP/HTTPS e reporta para o VMSS. Verifica saúde real da aplicação, não apenas conectividade.

# A extensão reporta: {"ApplicationHealthState": "Healthy"} ou {"ApplicationHealthState": "Unhealthy"}
# Endpoint configurado: http://localhost:8080/health

Comportamentos não óbvios

VMSS Uniform não suporta alteração do tamanho de disco de OS de uma instância individual. Você altera o modelo, e as instâncias são recriadas com o novo tamanho na próxima atualização. Não é possível alterar apenas uma instância.

Instâncias têm IDs numéricas, não nomes convencionais. Instâncias em um VMSS chamado vmss-web serão vmss-web_0, vmss-web_1, vmss-web_2. Os IDs não são sequenciais após deletações: se vmss-web_1 é deletada e depois uma nova instância é criada, ela pode receber o ID vmss-web_3, não vmss-web_1.

O cooldown previne oscilação mas pode atrasar resposta a picos súbitos. Um cooldown de 5 minutos significa que após um scale-out, o VMSS não vai escalar de novo por 5 minutos, mesmo se a carga continuar crescendo. Para picos súbitos, configure cooldowns menores com regras mais agressivas.

Scale-in de instâncias com estado pode causar perda de dados. Em workloads stateful (sessões de usuário, processos em andamento), remover uma instância no meio de uma operação pode perder trabalho em progresso. Para workloads stateful, use Drain (esvaziar conexões antes de remover) ou configure webhooks de terminação.

Overprovisioning pode ser problemático com inicializações lentas. Se a aplicação demora 10 minutos para inicializar e o overprovisioning cria 10 instâncias extras que serão deletadas, isso desperdiça 10 × 10 minutos de inicialização. Para aplicações com inicialização lenta, considere desabilitar overprovisioning.

6. Formas de Implementação

Portal do Azure

Quando usar: criação inicial, exploração das opções, configuração de autoscaling via interface visual

Criar VMSS pelo portal:

Portal > Virtual machine scale sets > + Create
Definir: subscription, RG, nome, região, zonas de disponibilidade
Orchestration mode: Uniform ou Flexible
Selecionar imagem e tamanho
Configurar credenciais de admin
Aba Disks: tipo de disco OS
Aba Networking: VNet, subnet, LB
Aba Scaling: capacidade inicial, min/max, upgrade policy
Aba Health: habilitar health monitoring
Review + Create

Para configurar Auto Scaling via portal após criação:

VMSS > Scaling > Custom autoscale > adicionar regras de scale-out e scale-in

Azure CLI

# Criar VMSS básico com autoscale
az vmss create \
  --resource-group "rg-producao" \
  --name "vmss-web" \
  --image "Ubuntu2204" \
  --vm-sku "Standard_D2s_v5" \
  --instance-count 3 \
  --admin-username "azureadmin" \
  --ssh-key-values ~/.ssh/id_rsa.pub \
  --zones 1 2 3 \
  --upgrade-policy-mode Rolling \
  --load-balancer "lb-web" \
  --backend-pool-name "bepool-web" \
  --location "brazilsouth"

# Verificar instâncias criadas
az vmss list-instances \
  --resource-group "rg-producao" \
  --name "vmss-web" \
  --output table

# Configurar Autoscale: scale-out quando CPU > 75%
az monitor autoscale create \
  --resource-group "rg-producao" \
  --resource "vmss-web" \
  --resource-type "Microsoft.Compute/virtualMachineScaleSets" \
  --name "autoscale-vmss-web" \
  --min-count 2 \
  --max-count 10 \
  --count 3

# Adicionar regra de scale-out
az monitor autoscale rule create \
  --resource-group "rg-producao" \
  --autoscale-name "autoscale-vmss-web" \
  --scale out 2 \
  --condition "Percentage CPU > 75 avg 5m"

# Adicionar regra de scale-in
az monitor autoscale rule create \
  --resource-group "rg-producao" \
  --autoscale-name "autoscale-vmss-web" \
  --scale in 1 \
  --condition "Percentage CPU < 25 avg 10m"

# Escalar manualmente para 5 instâncias
az vmss scale \
  --resource-group "rg-producao" \
  --name "vmss-web" \
  --new-capacity 5

# Atualizar o modelo (ex: nova imagem)
az vmss update \
  --resource-group "rg-producao" \
  --name "vmss-web" \
  --set virtualMachineProfile.storageProfile.imageReference.version="latest"

# Com upgrade policy Manual: atualizar instância específica
az vmss update-instances \
  --resource-group "rg-producao" \
  --name "vmss-web" \
  --instance-ids 1 2

# Com upgrade policy Manual: atualizar todas as instâncias
az vmss update-instances \
  --resource-group "rg-producao" \
  --name "vmss-web" \
  --instance-ids "*"

# Reimager uma instância (recriar do zero a partir do modelo)
az vmss reimage \
  --resource-group "rg-producao" \
  --name "vmss-web" \
  --instance-id 3

# Reimager todas as instâncias
az vmss reimage \
  --resource-group "rg-producao" \
  --name "vmss-web"

# Configurar scale-in policy para remover VMs mais antigas primeiro
az vmss update \
  --resource-group "rg-producao" \
  --name "vmss-web" \
  --scale-in-policy OldestVM

# Aplicar proteção de scale-in em uma instância específica
az vmss update \
  --resource-group "rg-producao" \
  --name "vmss-web" \
  --instance-id 2 \
  --protect-from-scale-in true

# Ver status de saúde das instâncias
az vmss get-instance-view \
  --resource-group "rg-producao" \
  --name "vmss-web" \
  --instance-id 0 \
  --query "vmHealth"

# Ver configuração de autoscale
az monitor autoscale show \
  --resource-group "rg-producao" \
  --name "autoscale-vmss-web" \
  --output json

# Configurar schedule scaling (ex: escalar às 8h e reduzir às 18h)
az monitor autoscale profile create \
  --autoscale-name "autoscale-vmss-web" \
  --resource-group "rg-producao" \
  --name "horario-comercial" \
  --min-count 5 \
  --max-count 10 \
  --count 5 \
  --start "2026-01-01 08:00" \
  --end "2027-12-31 18:00" \
  --recurrence week mo tu we th fr \
  --timezone "E. South America Standard Time"

Azure PowerShell

# Criar configuração do VMSS
$vmssConfig = New-AzVmssConfig `
  -Location "brazilsouth" `
  -SkuCapacity 3 `
  -SkuName "Standard_D2s_v5" `
  -UpgradePolicyMode Rolling `
  -Zone @("1", "2", "3")

# Configurar imagem
$vmssConfig = Set-AzVmssStorageProfile `
  -VirtualMachineScaleSet $vmssConfig `
  -ImageReferencePublisher "Canonical" `
  -ImageReferenceOffer "0001-com-ubuntu-server-jammy" `
  -ImageReferenceSku "22_04-lts-gen2" `
  -ImageReferenceVersion "latest" `
  -OsDiskCreateOption FromImage `
  -ManagedDisk @{storageAccountType = "Premium_LRS"}

# Configurar OS
$vmssConfig = Set-AzVmssOsProfile `
  -VirtualMachineScaleSet $vmssConfig `
  -ComputerNamePrefix "web" `
  -AdminUsername "azureadmin" `
  -AdminPassword "<senha-segura>"

# Configurar rede
$ipConfig = New-AzVmssIpConfig `
  -Name "ipconfig" `
  -SubnetId $subnetId `
  -LoadBalancerBackendAddressPoolsId $lbBackendPoolId

$vmssConfig = Add-AzVmssNetworkInterfaceConfiguration `
  -VirtualMachineScaleSet $vmssConfig `
  -Name "nicconfig" `
  -Primary $true `
  -IpConfiguration $ipConfig

# Criar VMSS
$vmss = New-AzVmss `
  -ResourceGroupName "rg-producao" `
  -VMScaleSetName "vmss-web" `
  -VirtualMachineScaleSet $vmssConfig

# Configurar Autoscale
$scaleOutRule = New-AzAutoscaleRule `
  -MetricName "Percentage CPU" `
  -MetricResourceId $vmss.Id `
  -TimeGrain ([TimeSpan]::FromMinutes(1)) `
  -Statistic Average `
  -TimeWindow ([TimeSpan]::FromMinutes(5)) `
  -TimeAggregationOperator Average `
  -Operator GreaterThan `
  -Threshold 75 `
  -ScaleActionCooldown ([TimeSpan]::FromMinutes(5)) `
  -ScaleActionDirection Increase `
  -ScaleActionValue 2 `
  -ScaleActionType ChangeCount

$scaleInRule = New-AzAutoscaleRule `
  -MetricName "Percentage CPU" `
  -MetricResourceId $vmss.Id `
  -TimeGrain ([TimeSpan]::FromMinutes(1)) `
  -Statistic Average `
  -TimeWindow ([TimeSpan]::FromMinutes(10)) `
  -TimeAggregationOperator Average `
  -Operator LessThan `
  -Threshold 25 `
  -ScaleActionCooldown ([TimeSpan]::FromMinutes(5)) `
  -ScaleActionDirection Decrease `
  -ScaleActionValue 1 `
  -ScaleActionType ChangeCount

$profile = New-AzAutoscaleProfile `
  -DefaultCapacity 3 `
  -MaximumCapacity 10 `
  -MinimumCapacity 2 `
  -Rule @($scaleOutRule, $scaleInRule) `
  -Name "default-profile"

Add-AzAutoscaleSetting `
  -ResourceGroupName "rg-producao" `
  -Location "brazilsouth" `
  -Name "autoscale-vmss-web" `
  -TargetResourceId $vmss.Id `
  -AutoscaleProfile $profile

Bicep

// VMSS com autoscale
resource vmss 'Microsoft.Compute/virtualMachineScaleSets@2023-03-01' = {
  name: 'vmss-web'
  location: 'brazilsouth'
  zones: ['1', '2', '3']
  sku: {
    name: 'Standard_D2s_v5'
    capacity: 3
  }
  properties: {
    upgradePolicy: {
      mode: 'Rolling'
      rollingUpgradePolicy: {
        maxBatchInstancePercent: 20
        maxUnhealthyInstancePercent: 20
        maxUnhealthyUpgradedInstancePercent: 20
        pauseTimeBetweenBatches: 'PT30S'
      }
    }
    automaticRepairsPolicy: {
      enabled: true
      gracePeriod: 'PT10M'
    }
    virtualMachineProfile: {
      osProfile: {
        computerNamePrefix: 'web'
        adminUsername: adminUsername
        adminPassword: adminPassword
        linuxConfiguration: {
          disablePasswordAuthentication: true
          ssh: {
            publicKeys: [
              {
                path: '/home/azureadmin/.ssh/authorized_keys'
                keyData: sshPublicKey
              }
            ]
          }
        }
      }
      storageProfile: {
        imageReference: {
          publisher: 'Canonical'
          offer: '0001-com-ubuntu-server-jammy'
          sku: '22_04-lts-gen2'
          version: 'latest'
        }
        osDisk: {
          createOption: 'FromImage'
          managedDisk: {
            storageAccountType: 'Premium_LRS'
          }
        }
      }
      networkProfile: {
        networkInterfaceConfigurations: [
          {
            name: 'nicconfig'
            properties: {
              primary: true
              ipConfigurations: [
                {
                  name: 'ipconfig'
                  properties: {
                    subnet: {
                      id: subnetId
                    }
                    loadBalancerBackendAddressPools: [
                      {
                        id: lbBackendPoolId
                      }
                    ]
                  }
                }
              ]
            }
          }
        ]
      }
      extensionProfile: {
        extensions: [
          {
            name: 'ApplicationHealthExtension'
            properties: {
              publisher: 'Microsoft.ManagedServices'
              type: 'ApplicationHealthLinux'
              typeHandlerVersion: '1.0'
              settings: {
                protocol: 'http'
                port: 8080
                requestPath: '/health'
              }
            }
          }
        ]
      }
    }
    scaleInPolicy: {
      rules: ['OldestVM']
    }
    overprovision: true
  }
}

// Auto Scale settings
resource autoscale 'Microsoft.Insights/autoscaleSettings@2022-10-01' = {
  name: 'autoscale-vmss-web'
  location: 'brazilsouth'
  properties: {
    enabled: true
    targetResourceUri: vmss.id
    profiles: [
      {
        name: 'default'
        capacity: {
          default: '3'
          minimum: '2'
          maximum: '10'
        }
        rules: [
          {
            metricTrigger: {
              metricName: 'Percentage CPU'
              metricResourceUri: vmss.id
              timeGrain: 'PT1M'
              statistic: 'Average'
              timeWindow: 'PT5M'
              timeAggregation: 'Average'
              operator: 'GreaterThan'
              threshold: 75
            }
            scaleAction: {
              direction: 'Increase'
              type: 'ChangeCount'
              value: '2'
              cooldown: 'PT5M'
            }
          }
          {
            metricTrigger: {
              metricName: 'Percentage CPU'
              metricResourceUri: vmss.id
              timeGrain: 'PT1M'
              statistic: 'Average'
              timeWindow: 'PT10M'
              timeAggregation: 'Average'
              operator: 'LessThan'
              threshold: 25
            }
            scaleAction: {
              direction: 'Decrease'
              type: 'ChangeCount'
              value: '1'
              cooldown: 'PT5M'
            }
          }
        ]
      }
    ]
  }
}

7. Controle e Segurança

Managed Identity para VMSS

# Atribuir System-Assigned Managed Identity ao VMSS
az vmss identity assign \
  --resource-group "rg-producao" \
  --name "vmss-web" \
  --identities [system]

# Dar permissão ao VMSS para acessar Key Vault
VMSS_IDENTITY=$(az vmss show \
  --resource-group "rg-producao" \
  --name "vmss-web" \
  --query "identity.principalId" --output tsv)

az keyvault set-policy \
  --name "kv-producao" \
  --object-id "$VMSS_IDENTITY" \
  --secret-permissions get list

VMSS com Azure Policy

# Auditar VMSS sem autoscale configurado
az graph query -q "
Resources
| where type == 'microsoft.compute/virtualmachinescalesets'
| where isnull(properties.scaleInPolicy)
| project name, resourceGroup, location"

# Verificar instâncias com modelo desatualizado (precisam de update)
az vmss list-instances \
  --resource-group "rg-producao" \
  --name "vmss-web" \
  --query "[?latestModelApplied == false].{ID: instanceId, Nome: osProfile.computerName}" \
  --output table

Automatic Repairs

O VMSS pode ser configurado para reparar automaticamente instâncias não saudáveis: se uma instância reportar saúde ruim por um período configurado (grace period), o VMSS deleta e recria aquela instância automaticamente.

# Habilitar automatic repairs
az vmss update \
  --resource-group "rg-producao" \
  --name "vmss-web" \
  --enable-automatic-repairs true \
  --automatic-repairs-grace-period "PT10M"

8. Tomada de Decisão

VMSS vs. VMs individuais

Situação	Escolha	Motivo
Web app com tráfego variável	VMSS	Scaling automático ajusta capacidade
Banco de dados primário stateful	VMs individuais	VMSS não é ideal para state; use AS ou AZ
Processamento de batch em lotes	VMSS com scaling por fila	Escala para processar fila, reduz para zero após
Ambientes de dev com 2-3 VMs	VMs individuais	VMSS overhead desnecessário para volumes pequenos
API de alta disponibilidade	VMSS com zonas	Distribuição automática + scaling
Aplicação que precisa de VMs heterogêneas	VMSS Flexible	Permite configurações diferentes por instância

Upgrade Policy por cenário

Cenário	Policy	Motivo
API de produção que não pode ter downtime total	Rolling	Atualiza em lotes com health checks
Ambiente de dev/test	Automatic	Conveniência, tolerante a interruções
Aplicação crítica com deploy controlado	Manual	Máximo controle sobre quando e quais instâncias
Black Friday (congelar mudanças durante pico)	Manual	Nenhuma atualização automática no pico

Configuração de Auto Scale

Workload	Scale-out threshold	Scale-in threshold	Cooldown
API REST (CPU bound)	CPU > 75% por 5min	CPU < 25% por 10min	5min
Worker de fila (queue depth)	Fila > 100 mensagens	Fila < 10 mensagens	3min
App com picos previsíveis	Schedule scaling para horários específicos	Schedule	N/A
ML inference (GPU)	GPU util > 80%	GPU util < 20%	10min

9. Boas Práticas

Sempre configure min e max capacity. Um VMSS sem limites pode escalar indefinidamente, gerando custos inesperados. Defina sempre minCount baseado no número mínimo para HA e maxCount baseado na capacidade máxima de custo aceitável.

Use pelo menos 2 regras: uma de scale-out e uma de scale-in. Um VMSS com apenas regra de scale-out vai crescer indefinidamente e nunca diminuir. Um com apenas scale-in pode se auto-destruir. Sempre configure ambas.

Configure scale-in de forma conservadora (threshold menor, window maior). Scale-in agressivo pode causar flapping: o sistema escala para fora, depois para dentro, depois para fora novamente em ciclos rápidos. Use um threshold baixo (CPU < 25%) e uma janela de tempo maior (10+ minutos) para scale-in.

Use Application Health Extension em vez de apenas LB Health Probe. A extensão verifica se a aplicação está realmente funcionando, não apenas se a VM está respondendo na porta. Rolling upgrades e automatic repairs são muito mais confiáveis com application health.

Para workloads com estado de sessão, use sticky sessions ou session store externo. Se usuários têm sessões ativas e o VMSS faz scale-in, a sessão pode estar em uma instância que será removida. Use Azure Redis Cache como session store externo ou configure sticky sessions no LB.

Teste o comportamento de scaling antes de produção. Execute testes de carga que provoquem scale-out e scale-in controlados. Verifique que os health checks funcionam, que o LB distribui tráfego corretamente e que não há erros durante a transição.

Use o modelo de Custom Script Extension ou cloud-init para configuração inicial. Não inclua configurações sensíveis no modelo do VMSS. Use cloud-init (Linux) ou Custom Script Extension para configurar aplicações na primeira inicialização, puxando configurações do Key Vault.

10. Erros Comuns

Erro	Por que acontece	Como evitar
VMSS oscilando (flapping) entre scale-out e scale-in	Cooldown muito curto ou thresholds muito próximos	Aumentar cooldown e separar thresholds
Instâncias com modelo desatualizado em produção	Upgrade policy Manual com esquecimento de aplicar	Usar Rolling para produção com health checks
Scale-out não acontece mesmo com CPU alta	Autoscale criado mas não vinculado ao VMSS corretamente	Verificar targetResourceUri no autoscale setting
Instâncias removidas com sessões ativas	Scale-in sem drain de conexões	Usar session store externo ou sticky sessions
Overprovisioning com inicialização lenta gerando custo	App com inicialização de 20+ minutos com overprovision ativo	Desabilitar overprovision para apps com init lento
maxCount muito baixo impedindo resposta a pico	maxCount definido arbitrariamente	Calcular maxCount baseado em testes de capacidade
VMSS sem health extension com rolling upgrade	Rolling upgrades sem saúde verificada podem derrubar todas as instâncias	Sempre habilitar Application Health Extension com rolling upgrades
Scaling por CPU sem considerar outras gargalos	Aplicação tem gargalo de banco de dados, não CPU	Identificar o real gargalo; considerar métricas customizadas

O erro mais crítico

Configurar uma regra de scale-out sem a correspondente de scale-in, ou configurar scale-in com threshold muito alto (ex: CPU < 80% reduz instâncias). No primeiro caso, o VMSS crescerá até o maxCount e ficará lá para sempre. No segundo, reduzirá instâncias antes de a carga realmente diminuir, causando degradação de performance imediata.

11. Operação e Manutenção

Monitorar estado do VMSS

# Status de todas as instâncias
az vmss list-instances \
  --resource-group "rg-producao" \
  --name "vmss-web" \
  --query "[].{
    ID: instanceId,
    Nome: osProfile.computerName,
    ModelAtualizado: latestModelApplied,
    Estado: provisioningState
  }" \
  --output table

# Ver histórico de scaling
az monitor activity-log list \
  --resource-group "rg-producao" \
  --query "[?operationName.value=='Microsoft.Compute/virtualMachineScaleSets/write'].{
    Hora: eventTimestamp,
    Operacao: operationName.value,
    Status: status.value
  }" \
  --output table

# Ver configuração atual de autoscale
az monitor autoscale show \
  --resource-group "rg-producao" \
  --name "autoscale-vmss-web" \
  --query "{Min: profiles[0].capacity.minimum, Max: profiles[0].capacity.maximum, Default: profiles[0].capacity.default}" \
  --output json

# Verificar se há instâncias não saudáveis
az vmss list-instances \
  --resource-group "rg-producao" \
  --name "vmss-web" \
  --query "[?provisioningState != 'Succeeded'].{ID: instanceId, Estado: provisioningState}" \
  --output table

Limites importantes

Limite	Valor
Instâncias por VMSS (Uniform)	1.000 com Managed Disks; 600 sem
Instâncias por VMSS (Flexible)	1.000
Regras de autoscale por profile	10
Profiles de autoscale por VMSS	20
Fault Domains (com zonas)	1-5 (configurável)
Instâncias que podem ser atualizadas simultaneamente (Rolling)	Configurável, padrão 20%

12. Integração e Automação

VMSS com Azure Service Bus para scaling orientado a eventos

100%

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

# Configurar autoscale com métrica customizada (Service Bus queue)
az monitor autoscale rule create \
  --resource-group "rg-producao" \
  --autoscale-name "autoscale-vmss-workers" \
  --condition "ActiveMessages > 100 avg 5m where EntityName == fila-trabalho" \
  --scale out 3

Deploy pipeline com zero-downtime via Rolling Upgrade

# Azure DevOps Pipeline: atualizar imagem do VMSS com zero-downtime
steps:
  - task: AzureCLI@2
    displayName: 'Update VMSS Image'
    inputs:
      azureSubscription: 'prod-subscription'
      scriptType: 'bash'
      scriptLocation: 'inlineScript'
      inlineScript: |
        # Atualizar referência de imagem no modelo
        az vmss update \
          --resource-group rg-producao \
          --name vmss-web \
          --set virtualMachineProfile.storageProfile.imageReference.version=$(IMAGE_VERSION)
        
        # Com upgrade policy Rolling, o Azure inicia automaticamente
        # Aguardar conclusão do rolling upgrade
        az vmss rolling-upgrade start \
          --resource-group rg-producao \
          --name vmss-web
        
        # Monitorar progresso
        while true; do
          STATUS=$(az vmss rolling-upgrade get-latest \
            --resource-group rg-producao \
            --name vmss-web \
            --query "runningStatus.code" -o tsv)
          echo "Status: $STATUS"
          if [ "$STATUS" == "RollingForwardCompleted" ]; then
            echo "Rolling upgrade concluido com sucesso"
            break
          elif [ "$STATUS" == "Cancelled" ] || [ "$STATUS" == "Faulted" ]; then
            echo "Rolling upgrade falhou: $STATUS"
            exit 1
          fi
          sleep 30
        done

13. Resumo Final

Pontos essenciais:

VMSS é um grupo de VMs idênticas gerenciadas como uma unidade, com scaling automático baseado em métricas
O modo Uniform é para instâncias idênticas com scaling automático; o modo Flexible permite instâncias heterogêneas
Upgrade Policy define como mudanças no modelo se propagam: Automatic (imediato), Rolling (em lotes com health checks), Manual (você controla)
Auto Scaling requer pelo menos uma regra de scale-out E uma de scale-in; cooldown previne flapping
A Scale-in Policy define qual instância é removida: Default (por zona e idade), OldestVM, NewestVM
Application Health Extension é necessária para Rolling Upgrades e Automatic Repairs funcionarem corretamente
Overprovisioning cria instâncias extras temporariamente para garantir que o número alvo seja atingido

Diferenças críticas:

VMSS vs. VMs individuais: VMSS é para workloads elásticos que variam com o tempo; VMs individuais são para workloads estáticos ou stateful
Uniform vs. Flexible: Uniform = instâncias idênticas com rolling upgrade nativo; Flexible = instâncias heterogêneas, mais próximo de um Availability Set moderno
Scale-out cooldown vs. Scale-in cooldown: são configurados separadamente; scale-in geralmente precisa de cooldown maior para evitar flapping
Update vs. Reimage: Update aplica mudanças do modelo à instância existente; Reimage recria a instância do zero a partir do modelo

O que precisa ser lembrado para o AZ-104:

Comando para escalar manualmente: az vmss scale --new-capacity <N>
Comando para ver instâncias: az vmss list-instances
Comando para atualizar instâncias (policy Manual): az vmss update-instances --instance-ids "*"
Autoscale é um recurso separado do VMSS: Microsoft.Insights/autoscaleSettings
VMSS com zonas requer que os discos gerenciados também sejam zone-aware
Limite de 1.000 instâncias por VMSS com Managed Disks
Rolling Upgrade sem Application Health Extension pode resultar em atualização de instâncias não saudáveis, potencialmente derrubando toda a camada
Instâncias VMSS têm nomes no formato {vmssname}_{id} onde IDs não são necessariamente sequenciais

1. Intuição Inicial​

2. Contexto​

Por que VMSS existe como conceito separado de VMs individuais​

O que depende do VMSS​

3. Construção dos Conceitos​

3.1 Modos de Orquestração​

3.2 Componentes principais de um VMSS Uniform​

3.3 Upgrade Policies​

3.4 Auto Scaling: como funciona​

3.5 Scale-in Policy​

3.6 Instance Protection​

3.7 Overprovisioning​

4. Visão Estrutural​

Arquitetura completa de um VMSS​

Ciclo de vida de uma instância VMSS​

5. Funcionamento na Prática​

Health Probes e Application Health Extension​

Comportamentos não óbvios​

6. Formas de Implementação​

Portal do Azure​

Azure CLI​

Azure PowerShell​

Bicep​

7. Controle e Segurança​

Managed Identity para VMSS​

VMSS com Azure Policy​

Automatic Repairs​

8. Tomada de Decisão​

VMSS vs. VMs individuais​

Upgrade Policy por cenário​

Configuração de Auto Scale​

9. Boas Práticas​

10. Erros Comuns​

O erro mais crítico​

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

Monitorar estado do VMSS​

Limites importantes​

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

VMSS com Azure Service Bus para scaling orientado a eventos​

Deploy pipeline com zero-downtime via Rolling Upgrade​

13. Resumo Final​

1. Intuição Inicial

2. Contexto

Por que VMSS existe como conceito separado de VMs individuais

O que depende do VMSS

3. Construção dos Conceitos

3.1 Modos de Orquestração

3.2 Componentes principais de um VMSS Uniform

3.3 Upgrade Policies

3.4 Auto Scaling: como funciona

3.5 Scale-in Policy

3.6 Instance Protection

3.7 Overprovisioning

4. Visão Estrutural

Arquitetura completa de um VMSS

Ciclo de vida de uma instância VMSS

5. Funcionamento na Prática

Health Probes e Application Health Extension

Comportamentos não óbvios

6. Formas de Implementação

Portal do Azure

Azure CLI

Azure PowerShell

Bicep

7. Controle e Segurança

Managed Identity para VMSS

VMSS com Azure Policy

Automatic Repairs

8. Tomada de Decisão

VMSS vs. VMs individuais

Upgrade Policy por cenário

Configuração de Auto Scale

9. Boas Práticas

10. Erros Comuns

O erro mais crítico

11. Operação e Manutenção

Monitorar estado do VMSS

Limites importantes

12. Integração e Automação

VMSS com Azure Service Bus para scaling orientado a eventos

Deploy pipeline com zero-downtime via Rolling Upgrade

13. Resumo Final