Google Cloud Networking: Enterprise Design Guide

1. Your Network Gets Complicated Before You Notice

Imagine six months into a Google Cloud migration. Twelve application teams are moving at different speeds. Security wants central firewall control. Finance wants clean billing. Some apps must stay private, others face the internet, a few still depend on the data center, GKE clusters are multiplying, and three teams have just discovered they reused the same IP ranges.

That is usually when networking stops feeling like setup work and starts feeling like architecture.

The difficult question is no longer “How do I create a VPC?” It is “How do we connect all of this without creating a network nobody understands a year from now?”

That is the question this guide will answer.

Start by documenting network boundaries, ownership, and traffic flows. Use those requirements to choose the appropriate connectivity and security controls.

2. Understand Global VPCs and Regional Subnets

There is one Google Cloud idea you should understand before everything else:

A Google Cloud VPC is global. Its subnets are regional.

This changes how you think about regions. Engineers coming from traditional data centers — or from cloud designs where networks are usually treated region by region — often assume each region needs its own network. In Google Cloud, it usually does not.

One VPC can stretch across regions. A VM in asia-south1, a GKE cluster in us-central1, and a Cloud Run workload in europe-west1 can all belong to the same VPC. You do not create VPC peering just because the workloads are in different regions.

The regional part is the subnet. A subnet belongs to one region and provides addresses to resources there. The VPC around those subnets is the global routing and policy boundary.

So multi-region does not automatically mean multi-VPC. A Shared VPC can span several regions with different subnets in each one.

Google Cloud also uses a software-defined network rather than a collection of physical network appliances you manage. That is why familiar ideas such as VLAN-based security zones do not map neatly onto Google Cloud.

And even if your first rollout is IPv4-only, leave room for IPv6. The source article notes support for IPv4, dual-stack, and IPv6-only subnets, so address planning in 2026 should at least account for where IPv6 may fit.

3. Decide Who Owns What Before You Draw the Network

A lot of network sprawl begins because teams draw VPCs before deciding who owns what.

Start with the Google Cloud resource hierarchy:

Organization
└── Folders
    └── Projects
        └── VPC networks
            └── Regional subnets
                └── Workloads

Projects own resources, IAM, billing, and API configuration. But a project boundary does not automatically need to become a separate VPC.

Before deciding how many networks to build, answer the organizational questions first:

• What is the boundary between production and non-production?
• Which workloads are in regulated environments (PCI, HIPAA, SOC2)?
• Which teams own which workloads, and how much independent network access do they need?
• Which workloads need strong isolation from each other?
• Is there a central platform team that should own networking infrastructure?
• What does the billing and chargeback model require?

Those answers tell you where the real administrative and trust boundaries are. Once those are clear, the network design gets much easier.

A real organization may have production, non-production, shared services, data, and regulated workloads separated into different projects or folders.

But a Shared Services project does not deserve its own VPC merely because it has its own project. Give it a separate network only when trust, routing, or administration actually needs a separate boundary.

4. Shared VPC: One Network Team, Many Application Projects

As application projects multiply, the platform team usually wants two things at the same time: application teams should control their own projects, but they should not all be changing routes, subnets, NAT, and firewall policy.

Shared VPC is built for exactly that split.

A host project owns the VPC, subnets, routes, and firewall controls. Service projects attach to it. Workloads in those service projects can use delegated subnets without owning the network itself.

So the commerce team can deploy into one subnet, analytics into another, and payments into another, while the networking team keeps the shared network configuration in one place.

Shared VPC is a strong fit when several projects share the same trust and network-administration model. If a regulated workload or separate business unit truly needs different routing, policy, or administration, give that boundary its own Shared VPC environment.

Production and non-production are also often separated when security and change control justify it. The goal is not to create as few VPCs as possible; it is to create only the boundaries you can explain.

5. When to Use a Separate VPC

A separate VPC should buy you a real boundary, because it also gives you another set of routes, policies, monitoring, and connectivity to operate.

Regulatory isolation. If a PCI or similarly regulated environment needs a clearly inspectable network boundary, a separate VPC can make that boundary explicit.

Different trust domains. A business unit or acquisition with its own security policy and administrators may deserve its own network.

