Agentes de aprovisionamiento de Windows en el primer arranque en la nube: EC2Launch v2, el agente de VM de Azure y cloudbase-init

Qué es

Los proveedores de nube ofrecen a una instancia nueva de Windows una forma de ejecutar configuración en su primer arranque. La configuración se entrega como un bloque de texto (un script o una configuración estructurada) que se proporciona al crear la instancia y que lee un agente ya incluido en la imagen.

AWS: el agente EC2Launch v2, que AWS documenta como software que se usa "to perform tasks during EC2 Windows instance launch" (para realizar tareas durante el lanzamiento de una instancia EC2 de Windows), ejecuta los datos de usuario de la instancia (scripts de PowerShell o por lotes, o listas de tareas en YAML). Es el agente predeterminado en las AMI de AWS con Windows Server 2022 y 2025, y AWS también publica AMI de 2016 y 2019 que lo incluyen; las AMI antiguas de 2016/2019 usan EC2Launch v1, y las anteriores a 2016 usan EC2Config. En las AMI personalizadas, ejecute Sysprep a través de EC2Launch v2 (con su herramienta de configuración o con EC2Launch.exe sysprep) para que el estado del propio agente se restablezca junto con el de Windows.

Azure: el agente de VM de Windows de Azure (visible en el Administrador de tareas como el proceso WindowsAzureGuestAgent.exe) ejecuta extensiones de VM y es opcional; para arrancar solo hace falta el agente de aprovisionamiento, que es independiente. En Windows, los datos personalizados (custom data) de Azure se escriben en %SystemDrive%\AzureData\CustomData.bin "but it isn't processed" (pero no se procesan), de modo que solo se ejecutan si la imagen contiene código que los lea, o si se usa en su lugar la extensión de script personalizado (Custom Script Extension). Los datos de usuario (user data) se pueden consultar en el Instance Metadata Service durante toda la vida de la VM. En Linux, cloud-init procesa los datos personalizados de forma predeterminada, mientras que el agente de VM de Linux (waagent) solo lo hace si Provisioning.ExecuteCustomData está habilitado en una imagen personalizada.

Otras nubes y nubes privadas locales: muchas imágenes de Windows para nubes distintas de AWS y Azure incluyen en su lugar cloudbase-init, un agente de código abierto. Su documentación describe un formato de datos de usuario #cloud-config como "Cloud-config YAML configuration as supported by cloud-init, excluding Linux specific content" (configuración YAML de cloud-config compatible con cloud-init, sin el contenido específico de Linux), lo que ofrece una superficie de configuración común entre plataformas de nube por lo demás distintas.

Por qué importa

Cuando una instancia de Windows arranca sin que se haya aplicado la configuración esperada, la solución depende de saber cuál de estos agentes está presente y dónde registra sus eventos, ya que ninguno de ellos convierte de forma fiable el fallo de un script de datos de usuario en un fallo del lanzamiento.

Cómo aplicarlo

• En AWS: revise %ProgramData%\Amazon\EC2Launch\log\agent.log para ver el estado y los errores del propio agente, según la guía de solución de problemas de EC2Launch v2 de AWS.
• En Windows sobre Azure: confirme que el proceso WindowsAzureGuestAgent.exe está en ejecución y revise después los registros del agente y de las extensiones en C:\WindowsAzure\Logs (WaAppAgent.log, Plugins\).
• En Linux sobre Azure: revise /var/log/waagent.log (waagent) y, en las imágenes con cloud-init, /var/log/cloud-init.log y cloud-init-output.log.
• En imágenes con cloudbase-init: revise el directorio de registros configurado (establecido con la opción log_dir en el propio archivo de configuración de cloudbase-init) para buscar errores de ejecución de los datos de usuario.
• En Azure, use los datos personalizados para una carga que se procese una sola vez durante el aprovisionamiento, y los datos de usuario cuando deban seguir siendo consultables y actualizables sin recrear la imagen. Los datos personalizados de una VM concreta no se pueden modificar después de crearla.

Trampas

• Suponer que una imagen de Windows se comporta como una imagen Linux con cloud-init; el agente, las rutas de registro y los formatos de datos de usuario admitidos varían según la plataforma y según el agente que incluya cada imagen concreta.
• Interpretar la ausencia de un archivo de registro como "no se proporcionó nada" en lugar de "el agente no está instalado o no es el esperado"; confirme qué agente hay presente (si hay alguno) antes de concluir que los datos de usuario estaban vacíos.
• Esperar que una VM de Windows en Azure ejecute por sí sola los datos personalizados, o tomar un estado de aprovisionamiento correcto en Linux como prueba de que el script de datos personalizados funcionó: Microsoft indica que los errores de los scripts no se consideran fallos fatales de aprovisionamiento.