Fundamentação Teórica: Manage Virtual Machine Sizes

1. Intuição Inicial

Imagine que você está montando um escritório para funcionários com perfis muito diferentes. Um designer gráfico precisa de uma workstation poderosa com muita memória e GPU. Um analista financeiro precisa de muita CPU para rodar modelos. Um funcionário administrativo que só usa e-mail e planilhas simples funciona bem com um computador básico.

Colocar todos em máquinas idênticas seria desperdiçador ou insuficiente. O correto é dimensionar cada máquina para a função que ela vai exercer.

No Azure, VM Size é exatamente essa decisão de dimensionamento: a escolha de quantas CPUs virtuais, quanta memória, que tipo e quantidade de armazenamento temporário, e que capacidade de rede cada VM terá. Cada combinação recebe um nome padronizado como Standard_D4s_v5 (4 vCPUs, 16 GB RAM, otimizada para uso geral).

Gerenciar VM Sizes significa não apenas escolher o tamanho certo na criação, mas também saber como mudar esse tamanho quando a carga de trabalho evolui, sem precisar recriar a VM do zero.

2. Contexto

Por que VM Sizes existem como conceito formal

A Microsoft opera centenas de datacenters com hardware físico específico. Para que um cliente possa reservar uma fatia desse hardware, é necessário um catálogo padronizado de configurações que o hardware suporta. Esse catálogo é o conjunto de VM Sizes disponíveis.

Do ponto de vista do cliente, VM Sizes existem para:

Controle de custos: pagar exatamente pelo que a carga de trabalho precisa
Garantia de performance: selecionar hardware otimizado para o tipo de workload
Escalabilidade: aumentar ou diminuir recursos sem recriar infraestrutura

O que depende da escolha correta de VM Size

Custo: a maior parte do custo de uma VM vem do seu tamanho
Performance: aplicações com sizing inadequado são lentas ou falham
Disponibilidade: alguns SKUs não estão disponíveis em todas as regiões
Funcionalidades: certas capacidades (Ultra SSD, Accelerated Networking, GPU) só estão disponíveis em SKUs específicos

3. Construção dos Conceitos

3.1 A nomenclatura dos VM Sizes

Entender o nome de um SKU de VM é essencial para navegar o catálogo sem precisar memorizar cada opção. A estrutura é:

[Familia][SubFamilia][Versao][Aditivos]_v[N]

Exemplo: Standard_D4ds_v5

Segmento	Valor	Significado
Tier	Standard	Nível (Basic foi descontinuado)
Family	D	Uso geral (D = General Purpose)
vCPU count	4	4 vCPUs
Sub-family	d	Disco temporário local NVMe
Features	s	Suporte a Premium Storage
Version	v5	5ª geração deste SKU

3.2 Letras de subfamília e features

100%

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

O sufixo s é especialmente importante: sem ele, o SKU não suporta Premium SSD. Por exemplo, Standard_D4_v5 não suporta Premium Storage, mas Standard_D4s_v5 sim.

3.3 Famílias de VM por tipo de workload

O Azure organiza os SKUs em famílias por propósito:

Família	Letra	Característica	Workloads típicos
General Purpose	B, D, D(a/s), DC	CPU:Memória equilibrado (1:4)	Web servers, dev/test, bancos de dados pequenos
Compute Optimized	F, FX	Alta CPU, menos memória (1:2)	Servidores web intensivos, processamento batch
Memory Optimized	E, E(a/s), M, Mv2	Muita memória (1:8 ou mais)	SAP HANA, SQL Server, Redis, grandes caches
Storage Optimized	L	Alto I/O em disco local	NoSQL, data warehouses, big data
GPU	N (NC, ND, NV)	GPUs NVIDIA	Machine learning, rendering, visualização
High Performance Compute	H, HB, HC	InfiniBand, alta CPU	Simulações científicas, CFD, molecular dynamics
Confidential Computing	DC	Trusted Execution Env	Workloads com dados altamente sensíveis

3.4 A série B: Burstable VMs

A família B merece explicação especial pois funciona de forma diferente das demais. VMs Burstable acumulam créditos de CPU quando a utilização está abaixo do baseline e os consomem quando precisam de mais CPU.

100%

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

VMs B são ideais para workloads com baixo uso médio de CPU e picos esporádicos: servidores de desenvolvimento, ambientes de teste, servidores de CI/CD com builds periódicos. Não são adequadas para workloads com uso contínuo alto de CPU.

