How to Create an Azure Architecture Diagram That Ages Well

How to create an Azure architecture diagram, the short version: decide who the diagram is for, draw the boundaries first (subscriptions, resource groups, regions, VNets), place the shared network services in a hub and workloads in spokes, then add the request and data flows with labels. Use Microsoft's official icons with the product name next to each one, and finish by reviewing the diagram against the Azure Well-Architected pillars.

That's the whole recipe. The rest of this post is the part that makes the difference between a diagram people trust and the one in the wiki labelled "v3-final-FINAL" that nobody has touched since 2023.

Azure diagrams have a specific failure mode. Teams copy the icons, drop a few App Services and a SQL database on a canvas, connect everything with arrows, and call it done. Then the first reviewer asks which subscription it's in, and the diagram goes quiet. Let's build one that answers those questions on its own.

What an Azure architecture diagram should show

Before you open any tool, pick a level. One diagram that tries to show the tenant, the network and the inside of a single workload ends up showing none of them clearly. A useful set looks like this:

Most teams need the second and third levels the most, because that's where incidents and audit questions land. If you only have time for one, draw the workload view and include enough of the network to show how traffic gets in and out.

→ Describe your system and get a first workload view with Architect AI

How to create an Azure architecture diagram in six steps

Step 1: Write down the audience and the question

Put a one-line caption on the diagram: who it's for and what it explains. "For the security review: inbound and outbound paths for the payments API" instantly tells a reviewer what to look at and what's intentionally missing.

Step 2: Draw the boundaries before the services

Azure has a resource hierarchy, and it's the first thing reviewers mentally reconstruct: management groups contain subscriptions, subscriptions contain resource groups, and resource groups contain resources. Draw the boundaries that matter for this audience, usually subscriptions and the region, with availability zones shown where the design actually uses them.

Boundaries matter because they carry policy, billing and access. A database "next to" an App Service on the canvas means nothing; a database inside the production subscription's data resource group, behind a private endpoint, means a lot.

Step 3: Lay out the network with real subnets

This is the bit most Azure diagrams skip, and the bit network teams care about most. For anything beyond a toy app, the common reference shape is hub-spoke. Microsoft's hub-spoke reference architecture describes it like this:

• The hub virtual network holds shared services, such as Azure Firewall, the VPN or ExpressRoute gateway, Azure Bastion, DNS and monitoring. It's a regional resource, so you use one hub per region.
• Each spoke virtual network isolates a workload or environment and is peered to a single hub in the same region. Spokes can live in different subscriptions.
• Peering is non-transitive. Spokes can't reach each other through the hub by default. If they need to talk, you route through the firewall with user-defined routes, connect them directly, or expose specific resources with Private Link.

Show address ranges on every VNet and subnet. Overlapping CIDRs across Azure and on-prem are a classic migration blocker, and a diagram that shows the ranges makes that problem visible before it becomes a ticket. A quick sanity check with a CIDR subnet calculator saves a lot of re-IPing later.

Step 4: Place the workload services and the flows

Now drop in the services, inside the subnet or boundary where they actually live. Then draw the flows that matter, and only those:

• The user request path, from the internet entry point to the data store
• The admin path (for example, Bastion into a VM with no public IP)
• The egress path (in hub-spoke, typically out through the firewall)
• Async flows, such as queue or event processing, drawn with a different line style

Number the steps on the main request path. "1. Client hits the gateway, 2. Gateway forwards to the app, 3. App reads from the database" is far easier to review than a spaghetti of unlabeled arrows.

Step 5: Mark identity, data and trust boundaries

Network diagrams lie by omission when they skip identity. Annotate which component authenticates users, which workloads use managed identities, where secrets live, and which data stores hold sensitive data. Draw a dashed trust boundary wherever traffic crosses from a less trusted zone to a more trusted one, because that's exactly where a threat model will start.

Step 6: Review it against the Well-Architected pillars

The Azure Well-Architected Framework has five pillars: Reliability, Security, Cost Optimization, Operational Excellence and Performance Efficiency. Walk the diagram once per pillar. If you can't answer a pillar's basic question from the picture, such as "what happens when a zone fails?" or "where does the money go?", the diagram is missing something.

