GCP Networking Deep Dive

GCP Networking Architecture

Google Cloud's networking stack is fundamentally different from traditional cloud providers. It is built on the same infrastructure that powers Google Search, YouTube, and Gmail: a global software-defined network spanning more than 180 points of presence and connected by a private fiber backbone. Understanding this architecture is critical for designing low-latency, high-throughput systems.

Key architectural differences from other clouds: VPCs are global (not regional), load balancers use Anycast IPs for global distribution, and GCP offers two distinct network tiers (Premium and Standard) that control how traffic traverses between users and your infrastructure. These differences mean that networking patterns that work well on AWS or Azure may not be optimal on GCP, and vice versa.

GCP's networking is entirely software-defined. There are no physical appliances for load balancers, NAT gateways, or firewalls; everything is implemented in the network fabric. This means there are no single points of failure, no manual capacity planning for network components, and no throughput ceilings from hardware limitations.

Network Service Tiers

GCP is the only major cloud provider that offers a choice of network tiers. This decision significantly affects latency, throughput, and cost. The tier is selected per-resource (per external IP address or forwarding rule), not per-project, so you can mix tiers for different workloads.

How Premium Tier Works

When a user in Tokyo accesses your service in us-central1 on Premium Tier, the traffic enters Google's network at the Tokyo POP (point of presence) and traverses Google's private fiber backbone all the way to the data center. This is significantly faster and more reliable than Standard Tier, where the traffic would traverse the public internet across multiple ISP networks before reaching Google's network in the us-central1 region.

The latency difference is typically 50-200ms depending on the user's location relative to the nearest Google POP. For global applications serving users across continents, this difference is significant.

Load Balancing Deep Dive

GCP offers a sophisticated load balancing system with multiple proxy and passthrough modes. Unlike traditional hardware load balancers, GCP LBs are software-defined and scale automatically. They handle millions of requests per second without pre-warming or capacity planning. Choosing the right type depends on your protocol, scope, and backend type.

External Application Load Balancer

The External Application Load Balancer (formerly HTTP(S) LB) is the most commonly used load balancer in GCP. It is based on Google's Envoy proxy and provides Layer 7 features including:

• URL-based routing (route different paths to different backends)
• Host-based routing (route different domains to different backends)
• Managed SSL certificates (automatic provisioning and renewal)
• Cloud CDN integration for content caching
• Cloud Armor integration for DDoS protection and WAF
• WebSocket and gRPC support
• Connection draining for graceful backend removal
• Custom request/response headers

# 1. Create a health check
gcloud compute health-checks create http my-hc \
  --port=8080 \
  --request-path=/healthz \
  --check-interval=10s \
  --healthy-threshold=2 \
  --unhealthy-threshold=3

# 2. Create a backend service
gcloud compute backend-services create my-backend \
  --protocol=HTTP \
  --port-name=http \
  --health-checks=my-hc \
  --global \
  --enable-cdn \
  --connection-draining-timeout=300

# 3. Add serverless NEG (for Cloud Run backend)
gcloud compute network-endpoint-groups create my-serverless-neg \
  --region=us-central1 \
  --network-endpoint-type=serverless \
  --cloud-run-service=my-api

gcloud compute backend-services add-backend my-backend \
  --global \
  --network-endpoint-group=my-serverless-neg \
  --network-endpoint-group-region=us-central1

# 4. Create URL map with path-based routing
gcloud compute url-maps create my-url-map \
  --default-service=my-backend

gcloud compute url-maps add-path-matcher my-url-map \
  --path-matcher-name=api-paths \
  --default-service=my-backend \
  --path-rules="/api/*=my-api-backend,/static/*=my-cdn-backend"

# 5. Create managed SSL certificate
gcloud compute ssl-certificates create my-cert \
  --domains=api.example.com,www.example.com \
  --global

# 6. Create target HTTPS proxy
gcloud compute target-https-proxies create my-https-proxy \
  --url-map=my-url-map \
  --ssl-certificates=my-cert

# 7. Create forwarding rule (Anycast IP)
gcloud compute forwarding-rules create my-https-fr \
  --global \
  --target-https-proxy=my-https-proxy \
  --ports=443

