VPC Networking on Google Cloud

A subnet reserves four IPv4 addresses (the network address, the default gateway, the second-to-last address and the broadcast address), so a /29 is the smallest usable primary range. Primary ranges of subnets in one VPC cannot overlap, and ranges that you later want to peer or connect by VPN must not overlap on either side, so plan the address space for the whole company before creating the first subnet. A subnet’s primary range can be expanded (never shrunk) in place, which is the usual remedy for a range that was sized too tightly.

See VPC networks and Subnets.

A VPC network is created in one of two subnet creation modes.

The ranges of an auto-mode network overlap with the ranges of every other auto-mode network and fit poorly with VPN or peering, so the standard advice is to run custom-mode networks only. An auto-mode network can be converted to custom mode in place (the reverse is not possible). Newer organizations are created secure by default, and the organization policy compute.skipDefaultNetworkCreation stops projects from getting a default network and its open rules at all; older guides start with the default network, the current approach is to create a custom-mode VPC and delete default if it exists (see Governance, Security and Compliance).

Routes decide where a packet goes after the firewall allows it. Every subnet gets a subnet route automatically, and every VPC starts with a default route 0.0.0.0/0 whose next hop is the default internet gateway. A route is chosen by the most specific destination range first, then by lowest priority number (the default is 1000). Dynamic routes learned by a Cloud Router over BGP (from HA VPN or Interconnect) take part in the same selection; the network’s dynamic routing mode decides whether they cover one region (regional) or all regions (global).

See gcloud compute routes create and Routes.

Private Google Access lets VMs that have only internal IP addresses reach the external IP addresses of Google APIs and services (storage.googleapis.com, artifactregistry.googleapis.com, and so on). It is a per-subnet switch, shown above as --enable-private-ip-google-access, and it needs a route to the default internet gateway (or to the special Google API ranges) for the traffic to leave the VM, although the traffic never traverses the public internet. Two special domains narrow the destinations: private.googleapis.com (199.36.153.8/30) reaches all Google APIs, and restricted.googleapis.com (199.36.153.4/30) reaches only the APIs that VPC Service Controls supports, which is the pairing used with perimeters (below). Resolving those names to the chosen range needs a private Cloud DNS zone, see Cloud DNS and Certificate Manager. Private Google Access is only for Google APIs; reaching other services outbound is the job of Cloud NAT, and reaching a managed database privately is the job of Private Service Access or Private Service Connect, both below.

See Private Google Access and Configure Private Google Access.

Google Cloud has two generations of firewall objects, and the effective rule set for a VM is the combination of all of them. All of them are stateful: if a connection is allowed in one direction, return traffic is allowed automatically.

Rules have a direction (INGRESS or EGRESS), a priority from 0 to 65535 where a lower number wins, an action (allow, deny; policies also offer goto_next and, with Cloud NGFW, apply_security_profile_group), and a match. The two implied rules (deny all ingress, allow all egress) have the lowest possible priority, 65535, and cannot be deleted. By default, rules are evaluated in this order: hierarchical policies from the organization down to the folder of the project, then VPC firewall rules, then global network firewall policies, then regional network firewall policies, and finally the implied rules. A network setting (--network-firewall-policy-enforcement-order) can move VPC firewall rules after the network policies, which is what you want once you migrate to policies.

Cloud NGFW is the name of the firewall product that these policies belong to; it has three tiers. Essentials is the free layer-3 and layer-4 stateful filtering with tags, address groups and geography. Standard adds fully qualified domain name (FQDN) and geolocation objects and Google threat-intelligence lists. Enterprise adds intrusion detection and prevention (IDS/IPS) and TLS inspection through security profiles and endpoints. Check the tier comparison for what each costs and which of them are in Preview.

Why not 0.0.0.0/0? A source range of 0.0.0.0/0 on a rule that allows tcp:22, tcp:3389 or a database port publishes that port to the whole internet, and scanners find it within minutes. Allow the narrowest source possible: your office range, a load balancer’s health-check ranges (130.211.0.0/22 and 35.191.0.0/16), or the Identity-Aware Proxy range 35.235.240.0/20 for SSH and RDP through IAP TCP forwarding (see Compute Engine). A rule should also be scoped by target, so that only the machines that need the port see it.

