Gcp Vpc

---
name: gcp-vpc
description: "Expert coverage of GCP VPC networking: global VPC architecture, firewall rules, hierarchical policies, Cloud NAT, Cloud Armor, Cloud Interconnect, HA VPN, Shared VPC, NCC, Private Service Connect, and VPC Service Controls. Use for \"GCP VPC\", \"GCP firewall\", \"Cloud NAT\", \"Cloud Armor\", \"Cloud Interconnect\", \"HA VPN\", \"Shared VPC\", \"NCC\", \"Private Service Connect\", \"GCP networking\". Do NOT use for cross-vendor comparison, platform selection, or category-wide architecture -- use the `cloud-networking` skill. Do NOT use for general GCP account/resource management beyond VPC networking -- that's the `gcp` skill (in the `cloud-platforms` plugin)."
license: MIT
---

# GCP VPC

This skill covers Google Cloud Platform VPC networking. Areas of expertise include:

- Global VPC architecture (VPC spans all regions by default)
- VPC firewall rules (stateful, tag-based) and hierarchical firewall policies
- Cloud NAT for private instance egress
- Cloud Armor for WAF and DDoS protection
- Cloud Interconnect (Dedicated and Partner)
- HA VPN with BGP for hybrid connectivity
- Shared VPC for multi-project network centralization
- Network Connectivity Center (NCC) for hub-and-spoke transit
- Private Service Connect (PSC) for private access to Google APIs and services
- VPC Service Controls for API-level security perimeters
- Cloud Router and BGP route management
- Cloud DNS and split-horizon DNS

## How to Approach Tasks

1. **Classify** the request:
   - **Design** -- Load `references/architecture.md` for global VPC patterns, Shared VPC, NCC topology
   - **Security** -- Apply firewall rules, hierarchical policies, Cloud Armor, and VPC Service Controls guidance
   - **Connectivity** -- Determine if intra-VPC, inter-VPC, hybrid, or internet and apply relevant guidance
   - **Troubleshooting** -- Use VPC Flow Logs, Firewall Rules Logging, Connectivity Tests
   - **Automation** -- Apply gcloud CLI, Terraform, or Deployment Manager guidance

2. **Gather context** -- Number of projects, VPCs, regions, traffic patterns, existing Interconnect or VPN, GKE cluster requirements

3. **Analyze** -- Apply GCP-specific reasoning. GCP's global VPC fundamentally changes design patterns compared to AWS/Azure (no cross-region peering needed).

4. **Recommend** -- Provide actionable guidance with gcloud CLI examples or Terraform snippets

5. **Verify** -- Suggest validation steps (Connectivity Tests, Flow Logs, firewall rule logging)

## Global VPC Architecture

### Key Difference from AWS/Azure

GCP VPC is **global by default**:
- A single VPC spans all GCP regions simultaneously
- VMs in different regions within the same VPC communicate privately without peering
- Subnets are regional (not AZ-scoped like AWS)
- Firewall rules apply at the VPC level across all regions
- This eliminates the need for cross-region VPC peering or transit hubs for intra-VPC traffic

### VPC Modes

**Auto-mode VPC:**
- Creates subnets automatically in every region (10.128.0.0/9 space)
- Good for simple deployments and quick starts
- Cannot be used with VPC peering if address space overlaps
- Not recommended for production (limited CIDR control)

**Custom-mode VPC:**
- No automatic subnets -- administrator controls all subnet creation
- Full CIDR flexibility
- Required for production workloads
- Required for Shared VPC host projects

### Subnets

- Regional resources (span all zones within a region)
- Primary IP range: for VM instances
- Secondary IP ranges: for GKE pods and services (alias IPs)
- Private Google Access: allows VMs without external IPs to reach Google APIs
- Flow Logs: configurable per subnet (sampling rate, aggregation interval)

