Azure Resource Graph - Simply Explained

0:00 Welcome to the M365 FM podcast, where we explore the people, ideas and technologies shaping the future of work. What Azure Resource Graph actually is? Azure Resource Graph is a service inside Azure that lets you ask questions about your resources and get fast answers, even when you have thousands of them. The name sounds heavier than the thing really is. Strip it down and you get a tool that reads your Azure setup and tells you what's in it. Start with the word resource because everything else hangs on it. Anything you create in Azure counts as a resource, a virtual machine, a storage account, a database, a network, a website. If you built it and Azure keeps it running for you, resource graph can see it. You probably met Azure through the portal, the website where you click around to build and manage things. Resource graph doesn't replace that portal, and it isn't a separate app.

0:41 You have to go learn somewhere else. It's the engine running underneath it, and you've seen its work without ever knowing the name. The search bar at the top of the portal uses it, and so does the all resources view that lays out everything you own. The change history inside Azure policy, which shows what changed and when uses it to the word query. Sounds technical, so let's get the fear out of the way before it gets in the way. A query is a question. You type in a small structured language and Azure answers with a list or a number. You're not building an app and you're not writing a program. You're asking something like, how many virtual machines do I have? Then reading the answer that comes back, one more piece of vocabulary makes the rest of this click, and that's the subscription. A subscription is a container for your resources, usually tied to how you pay.

1:22 And a single organization often runs several of them. Resource graph can look across all of those containers in one question, which is exactly where a normal portal view gives up that cross subscription reach is the part worth remembering, because a regular portal page is tied to whatever scope you happen to have open a resource graph query isn't tied that way, so one question can cover the whole estate you're allowed to see, no matter how it's split up. For someone new to Azure, that's the gap this tool closes. You don't have to know where something lives before you ask about it. The surprising part is that the service is already on and it costs nothing extra to use. Nobody had to install it or switch it on for you. It ships with Azure and sits there until you ask it something. Why The normal way of asking. Azure breaks down to see why resource graph exists.

2:03 You have to meet the service it extends and that service is Azure Resource Manager. Resource manager is the front door for managing everything in Azure, the layer that accepts your commands and keeps track of what you own every time you create or change a resource. Resource manager is part of the story. Resource manager handles the basics well. Ask it for resources. Name its ID, its type, the resource group it lives in, the subscription it belongs to, or its location, and the answer comes back right away. What it can't do is hand you the detailed settings inside a resource without you asking one resource at a time. Those deeper details sit with the individual resource providers, and reaching them means calling each provider one resource after another. Picture the math on that ten virtual machines is a short afternoon of clicking.

2:44 A thousand resources spread across a dozen subscriptions is a different problem entirely, and doing it by hand stops being realistic. Somewhere in the middle, you either click for a very long time, or you write a script that calls Azure over and over. Then wait while it works through the list. The script Root has its own cost. Someone has to write it, test it, and rerun it. Every time the environment changes and it tends to break the moment a resource provider shifts something underneath it. That's a real skill, and it's a lot of work for a question you wanted answered. Once resource graph takes the same problem and answers it a different way, instead of asking about one resource at a time, you ask one question and let the service do the searching. Under the hood resource graph keeps its own index of resource data, so a single query can filter, group and sort across many subscriptions at once.

3:26 That index is why the answers come back quickly, and it's the reason the tool exists. The portal gives you the feeling that you can already see everything, and with a handful of resources, that feeling is close enough to true. Once your environment grows, the gaps start to show because the portal shows you what fits on a screen rather than everything that matches a question. Filters and columns help, but you're still looking at one slice at a time. There's one honest caveat here resource graph data isn't instant, as Azure Resource Manager tells it about changes, and it also runs regular full scans to catch anything missed. So a resource you just created can take a moment to appear. Hold on to one more thing before we leave this section. When the data does come back, there's a ceiling on how much of it arrives at once, and that ceiling trips up more beginners than anything else in this service.

4:07 We'll get to it in detail later, but keep it in the back of your mind. The query language explained without the scary parts. Every question you ask resource graph is written in a language called Kusto query language or Kql for short. If you've touched Azure Data Explorer or Log Analytics, it will look familiar because they use the same language. You don't need all of it. Resource graph supports a slice of KCL, and that slice is small enough to learn in a single sitting. A Kql query reads like a recipe, and the pipe character is what separates the steps. You start with a table of data, then you pipe it into one instruction after another, and each instruction narrows or reshapes what you have. Read it top to bottom and it almost sounds like plain English, which is the whole point. Take the simplest useful query in the documentation, which is the word resources followed by a pipe, and then summarize count.