An external IP address attached to a VM is ephemeral by default: it changes when the VM stops. A reserved (static) address stays yours until you release it and can move between resources. The decision that matters is the scope.

All external IPv4 addresses are billed by the hour; an address that is reserved but not in use costs more than one that is attached, so release addresses you do not need. Pricing and the exact distinctions are on the VPC pricing page, dated by the page itself; do not copy numbers from old blog posts, because the model changed when Google started charging for in-use external IPv4 addresses.

See gcloud compute addresses create and Reserve a static external IP address. In the console: VPC network, IP addresses, Reserve external static IP address (choose Regional or Global, IPv4 or IPv6, Premium or Standard network tier) or Reserve internal static IP address.

A VM, GKE node or Cloud Run revision with only an internal IP address cannot be reached from, or reach, the internet. Cloud NAT is the managed, software-defined outbound NAT service: a NAT configuration lives on a Cloud Router in one region, translates the source address of outbound connections to one or more NAT IP addresses, and allows return traffic for those connections only. There is no instance in the path and no throughput bottleneck, and nothing can open a connection into the network through it. Use it for patch downloads, calling third-party APIs (for example the SendGrid API from the notifier, see Sending Email from Google Cloud) and pulling public container images.

Two types exist. Public NAT translates private source addresses to external IPv4 addresses, either allocated automatically or taken from reserved addresses (reserve two addresses when a partner has to allow-list your egress IPs). Private NAT translates between private address spaces, for example between two VPC networks or from a VPC to on-premises over Network Connectivity Center or Cloud VPN when the ranges overlap; it needs NAT rules and does not use external IPs. Port allocation is the setting to understand: each VM is given a number of source ports per NAT IP (--min-ports-per-vm, default 64), a connection to the same destination address and port uses one port, and a VM that runs out of ports sees dropped connections and the OUT_OF_RESOURCES and NAT_ALLOCATION_FAILED counters in the NAT logs. Dynamic port allocation (--enable-dynamic-port-allocation) lets busy VMs grow their allocation between a minimum and a maximum, and is the recommended answer for many connections to few destinations.

Most managed services run in networks that Google or a producer owns, and the question is how your VPC reaches them with private addresses. Two mechanisms answer it.

Private Service Connect (PSC) exposes a service as an internal IP address in your own subnet: a forwarding rule whose target is either a bundle of Google APIs or a producer’s service attachment. There is no peering and no shared address space, so the ranges of consumer and producer may even overlap, and the connection is one-directional (the consumer reaches the producer, not the other way round). PSC comes in four shapes:

Private Service Access (PSA) is the older mechanism: you reserve an internal range (for example 10.20.0.0/16) in your VPC and create a VPC peering to Google’s servicenetworking.googleapis.com; the producer then allocates its instances (for example the Cloud SQL private IP) from that range. Because it is a peering it is non-transitive, so on-premises hosts cannot reach the instance unless the peering exports custom routes and the ranges do not overlap. Prefer PSC for new designs where the service supports it; PSA remains the default private-IP path for Cloud SQL instances and for several other services that have not moved, and GKE’s legacy private clusters used VPC peering (newer clusters use PSC and a DNS-based control plane endpoint, see GKE Clusters).

Cloud Run services and jobs, and Cloud Run functions, run outside your VPC. To reach a private IP (a Cloud SQL private address, a Memorystore instance, an internal load balancer) they can attach to a subnet in one of two ways. Direct VPC egress, generally available since 2024-04-24, assigns IP addresses from your subnet straight to the instances, needs no extra component, scales faster and costs less than the alternative, and is the current approach. Serverless VPC Access connectors are small managed VM groups that you size and pay for even while idle; older guides and tutorials still create them first, and they remain a fallback where Direct VPC egress is unavailable. The --vpc-egress setting decides what goes through the VPC: private-ranges-only sends only RFC 1918 (and other private) destinations through the network while public traffic goes straight out, and all-traffic sends everything, which is the setting to combine with Cloud NAT when a partner allow-lists a fixed egress IP. Plan the subnet size: Direct VPC egress consumes more addresses than the number of running instances, and the documented minimum is a /26.

See Direct VPC egress with a VPC network and Cloud Run. The tag set with --network-tags can be matched by VPC firewall rules so that only catalog-api instances can reach the database subnet.

