How to create a GCP architecture diagram, the short version: start with one audience and one question, draw the project boundaries first, show the VPC as a global network with regional subnets inside it, then add the entry point, request flow, egress path and identity. Use the official Google Cloud icons with labels, and review the result against the Well-Architected pillars.
That sounds like every other cloud diagram guide. It isn't, because Google Cloud punishes copied mental models.
Most bad GCP diagrams are AWS diagrams with a Google colour palette: a big "VPC" box sitting inside a region, wrapped around a neat CIDR. On GCP, that picture is simply wrong. Fix the shapes first and the rest of the diagram gets much easier to review.
Why a GCP architecture diagram needs its own shape
Three things make Google Cloud different on a canvas. Get these right and reviewers stop asking basic questions.
| Concept | How GCP works | How to draw it |
|---|---|---|
| Project | The core organizing unit. You need one to use Google Cloud, and it holds your resources. | A labelled boundary around resources, with its environment in the name |
| VPC network | A global resource, along with its routes and firewall rules | A box that spans regions, not one nested inside a region |
| Subnet | A regional resource with its own IPv4 range | A box inside the VPC and inside its region, labelled with the CIDR |
| Shared VPC | A host project owns the network; service projects consume it | Two project boundaries with attachments drawn between them |
Two consequences catch people out. First, a VPC has no single network-wide CIDR you need to label. Ranges belong to subnets, and they don't have to form one contiguous block, though each range must be unique within the network. Second, one VPC can have subnets in several regions, so a multi-region app doesn't automatically mean two networks.
→ Describe your GCP system and get a first draft with Architect AI
How to create a GCP architecture diagram in six steps
Step 1: Pick the level and write the caption
One diagram can't show the org structure, the network and a single service's internals. Pick one, then caption it with the audience and the question: "For security review: every path into and out of the checkout service." A caption tells reviewers what's missing on purpose.
Step 2: Draw organization, folders and projects
The hierarchy runs organization, then folders, then projects, then resources. It's not just filing. Access and organization policies set high up are inherited downward, so a role granted on a folder applies to everything under it.
That's why project boundaries carry real meaning, and why this level belongs on most reviews. If you need the design decisions behind the structure, the GCP resource hierarchy explainer goes deeper. For a workload diagram, one folder and two or three projects is usually plenty.
Step 3: Draw the network the way GCP actually builds it
Draw the VPC across the regions it serves, then place subnets inside, each with region and CIDR. Google recommends custom mode VPC networks in production, since auto mode creates a subnet in each region whether you need one or not. Check for range overlaps with a CIDR subnet calculator before anyone peers anything.
Step 4: Show who owns the network
If several teams share one network, you're probably looking at Shared VPC, and this is where a diagram earns its keep. Per Google's Shared VPC docs:
- A project can't be both a host and a service project at the same time.
- Each service project attaches to a single host project, though an organization can have several hosts.
- Host and service projects must belong to the same organization, apart from temporary states during an org-to-org migration.
- You can share all of a host's subnets or only specific ones.
Billing is the bit worth annotating. Outbound traffic from an instance is billed to the project containing that instance, and load balancer costs go to the project containing its components. So Shared VPC doesn't quietly move your workload's network bill to the platform team. The Shared VPC explainer covers the design trade-offs.
Step 5: Add flows, identity and egress
Draw only the paths someone will ask about: the user request, service-to-database traffic, async flows in a different line style, and the outbound path. Number the main request path. Then annotate which service account each workload runs as and where secrets come from. On GCP, service accounts are the real trust boundary more often than the subnet is, and an arrow without an identity is a vibe, not a design.
Step 6: Walk the pillars
The Google Cloud Well-Architected Framework has six pillars: Operational excellence; Security, privacy, and compliance; Reliability; Cost optimization; Performance optimization; and Sustainability. Ask one hard question per pillar. If the diagram can't answer "what happens when this region is down?", you've found the next thing to draw.
→ Get a cost breakdown from the finished diagram with Cost Estimator
GCP architecture diagram example: Cloud Run on Shared VPC
Here's a realistic example: an HTTPS API on Cloud Run, a private Cloud SQL database, and a platform team that owns the network. Sketch it in about ten minutes.
| Boundary | Component | Notes for the diagram |
|---|---|---|
Host project net-host-prod | VPC vpc-shared-prod (custom mode) | Draw it spanning regions, even if only one is in use today |
| Host project | Subnet subnet-app-usc1, us-central1, 10.10.0.0/24 | Direct VPC egress needs /26 or larger |
| Host project | Cloud NAT in us-central1 | Regional gateway. Outbound only, no unsolicited inbound |
Service project checkout-prod | Global external Application Load Balancer | Entry point. Cloud Armor attaches here, with some serverless limitations |
| Service project | Serverless NEG in us-central1 | Must share a project and region with the Cloud Run service |
| Service project | Cloud Run checkout-api | Same region as the subnet; uses Direct VPC egress |
| Service project | Cloud SQL for PostgreSQL, private IP | Connect over the private IP on port 5432 |
| Service project | Secret Manager | Google recommends it for SQL credentials |
The numbered path: 1. Client hits the load balancer. 2. It forwards through the serverless NEG to Cloud Run. 3. Cloud Run reaches Cloud SQL through the shared subnet. 4. Anything leaving for the internet, if routed via the VPC, goes out through Cloud NAT.
A few notes that belong on the canvas, because they all change the design:
- Health checks: serverless backends don't support them, so don't draw a health check there.
- IP sizing: Cloud Run uses about twice as many IP addresses as container instances at steady state, so size the subnet for peak scale, not average.
- Region lock: a serverless NEG only points at resources in its own region. A second region means a second NEG, and a global backend service can hold one per region.
- Private connectivity: Google now recommends Private Service Connect over private services access for Cloud SQL, partly because private services access only reaches one VPC network by default. Label which one you chose.
- Cold starts: Cloud Run's docs flag longer cold starts when Direct VPC egress goes through Cloud NAT. Test it if latency matters.
The same network in Terraform
If the network exists as code, the diagram should match it. Here's the host side, using the google provider:
resource "google_compute_network" "shared" {
project = "net-host-prod"
name = "vpc-shared-prod"
auto_create_subnetworks = false # custom mode
}
resource "google_compute_subnetwork" "app_usc1" {
project = "net-host-prod"
name = "subnet-app-usc1"
region = "us-central1"
network = google_compute_network.shared.id
ip_cidr_range = "10.10.0.0/24"
}
resource "google_compute_shared_vpc_host_project" "host" {
project = "net-host-prod"
}
resource "google_compute_shared_vpc_service_project" "checkout" {
host_project = google_compute_shared_vpc_host_project.host.project
service_project = "checkout-prod"
}
resource "google_compute_subnetwork_iam_member" "run_agent" {
project = google_compute_subnetwork.app_usc1.project
region = google_compute_subnetwork.app_usc1.region
subnetwork = google_compute_subnetwork.app_usc1.name
role = "roles/compute.networkUser"
member = "serviceAccount:service-${var.checkout_project_number}@serverless-robot-prod.iam.gserviceaccount.com"
}That last resource is the one most diagrams miss. The Cloud Run service agent in the service project needs Compute Network User on the subnet (or the host project). Grant it at subnet level and it also needs Compute Network Viewer on the host project. That's an invisible dependency between two teams, so give it a label on the canvas.
Want to see how your own modules hang together first? Run them through the Terraform module visualizer.
→ Explore every GCP guide, from GKE platforms to regional resilience
Google Cloud architecture icons: get the official set
Google hosts its official product icon library for diagrams and technical documentation. Four things sit on that page:
- Core product icons: a ZIP of SVG and PNG files
- Product category icons: another ZIP, also SVG and PNG
- Legacy console icons: the older set, in its own ZIP
- Product icons overview: a PDF explaining the system, which changed in early 2025
Read the overview first, because older diagrams online still use the pre-2025 look. Then pick a lane. Mixing new and legacy icons on one canvas looks like three people drew it, which is usually exactly what happened.
Our opinion: labels matter more than glyphs. Write the product name under every icon. Lots of smart engineers can't name half the Google Cloud catalogue from a hexagon, and they shouldn't have to.
→ Check your finished diagram against STRIDE with the free threat checklist
Choosing a GCP architecture diagram tool with official icons
There's no single best option, it depends on what the diagram has to do after it's drawn.
| Option | Good for | Watch out for |
|---|---|---|
| draw.io | Free, flexible manual diagrams using the official SVGs | Layout and upkeep are all on you |
| Google's Architecture Diagramming Tool | Starting from Google reference architectures. Launched in 2022, built on Excalidraw | Check its current state; it's a drawing tool, not a review workflow |
| Diagram as code | Versioned diagrams next to your repo | Learning curve; review context lives elsewhere |
| Architect AI | A first draft from a plain-English description, then review on the same design | Treat output as a proposal and verify it against the rules above |
If you're leaning towards a general diagramming tool, our draw.io comparison for cloud architecture is a fair look at where it wins.
With Architect AI, you might write: "Shared VPC on GCP, Cloud Run API in a service project behind a global external load balancer, Cloud SQL on private IP, egress through Cloud NAT." You get a structured topology on an editable canvas. Then the same design can feed Threat Analyzer for STRIDE-based threat modeling and Cost Estimator, which lists GCP among its providers. Once the design is live, Drift Detector helps you spot where deployed reality has wandered off from the plan.
You still own the correctness. The win is lowkey simple: no blank canvas, and fewer disconnected artefacts.
→ Generate your first GCP architecture from a prompt
GCP architecture diagram best practices checklist
Run this before the diagram leaves your team:
- Caption names the audience and the one question being answered
- Folders and projects are drawn, with environments obvious from the labels
- VPC spans regions; it isn't nested inside one
- Every subnet shows its region and CIDR
- Shared VPC host and service projects are clearly separated
- Network ownership is noted (who runs subnets, who runs firewall rules)
- Internet entry point and egress path are both visible
- Main request path is numbered; async flows use a different line style
- Each workload shows its service account, and secret storage is marked
- Private connectivity for managed databases is labelled
- Icons come from one consistent official set, with product names beside them
- Each Well-Architected pillar has a visible answer or a named open question
Want this as a repeatable review? Save yourself the copy-paste.
→ Build your own version with the Architecture Review Checklist Builder
Key takeaways
- Draw for one audience and one question.
- Projects are the first boundary on GCP, and policies inherit down the hierarchy.
- VPCs are global, subnets are regional, and CIDRs belong to subnets.
- Shared VPC needs host, service and ownership shown explicitly.
- Serverless paths have GCP-specific rules: same-region NEGs, no health checks, and service agent IAM on shared subnets.
- Use official icons from one set, always labelled.
Working across clouds? Compare this with our guides on creating an Azure architecture diagram and designing an AWS architecture diagram.
→ Skip the blank canvas and draft your GCP design with Architect AI
FAQ
What should a GCP architecture diagram include?
At minimum: the organization, folder and project boundaries that matter to the audience, the VPC networks with their regional subnets and CIDR ranges, the internet entry point and egress path, the main request and data flows, and where service accounts and secrets are used. If you use Shared VPC, show which project hosts the network and which projects consume it.
Where do I get official Google Cloud architecture icons?
Google publishes them at cloud.google.com/icons. The page offers ZIP downloads of core product icons and product category icons in SVG and PNG, a separate legacy icon set, and a PDF overview of the icon system that was updated in early 2025.
Is there a free GCP architecture diagram tool?
Yes. draw.io is free and can use the official SVG icons, and Google launched its own browser-based Architecture Diagramming Tool in 2022. If you want a first draft from a text description, Architecto's Architect AI generates an editable architecture with GCP support.
How do you show Shared VPC in an architecture diagram?
Draw the host project as the owner of the VPC network and subnets, then draw each service project separately with its workloads attached to the shared subnets. Label the subnet region and CIDR, and note who administers the network, because a service project can attach to only one host project and the two must normally sit in the same organization.
→ Threat-model your GCP topology with Threat Analyzer
Ship the GCP diagram people actually use
You now know how to create a GCP architecture diagram that respects how Google Cloud really works: real project boundaries, a global VPC, regional subnets, visible ownership and honest network paths.
The slow part was never the icons. It's the blank canvas, then keeping cost and security reviews in step with the picture. Describe your system once, get an editable architecture, and keep the reviews attached to the design.