```bash
# Create custom-mode VPC
gcloud compute networks create prod-vpc --subnet-mode=custom

# Create subnet with secondary ranges for GKE
gcloud compute networks subnets create app-subnet \
  --network=prod-vpc \
  --region=us-central1 \
  --range=10.0.1.0/24 \
  --secondary-range=pods=10.4.0.0/14,services=10.8.0.0/20 \
  --enable-private-ip-google-access \
  --enable-flow-logs
```

## Firewall Rules

### VPC Firewall Rules

Stateful firewall rules applied to instances based on target:
- **Target**: All instances in VPC, instances with specific network tag, or instances with specific service account
- **Direction**: Ingress or egress
- **Priority**: 0-65535 (lower number = higher priority)
- **Action**: Allow or deny
- Stateful: return traffic is automatically allowed
- Rules evaluated per-instance, not per-subnet

```bash
# Allow HTTP/HTTPS to instances tagged "web"
gcloud compute firewall-rules create allow-web \
  --network=prod-vpc \
  --direction=INGRESS \
  --action=ALLOW \
  --rules=tcp:80,tcp:443 \
  --source-ranges=0.0.0.0/0 \
  --target-tags=web \
  --priority=1000

# Allow internal communication
gcloud compute firewall-rules create allow-internal \
  --network=prod-vpc \
  --direction=INGRESS \
  --action=ALLOW \
  --rules=all \
  --source-ranges=10.0.0.0/8 \
  --priority=1000
```

### Hierarchical Firewall Policies

Organization or folder-level firewall policies evaluated BEFORE VPC firewall rules:

```
Organization Policy (Priority 100: Deny known-bad CIDRs)
  |
Folder Policy (Priority 200: Allow shared services)
  |
VPC Firewall Rules (Priority 1000+: Application-specific rules)
```

**Actions:**
- `allow`: Permit and skip lower policies
- `deny`: Block and skip lower policies
- `goto_next`: Delegate decision to the next level (folder policy or VPC rules)

**Use case**: Centralized security team enforces org-wide deny rules; application teams manage VPC-level allow rules.

```bash
# Create organization firewall policy
gcloud compute firewall-policies create \
  --organization=123456789 \
  --short-name=org-security-policy

# Add rule to block known-bad IPs
gcloud compute firewall-policies rules create 100 \
  --firewall-policy=org-security-policy \
  --direction=INGRESS \
  --action=deny \
  --src-ip-ranges=198.51.100.0/24 \
  --layer4-configs=all
```

### Default VPC Rules

Default VPC includes permissive rules:
- `default-allow-internal`: Allow all traffic between instances in the VPC
- `default-allow-ssh`: Allow SSH (22) from anywhere
- `default-allow-rdp`: Allow RDP (3389) from anywhere
- `default-allow-icmp`: Allow ICMP from anywhere

**Best practice**: Delete default rules in production VPCs. Create explicit, least-privilege rules.

## Cloud NAT

Managed NAT service for private instances:
- Regional resource; one per region per Cloud Router
- Fully managed -- no NAT VM instances required
- Auto-scales based on traffic demand
- Supports configurable port allocation per VM
- NAT logging for translation events

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

# Create Cloud NAT
gcloud compute routers nats create prod-nat \
  --router=nat-router \
  --region=us-central1 \
  --auto-allocate-nat-external-ips \
  --nat-all-subnet-ip-ranges
```

### Port Allocation

- Default: 64 ports per VM (supports 64 concurrent connections to the same destination)
- Increase for high-connection workloads: `--min-ports-per-vm=2048`
- Dynamic port allocation (DPA): automatically scales ports per VM based on demand
- Monitor with Cloud Monitoring: `nat/allocated_ports` vs `nat/used_ports`

## Cloud Armor

WAF and DDoS protection applied at the global load balancer:

### Security Policies

```bash
# Create security policy
gcloud compute security-policies create web-policy

# Add OWASP rule (SQLi protection)
gcloud compute security-policies rules create 1000 \
  --security-policy=web-policy \
  --expression="evaluatePreconfiguredExpr('sqli-v33-stable')" \
  --action=deny-403

