Agentes de provisionamento do primeiro boot no Windows na nuvem: EC2Launch v2, Azure VM Agent e cloudbase-init

O que é

Os provedores de nuvem oferecem às novas instâncias Windows uma forma de executar configurações no primeiro boot. A configuração é entregue como um bloco de texto (um script ou uma configuração estruturada) informado na criação da instância e lido por um agente que já vem embutido na imagem.

AWS: o agente EC2Launch v2, descrito pela AWS como software usado "to perform tasks during EC2 Windows instance launch" (para executar tarefas durante a inicialização de instâncias EC2 Windows), executa o user data da instância (scripts PowerShell/batch ou listas de tarefas em YAML). É o agente padrão nas AMIs do Windows Server 2022 e 2025 da AWS, que também publica AMIs 2016/2019 com ele. As AMIs 2016/2019 mais antigas usam o EC2Launch v1, e as anteriores a 2016 usam o EC2Config. Em AMIs personalizadas, execute o Sysprep por meio do EC2Launch v2 (pela ferramenta de configurações ou com EC2Launch.exe sysprep), para que o estado do próprio agente seja redefinido junto com o do Windows.

Azure: o Azure Windows VM Agent (visível no Gerenciador de Tarefas como o processo WindowsAzureGuestAgent.exe) executa extensões de VM e é opcional; para o boot basta o agente de provisionamento, que é separado. No Windows, o custom data do Azure é gravado em %SystemDrive%\AzureData\CustomData.bin "but it isn't processed" (mas não é processado). Ele só é executado se a imagem tiver código que o leia ou se você usar, em vez disso, a Custom Script Extension. O user data pode ser consultado no Instance Metadata Service durante toda a vida da VM. No Linux, o cloud-init processa o custom data por padrão, enquanto o Linux VM Agent (waagent) só faz isso quando Provisioning.ExecuteCustomData está habilitado em uma imagem personalizada.

Outras nuvens e nuvens privadas locais: muitas imagens Windows de nuvem que não são da AWS nem do Azure trazem, em vez disso, o cloudbase-init, um agente de código aberto. Sua documentação descreve o formato de user data #cloud-config como "Cloud-config YAML configuration as supported by cloud-init, excluding Linux specific content" (configuração YAML cloud-config conforme suportada pelo cloud-init, excluindo o conteúdo específico de Linux), o que oferece uma superfície de configuração comum a plataformas de nuvem diferentes entre si.

Por que importa

Quando uma instância Windows sobe sem a configuração esperada, a correção depende de saber qual desses agentes está presente e onde ele registra logs, pois nenhum deles faz com que um script de user data com falha resulte, de forma confiável, em uma falha de inicialização.

Como aplicar

• Na AWS: consulte %ProgramData%\Amazon\EC2Launch\log\agent.log para ver o status e os erros do próprio agente, conforme a orientação de solução de problemas do EC2Launch v2 da AWS.
• No Windows do Azure: confirme que o processo WindowsAzureGuestAgent.exe está em execução e depois verifique os logs do agente e das extensões em C:\WindowsAzure\Logs (WaAppAgent.log, Plugins\).
• No Linux do Azure: verifique /var/log/waagent.log (waagent) e, em imagens com cloud-init, /var/log/cloud-init.log e cloud-init-output.log.
• Em imagens com cloudbase-init: verifique o diretório de logs configurado (definido pela opção log_dir no arquivo de configuração do próprio cloudbase-init) em busca de erros na execução do user data.
• No Azure, use o custom data para uma carga processada uma única vez durante o provisionamento, e o user data quando ele precisar continuar acessível e atualizável sem recriar a imagem. O custom data de uma VM individual não pode ser alterado após a criação.

Armadilhas

• Supor que uma imagem Windows se comporta como uma imagem Linux com cloud-init: o agente, os caminhos de log e os formatos de user data aceitos variam conforme a plataforma e conforme o agente que a imagem específica traz.
• Interpretar a ausência de um arquivo de log como "nada foi fornecido", e não como "o agente não está instalado ou não é o esperado". Confirme qual agente (se houver) está presente antes de concluir que o user data estava vazio.
• Esperar que uma VM Windows no Azure execute o custom data por conta própria, ou tomar um estado de provisionamento bem-sucedido no Linux como prova de que o script de custom data funcionou: a Microsoft afirma que erros de script não são falhas fatais de provisionamento.