I run into the same picture again and again. In many Azure environments, resource logging is patchy or inconsistent. Sometimes a handful of workloads send diagnostic logs to Log Analytics, sometimes none do, and Azure Policy only gets used for tagging or resource locks, never for systematic logging. Consistent diagnostic settings matter for security, compliance and troubleshooting, and they also give you visibility into costs. Rolling out diagnostic settings at scale with Azure Policy built-in initiatives isn't hard, as long as the prerequisites are in place and you know a few practical tricks.

Built-in initiatives enforce diagnostic settings through DeployIfNotExists

Microsoft ships several ready-made policy initiatives for deploying diagnostic settings. The one I use most is Deploy Diagnostic Settings for {category} to Log Analytics workspace, which works via DeployIfNotExists. With it you can enforce the allLogs category group (or individual categories) on supported resources and write the logs straight into a Log Analytics workspace. It covers Key Vaults, Storage Accounts, App Services and more, so every new resource logs the way it should without an admin configuring anything by hand. The policies are fully parameterizable (workspace, categories, even table plans) and can be assigned to entire management group hierarchies. For me, this is one of the core building blocks of a well-governed landing zone, as I explained in my post on landing zones, management groups and policy.

The managed identity needs the right permissions from day one

Where people often trip up is the managed identity that DeployIfNotExists assignments require. It needs at least Log Analytics Contributor on the target workspace, plus permissions on the resources it is supposed to configure (Contributor or a suitable custom role). Forget this and remediation either fails silently or throws permission errors. Assign the managed identity when you create the policy assignment, then check afterwards that it actually has the access it needs. Check again if you restructure your role assignments at some point. If you don't, you'll be looking at a long list of resources stuck at "not compliant".

Existing resources only comply after a remediation task

Anything created before the policy was assigned needs a remediation task. In the Azure Portal, open Azure Policy → Remediation, pick the policy assignment and start remediation. The managed identity must have rights on every affected resource. If it doesn't, the remediation logs show you exactly where it hit access problems.

# PowerShell (Az module, e.g. Cloud Shell), needs Policy Contributor + resource group access
Start-AzPolicyRemediation -Name "diagnostic-remediate" -PolicyAssignmentId <ID> -ResourceGroupName <RG>

In large tenants I've watched remediation tasks for diagnostic settings run for hours, sometimes days, depending on how many resources there are and how the policy is scoped. It's worth waiting for, though. Afterwards you have an audit trail showing which resources were brought into compliance and when.

Log categories, retention and workspace design decide the cost

This part gets overlooked a lot. If you enable allLogs on every resource through policy, you can end up with terabytes of log data per month, and that hits your Log Analytics bill hard (Pay-as-you-go). What I recommend in practice:

  • Restrict logging to the categories you actually need (e.g. Audit or only selected metrics/logs).
  • Set workspace retention to match the business need (30/90 days is often enough, not the default 2 years).
  • In larger organizations, think about separate workspaces for different business units or workloads.

Azure Monitor → Diagnostic settings gives you a complete view of what is being sent where.

Practical tip: Begin with policies that enforce only the AuditLogs category or cover just a few specific resource groups. Then widen the scope step by step so the bill doesn't surprise you.

Subscription-level activity logs need their own export

Resource logs only tell part of the story. Subscription-level Activity Logs (formerly Audit Logs) capture changes to the Azure configuration and access attempts, which you need for compliance and forensics. They have to be exported to Log Analytics separately, ideally via policy as well. A short retention period is usually fine here, because you rarely need Activity Logs older than a few months. With a policy in place, nothing slips through, even when someone deletes or breaks the export by hand.

The compliance view shows where diagnostic settings are missing

The results of your policy assignments and remediation tasks show up in the Azure Policy Portal under Compliance. You see compliant and non-compliant resources side by side and can start remediation from there when needed. I sketched the following diagram to show how policy-driven diagnostic settings fit together:

flowchart TD
    mg["Management Group"] --> policy["Azure Policy"]
    policy --> mi["Managed Identity"]
    policy --> rem["Remediation Task"]
    rem --> res["Resource"]
    res --> diag["Diagnostic Setting"]
    diag --> la["Log Analytics Workspace"]

Figure: Diagnostic settings deployed at scale through Azure Policy and remediation.

In large environments especially, review compliance on a regular schedule and dig into resources that stay non-compliant. Applied consistently, Azure Policy gives you a solid base for reporting, alerting and even cost control, provided you keep track of what is actually being logged.

Diagnostic settings at scale belong in every mature Azure tenant

In my view, any serious Azure tenant today should roll out diagnostic settings through Azure Policy as a matter of course. Get the managed identity's permissions right, decide consciously what you log and why, and keep watching compliance. If you build this into your landing zone from the beginning, you spare yourself an awkward retrofit later and the logs are there when you need them. With policy and automation available, I don't see a good reason for missing logs anymore.