# Rate limiting
gcloud compute security-policies rules create 2000 \
  --security-policy=web-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

# Attach to backend service
gcloud compute backend-services update web-backend \
  --security-policy=web-policy \
  --global
```

### Adaptive Protection

- ML-based detection of L7 DDoS attacks
- Automatically generates suggested mitigation rules when anomalous traffic detected
- Admin reviews and applies suggestions (not auto-applied)
- Requires Cloud Armor Managed Protection Plus tier

### Cloud Armor vs Cloud Firewall

| Aspect | Cloud Armor | VPC Firewall Rules |
|---|---|---|
| Layer | L7 (HTTP/HTTPS) | L3/L4 (IP/port) |
| Attachment | Global Load Balancer | VPC / instances |
| WAF | Yes (OWASP rules) | No |
| DDoS | Yes (volumetric + L7) | No |
| Rate limiting | Yes | No |
| Use case | Protect web applications | Network access control |

## Cloud Interconnect

### Dedicated Interconnect

- Physical 10 Gbps or 100 Gbps connections at colocation facilities
- VLAN attachments connect to Cloud Routers in specific regions
- BGP routing between customer router and Cloud Router
- 99.9% SLA (single interconnect), 99.99% SLA (redundant in separate metros)

### Partner Interconnect

- 50 Mbps to 10 Gbps via connectivity partners (Megaport, Equinix, etc.)
- No physical presence at Google colocation required
- VLAN attachment through partner's infrastructure
- Lower cost entry point for hybrid connectivity

### Design Pattern

```
On-prem Router-A -> Dedicated Interconnect (Metro-1) -> VLAN Attachment -> Cloud Router (us-central1)
On-prem Router-B -> Dedicated Interconnect (Metro-2) -> VLAN Attachment -> Cloud Router (us-east1)
```

- Two interconnects in separate metros for 99.99% SLA
- Cloud Routers in different regions for regional redundancy
- BGP AS-path prepending for primary/backup path preference
- MED for inbound traffic engineering

## HA VPN

High-availability VPN with 99.99% SLA:
- Two interfaces per HA VPN gateway
- BGP required (no static routing with HA VPN)
- Each tunnel supports up to 3 Gbps
- Create 4 tunnels (2 per interface) for full redundancy

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

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

# Create VPN tunnel
gcloud compute vpn-tunnels create tunnel-0 \
  --vpn-gateway=ha-vpn-gw \
  --peer-gcp-gateway=peer-vpn-gw \  # or --peer-external-gateway
  --region=us-central1 \
  --ike-version=2 \
  --shared-secret=<secret> \
  --router=vpn-router \
  --vpn-gateway-interface=0
```

### HA VPN to AWS

Requires 4 tunnels for full redundancy:
- 2 AWS customer gateways (one per HA VPN interface IP)
- 2 AWS VPN connections (one per customer gateway)
- 4 total tunnels (2 per VPN connection x 2 connections)
- BGP peering on all 4 tunnels

## Shared VPC

Centralize network administration while distributing compute resources:

- **Host project**: Owns the VPC, controls subnets, firewall rules, and Cloud NAT
- **Service projects**: Deploy VMs, GKE clusters, Cloud Run in shared subnets
- Resources billed to the service project; network managed by the host project

### Design Pattern

```
Host Project (Network Team)
  prod-vpc
    app-subnet-us-central1 (10.0.1.0/24)
    app-subnet-us-east1 (10.0.2.0/24)
    gke-subnet-us-central1 (10.0.10.0/24)
  Firewall rules, Cloud NAT, Cloud Router

Service Project A (App Team A)
  VMs in app-subnet-us-central1

Service Project B (App Team B)
  GKE cluster in gke-subnet-us-central1

Service Project C (App Team C)
  VMs in app-subnet-us-east1
```

### IAM Roles

- `roles/compute.networkAdmin`: Manage VPC, subnets, firewall rules (network team)
- `roles/compute.networkUser`: Use subnets for deploying resources (app teams)
- `roles/compute.securityAdmin`: Manage firewall rules only (security team)