See Connectivity Tests, Use VPC Flow Logs and Firewall Rules Logging. A short symptom list:

IAM answers "who may call this API". VPC Service Controls answers "from where, and may the data leave". It creates a service perimeter around the Google Cloud projects and services you choose (for example storage.googleapis.com, secretmanager.googleapis.com, bigquery.googleapis.com), and API calls that cross the perimeter boundary are blocked even with valid credentials. It exists to limit data exfiltration: a stolen credential, a mis-shared bucket or a developer copying a dataset into a personal project cannot move protected data out. Perimeters belong to an access policy defined at the organization (or a folder or project scope) and need Access Context Manager.

The pieces are: protected resources (projects, and VPC networks), restricted services, access levels (conditions such as source IP ranges, device state or identity that permit access from outside), and ingress and egress rules that allow specific identities, services and projects to cross the boundary in a defined direction. Always create a perimeter first in dry-run mode: it logs the violations it would have enforced, so you can fix ingress and egress rules before you break a production job. Combine it with Private Google Access through restricted.googleapis.com or a PSC endpoint for the vpc-sc bundle, so that calls from inside the network reach only supported APIs.

See VPC Service Controls overview, Create a service perimeter and Dry run mode. The 203.0.113.0/24 range is a documentation address. In the console, open Security, then VPC Service Controls (the project must be in an organization), choose Create perimeter, select the projects, restricted services and access levels, and use Dry run mode before enforcing. Note that the perimeter protects the APIs of the listed services only; it does not filter traffic between VMs, which is the firewall’s job, and it needs ingress and egress rules for legitimate cross-perimeter flows such as Cloud Build reading source from a bucket outside the perimeter. Governance topics that surround it are in Governance, Security and Compliance. The existing material on securing databases and data stores, such as Authentication, authorization & encryption, covers the engine layer; the network layer is this page.

The whole network can be declared with the Terraform hashicorp/google provider (version 8 at the time of writing), which is how teams keep ranges and rules reviewable; see Infrastructure as Code for state backends, modules and Infrastructure Manager.

See google_compute_network, google_compute_router_nat and Terraform on Google Cloud.

The VPC network, its subnets, routes and firewall rules (including Essentials-tier policies) are free. Costs come from what you attach to them: external IPv4 addresses (in use or reserved), network egress by volume, destination and network service tier, Cloud NAT (a gateway-hour component and a data-processing component), Private Service Connect endpoint hours and data processing for published services, VPC Flow Logs and Firewall Rules Logging (billed as Cloud Logging ingestion), Cloud NGFW Standard and Enterprise endpoint and inspection charges, and Interconnect and VPN (see VPN and Hybrid Connectivity). Traffic between VMs in the same zone over internal IPs is free; traffic across zones, regions or to the internet is billed, and egress to Google APIs through Private Google Access follows the destination service’s pricing. VPC Service Controls itself has no separate charge. There is no permanent free tier for NAT or addresses beyond the trial credits (see Getting Started with Google Cloud). Use the VPC network pricing and Cloud NAT pricing pages, both dated, and the pricing calculator for estimates.

Quotas that bite first: networks per project, subnets per project, firewall rules and policy rules per network or policy, static addresses per region, forwarding rules, peerings per network, and routes and instances per peered group. Check gcloud compute project-info describe and the VPC quotas page, and request increases in IAM & Admin, Quotas.

Delete in dependency order. A network cannot be deleted while subnets, routes, firewall rules, peerings, NAT gateways, forwarding rules or attached resources remain, and a reserved address keeps billing until it is released.

See gcloud compute networks delete, gcloud compute routers nats delete and gcloud compute addresses delete. Deleting a policy deletes its rules, but the association must be removed first. Tag values must be deleted before their key, and tag bindings on VMs go away with the VMs. Delete the second peering from the partner project, otherwise it stays INACTIVE. In the console: VPC network, VPC networks, select the network, Delete VPC network (which also removes its subnets, routes and firewall rules); Cloud NAT, Delete; IP addresses, Release static address; Security, VPC Service Controls, delete the perimeter. If you created the resources from a Terraform configuration, terraform destroy removes them in the right order. The simplest and most complete clean-up for a tutorial project is to delete the whole throwaway project (see Resource Hierarchy and Projects); perimeters and the access policy live at the organization and are not removed with the project.