# 8. Create HTTP-to-HTTPS redirect
gcloud compute url-maps import http-redirect \
  --source=/dev/stdin <<EOF
name: http-redirect
defaultUrlRedirect:
  httpsRedirect: true
  redirectResponseCode: MOVED_PERMANENTLY_DEFAULT
EOF

gcloud compute target-http-proxies create http-redirect-proxy \
  --url-map=http-redirect

gcloud compute forwarding-rules create http-redirect-fr \
  --global \
  --target-http-proxy=http-redirect-proxy \
  --ports=80

Cloud Armor: DDoS Protection and WAF

Cloud Armor provides DDoS protection and Web Application Firewall (WAF) capabilities for applications behind the External Application Load Balancer. It is the GCP equivalent of AWS WAF + Shield.

# Create a Cloud Armor security policy
gcloud compute security-policies create my-security-policy \
  --description="Production WAF policy"

# Block traffic from specific countries
gcloud compute security-policies rules create 1000 \
  --security-policy=my-security-policy \
  --expression="origin.region_code == 'CN' || origin.region_code == 'RU'" \
  --action=deny-403 \
  --description="Block traffic from specific regions"

# Rate limiting: max 100 requests per minute per IP
gcloud compute security-policies rules create 2000 \
  --security-policy=my-security-policy \
  --expression="true" \
  --action=throttle \
  --rate-limit-threshold-count=100 \
  --rate-limit-threshold-interval-sec=60 \
  --conform-action=allow \
  --exceed-action=deny-429 \
  --enforce-on-key=IP

# OWASP Top 10 protection (preconfigured WAF rules)
gcloud compute security-policies rules create 3000 \
  --security-policy=my-security-policy \
  --expression="evaluatePreconfiguredExpr('sqli-v33-stable')" \
  --action=deny-403 \
  --description="Block SQL injection attacks"

gcloud compute security-policies rules create 3001 \
  --security-policy=my-security-policy \
  --expression="evaluatePreconfiguredExpr('xss-v33-stable')" \
  --action=deny-403 \
  --description="Block XSS attacks"

# Attach the policy to a backend service
gcloud compute backend-services update my-backend \
  --security-policy=my-security-policy \
  --global

Private Connectivity Options

GCP provides multiple paths for private connectivity to managed services, on-premises networks, and other clouds. Each has different latency, bandwidth, and cost characteristics. Choosing the right connectivity option is one of the most impactful networking decisions for hybrid and multi-cloud architectures.

Private Service Connect (PSC)

PSC creates private endpoints in your VPC that route to Google-managed services (Cloud SQL, GKE, Vertex AI) or to your own services published in another VPC. Traffic stays entirely within Google's network and uses private IP addresses from your VPC's CIDR range. PSC is the most secure and flexible private connectivity option.

PSC supports two modes:

• PSC for Google APIs: Creates a single endpoint in your VPC that provides access to all Google APIs (or a specific bundle). Replaces the need for Private Google Access.
• PSC for Published Services: Allows you to publish a service in one VPC and consume it from another VPC via a private endpoint. Works across projects and organizations.

# PSC for Google APIs
gcloud compute addresses create psc-google-apis \
  --global \
  --purpose=PRIVATE_SERVICE_CONNECT \
  --addresses=10.10.34.1 \
  --network=prod-vpc

gcloud compute forwarding-rules create psc-apis-fr \
  --global \
  --network=prod-vpc \
  --address=psc-google-apis \
  --target-google-apis-bundle=all-apis

# PSC for a published service (consumer side)
gcloud compute addresses create my-psc-address \
  --region=us-central1 \
  --subnet=prod-us-central1 \
  --addresses=10.10.0.100

gcloud compute forwarding-rules create my-psc-endpoint \
  --region=us-central1 \
  --network=prod-vpc \
  --address=my-psc-address \
  --target-service-attachment=projects/provider-project/regions/us-central1/serviceAttachments/my-service

Cloud Interconnect

Dedicated Interconnect provides a physical, private connection between your data center and Google's network. It supports 10 Gbps or 100 Gbps circuits and offers an SLA of 99.99% with redundant connections. Partner Interconnect is available through service providers for lower bandwidth needs (50 Mbps to 50 Gbps).

Cloud VPN

