Skip to content

Subscription Activity Logs

Every Azure subscription has an Activity Log. It records every control-plane operation on the subscription and its resources: who created, changed or deleted what, role assignments, policy decisions and service health events. Like Entra ID's logs, it is kept only briefly unless it is exported. A diagnostic setting on each subscription streams it to the same central Log Analytics workspace as the Entra ID logs, so identity events and resource changes can be queried together.

Why it matters

Azure keeps Activity Log events for 90 days, and only in the portal and API. Exporting them to Log Analytics adds:

  • Longer retention. AzureActivity keeps 90 days interactive and about 2 years in archive, the same as SigninLogs and AuditLogs.
  • Correlation. Sign-ins and directory changes (SigninLogs, AuditLogs) sit next to resource changes (AzureActivity) in one workspace. You can follow a single identity from sign-in to the changes it made.
  • Audit evidence. A durable record of every control-plane write supports NIST SP 800-53 AU-2 (audit events), AU-6 (audit review) and AU-11 (audit record retention).
  • Alerting and security tooling. Alert rules, Defender for Cloud and Sentinel (if added) read AzureActivity.

What is streamed

Each subscription's diagnostic setting, named to-log-platform-prod, sends every Activity Log category to the AzureActivity table. Subscription-level diagnostic settings carry logs only, not metrics.

Category What it records
Administrative Every create, update, delete and action through Resource Manager, including role assignments. This is the core audit trail.
Security Alerts raised by Microsoft Defender for Cloud
Policy Azure Policy effects, such as denials, audits and DeployIfNotExists deployments
ServiceHealth Azure service incidents and maintenance affecting the subscription
ResourceHealth Health changes to individual resources
Alert Azure Monitor alert activations
Autoscale Autoscale operations
Recommendation Azure Advisor recommendations

How subscriptions are onboarded

Two mechanisms point at the same workspace, divided by one rule. A fixed thing created once is managed in Terraform. A rule that must also cover subscriptions that don't exist yet is managed as policy.

flowchart LR
    subgraph TF["Terraform: azure-monitoring"]
        PLAT["Platform subscriptions<br/>(local.activity_log_subscriptions)"]
    end
    subgraph EPAC["EPAC: psa-mon-actlog-001 at mg-intermediate-root"]
        WL["Every other subscription<br/>(workload, landing zone, sandbox, future)"]
    end
    PLAT -->|"diagnostic setting<br/>to-log-platform-prod"| LAW["log-platform-prod<br/>AzureActivity"]
    WL -->|"DeployIfNotExists<br/>(remediation task)"| LAW

Platform subscriptions: Terraform

The azure-monitoring deployment, which also owns the workspace, creates an azurerm_monitor_diagnostic_setting for each subscription listed in local.activity_log_subscriptions. Today that is the management subscription. Connectivity and identity are placeholders for when those subscriptions exist.

To add a platform subscription:

  1. Add it to local.activity_log_subscriptions in azure-monitoring/locals.tf.
  2. Grant sp-pla-tf-monitoring-rw Monitoring Contributor on that subscription, from the subscription-vending deployment.
  3. MR, plan, then apply.

Don't add workload subscriptions here. Policy covers them.

Every other subscription: Azure Policy (EPAC)

The EPAC assignment psa-mon-actlog-001 assigns the built-in policy Configure Azure Activity logs to stream to specified Log Analytics workspace (2465583e-4e78-4c15-b6be-a36cbc7c8b0f) at mg-intermediate-root. Every management group sits under it, so every current and future subscription is in scope, including sandboxes. No subscriptions are excluded.

Setting Value Meaning
Effect DeployIfNotExists The policy can create the missing diagnostic setting.
Enforcement mode DoNotEnforce The policy evaluates and reports but does not deploy anything by itself when a subscription is created or changed.
Identity System-assigned managed identity, created by EPAC Used by remediation tasks. EPAC grants it the roles the policy declares: Monitoring Contributor and Log Analytics Contributor.

New subscriptions are not onboarded automatically

Because the assignment uses DoNotEnforce, a newly vended subscription does not get its diagnostic setting when it is created. It appears as non-compliant in Azure Policy, and its Activity Log is not exported until someone runs a remediation task.

Run a remediation task after vending a subscription, or regularly for all non-compliant subscriptions:

Start-AzPolicyRemediation -Name "actlog-remediate-$(Get-Date -Format yyyyMMdd)" `
  -ManagementGroupName "mg-intermediate-root" `
  -PolicyAssignmentId "/providers/Microsoft.Management/managementGroups/mg-intermediate-root/providers/Microsoft.Authorization/policyAssignments/psa-mon-actlog-001"

To make onboarding automatic, change enforcementMode to Default in psa-mon-ActivityLogToWorkspace.jsonc. New subscriptions would then get the setting on creation, and existing ones would still need one remediation run.

Resource logs are separate

This page covers the subscription Activity Log. Logs from resources inside a subscription, such as Key Vault access or NSG flow events, need a diagnostic setting on each resource. The companion EPAC assignment psa-mon-diagres-001 handles those at the same scope, but it is currently audit-only (AuditIfNotExists). It reports which resources are missing a setting but does not create one.

Security classification

Creating or deleting a subscription's diagnostic setting needs Microsoft.Insights/diagnosticSettings/write on the subscription, which Monitoring Contributor includes. Under the Access Tiering Model this is Tier 1 (management plane). It administers logging, not identity, so it is delivered through Lane B: azure-monitoring and EPAC both deploy from CI.

It still earns stricter Tier 1 handling under NIST AC-6(1), access to security functions. Deleting a subscription's diagnostic setting silently stops that subscription's audit trail. The deletion is itself an Administrative event. It is always kept in the subscription's own Activity Log for 90 days, and it usually reaches the workspace too.

Verifying it works

List a subscription's diagnostic settings:

az monitor diagnostic-settings subscription list --subscription <subscription-id> -o table

Check which subscriptions are reporting to the workspace:

AzureActivity
| where TimeGenerated > ago(24h)
| summarize LastEvent = max(TimeGenerated), Events = count() by SubscriptionId
| order by LastEvent desc

A subscription missing from this result has either had no activity in the last 24 hours or is not exporting. Check its compliance with psa-mon-actlog-001 in Azure Policy.

Recommended: alert on removal

Alert when anyone deletes a diagnostic setting. Pair it with the "no events" check above, because the delete event itself may not reach the workspace once the stream is cut:

AzureActivity
| where OperationNameValue =~ "MICROSOFT.INSIGHTS/DIAGNOSTICSETTINGS/DELETE"
| project TimeGenerated, SubscriptionId, Caller, ResourceId, ActivityStatusValue