My Awesome Project

Appearance

Shared VPC: Centralized Network Management ​

Tại sao cần Shared VPC ​

Production organizations không thể để mỗi project manage networking independently:

Anti-pattern: Independent networks per project
my-project-prod:
  VPC: 10.0.0.0/16

my-project-staging:
  VPC: 10.0.0.0/16  # OVERLAP! Cannot communicate
  
Result: Cannot route traffic, no service mesh, firewall chaos

Shared VPC provides:

  • Centralized network management
  • Single perimeter security
  • Service-to-service communication
  • Shared subnets across projects

Architecture ​

Organization
├── Host Project (contains VPC)
│   └── Network: shared-vpc-prod
│       ├── Subnet: us-central1
│       ├── Subnet: us-east1
│       └── Firewall rules
│
└── Service Projects (use VPC from host)
    ├── Service Project A (GKE)
    ├── Service Project B (Cloud Run)
    └── Service Project C (Compute Engine)

Key relationship: Service projects cannot create networks—must use host project's network.

Setup ​

bash
# 1. Enable Shared VPC on organization
gcloud compute shared-vpc organizations enable ORG_ID

# 2. Designate host project
gcloud compute shared-vpc host-projects create HOST_PROJECT_ID

# 3. Create shared network
gcloud compute networks create shared-vpc-prod \
  --project=HOST_PROJECT_ID \
  --subnet-mode=custom

# 4. Create shared subnet
gcloud compute networks subnets create us-central1-subnet \
  --project=HOST_PROJECT_ID \
  --network=shared-vpc-prod \
  --region=us-central1 \
  --range=10.0.0.0/24

# 5. Attach service project
gcloud compute shared-vpc associated-projects attach SERVICE_PROJECT \
  --host-project=HOST_PROJECT_ID

# 6. Grant permissions
gcloud projects add-iam-policy-binding SERVICE_PROJECT \
  --member=serviceAccount:service-account@HOST_PROJECT_ID.iam.gserviceaccount.com \
  --role=roles/compute.networkUser

Network Admin vs Service Account Management ​

Host Project:
- Network Admin (from host project)
  - Can modify subnets, firewall, routes
  - Central control point

Service Projects:
- Network User (delegated role)
  - Can create resources using shared network
  - Cannot modify network itself

Cross-Project Service Communication ​

yaml
# GKE cluster ở service project A
Namespace: default
Pod: frontend-deployment
Service: frontend-svc (10.1.0.1)

# Cloud SQL ở service project B
Internal IP: 10.2.0.5

# Both connected via Shared VPC → can communicate
# frontend-svc → 10.2.0.5 (direct routing)

Firewall Rules in Shared VPC ​

bash
# Central firewall rule ở host project
gcloud compute firewall-rules create allow-backend-api \
  --project=HOST_PROJECT_ID \
  --network=shared-vpc-prod \
  --allow=tcp:8080 \
  --source-ranges=10.0.0.0/16 \
  --target-service-accounts=backend-sa@service-project-a.iam.gserviceaccount.com

# Service project resources automatically use central firewall
# (no need to define duplicate rules per project)

Shared VPC Limitations ​

Cannot:
- Peering between service projects (use shared VPC instead)
- Multiple host projects per organization (only 1)
- Reverse: Service project cannot be host
- Dynamic routing policies vary per host/service project

Multi-Region Shared VPC ​

hcl
# Terraform: Multi-region shared network

resource "google_compute_network" "shared_vpc" {
  project                 = var.host_project_id
  name                    = "shared-vpc-prod"
  auto_create_subnetworks = false
  routing_mode            = "GLOBAL"  # Enable cross-region routing
}

resource "google_compute_subnetwork" "us_central" {
  project       = var.host_project_id
  name          = "us-central1"
  region        = "us-central1"
  network       = google_compute_network.shared_vpc.id
  ip_cidr_range = "10.0.0.0/24"
}

resource "google_compute_subnetwork" "us_east" {
  project       = var.host_project_id
  name          = "us-east1"
  region        = "us-east1"
  network       = google_compute_network.shared_vpc.id
  ip_cidr_range = "10.1.0.0/24"
}

# GKE cluster ở service project, spanning multiple regions
resource "google_container_cluster" "global_cluster" {
  project  = var.service_project_id
  name     = "global-cluster"
  
  # Uses shared VPC from host project
  network    = "shared-vpc-prod"
  subnetwork = google_compute_subnetwork.us_central.name
  
  # Pod CIDR from shared subnet
  ip_allocation_policy {
    cluster_secondary_range_name  = "pods"
    services_secondary_range_name = "services"
  }
}

Cost Implications ​

Shared VPC pricing:

  • No additional cost for VPC/subnets
  • Egress charges apply per service project
  • Shared NAT gateway costs borne by host project
Example: 2 service projects using shared NAT
- Service Project A: 10TB egress
- Service Project B: 5TB egress
- Total egress cost: (10+5TB) × $0.12/GB
  charged to host project (where NAT exists)

Migration from VPC Peering to Shared VPC ​

bash
# Old pattern: VPC peering
Proj A (network A) ←→ Peering ←→ Proj B (network B)

# New pattern: Shared VPC
Proj A & B use same network from Host project
(simpler, no peering maintenance)

# Migration steps:
# 1. Create shared VPC in new host project
# 2. Create subnets in shared VPC
# 3. Attach service projects
# 4. Migrate resources gradually
# 5. Update DNS, load balancers
# 6. Remove old VPC peering

References ​