Saving time with Azure Resource Graph

Back to previous page

Saving time with Azure Resource Graph

This year, at the Ignite conference, Microsoft announced Azure Resource Graph service. As we can read in the documentation, Azure Resource Graph is:

a service in Azure that is designed to extend Azure Resource Management by providing efficient and performant resource exploration with the ability to query at scale across all subscriptions and management groups so that you can effectively govern your environment. These queries provide the following capabilities:

  • Ability to query resources with complex filtering, grouping, and sorting by resource properties.
  • Ability to iteratively explore resources based on governance requirements and convert the resulting expression into a policy definition.
  • Ability to assess the impact of applying policies in a vast cloud environment.

What is Azure Resource Graph?

Azure Resource Manager sends data to a cache that exposes some information about resource (Resource name, ID, Type, Resource Group, Subscriptions, and Location). Normally we make calls to each resource provider and request these informations for each resource. It means not only much more calls to make but also a need to create a script which will handle that operation.

With Azure Resource Graph, we can access these informations directly, using complex query language we know, the Kusto query language.

How to use Azure Resource Graph?

To use Azure Resource Graph, you need at least Reader (RBAC) role on the resources you want to query.

To query Azure Resource Graph, you can use Azure CLI, PowerShell, SDK or REST API directly.

Sample queries

How much time we are saving?

In simple words, a lot. Let’s consider a simple scenario with just 10 VMs in just one subscription. If we want to summarize Operating Systems we are using Without Azure Resource Graph, we need to call Azure Resource Manager for all the resources with resource type like Microsoft.Compute/virtualMachines and then iterate all VMs for storageProfile.osDisk.osType property. In Azure CLI it will be something like that:

The uniq -c command at the end is summarizing every unique OS type. The output of this script for my subscription is:

and it took a little bit more than 11s to complete.

With Azure Resource Graph I used az graph query command with simple Kusto query:

The output of this command is:

and it took around 1.5s to complete.

As you can see, in graph query I have limited query to just one subscription – it’s because Azure Resource Graph is returning results for all resources in all subscriptions we have access to. I have also noticed, that this rule is not true for subscriptions where we are external AAD users with RBAC roles – in that situation we are receiving “Access denied” message.


The response schema for ARG query is different than resource query. As an example, let’s check a schema for query about a VM.


az vm show -g group -n VM0



az graph query -q "where type =~ 'Microsoft.Compute/virtualMachines'" -s xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx


If you are wondering what Aliases are, check here.

About the Author:

Michal Smereczynski
Microsoft Azure MVP. Open Source Software and interoperability evangelist.


Smereczynski, M. (2018). Saving time with Azure Resource Graph. Available at: [Accessed 30 January 2019]

Share this on...

Leave a Reply

Back to previous page

ESPC Community Login

ESPC Community Login

  • Already a member? Simply Login

  • Become an ESPC Community Member today to access a wealth of SharePoint, Office 365 and Azure knowledge for free. New content is added daily to the online Resource Centre, across a variety of topics and formats from Microsoft MVP’s and industry experts. .

    (All Fields Required)
  • ** Verification Email will be sent **
    Check your Spam/Junk/Clutter folder
  • This field is for validation purposes and should be left unchanged.
Scroll to top
[gravityform id="97" title="false" description="false" ajax="true" tabindex="50"]
  • This field is for validation purposes and should be left unchanged.