3.5 Redimensionamento: como e quando acontece

Mudar o tamanho de uma VM existente é chamado de resize. Há dois cenários técnicos:

Resize dentro da mesma família de hardware (mesmo cluster):

Pode ser feito sem desalocação em muitos casos
O Azure tenta fazer o resize sem mover a VM para outro host físico
Ainda pode requerer reinicialização breve

Resize para outra família de hardware:

Requer desalocação da VM (stop + deallocate, não apenas stop)
A VM é movida para um host físico diferente que suporta o novo SKU
Tempo de indisponibilidade de alguns minutos

100%

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

4. Visão Estrutural

Hierarquia de decisão para escolha de VM Size

100%

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

Comparação de SKUs da família D (uso geral) mais comuns

SKU	vCPU	RAM	Disco Temp	Premium Storage	Uso típico
Standard_B2s	2	4 GB	8 GB	Sim	Dev/test, sites pequenos
Standard_D2s_v5	2	8 GB	Nenhum	Sim	Uso geral leve
Standard_D4s_v5	4	16 GB	Nenhum	Sim	Uso geral médio
Standard_D4ds_v5	4	16 GB	150 GB NVMe	Sim	Uso geral com temp disk
Standard_D8s_v5	8	32 GB	Nenhum	Sim	Uso geral intenso
Standard_D16s_v5	16	64 GB	Nenhum	Sim	Uso geral alto

5. Funcionamento na Prática

Processo de resize de uma VM

100%

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

Comportamentos não óbvios importantes

Resize sem desalocação depende de capacidade no cluster atual. Mesmo que o novo SKU seja da mesma família, se o host físico atual não tiver capacidade para alocar o tamanho maior, o resize falhará. A mensagem de erro indicará que não há capacidade disponível. A solução é desalocar e tentar novamente (a VM será alocada em um host diferente).

Desalocação libera o IP público dinâmico. Se a VM usa um IP público com alocação Dinâmica, ao desalocar a VM para resize, o IP é liberado e um novo IP é atribuído quando a VM inicia. Para evitar isso, use IP público com alocação Estática antes de desalocar.

Disco temporário muda de tamanho com o SKU. O disco temporário (D: no Windows, /dev/sdb em Linux) tem seu tamanho determinado pelo SKU. Ao fazer resize para um SKU menor, o disco temporário diminui. Dados no disco temporário são perdidos em qualquer desalocação ou resize.

Algumas funcionalidades ficam indisponíveis ao fazer downsize. Se a VM tem Accelerated Networking habilitado e você faz resize para um SKU que não suporta essa funcionalidade, ela é automaticamente desabilitada. O mesmo vale para caches de discos de alta performance.

VMs em Availability Sets têm SKUs possíveis limitados. Um Availability Set é mapeado a um cluster físico específico. Apenas SKUs disponíveis naquele cluster podem ser usados. Para usar um SKU de outra família, pode ser necessário recriar a VM fora do Availability Set.

VMs em Availability Zones têm mais flexibilidade de SKU. Zones usam hardware distribuído em múltiplos datacenters, oferecendo maior variedade de SKUs disponíveis comparado a Availability Sets.

6. Formas de Implementação

Portal do Azure

Quando usar: resize pontual, verificação visual de SKUs disponíveis

Para fazer resize pelo portal:

Portal > Virtual Machines > selecionar a VM
Menu lateral > Size (em Settings)
O portal exibe os SKUs disponíveis para aquela VM naquela região
Selecionar o novo SKU
Resize

O portal mostrará automaticamente apenas os SKUs que estão disponíveis para aquela VM naquela configuração (respeitando Availability Set, zona, etc.).

Limitação: não reproduzível, sem controle de versão, impraticável para múltiplas VMs.

Azure CLI

# Listar todos os SKUs disponíveis em uma região
az vm list-sizes \
  --location "brazilsouth" \
  --output table

# Filtrar SKUs por família (ex: família D)
az vm list-sizes \
  --location "brazilsouth" \
  --query "[?starts_with(name, 'Standard_D')]" \
  --output table

# Verificar SKUs disponíveis para resize de uma VM específica
# (considera Availability Set e localização)
az vm list-vm-resize-options \
  --resource-group "rg-producao" \
  --name "vm-web-01" \
  --output table

