Using Azure Policy to send logs from Flexible Virtual Machine Scale Sets to Azure Monitor

Introduction

Microsoft recommends Flexible orchestration mode as the default option for new Virtual Machine Scale Sets (VMSS).

Flexible VMSS expose their instances as standard Azure VM resources, providing greater flexibility than Uniform orchestration. Although extensions can still be defined in the scale set model, Azure Policy provides a centralized way to enforce the installation of the Azure Monitor Agent (AMA) and the association of a Data Collection Rule (DCR) across multiple scale sets and deployment methods.

If you are running tens or hundreds of Flexible VMSS across multiple subscriptions, manually installing AMA and associating a DCR with every new instance is not a sustainable approach.

Azure Policy provides a declarative way to enforce this configuration at scale so that every VM instance belonging to a Flexible VMSS will:

• Have the Azure Monitor Agent extension installed. Agent updates are then handled according to the extension upgrade settings and the Azure Monitor Agent servicing model.
• Be associated with a Data Collection Rule that defines which logs and performance counters must be sent to a Log Analytics workspace or another supported destination.

New VM instances created during scale-out operations or through Terraform or Bicep deployments are evaluated by Azure Policy. If an instance is noncompliant, the DeployIfNotExists policies deploy the required identity or agent configuration and create the DCR association. This process is automatic, but not necessarily instantaneous.

Built-in DeployIfNotExists policies

Azure Policy provides DeployIfNotExists policies and initiatives for installing AMA and associating DCRs with Azure VMs, VMSS, and Azure Arc-enabled servers.

Because instances in a Flexible VMSS are exposed as standard Azure VM resources, verify that the selected initiative evaluates Microsoft.Compute/virtualMachines. Policies designed specifically for Microsoft.Compute/virtualMachineScaleSets might target the scale set resource or Uniform orchestration scenarios rather than the individual Flexible instances.

The relevant built-in initiatives currently use names similar to:

• Deploy the Azure Monitor Agent for Linux client machines by using user-assigned managed identity-based auth and associate it with a DCR.
• Deploy the Azure Monitor Agent for Windows client machines by using user-assigned managed identity-based auth and associate it with a DCR.

Initiative display names can change. Before assigning an initiative, verify its definition ID, version, supported operating systems, evaluated resource types, included policy definitions, and parameters in the Azure Policy portal.

Depending on the selected initiative and its parameters, the included policies can:

• Create or use a user-assigned managed identity for AMA authentication.
• Install the AzureMonitorLinuxAgent or AzureMonitorWindowsAgent extension on the evaluated VM resources.
• Create a Data Collection Rule Association between the VM instances and the specified DCR.

Prerequisites

Before assigning the policy, make sure you have:

• A Log Analytics workspace or another supported destination already created.
• A Data Collection Rule that targets the destination and defines the data sources you want to collect, such as Syslog, Windows Event Logs, performance counters, or custom text logs.
• A scope for the policy assignment: a Management Group, Subscription, or Resource Group.
• A clear understanding of the two managed identities involved:
  • The policy assignment managed identity performs the resource deployments required by DeployIfNotExists.
  • The user-assigned managed identity used by AMA authenticates the agent on the VM instances.

These identities serve different purposes. When using automation, explicitly create the policy assignment identity and grant every role required by the included policy definitions at the appropriate scope. Do not assume that creating the identity also grants the required roles.

When assigning the initiative from the Azure portal, Azure can create the policy assignment identity and, when the operator has sufficient permissions, configure the role assignments requested by the initiative. For assignments created through Azure CLI or infrastructure as code, verify and grant the required roles explicitly before starting remediation.

Create the Data Collection Rule

You can create a DCR from the Azure portal under Monitor > Data Collection Rules > Create, or by using Azure CLI:

az monitor data-collection rule create \
  --resource-group <rg_name> \
  --name <dcr_name> \
  --location <region> \
  --rule-file ./dcr.json

The dcr.json file must follow the DCR schema and reference the destination resources required by your configuration.

Create the DCR in the same region as its destination Log Analytics workspace or Azure Monitor workspace. The monitored machines do not necessarily have to be in the same resource group or subscription, provided that the applicable tenant and authorization requirements are met.

Assign the policy initiative

From the Azure portal

