How to Make a GCP Architecture Diagram: A Tutorial

Google Cloud organizes resources around projects, and its networking has a quirk that surprises people coming from AWS: a VPC in GCP is a global resource, with subnets that are regional rather than zonal. That single difference reshapes how a GCP diagram should look, because a single VPC can span multiple regions natively. Getting these organizing choices right is what makes a GCP diagram accurate rather than an AWS diagram with the icons swapped.

This tutorial builds a GCP architecture diagram for a typical web workload from the boundaries inward. You can draw it in Atlas Diagram Studio at /diagrams, which provides GCP, AWS, Azure, and Kubernetes stencils and more than 1000 shapes, and the network and cloud diagram tool at /diagram-tools/network-diagram gives you the VPC and subnet containers so the network layer is correct before you place a service. The method parallels the AWS and Azure tutorials but respects Google Cloud's own model.

GCP boundaries: projects, VPCs, and regional subnets

Start with the project, which is GCP's fundamental organizing and billing boundary - resources belong to a project, and IAM and quotas are scoped there. Draw a project box and place the resources it contains inside. Then draw the VPC, and here is the key difference: a GCP VPC is global, so a single VPC box can legitimately contain subnets in different regions. Draw the regions as boxes inside the VPC, and put the regional subnets inside their region.

Because subnets in GCP are regional and automatically span the zones within that region, you do not draw a separate subnet per zone the way you might mentally model AWS. Zones still matter for placing zonal resources like individual VM instances or a zonal GKE node, so show zones inside a region when the design's fault tolerance depends on them. Firewall rules in GCP are VPC-level and applied by tags or service accounts rather than attached to subnets, which is a notation difference worth keeping in mind when you show what governs traffic.

Placing Google Cloud services

With projects, the global VPC, regions, and regional subnets drawn, add the services for a standard web application.

• Cloud Load Balancing at the edge as the global, internet-facing entry point, since GCP's HTTP(S) load balancer is itself a global resource.
• Cloud CDN attached to the load balancer for content delivery, shown at the edge in front of your backends.
• GKE drawn as a cluster boundary with its node pools inside a region, containing the pods and services when the workload runs on Kubernetes.
• Cloud Run as a managed serverless container platform, placed as a regional service when you want containers without managing a cluster.
• Cloud SQL or Firestore as the data tier, shown with private service access into the VPC when locked to internal traffic.
• Cloud Storage as a bucket outside the subnet structure, connected to the tier that uses it, since buckets are a global or multi-region service.
• Cloud Functions for event-driven compute, placed where they apply, connected to the events or services that trigger them.

Notation and request flow in GCP

Use the official Google Cloud icon set from the GCP stencil and label each service with its specific role. Then trace the request flow along one path: a user reaches Cloud Load Balancing, is served through Cloud CDN, hits a GKE ingress or a Cloud Run service, which queries Cloud SQL and reads from a Cloud Storage bucket. As always, a single clearly drawn path communicates far better than a mesh of every connection, and directed, labeled arrows tell the reader what protocol is used and which way data flows.

Because a GCP VPC is global, take care to show which resources are regional and which are global - the load balancer and Cloud Storage are global, while GKE node pools and Cloud SQL instances are regional or zonal. Making that distinction visible prevents a reader from assuming a regional resource is globally redundant or vice versa. The overall discipline is the same as any cloud diagram, covered in the system architecture diagram guide at /guides/system-architecture-diagram-guide, but the global-VPC model is Google Cloud's signature.

Keeping the GCP diagram accurate

The GCP-specific inaccuracies to watch for come from the global VPC and the serverless services. Drawing a separate VPC per region when GCP uses one global VPC misrepresents the network. Showing Cloud Run or Cloud Functions inside a subnet, when they are managed services reached over their own endpoints unless you configure VPC connectors, tells the wrong story about how traffic reaches them. Both are easy to get wrong if you carry an AWS mental model into a GCP diagram.

Keep the diagram editable in Atlas Diagram Studio at /diagrams so it can be corrected as the architecture evolves, assign it an owner, and update it when the VPC, regions, or service topology change. Real-time collaboration lets the team that runs the GCP environment fix the diagram directly. For teams choosing between providers, the guide on diagramming AWS versus Azure versus GCP compares the models side by side, and the AI diagram generator at /diagram-tools/ai-diagram-generator can sketch a first GCP layout you then verify.