# Ver o SKU atual da VM
az vm show \
  --resource-group "rg-producao" \
  --name "vm-web-01" \
  --query "hardwareProfile.vmSize" \
  --output tsv

# Resize sem desalocação (tenta primeiro sem parar)
az vm resize \
  --resource-group "rg-producao" \
  --name "vm-web-01" \
  --size "Standard_D4s_v5"

# Resize que requer desalocação (família diferente)
# Passo 1: Preservar o IP público se for dinâmico
# Verificar tipo de IP
az network public-ip show \
  --resource-group "rg-producao" \
  --name "pip-vm-web-01" \
  --query "publicIPAllocationMethod" \
  --output tsv

# Se for Dynamic, mudar para Static antes de desalocar
az network public-ip update \
  --resource-group "rg-producao" \
  --name "pip-vm-web-01" \
  --allocation-method Static

# Passo 2: Desalocar
az vm deallocate \
  --resource-group "rg-producao" \
  --name "vm-web-01"

# Passo 3: Redimensionar
az vm resize \
  --resource-group "rg-producao" \
  --name "vm-web-01" \
  --size "Standard_E4s_v5"

# Passo 4: Iniciar
az vm start \
  --resource-group "rg-producao" \
  --name "vm-web-01"

# Verificar o novo tamanho
az vm show \
  --resource-group "rg-producao" \
  --name "vm-web-01" \
  --query "hardwareProfile.vmSize" \
  --output tsv

# Script: Resize em lote de múltiplas VMs
for vm in vm-web-01 vm-web-02 vm-web-03; do
  echo "Redimensionando $vm para Standard_D4s_v5..."
  
  az vm deallocate \
    --resource-group "rg-producao" \
    --name "$vm"
  
  az vm resize \
    --resource-group "rg-producao" \
    --name "$vm" \
    --size "Standard_D4s_v5"
  
  az vm start \
    --resource-group "rg-producao" \
    --name "$vm"
  
  echo "$vm redimensionada com sucesso."
done

# Verificar uso de CPU para determinar se resize é necessário
# (via Azure Monitor)
az monitor metrics list \
  --resource "/subscriptions/<sub-id>/resourceGroups/rg-producao/providers/Microsoft.Compute/virtualMachines/vm-web-01" \
  --metric "Percentage CPU" \
  --interval PT1H \
  --start-time "$(date -u -d '24 hours ago' +%Y-%m-%dT%H:%M:%SZ)" \
  --end-time "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
  --aggregation Average \
  --output table

Azure PowerShell

# Listar SKUs disponíveis em uma região
Get-AzVMSize -Location "brazilsouth" |
  Sort-Object Name |
  Format-Table Name, NumberOfCores, MemoryInMB, MaxDataDiskCount

# Filtrar SKUs da família D
Get-AzVMSize -Location "brazilsouth" |
  Where-Object { $_.Name -like "Standard_D*" } |
  Format-Table Name, NumberOfCores, MemoryInMB

# Ver SKUs disponíveis para uma VM específica
Get-AzVMSize `
  -ResourceGroupName "rg-producao" `
  -VMName "vm-web-01" |
  Format-Table Name, NumberOfCores, MemoryInMB

# Ver SKU atual
(Get-AzVM -ResourceGroupName "rg-producao" -Name "vm-web-01").HardwareProfile.VmSize

# Resize sem desalocação (mesma família)
$vm = Get-AzVM -ResourceGroupName "rg-producao" -Name "vm-web-01"
$vm.HardwareProfile.VmSize = "Standard_D4s_v5"
Update-AzVM -ResourceGroupName "rg-producao" -VM $vm

# Resize com desalocação (família diferente)
# Passo 1: Desalocar
Stop-AzVM -ResourceGroupName "rg-producao" -Name "vm-web-01" -Force

# Passo 2: Mudar o tamanho
$vm = Get-AzVM -ResourceGroupName "rg-producao" -Name "vm-web-01"
$vm.HardwareProfile.VmSize = "Standard_E4s_v5"
Update-AzVM -ResourceGroupName "rg-producao" -VM $vm

# Passo 3: Iniciar
Start-AzVM -ResourceGroupName "rg-producao" -Name "vm-web-01"