1. Go to Policy > Definitions and search for the appropriate Windows or Linux initiative that deploys AMA by using user-assigned managed identity-based authentication and associates it with a DCR.
2. Open the initiative and verify that it evaluates the resource types required for your Flexible VMSS instances, including Microsoft.Compute/virtualMachines.
3. Select Assign and choose the desired scope: Management Group, Subscription, or Resource Group.
4. In the Parameters tab:
   • Configure the user-assigned identity option according to whether the initiative should use an existing identity or create and assign the identity required for AMA authentication.
   • Provide the Resource ID of the Data Collection Rule.
   • Review any parameters for supported operating systems, additional VM images, or DCR association behavior.
5. In the Remediation tab, enable Create a remediation task so that the initiative is applied to existing noncompliant resources, not only to resources evaluated after the assignment.
6. Review and create the assignment.

Using Azure CLI

Export or inspect the selected initiative definition before preparing the parameter file. Parameter names must exactly match the definition and version available in your environment. The names in the following example are illustrative and must be verified before use.

For Linux:

az policy assignment create \
  --name "deploy-ama-vmss-flex" \
  --display-name "Deploy AMA on Flexible VMSS" \
  --scope "/subscriptions/<subscription_id>" \
  --policy "<initiative_definition_id>" \
  --params '{
    "dcrResourceId": {
      "value": "<dcr_resource_id>"
    },
    "bringYourOwnUserAssignedIdentity": {
      "value": false
    }
  }' \
  --location <region> \
  --assign-identity

Here, --assign-identity creates a system-assigned managed identity for the policy assignment. It is not the identity used by AMA on the VMs. Depending on the selected initiative, setting the user-assigned identity parameter to false can instruct the initiative to create and assign a user-assigned managed identity for AMA authentication.

Grant the policy assignment identity the role definitions required by the initiative before running remediation. Creating the policy assignment identity does not, by itself, guarantee that all required role assignments have been granted.

Then trigger the remediation:

az policy remediation create \
  --name "remediate-ama-vmss-flex-linux" \
  --policy-assignment "<policy_assignment_id>"

What happens on the scale set

Once the initiative is assigned and the remediation task completes, verify the following on the VM instances belonging to each Flexible VMSS:

• The AzureMonitorLinuxAgent or AzureMonitorWindowsAgent extension is in the Provisioning succeeded state.
• A Data Collection Rule Association exists for the individual VM resource under Monitor > Data Collection Rules.
• The data sources configured in the DCR, such as Windows events, Syslog records, performance counters, or custom text logs, are reaching the configured destinations.

New VM instances created during scale-out are evaluated by Azure Policy. If they are noncompliant, the DeployIfNotExists policies apply the required configuration. Allow for policy evaluation, extension deployment, and DCR association before expecting data to appear in the destination.

Important considerations

• Flexible VMSS instances are exposed as standard Azure VM resources. Extensions can be included in the scale set model, while Azure Policy can also evaluate and configure the individual VM resources. This makes policy useful when consistent monitoring must be enforced across multiple scale sets and deployment methods.
• Verify the evaluated resource types. Do not select an initiative only from its display name. Inspect its policy rules and confirm that it covers the Flexible VMSS instance resources required by your design.
• Review supported operating systems and images. Built-in policy definitions contain supported Windows and Linux image lists. If you use a custom image, review whether the initiative provides an additional VM images parameter.
• Plan the removal of the legacy Log Analytics agent. If MMA or the OMS Agent is still installed, validate the migration to AMA before removing it. Temporary coexistence can be required during migration, but duplicate data collection can increase ingestion volume and cost.
• Assign policy at the highest reasonable scope. A Management Group or Subscription assignment usually provides more consistent coverage, but its managed identity must have only the roles and scopes required by the included policies.
• Allow for policy processing time. A new instance does not inherit the policy configuration instantaneously. It must be evaluated, remediated when necessary, and successfully connected to its DCR.
• Control ingestion costs. Combine the monitoring design with retention settings, table plans, transformations where appropriate, and a Log Analytics workspace daily cap if a cap is compatible with your operational requirements.

Sources

• Azure Monitor Agent overview
• Data Collection Rules in Azure Monitor
• Use Azure Policy to install and manage the Azure Monitor Agent
• Azure Monitor Agent requirements
• Orchestration modes for Virtual Machine Scale Sets
• Upgrade policy modes for Virtual Machine Scale Sets