→ Turn the finished diagram into a cost breakdown with Cost Estimator

Azure architecture diagram example: a hub-spoke web app

Here's a worked example you can sketch in ten minutes. A customer-facing web app in one region, connected to on-prem, with shared network services in a hub.

The subnet rules in that table come straight from Microsoft's hub-spoke reference architecture. They're also why it pays to draw subnets by name: a diagram that shows GatewaySubnet as a /28 is a design bug you can catch in review instead of during deployment.

The same topology in Terraform

If the network already exists as code, your diagram should match it. Here's the hub side of the example, plus the peering pair, using the azurerm provider:

resource "azurerm_virtual_network" "hub" {
  name                = "vnet-hub-weu"
  location            = azurerm_resource_group.network.location
  resource_group_name = azurerm_resource_group.network.name
  address_space       = ["10.0.0.0/22"]
}

resource "azurerm_subnet" "firewall" {
  name                 = "AzureFirewallSubnet" # exact name required
  resource_group_name  = azurerm_resource_group.network.name
  virtual_network_name = azurerm_virtual_network.hub.name
  address_prefixes     = ["10.0.0.0/26"]
}

resource "azurerm_subnet" "gateway" {
  name                 = "GatewaySubnet" # exact name required
  resource_group_name  = azurerm_resource_group.network.name
  virtual_network_name = azurerm_virtual_network.hub.name
  address_prefixes     = ["10.0.0.64/26"]
}

resource "azurerm_virtual_network_peering" "hub_to_spoke" {
  name                      = "peer-hub-to-spoke-app"
  resource_group_name       = azurerm_resource_group.network.name
  virtual_network_name      = azurerm_virtual_network.hub.name
  remote_virtual_network_id = azurerm_virtual_network.spoke_app.id
  allow_forwarded_traffic   = true
  allow_gateway_transit     = true
}

resource "azurerm_virtual_network_peering" "spoke_to_hub" {
  name                      = "peer-spoke-app-to-hub"
  resource_group_name       = azurerm_resource_group.app.name
  virtual_network_name      = azurerm_virtual_network.spoke_app.name
  remote_virtual_network_id = azurerm_virtual_network.hub.id
  allow_forwarded_traffic   = true
  use_remote_gateways       = true # needs a gateway deployed in the hub
}

Peering is configured on both sides, which is why the diagram should show it as a two-way link with the settings labelled, not a single anonymous line. One gotcha worth a note on the canvas: use_remote_gateways only works once the hub actually has a virtual network gateway, so the spoke-side peering depends on the gateway deployment.

For a deeper look at hub and spoke trade-offs, the Azure hub and spoke networks explainer goes further than we can here.

→ Browse every Azure architecture guide, from AKS to landing zones

Azure architecture icons: the rules most diagrams break

Microsoft publishes the official Azure architecture icons as a zip of SVG files on Microsoft Learn. A few things people miss:

• You accept terms before downloading. The icons are licensed for architecture diagrams, training materials and documentation, not for representing your own product.
• There are no Visio stencils. Microsoft says it has no plans to ship them as stencils, but the SVGs drag into most diagram tools, Visio included.
• Label every icon. Microsoft recommends putting the product name close to the icon. Half your readers can't tell Event Grid from Event Hubs by glyph alone, and that's fine.
• Don't edit them. No cropping, flipping, rotating or reshaping. Use them as they appear in Azure.
• Refresh your set. The icon set gets regular additions, so an old zip on someone's laptop may be missing newer services.

Lowkey the biggest upgrade most Azure diagrams need isn't better icons, it's fewer of them. If an icon doesn't change the answer to the diagram's question, cut it.

→ Sketch the boundaries, then let Architect AI fill in the services

Azure architecture diagram generator online: when to stop dragging boxes

Drag-and-drop tools are fine for a one-off. draw.io is free and handles the official SVG icons well, and plenty of teams live happily in Visio or Lucidchart. If you're weighing those, our draw.io comparison for cloud architecture lays out the trade-offs honestly.

The pain starts when the diagram has to do more than look right. Every review cycle, someone re-draws arrows after a subnet change, re-checks costs in a separate calculator, and re-explains trust boundaries in a separate threat-model doc. That's three artefacts drifting apart.

