Ciclo de Vida de uma VM no Azure: Parar, Desalocar, Redimensionar e Controlar Custos

Leave a Comment / Azure / By

Uma máquina virtual no Azure atravessa vários estados desde a sua criação até à eliminação. Pode estar em aprovisionamento, execução, paragem, desalocação ou redimensionamento, e cada transição afeta de forma diferente a disponibilidade, a capacidade reservada e os custos. Compreender este ciclo de vida permite executar operações de manutenção com segurança, evitar faturação desnecessária e antecipar impactos em discos temporários, endereços IP e capacidade de computação.

Introdução

Desligar uma VM no azure pode significar duas operações tecnicamente diferentes:

  • Desligar o sistema operativo, mantendo a capacidade de computação reservada;
  • Desligar e desalocar a VM, libertando essa capacidade.

A primeira opção continua normalmente a gerar custos de computação. A segunda interrompe a faturação da instância de computação, mas não elimina todos os custos associados à VM. O redimensionamento acrescenta outra dimensão ao problema. Alterar o tamanho de uma VM pode provocar um reinício, exigir desalocação, remover os dados do disco temporário, alterar endereços IP dinâmicos ou falhar devido à indisponibilidade de capacidade física.

A operação correta depende, por isso, de quatro perguntas:

  1. Que estado de energia se pretende atingir?
  2. É necessário preservar a alocação da VM no anfitrião?
  3. Que componentes continuarão a ser faturados?
  4. Que interrupções e riscos são aceitáveis para o serviço?

Uma gestão eficaz do ciclo de vida exige compreender tanto o estado técnico da VM como o modelo de custos dos recursos que a suportam.

Pré-Requisitos

Para executar os exemplos deste artigo são necessários:

  • uma subscrição Azure ativa;
  • uma máquina virtual existente;
  • permissões para consultar e alterar a VM;
  • Azure Cloud Shell, Azure CLI ou Azure PowerShell;
  • conhecimento do grupo de recursos, nome da VM e subscrição;
  • uma janela de manutenção para operações disruptivas;
  • acesso ao Azure Monitor e ao Cost Management, quando for necessário analisar desempenho ou custos.

A função integrada Virtual Machine Contributor permite gerir máquinas virtuais, mas não concede automaticamente acesso administrativo ao sistema operativo nem permissões gerais sobre a rede virtual.

Instalar a Azure CLI no Windows

Uma forma suportada de instalar a Azure CLI através do Windows Package Manager é:

PowerShell
winget install --exact --id Microsoft.AzureCLI

Depois da instalação, deve abrir-se uma nova sessão de terminal e autenticar a conta:

PowerShell
az login
az account set --subscription "<ID-DA-SUBSCRICAO>"
az account show --output table

Em ambientes sem interface gráfica, pode utilizar-se a autenticação por código de dispositivo:

PowerShell
az login --use-device-code

Para consultar a versão instalada:

PowerShell
az version

Instalar o módulo Az do PowerShell

PowerShell
Install-Module `
  -Name Az `
  -Repository PSGallery `
  -Scope CurrentUser `
  -Force

Import-Module Az
Connect-AzAccount
Set-AzContext -SubscriptionId "<ID-DA-SUBSCRICAO>"

Para confirmar o contexto ativo:

PowerShell
Get-AzContext

Em automações de produção, deve utilizar-se uma identidade gerida, uma identidade de workload ou outro mecanismo não interativo. Não se devem guardar palavras-passe ou segredos diretamente em scripts.

Conceitos essenciais do ciclo de vida

Uma VM do Azure tem diferentes tipos de estado. Os dois mais relevantes para a operação diária são:

  • Estado de aprovisionamento;
  • Estado de energia.

Estes estados são independentes e não devem ser confundidos.

Estado de Aprovisionamento

O estado de aprovisionamento descreve o resultado da última operação realizada sobre o recurso no plano de controlo do Azure.

