Designing and planning VPC networks

Network tiers

Choose Standard for cost-sensitive, latency-tolerant traffic in one region; choose Premium when users are global or you need a single global anycast IP. Network tier is set per external IP address and forwarding rule, not per project (you can set a project default). Traffic between VMs and to Google APIs inside Google’s network is not affected.

VPC fundamentals that get tested

• A VPC network is a global, software-defined resource. Subnets are regional and span all zones of a region. VMs in different regions of one VPC talk over internal IPs with no gateways or VPN.
• Auto mode VPC creates one /20 subnet per region from 10.128.0.0/9 and adds default firewall rules. Fine for experiments, bad for production (ranges overlap with on-premises and peers). You can convert auto to custom, never custom to auto.
• Custom mode VPC: you create every subnet. Use it for anything real.
• The default network is an auto mode network with permissive default rules; organization policy can stop it being created.
• Every IPv4 subnet reserves four addresses in its primary range: network, default gateway, the second-to-last (reserved by Google) and broadcast. A /29 therefore has 4 usable addresses.
• A subnet’s primary range can be expanded but never shrunk, without recreating the subnet and without downtime. Expand with gcloud compute networks subnets expand-ip-range; the new range must contain the old one and not overlap other ranges. Secondary ranges can be added later, and you can replace or extend them for GKE, but cannot overlap the primary.
• Subnet purposes matter: PRIVATE (normal), REGIONAL_MANAGED_PROXY and GLOBAL_MANAGED_PROXY (proxy-only subnets for Envoy-based LBs), PRIVATE_SERVICE_CONNECT (NAT subnet for a service producer), INTERNAL_HTTPS_LOAD_BALANCER (legacy name for the proxy-only purpose). Proxy-only subnets cannot hold VMs.
• Private Google Access is a per-subnet toggle that lets VMs with only internal IPs reach Google APIs and services (*.googleapis.com) on the default internet gateway route. It needs a route to the default internet gateway (0.0.0.0/0 next hop) or the special API ranges, and DNS that resolves to Google’s ranges. It does not give general internet access; use Cloud NAT for that.
• For on-premises hosts to reach Google APIs privately over VPN or Interconnect, use Private Service Connect for Google APIs (an endpoint with an internal IP) or the private.googleapis.com and restricted.googleapis.com virtual IPs. restricted.googleapis.com (199.36.153.4/30) only exposes APIs supported by VPC Service Controls and is what you use with a perimeter. private.googleapis.com (199.36.153.8/30) exposes all APIs. These ranges are advertised from Cloud Router as custom routes.

Choosing the VPC type and count

Typical reasons for multiple VPCs: environment isolation (prod vs non-prod), compliance boundaries, different overlapping IP plans, per-business-unit quotas, or a separate VPC for shared services and on-premises connectivity. The more VPCs you add, the more connections you must manage, so many designs use one Shared VPC host per environment and a hub VPC for hybrid connectivity.

Shared VPC in detail

• Enabled at the organization level by someone with Shared VPC Admin (roles/compute.xpnAdmin) on the organization or folder. A project becomes a host project; other projects attach as service projects.
• A project can be attached to only one host project. A host project cannot itself be a service project.
• Sharing can be all subnets in the host project or specific subnets. Sharing specific subnets is the least-privilege answer.
• Permissions that service project users need:
  • Compute Network User (roles/compute.networkUser) on the host project or on individual subnets, so they can create VMs, instance templates, GKE nodes and internal LBs in those subnets. Granting at the subnet level limits them to one subnet.
  • Compute Network Admin or Compute Security Admin (host project or folder) for the network team who manage routes, peering and firewall policy.
  • Service accounts of the service project also need Network User: the Compute Engine default service account and the @cloudservices.gserviceaccount.com account for managed instance groups, and for GKE the GKE service agent needs Host Service Agent User (roles/container.hostServiceAgentUser) in the host project plus Compute Network User on the subnet.
• Load balancer provisioning: forwarding rules and backends can live in a service project while the frontend uses a host project subnet (for internal LBs) or a cross-project URL map. Compute Load Balancer Admin (roles/compute.loadBalancerAdmin) creates and modifies LB resources; Compute Load Balancer Services User (roles/compute.loadBalancerServiceUser) lets someone use LB backend services without managing them (for cross-project service referencing).
• Firewall rules and policies are managed in the host project; use service accounts or secure tags as source/target so rules follow workloads across service projects.
• Shared VPC can be used with VPC Service Controls, but the host and service projects must be inside the same perimeter for a normal setup.

VPC Network Peering