4:53 Spoken out loud, that means take everything in the resources table and give me a count. What comes back is a single number, and that number is how many resources you have. It's a good first query because it tells you the size of your own environment in one line. Once counting works, filtering is the next step. Add a where clause that says the type equals key vaults and the same query counts only your key vaults. Change the filter to virtual machines and your counting those instead. The shape stays the same and only the condition changes, which is why people pick this up faster than they expect. Two more instructions are worth knowing by name project picks which columns you want to see, so you can ask for just the name, the type, and the location instead of everything. Order by sorts. The results. So a list of resources comes back alphabetized. Instead of in a random pile.

5:34 Together they turn a raw dump into a tidy table you can scan. There's one instruction that saves a lot of typing, and it's called extend. Extend creates a temporary column you name yourself. So you can pull a nested value out of a resource and give it a short label to reuse later in the same query. It's the difference between repeating a long path five times and writing it once. One small trap is worth flagging early. The match operator that looks like an equal sign with a tilde beside it ignores uppercase and lowercase, so a filter for key vaults matches no matter how you type it. Property names are stricter than that. Spell a property with the wrong capitalization and the query doesn't error out, it just returns blank values instead, which sends people hunting for a bug that isn't their query. Start from a table, and the default one is simply called resources, which holds most of what you'll want.

6:17 Other tables exist for specific areas, and the ones worth remembering cover policy, security, and the containers that hold your stuff, meaning management groups, subscriptions, and resource groups. You'll reach for those when a plain resource question isn't enough. The nice part is that Kql isn't unique to this service. Learn it here, and the same language shows up in Log Analytics and Azure Data Explorer, so the effort carries over instead of starting from zero next time. That's really all the language you need to get moving. The next question is where you actually type it, and that part is friendlier than you'd guess your first query. In Resource Graph Explorer. You don't need to install anything to try this as your resource graph explorer is a page inside the Azure portal, and you reach it by searching for Resource Graph in the top search box.

6:57 Open it and you get a query window on the right and a list of tables and resource types on the left. That left hand list is called the schema browser, and it works like training wheels. Select a table and its name drops into your query. Select a resource type and it adds a filter for you and select a property and it adds the next line. You still write the query, but the browser hands you the pieces so you don't have to memorize the names. One control at the top is easy to miss and worth finding. The directory picker sets the scope so you can point a query at a single subscription, a management group, or the whole directory. Getting that wrong is the most common reason a query comes back smaller than expected. Running a query comes down to three habits. Type or paste your query into the window. Select Run Query and then read the results tab. The messages tab beside it is easy to overlook and worth opening because it tells you how many results came back and how long the query took.

7:44 A count query can also be shown as a bar chart or a donut chart, so a boring list of numbers turns into something you can read at a glance. You can pin that chart to an Azure dashboard, and it refreshes every time the dashboard loads. Your most important numbers end up on one screen live without you running anything by hand. When you need the raw data somewhere else, the toolbar has a download as CSV option that exports whatever the query returned. That's handy for a spreadsheet, a report, or a quick inventory you want to pass to someone else. If a query earns a permanent spot in your routine, you can save it and reopen it later instead of rebuilding it from scratch. The explorer is the friendliest door into resource graph, but it isn't the only one. The same queries run from the Azure command line from PowerShell and through the rest API, which is how you automate them.

8:25 There's also a power BI connector, so a query can feed a report directly, and that connector can pull in every record when your results run past a thousand. That covers how you ask the question. The part that surprises people is what those questions end up finding, what people actually use it for. The first thing almost everyone does is take inventory, and it's the easiest win in the tool. One query counts every resource you own across every subscription you can see, and the answer arrives in a second or two. Change the query to list resources sorted by name and you get an actual list. You can scan instead of a number. From there, the queries get more specific and more useful. One of the documentations examples finds every network security group that isn't attached to anything, which is the kind of question that normally eats a whole afternoon.