## Network Connectivity Center (NCC)

Hub-and-spoke transit for GCP and hybrid connectivity:

- **Hub**: Central network resource owning the topology
- **Spokes**: VPN tunnels, Interconnect VLANs, SD-WAN appliances, or VPC networks
- VPC spokes enable transitive routing between VPCs via NCC hub
- Export filters control route propagation between spokes

### PSC via NCC

Private Service Connect endpoints in spoke VPCs are accessible from all other spokes:
- Single PSC endpoint serves multiple VPCs through NCC hub
- Eliminates per-VPC PSC endpoint duplication
- Reduces cost and management overhead for multi-VPC architectures

## Private Service Connect (PSC)

### PSC for Google APIs

Access Google APIs (Storage, BigQuery, etc.) via private IP:

```bash
# Create PSC endpoint for Google APIs
gcloud compute addresses create google-apis-endpoint \
  --region=us-central1 \
  --subnet=app-subnet \
  --addresses=10.0.1.100

gcloud compute forwarding-rules create google-apis-psc \
  --region=us-central1 \
  --network=prod-vpc \
  --address=google-apis-endpoint \
  --target-google-apis-bundle=all-apis
```

### PSC for Published Services

Access producer services via private endpoint:
- Producer creates a service attachment backed by an internal load balancer
- Consumer creates a PSC endpoint (forwarding rule with private IP)
- Traffic flows over Google's internal network
- Cross-project and cross-organization supported

## VPC Service Controls

API-level security perimeters preventing data exfiltration:

```bash
# Create access policy
gcloud access-context-manager policies create --organization=123456789

# Create service perimeter
gcloud access-context-manager perimeters create prod-perimeter \
  --policy=<policy-id> \
  --title="Production Perimeter" \
  --resources=projects/prod-project-1,projects/prod-project-2 \
  --restricted-services=storage.googleapis.com,bigquery.googleapis.com
```

- Projects inside the perimeter can access restricted services
- Requests from outside (even with valid credentials) are blocked
- Bridges: controlled access between perimeters
- Audit mode: log violations without blocking (test before enforcing)

## Common Pitfalls

1. **Auto-mode VPC in production** -- Auto-mode VPCs use fixed CIDR ranges (10.128.0.0/9) that conflict with common enterprise allocations and cannot be changed. Always use custom-mode VPCs for production.

2. **Default firewall rules left in place** -- Default VPC allows SSH/RDP from 0.0.0.0/0. Delete these rules immediately and create explicit, least-privilege rules.

3. **Missing Private Google Access** -- Without Private Google Access enabled on a subnet, VMs without external IPs cannot reach Google APIs (Cloud Storage, BigQuery, etc.). Enable it on all private subnets.

4. **Cloud NAT port exhaustion** -- Default 64 ports per VM is insufficient for workloads making many concurrent connections. Monitor `nat/allocated_ports` and increase `--min-ports-per-vm` or enable Dynamic Port Allocation.

5. **Shared VPC IAM misconfiguration** -- Service project users need `compute.networkUser` role on the specific subnet(s) they should use, not on the entire host project. Granting at the project level gives access to all subnets.

6. **HA VPN without BGP** -- HA VPN requires BGP. Static routing with HA VPN is not supported and results in deployment failure. Always configure Cloud Router with BGP peering for HA VPN tunnels.

7. **VPC Service Controls blocking legitimate traffic** -- VPC SC blocks all API requests from outside the perimeter, including CI/CD pipelines, developer workstations, and partner integrations. Use access levels and ingress/egress policies to allow legitimate access patterns. Test in audit mode first.

## Reference Files

Load these when you need deep knowledge:

- `references/architecture.md` -- Global VPC internals, Shared VPC topology, NCC hub-and-spoke, Cloud Interconnect design, Cloud Armor implementation, PSC architecture, VPC Service Controls. Read for design and troubleshooting questions.