An online Azure architecture diagram generator flips the order. With Architecto's Architect AI, you describe the system in plain English, for example "regional hub-spoke on Azure, web app and API in a spoke, managed database behind a private endpoint, egress through Azure Firewall", and get a structured topology on an editable canvas. From there the same architecture can flow into:

• Cost Estimator for provider-aware cost breakdowns and scenario comparisons, with Azure among the supported providers
• Threat Analyzer for STRIDE-driven threat modeling on the actual topology
• Documentation and share links, so the review happens on the diagram rather than on a screenshot of it

Treat any generated output as a proposal, not gospel. You still check the subnet sizes, the peering settings and the egress path against the rules above. The win is skipping the blank canvas and keeping review work attached to the design.

→ Generate your first Azure architecture from a prompt

Azure architecture diagram review checklist

Run this before you share the diagram with anyone outside your team. It doubles as a list of Azure architecture diagram best practices.

• Caption states the audience and the one question the diagram answers
• Subscription, resource group and region boundaries are drawn
• Availability zones are shown where the design relies on them
• Every VNet and subnet shows its address range, with no overlaps with on-prem
• Reserved subnets use their exact names (AzureFirewallSubnet, GatewaySubnet, AzureBastionSubnet)
• Peerings are shown, and any spoke-to-spoke path is explicit, not assumed
• Internet entry points, the admin path and the egress path are all visible
• Main request path is numbered; async flows use a different line style
• Identity, managed identities and secret storage are annotated
• Trust boundaries are drawn where traffic crosses into a more trusted zone
• Every icon is an unmodified official icon with the product name beside it
• Each Well-Architected pillar has at least one answer visible on the diagram

If the trust-boundary items feel thin, run the design through a STRIDE threat checklist next.

→ Build a reusable version of this list with the Architecture Review Checklist Builder

Key takeaways

• Start with the audience and the question, not the icon palette.
• Boundaries first: subscriptions, resource groups, regions, VNets, subnets with CIDRs.
• Hub-spoke is the common Azure network shape; peering is non-transitive, so draw spoke-to-spoke paths explicitly.
• Use official Azure icons unmodified, with product names next to them.
• Review every diagram once per Well-Architected pillar.
• If the network is in Terraform, the diagram should match the code. For the AWS version of this workflow, see our AWS architecture diagram guide.

→ Skip the blank canvas: start your Azure design with Architect AI

FAQ

What should an Azure architecture diagram include?

At minimum: the subscription and resource group boundaries, the region and availability zone layout, the virtual networks and subnets with their address ranges, the entry points from the internet and from on-premises, the main request and data flows, and where identity and secrets are handled. Label every icon with the product name, and state the one question the diagram is meant to answer.

Where do I get official Azure architecture icons?

Microsoft publishes the Azure architecture icon set as a downloadable zip of SVG files on Microsoft Learn. You must accept the terms of use before downloading, and the icons are licensed for architecture diagrams, training materials and documentation. Microsoft does not plan to ship them as Visio stencils, but the SVGs can be imported into most diagramming tools, including Visio.

Is there a free Azure architecture diagram generator online?

Yes, there are several routes. General diagram tools such as draw.io let you build Azure diagrams for free with the official SVG icons, and AI-assisted tools can generate a first draft from a text prompt. Architecto's Architect AI turns a natural-language description into an editable Azure architecture, and you can start on the free plan.

How do you draw a hub-spoke network in Azure?

Draw one hub virtual network per region containing shared services such as Azure Firewall, the VPN or ExpressRoute gateway and Azure Bastion, then draw each workload in its own spoke virtual network peered to that hub. Show the reserved subnets by their exact names, label address ranges, and make it clear that peering is non-transitive, so spoke-to-spoke traffic needs a route through the firewall or a direct connection.

→ Threat-model your Azure topology with Threat Analyzer

Start your Azure diagram the fast way

You now know how to create an Azure architecture diagram that survives a review: clear scope, real boundaries, honest network paths, labelled icons and a pillar-by-pillar check. The slow part is the blank canvas and keeping cost and security work in sync with the picture.

Describe your Azure system once, get an editable architecture, and keep the cost and threat reviews attached to the same design.

→ Start free and generate your first Azure architecture