GCP Networking - Professional Cloud Architect¶

Characteristics:
- One subnet per region created automatically
- Predictable IP ranges: 10.128.0.0/20 per region
- New regions get subnets automatically
- Can be converted to custom mode (one-way operation)
- Default firewall rules included

When to Use:
- Development/testing environments
- Quick prototypes
- Learning/training scenarios
- Simple applications without complex networking

When to Avoid:
- Production environments
- IP range conflicts with on-premises
- Multiple VPCs needing to peer
- Strict compliance requirements

Characteristics:
- Complete control over subnet creation
- Define your own IP ranges
- No automatic subnet creation
- Must explicitly create all subnets
- Production-ready from the start

When to Use:
- Production workloads (always)
- Hybrid cloud architectures
- Multiple VPCs requiring peering
- Organizations with IP allocation policies
- Compliance and security requirements

Best Practices:
- Plan IP addressing scheme upfront
- Document subnet purposes
- Use consistent naming conventions
- Leave room for growth (30-40% spare capacity)
- Consider secondary ranges for GKE/containers

Use Case: Simple application, single team
Architecture:
├── VPC: production-vpc (global)
    ├── Subnet: web-tier (us-central1) - 10.1.1.0/24
    ├── Subnet: app-tier (us-central1) - 10.1.2.0/24
    ├── Subnet: db-tier (us-central1) - 10.1.3.0/24
    └── Subnet: web-tier (us-east1) - 10.2.1.0/24

Benefits:
- Simple to manage
- Low latency between regions
- No VPC peering needed
- Unified firewall rules

Limitations:
- Single blast radius
- No network isolation between teams
- Harder to enforce separation of duties

Use Case: Multiple environments, team isolation
Architecture:
├── VPC: prod-vpc
│   └── Subnets: production workloads
├── VPC: staging-vpc
│   └── Subnets: staging workloads
├── VPC: dev-vpc
│   └── Subnets: development workloads
└── VPC: shared-services-vpc
    └── Subnets: DNS, monitoring, logging

Benefits:
- Environment isolation
- Independent security policies
- Blast radius containment
- Team autonomy

Considerations:
- Requires VPC peering for connectivity
- More complex to manage
- Higher operational overhead

Use Case: Enterprise with multiple projects
Architecture:
Host Project (Network Admin)
├── VPC: shared-vpc (global)
    ├── Subnet: prod-subnet (shared with project-a)
    ├── Subnet: staging-subnet (shared with project-b)
    └── Subnet: shared-services (available to all)

Service Projects (Compute Admin)
├── project-a: Uses prod-subnet
├── project-b: Uses staging-subnet
└── project-c: Uses shared-services

Benefits:
- Centralized network administration
- Unified security policies
- Cost allocation per project
- Simplified connectivity

Requirements:
- Organization-level resource
- Specific IAM roles (Shared VPC Admin)
- Network admins separate from compute admins

Subnet Sizing Guidelines:
/24 (254 usable IPs): Small applications, dev environments
/22 (1022 usable IPs): Medium applications, typical workloads
/20 (4094 usable IPs): Large applications, GKE clusters
/16 (65534 usable IPs): Very large deployments, future growth

Exam Tip: Always account for 4 reserved IPs per subnet
- .0: Network address
- .1: Gateway (default route)
- .2: Second-to-last (Google reserved)
- .255: Broadcast address (for /24)

Purpose: IP aliasing for pods and services
Primary Range: 10.0.1.0/24 (VM instances - 254 IPs)
Secondary Range 1: 10.100.0.0/16 (GKE pods - 65,534 IPs)
Secondary Range 2: 10.200.0.0/20 (GKE services - 4,094 IPs)

Exam Scenarios:
Q: GKE cluster needs 1000 pods, how to configure?
A: Primary for nodes, secondary for pods (size appropriately)

Q: Running out of pod IPs, what to do?
A: Add secondary range, cannot expand existing secondary

Calculation Example:
- 50 nodes
- 110 pods per node (GKE default max)
- Total pods: 5,500
- Need: At least /19 (8,192 IPs) for pod range

Purpose: Access Google APIs without external IPs
Configuration: Per-subnet setting