# Relatório: listar todas as VMs e seus tamanhos em um RG
Get-AzVM -ResourceGroupName "rg-producao" |
  Select-Object Name, @{N="Size"; E={$_.HardwareProfile.VmSize}}, Location |
  Format-Table

# Script: Automatizar resize baseado em CPU média
$resourceGroup = "rg-producao"
$vmName = "vm-web-01"
$threshold = 80  # % CPU para trigger de scale up
$newSize = "Standard_D8s_v5"

$metric = Get-AzMetric `
  -ResourceId (Get-AzVM -ResourceGroupName $resourceGroup -Name $vmName).Id `
  -MetricName "Percentage CPU" `
  -StartTime (Get-Date).AddHours(-4) `
  -EndTime (Get-Date) `
  -TimeGrainInMinutes 60 `
  -AggregationType Average

$avgCpu = ($metric.Data | Measure-Object -Property Average -Average).Average

if ($avgCpu -gt $threshold) {
  Write-Output "CPU media: $avgCpu%. Acima de $threshold%. Iniciando resize para $newSize..."
  Stop-AzVM -ResourceGroupName $resourceGroup -Name $vmName -Force
  $vm = Get-AzVM -ResourceGroupName $resourceGroup -Name $vmName
  $vm.HardwareProfile.VmSize = $newSize
  Update-AzVM -ResourceGroupName $resourceGroup -VM $vm
  Start-AzVM -ResourceGroupName $resourceGroup -Name $vmName
  Write-Output "Resize concluido."
} else {
  Write-Output "CPU media: $avgCpu%. Dentro do limite. Resize nao necessario."
}

Bicep

// Definir VM Size como parâmetro para flexibilidade
@description('VM Size SKU')
@allowed([
  'Standard_B2s'
  'Standard_D2s_v5'
  'Standard_D4s_v5'
  'Standard_D8s_v5'
  'Standard_E4s_v5'
])
param vmSize string = 'Standard_D4s_v5'

resource vm 'Microsoft.Compute/virtualMachines@2023-03-01' = {
  name: 'vm-web-01'
  location: 'brazilsouth'
  properties: {
    hardwareProfile: {
      vmSize: vmSize  // SKU como parâmetro, não hardcoded
    }
    // ... resto das configurações
  }
}

7. Controle e Segurança

Azure Policy para limitar SKUs permitidos

Para evitar uso de SKUs muito caros ou SKUs inadequados para um ambiente:

# Built-in policy: "Allowed virtual machine size SKUs"
# Policy ID: cccc23c7-8427-4f53-ad12-b6a63eb452b3

az policy assignment create \
  --name "allowed-vm-sizes" \
  --display-name "Apenas SKUs aprovados para producao" \
  --policy "cccc23c7-8427-4f53-ad12-b6a63eb452b3" \
  --scope "/subscriptions/<sub-id>/resourceGroups/rg-producao" \
  --params '{
    "listOfAllowedSKUs": {
      "value": [
        "Standard_D2s_v5",
        "Standard_D4s_v5",
        "Standard_D8s_v5",
        "Standard_E4s_v5",
        "Standard_E8s_v5"
      ]
    }
  }'

Isso garante que nenhuma VM pode ser criada ou redimensionada para um SKU fora da lista aprovada, evitando uso acidental de SKUs caros.

Quotas de vCPU por subscription

Cada subscription tem limites de vCPU por família de VM e por região. Antes de planejar resize que aumenta vCPUs significativamente, verifique e solicite aumento:

# Ver quota atual de vCPU por família em uma região
az vm list-usage \
  --location "brazilsouth" \
  --query "[?contains(name.value, 'cores')].{Name: name.localizedValue, Current: currentValue, Limit: limit}" \
  --output table

# Ver quota para família específica
az vm list-usage \
  --location "brazilsouth" \
  --query "[?name.value=='standardDSv5Family'].{Name: name.localizedValue, Current: currentValue, Limit: limit}" \
  --output table

8. Tomada de Decisão

Escolha de família por tipo de workload

