Diagramming AWS vs Azure vs GCP: How the Models Compare
The three big clouds organize resources differently, and a diagram that ignores those differences ends up subtly wrong. Knowing where the models diverge is what makes each diagram accurate.
AWS, Azure, and GCP solve the same problems, but they organize resources in different ways, and those differences show up directly in how you diagram each. The boundaries that carry meaning - how accounts and projects group things, how the virtual network works, whether a resource is global or regional - are not the same across the three, so a diagram drawn with an AWS mental model can be subtly wrong for Azure or GCP even when the icons are correct. Understanding where the models diverge is what lets you draw each cloud honestly instead of forcing all three into one template.
This guide compares the three on the dimensions that matter for diagramming: the organizing boundaries, the networking model, the compute and container services, and the global-versus-regional distinction. You can draw all three in Atlas Diagram Studio at /diagrams, which ships AWS, Azure, and GCP stencils side by side along with Kubernetes stencils and over 1000 shapes, and the network and cloud diagram tool at /diagram-tools/network-diagram provides the network containers for each. The provider-specific tutorials go deeper on each; this guide is about the comparison.
The organizing boundaries differ
The outermost boundaries in a diagram are where the three clouds diverge first. AWS organizes around accounts, often many accounts under an organization, with resources living in a Region inside an account. Azure adds two layers: a subscription as a billing and management boundary, and a resource group as a lifecycle and access-control boundary that holds resources deployed together - so an Azure diagram naturally shows resource-group boxes that have no direct AWS equivalent. GCP organizes around projects, the fundamental unit that owns resources and scopes IAM and billing.
These differences are not cosmetic, because the boundaries encode how the architecture is governed. An Azure diagram that omits resource groups hides how resources are managed together; a GCP diagram that ignores the project boundary loses the primary organizing unit; an AWS diagram that flattens multiple accounts into one misses a real isolation boundary. When you draw each cloud, use its own top-level boundaries rather than mapping everything onto AWS's account-and-Region model, because the grouping is part of the design in each case.
Networking: the biggest divergence
Networking is where the three models differ most, and it changes the shape of the diagram. These are the distinctions to keep straight when drawing each cloud.
- AWS: a VPC is regional, with subnets tied to a single Availability Zone, so multi-AZ redundancy means repeating resources per AZ in the diagram.
- Azure: a VNet is regional, divided into subnets, with network security groups attached to subnets or interfaces to filter traffic.
- GCP: a VPC is global, so one VPC box can span regions, and subnets are regional and automatically cover the zones within a region.
- AWS security groups act as stateful per-resource firewalls, while GCP firewall rules are VPC-level and applied by tags or service accounts.
- Load balancing differs: GCP's HTTP(S) load balancer is global, while AWS and Azure layer-7 load balancers are regional resources.
- Hybrid connectivity uses different primitives - Direct Connect on AWS, ExpressRoute on Azure, Cloud Interconnect on GCP - drawn at the on-premises boundary.
- Private access to managed services uses VPC endpoints on AWS, private endpoints on Azure, and private service access on GCP.
Compute and container services
The compute layer maps loosely across the three, but the mapping is imperfect and the diagram should reflect each cloud's actual services rather than a generic label. For virtual machines it is EC2 on AWS, Virtual Machines on Azure, and Compute Engine on GCP. For managed Kubernetes it is EKS, AKS, and GKE - all Kubernetes, so the cluster-and-node-pool representation is the same, but the surrounding managed integration differs. For serverless functions it is Lambda, Azure Functions, and Cloud Functions, and for serverless containers it is Fargate, Azure Container Apps, and Cloud Run.
The managed platform-as-a-service story diverges more. Azure's App Service is a distinctive managed web-app platform with no exact AWS or GCP twin, and each cloud's fully managed database offerings - DynamoDB, Cosmos DB, Firestore - have different data models that matter when you label them. The practical rule is to draw the real service by name and represent its actual nature - global or regional, cluster or serverless - rather than a generic "compute" box, because the specifics are what make the diagram informative. The three provider tutorials cover the details for each.
Drawing each cloud honestly
The through-line is that each cloud deserves a diagram drawn in its own vocabulary. Use the provider's official icon set so readers recognize the services, use the provider's real boundaries - accounts and Regions for AWS, subscriptions and resource groups for Azure, projects for GCP - and represent the global-versus-regional nature of each resource correctly, since that is where mental-model mistakes cluster. A diagram that gets the icons right but the boundaries wrong is still misleading, and boundaries are exactly where the three clouds differ.
Keep all of it editable in Atlas Diagram Studio at /diagrams, which lets you draw AWS, Azure, and GCP diagrams with the correct stencils in one place, useful when you are comparing designs or running more than one cloud. For teams genuinely spanning providers, the multi-cloud architecture diagram guide covers drawing more than one cloud in a single coherent picture, and the system architecture diagram guide at /guides/system-architecture-diagram-guide covers the leveled approach that applies regardless of provider. The AI diagram generator at /diagram-tools/ai-diagram-generator can rough out a layout for any of the three that you then correct against its real model.