HA VPN provides encrypted tunnels over the public internet with a 99.99% SLA (when configured with the recommended 4-tunnel topology). Each tunnel supports up to 3 Gbps. VPN is the quickest path to hybrid connectivity but is limited by internet bandwidth and latency.

# Create HA VPN gateway
gcloud compute vpn-gateways create my-ha-vpn \
  --network=prod-vpc \
  --region=us-central1

# Create external VPN gateway (on-prem side)
gcloud compute external-vpn-gateways create on-prem-gw \
  --interfaces=0=203.0.113.1,1=203.0.113.2

# Create Cloud Router with BGP ASN
gcloud compute routers create vpn-router \
  --network=prod-vpc \
  --region=us-central1 \
  --asn=65001

# Create VPN tunnels (4 tunnels for full HA)
for i in 0 1; do
  for j in 0 1; do
    gcloud compute vpn-tunnels create tunnel-${i}-${j} \
      --vpn-gateway=my-ha-vpn \
      --vpn-gateway-interface=${i} \
      --peer-external-gateway=on-prem-gw \
      --peer-external-gateway-interface=${j} \
      --shared-secret=MY_SHARED_SECRET \
      --router=vpn-router \
      --region=us-central1 \
      --ike-version=2
  done
done

Cloud NAT Deep Dive

Cloud NAT is a managed, software-defined NAT gateway that provides outbound internet access for VMs without external IPs. Unlike traditional NAT appliances, Cloud NAT is implemented in the network fabric, so there is no VM or appliance to manage, patch, or scale. It provides high availability with no single point of failure.

NAT Configuration and Sizing

Each NAT IP address supports approximately 64,000 concurrent connections (ports). For workloads with high connection counts (like web scrapers or API clients making many concurrent requests), you need to plan your NAT IP and port allocation carefully.

# Create Cloud Router
gcloud compute routers create prod-router \
  --network=prod-vpc \
  --region=us-central1

# Create Cloud NAT with dynamic port allocation
gcloud compute routers nats create prod-nat \
  --router=prod-router \
  --region=us-central1 \
  --auto-allocate-nat-external-ips \
  --nat-all-subnet-ip-ranges \
  --enable-logging \
  --log-filter=ERRORS_ONLY \
  --min-ports-per-vm=2048 \
  --enable-dynamic-port-allocation \
  --max-ports-per-vm=65536 \
  --tcp-established-idle-timeout=1200 \
  --tcp-transitory-idle-timeout=30 \
  --udp-idle-timeout=30

# Use static IPs for allowlisting at third parties
gcloud compute addresses create nat-ip-1 nat-ip-2 nat-ip-3 \
  --region=us-central1

gcloud compute routers nats update prod-nat \
  --router=prod-router \
  --region=us-central1 \
  --nat-external-ip-pool=nat-ip-1,nat-ip-2,nat-ip-3

# Monitor NAT port allocation
gcloud compute routers get-nat-mapping-info prod-router \
  --region=us-central1

Cloud DNS Advanced Configuration

Cloud DNS is a managed, authoritative DNS service with 100% availability SLA. Beyond basic DNS resolution, it provides several advanced features for enterprise networking:

DNS Features Overview

• DNS Peering: Forward DNS queries from one VPC to another, enabling cross-project name resolution without exposing records publicly.
• Private Zones: Create DNS records visible only within specified VPC networks. Essential for internal service discovery.
• Response Policies: Override DNS responses for specific domains. Useful for blocking malicious domains or redirecting internal services.
• DNSSEC: Sign your zones to prevent DNS spoofing. Cloud DNS supports both zone signing and validation.
• DNS Forwarding: Forward queries for specific zones to on-premises DNS servers for hybrid DNS resolution.

# Create a private zone for internal service discovery
gcloud dns managed-zones create internal-zone \
  --dns-name="internal.example.com." \
  --visibility=private \
  --networks=projects/my-project/global/networks/prod-vpc

# Add service records
for svc in api db cache worker queue; do
  gcloud dns record-sets create $svc.internal.example.com. \
    --zone=internal-zone \
    --type=A \
    --ttl=60 \
    --rrdatas="10.10.0.$((RANDOM % 254 + 1))"
done