Workload	Família recomendada	Motivo
Web server, API REST	D-series (D2s-D8s v5)	CPU:RAM 1:4 equilibrado, Premium SSD
Banco de dados SQL Server	E-series ou M-series	Alta memória para buffer pool
Redis, Memcached, cache em memória	E-series	Alta RAM para dados em memória
Machine Learning training	N-series (NC, ND)	GPU necessária para aceleração
Machine Learning inference	N-series ou F-series	GPU ou alta CPU por consulta
Servidor de aplicação Java/JVM	E-series	JVM se beneficia de muita RAM
Build server CI/CD	F-series ou B-series	Alta CPU ou burstable
Dev/test com uso esporádico	B-series	Custo baixo, CPU burstable
SAP HANA	M-series (Mv2)	Até TBs de RAM
Servidor de arquivo NFS	L-series ou D-series	Alta I/O local ou rede

Quando fazer resize vs. adicionar mais VMs (scale up vs. scale out)

Situação	Abordagem	Motivo
Aplicação single-threaded com CPU alta	Scale up (VM maior)	Aplicação não paralleliza
Web app stateless com muitas requisições	Scale out (mais VMs + LB)	Distribuição de carga mais eficiente
Banco de dados com memória insuficiente	Scale up (mais RAM)	BD é stateful, difícil de distribuir
Processamento batch sem prazo crítico	Scale out com Spot VMs	Custo minimizado
VM de desenvolvimento com picos de build	Manter B-series	Burstable cobre os picos
Aplicação em VM B-series com CPU alta contínua	Scale up para D-series	B-series sem créditos é ineficiente

9. Boas Práticas

Sempre verifique os SKUs disponíveis antes de planejar um resize. O comando az vm list-vm-resize-options mostra apenas os SKUs que estão disponíveis para aquela VM específica naquele momento. SKUs disponíveis variam por região, Availability Set e capacidade atual do cluster.

Use IP Público Estático para VMs que serão frequentemente desalocadas. IPs dinâmicos mudam a cada deallocate/start. Para VMs que passam por resize frequente ou que são desligadas à noite, configure IP estático para manter o endereço consistente.

Monitore CPU e memória por pelo menos 2 semanas antes de fazer resize. Uma semana pode não capturar padrões semanais (segunda-feira com mais carga, finais de semana mais tranquilos). Use Azure Monitor para obter dados históricos suficientes antes de decisões de sizing.

Para VMs de produção, planeje janelas de manutenção para resizes que requerem desalocação. Comunique o downtime com antecedência. Um resize de família diferente leva apenas alguns minutos, mas esses minutos precisam estar planejados.

Use tags para rastrear o sizing justificado. Tags como LastResizeDate, ResizeReason, OriginalSize ajudam a auditar decisões de sizing ao longo do tempo. Sem rastreamento, em 6 meses ninguém sabe por que uma VM foi aumentada de tamanho.

Considere Reserved Instances após o sizing estar estabilizado. Comprar uma Reserved Instance (RI) do tamanho errado é um desperdício. Espere o sizing se estabilizar por 2-3 meses antes de comprar reservas. A economia pode chegar a 72% em relação ao Pay-As-You-Go para o mesmo SKU com compromisso de 3 anos.

Para ambientes de dev/test, use Azure Dev/Test subscriptions e B-series. Dev/test subscription tem preços reduzidos e B-series têm baixo custo base. Uma VM B2s para desenvolvimento pode custar 60-70% menos que uma D2s_v5 equivalente em uma subscription de produção.

10. Erros Comuns

Erro	Por que acontece	Como evitar
Resize falha por falta de capacidade no cluster	SKU desejado sem hardware disponível no cluster atual	Desalocar VM primeiro; a realocação em novo host tem mais opções
IP público muda após resize que requereu desalocação	IP dinâmico liberado na desalocação	Mudar para IP estático antes de desalocar
Disco temporário de dados perdidos após resize	Disco temporário é efêmero, resetado em qualquer operação de host	Nunca armazenar dados persistentes em disco temporário
VMs B-series com CPU 100% constante e sem créditos	Entender burstable como uso contínuo	B-series é para workloads com baixo uso médio; mudar para D-series se uso é contínuo
Escolher SKU sem sufixo `s` e não conseguir usar Premium SSD	Não entender a nomenclatura	Sempre verificar que o SKU tem `s` se Premium Storage for necessário
Resize de VM em Availability Set falhando	AS limita SKUs ao cluster físico	Verificar `list-vm-resize-options` para ver SKUs disponíveis
Quota de vCPU esgotada ao tentar scale up	Não verificar quota antes de planejar resize	Monitorar quota com alertas em 70% e solicitar aumento preventivamente
Accelerated Networking desabilitado após downsize	SKU menor não suporta a funcionalidade	Verificar compatibilidade de features antes de downsizing

