Private Connectivity

A hardened GCP org keeps its VMs and managed services off the public internet entirely, and three mechanisms make that work: Private Service Access for reaching Google-managed services like Cloud SQL over a private IP, Private Service Connect for private endpoints to services and APIs, and Cloud NAT with a Cloud Router for outbound internet from VMs that have no external IP.

Hatch's app VMs and its Cloud SQL instance live entirely on internal addresses, which is why "no external IP" is an org-policy constraint the design has to satisfy from the start rather than bolt on later. The three mechanisms are not interchangeable — each solves a different leg of the private-posture problem, and mixing them up is the usual cause of "the VM can't reach Cloud SQL but can reach the internet."

Why "No External IP" Is a Policy

An external IP is an attack surface and a data-exfiltration path. Most security-conscious orgs set an org policy — constraints/compute.vmExternalIpAccess — that denies external IPs outright, so no engineer can attach one even by accident. Your network then has to give VMs both egress and service access without one, which is exactly what the rest of this topic builds.

For Hatch this is a hard constraint, not a preference. Every VM in hatch-app-prod starts with no public face, and the design has to make a no-external-IP VM fully functional — able to patch itself, reach Cloud SQL, and call Google APIs — using only the private mechanisms below.

Private Service Access for Cloud SQL

Google-managed services like Cloud SQL run in Google's own VPC, not yours. Private Service Access bridges the two: you reserve a range with google_compute_global_address and create a google_service_networking_connection that peers your VPC to the service producer's network. Cloud SQL then gets a private IP drawn from your reserved range and never needs a public endpoint.

The ordering matters and bites people. You must reserve the global address range before the service networking connection, or Cloud SQL's private IP allocation fails with a peering error. And size the reserved range generously — a tight /24 runs out of private IPs as you add managed instances, and the range is hard to grow after services attach.

resource "google_compute_global_address" "psa" {
  project       = "hatch-net-host"
  name          = "psa-range"
  purpose       = "VPC_PEERING"
  address_type  = "INTERNAL"
  prefix_length = 16                # generous — hard to grow after services attach
  network       = google_compute_network.hatch.id
}

resource "google_service_networking_connection" "psa" {
  network                 = google_compute_network.hatch.id
  service                 = "servicenetworking.googleapis.com"
  reserved_peering_ranges = [google_compute_global_address.psa.name]
}

Private Service Connect

Private Service Connect creates a private endpoint IP inside your own subnet that fronts a Google API or a published service. A google_compute_forwarding_rule-based PSC endpoint means traffic to those services stays on internal addresses, instead of leaving your VPC to reach *.googleapis.com over the public internet.

Where Private Service Access is the right tool for managed services that publish over service networking, PSC is the tool for API access and finer-grained private endpoints. The two coexist in a hardened design: PSA gives Cloud SQL its private IP, PSC gives the app a private path to Google APIs.

Cloud NAT and Cloud Router

A google_compute_router paired with a google_compute_router_nat gives internal-only VMs outbound internet — package mirrors, external APIs — through a managed NAT, with no per-VM external IP and no inbound exposure. This is egress without a public face: the VM can run apt and call an external API, but nothing on the internet can initiate a connection to it.

The boundary to keep straight is that Cloud NAT is outbound only. It solves egress and does nothing for ingress — no service reaches in to your VMs through it. And it is for the open internet, not for reaching Google services; use Private Service Access or PSC for those. Conflating the two is the classic "the VM has internet but can't reach Cloud SQL" symptom.

resource "google_compute_router" "nat" {
  project = "hatch-net-host"
  name    = "nat-router-uc1"
  region  = "us-central1"
  network = google_compute_network.hatch.id
}

resource "google_compute_router_nat" "nat" {
  project                             = "hatch-net-host"
  name                                = "nat-uc1"
  router                              = google_compute_router.nat.name
  region                              = "us-central1"
  nat_ip_allocate_option              = "AUTO_ONLY"
  source_subnetwork_ip_ranges_to_nat  = "ALL_SUBNETWORKS_ALL_IP_RANGES"  # outbound only
}

Putting It Together for Hatch

The full picture: the app VMs in hatch-app-prod have no external IP. They reach Cloud SQL over Private Service Access, reach Google APIs over PSC or Private Google Access, and reach the wider internet only outbound through Cloud NAT. Every leg of connectivity is satisfied without a single public endpoint.

Put the Cloud Router and Cloud NAT in hatch-net-host alongside the subnets, so egress is managed centrally for every service project rather than reinvented per app. This is the fully private posture the org policy demands — egress, service access, and API access all on internal addresses, with the public internet reachable outbound only and never inbound.