• Connects two VPCs (same or different projects or organizations) so VMs reach each other by internal IPs, with traffic staying on Google’s network. No gateways, no bandwidth bottleneck, no extra charge for the peering itself.
• Not transitive: if A peers B and B peers C, A cannot reach C. It also does not carry on-premises routes unless you explicitly export custom routes (see below).
• Both sides must create the peering. Subnet ranges cannot overlap (including secondary ranges). Ranges that would overlap after peering conflict.
• Custom route exchange: by default only subnet routes are exchanged. Turn on export custom routes on one side and import custom routes on the other to pass static or dynamic routes (for example learned from VPN). This is how a spoke VPC can reach on-premises through a hub VPC that holds the VPN, but only one hop (the hub’s routes, not another peer’s).
• You can also exchange subnet routes with public IP ranges (PUPI) if you opt in.
• Peering with a hub does not let spokes reach each other. For that use NCC, VPN between VPCs, or a shared appliance.
• Quotas: default limits on peering connections per VPC (25) and on total instances and forwarding rules in a peering group, which are enforced across the group. Large peering meshes hit these limits, which is a reason to prefer NCC.
• Firewall rules are not shared across peering: each VPC must allow the other’s traffic.

Managed services connectivity

Key differences between PSA and PSC:

• PSA uses peering, so it is non-transitive and consumes an allocated range that must not overlap your on-premises ranges. To let on-premises reach the managed service you must advertise the allocated range via Cloud Router (custom advertisement) and export custom routes on the peering.
• PSC uses a single internal IP in your VPC and is unidirectional (consumer to producer), works across overlapping address spaces, and is reachable from on-premises like any internal IP. No peering and no route exchange.
• For Google APIs, a PSC endpoint can use the all-apis bundle or vpc-sc bundle, and you can give it a custom name like p.googleapis.com DNS records.

Serverless connectors need a subnet with a /28 range (not in use) and the connector service account roles; connector throughput scales between a configurable minimum and maximum number of instances. If a question mentions a connector limit, Direct VPC egress is the modern replacement.

IP address management (IPAM)

• Plan before building: pick non-overlapping RFC 1918 blocks for cloud, on-premises, peers and managed services. Overlap breaks peering, VPN routing and PSA. Reserve ranges for growth, GKE pods and services (the biggest consumers), proxy-only subnets, PSA allocations and connector subnets.
• Non-RFC 1918 ranges: you can use other private-ish ranges such as 100.64.0.0/10 and 240.0.0.0/4 (class E) as subnet ranges. Class E is a popular source of extra space for GKE pods. Peers must accept the range and on-premises devices must route it.
• Privately used public IP (PUPI): public addresses used internally. They work inside a VPC and between peered VPCs only if the peering is configured to import and export them. They are never advertised on the internet, and VMs cannot reach the real owner of those addresses.
• Private NAT translates between overlapping private ranges, for example between VPCs, over NCC or to on-premises, without any public IP. It is the answer when two merged companies use the same RFC 1918 space.
• Bring your own IP (BYOIP) lets you bring public ranges you own to Google (advertise from Google, keep addresses across migration). Needs a /24 or larger and proof of ownership (RPKI/ROA).
• IPv6: subnets can be dual stack (IPv4 + IPv6) or IPv6-only. Internal IPv6 uses ULA (fd20::/20, a /48 per VPC); external IPv6 uses a Google-assigned /64 per subnet. Internal and external access types are chosen per subnet. IPv6 is supported by Cloud Router, HA VPN and Interconnect as well as external load balancers.
• Internal ranges (the internalRanges resource) reserve CIDR blocks centrally, avoid overlaps and can be used with NCC for IPAM automation. Reserve with prefix length instead of calculating by hand; they can also be allocated for GKE, PSC or NCC use.
• Automation: Terraform modules, Network Connectivity Center internal ranges, and IPAM allocation tools replace spreadsheets. In exam answers “centrally managed, automated, non-overlapping” points to internal ranges.

Global vs regional design

• A VPC being global means one VPC can hold subnets in many regions and use global dynamic routing so a single VPN or Interconnect can serve all of them (see dns-routing notes).
• Regional designs (a VPC with subnets in one region and regional dynamic routing) fit data residency, latency isolation and blast radius limits.
• High availability: spread across zones with managed instance groups, across regions with global load balancing, and keep each region’s resources reachable. Ensure hybrid links exist in at least two edge locations or two regions with a 99.99% topology for critical workloads.
• Disaster recovery: put the DR region in the same VPC (a second subnet), use a global LB with failover or Cloud DNS failover routing policy, and replicate data by region-level services.
• Plan for quotas and limits: subnet and route counts, forwarding rules per network and per peering group, VM counts, routes per VPC, static IPs, Cloud Router prefix counts and BGP session limits. Quota metrics are visible in Cloud Monitoring and gcloud compute project-info describe; request increases early. NCC and Interconnect have their own limits.

MTU

• A VPC network’s default MTU is 1460. You can set 1300 to 8896; 1500 matches the internet and most on-premises networks, and 8896 (jumbo) is only useful inside the VPC or over supporting attachments.
• MTU is a VPC network setting applied to all VM interfaces. VMs must be configured to match; mixed MTUs in one VPC cause fragmentation or drops.
• Cloud VPN: the gateway MTU is 1460 bytes; tunnel overhead (ESP) reduces the payload so the effective payload is lower (TCP MSS clamping is recommended). Keep workload MTU at or below what the gateway supports.
• Interconnect VLAN attachments: MTU of 1440 (default), 1460, 1500 or 8896 (check current docs), and the VPC MTU on the other side should be equal or higher. For HA VPN over Interconnect, the tunnel overhead means a lower payload.
• When MTU mismatches exist, symptom: small packets (ping, SSH login) work but large transfers hang. Fix with a matching MTU or MSS clamping.

