Skip to main content
Back to Blog

Mapping Azure Network Topology Without Drawing It by Hand

StratoLens Team
NetworkingVisibilityAzure Resource Graph

The new engineer on your team asks a perfectly reasonable onboarding question: "Is there a network diagram?" There is. It's a Visio export on a SharePoint site, last touched three years and two acquisitions ago. Half the VNets on it no longer exist, and none of the VNets added since appear at all. Everyone knows this, so everyone quietly ignores the diagram and reads JSON instead.

The real topology isn't lost. Every peering, every subnet, every NSG association is recorded precisely in Azure Resource Manager. The problem is that nobody can see it whole, because it's scattered across hundreds of resource properties and, in most organizations, a dozen or more subscriptions.

That gap between "the data exists" and "anyone can picture it" is what makes connectivity troubleshooting slow, architecture reviews painful, and compliance documentation a quarterly scramble.

The Problem: Azure Records the Topology but Never Shows It

Azure stores network relationships as references inside individual resources. A peering is a property of a VNet. An NSG association is a property of a subnet. A private endpoint is a property of something else again. No single resource, and no single native view, owns the whole picture:

  • Relationships are buried in properties. The peering between vnet-hub and vnet-spoke-03 exists only as JSON inside each VNet's configuration.
  • The picture spans subscriptions. Hub-and-spoke designs almost guarantee that the hub lives in one subscription and the spokes in several others, so no per-subscription view is ever complete.
  • Network Watcher helps, but narrowly. Its topology view is useful for a single scope, but it doesn't give you one interactive map of the whole estate across subscriptions (verify the exact scoping for your Network Watcher version).
  • Diagrams rot. The moment someone exports a picture, the platform keeps changing underneath it.

Drawing the diagram was never the hard part. Keeping it true is. Topology isn't a drawing problem; it's a freshness problem.

Reading the Real Topology with Azure Resource Graph

Resource Graph can pull the relationships out of those buried properties across every subscription you can see. Start with VNets and their peerings:

resources
| where type =~ 'microsoft.network/virtualnetworks'
| mv-expand peering = properties.virtualNetworkPeerings
| project vnetName = name, resourceGroup, subscriptionId,
          peerVnet = tostring(peering.properties.remoteVirtualNetwork.id),
          peeringState = tostring(peering.properties.peeringState)

Then subnets, with their address prefixes and NSG associations:

resources
| where type =~ 'microsoft.network/virtualnetworks'
| mv-expand subnet = properties.subnets
| project vnetName = name, resourceGroup, subscriptionId,
          subnetName = tostring(subnet.name),
          addressPrefix = tostring(subnet.properties.addressPrefix),
          nsgId = tostring(subnet.properties.networkSecurityGroup.id)

Run these in Resource Graph Explorer (not Log Analytics; the tables are different) and you have an honest, current inventory of your network's edges. That's genuinely useful, and it beats the stale Visio on day one. But look at what you're holding:

  1. Rows, not a picture. An adjacency list of 200 peerings is accurate and unreadable. You still have to assemble the mental model yourself, or paste it into a diagramming tool by hand.
  2. "Can A reach B?" is still unanswered. Topology tells you what's connected, not what traffic actually flows. NSG rules, route tables, and firewalls sit between "peered" and "reachable," and none of them appear in these results.
  3. Assembly across subscriptions is on you. The query spans subscriptions, but turning peering IDs back into names, grouping by hub, and spotting the one disconnected spoke is manual work.
  4. It stales immediately. The output is a snapshot. Next sprint's new spoke VNet won't be on whatever diagram you build from it today.

How StratoLens Keeps the Map Current

StratoLens builds the diagram from the same underlying data, then does the parts the queries can't:

  • The picture draws itself. Interactive topology diagrams are generated automatically from each scan of your infrastructure: VNets, subnets, peering, NSG associations, and connected resources in one graph you can drag, zoom, and click through to resource details.
  • Route tracing answers the reachability question. You can simulate a packet's path across VNets, NSGs, firewalls, VPN Gateways, and VWAN to see whether A can actually reach B, and where traffic gets stopped, without sending real traffic.
  • It refreshes with every scan. New spoke VNet? It's on the next diagram with no manual maintenance.
  • History is kept. You can view the topology from any previous scan, which turns "did the network change before this outage?" into a comparison instead of a memory test.

The map never leaves the territory, either: StratoLens is deployed into your own Azure tenant, so your topology data stays inside your environment.

Retire the Visio, Keep the Queries

The Resource Graph queries above are worth keeping in your toolbox; they're the fastest honest answer to "what's peered to what" on any given day. What they can't be is a living diagram your whole team troubleshoots from. If you want the interactive map, the route tracing, and the history without maintaining any of it, take a look at Network Topology Visualization in StratoLens.

Start Your 28-Day Free Trial

Every feature unlocked. Deploys to your Azure tenant. No data leaves your tenant.

Available now on the Azure Marketplace.

Built for Azure infrastructure teams who need complete visibility across their entire estate.