Mastering GCP Infrastructure with Terraform: Regional HTTPS Load Balancer with Cloud DNS - Part 2

?? Welcome to Part 2 of the series, "Mastering GCP Infrastructure with Terraform: Regional HTTPS Load Balancer with Cloud DNS." In Part 1, we laid the foundation for our infrastructure by configuring Terraform, defining variables, and setting up reusable local values.

In Part 2, we’ll move on to the networking layer. A strong network setup ensures your infrastructure is secure, scalable, and reliable. We’ll create a custom Virtual Private Cloud (VPC), define subnets, and configure firewall rules to control traffic.

By the end of this part, you’ll have a custom network ready to support your scalable application.

Setting Up Networking

Custom networking in GCP gives you control over IP ranges, traffic flow, and resource isolation. Let’s dive into the configurations.

1. Creating a Custom VPC and Subnets

resource "google_compute_network" "myvpc" {
  name                    = "${local.name}-vpc"
  auto_create_subnetworks = false
}

resource "google_compute_subnetwork" "mysubnet" {
  name          = "${var.gcp_region1}-subnet"
  region        = var.gcp_region1
  ip_cidr_range = "10.128.0.0/24"
  network       = google_compute_network.myvpc.id
}

resource "google_compute_subnetwork" "regional_proxy_subnet" {
  name          = "${var.gcp_region1}-regional-proxy-subnet"
  region        = var.gcp_region1
  ip_cidr_range = "10.0.0.0/24"
  network       = google_compute_network.myvpc.id
  purpose       = "REGIONAL_MANAGED_PROXY"
  role          = "ACTIVE"
}
        

Custom VPC (google_compute_network):

• name: Dynamically creates a VPC name, such as dev-terraform-gcp-project-vpc.
• auto_create_subnetworks = false: Disables automatic subnet creation, giving us full control over networking.

Subnets (google_compute_subnetwork):

• General Subnet:

1. Allocates an IP range (10.128.0.0/24) for application resources.
2. Links to the custom VPC (myvpc).

• Regional Proxy Subnet:

1. A special subnet with the REGIONAL_MANAGED_PROXY purpose, required for the HTTPS load balancer to function.
2. Uses the IP range 10.0.0.0/24 to isolate proxy traffic.

2. Configuring Firewall Rules

Firewall rules allow or deny specific traffic to your network. Here’s how we set them up:

resource "google_compute_firewall" "fw_ssh" {
  name = "${local.name}-fwrule-allow-ssh22"
  allow {
    protocol = "tcp"
    ports    = ["22"]
  }
  direction      = "INGRESS"
  network        = google_compute_network.myvpc.id
  priority       = 1000
  source_ranges  = ["0.0.0.0/0"]
  target_tags    = ["ssh-tag"]
}
        

Firewall Rule for SSH (fw_ssh):

• allow: Enables TCP traffic on port 22 (SSH).
• source_ranges: Accepts traffic from all IP ranges (0.0.0.0/0)—not recommended for production without IP whitelisting.
• target_tags: Ensures this rule applies only to resources tagged with ssh-tag.

Here’s another example for HTTP traffic:

resource "google_compute_firewall" "fw_http" {
  name = "${local.name}-fwrule-allow-http80"
  allow {
    protocol = "tcp"
    ports    = ["80"]
  }
  direction      = "INGRESS"
  network        = google_compute_network.myvpc.id
  priority       = 1000
  source_ranges  = ["0.0.0.0/0"]
  target_tags    = ["webserver-tag"]
}
        

Firewall Rule for HTTP (fw_http):

• Allows traffic on TCP port 80 for HTTP requests.
• Applies to resources tagged with webserver-tag.

Finally, we need a rule for health checks:

resource "google_compute_firewall" "fw_health_checks" {
  name = "fwrule-allow-health-checks"
  network = google_compute_network.myvpc.id
  allow {
    protocol = "tcp"
    ports    = ["80"]
  }
  source_ranges = [
    "1.1.1.1/16",
    "2.2.2.2./22"
  ]
  target_tags = ["allow-health-checks"]
}
        

Firewall Rule for Health Checks (fw_health_checks):

• Allows traffic from GCP’s health check IP ranges (1.1.1.1/16 and 2.2.2.2/22) on port 80.
• Ensures the load balancer can verify backend health.

Why These Steps Matter

1. Custom VPC: A custom VPC ensures your network is isolated and secure, with control over IP ranges and subnets.
2. Firewall Rules: Protect your resources by limiting access to specific traffic (e.g., SSH, HTTP).
3. Proxy Subnet: Essential for enabling a Regional HTTPS Load Balancer.

What’s Next?

In Part 3, we’ll set up instance templates and managed instance groups (MIGs) to automate scaling and ensure high availability. This will be the backbone of our backend infrastructure.

Conclusion

By completing this part, you’ve built the networking layer for your infrastructure:

• A custom VPC with defined subnets.
• Firewall rules to control traffic for SSH, HTTP, and health checks.

These configurations provide a secure and scalable foundation for deploying application resources.