Different routing needs. Partner connectivity, unusual CIDR requirements, or routing rules that would complicate the main network can justify isolation.

Administrative independence. If a team genuinely needs to administer the network itself — not just deploy workloads — a separate VPC is the natural boundary.

Acquisitions. When a newly acquired company brings its own address space and operating model, connect the networks deliberately before trying to merge them.

What does not justify another VPC by itself? A new application, microservice, or team that simply wants its own network. One-VPC-per-app feels tidy when there are five apps and painful when there are fifty.

6. Shared VPC, Peering, NCC, or PSC? Start With What Must Connect

These four options are often discussed together, which makes them sound interchangeable. They are not.

Ask a simpler question first: what exactly needs to connect?

Shared VPC

Use Shared VPC when several projects should operate inside one centrally managed network and security domain.

VPC Network Peering

VPC Peering connects two separate VPCs directly. The important limitation is that peering is non-transitive: A↔B and B↔C does not create A↔C.

Peering is perfectly reasonable for a few direct relationships. It becomes hard to manage when every new VPC adds more pairwise connections and the diagram turns into a mesh.

Network Connectivity Center

Network Connectivity Center (NCC) becomes interesting when you have many VPCs or hybrid networks and point-to-point connectivity is getting hard to reason about.

NCC uses a hub-and-spoke model. VPCs, VPN or Interconnect connections, and router appliances can attach as spokes.

Mesh: connected VPCs can exchange subnet routes with one another.

Star: edge VPCs can reach center VPCs but do not automatically reach other edge VPCs — useful when everyone needs shared services but lateral connectivity should stay limited.

NCC manages the connectivity topology; it is not a physical router appliance that every application packet must traverse.

Its routing behavior still depends on route type, routing mode, and topology. Do not reduce it to a blanket rule such as “NCC always requires Global routing.”

Private Service Connect

Private Service Connect (PSC) solves a narrower problem: reaching one service without broadly joining two networks.

If an application only needs the payment service, giving it network access to the payment team’s entire VPC is excessive. PSC gives the consumer a private endpoint to the service while the producer network stays separate.

Shared VPC shares one network across projects; Peering connects VPCs; NCC manages network connectivity; PSC provides private access to a service.

7. PSC vs PSA: Similar Names, Very Different Connections

PSC and PSA sound almost identical, but they connect services in different ways.

Private Service Connect

With Private Service Connect, the consumer gets an endpoint inside its own VPC. Traffic reaches a specific producer service through that endpoint without creating broad routing between the consumer and producer networks.

The consumer controls its endpoint; the producer controls which consumers are allowed to connect. The networks do not exchange subnet routes.

Private Services Access

Private Services Access (PSA) uses a different model: the consumer reserves an address range and creates private connectivity to a Google-managed producer network through the service networking model.

Cloud SQL is the familiar example of a managed service that has used PSA extensively.

The Part That Usually Causes Confusion

The easiest mistake is turning this into a “new versus old” debate.

PSC and PSA are different models. Pick based on what the target service supports and what your network needs.

Cloud SQL makes the point nicely: the source notes that it can support PSA, PSC, or configurations that use both. You do not need to rip out a working PSA design merely because PSC exists.

8. Now Connect the Data Center

Most enterprises do not move everything to Google Cloud in one weekend. For a long time, cloud workloads still need private connectivity back to data centers, offices, or other existing environments.

The two main choices in this article are HA VPN and Cloud Interconnect.

HA VPN

HA VPN gives you encrypted IPsec connectivity. A Google Cloud HA VPN gateway has two interfaces, and meeting the 99.99% availability SLA requires a supported redundant topology across them.

HA VPN is not a “temporary” or second-class option. Many production environments use it successfully. The important part is designing redundancy and BGP correctly.

• Environments where dedicated physical connectivity is unnecessary or not yet justified
• Moderate bandwidth requirements — each Cloud VPN tunnel supports up to 250,000 packets per second, roughly 1–3 Gbps depending on average packet size; additional tunnel pairs can be used when more throughput and failover capacity are required
• Rapid deployment without physical provisioning lead times
• Secondary or backup connectivity alongside Interconnect
• Geographically distributed sites where Interconnect facilities are impractical

