Google Cloud VPC: Subnets, Firewalls, Routes, and NAT

VPC Networking Overview

A Google Cloud VPC network is a global resource containing regional subnets, routes, and firewall policy. Workloads receive interfaces in subnet ranges and communicate according to routes plus authorization controls.

A private VM does not need a public address to reach every destination. Private Google Access covers supported Google APIs, while Cloud NAT provides managed outbound translation for general internet destinations without accepting unsolicited inbound connections.

IP Address Plan

Custom-mode networks make subnet creation explicit. Choose non-overlapping primary and secondary ranges with room for workloads, GKE pods and services, private service access, hybrid routing, and future regions.

Overlapping ranges make peering and hybrid connectivity difficult. Record ownership and allocation in an IP address plan rather than letting each project choose independently.

Firewall Targets

Firewall rules are stateful. Use source ranges or identities that represent the caller, and target service accounts or controlled tags that represent the destination. Priority determines which applicable rule wins.

Opening 0.0.0.0/0 for SSH or a database turns a routing test into a security exposure. Use Identity-Aware Proxy, a managed load balancer, VPN, or another deliberate administration path.

Give a private subnet outbound access through Cloud NAT

gcloud compute routers create app-router \
  --network=vpc-app --region=us-central1

gcloud compute routers nats create app-nat \
  --router=app-router --region=us-central1 \
  --auto-allocate-nat-external-ips \
  --nat-all-subnet-ip-ranges \
  --enable-logging

Cloud NAT is regional and depends on a Cloud Router.
NAT logs help investigate allocation and translation failures but can add logging cost.

Connectivity and Exposure

Shared VPC centralizes network administration while service projects own workloads. VPC Network Peering exchanges routes between networks but is not transitive. VPN and Interconnect extend connectivity to external networks with different throughput and availability models.

Use Connectivity Tests, effective routes, firewall logging, load balancer health, DNS inspection, and service logs to identify the failed hop. A successful ping does not prove an application port, TLS identity, or IAM policy works.

Global Network and Regional Subnets

A Google Cloud VPC is global, while its subnets are regional. Plan non-overlapping IPv4 and IPv6 ranges for current workloads, GKE Pods and Services, private service access, hybrid routes, peers, and growth. An address plan that works for one project can block Shared VPC, Network Connectivity Center, VPN, Interconnect, or acquisition integration later.

Shared VPC lets a host project own networks and service projects consume approved subnets. This separates central network administration from workload resource administration, but it also creates cross-project IAM and troubleshooting boundaries. Document who owns subnets, firewalls, routes, DNS, service identities, and incident response before onboarding service projects.

Subnets do not automatically represent trust zones. Segmentation comes from project boundaries, hierarchical firewall policies, VPC firewall rules, service perimeters, load-balancer design, and application authorization. Use a separate VPC when administrative ownership, routing domain, or blast radius truly differs; avoid creating networks merely to reproduce physical data-center habits.

Reserve address space for regional growth and managed services.
Record every overlapping range before adding hybrid connectivity.
Use Shared VPC roles instead of broad host-project ownership.
Treat IP boundaries as one layer, not the user authorization model.

Routes and Firewall Decisions

Routes choose a next hop for egress traffic; firewall policy decides whether relevant ingress or egress packets are allowed. A correct route cannot override a deny, and an allow rule cannot create a missing path. Diagnose destination DNS result, selected route, rule priority and target, source identity or range, return path, and any proxy or translation separately.

Google Cloud uses a distributed routing system rather than a virtual router appliance attached to each VPC. Route types and priorities determine the selected path, while dynamic routing mode affects learned route behavior across regions. Policy-based routes are evaluated differently from ordinary subnet, static, peering, and dynamic routes. Verify effective routes on the actual interface instead of reading only the rule you expected to win.

Firewall rules are stateful for allowed connections and can target service accounts or network tags where supported. Prefer service-account targets for stable workload identity and govern who can attach that identity. Enable firewall rule logging selectively for investigation and validation; logging every allowed packet can create cost and noise without improving decisions.

Test ingress and egress from the real source and destination.
Name rules with direction, purpose, owner, and expiry.
Review implied rules and hierarchical policies.
Remove temporary broad rules after diagnosis.

Private Egress and Google APIs