Os estados mais comuns são:

Uma VM pode apresentar simultaneamente:

ProvisioningState/succeeded
PowerState/deallocated

Isto significa que a configuração da VM foi aplicada com sucesso, mas a instância não está alocada num anfitrião físico. O estado Succeeded não significa, portanto, que o sistema operativo esteja em execução.

Estado de Energia

O estado de energia representa o último estado conhecido da instância do ponto de vista do hipervisor.

Outros recursos, como discos, endereços IP e serviços de rede, podem continuar a gerar custos.

A distinção fundamental é:

Stopped               = desligada, mas ainda alocada e faturada
Stopped (Deallocated) = desligada, desalocada e sem faturação da instância

Parar, Desalocar, Reiniciar e Eliminar

Embora estas operações sejam frequentemente tratadas como equivalentes, têm efeitos diferentes.

Parar sem Desalocar

Quando o sistema operativo é encerrado internamente — por exemplo, através de shutdown, poweroff ou da opção Shut down do Windows — o Azure pode manter a VM no estado Stopped.

O mesmo acontece ao executar:

PowerShell
az vm stop `
  --resource-group "rg-producao-weu" `
  --name "vm-api-01"

Neste estado:

  • O sistema operativo deixa de estar em execução;
  • A capacidade de CPU e memória continua reservada;
  • A VM permanece alocada num anfitrião;
  • A computação continua a ser faturada.

Esta operação pode ser adequada quando existe uma necessidade específica de manter a VM aprovisionada. Não deve, contudo, ser utilizada como medida de redução de custos.

Parar e Desalocar

Para desligar a VM e libertar a capacidade de computação:

PowerShell
az vm deallocate `
  --resource-group "rg-producao-weu" `
  --name "vm-api-01"

Com Azure PowerShell:

PowerShell
Stop-AzVM `
  -ResourceGroupName "rg-producao-weu" `
  -Name "vm-api-01" `
  -Force

Por omissão, Stop-AzVM para e desaloca a VM. Para a manter aprovisionada, existe o parâmetro -StayProvisioned:

PowerShell
Stop-AzVM `
  -ResourceGroupName "rg-producao-weu" `
  -Name "vm-api-01" `
  -StayProvisioned `
  -Force

Neste último caso, a VM permanece num estado faturável.
No portal do Azure, a opção Stop apresentada na página da VM normalmente para e desaloca a instância. Ainda assim, deve confirmar-se sempre que o estado final é Stopped (deallocated).

Reiniciar

O reinício mantém a VM como recurso ativo e provoca o reinício do sistema operativo:

PowerShell
az vm restart `
  --resource-group "rg-producao-weu" `
  --name "vm-api-01"

Com Azure PowerShell:

PowerShell
Restart-AzVM `
  -ResourceGroupName "rg-producao-weu" `
  -Name "vm-api-01"

Um reinício não é uma estratégia de redução de custos. A VM continua a ser faturada durante a operação.

Eliminar

Eliminar uma VM remove o recurso de computação:

PowerShell
az vm delete `
  --resource-group "rg-producao-weu" `
  --name "vm-api-01" `
  --yes

Eliminar não é o mesmo que desalocar. Dependendo da configuração, alguns recursos associados podem permanecer:

  • Discos do sistema operativo;
  • Discos de dados;
  • Interfaces de rede;
  • Endereços IP públicos;
  • Snapshots;
  • Recursos de backup;
  • Balanceadores.

Esses recursos podem continuar a gerar custos até serem explicitamente eliminados.

Consequências da Desalocação

A desalocação tem efeitos financeiros e operacionais.

Efeitos Esperados

Quando uma VM é desalocada:

  • A faturação da instância de computação em consumo é interrompida;
  • A capacidade física ocupada pela VM é libertada;
  • Os discos geridos são preservados;
  • A configuração da VM permanece no plano de controlo;
  • A VM pode ser iniciada novamente mais tarde.