Cloud Interconnect gives you private connectivity into Google’s network without using the public internet.

Cloud Interconnect

Dedicated Interconnect is a physical connection at a supported colocation facility. The source article lists 10, 100, and 400 Gbps options, with availability depending on location.

Partner Interconnect uses a provider’s connection to Google and is useful when you are not colocated with Google or do not need a full Dedicated Interconnect connection.

Interconnect becomes worth evaluating when bandwidth is consistently high, predictable low latency matters to the business, and the environment is large enough to justify the procurement and operating model.

A common pattern is Interconnect for the primary path and HA VPN as a fallback.

• Aggregate bandwidth requirements are high and consistent
• Predictable, low-latency, private connectivity to Google Cloud is a business requirement
• Network scale justifies the procurement and operational model

The best option is the one that meets bandwidth, latency, resilience, location, and operational requirements — not the one that sounds more “enterprise.”

9. Two Links Do Not Automatically Mean High Availability

This is where a diagram with two lines can create dangerous confidence.

Two Interconnect links do not automatically make the design highly available, and two VLAN attachments do not automatically qualify for a particular SLA. The topology has to match Google’s documented requirements.

For Dedicated Interconnect, the source describes documented 99.99% topologies, including a classic multi-region pattern and a single-region option that became generally available in June 2026.

For Partner Interconnect, the source describes a 99.99% topology using four VLAN attachments across two metros, with multiple Cloud Routers.

The exact pattern depends on the Interconnect type and topology, so verify the current requirements before promising an SLA.

Check that the links have the required failure independence, routing behavior, and capacity. Test failover before relying on the topology.

10. Cloud Router Does Not Forward Your Application Traffic

The name Cloud Router encourages the wrong mental picture if you are used to physical routers.

Cloud Router is a managed BGP control-plane service. Your application packets do not pass through it.

Its job is to establish BGP sessions, learn prefixes from peers, advertise Google Cloud prefixes back to those peers, and update the VPC routing table with that information.

Because it is not in the packet path, you do not size Cloud Router for application throughput. But BGP failures still matter: if routes disappear and there is no alternate path, application traffic will fail.

The four concepts worth knowing are straightforward:

Learned routes are prefixes Cloud Router receives from peers and installs into the VPC routing table.

Advertised routes are Google Cloud prefixes Cloud Router sends to peers so those networks know how to reach your cloud resources.

Custom advertisements let you choose or aggregate the prefixes sent to peers.

BGP route policies let you filter routes or change routing attributes on the way in or out.

11. Regional or Global Routing? Follow the Routes

Google Cloud VPCs support Regional and Global dynamic routing. The choice controls how far learned dynamic routes are available inside the VPC.

Regional routing: routes learned by a Cloud Router are available only in that router’s region.

Global routing: learned routes can be available across all regions in the VPC.

Imagine a Shared VPC with workloads in three regions and an on-premises connection in us-central1. With Regional routing, the learned on-premises routes stay in that region. With Global routing, workloads in the other regions can receive those routes through the VPC.

For multi-region hybrid networks, Global routing is often useful. But it is still a design choice, not a universal best practice.

Also check the routing requirements of the exact Interconnect or HA topology you choose, because some designs have specific requirements.

12. Plan IP Space While Renumbering Is Still Cheap

IP planning is the networking task everyone wants to postpone until the day overlap blocks a migration.

On-premises overlap. If your data center already uses large parts of RFC1918 space and cloud ranges collide with it, hybrid connectivity becomes much harder.

VPC overlap. Peering cannot use overlapping subnet ranges, and NCC route exchange also has to deal with conflicts deliberately.

Acquisitions. Buying a company that happened to choose the same ranges can turn address management into a business project.

GKE. Pod and service ranges can consume far more address space than VM-only teams expect.

PSC and managed services. Endpoints and service allocations need address space too.

The example below is only an illustration of one way to reserve address blocks by purpose:

10.0.0.0/8     Enterprise cloud pool (illustrative)
10.10.0.0/16   Production
10.20.0.0/16   Non-production
10.30.0.0/16   Shared services
10.40.0.0/16   Data platforms
10.50.0.0/16   Reserved for PSA / PSC
10.60.0.0/16   Reserved for GKE secondary ranges
10.70.0.0/16   Future expansion