# Create SRV records for service port discovery
gcloud dns record-sets create _grpc._tcp.api.internal.example.com. \
  --zone=internal-zone \
  --type=SRV \
  --ttl=60 \
  --rrdatas="10 0 8080 api.internal.example.com."

Network Intelligence Center

Network Intelligence Center is a suite of tools for monitoring, verifying, and troubleshooting network configurations. It provides visibility that would otherwise require manual packet capture and analysis.

Connectivity Tests

Connectivity Tests simulate a packet from source to destination and show exactly where it would be dropped (firewall, route, NAT). This is invaluable for debugging connectivity issues without needing SSH access to VMs.

# Test connectivity between two VMs
gcloud network-management connectivity-tests create test-web-to-db \
  --source-instance=projects/my-project/zones/us-central1-a/instances/web-server \
  --destination-instance=projects/my-project/zones/us-central1-a/instances/db-server \
  --destination-port=5432 \
  --protocol=TCP

# Check results
gcloud network-management connectivity-tests describe test-web-to-db \
  --format="yaml(reachabilityDetails)"

# Test external connectivity
gcloud network-management connectivity-tests create test-internet \
  --source-instance=projects/my-project/zones/us-central1-a/instances/web-server \
  --destination-ip-address=8.8.8.8 \
  --destination-port=443 \
  --protocol=TCP

Firewall Insights

Firewall Insights identifies overly permissive firewall rules, shadowed rules (rules that never match because a higher-priority rule already matches), and rules with deny-hits that may indicate an attack.

# Find shadowed (unused) firewall rules
gcloud recommender insights list \
  --insight-type=google.compute.firewall.Insight \
  --project=my-project \
  --location=global \
  --filter="category=SHADOWED_RULE" \
  --format="table(content.firewallRuleDetails.displayName, stateInfo.state)"

# Find overly permissive rules
gcloud recommender insights list \
  --insight-type=google.compute.firewall.Insight \
  --project=my-project \
  --location=global \
  --filter="category=OVERLY_PERMISSIVE" \
  --format="table(content.firewallRuleDetails.displayName)"

# Get firewall rule hit counts
gcloud compute firewall-rules list \
  --project=my-project \
  --format="table(name, direction, priority, disabled, hitCount.count)"

Performance Dashboard

The Performance Dashboard monitors packet loss and latency between your GCP resources and across regions. It helps identify network degradation before it impacts users and provides historical data for capacity planning.

Network Topology

Network Topology visualizes your VPC topology, traffic flows, and bandwidth utilization in real time. It shows how traffic flows between regions, zones, subnets, and individual VMs, making it easy to identify unexpected cross-region traffic that is adding cost and latency.

Network Security Best Practices

Network security in GCP involves multiple layers of defense. No single control is sufficient; you need defense in depth with overlapping controls.

Defense in Depth Layers

1. Organization policies: Block external IPs on VMs, restrict allowed regions, require shielded VMs.
2. Hierarchical firewall policies: Organization-wide rules that enforce baseline security regardless of project-level configurations.
3. VPC firewall rules: Network-specific rules targeting service accounts (not tags) for production workloads.
4. Cloud Armor: DDoS protection and WAF for internet-facing services behind the load balancer.
5. VPC Service Controls: Data exfiltration prevention for sensitive services.
6. Private connectivity: Cloud NAT, Private Google Access, and Private Service Connect to minimize internet exposure.

Multi-Cloud Networking

For organizations with workloads spanning GCP, AWS, and Azure, network connectivity between clouds requires careful design. GCP provides several options for cross-cloud connectivity:

• HA VPN to AWS/Azure: The simplest option. Create HA VPN connections to AWS VPN Gateway or Azure VPN Gateway. Each tunnel supports up to 3 Gbps.
• Dedicated/Partner Interconnect: For higher bandwidth cross-cloud connectivity, use Interconnect to a colocation facility that also hosts connections to other clouds.
• Cross-Cloud Interconnect: GCP offers direct Interconnect connections to AWS and Azure in specific locations, providing the lowest latency cross-cloud connectivity.
• Network Connectivity Center: Use NCC as a hub for managing all connectivity (VPCs, on-premises, other clouds) from a single control plane.

Network Audit Checklist

Periodically review your network configuration against this checklist to identify security gaps, performance issues, and cost optimization opportunities.