Third-party appliances in the path

• Use a multi-NIC VM (one NIC in each VPC) running the NGFW or router. Traffic is steered to it by custom static routes whose next hop is an internal passthrough Network Load Balancer (so the appliance pool is highly available) or a single VM instance.
• A route with an internal LB next hop is the standard HA design. Set the routes on the spokes with priorities; use health checks to remove a failed appliance. Symmetric flows are needed: use symmetric hashing on the LB so request and response go through the same appliance.
• Policy-based routes can send a specific source or protocol to the appliance without changing the default route.
• Alternative: Packet Mirroring and out-of-band Network Security Integration for inspection without being in path (see network-security notes).
• Routing details, priorities and tags are in the dns-routing notes.

GKE networking design

Cluster types and IP planning

• VPC-native clusters (using alias IP ranges) are the default and required for most features. Each node gets an IP from the subnet primary range; Pods come from a secondary range (a /24 per node by default for 110 pods) and Services (ClusterIPs) come from another secondary range. Routes-based clusters are legacy.
• Sizing: pod range size is the main scale limit. Standard clusters: default 110 pods per node (range /24 per node, because Google allocates double the max pods); you can lower max pods per node (to 8 to 256 total settable) to use smaller blocks. Autopilot defaults to 32 pods per node (/26) and manages nodes itself. Number of nodes = pod range size / per-node block size, so a /14 pod range with /24 per node gives 1,024 nodes. The Service range cannot be changed once set (plan size up front, typically /20 or larger).
• Additional Pod ranges (discontiguous multi-Pod CIDR) can be added to a cluster or a node pool when the original range is exhausted. This is the fix for “pod IPs exhausted” without recreating the cluster. Node pools can use different secondary ranges.
• Non-RFC 1918 sources for Pods: class E, 100.64.0.0/10, PUPI. Use them when RFC 1918 space is short; on-premises needs no route to them if egress SNATs to the node IP.
• Sharing: pods and services secondary ranges can be shared across clusters only in specific patterns (Services ranges must be unique per cluster; Pod ranges can be shared but it is discouraged).
• Shared VPC: create the cluster in a service project using a host project subnet and its secondary ranges; grant Network User and Host Service Agent User.
• IPv6: GKE supports dual-stack clusters (VPC-native, with a dual-stack subnet) for nodes, Pods and Services.

Public or private

• DNS-based endpoint (gke-xxxx.location.gke.goog): reachable from anywhere over HTTPS but access is gated by IAM permissions and VPC Service Controls, with no need for authorized networks or a VPN. It is the “simplest way for developers to reach the control plane” answer.
• A private cluster’s control plane uses a /28 range (older design) or a PSC endpoint; to reach it from on-premises you must export custom routes on the peering (older design) or advertise the PSC address range.
• Enable control plane global access to reach a private endpoint from other regions.

Data plane and networking features

• GKE Dataplane V2 is based on Cilium and eBPF: built-in network policy enforcement (no Calico add-on needed), logging of policy actions and better observability. Enable at cluster creation; it cannot be switched on later for an existing cluster.
• Network policies: Kubernetes NetworkPolicy objects restrict pod-to-pod traffic. Without Dataplane V2, enabling network policy needs Calico and node pool recreation.
• SNAT and IP masquerade: pod traffic to destinations outside of the pod range is source-NATed to the node IP by default, except to the configured non-masquerade CIDRs (RFC 1918 ranges by default in Standard). Tune it with the ip-masq-agent ConfigMap or the Autopilot/Dataplane V2 egress NAT policy CRD when on-premises must see pod IPs.
• DNS: kube-dns (default), Cloud DNS for GKE (cluster scope, or additive VPC scope so VMs resolve Services) and NodeLocal DNSCache. Cloud DNS scales better and removes in-cluster DNS pods. The external-dns controller creates Cloud DNS records from Services and Ingresses.
• Load balancing: GKE Ingress creates an external or internal Application Load Balancer; Gateway API (GKE Gateway controller with classes like gke-l7-global-external-managed, gke-l7-regional-external-managed, gke-l7-rilb) is the successor with richer routing and multi-cluster options. Container-native load balancing uses NEGs so the LB sends traffic straight to Pod IPs, skipping kube-proxy hops. Services of type LoadBalancer create passthrough Network LBs (or internal passthrough with an annotation).
• Node pools hold nodes of one configuration; adding pools lets you use different machine types, private or public nodes, and different pod ranges. Upgrade strategy and autoscaling are set per pool.
• Multi-cluster Services and multi-cluster Gateway expose Services across clusters using fleet features.