LAB35_GCP_Network Topology: VPC Network Peering

Network Topology: VPC Network Peering

☁ GCP 🔥 Intermediate VPC Peering Networking Decentralized

Scenario

Your decentralized organization has two separate VPC networks ("Frontend" and "Backend") living in completely independent administrative planes. They must communicate securely using internal IP addresses without traffic ever traversing the public internet. You will establish a decentralized VPC Network Peering connection.

Your Objectives
  • Create VPC Network "A" and Subnet "A".
  • Create VPC Network "B" and Subnet "B" (Ensure the CIDR ranges DO NOT overlap!).
  • Create a google_compute_network_peering request originating from Network A targeting Network B.
  • Create a matching google_compute_network_peering request originating from Network B targeting Network A.
  • (Peering in GCP requires a bidirectional handshake to become active).

Additional Context

Peering Handshakes: VPC Network Peering is strictly a 1-to-1 relationship and requires agreement from both sides. If Network A creates a peering connection to Network B, the status will show as "Inactive" until Network B's administrator creates the exact corresponding connection pointing back to Network A. Once both exist, GCP magically exchanges the routing tables in seconds.

Non-Transitive: Peering is non-transitive. If VPC A peers with VPC B, and VPC B peers with VPC C, VPC A cannot communicate with VPC C.

variables.tf

variable "project_id" { type = string }

main.tf

provider "google" {
  project = var.project_id
  region  = "us-central1"
}

# 1. The Frontend Infrastructure
resource "google_compute_network" "frontend" {
  name                    = "frontend-vpc"
  auto_create_subnetworks = false
}

resource "google_compute_subnetwork" "frontend_sub" {
  name          = "frontend-sub-central"
  network       = google_compute_network.frontend.id
  region        = "us-central1"
  cidr_range    = "10.0.1.0/24" # Non-overlapping range 1
}

# 2. The Backend Infrastructure
resource "google_compute_network" "backend" {
  name                    = "backend-vpc"
  auto_create_subnetworks = false
}

resource "google_compute_subnetwork" "backend_sub" {
  name          = "backend-sub-central"
  network       = google_compute_network.backend.id
  region        = "us-central1"
  cidr_range    = "10.0.2.0/24" # Non-overlapping range 2
}

# 3. Peering Requester (Frontend -> Backend)
resource "google_compute_network_peering" "peering_f_to_b" {
  name         = "peer-front-to-back"
  network      = google_compute_network.frontend.id
  peer_network = google_compute_network.backend.id
}

# 4. Peering Accepter (Backend -> Frontend)
resource "google_compute_network_peering" "peering_b_to_f" {
  name         = "peer-back-to-front"
  network      = google_compute_network.backend.id
  peer_network = google_compute_network.frontend.id
}

outputs.tf

output "status_f_to_b" {
  value = google_compute_network_peering.peering_f_to_b.state
}

output "status_b_to_f" {
  value = google_compute_network_peering.peering_b_to_f.state
}

Workflow Commands

terraform init
terraform apply -var="project_id=my-gcp-project-123"

# Verify that both states output "ACTIVE" rather than "INACTIVE"
# If you comment out the Accepter block and apply, the Requester state will drop to INACTIVE.

terraform destroy -var="project_id=my-gcp-project-123"
✓ Expected Output After Apply
Apply complete! Resources: 6 added, 0 changed, 0 destroyed.

Outputs:

status_b_to_f = "ACTIVE"
status_f_to_b = "ACTIVE"

Related Posts