Endereços IP Dinâmicos

A desalocação pode libertar endereços IP dinâmicos. No arranque seguinte, a VM pode receber outro endereço. Se o serviço depender de um endereço público estável, deve utilizar-se:

  • Um IP público estático suportado;
  • Um nome DNS;
  • Um balanceador;
  • Uma arquitetura que não dependa diretamente do endereço da VM.

O custo e as regras dos endereços IP públicos dependem do SKU e da configuração. Devem ser confirmados na documentação e na página de preços atual.

Disco Temporário

Alguns tamanhos de VM incluem um disco temporário local. Este disco:

  • Está ligado ao anfitrião físico;
  • Não é armazenamento persistente;
  • Pode ser perdido durante a desalocação;
  • Pode ser perdido durante manutenção ou redimensionamento;
  • Não deve armazenar dados indispensáveis.

Dados persistentes devem ser guardados em:

  • Discos geridos;
  • Azure Files;
  • Blob Storage;
  • Bases de dados;
  • Outro serviço de armazenamento durável.

Disponibilidade de Capacidade no Arranque

Depois da desalocação, o Azure terá de encontrar capacidade compatível para iniciar novamente a VM.

O arranque pode falhar se:

  • Não existir capacidade para o SKU;
  • A zona estiver temporariamente limitada;
  • A quota de vCPUs tiver sido atingida;
  • Existirem restrições de policy;
  • O SKU tiver deixado de estar disponível para novas alocações.

A desalocação não garante que a VM possa voltar a ser iniciada imediatamente no mesmo tipo de hardware. Para workloads que exigem garantia de capacidade, pode ser necessário considerar uma On-demand Capacity Reservation. Este recurso tem um modelo de custos próprio e pode ser faturado mesmo quando a capacidade reservada não está a ser utilizada.

Consultar Corretamente os Estados

Não se deve determinar o estado de uma VM apenas através de RDP, SSH, ICMP ou testes à aplicação. A confirmação deve ser realizada através do plano de controlo do Azure.

Consultar uma VM com Azure CLI

PowerShell
$resourceGroup = "rg-producao-weu"
$vmName = "vm-api-01"

az vm get-instance-view `
  --resource-group $resourceGroup `
  --name $vmName `
  --query "instanceView.statuses[?starts_with(code, 'PowerState/')].[code,displayStatus]" `
  --output table

Uma alternativa resumida é:

PowerShell
az vm show `
  --resource-group $resourceGroup `
  --name $vmName `
  --show-details `
  --query "{name:name,size:hardwareProfile.vmSize,powerState:powerState}" `
  --output table

Para consultar apenas o estado de energia:

PowerShell
az vm show `
  --resource-group $resourceGroup `
  --name $vmName `
  --show-details `
  --query "powerState" `
  --output tsv

Consultar com Azure PowerShell

PowerShell
$resourceGroup = "rg-producao-weu"
$vmName = "vm-api-01"

Get-AzVM `
  -ResourceGroupName $resourceGroup `
  -Name $vmName `
  -Status |
Select-Object -ExpandProperty Statuses |
Where-Object Code -Like "PowerState/*" |
Select-Object Code, DisplayStatus

Consultar todas as VMs de uma Subscrição

PowerShell
az vm list `
  --show-details `
  --query "[].{name:name,resourceGroup:resourceGroup,size:hardwareProfile.vmSize,state:powerState}" `
  --output table

Esta consulta é útil para identificar VMs em Stopped que ainda podem estar a gerar custos de computação.

Custos que Permanecem depois da Desalocação

Uma VM não é apenas uma instância de computação. É uma composição de vários recursos com medidores de faturação independentes.

Discos Geridos

Os discos geridos continuam provisionados quando a VM é desalocada.