9:07 An unattached security group is money spent on nothing and a loose end in your setup, so finding all of them at once feels like a win. Public IP addresses are another common one, because each of those addresses is a door into your network. A single query lists them along with their addresses, so you can spot the ones you set up for a test and then forgot about. That's the sort of cleanup that used to take hours and now takes one line, and the same pattern keeps showing up in every corner of Azure. Tags are another area where this pays off. You can list every tag and its values, or find every resource carrying a specific tag, which is how you catch the resources someone forgot to label. Tagging is what makes cost reporting work in Azure, so a query that surfaces untagged resources can save real money. Grouping is where resource graph starts to feel like a dashboard tool rather than a search box.

9:50 Ask it to count your virtual machines by operating system and you get a quick picture of your estate. No spreadsheet required. Ask it to break resources down by subscription and you see where everything actually lives. That shift from hunting, for one thing, to seeing the shape of everything, is the moment the tool clicks for most people. Compliance and governance questions sit at the deeper end and they matter more. As your environment grows, you can query policy assignments to see which rules are applied, and role assignments to see who can do what. The service also keeps the last fourteen days of resource configuration changes. So when something moves and nobody admits to moving it, there's a record of which property changed and when. None of these are exotic admin tasks. They're the questions any team eventually asks, usually with a spreadsheet and a lot of patience.

10:32 Resource graph turns each one into a sentence you type. And that's the real promise of the tool for a beginner. It's also the kind of work that shows up under governance and cloud operations, so the habit is worth building early. The limits. Nobody warns you about here's the ceiling we flagged earlier, and it's the part that confuses people most. By default, a resource graph query returns at most one thousand records. That isn't a bug and it isn't your query failing. It's a guardrail the service sets to protect you from accidentally pulling down a giant result, and the setting that controls it tops out at one thousand as well. If you need more than one thousand records, you page through them the service hands back a token that marks where you stopped and your next request picks up from there. So a large answer arrives in chunks. It works well, but it's also why a beginner sometimes sees a partial list and assumes data is missing.

11:15 The CSV export has its own ceiling. Downloading results from the explorer stops at fifty five thousand rows, and that limit is a platform rule that a support ticket can't raise. For most people, that's plenty, but it's worth knowing before you plan around a giant export. There's also a clock on every query resource graph times out after 30s matching the timeout used by Azure Resource Manager. If you hit it, the fix is almost always to narrow the scope, either by querying fewer subscriptions or by shrinking the part of the query that runs first. The structure of a query has limits too. You can use at most three join or union operations combined in one query, and at most three operations that expand a list of values into separate rows. Those sound obscure until you write something ambitious and get an error, and then they matter a lot. Scope carries a limit as well. Send a query to a management group, and the results come from the first ten thousand subscriptions in or under that group, which is more than enough for most organizations and a real edge for the largest ones.

12:05 One more limit lives outside the query itself. Resource graph is a free service, so it throttles how often one person can ask. Microsoft's own documentation gives an example of fifteen queries within a five second window, and it notes that the real number can change when you get close. The response tells you how much of your quota is left, which is your cue to slow down. Throttling can also come from a second place, and it helps to know the difference. Azure Resource Manager enforces its own limits on top of the resource graph ones, and those limits are hard limits you can't raise. The error message tells you which layer pushed back, which spares you a lot of guessing. Permissions are the last piece, and they're simple. You see only what you have read access to, and nothing comes back without it. That's why the limit story matters when a query returns fewer results than expected.

12:48 The usual cause is the one thousand cap a scope you didn't mean to set, or a resource you don't have permission to read. It's rarely a broken query. A quick recap and one question for you. So here's the short version to carry with you. Azure Resource Graph is a free service that lets you ask one question across all your Azure resources at once, and it's already powering parts of the portal you use today. It speaks a small slice of kusto. It lives in a portal page called Resource Graph Explorer, and it answers the questions that clicking can't remember the one thousand record default and the thirty second clock, and you'll sidestep the confusion most beginners run into. Now here's the question I want to leave you with. If you could ask Azure one thing about everything you own across every subscription, what would you ask it first? That question is usually the moment people realize how little they know about their own environment.

13:32 And it's the best reason to open Resource Graph Explorer this week. If this made Azure Resource Graph feel less intimidating, subscribe to M365 FM to master the tools and the mindset shaping the future of work. Then open the explorer, run one count query and see what your own environment has been hiding.