Networking and connectivity

Start with the packet path

Cloud networking becomes manageable when you trace a request from source to destination and ask the same questions at each hop:

1. How does the source resolve the destination name?
2. Which IP and route does it select?
3. Which firewall, identity or service policy permits the traffic?
4. Which load balancer or proxy terminates the connection?
5. How does the response return, and where can it be observed?

Keep three paths separate: ingress into a workload, east-west traffic between workloads, and egress towards APIs or the internet. They often use different controls.

VPC networks are global; subnets are regional

A Google Cloud Virtual Private Cloud network is a global resource. It can contain regional subnets, routes and firewall policies that connect resources across regions. This differs from clouds where the virtual network itself is regional.

IP planning still matters. Choose non-overlapping address ranges that leave room for environments, clusters, services and hybrid networks. Overlap makes peering and hybrid routing difficult later. Prefer custom-mode VPCs for deliberate production designs; the automatically created default network is convenient for exploration but usually too permissive and implicit for a governed landing zone.

VPC firewall rules are stateful and apply to instances or network interfaces based on direction, priority, target and source. Hierarchical firewall policies can enforce rules higher in the organization. A firewall permits network reachability; it does not authorize a business operation.

Read the VPC overview and firewall policy overview.

Shared VPC and peering solve different ownership problems

Shared VPC lets a host project own networks and expose selected subnets to service projects. It is useful when a network/platform team governs connectivity while product teams own workloads in separate projects. IAM controls who may use each subnet.

VPC Network Peering connects two independently administered VPC networks using private IP routes. The networks remain separate, and peering is not transitive: if A peers with B and B peers with C, A does not automatically reach C through B.

Private Service Connect publishes or consumes managed services and producer services through private endpoints. It is often a better abstraction than broad network peering when the desired contract is “consume this service,” not “join these networks.”

Choose based on ownership and exposure:

Ingress, load balancing and DNS

Google Cloud offers global and regional load-balancing modes for different protocols and backends. For an internet-facing HTTP application, a global external Application Load Balancer can provide one anycast IP, TLS termination, routing, health checks and integration with Cloud Armor. A regional internal Application Load Balancer is a different choice for private regional consumers.

Cloud DNS provides authoritative public and private zones. Private zones and forwarding policies affect how workloads resolve internal names. DNS failures can look like network or application failures, so include resolution in observability and troubleshooting.

Cloud Armor adds web application firewall and DDoS-related controls for supported load-balanced applications. It does not repair insecure application authorization or unsafe input handling.

Egress and access to Google APIs

A workload without an external IP can use Cloud NAT for outbound internet connections. NAT does not accept unsolicited inbound sessions and does not by itself restrict which external hosts a workload may contact. Egress firewall policy, proxies or platform-specific controls may still be required.

Access to Google APIs has several private-routing patterns. The correct choice depends on whether the workload has an external IP, whether it must stay within a service perimeter, which API endpoints are supported and how DNS is configured. “Private IP only” is an intended property that must be verified end-to-end, not a checkbox on one resource.

Architecture checkpoint

A public API runs in two regions. Its database is private, administrators connect from an on-premises network, and product projects must not manage shared routes.

A plausible design uses a centrally managed Shared VPC, service projects for workloads, private database connectivity, global HTTP(S) load balancing with health-aware backends, Cloud Armor, and Cloud VPN or Interconnect for hybrid access. The detailed answer must also state DNS ownership, egress, firewall targets, route exchange, regional failure behavior and which team operates every component.

Official study links

• VPC networks
• Shared VPC
• Cloud Load Balancing overview
• Private Service Connect
• Hybrid connectivity

Nais bridge

Nais presents networking primarily through ingresses and accessPolicy. The platform translates declared service relationships into routing and network controls on the underlying Kubernetes and cloud network. Teams should still understand names, TLS, ingress exposure, outbound dependencies and timeouts. An access policy establishes permitted connectivity; token validation and domain authorization remain separate layers.