O custo depende de fatores como:

  • Tipo do disco;
  • Capacidade provisionada;
  • Nível de desempenho;
  • Redundância;
  • Transações, quando aplicável;
  • Funcionalidades adicionais.

Um disco Premium SSD provisionado continua normalmente a gerar custos mesmo que não receba operações de leitura ou escrita.

Desalocar a VM não reduz automaticamente:

  • O tamanho do disco;
  • O SKU do disco;
  • A capacidade provisionada;
  • O período de retenção dos snapshots.

Endereços IP Públicos

O endereço IP público é um recurso separado da VM. Pode continuar a ser faturado mesmo quando a VM está desalocada. Se o endereço não for necessário durante um período prolongado, poderá ser possível:

  1. Remover a associação à interface de rede;
  2. Eliminar o recurso de IP público;
  3. Criar um novo endereço quando necessário.

Esta decisão pode alterar o endereço utilizado pelo serviço e exigir atualizações em DNS, listas de acesso e firewalls.

Backups e Snapshots

Os backups e snapshots preservam dados independentemente do estado da VM. Por isso, continuam a consumir armazenamento.

Antes de eliminar uma VM, deve verificar-se:

  • Se existe proteção no Recovery Services vault;
  • Se a retenção continua ativa;
  • Se existem snapshots manuais;
  • Se os discos permanecem ligados ou órfãos;
  • Se a eliminação de dados respeita os requisitos de retenção.

Reservations e Savings Plans

A afirmação “uma VM desalocada não paga computação” refere-se ao medidor de utilização da instância. Não cancela compromissos comerciais previamente adquiridos.

Numa reservation:

  • Existe um compromisso de um ou três anos;
  • O desconto é aplicado automaticamente a utilização elegível;
  • Se a VM for desalocada, o desconto poderá ser aplicado a outra VM compatível;
  • Se não houver outra utilização elegível, a capacidade financeira pode ficar subutilizada.

Num Savings Plans for Compute:

  • Existe um compromisso monetário por hora;
  • O benefício é aplicado a utilização elegível;
  • Desalocar a VM não elimina o compromisso horário.

Assim, desalocar reduz o consumo técnico, mas não recupera automaticamente o valor de um compromisso já contratado.

Procedimento Seguro para Desalocar e Iniciar uma VM

A operação deve considerar a aplicação, não apenas a infraestrutura.

Passo 1: confirmar o contexto

PowerShell
$subscriptionId = "<ID-DA-SUBSCRICAO>"
$resourceGroup = "rg-producao-weu"
$vmName = "vm-api-01"

az account set --subscription $subscriptionId

az vm show `
  --resource-group $resourceGroup `
  --name $vmName `
  --query "{name:name,location:location,size:hardwareProfile.vmSize}" `
  --output table

Passo 2: preparar a aplicação

Antes de parar a VM:

  • Retirar a instância do balanceador;
  • Impedir a entrada de novos pedidos;
  • Concluir ou transferir trabalhos em curso;
  • Descarregar buffers para armazenamento persistente;
  • Parar aplicações e bases de dados de forma controlada;
  • Confirmar que não existem dados importantes no disco temporário;
  • Validar os backups quando a criticidade o justificar.

Passo 3: desalocar

PowerShell
az vm deallocate `
  --resource-group $resourceGroup `
  --name $vmName

Sem --no-wait, o comando aguarda normalmente a conclusão da operação.

Passo 4: confirmar o estado final

PowerShell
az vm get-instance-view `
  --resource-group $resourceGroup `
  --name $vmName `
  --query "instanceView.statuses[?starts_with(code, 'PowerState/')].displayStatus | [0]" `
  --output tsv

O resultado esperado é equivalente a:

VM deallocated

Passo 5: iniciar novamente

PowerShell
az vm start `
  --resource-group $resourceGroup `
  --name $vmName

Passo 6: validar a infraestrutura

