Upgrades automáticos de imagem do SO para VMSS Flex: o que muda na gestão de patches na Azure

TL;DR: A Azure disponibilizou em public preview o upgrade automático de imagens de SO para VMSS Flex. Isso reduz significativamente o toil de patches manuais e garante que novas VMs herdem imagens corrigidas automaticamente. Para empresas brasileiras que operam scale sets críticos, a feature elimina gaps de segurança e simplifica a automação de lifecycle, mas exige atenção a scheduling e draining de instâncias.

Como funciona o upgrade automático de imagem do SO no VMSS Flex?

Gerenciar patches de sistema operacional em scale sets sempre foi um daqueles processos que consomem tempo de engenharia e, se mal feitos, abrem brechas de segurança. A Microsoft acaba de colocar em public preview uma funcionalidade que promete aliviar essa dor: o Automatic OS Image Upgrades para Virtual Machine Scale Sets (VMSS) com orquestrador Flex.

Até então, essa funcionalidade existia apenas para o modelo Uniform de orquestração. Agora, quem adotou o Flex — que oferece mais flexibilidade de gerenciamento de instâncias individuais — também pode contar com upgrades automáticos de imagem, sem depender de scripts customizados ou pipelines externos.

A mecânica é relativamente simples: o VMSS Flex passa a monitorar a versão da imagem de SO definida na configuração do scale set (seja uma imagem do marketplace, uma imagem personalizada no Azure Compute Gallery ou uma imagem de comunidade). Quando uma nova versão é detectada, o serviço orquestra a substituição das VMs existentes pela nova imagem, seguindo políticas de health e draining.

Quais impactos práticos para times de infra no Brasil?

Para a realidade de empresas brasileiras, onde a equipe de operações muitas vezes é enxuta e os ambientes precisam rodar 24/7, essa feature ataca diretamente dois problemas clássicos:

1. Atraso na aplicação de patches de segurança: em vez de depender de um cron job ou de um pipeline manual, o próprio Azure gerencia a atualização. Isso reduz a janela de exposição a vulnerabilidades conhecidas.
2. Toil operacional com recreação de VMs: quem já precisou fazer um rolling upgrade manual sabe o trabalho que dá — drenar tráfego, esperar health checks, validar logs. A automação nativa libera o time para tarefas mais estratégicas.

Por outro lado, é preciso atenção: upgrades automáticos podem quebrar a aplicação se a nova imagem introduzir uma mudança incompatível. O recomendado é testar a imagem em um stage antes de aprová-la no scale set de produção, usando o próprio processo de approval do Azure Compute Gallery.

Como configurar e quais requisitos?

A configuração é feita diretamente na propriedade upgradePolicy do VMSS Flex, que deve ser ajustada para Automatic. O recurso funciona com imagens Linux e Windows — desde que a imagem suporte o mecanismo de health extension ou health probe.

Requisitos técnicos:

• VMSS com orquestrador Flex (não funciona com Uniform)
• Health probe configurada (Application Health Extension ou Azure Load Balancer health probes)
• Permissões de IAM adequadas (Contributor no scale set, leitura no Azure Compute Gallery se usar imagem customizada)
• A imagem de SO deve ser referenciada por version: latest ou uma versão específica do gallery

Copiar{
  "properties": {
    "upgradePolicy": {
      "mode": "Automatic",
      "automaticOSUpgradePolicy": {
        "enableAutomaticOSUpgrade": true,
        "disableAutomaticRollback": false
      }
    }
  }
}

Quais cenários de uso mais se beneficiam?

Ambientes com alta rotatividade de instâncias, como clusters de Kubernetes (AKS) ou workers de processamento batch, são os que mais ganham. Nesses casos, a frequência de patches é alta e o custo de uma VM desatualizada pode ser crítico.

Já para cargas stateful ou bancos de dados rodando em VMs dentro do scale set, a automação exige mais cuidado: a drenagem de tráfego e a persistência de dados precisam ser garantidas. A recomendação é combinar a feature com scheduled events e Managed Disks com suporte a snapshots.

Pontos de atenção antes de ativar

• Rollback automático: a funcionalidade traz um mecanismo de rollback automático caso a nova VM não passe no health check — mas não espere milagres. Ele reverte para a última imagem válida, mas se o problema for na configuração do scale set, o rollback não resolve.
• Custo de reimage: cada upgrade cria uma nova VM e descarta a anterior (reimage). O processo é rápido, mas gera custo de criação de disco temporário. Para ambientes com centenas de VMs, vale simular o custo.
• Disponibilidade regional: a feature está em public preview. Nem todas as regiões Azure podem suportar no mesmo ritmo. Para workloads críticos no Brasil, verifique a disponibilidade na região South Brazil (Southeast) antes de ativar.

Perguntas Frequentes

• O upgrade automático de imagem do SO funciona em VMSS Uniform também?
  Não. A feature anunciada em public preview é exclusiva para VMSS Flex. Para o orquestrador Uniform, a Microsoft já oferecia upgrade automático de imagem há algum tempo. Agora a funcionalidade é estendida ao Flex, que tem um modelo mais flexível de gerenciamento de instâncias.

• Posso controlar a janela de manutenção para evitar impacto em produção?
  Sim. O recurso permite configurar políticas de health probe e draining de instâncias, além de trabalhar com Availability Zones e scheduled events. Isso possibilita que as atualizações ocorram de forma gradual, respeitando a capacidade e a saúde do workload — essencial para ambientes brasileiros com janelas de manutenção restritas.

• Preciso refazer todo o meu pipeline de CI/CD para usar essa feature?
  Não necessariamente. A funcionalidade reduz a necessidade de triggers manuais de redeploy para aplicar patches, mas você ainda deve manter pipelines de validação de imagem. O ideal é combinar o upgrade automático com um processo de approval e rollback para imagens quebradas, especialmente se você usa imagens customizadas do Azure Compute Gallery.

• Quais requisitos de IAM são necessários para habilitar a feature?
  É preciso ter permissões de Contributor ou Owner sobre o VMSS Flex e, se aplicável, acesso ao Azure Compute Gallery. A feature usa a identidade gerenciada do scale set para baixar a imagem — portanto, certifique-se de que a role atribuída tenha permissão de leitura sobre a galeria de imagens.

• Há custos adicionais associados a essa funcionalidade?
  Não há custo adicional pela feature em si, mas lembre-se de que cada atualização gera uma nova VM e descarta a anterior (reimage). Isso pode aumentar o throughput de criação de VMs e, em alguns casos, gerar custos de storage temporário. Para ambientes com muitas instâncias, vale modelar o custo total com o time de FinOps antes de ativar em larga escala.

---

Artigo originalmente publicado em Azure Updates - Latest from Azure Charts.