How to Make an Azure Architecture Diagram: A Tutorial

Azure has its own way of organizing the world, and an Azure architecture diagram that borrows AWS habits ends up subtly wrong. Where AWS thinks in Regions, VPCs, and subnets, Azure adds subscriptions and resource groups as first-class organizing boundaries, and its networking primitive is the virtual network, or VNet, subdivided into subnets. A diagram that shows these boundaries correctly tells a reader not just what services run, but how they are grouped for billing, access control, and lifecycle - which in Azure is a large part of the design.

This tutorial walks through building an Azure diagram for a typical web workload, from the outer boundaries down to services and flows. You can draw it in Atlas Diagram Studio at /diagrams, which ships Azure, AWS, GCP, and Kubernetes stencils along with over 1000 shapes, and the network and cloud diagram tool at /diagram-tools/network-diagram provides the VNet and subnet containers so the network structure is right before you place a service. The approach mirrors the AWS tutorial but respects Azure's own grouping model.

Azure boundaries: subscriptions, resource groups, and VNets

Start with the outer boundaries, because in Azure they are more than cosmetic. A subscription is a billing and management boundary; a resource group is a lifecycle and access-control boundary that holds related resources you deploy, update, and delete together. Draw a resource group box and place the resources that share a lifecycle inside it - this immediately communicates how the architecture is managed, which is information an AWS-style diagram would not surface.

Inside that, draw the region and the virtual network. A VNet is Azure's isolated network boundary, analogous to an AWS VPC, and it is divided into subnets just as a VPC is. Split your subnets into those that hold internet-facing resources and those that hold internal ones, and if you use network security groups to control traffic, they attach to subnets or interfaces and are worth showing where access control is part of the story. With the resource group, region, VNet, and subnets drawn, every service you add lands in a boundary that means something.

Placing Azure services correctly

With the boundaries in place, add the Azure services for a standard web application into the right containers.

• Azure Front Door or Application Gateway at the edge as the internet-facing entry point, with the Application Gateway able to sit in its own subnet inside the VNet.
• App Service for a managed web app, or AKS if you run containers, placed to show whether it is VNet-integrated or accessed over its public endpoint.
• Azure Kubernetes Service drawn as a cluster boundary with its node pools inside, when the workload runs on Kubernetes rather than App Service.
• Azure SQL Database or Cosmos DB as the data tier, shown with a private endpoint into a subnet when access is locked to the VNet.
• Blob Storage as a managed storage account outside the subnet structure, connected to the tier that uses it, since it is a regional service.
• Azure Functions for event-driven compute, placed where they apply, with VNet integration shown only if the functions actually need it.
• Azure Load Balancer inside the VNet when you balance traffic across VMs or AKS nodes at layer 4, distinct from the layer-7 Application Gateway.

Notation, labels, and request flow

Use the official Azure icon set from the Azure stencil, keep the icons in their standard styling, and label each one with its specific role rather than just its service type. Then draw the request flow along one real path: a user reaches Azure Front Door, which routes to the Application Gateway, which forwards to App Service or an AKS ingress, which queries Azure SQL and reads from Blob Storage. Tracing a single path makes the diagram legible where drawing every possible connection makes it noise.

As with any cloud diagram, direction and labels on the arrows carry the meaning - a labeled, directed arrow tells the reader the protocol and which way data moves, while a bare line leaves them guessing. Show the resource group boundaries so it is clear which resources are managed together, and mark private endpoints where a service is reachable only inside the VNet, because that is a security fact worth making explicit. The general method is the same across providers, as the system architecture diagram guide at /guides/system-architecture-diagram-guide describes, but the grouping vocabulary is Azure's own.

Keeping the Azure diagram trustworthy

An Azure diagram earns trust by staying current and by being honest about the boundaries. The most common inaccuracies are showing a service as VNet-integrated when it is actually reached over a public endpoint, or omitting the resource-group grouping so a reader cannot tell what is deployed and managed together. Both change how someone reasons about security and operations, so they are worth getting right and updating when the design shifts.

Keep the diagram editable in Atlas Diagram Studio at /diagrams rather than freezing it as an exported image, and update it when the VNet topology, private endpoints, or resource-group layout change. Real-time collaboration lets the team that owns the Azure environment correct the diagram directly. If you compare providers, the guide on diagramming AWS versus Azure versus GCP covers how the boundary vocabularies differ, and the AI diagram generator at /diagram-tools/ai-diagram-generator can produce a first-draft Azure layout you then refine against reality.