PowerShell
az vm show `
  --resource-group $resourceGroup `
  --name $vmName `
  --show-details `
  --query "{powerState:powerState,privateIps:privateIps,publicIps:publicIps}" `
  --output table

Passo 7: validar a aplicação

Depois do arranque, devem verificar-se:

  • Estado dos serviços;
  • Montagem dos discos;
  • Conectividade;
  • DNS;
  • Health probes;
  • Logs;
  • Métricas;
  • Processamento de pedidos;
  • Tarefas agendadas;
  • Replicação e consistência dos dados.

Uma VM em Running não significa necessariamente que a aplicação esteja operacional.

Redimensionar uma VM

Redimensionar uma VM significa alterar o respetivo SKU, também designado por tamanho.

O tamanho determina, entre outros elementos:

  • Número de vCPUs;
  • Quantidade de memória;
  • Desempenho da rede;
  • Suporte para Premium Storage;
  • Número máximo de discos;
  • IOPS e débito máximos;
  • Número máximo de interfaces de rede;
  • Existência de disco temporário;
  • Preço da instância.

O redimensionamento vertical pode assumir duas formas:

  • Scale up: aumetar a capacidade;
  • Scale down: reduzir a capacidade e potencialmente o custo.

O Redimensionamento é Disruptivo

Alterar o tamanho de uma VM deve ser considerado uma operação disruptiva:

  • Se a VM estiver em execução, será reiniciada;
  • Se o tamanho não estiver disponível no cluster atual, será necessário desalocar;
  • A desalocação pode libertar IPs dinâmicos;
  • O disco temporário pode perder os dados;
  • O novo SKU pode não ter capacidade disponível;
  • Limites de discos e interfaces podem impedir a alteração.

Escolher o Tamanho com Base em Métricas

Antes de redimensionar, devem analisar-se:

  • Percentis de utilização de CPU;
  • Memória utilizada;
  • Paginação;
  • IOPS;
  • Débito e latência dos discos;
  • Desempenho da rede;
  • Número de discos ligados;
  • Créditos acumulados e consumidos nas VMs da série B;
  • Sazonalidade;
  • Picos de carga;
  • Requisitos de licenciamento.

A média de CPU, isoladamente, não é suficiente. Uma VM pode apresentar CPU baixa e estar limitada pela memória, rede ou armazenamento.

Recomendação: recolher métricas durante um período representativo do ciclo normal de negócio antes de reduzir a capacidade.

Redimensionamento completo com Azure CLI

O exemplo seguinte utiliza PowerShell para executar comandos da Azure CLI. O script confirma o tamanho atual, verifica as opções disponíveis, desaloca a VM, altera o tamanho e volta a iniciá-la.

PowerShell
$ErrorActionPreference = "Stop"

$subscriptionId = "<ID-DA-SUBSCRICAO>"
$resourceGroup = "rg-producao-weu"
$vmName = "vm-api-01"
$newSize = "Standard_D4s_v5"

az account set --subscription $subscriptionId

if ($LASTEXITCODE -ne 0) {
    throw "Não foi possível selecionar a subscrição."
}

$currentSize = az vm show `
    --resource-group $resourceGroup `
    --name $vmName `
    --query "hardwareProfile.vmSize" `
    --output tsv

if ($LASTEXITCODE -ne 0) {
    throw "Não foi possível consultar a VM."
}

Write-Host "Tamanho atual: $currentSize"
Write-Host "Tamanho pretendido: $newSize"

$availableSizes = @(
    az vm list-vm-resize-options `
        --resource-group $resourceGroup `
        --name $vmName `
        --query "[].name" `
        --output tsv
)

if ($LASTEXITCODE -ne 0) {
    throw "Não foi possível consultar os tamanhos disponíveis."
}

if ($availableSizes -notcontains $newSize) {
    throw "O tamanho $newSize não está disponível para esta VM."
}

az vm deallocate `
    --resource-group $resourceGroup `
    --name $vmName

if ($LASTEXITCODE -ne 0) {
    throw "A desalocação falhou."
}

az vm resize `
    --resource-group $resourceGroup `
    --name $vmName `
    --size $newSize