Do not copy the numbers blindly. Copy the habit: centralize allocations, reserve space for known growth areas, and avoid casually accepting address ranges that will collide with on-premises or future cloud networks.

13. IPv6 Is Now a Planning Question, Not a Future Problem

You do not have to migrate everything to IPv6 tomorrow. But a network designed in 2026 should stop pretending IPv6 will never arrive.

The source notes Google Cloud support for dual-stack and IPv6-only subnets.

Dual-stack is the least disruptive way to gain experience: existing workloads keep IPv4 while newer workloads can also use IPv6.

Application compatibility is still the real constraint. Test libraries, third-party services, and operational tooling rather than assuming support.

Security rules need to cover both address families. IPv4 policy does not magically secure IPv6.

DNS changes too: dual-stack environments introduce AAAA records alongside A records, and Google API access has IPv6 considerations.

Even if rollout is later, leave room for IPv6 in the network plan now. Retrofitting it into a mature estate is harder than accounting for it up front.

14. Network Security Is More Than a Firewall Rule

Google Cloud network security works best when you stop looking for one giant perimeter firewall and think in layers.

VPC Firewall Rules

VPC firewall rules remain useful for workload-level controls. They can target VM instances using tags or service accounts, but project-by-project rules can become difficult to govern at scale.

Firewall Policies

Firewall policies give central teams a cleaner way to apply consistent policy across a larger organization.

Hierarchical firewall policies can apply at the organization or folder level, which lets security teams establish controls that projects underneath must respect.

Global network firewall policies cover a VPC across regions.

Regional network firewall policies apply in one region.

When classic VPC firewall rules and network firewall policies are used together, their evaluation order can be configured. That is exactly the sort of detail to verify in the current product documentation before rolling out a complex policy stack.

The Layered Model in Practice

A simple layered model is enough to start: organization-level rules for mandatory guardrails, environment or network policies for shared controls, and workload-level rules for the specific application paths that should be allowed.

15. Cloud NGFW: Add Only the Security Features You Need

Cloud NGFW adds distributed firewall capabilities without forcing traffic through one central appliance.

Secure tags are useful because they are governed by IAM, rather than being simple labels that anyone with enough project access might apply.

The source article describes three tiers:

Essentials covers the foundation: hierarchical and network firewall policies, secure tags, and address groups.

Standard adds features such as threat intelligence, FQDN-based objects, and geolocation rules.

Enterprise adds inline IPS and deeper Layer-7 inspection.

Do not buy the highest tier because the word “Enterprise” feels safer. Start with the controls your threat model requires, then add Standard or Enterprise capabilities when there is a clear security reason.

16. A Subnet Is an Address Boundary, Not a Trust Boundary

This is one of the most useful corrections for engineers coming from VLAN-heavy data-center designs.

In a traditional environment, subnet or VLAN membership often implied a trust level.

In Google Cloud, a subnet mainly gives you a regional IP range. Traffic is still evaluated by the platform’s firewall controls, including traffic between resources in the same subnet.

The real security picture combines VPC boundaries, firewall policies, IAM, secure tags, service-level authentication, and — where appropriate — VPC Service Controls.

Subnets still matter for addressing and routing, but do not treat a subnet by itself as the security perimeter.

17. VPC Service Controls Protect Data, Not Packets

VPC Service Controls are about reducing data-exfiltration risk around supported Google-managed services such as Cloud Storage, BigQuery, and Pub/Sub.

For example, you may want a sensitive BigQuery dataset to be reachable only from approved environments even if an identity elsewhere has IAM permission.

VPC Service Controls are not a packet firewall, routing technology, NAT feature, or IAM replacement. Think of them as an additional service boundary around sensitive data.

18. Give Internet Traffic One Clear Front Door

For public applications, make the internet entry path obvious instead of letting workloads expose themselves in many different ways.

The pattern in this article uses a global Application Load Balancer for the entry point, TLS termination and certificates, Cloud Armor for edge security, health checking, and the ability to send traffic to healthy backends across regions.

Those backends can be VMs, GKE, Cloud Run, or static content. The ingress pattern does not force one compute platform.

