In a recent engagement with a customer willing to decrease Shared Access Signature (SAS) tokens usage in their Storage Accounts, we found out that a good amount of SAS token-based requests was associated with VM diagnostics. One practical way to reduce SAS token usage is to eliminate dependencies that require Storage Accounts in the first place, especially when Azure offers managed alternatives.
This post focuses on two VM-level features that often introduce (or preserve) unnecessary Storage Account coupling:
- The legacy IaaS Diagnostics extension (retiring), which can write diagnostic data to Storage
- Boot diagnostics configured to use a customer-managed Storage Account, considering Microsoft-managed boot diagnostics works as well without any operational effort.
1) Retire the legacy IaaS Diagnostics extension
If you’re no longer using the legacy IaaS Diagnostics extension for VM monitoring and troubleshooting, removing it is an easy win: it reduces Storage Account coupling and helps you stay ahead of platform deprecations. Microsoft has announced retirement of the extension as of March 31, so now is a good time to inventory and remove it where it’s still present.
How to find affected VMs
Use Azure Resource Graph (ARG) to identify virtual machines with the extension installed across subscriptions at scale. Once you have the list, you can remove the extension directly from the Azure portal or using your preferred automation approach (PowerShell or Azure CLI).
For a proven at-scale removal pattern (including cleanup of the data the extension produced), see How to remove at scale the Azure Diagnostics Extension and its storage data.
2) Switch boot diagnostics to Microsoft-managed storage
Boot diagnostics are invaluable when you need VM boot screenshots/logs and serial console access. Historically, it required a customer-managed Storage Account—often leading teams to create “diagnostics” Storage Accounts, wire up access, and sometimes rely on SAS tokens to make the integration work across tooling.
Today, you can enable boot diagnostics without providing a Storage Account by using managed boot diagnostics (Microsoft-managed storage). In most scenarios, this removes an entire class of dependency without sacrificing functionality. The switch is also operationally friendly: it does not require a VM reboot and doesn’t interfere with the guest OS.
How to find and migrate at scale
As with extensions, Azure Resource Graph is a good starting point to identify VMs that have boot diagnostics enabled against a customer-managed Storage Account. Use the query below to identify those VMs:
resources
| where type =~ 'microsoft.compute/virtualmachines'
| extend diagProfile = properties.diagnosticsProfile.bootDiagnostics
| extend powerState = tostring(properties.extended.instanceView.powerState.code)
| extend diagAccount = tostring(split(parse_url(tostring(properties.diagnosticsProfile.bootDiagnostics.storageUri)).Host,'.')[0])
| extend bootDiagnosticsEnabled = tobool(properties.diagnosticsProfile.bootDiagnostics.enabled)
| project name, resourceGroup, subscriptionId, powerState, bootDiagnosticsEnabled, diagAccount
| where bootDiagnosticsEnabled and isnotempty(diagAccount)
After you’ve validated the impact in a non-production subscription, you can automate migration in bulk to enable managed boot diagnostics, by using the Set-AzVMBootDiagnosticsWrapper.ps1 script. Simply download it, unblock it (file properties > unblock), and upload it to Azure Cloud Shell.
Example PowerShell usage pattern:
./Set-AzVMBootDiagnosticsWrapper.ps1 -Action EnableManaged [-TargetSubscriptionId <sub id>] [-ARGFilter <ARG condition, e.g., resourceGroup =~ 'xyz'>] [-Simulate]
Wrap-up
Reducing SAS token usage isn’t only about replacing tokens with another credential type —it’s also about removing the underlying dependencies that make tokens attractive in the first place. By (1) removing the retiring IaaS Diagnostics extension and (2) migrating boot diagnostics to Microsoft-managed storage, you can simplify your VM baseline, reduce Storage Account sprawl, and stay ahead of deprecations. As a next step, consider standardizing these checks in your provisioning pipelines (Bicep/Terraform), and add periodic ARG-based hygiene queries to keep drift under control.
Microsoft