Resource Graph Explorer and common use cases
This is my third post about Resource Graph and this time I will cover the new Explorer in the Azure portal and some use cases where I have found Resource Graph really helpful.
You can find my previous posts here:
Resource Graph Explorer
The new Resource graph Explorer gives the opportunity to create, save and pin queries that we made in Resource graph. In the Explorer you use Kusto query language directly so no need to use Powershell or CLI.
More info about Kusto can be found here
where type =~ 'microsoft.compute/virtualmachines'
| summarize count() by
OS = tostring(aliases['Microsoft.Compute/virtualMachines/storageProfile.osDisk.osType']),
OsVersion = tostring(properties.storageProfile.imageReference.version)
In the explorer we can build queries by just browsing and clicking the resources and properties we are looking for.
In below example i first added virtual machines and then vmsize under hardwareProfile. Then i simply add the size i was looking for in my case Standard_B1ls.
It also gives us an easy way to save and reuse our saved queries, with the save and open query option showed in above picture. No need to memorize or save queries elsewhere.
Another nice feature is that you can pin your results to visualize it on your dashboard.
View from dashboard
Its so easy to create resources in Azure today, which is great! But often when we are cleaning our environments of retired resources, we tend to focus on the one that generates the most cost. This leaves us with orphan resources that might not longer be in use. Let´s take Availability set as example we create them to keep our SLA´s up for virtual machines but after retirement of the virtual machines the availability sets might still be there.
Let’s use Resource graph explorer to find all Availability sets and show the property of virtual machines.
where type =~ 'Microsoft.Compute/availabilitySets' | project subscriptionId, name, resourceGroup, properties.virtualMachines
This can be done through for example Powershell but the scripts tend to become quite advanced just to get the property of resources across subscriptions, this is not the case with Resource Graph.
Evaluate Policy Impact
Perhaps one of the most common use cases for resource graph is to evaluate policy impact before even creating the policy. We can query our resource in such way our policy would evaluate our resources. Take Storage account as an example. Perhaps we would like to deploy a policy to deny creation of Storage accounts that allows connection from “All Networks”. Before doing this, we can run a query in Resource Graph and get the result for already created resources.
where type =~ 'microsoft.storage/storageaccounts' | where aliases['Microsoft.Storage/storageAccounts/networkAcls.defaultAction'] =='Allow'
If you are using Powershell or CLI its easy to create a policy based on your Resource graph query take a look at the post i linked to at the start of this post.
Get Resource changes
A recently released preview feature gives you the possibility to find changes done to your resources. To do this we can use REST API, Activity log or the compliance view in Azure Policy. All the below approaches to get Change history is provided through Resource Graph. To trigger a change a property of the resource is either added, removed or modified.
View Change history is available as preview in Activity logs.
From the Activity log you can drill down to an event and then click “Change History (Preview)”.
In my example below i changed the setting on a storage account to allow Access from – Selected networks.
From the compliance view in Azure Policy go to your initiative or definition and then select the recourse you would like to view change history for. From here we get similar experience as described before in Activity logs. We can easily determine what properties that have changed.
Choose detection time to show exactly what changed for the resource.
Its also possible to get resource changes through the API, i wont cover the details in this post but follow the link below to get started.
Through the API the process can be broken down into three steps.
- Enter an interval and resourceID.(Find when changes were detected)
- Use the ChangeID to to get what properties changed.(See what properties changed)
- The response will be a JSON formatted with two configurations, one before the snapshot and one after the snapshot. Compare both to determine what properties changed for the given changeID.
To get a better understanding on how to use the API for resource changes take a look here
I think the new resource change view is great and it gives a simple way to see how your resources have modified. The possibility to do so both through Activity log and API makes it flexible and useful for most common scenarios and through the compliance view it’s a great way to track changes that might have changed your compliance level.
Azure Resource Explorer
With the new explorer we get similar experience as we are familiar with from Log Analytics and the language is also Kusto based as in Log analytics. Build a library of commonly used queries and pin them to your dashboard to keep tracking of resources and properties that’s important in your environment.
If you have any questions or scenarios you would like to discuss you can reach me at