And as a general design principle, avoid public IPs on workload VMs unless there is a real reason. One controlled front door is easier to protect and understand than dozens of direct internet paths.

19. Design Egress as Carefully as Ingress

Teams often spend hours perfecting inbound traffic and then treat outbound traffic as “whatever gets to the internet.” That is a mistake.

Cloud NAT for Internet Egress

Private VMs without external IPs need an explicit way to make outbound internet connections. Cloud NAT provides that path.

Cloud NAT supports connections initiated from the private workload and the return traffic for those connections. It does not make the VM directly reachable from arbitrary internet clients.

The part people forget is port capacity. Every concurrent outbound connection consumes NAT source-port capacity.

Static port allocation gives a more predictable allocation model.

Dynamic port allocation adjusts per-VM port allocation as usage changes.

Whichever mode you use, monitor port usage. Dynamic allocation changes how ports are distributed; it does not create infinite capacity.

20. Cloud NAT, Private Google Access, and PSC: Three Different Jobs

These three features can all appear in a private workload design, but they solve different problems.

Cloud NAT is for outbound access from private workloads to public internet destinations.

Private Google Access lets private workloads reach supported Google APIs without giving those workloads external IPs.

Private Service Connect creates a private endpoint to one specific service.

So they are not replacements for one another. A private application may legitimately use all three for different traffic.

For Google API domains, the source distinguishes private.googleapis.com from restricted.googleapis.com. The second narrows API access to services that support VPC Service Controls, but DNS choice alone does not create a VPC Service Controls perimeter.

21. Private NAT Helps When IP Ranges Collide

Overlapping IP ranges tend to show up at the worst time — an acquisition, partner integration, or hybrid connection.

The source article describes Private NAT and Hybrid NAT as translation options when private address spaces collide and immediate renumbering is not practical.

Treat them as a bridge, not permission to stop caring about IP planning. If both sides can eventually be renumbered cleanly, fixing the overlap is still the simpler long-term architecture.

22. DNS Can Break a Network That Routes Perfectly

A route can be perfect and the application can still fail because the hostname resolves to the wrong address.

Cloud DNS should be treated as part of the network design, especially in hybrid environments.

Public zones serve internet-resolvable names.

Private zones serve internal names to the VPCs associated with them.

Inbound forwarding lets on-premises resolvers send queries for Google Cloud private zones into Cloud DNS.

Outbound forwarding lets Google Cloud workloads forward selected domains to on-premises resolvers.

DNS peering lets one VPC use DNS configuration from another VPC without requiring network peering between the VPCs.

One important warning: network connectivity does not automatically make every DNS-forwarding path reachable. DNS forwarding has its own reachability and policy requirements.

Once several VPCs and on-premises domains are involved, a deliberate DNS architecture is much easier to operate than configuring each VPC independently and hoping they stay consistent.

23. Multi-Region Does Not Mean Multi-VPC

Putting workloads in several regions can improve resilience, latency, and data-location options. It still does not require a separate VPC for every region.

A single VPC can contain subnets in several regions, and workloads in those subnets can communicate with internal addresses.

The real multi-region decisions are application placement, load balancing, data replication and consistency, route propagation, and failover capacity. A network can be perfectly connected and still fail during a regional outage because the surviving region was never sized to handle the full load.

24. Network HA Does Not Equal Application DR

Network HA removes single points of failure in connectivity: redundant VPN tunnels, Interconnect links, BGP paths, and resilient DNS.

Application HA and DR deal with the application itself: replicas, database failover, dependencies, regional capacity, and recovery procedures.

A redundant network does not rescue a single-instance database or a dependency that exists in only one region. Test the whole application failover path, not just the network links.

25. GKE Can Consume More IP Space Than You Expect

GKE can consume address space much faster than a VM-focused network team expects.

VPC-native clusters use alias IPs and secondary ranges for Pods. Depending on cluster size and Pod density, one cluster can reserve a very large range.

Reserve Pod and Service ranges intentionally before dozens of clusters appear across development, staging, and production.

Private GKE clusters are also common when the goal is to avoid public node IPs, which makes private control-plane and network access design part of the planning.

26. Serverless Services Still Live in Your Network Design

Serverless removes server management, not networking decisions.