A VM without an external IP needs a deliberate egress path. Public Cloud NAT provides source translation for supported outbound connections without accepting unsolicited inbound sessions. Size NAT IPs and ports for connection fan-out, monitor port exhaustion and dropped packets, and remember that NAT is not an application proxy or an authorization control.

Private Google Access lets eligible resources with internal IP addresses reach Google APIs and services through defined Google endpoints when DNS and routing are configured correctly. The default, private, and restricted API domains have different reach and control implications. Requests still require valid IAM authorization, and VPC Service Controls may restrict data movement independently of the network path.

Private Service Connect, private services access, and peering solve different producer-consumer connectivity models. Confirm address allocation, DNS ownership, route exchange, transitivity limits, service attachment policy, and failure behavior before selecting one. A private IP address can still cross organizational or service trust boundaries, so authenticate every request.

Monitor NAT port use and allocate deterministic egress where partners require it.
Test Google API DNS and routes from private workloads.
Document which private connectivity mechanism each service uses.
Keep service authorization independent from network reachability.

Hybrid and Network Diagnostics

Cloud VPN provides encrypted tunnels, while Cloud Interconnect provides dedicated connectivity options; Cloud Router exchanges routes through BGP for supported products. Design redundant devices, links, tunnels, BGP sessions, and regions according to availability objectives. Redundancy on the Google side does not protect a single customer router, carrier path, DNS dependency, or on-premises firewall.

Use Network Intelligence Center capabilities such as Connectivity Tests, Network Topology, Performance Dashboard, and Firewall Insights to form hypotheses, then confirm with application telemetry and packet-level evidence where appropriate. VPC Flow Logs sample network flows and help answer who communicated with whom, but they are not a full packet capture and their aggregation and sampling settings affect interpretation.

Run failure exercises for a tunnel, BGP session, region, NAT gateway configuration, DNS zone, route advertisement, firewall policy, and exhausted subnet. Measure reconvergence and application recovery, not only link status. Keep an approved emergency path for correcting network policy that does not depend on the broken route.

Diagram forward and return paths with route ownership.
Alert on BGP, tunnel, NAT, DNS, and packet-loss symptoms.
Correlate flow records with load balancer and application logs.
Practice rollback for firewall and route changes.

DNS and Load Balancing Path

DNS decides which endpoint the client attempts before routes and firewalls matter. Document public and private Cloud DNS zones, forwarding and peering zones, response policies, split-horizon names, resolver paths, TTLs, and ownership. Test from each relevant VPC and on-premises network because the same name can intentionally return different answers.

For a load-balanced service, trace forwarding rule, IP address, proxy or passthrough behavior, target proxy, URL map where applicable, backend service, health check, firewall allowance, and backend response. Health-check success proves a configured probe reaches a backend; it does not prove user authentication, a deep dependency, or the complete business journey.

Plan DNS and certificate changes as releases. Lower TTL before a migration when appropriate, wait for prior values to age out, validate both old and new endpoints, and keep rollback available. Monitor NXDOMAIN, SERVFAIL, certificate expiry, unhealthy backends, and regional traffic distribution alongside application indicators.

Cloud DNS changes propagate quickly inside the authoritative service, but recursive resolvers and clients can retain prior answers until TTL expiry. Negative answers can also be cached. During diagnosis, query the authoritative name servers and the client resolver separately, include record type, and verify that private-zone visibility or forwarding order selects the intended zone.

Query DNS from the actual client network.
Separate endpoint health from business success.
Test certificate and DNS rollback before migration.
Record every component in the load-balancer path.
Verify IPv4 and IPv6 where both address families are published.
Test private DNS from every attached consumer network.
Confirm health probes use the intended port and protocol.
Validate return routes through every hybrid attachment.
Check resolver policy after network peering changes.

VPC Diagnostic Examples

Diagnose Private Google API Access

A VM without an external address cannot reach a Google API endpoint.

Diagnose Private Google API Access

Constraints: The subnet should use private API access and outbound internet traffic is prohibited.
Decision: Trace DNS selection, subnet private-access setting, routes, hierarchical firewall policy, and the service perimeter.
Verification: Connectivity Tests and an application request show the private path succeeds without a public address.
Failure test: Disable private access in a test subnet and confirm the same request fails at the expected boundary.

Output

Expected evidence: Connectivity Tests and an application request show the private path succeeds without a public address.

This is a worked engineering decision, so the result is operational evidence rather than terminal output.

Before you move on