Windows first-boot provisioning agents in the cloud: EC2Launch v2, the Azure VM Agent, and cloudbase-init

What it is

Cloud providers give a new Windows instance a way to run configuration on its first boot, delivered as a block of text (a script or a structured config) supplied when the instance is created and read by an agent already baked into the image.

AWS: the EC2Launch v2 agent, documented by AWS as software used "to perform tasks during EC2 Windows instance launch," runs the instance's user data (PowerShell/batch scripts or YAML task lists). It is the default agent on AWS Windows Server 2022 and 2025 AMIs, and AWS also publishes 2016/2019 AMIs with it; older 2016/2019 AMIs use EC2Launch v1, and pre-2016 AMIs use EC2Config. For custom AMIs, run Sysprep through EC2Launch v2 (its settings tool or EC2Launch.exe sysprep) so the agent's own state is reset along with Windows.

Azure: the Azure Windows VM Agent (visible in Task Manager as the WindowsAzureGuestAgent.exe process) runs VM extensions and is optional; booting needs only the separate provisioning agent. On Windows, Azure custom data is written to %SystemDrive%\AzureData\CustomData.bin "but it isn't processed", so it runs only if your image has code that reads it, or if you use the Custom Script Extension instead. User data is retrievable from the Instance Metadata Service for the life of the VM. On Linux, cloud-init processes custom data by default, while the Linux VM Agent (waagent) only does so when Provisioning.ExecuteCustomData is enabled in a custom image.

Other clouds and on-premises private clouds: many non-AWS, non-Azure Windows cloud images instead ship cloudbase-init, an open-source agent. Its documentation describes a #cloud-config user-data format as "Cloud-config YAML configuration as supported by cloud-init, excluding Linux specific content," giving a common configuration surface across otherwise different cloud platforms.

Why it matters

When a Windows instance comes up without the expected configuration applied, the fix depends on knowing which of these agents is present and where it logs, since none of them reliably turns a failed user-data script into a failed launch.

How to apply

• On AWS: check %ProgramData%\Amazon\EC2Launch\log\agent.log for the agent's own status and errors, per AWS's EC2Launch v2 troubleshooting guidance.
• On Azure Windows: confirm the WindowsAzureGuestAgent.exe process is running, then check the agent and extension logs under C:\WindowsAzure\Logs (WaAppAgent.log, Plugins\).
• On Azure Linux: check /var/log/waagent.log (waagent) and, on cloud-init images, /var/log/cloud-init.log and cloud-init-output.log.
• On cloudbase-init images: check the configured log directory (set via the log_dir option in cloudbase-init's own configuration file) for userdata execution errors.
• On Azure, use custom data for a payload processed once at provisioning, and user data when it must remain retrievable and updatable without reimaging. Custom data of a single VM cannot be changed after creation.

Pitfalls

• Assuming a Windows image behaves like a Linux cloud-init image; the agent, its log paths and its supported user-data formats differ by platform and by which agent the specific image ships.
• Treating a missing log file as "nothing was supplied" rather than "the agent isn't installed or isn't the one expected" — confirm which agent (if any) is present before concluding user data was empty.
• Expecting a Windows VM on Azure to execute custom data by itself, or reading a successful provisioning state on Linux as proof that the custom-data script worked: Microsoft states that script errors are not fatal provisioning failures.