Direct VPC egress lets Cloud Run send traffic to VPC resources without a separate connector.

PSC can be used when the Cloud Run service needs a private endpoint to a supported service.

Cloud Run can also sit behind internal load balancing when the service should be reachable only from private environments.

The source also notes VPC Flow Logs support for Cloud Run resources using Direct VPC egress.

So include serverless workloads in subnet sizing, firewall policy, and observability planning. They are managed workloads, not network-free workloads.

27. Turn On Network Observability Before the Outage

Network telemetry is far more useful when you already have a healthy baseline from before the incident.

VPC Flow Logs

VPC Flow Logs give you sampled flow information such as source, destination, ports, bytes, and packets. One subtle point from the source: denied ingress traffic is not what you use Flow Logs to inspect, because ingress sampling happens after ingress firewall processing.

Firewall Rules Logging

Firewall Rules Logging tells you which firewall rule allowed or denied a connection. Use it when the question is “which rule made this decision?”

Other Observability Components

Cloud NAT logging is especially useful when you suspect NAT allocation or port exhaustion.

Cloud DNS logging helps when name resolution is the real problem.

Network Intelligence Center adds path testing and traffic-analysis tools that help answer whether connectivity should work and how the network is behaving.

A Practical Troubleshooting Sequence

When an application cannot reach a database, debug in a boring order instead of guessing:

1. DNS — does the name resolve to the address you expect?
2. Route — is there a valid path from the application network to the database?
3. Firewall — which rule allowed or denied the traffic?
4. PSC/PSA — if private service connectivity is involved, is the endpoint or service connection healthy?
5. Backend — is the database itself up and accepting connections?

If you already have logs and baselines for these layers, each step can be answered with evidence instead of a theory.

28. Put the Design on One Page

Now put the pieces on one page. This is a reference, not a template you must copy. Use the parts that match your own trust boundaries, traffic paths, and hybrid needs.

One useful guardrail: production and non-production should not be broadly routed together by default. If one service needs to cross the boundary, expose that service deliberately rather than opening a much larger network path.

29. The Mistakes That Hurt Most Later

The failures that hurt most usually start as small shortcuts while the environment is still easy to manage.

1. One VPC per application. Use a new network for a real trust or administration boundary, not simply because a new app exists.

2. Treating subnets like VLAN security zones. A Google Cloud subnet is primarily an address range; security needs explicit policy.

3. Letting peering grow into a giant mesh. Pairwise peering becomes very hard to understand as VPC count grows. NCC exists for the “many networks” problem.

4. Ignoring address overlap. Fixing CIDRs early is far easier than building translation and routing workarounds later.

5. Forgetting GKE address consumption. Pod and Service ranges can exhaust a plan that looked generous for VMs.

6. Pretending IPv6 will never matter. You do not need to deploy it everywhere now, but you should leave room for it.

7. Treating PSC and PSA as the same thing. They are different private-connectivity models.

8. Routing whole networks when one private service would do. PSC can keep the connection much narrower.

9. Choosing Regional or Global routing by habit. Match the routing mode to where learned routes actually need to be available.

10. Drawing Cloud Router in the packet path. It exchanges BGP routes; it is not the forwarding appliance.

11. Assuming two links equal a 99.99% design. SLA topology requirements still have to be satisfied.

12. Giving workloads public IPs without a reason. A controlled load-balancer entry point is easier to secure.

13. Forgetting NAT port capacity. Port exhaustion often looks like a mysterious application timeout.

14. Letting firewall rules grow project by project with no central guardrails. Use hierarchical policy where the organization needs consistent controls.

15. Treating VPC Service Controls like a firewall. It protects service/data boundaries, not packet flows.

16. Designing hybrid routing and leaving DNS for later. Routing and name resolution are separate systems.

17. Assuming a working route means DNS must work. It does not.

18. Using Flow Logs to answer a firewall-decision question. Use Firewall Rules Logging when you need to know which rule allowed or denied traffic.

19. Turning on telemetry after the first incident. Baselines are what make telemetry useful.

20. Never testing failover. A diagram can be resilient while the application still fails during a real switchover.

30. When the Network Grows Beyond Google Cloud