O erro mais custoso

Escolher um SKU de produção sem pesquisar as opções e permanecer nele por anos sem revisão. Uma VM criada há 3 anos na série D_v3 pode ser migrada para D_v5 da mesma família com mais performance pelo mesmo preço ou menos. A Microsoft lança novas gerações regularmente com melhor custo-benefício. Uma revisão anual de sizing pode gerar economias significativas.

11. Operação e Manutenção

Inventário e análise de sizing de todas as VMs

# Listar todas as VMs com SKU atual
az vm list \
  --query "[].{Name: name, RG: resourceGroup, Size: hardwareProfile.vmSize, Location: location}" \
  --output table

# Via Resource Graph: todas as VMs e seus SKUs em toda a organização
az graph query -q "
Resources
| where type == 'microsoft.compute/virtualmachines'
| project name, resourceGroup, location, subscriptionId, vmSize=properties.hardwareProfile.vmSize
| order by vmSize"

# Identificar VMs com SKUs de gerações antigas para upgrade
az graph query -q "
Resources
| where type == 'microsoft.compute/virtualmachines'
| where properties.hardwareProfile.vmSize contains '_v3'
      or properties.hardwareProfile.vmSize contains '_v2'
| project name, resourceGroup, vmSize=properties.hardwareProfile.vmSize"

Monitorar métricas para decisões de resize

# CPU média das últimas 24 horas
az monitor metrics list \
  --resource "/subscriptions/<sub-id>/resourceGroups/rg-producao/providers/Microsoft.Compute/virtualMachines/vm-web-01" \
  --metric "Percentage CPU" \
  --interval PT1H \
  --aggregation Average \
  --start-time "$(date -u -d '24 hours ago' +%Y-%m-%dT%H:%M:%SZ)" \
  --end-time "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
  --output table

# Memória disponível (para decisões de resize de memória)
az monitor metrics list \
  --resource "/subscriptions/<sub-id>/resourceGroups/rg-producao/providers/Microsoft.Compute/virtualMachines/vm-web-01" \
  --metric "Available Memory Bytes" \
  --interval PT1H \
  --aggregation Average \
  --start-time "$(date -u -d '7 days ago' +%Y-%m-%dT%H:%M:%SZ)" \
  --end-time "$(date -u +%Y-%m-%dT%H:%M:%SZ)" \
  --output table

Azure Advisor para recomendações de sizing

O Azure Advisor analisa o uso de CPU e memória das VMs e gera recomendações automáticas de resize quando detecta superprovisionamento:

# Ver recomendações de Cost do Advisor (inclui resize de VMs)
az advisor recommendation list \
  --category Cost \
  --query "[?contains(shortDescription.problem, 'virtual machine') || contains(shortDescription.problem, 'VM')].{
    VM: resourceMetadata.resourceId,
    Problema: shortDescription.problem,
    Solucao: shortDescription.solution,
    EconomiaAnual: extendedProperties.annualSavingsAmount
  }" \
  --output table

12. Integração e Automação

Auto-sizing com Azure Automation e Azure Monitor

Para ambientes onde o sizing precisa ser ajustado automaticamente baseado em métricas históricas:

100%

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

Terraform com sizing paramétrico por ambiente

variable "environment" {
  type    = string
  default = "dev"
}

locals {
  vm_sizes = {
    dev     = "Standard_B2s"
    staging = "Standard_D2s_v5"
    prod    = "Standard_D4s_v5"
  }
  
  vm_size = local.vm_sizes[var.environment]
}

resource "azurerm_linux_virtual_machine" "main" {
  name                = "vm-app-${var.environment}"
  resource_group_name = azurerm_resource_group.main.name
  location            = azurerm_resource_group.main.location
  size                = local.vm_size  # B2s em dev, D4s_v5 em prod
  
  # ... resto das configurações
}

13. Resumo Final

Pontos essenciais:

VM Size define a quantidade de vCPU, memória, disco temporário e capacidades de rede de uma VM
A nomenclatura segue o padrão Standard_[Familia][vCPUs][subfamilia][features]_v[N]; o sufixo s indica suporte a Premium Storage
Principais famílias: B (burstable), D (uso geral), E (memory optimized), F (compute optimized), N (GPU), L (storage optimized), M (memória extrema)
Resize dentro da mesma família pode ser feito sem desalocação (com possível reboot breve); resize para outra família requer desalocação
Desalocação libera IPs públicos dinâmicos; usar IP estático para evitar mudança de endereço