if ($LASTEXITCODE -ne 0) {
    throw "O redimensionamento falhou. A VM permanece desalocada."
}

az vm start `
    --resource-group $resourceGroup `
    --name $vmName

if ($LASTEXITCODE -ne 0) {
    throw "O tamanho foi alterado, mas o arranque falhou."
}

az vm show `
    --resource-group $resourceGroup `
    --name $vmName `
    --show-details `
    --query "{name:name,size:hardwareProfile.vmSize,state:powerState}" `
    --output table

A lista devolvida por az vm list-vm-resize-options não constitui uma garantia permanente de capacidade. A disponibilidade pode mudar entre a consulta e a alocação.

Redimensionar sem Desalocar Previamente

Se o tamanho pretendido estiver disponível no cluster atual:

PowerShell
az vm resize `
  --resource-group "rg-producao-weu" `
  --name "vm-api-01" `
  --size "Standard_D4s_v5"

A VM será reiniciada. Esta abordagem evita libertar previamente a alocação, mas continua a provocar indisponibilidade.

Impacto nos Custos

Depois de um redimensionamento bem-sucedido, a computação passa a ser faturada segundo o novo SKU quando a VM estiver num estado faturável. Os discos não são redimensionados automaticamente. Por exemplo, alterar uma VM de Standard_D8s_v5 para Standard_D4s_v5 pode reduzir o custo da instância, mas não altera o custo dos discos Premium existentes, e também deve confirmar-se se Reservations, Savings Plans e benefícios de licenciamento continuam a aplicar-se ao novo tamanho.

Redimensionamento com Azure PowerShell

PowerShell
$ErrorActionPreference = "Stop"

$resourceGroup = "rg-producao-weu"
$vmName = "vm-api-01"
$newSize = "Standard_D4s_v5"

$availableSizes = Get-AzVMSize `
    -ResourceGroupName $resourceGroup `
    -VMName $vmName |
    Select-Object -ExpandProperty Name

if ($availableSizes -notcontains $newSize) {
    throw "O tamanho $newSize não está disponível."
}

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

Get-AzVM `
    -ResourceGroupName $resourceGroup `
    -Name $vmName `
    -Status

Se a VM pertencer a um availability set e o tamanho pretendido não estiver disponível no cluster atual, pode ser necessário desalocar todas as VMs do conjunto. Esta operação deve ser planeada como uma manutenção do serviço, porque pode afetar simultaneamente várias instâncias.

Decisões Técnicas e Alternativas

Quando utilizar stop

Utilizar stop sem desalocar pode fazer sentido quando:

  • É necessário manter a alocação no anfitrião;
  • A paragem será muito curta;
  • Existe uma razão operacional específica para evitar a desalocação;
  • O custo adicional foi aceite.

Não é a opção recomendada para poupar custos.

Quando utilizar deallocate

A desalocação é adequada quando:

  • A VM ficará inativa durante um período relevante;
  • O objetivo é interromper o custo da instância;
  • A aplicação tolera um novo processo de alocação;
  • O IP dinâmico pode mudar;
  • Não existem dados persistentes no disco temporário.

Redimensionamento Vertical ou Horizontal

O redimensionamento vertical altera a capacidade de uma única VM. É simples, mas causa uma interrupção e mantém a dependência numa única instância.

O dimensionamento horizontal adiciona ou remove instâncias. É normalmente mais adequado para aplicações:

  • Sem estado;
  • Distribuídas;
  • Colocadas atrás de um balanceador;
  • Preparadas para escalabilidade automática;
  • Com requisitos elevados de disponibilidade.

Quando a aplicação suporta múltiplas instâncias, um Virtual Machine Scale Set pode ser preferível ao redimensionamento manual de uma única VM.

Desalocação ou Eliminação

Desalocar preserva a VM e os seus discos para utilização futura. Eliminar remove o recurso de computação e pode reduzir custos adicionais, desde que os recursos associados também sejam tratados.

Para ambientes temporários, Infrastructure as Code pode ser utilizada para:

  1. Guardar a configuração declarativa;
  2. Eliminar os recursos quando não são necessários;
  3. Recriar o ambiente de forma consistente.

Esta alternativa exige que o estado da aplicação esteja separado da infraestrutura descartável.

Erros comuns e respetivas soluções: “Desliguei a VM, mas continuo a pagar computação”

Causa provável: a VM ficou em Stopped, não em Deallocated.

Diagnóstico:

PowerShell
az vm show `
  --resource-group "rg-producao-weu" `
  --name "vm-api-01" `
  --show-details `
  --query "powerState" `
  --output tsv