Once the network includes branches, stores, factories, or workloads in other clouds, you are solving a wider WAN problem, not just a Google Cloud VPC problem.

The source describes NCC Gateway spokes as a way to integrate third-party Security Service Edge providers into NCC-based designs.

It also describes Cross-Cloud Interconnect for private connectivity between Google Cloud and other cloud providers, including a Partner Cross-Cloud Interconnect option for AWS that reached general availability in 2026.

NCC can also act as the hub for branch and WAN connectivity into Google Cloud.

These are useful options when you genuinely have a WAN or multi-cloud requirement. Get the core VPC, Shared VPC, hybrid, and routing model clean first; then extend it rather than starting with the most complex network on day one.

31. Network Design Review Checklist

Start with boundaries, not products. Decide where trust, administration, compliance, and workload ownership change.

Remember the Google Cloud model. VPCs are global; subnets are regional.

Share networks where trust allows. Shared VPC keeps network administration central without forcing every workload into one project.

Separate networks when the boundary is real. Regulation, trust, routing, or administration should explain the extra VPC.

Connect only what needs to connect. If the consumer needs one service, consider service-level connectivity instead of broad network access.

Design hybrid routes on purpose. Choose routing modes, BGP policy, and failover paths with the full topology in mind.

Ingress and egress are separate design problems. Give both an explicit path.

DNS is infrastructure. Build hybrid name resolution alongside hybrid routing.

Keep security guardrails central. Organization and folder-level policy can prevent every project from inventing its own baseline.

Use the right telemetry for the question. Flow Logs show traffic patterns; Firewall Rules Logging shows rule decisions.

Test failure, do not just diagram it. Route, DNS, network, and application failover all need to work together.

Automate the network. Large estates drift quickly when routes, firewall rules, and DNS are hand-edited.

The goal is not maximum connectivity. The goal is a network where every connection has a reason, every boundary is understandable, and the next engineer can still explain the design years later.

Frequently Asked Questions

Is a Google Cloud VPC global or regional?

Yes. The VPC is global; subnets are regional. Workloads in different regions can belong to the same VPC and communicate using internal addresses.

What is the difference between Shared VPC and VPC Peering?

Shared VPC lets many projects use one centrally administered VPC. VPC Peering connects two separate VPCs. Peering is non-transitive.

When should I use Network Connectivity Center?

Use NCC when you have many VPCs and/or hybrid networks and point-to-point relationships are becoming difficult to manage. It supports hub-and-spoke patterns including mesh and star topologies.

What is the difference between PSC and PSA?

PSC gives a consumer a private endpoint to a specific service without broadly joining networks. PSA uses private service networking with an allocated range and a producer-network relationship. Choose based on what the service supports and what the design requires.

Does Cloud Router forward packets?

No. Cloud Router is the BGP control plane. It exchanges route information; application packets do not traverse it.

Does Cloud NAT allow inbound internet traffic?

No. Cloud NAT allows outbound-initiated internet connections and their return traffic. It does not make a private VM directly reachable from the internet.

Should production and non-production use separate VPCs?

Often, but not automatically. Separate production and non-production networks when security, compliance, or change-control boundaries justify it. If one service must cross the boundary, expose that service narrowly rather than routing everything together.

When should I use Interconnect instead of HA VPN?

Consider Interconnect when bandwidth, latency, private connectivity, and scale justify the physical or provider-based model. HA VPN is a strong option for encrypted connectivity, faster deployment, backup paths, and locations where Interconnect is impractical.

Does multi-region deployment require multiple VPCs?

No. One global VPC can contain subnets and workloads in multiple regions.

What is the difference between Cloud NAT and Private Google Access?

Cloud NAT reaches public internet destinations. Private Google Access reaches supported Google APIs without public IPs. They can be used together.

What is the difference between VPC Flow Logs and Firewall Rules Logging?

Flow Logs show sampled traffic-flow telemetry. Firewall Rules Logging tells you which firewall rule allowed or denied a connection.

What is the difference between private.googleapis.com and restricted.googleapis.com?

private.googleapis.com provides private access to a broad set of supported Google APIs. restricted.googleapis.com narrows access to services compatible with VPC Service Controls. The DNS name itself does not create a VPC Service Controls perimeter.