Services Accessible:
- Cloud Storage (gs://)
- BigQuery
- Container Registry
- Artifact Registry
- Cloud Monitoring/Logging
- Pub/Sub
- Dataflow, Dataproc
- ML APIs (Vision, NLP, etc.)

Services NOT Accessible:
- Third-party APIs
- General internet access
- Other cloud providers
- Non-Google services

Exam Question Pattern:
"VM has no external IP, cannot access Cloud Storage"
Answer: Enable Private Google Access on subnet

Configuration:
gcloud compute networks subnets update SUBNET \
  --region=REGION \
  --enable-private-ip-google-access

Important: VMs need internal IP and route to 199.36.153.4/30

Evolution of Private Google Access:
PGA → PSC (more control, uses internal IPs)

Benefits vs Private Google Access:
- Uses VPC internal IPs (not 199.36.153.4/30)
- More granular access control
- Works with VPC-SC perimeters
- Supports DNS configuration
- Better for hybrid architectures

Setup:
gcloud compute addresses create psc-endpoint \
  --global \
  --purpose=PRIVATE_SERVICE_CONNECT \
  --addresses=10.0.5.5 \
  --network=my-vpc

gcloud compute forwarding-rules create psc-rule \
  --global \
  --network=my-vpc \
  --address=psc-endpoint \
  --target-google-apis-bundle=all-apis

Exam Tip: Choose PSC over PGA for scenarios requiring:
- On-premises access to Google APIs via hybrid connectivity
- VPC Service Controls integration
- Custom DNS requirements

Example: 10.1.1.0/24 subnet
10.1.1.0   - Network address (reserved)
10.1.1.1   - Default gateway (reserved)
10.1.1.2   - Reserved by Google for future use
10.1.1.254 - Reserved by Google for future use
10.1.1.255 - Broadcast address (reserved)

Usable range: 10.1.1.3 to 10.1.1.253 (251 IPs from /24)

Exam Calculation:
Subnet /24: 256 - 4 = 252 usable IPs (actual: 251)
Subnet /22: 1024 - 4 = 1020 usable IPs (actual: 1019)

Metadata Server: 169.254.169.254
- Accessible from all instances
- Provides instance metadata
- Cannot be blocked by firewall

Private Google Access: 199.36.153.4/30
- Used when PGA enabled
- Routes Google API traffic internally

Default Internet Gateway: 0.0.0.0/0 → internet gateway
- Automatically created in VPC
- Used for external connectivity

Cloud DNS: 169.254.169.254
- Internal DNS resolution
- Always available to instances

default-allow-internal: Allow all traffic between VPC instances
default-allow-ssh: Allow SSH (tcp:22) from anywhere  
default-allow-rdp: Allow RDP (tcp:3389) from anywhere
default-allow-icmp: Allow ICMP from anywhere

Start: What type of traffic?
│
├─ HTTP(S) Traffic
│  │
│  ├─ Internal (within GCP)?
│  │  ├─ Single region → Internal HTTP(S) LB
│  │  └─ Multiple regions → Cross-Region Internal HTTP(S) LB
│  │
│  └─ External (from internet)?
│     ├─ Single region → Regional External HTTP(S) LB
│     └─ Multiple regions → Global External HTTP(S) LB
│
├─ TCP Traffic (non-HTTP)
│  │
│  ├─ Internal?
│  │  └─ Regional Internal TCP/UDP LB
│  │
│  └─ External?
│     ├─ Need SSL termination → Global SSL Proxy LB
│     ├─ Need global distribution → Global TCP Proxy LB
│     └─ Regional, preserve IPs → Regional Network LB
│
└─ UDP Traffic
   └─ Regional Network LB (external) or Internal TCP/UDP LB (internal)

Exam Tip: Global = Anycast IP, Regional = Regional IP

                    Internet
                       │
                   [Anycast IP]
                  35.244.x.x (Global)
                       │
        ┌──────────────┼──────────────┐
        │              │              │
   [us-central1]  [europe-west1]  [asia-east1]
        │              │              │
    ┌───┴───┐      ┌───┴───┐      ┌───┴───┐
    │Backend│      │Backend│      │Backend│
    │Service│      │Service│      │Service│
    └───────┘      └───────┘      └───────┘
        │              │              │
    [Instance      [Instance      [Instance
     Groups]        Groups]        Groups]

Traffic Flow:
1. User connects to anycast IP
2. Google edge forwards to nearest healthy backend
3. Response returns through same edge
4. Cloud CDN can cache responses at edge

Key Features:
- Single global IP address (anycast)
- Automatic multi-region failover
- Cloud CDN integration
- Cloud Armor for security
- SSL termination at edge
- Content-based routing (URL maps)
- WebSocket support
- HTTP/2 and gRPC support

1. ROUND_ROBIN (default)
   - Distributes requests evenly
   - Good for uniform workloads
   - No session awareness

2. LEAST_REQUEST
   - Routes to backend with fewest active requests
   - Good for varying request durations
   - Better resource utilization

3. RING_HASH (with Session Affinity)
   - Consistent hashing
   - Good for caching scenarios
   - Minimizes cache misses during scaling

4. RANDOM
   - Random selection
   - Simple, low overhead
   - Good for stateless applications

5. MAGLEV (Network LB)
   - Consistent hashing for Network LB
   - Minimizes connection disruption
   - Default for passthrough LBs

Configuration:
gcloud compute backend-services update BACKEND \
  --load-balancing-scheme=EXTERNAL \
  --locality-lb-policy=ROUND_ROBIN

Session Affinity Types:

1. NONE (default)
   - No affinity
   - Pure load distribution

2. CLIENT_IP
   - Hash of client IP
   - Good for stateful applications
   - Survives backend changes

3. GENERATED_COOKIE
   - LB generates cookie (GCLB)
   - Best for HTTP applications
   - Survives client IP changes

4. CLIENT_IP_PROTO
   - Client IP + protocol
   - More granular than CLIENT_IP

5. CLIENT_IP_PORT_PROTO
   - Client IP + port + protocol
   - Most granular
   - For Network LB

Configuration:
gcloud compute backend-services update web-backend \
  --session-affinity=GENERATED_COOKIE \
  --affinity-cookie-ttl=3600 \
  --global

Exam Scenario:
Q: Users losing shopping cart on load balanced site
A: Enable session affinity (GENERATED_COOKIE for HTTP)

Use Cases:
- Need to preserve source IP address
- UDP traffic (e.g., game servers, VoIP)
- Non-HTTP TCP traffic in single region
- Traffic doesn't need SSL termination
- Lower latency requirements (same region)

Architecture:
Regional IP (e.g., 35.1.2.3 in us-central1)
        ↓
Regional Network LB (passthrough)
        ↓
Backend instances (see actual client IP)

Configuration:
gcloud compute forwarding-rules create regional-lb \
  --region=us-central1 \
  --load-balancing-scheme=EXTERNAL \
  --network-tier=PREMIUM \
  --ip-protocol=TCP \
  --ports=80,443 \
  --backend-service=regional-backend

Benefits:
- Preserves source IP (no X-Forwarded-For needed)
- Lower latency (no proxy)
- Supports UDP
- Simpler troubleshooting

Limitations:
- Regional scope only
- No SSL termination at LB
- No content-based routing
- No Cloud CDN integration

Use Case: Microservices architecture, service mesh

Architecture:
    GCP VPC (10.0.0.0/8)
         │
    [Internal IP: 10.1.1.100]
         │
  Internal HTTP(S) LB (regional)
         │
    ┌────┴────┐
    │         │
[Backend1] [Backend2]
(10.1.2.x) (10.1.2.y)

Features:
- Private (RFC 1918) IP address
- Regional resource
- Proxy-based (Envoy)
- Supports all HTTP(S) LB features
- No internet exposure
- Cross-VPC support (via peering)

Configuration:
gcloud compute forwarding-rules create internal-lb \
  --load-balancing-scheme=INTERNAL_MANAGED \
  --network=my-vpc \
  --subnet=backend-subnet \
  --region=us-central1 \
  --ports=80 \
  --target-http-proxy=internal-proxy

Exam Pattern:
Q: Microservices need load balancing without internet exposure
A: Internal HTTP(S) Load Balancer

Use Case: Internal databases, legacy applications

Architecture:
    GCP VPC
         │
    [Internal IP: 10.1.1.50]
         │
  Internal TCP/UDP LB (passthrough)
         │
    ┌────┴────┐
    │         │
[Database1] [Database2]

Features:
- Preserves source IP
- Passthrough (not proxy)
- TCP and UDP support
- Regional scope
- High throughput, low latency

Configuration:
gcloud compute forwarding-rules create internal-tcp-lb \
  --load-balancing-scheme=INTERNAL \
  --network=my-vpc \
  --subnet=db-subnet \
  --region=us-central1 \
  --ip-protocol=TCP \
  --ports=3306 \
  --backend-service=db-backend

Use Cases:
- Internal database clustering
- Legacy application load balancing
- Internal DNS servers
- Internal caching layers

1. HTTP Health Check
   - Checks HTTP response code
   - Can check response body
   - Most common for web apps

2. HTTPS Health Check
   - SSL/TLS health check
   - Validates certificate (optional)
   - For secure applications

3. TCP Health Check
   - TCP connection test
   - No application-level check
   - For non-HTTP services

4. gRPC Health Check
   - Native gRPC health protocol
   - For gRPC services
   - Protocol buffer based

5. HTTP/2 Health Check
   - HTTP/2 protocol
   - For modern applications

User (Tokyo) → Google Edge (Tokyo) → [Cache Hit] → Return
                       │
                       └─→ [Cache Miss] → Origin (us-central1)
                                              ↓
                           Cache at edge ←──┘

Flow:
1. User requests content
2. Anycast routes to nearest Google edge
3. Edge checks cache
4. Cache hit: Return immediately (low latency)
5. Cache miss: Fetch from origin, cache, then return
6. Subsequent requests served from edge

Benefits:
- Lower latency for global users
- Reduced origin load
- Lower egress costs (cached traffic free from origin)
- DDoS protection (edge absorbs traffic)

Behavior: Respects Cache-Control headers from origin

Origin Response Headers:
Cache-Control: public, max-age=3600
  → Cached for 1 hour

Cache-Control: private, no-cache
  → Not cached

Cache-Control: public, max-age=86400, s-maxage=3600
  → Cached for 1 hour at CDN (s-maxage takes precedence)

When to Use:
- Dynamic content with proper cache headers
- Mixed cacheable/non-cacheable content
- Need fine-grained control per URL
- Best practice for most applications

Configuration:
gcloud compute backend-services update web-backend \
  --enable-cdn \
  --cache-mode=USE_ORIGIN_HEADERS \
  --global

Behavior: Automatically caches static content regardless of headers

Cached by Default:
- Images: .jpg, .jpeg, .png, .gif, .webp, .svg
- Video: .mp4, .webm, .ogg
- Scripts: .js
- Stylesheets: .css
- Documents: .pdf
- Fonts: .woff, .woff2, .ttf, .eot

NOT Cached:
- HTML files
- Dynamic content (.php, .aspx)
- Authenticated requests
- POST/PUT/DELETE requests

When to Use:
- Legacy applications without cache headers
- Quick CDN enablement without code changes
- Static asset heavy sites

Limitations:
- Less control than USE_ORIGIN_HEADERS
- May cache too much or too little

Behavior: Cache everything for specified TTL

Configuration:
gcloud compute backend-services update api-backend \
  --enable-cdn \
  --cache-mode=FORCE_CACHE_ALL \
  --default-ttl=3600 \
  --client-ttl=1800 \
  --max-ttl=86400 \
  --global

TTL Parameters:
- default-ttl: TTL when origin doesn't specify (default: 3600)
- client-ttl: TTL for client browsers (default: same as default-ttl)
- max-ttl: Maximum TTL allowed (default: 86400)

When to Use:
- Static sites (JAMstack)
- APIs with consistent responses
- Need to override origin headers
- Testing/development

Warnings:
- Can cache authenticated content (security risk)
- Can serve stale data
- Careful with dynamic content

Control what makes content unique in cache:

Default Cache Key:
- URL (scheme://host/path?query)

Custom Cache Key Options:
1. Include/exclude query string
2. Include/exclude specific query parameters
3. Include/exclude hostname
4. Include/exclude protocol

Configuration:
gcloud compute backend-services update web-backend \
  --cache-key-include-protocol \
  --cache-key-include-host \
  --cache-key-include-query-string \
  --cache-key-query-string-whitelist=product_id,category \
  --global

Exam Scenario:
Q: Different content for /api?user_id=123 vs /api?user_id=456
A: Include query string in cache key (default behavior)

Q: Same content for /api?user_id=123&session=xyz vs /api?user_id=123&session=abc
A: Include only user_id in cache key (whitelist)

Purpose: Restrict access to cached content

Signed URL Example:
https://example.com/video.mp4?Expires=1234567890&KeyName=my-key&Signature=abc123...

Process:
1. Generate key pair
2. Add public key to backend service
3. Application generates signed URLs
4. CDN validates signature before serving

Configuration:
# Create signing key
openssl genrsa -out private_key.pem 2048
openssl rsa -in private_key.pem -pubout -out public_key.pem

# Add key to backend service
gcloud compute backend-services add-signed-url-key web-backend \
  --key-name=my-key \
  --key-file=public_key.pem \
  --global

# Generate signed URL (in application)
import base64
import hashlib
import datetime

def sign_url(url, key_name, private_key, expiration_time):
    # Implementation details
    pass

Use Cases:
- Paid content (videos, documents)
- Time-limited access
- User-specific content
- License verification

Configuration:
gcloud compute backend-services update web-backend \
  --negative-caching \
  --negative-caching-policy=404=60,500=10 \
  --global

Behavior:
- Cache 404 responses for 60 seconds
- Cache 500 responses for 10 seconds
- Reduces origin load for errors
- Prevents error page fetch storms

Exam Tip: Enable negative caching to protect origin from repeated failed requests

Configuration:
gcloud compute backend-services update web-backend \
  --serve-while-stale=86400 \
  --global

Behavior:
- Serve stale content if origin is down
- Up to specified duration (86400s = 24 hours)
- Improves availability
- Marked with Warning header

Use Cases:
- High availability requirements
- Tolerate slightly stale content
- Origin maintenance windows

Key Metrics:
- Cache hit ratio (target: >80%)
- Cache fill bytes (origin egress)
- Request count by cache status
- Latency by cache status

View Metrics:
gcloud monitoring time-series list \
  --filter='metric.type="loadbalancing.googleapis.com/https/request_count"'

Logging:
- Enable CDN logging in backend service
- Logs include: cache status, latency, bytes
- Export to BigQuery for analysis

Troubleshooting:
Low cache hit ratio:
1. Check cache-control headers from origin
2. Verify cache key configuration
3. Look for high variation in URLs
4. Consider cache mode settings

Characteristics:
- Single VPN gateway (single point of failure)
- 99.9% SLA
- Static or dynamic routing
- Up to 3 Gbps per tunnel
- Being phased out

Exam Note: Know this exists but recommend HA VPN instead

Architecture:
┌─────────────────────────────────────────┐
│         On-Premises Network             │
│  ┌──────────┐         ┌──────────┐     │
│  │ Device 1 │         │ Device 2 │     │
│  └────┬─────┘         └─────┬────┘     │
│       │                     │          │
└───────┼─────────────────────┼──────────┘
        │    IPsec Tunnels    │
        │   (Encrypted)       │
┌───────┼─────────────────────┼──────────┐
│  ┌────▼─────┐         ┌─────▼────┐    │
│  │Interface0│         │Interface1│    │
│  └────┬─────┘         └─────┬────┘    │
│       └────────┬─────────────┘         │
│         HA VPN Gateway                 │
│         (Regional Resource)            │
│                                        │
│            GCP VPC Network             │
└────────────────────────────────────────┘

Key Features:
- Two external IP addresses (interfaces)
- 99.99% SLA when properly configured
- Requires two tunnels minimum
- Regional resource (not zonal)
- Automatic failover
- Up to 3 Gbps per tunnel (6+ Gbps total)
- Dynamic routing (BGP) required for SLA

SLA Requirements (Critical for Exam):
- Two on-premises VPN devices
- Two tunnels to each device (4 tunnels total)
- BGP routing configured
- Both interfaces active

Configuration Patterns:
1. Two on-prem devices: 4 tunnels (99.99% SLA)
2. One on-prem device: 2 tunnels (99.9% SLA)
3. Peer to another cloud: 2+ tunnels

Physical Connection to Google Network

Specifications:
├── Speeds: 10 Gbps or 100 Gbps per circuit
├── Location: Google Colocation Facilities
├── Latency: 1-2ms typical (depends on proximity)
├── SLA: 99.9% or 99.99% (with redundancy)
└── Cost: Port fee + egress (no ingress charges)

Architecture:
┌──────────────────────────────────────────┐
│     Your Data Center or Colo            │
│  ┌────────────┐                          │
│  │ Your Router│◄────── You manage       │
│  └──────┬─────┘                          │
└─────────┼────────────────────────────────┘
          │ (10/100 Gbps fiber)
          │ Cross-connect
┌─────────▼────────────────────────────────┐
│  ┌────────────┐                          │
│  │ Google Edge │                         │
│  │   Router    │◄────── Google manages   │
│  └──────┬─────┘                          │
│         │                                │
│    GCP Network                           │
└──────────────────────────────────────────┘

Use Cases:
- High bandwidth requirements (>3 Gbps sustained)
- Predictable network performance
- Lower egress costs than VPN
- Private access to Google services
- Regulatory/compliance requirements

Requirements:
- Physical presence in Google colo facility
- 10GBASE-LR or 100GBASE-LR optics
- BGP configuration
- Layer 3 connectivity
- Single-mode fiber

Cost Comparison (Monthly):
Port Fee: $1,700 (10G) or $27,000 (100G)
Egress: Significantly cheaper than internet egress
Breakeven: Typically 1-5 TB/month depending on region

Exam Scenarios:
Q: Company needs consistent 5 Gbps to GCP
A: Dedicated Interconnect (VPN max 3 Gbps per tunnel)

Q: Reduce network egress costs
A: Dedicated Interconnect (if traffic volume justifies)

Connection via Service Provider

Specifications:
├── Speeds: 50 Mbps to 50 Gbps (incremental)
├── Location: Service provider facilities
├── SLA: Depends on provider (typically 99.9%)
├── Setup: Faster than Dedicated (no colo needed)
└── Cost: Provider charges + GCP egress

Architecture:
┌──────────────────────────────────────────┐
│     Your Data Center                     │
│  ┌────────────┐                          │
│  │ Your Router│                          │
│  └──────┬─────┘                          │
└─────────┼────────────────────────────────┘
          │ (Connection to provider)
┌─────────▼────────────────────────────────┐
│  Service Provider Network                │
│  ┌────────────┐                          │
│  │  Provider  │                          │
│  │   Router   │                          │
│  └──────┬─────┘                          │
└─────────┼────────────────────────────────┘
          │ (Provider → Google connection)
┌─────────▼────────────────────────────────┐
│  ┌────────────┐                          │
│  │ Google Edge│                          │
│  │   Router   │                          │
│  └──────┬─────┘                          │
│         │                                │
│    GCP Network                           │
└──────────────────────────────────────────┘

Available Bandwidth Options:
50 Mbps, 100 Mbps, 200 Mbps, 300 Mbps, 400 Mbps, 500 Mbps
1 Gbps, 2 Gbps, 5 Gbps, 10 Gbps, 20 Gbps, 50 Gbps

Service Provider Selection:
- Check availability in your region
- Compare pricing and SLAs
- Verify supported locations
- Consider existing relationships

Use Cases:
- No presence in Google colo facilities
- Flexible bandwidth requirements
- Need faster deployment than Dedicated
- Testing before Dedicated Interconnect
- Multiple smaller connections

Exam Tip: Choose Partner over Dedicated when:
- Not in Google colo facility
- Need <10 Gbps bandwidth
- Want faster deployment
- Flexibility more important than cost

Architecture:
On-Premises Data Center
    ├── VPN/Interconnect → us-central1 (primary)
    ├── VPN/Interconnect → us-east1 (secondary)
    └── VPN/Interconnect → europe-west1 (DR)

Configuration Strategy:
1. Primary connection: Dedicated/Partner Interconnect
2. Backup: HA VPN to same region
3. DR: Interconnect or VPN to different region

BGP Configuration:
- Use AS-PATH prepending for preference
- Local preference for traffic engineering
- MED (Multi-Exit Discriminator) for return path
- BFD (Bidirectional Forwarding Detection) for fast failover

Exam Pattern:
Q: High availability hybrid connectivity
A: HA VPN (99.99%) or dual Dedicated Interconnect circuits

Requirements:
- On-premises VMs resolve GCP DNS names
- GCP VMs resolve on-premises DNS names
- Private zone management

Solution: Cloud DNS with Forwarding
┌─────────────────────────────────────────┐
│  On-Premises                            │
│  ├── DNS Server (company.local)        │
│  └── Forward *.googleapis.com → GCP    │
└─────────────────────────────────────────┘
           ↕ (VPN/Interconnect)
┌─────────────────────────────────────────┐
│  GCP                                    │
│  ├── Cloud DNS Private Zone            │
│  ├── Inbound Endpoint (on-prem queries)│
│  └── Outbound Policy (forward to       │
│      on-prem DNS)                       │
└─────────────────────────────────────────┘

Configuration:
# Create private zone
gcloud dns managed-zones create gcp-private \
  --description="GCP private zone" \
  --dns-name=gcp.company.local \
  --networks=my-vpc \
  --visibility=private

# Create DNS policy for outbound forwarding
gcloud dns policies create hybrid-dns-policy \
  --description="Forward to on-prem DNS" \
  --networks=my-vpc \
  --enable-inbound-forwarding \
  --alternative-name-servers=10.0.1.5,10.0.1.6

Purpose: Segment traffic over Interconnect

Topology:
Physical Connection (10/100G)
├── VLAN 100: Production (Attachment 1)
├── VLAN 200: Staging (Attachment 2)
├── VLAN 300: Development (Attachment 3)
└── VLAN 400: Management (Attachment 4)

Configuration:
gcloud compute interconnects attachments create prod-vlan \
  --region=us-central1 \
  --router=interconnect-router \
  --interconnect=my-interconnect \
  --vlan=100 \
  --candidate-subnets=169.254.100.0/29

Benefits:
- Logical separation over shared physical connection
- Different VPCs over same Interconnect
- QoS and traffic management
- Cost optimization (share port fees)

Limits:
- 8 VLAN attachments per Interconnect
- Must use /29 for BGP peering
- Cannot overlap subnets

Cloud Armor = WAF + DDoS Protection + Bot Management

Integration: Only with External HTTP(S) Load Balancers
Scope: Global (applies at edge)
Pricing: Per policy + per request evaluated

Architecture:
Internet → Cloud Armor (edge) → Load Balancer → Backends
              │
              ├─ Allow/Deny rules
              ├─ Rate limiting
              ├─ Geo-blocking
              └─ WAF rules (OWASP)

1. Per Client IP (most common)
   --enforce-on-key=IP

2. Per HTTP Header
   --enforce-on-key=HTTP-HEADER
   --enforce-on-key-name=X-API-Key

3. Per Region Code
   --enforce-on-key=REGION-CODE

4. Per ALL (global limit)
   --enforce-on-key=ALL

5. Per XFF IP (behind proxy)
   --enforce-on-key=XFF-IP

Exam Scenario:
Q: API key abuse, multiple requests per key
A: Rate limit with --enforce-on-key=HTTP-HEADER --enforce-on-key-name=X-API-Key

Organization-level vs VPC-level:

Organization Policy (Hierarchical)
├── Applied to entire organization or folders
├── Inherited by all projects/VPCs
├── Cannot be overridden by VPC rules
├── Priority: 0-2147483647
└── Use for corporate-wide rules

VPC Firewall Rules (Legacy, still common)
├── Applied to specific VPC
├── Priority: 0-65535
├── Can be overridden within VPC
└── Most granular control

Evaluation Order:
1. Hierarchical deny rules (highest priority)
2. Hierarchical allow rules
3. VPC deny rules
4. VPC allow rules (lowest priority)

Configuration (Hierarchical):
gcloud compute firewall-policies create corp-firewall-policy \
  --description="Corporate security policy"

gcloud compute firewall-policies rules create 100 \
  --firewall-policy=corp-firewall-policy \
  --action=deny \
  --direction=ingress \
  --src-ip-ranges=0.0.0.0/0 \
  --layer4-configs=tcp:22 \
  --description="Block SSH from internet"

gcloud compute firewall-policies associations create \
  --firewall-policy=corp-firewall-policy \
  --organization=ORGANIZATION_ID

Purpose: Create security perimeters around Google Cloud resources

Protection:
- Prevents data exfiltration
- Enforces context-aware access
- Protects Google-managed services
- Works across projects

Supported Services:
- Cloud Storage
- BigQuery
- Cloud SQL
- Dataflow
- Pub/Sub
- And 40+ more

Architecture:
┌─────────────────────────────────────┐
│   VPC Service Control Perimeter     │
│                                     │
│  ┌──────────┐      ┌──────────┐   │
│  │ Project A│──────│ Project B│   │
│  │          │      │          │   │
│  │ GCS      │      │ BigQuery │   │
│  └──────────┘      └──────────┘   │
│                                     │
└─────────────────────────────────────┘
         │                   │
         ✓ Allowed           ✗ Blocked
    (within perimeter)  (outside perimeter)

Evolution: Private Google Access → Private Service Connect

Benefits:
- Uses your VPC IP addresses
- Works with on-premises (via VPN/Interconnect)
- No internet exposure
- Supports VPC-SC perimeters
- Fine-grained DNS control

Architecture:
On-Premises ←─VPN/Interconnect─→ GCP VPC
                                    │
                              PSC Endpoint
                            (10.1.1.5 - your IP)
                                    │
                          ┌─────────┴─────────┐
                   Cloud Storage          BigQuery
                   (googleapis.com)

Configuration:
# Reserve internal IP
gcloud compute addresses create psc-google-apis \
  --global \
  --purpose=PRIVATE_SERVICE_CONNECT \
  --addresses=10.1.1.5 \
  --network=my-vpc

# Create forwarding rule
gcloud compute forwarding-rules create psc-rule \
  --global \
  --network=my-vpc \
  --address=psc-google-apis \
  --target-google-apis-bundle=all-apis \
  --service-directory-registration=projects/PROJECT/locations/us-central1

# Configure DNS
gcloud dns managed-zones create googleapis-zone \
  --description="Private zone for googleapis.com" \
  --dns-name=googleapis.com \
  --networks=my-vpc \
  --visibility=private

gcloud dns record-sets create storage.googleapis.com. \
  --zone=googleapis-zone \
  --type=A \
  --ttl=300 \
  --rrdatas=10.1.1.5

Use Case: Private connection to third-party SaaS

Architecture:
Your VPC          PSC Endpoint      Service Producer VPC
  │                   │                      │
VM ─────→ 10.1.1.100 ─────────────→ SaaS Application
         (your IP)            (private connection)

Benefits:
- No public IP exposure
- Traffic stays on Google network
- Reduced attack surface
- Simplified firewall rules

Configuration:
# Create endpoint
gcloud compute forwarding-rules create saas-endpoint \
  --region=us-central1 \
  --network=my-vpc \
  --subnet=prod-subnet \
  --target-service-attachment=projects/PRODUCER_PROJECT/regions/us-central1/serviceAttachments/SERVICE_NAME

Use Cases:
- MongoDB Atlas via PSC
- Confluent Cloud via PSC
- Elastic Cloud via PSC
- Custom SaaS connections

Internet Users (Global)
        │
        ▼
┌───────────────────────────────────────┐
│   Global HTTP(S) Load Balancer       │
│   - Anycast IP: 34.149.x.x           │
│   - Cloud CDN enabled                 │
│   - Cloud Armor (WAF + DDoS)         │
└───────┬───────────────────────────────┘
        │
    ┌───┴────────────────────┐
    │                        │
┌───▼─────┐          ┌───────▼────┐
│us-central1│          │europe-west1│
│                      │            │
│ Web Tier            │ Web Tier   │
│ 10.1.1.0/24        │ 10.2.1.0/24│
│ (MIG: 3-10 VMs)    │ (MIG: 3-10)│
└───┬─────┘          └───────┬────┘
    │                        │
┌───▼─────────────────────────▼────┐
│   Internal HTTP(S) Load Balancer │
│   (Regional - per region)        │
└───┬─────────────────────────┬────┘
    │                         │
┌───▼─────┐          ┌────────▼───┐
│App Tier │          │ App Tier   │
│10.1.2.0/│          │10.2.2.0/24 │
│24 (MIG) │          │    (MIG)   │
└───┬─────┘          └────────┬───┘
    │                         │
    └──────────┬──────────────┘
               │
    ┌──────────▼──────────────┐
    │ Internal TCP/UDP LB     │
    │ (for database failover) │
    └──────────┬──────────────┘
               │
        ┌──────┴──────┐
    ┌───▼────┐    ┌───▼────┐
    │Cloud SQL│    │Read    │
    │Primary  │────│Replica │
    │us-cent1 │    │eu-west1│
    └─────────┘    └────────┘

On-Premises Data Center
├── IP Range: 172.16.0.0/12
├── DNS: 172.16.1.5, 172.16.1.6
├── VPN Device 1: 203.0.113.1
└── VPN Device 2: 203.0.113.2
        │
        ├── Dedicated Interconnect (10 Gbps)
        │   ├── Primary Circuit → us-central1
        │   └── Secondary Circuit → us-east1
        │
        └── HA VPN (Backup)
            └── 4 Tunnels → us-central1
        │
        ▼
┌─────────────────────────────────────────┐
│          GCP VPC Network                │
│                                         │
│  Shared VPC (Host Project)             │
│  ├── IP Range: 10.0.0.0/8             │
│  ├── Cloud DNS Private Zone           │
│  │   ├── gcp.company.local            │
│  │   └── Inbound/Outbound Forwarding  │
│  │                                     │
│  ├── Service Project A (Production)   │
│  │   └── Subnet: 10.1.0.0/16          │
│  │                                     │
│  ├── Service Project B (Staging)      │
│  │   └── Subnet: 10.2.0.0/16          │
│  │                                     │
│  └── Service Project C (Development)  │
│      └── Subnet: 10.3.0.0/16          │
└─────────────────────────────────────────┘

Internet (Customers)
        │
        ▼
┌────────────────────────────────────────┐
│  Global HTTP(S) Load Balancer         │
│  - Cloud Armor (rate limiting per API)│
│  - Cloud CDN for static assets        │
└────────┬───────────────────────────────┘
         │
    ┌────┴────────┐
┌───▼────┐   ┌────▼────┐
│us-cent1│   │eu-west1 │
│        │   │         │
│API GW  │   │ API GW  │
│(IAP)   │   │ (IAP)   │
└───┬────┘   └────┬────┘
    │             │
    └──────┬──────┘
           │
┌──────────▼───────────────────────────┐
│  Internal HTTP(S) Load Balancer     │
│  (Cross-Region)                     │
└──────────┬───────────────────────────┘
           │
    ┌──────┴─────────┐
┌───▼────────┐  ┌────▼────────┐
│Auth Service│  │Tenant Service│
│(GKE)       │  │(GKE)         │
└───┬────────┘  └────┬─────────┘
    │                │
    └────────┬───────┘
             │
┌────────────▼──────────────────────┐
│  Service Mesh (Istio)             │
│  - mTLS between services          │
│  - Fine-grained access control    │
│  - Distributed tracing            │
└────────────┬──────────────────────┘
             │
    ┌────────┴────────┐
┌───▼──────┐    ┌─────▼──────┐
│Billing   │    │Analytics   │
│Service   │    │Service     │
│(Cloud Run)    │(Cloud Run) │
└───┬──────┘    └─────┬──────┘
    │                 │
    └────────┬────────┘
             │
┌────────────▼──────────────────┐
│  Data Layer                   │
│  ├── Firestore (tenant data)  │
│  ├── Cloud SQL (billing)      │
│  └── BigQuery (analytics)     │
│                               │
│  VPC Service Controls        │
│  (data exfiltration prevent) │
└───────────────────────────────┘

Primary Region (us-central1) [Active]
├── VPC: dr-vpc (global)
├── Subnet: 10.1.0.0/16
├── Compute: 10 VMs (MIG)
├── Cloud SQL: Primary instance
├── Cloud Storage: prod-bucket
└── Load Balancer: Active

DR Region (us-east1) [Standby]
├── Same VPC: dr-vpc
├── Subnet: 10.2.0.0/16
├── Compute: 2 VMs (MIG, min=0, max=10)
├── Cloud SQL: Read replica
├── Cloud Storage: replication enabled
└── Load Balancer: Same global LB

Failover Mechanism:
├── Global HTTP(S) LB health checks
├── Automatic backend selection
├── Cloud SQL failover to replica
└── Manual DNS update (optional)

Decision Tree:
1. Bandwidth requirements?
   - < 3 Gbps → Consider VPN
   - 3-10 Gbps → Partner Interconnect or VPN
   - > 10 Gbps → Dedicated Interconnect

2. Latency requirements?
   - Variable OK → VPN (via internet)
   - Consistent required → Interconnect

3. Cost considerations?
   - Budget-conscious → VPN
   - High traffic volume → Interconnect (lower egress costs)

4. Availability requirements?
   - 99.9% → Single HA VPN or single Interconnect
   - 99.99% → HA VPN (4 tunnels) or redundant Interconnect

5. Location?
   - No Google colo presence → Partner Interconnect or VPN
   - In Google colo → Dedicated Interconnect

Decision Tree:
1. Internal or External?
   - Internal → Internal HTTP(S) or TCP/UDP LB
   - External → Continue

2. Protocol?
   - HTTP(S) → HTTP(S) Load Balancer
   - TCP (non-HTTP) → TCP Proxy or Network LB
   - UDP → Network LB

3. Scope?
   - Single region → Regional LB
   - Multiple regions → Global LB

4. Need source IP preservation?
   - Yes → Network LB (passthrough)
   - No → Proxy-based LB OK

5. Need SSL termination?
   - Yes → HTTP(S) LB or SSL Proxy
   - No → TCP Proxy or Network LB

6. Need content-based routing?
   - Yes → HTTP(S) Load Balancer
   - No → Any appropriate LB

Question: "Running out of IPs in subnet, what to do?"

Wrong Answers:
- Delete and recreate subnet (downtime)
- Use another subnet (requires reconfiguration)
- Migrate to auto-mode VPC (not possible)

Correct Answer:
- Expand subnet IP range (no downtime)
- Cannot shrink, only expand

Question: "All backends showing unhealthy"

Most Common Cause:
- Missing firewall rule for health check ranges
- Must allow from 35.191.0.0/16 and 130.211.0.0/22
- Different ranges for internal vs external LBs

Not Usually:
- Backend service configuration
- Health check endpoint
- Instance issues

Question: "VM without external IP can't access Cloud Storage"

Wrong Answers:
- Add external IP (defeats purpose)
- Use VPN (not needed)
- Create NAT gateway (AWS concept)

Correct Answer:
- Enable Private Google Access on subnet
- Works for Google APIs only
- Does NOT provide general internet access

Question: "VPC A peers with B, B peers with C. Can A reach C?"

Answer: NO
- VPC peering is NOT transitive
- Must create A ↔ C peering directly
- Common misconception from other clouds

Alternative:
- Use Shared VPC instead
- Or VPN/Interconnect with proper routing

Question: "Enable Cloud CDN on Internal HTTP(S) Load Balancer"

Answer: NOT POSSIBLE
- Cloud CDN only works with:
  - Global External HTTP(S) Load Balancer
  - Regional External HTTP(S) Load Balancer
- Does NOT work with:
  - Internal Load Balancers
  - Network Load Balancers

Time to mark unhealthy = check-interval × unhealthy-threshold
Time to mark healthy = check-interval × healthy-threshold

Example:
check-interval: 10s
unhealthy-threshold: 3
Unhealthy after: 10s × 3 = 30 seconds

Example:
check-interval: 5s
healthy-threshold: 2
Healthy after: 5s × 2 = 10 seconds

Formula: Total pod IPs needed = nodes × max-pods-per-node

Example:
- 50 nodes
- 110 pods per node (default max)
- Total: 50 × 110 = 5,500 pods
- Need: /19 (8,192 IPs) or larger for pod secondary range

Services:
- Typically need /20 (4,096 IPs) for services
- One IP per Kubernetes Service

Primary range:
- One IP per node
- /24 (252 IPs) sufficient for most clusters

Premium Tier:
- Global routing via Google network
- Best performance, lowest latency
- Higher cost
- Use for: Production, latency-sensitive apps

Standard Tier:
- Regional routing via ISP networks
- Lower cost (up to 35% savings)
- Higher latency, variable performance
- Use for: Batch processing, backups, logs

Avoid Cross-Region Traffic:
- $0.01/GB between regions (within NA/EU)
- $0.05-$0.08/GB between continents
- Keep data in same region when possible

Use Cloud CDN:
- Cache at edge (free once cached)
- Reduces origin egress charges
- Typical savings: 60-90% of egress costs

Use Interconnect for High Volume:
- VPN egress: Standard internet rates
- Interconnect egress: 50-75% cheaper
- Breakeven: 1-5 TB/month depending on region