Solução:

PowerShell
az vm deallocate `
  --resource-group "rg-producao-weu" `
  --name "vm-api-01"

“A VM está desalocada, mas ainda aparecem custos”

Causas possíveis:

  • discos geridos;
  • snapshots;
  • IP público;
  • backups;
  • Azure Monitor;
  • Bastion;
  • Load Balancer;
  • software do Marketplace;
  • Reservations;
  • Savings Plans;
  • Capacity Reservations.

Solução: analisar os custos por recurso e por medidor no Azure Cost Management. Não se deve assumir que todos os encargos pertencem à instância de computação.

“O endereço IP mudou depois do arranque”

Causa: a VM foi desalocada e utilizava um endereço dinâmico.

Solução: utilizar um IP público estático quando necessário e evitar dependências diretas através da utilização de DNS.

“Perdi ficheiros depois da desalocação ou do resize”

Causa provável: os ficheiros estavam no disco temporário local.
Solução: guardar dados persistentes em discos geridos ou noutro serviço de armazenamento durável.

“O tamanho pretendido não aparece”

Causas possíveis:

  • SKU indisponível na região ou zona;
  • ausência de capacidade no cluster atual;
  • quota insuficiente de vCPUs;
  • policy que limita os SKUs;
  • incompatibilidade com discos ou interfaces;
  • restrições de arquitetura de armazenamento;
  • limitações relacionadas com disco temporário ou NVMe.

Solução: confirmar quotas, restrições e compatibilidade antes de desalocar. Se necessário, escolher outro SKU, zona ou região.

“O resize falhou, mas o portal mostra o tamanho novo”

Segundo a documentação do Azure, uma falha de redimensionamento pode deixar o modelo da VM a apresentar o tamanho pedido, enquanto a instância continua temporariamente no tamanho anterior.

Devem ser verificados:

  • resultado da operação;
  • Activity Log;
  • estado da instância;
  • métricas;
  • tamanho efetivo depois de uma alocação bem-sucedida.

“A VM não volta a arrancar depois da desalocação”

Causa provável: falha de alocação por indisponibilidade de capacidade.
Alternativas:

  • tentar novamente mais tarde;
  • selecionar outro tamanho compatível;
  • utilizar outra zona ou região;
  • confirmar a quota;
  • recorrer a uma Capacity Reservation quando existir necessidade de garantia;
  • utilizar várias instâncias para evitar dependência numa única VM.

Segurança, Desempenho e Manutenção

Segurança

As operações sobre o ciclo de vida devem respeitar o princípio do menor privilégio:

  • limitar quem pode iniciar, parar, desalocar e redimensionar VMs;
  • utilizar Azure RBAC;
  • evitar credenciais partilhadas;
  • proteger automações com identidades geridas;
  • criar alertas para operações críticas;
  • consultar o Activity Log;
  • evitar IPs públicos quando Bastion, VPN ou acesso privado forem suficientes;
  • manter os discos encriptados;
  • validar periodicamente os backups.

