Designing and planning a cloud solution architecture · Topic 5 of 8
Cloud-Native and Hybrid Network Design
Designing VPC networks, Shared VPC, peering, Private Service Connect, load balancers and container networking, and connecting on-premises and other clouds.
- 4 min
- VPCs are global, subnets regional.
- Shared VPC centralizes control; peering is non-transitive and needs unique ranges; PSC exposes single services.
- Pick the load balancer by traffic type and scope; global Application Load Balancer for HTTP(S) from the internet.
What it is
Network design decides how workloads reach each other, how users reach them and how the cloud joins existing data centers and other clouds. The exam tests the design choice; the next chapter covers configuring the same pieces.
How it works
VPC building blocks
| Piece | What to know |
|---|---|
| VPC network | Global; subnets are regional; one network can span every region |
| Firewall rules and policies | Stateful rules; hierarchical firewall policies apply across an organization or folder |
| Routes and Cloud Router | Cloud Router exchanges routes with on-premises and other networks over BGP |
| Private Google Access | VMs without external IPs reach Google APIs |
| Cloud NAT | Outbound internet for private resources, with fixed external addresses if needed |
Connecting VPC networks
| Option | Use it when | Watch out for |
|---|---|---|
| Shared VPC | One central team runs the network; many projects use its subnets | Host and service projects in the same organization |
| VPC Network Peering | Two networks need private connectivity | No overlapping ranges; peering is not transitive |
| Private Service Connect | Publish or consume one service privately across networks or organizations | Works with overlapping IP ranges; exposes the service, not the network |
| Network Connectivity Center | Hub and spoke for many VPCs and hybrid sites | Can carry site-to-site traffic over Google's network |
Overlapping address ranges rule out peering. When a partner must reach only one service, Private Service Connect is the usual answer.
Load balancers
| Load balancer | Traffic | Scope |
|---|---|---|
| Global external Application Load Balancer | HTTP(S) from the internet | Global anycast IP, Cloud CDN, Cloud Armor, IAP |
| Regional external Application Load Balancer | HTTP(S) | One region, for regional requirements |
| Internal Application Load Balancer | HTTP(S) inside the VPC | Regional or cross-region |
| Proxy and passthrough Network Load Balancers | TCP/UDP | External or internal; passthrough keeps client IPs |
Serverless backends (Cloud Run) attach through serverless NEGs; on-premises or other-cloud backends through hybrid NEGs.
Container networking
GKE clusters should be VPC-native: Pods get addresses from a subnet secondary range, so they are routable in the VPC; Services use another secondary range or, on newer clusters, a Google-managed range. Plan these ranges early so they do not overlap with on-premises networks. Use Gateway (or Ingress) for HTTP load balancing, and multi-cluster Gateway to spread traffic across clusters in several regions.
Integration with on-premises and other clouds
| Need | Option |
|---|---|
| Encrypted link over the internet, fast to set up | HA VPN (99.99% SLA with the right topology) |
| High bandwidth, private, at a Google colocation facility | Dedicated Interconnect |
| Private link through a service provider | Partner Interconnect |
| Private link to another cloud provider | Cross-Cloud Interconnect |
| Consistent Kubernetes across sites | GKE Enterprise fleets and Google Distributed Cloud |
A worked scenario
A retailer's shipping partner runs in its own VPC with ranges that overlap the retailer's. The partner must call one order service privately and see nothing else. Peering fails on the overlap, Shared VPC would pull the partner into the retailer's network, and a public load balancer exposes the service. Private Service Connect publishes only the order service.
How the exam asks about this
- "Central network team, many application projects." Shared VPC.
- "Plants must reach each other over Google's backbone using only their links to Google Cloud." Network Connectivity Center with hybrid spokes.
- "One hostname, some paths to Cloud Run, the rest to the legacy system." Global external Application Load Balancer with serverless and hybrid NEGs.
What to remember for the exam
- VPCs are global, subnets regional.
- Shared VPC centralizes control; peering is non-transitive and needs unique ranges; PSC exposes single services.
- Pick the load balancer by traffic type and scope; global Application Load Balancer for HTTP(S) from the internet.
- Plan GKE Pod and Service ranges to avoid overlaps.
- HA VPN for quick encrypted links; Interconnect for private bandwidth; Cross-Cloud Interconnect for other clouds.
VPC peering is not transitive. Network A peered to B and B peered to C does not let A reach C.
Common mistakes
Peering overlapping networks. It is not allowed; use Private Service Connect.
Exposing internal services to the internet to reach a partner.
Forgetting IP planning for GKE. Secondary ranges are hard to change later.
Check yourself
Which option lets a partner with overlapping IP ranges reach one of your services privately?
Private Service Connect.
How do you route some URL paths to Cloud Run and the rest to on-premises servers under one hostname?
A global external Application Load Balancer with a serverless NEG and a hybrid NEG.
Is VPC Network Peering transitive?
No.
Topic 5 of 8 in Designing and planning a cloud solution architecture
Test yourself on Designing and planning a cloud solution architecture
The full Google Cloud Professional Cloud Architect question bank has 877 questions, with timed practice exams and an explanation for every answer.
This study guide is independent and is not affiliated with, endorsed by, or sponsored by Google Cloud. Vendor names, certification names and exam codes are trademarks of their respective owners and are used for identification only.