Diferenças críticas:

Stop vs. Deallocate: Stop mantém a VM no host físico (não altera SKU, cobra pela VM); Deallocate libera o host (permite mudança de SKU, não cobra pela VM parada)
Resize vs. Scale out: Resize aumenta recursos de uma VM (vertical scaling); Scale out adiciona mais VMs (horizontal scaling)
Serie B vs. Serie D: B-series é burstable (CPU variável com créditos, menor custo base); D-series tem CPU dedicada (performance consistente)
SKU com s vs. sem s: com s suporta Premium SSD e caching de disco; sem s limita a Standard SSD/HDD

O que precisa ser lembrado para o AZ-104:

O comando CLI para listar opções de resize para uma VM específica é: az vm list-vm-resize-options
O comando para redimensionar é: az vm resize --size <new-size>
Para resize que requer desalocação: az vm deallocate + az vm resize + az vm start
A built-in policy para restringir SKUs é: "Allowed virtual machine size SKUs" (ID: cccc23c7-8427-4f53-ad12-b6a63eb452b3)
SKUs disponíveis variam por região; o que existe em East US pode não existir em brazilsouth
VMs em Availability Sets têm SKUs limitados ao cluster físico do AS
O disco temporário tem seu tamanho determinado pelo SKU e perde dados em toda desalocação ou resize

1. Intuição Inicial​

2. Contexto​

Por que VM Sizes existem como conceito formal​

O que depende da escolha correta de VM Size​

3. Construção dos Conceitos​

3.1 A nomenclatura dos VM Sizes​

3.2 Letras de subfamília e features​

3.3 Famílias de VM por tipo de workload​

3.4 A série B: Burstable VMs​

3.5 Redimensionamento: como e quando acontece​

4. Visão Estrutural​

Hierarquia de decisão para escolha de VM Size​

Comparação de SKUs da família D (uso geral) mais comuns​

5. Funcionamento na Prática​

Processo de resize de uma VM​

Comportamentos não óbvios importantes​

6. Formas de Implementação​

Portal do Azure​

Azure CLI​

Azure PowerShell​

Bicep​

7. Controle e Segurança​

Azure Policy para limitar SKUs permitidos​

Quotas de vCPU por subscription​

8. Tomada de Decisão​

Escolha de família por tipo de workload​

Quando fazer resize vs. adicionar mais VMs (scale up vs. scale out)​

9. Boas Práticas​

10. Erros Comuns​

O erro mais custoso​

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

Inventário e análise de sizing de todas as VMs​

Monitorar métricas para decisões de resize​

Azure Advisor para recomendações de sizing​

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

Auto-sizing com Azure Automation e Azure Monitor​

Terraform com sizing paramétrico por ambiente​

13. Resumo Final​

1. Intuição Inicial

2. Contexto

Por que VM Sizes existem como conceito formal

O que depende da escolha correta de VM Size

3. Construção dos Conceitos

3.1 A nomenclatura dos VM Sizes

3.2 Letras de subfamília e features

3.3 Famílias de VM por tipo de workload

3.4 A série B: Burstable VMs

3.5 Redimensionamento: como e quando acontece

4. Visão Estrutural

Hierarquia de decisão para escolha de VM Size

Comparação de SKUs da família D (uso geral) mais comuns

5. Funcionamento na Prática

Processo de resize de uma VM

Comportamentos não óbvios importantes

6. Formas de Implementação

Portal do Azure

Azure CLI

Azure PowerShell

Bicep

7. Controle e Segurança

Azure Policy para limitar SKUs permitidos

Quotas de vCPU por subscription

8. Tomada de Decisão

Escolha de família por tipo de workload

Quando fazer resize vs. adicionar mais VMs (scale up vs. scale out)

9. Boas Práticas

10. Erros Comuns

O erro mais custoso

11. Operação e Manutenção

Inventário e análise de sizing de todas as VMs

Monitorar métricas para decisões de resize

Azure Advisor para recomendações de sizing

12. Integração e Automação

Auto-sizing com Azure Automation e Azure Monitor

Terraform com sizing paramétrico por ambiente

13. Resumo Final