As operações automatizadas devem registar:

  • identidade que iniciou a operação;
  • VM afetada;
  • estado anterior;
  • estado pretendido;
  • resultado;
  • duração;
  • erros recebidos.

Desempenho

Um SKU inferior pode reduzir:

  • vCPUs;
  • memória;
  • largura de banda de rede;
  • IOPS;
  • débito dos discos;
  • número máximo de discos;
  • número máximo de interfaces;
  • capacidade de caching;
  • dimensão do disco temporário.

Uma redução de tamanho deve ser acompanhada por monitorização depois da alteração. É importante verificar se o novo SKU introduziu throttling ou saturação.

Manutenção

Para ambientes de desenvolvimento e teste, é recomendável automatizar horários:

  • iniciar antes do período de utilização;
  • desalocar no final;
  • excluir fins de semana ou feriados;
  • confirmar o estado final;
  • alertar quando a operação falhar.

O Auto-shutdown ajuda a desligar VMs num horário definido, mas não substitui uma política completa de:

  • arranque;
  • exceções;
  • dependências;
  • drenagem da aplicação;
  • confirmação do estado;
  • tratamento de falhas.

Em produção, desligar uma única VM não deve ser a principal estratégia de disponibilidade. Aplicações críticas devem utilizar redundância, balanceamento, health probes e procedimentos de manutenção controlados.

Concluindo, o ciclo de vida de uma VM no Azure influencia diretamente a disponibilidade, o desempenho e os custos da solução. Uma VM no estado Stopped está desligada, mas continua alocada e, por isso, continua a gerar custos de computação. Para interromper esse medidor, é necessário que a VM atinja o estado Stopped (Deallocated).
A desalocação não torna a solução totalmente gratuita. Discos, snapshots, endereços IP, backups, monitorização, recursos de rede e compromissos comerciais podem continuar a ser faturados.

A operação também introduz riscos: perda do conteúdo do disco temporário, alteração de IPs dinâmicos e indisponibilidade de capacidade durante o próximo arranque.
O redimensionamento deve ser tratado como uma alteração disruptiva. A decisão deve basear-se em métricas, compatibilidade técnica, disponibilidade de capacidade e impacto financeiro. Depois da alteração, tanto a infraestrutura como a aplicação devem ser validadas.

Uma gestão correta do ciclo de vida não consiste apenas em executar comandos. Exige compreender o estado pretendido, preparar a aplicação, antecipar os custos residuais e confirmar o resultado final.

Checklist de validação

  • Confirmei a subscrição, o grupo de recursos e o nome da VM.
  • Distingo o estado de aprovisionamento do estado de energia.
  • Consultei o estado através do plano de controlo do Azure.
  • Para poupar computação, confirmei Stopped (Deallocated).
  • Inventariei discos, snapshots, IPs, backups e recursos de rede.
  • Verifiquei Reservations, Savings Plans e Capacity Reservations.
  • Confirmei que não existem dados persistentes no disco temporário.
  • Validei quotas e disponibilidade do SKU pretendido.
  • Analisei CPU, memória, discos e rede antes do redimensionamento.
  • Confirmei os limites de discos e interfaces do novo SKU.
  • Planeei a interrupção provocada pelo redimensionamento.
  • Confirmei a estabilidade dos endereços IP e DNS.
  • Preparei a aplicação antes da paragem.
  • Validei o estado e o tamanho depois do arranque.
  • Testei a aplicação, os discos, a rede e os serviços.
  • Consultei o Activity Log em caso de falha.
  • Comparei os custos no Azure Cost Management.
  • Configurei alertas para operações e estados inesperados.
  • Protegi as automações com identidades geridas e Azure RBAC.

Para leitura adicional consulte os links da documentação oficial:

Leave a Comment

O seu endereço de email não será publicado. Campos obrigatórios marcados com *