Private Connectivity for VPC Networks

1.1Implementing and Governing VPC Network Peering

VPC Network Peering (opens in a new tab) is a bilateral connection that provides internal IP connectivity between two Virtual Private Cloud (VPC) (opens in a new tab) networks. The two networks can be in the same project, in different projects, or in different organizations, and can mix IPv4-only, dual-stack, and IPv6-only subnets. Traffic flows only between the two directly peered networks because peering is non-transitive and never forwards traffic to a third network.

Cross-project peering requires coordination because no administrator can list peering requests for a VPC network. The local administrator must obtain the peer VPC network name and peer project ID from the peer administrator, and the Compute Engine API must be enabled. Peering operations are governed by the Compute Network Admin role or a custom role with explicit permissions for compute.networks.addPeering to create, compute.networks.updatePeering to change route exchange or stack type, compute.networks.removePeering to delete, and compute.networks.listPeeringRoutes to inspect exports and import candidates. Only one peering operation at a time is allowed across peered networks.

A peering becomes usable only after both sides configure toward each other:

1. Create first side: Create peer-ab in network-a that references the peer project and network-b, with import and export of custom routes selected.
2. Create matching side: Create peer-ba in network-b that references the first project and network, usually by the peer administrator.
3. Exchange implicit routes: When both sides are ACTIVE, subnet routes and enabled custom routes are exchanged automatically as implicit routes with no route resources.

The first side alone stays INACTIVE while waiting for the peer. In gcloud, each side uses gcloud compute networks peerings create with --network, --peer-project, and --peer-network. Route verification distinguishes offered routes from installed routes, so the Effective routes view filtered to Peering subnet, Peering static, or Peering dynamic shows which routes are installed versus suppressed due to conflict.

1.2Architecting and Securing Shared VPC Infrastructures

Shared VPC (opens in a new tab) is a model that shares one or more VPC networks from a central host project with service projects in the same organization. The host project holds the shared networks, subnets, routes, and firewall rules, while attached service projects hold workloads such as Compute Engine instances that use those shared subnets with internal IP addresses. This split keeps network boundary control centralized while delegating workload creation to separate teams.

Administrative boundaries enforce strict separation. A project is either a host project or a service project, never both, and each service project attaches to only one host project. An organization can operate multiple host projects. A host project must first be enabled by a Shared VPC Admin before service projects attach, and any VPC network inside a service project stays local and is never shared. Attachment does not convert existing resources, so an instance or private zone created before attachment must be re-created to use a shared subnet.

Delegation follows least privilege by separating network changes from workload placement. Shared VPC Admins enable the host and attach service projects, Network Admins manage subnets, Cloud VPN gateways, Cloud Router instances, and routes, Security Admins manage firewall rules, and Service Project Admins create eligible resources in authorized shared subnets. Subnet-level grants are preferred for isolation, while project-level grants allow use of any subnet:

All firewall rules for the Shared VPC network are created in the host project. Instances in different service projects communicate over internal addresses only as host firewall rules allow. The same central control extends to hybrid: a Network Admin creates the Cloud VPN gateway and Cloud Router in the host project, and with global dynamic routing the learned on-premises routes apply to all subnets. For stronger separation, use multiple host projects for test versus production or when quotas or independent IAM control require it.

1.3Configuring Private Google Access for On-Premises and Hybrid Workloads

Private Google Access for on-premises hosts (opens in a new tab) lets private on-premises systems reach Google APIs without public internet paths. Traffic flows from on-premises hosts through a Cloud VPN tunnel or Cloud Interconnect VLAN attachment into the VPC network, then from the VPC network to Google API virtual IP (VIP) ranges. The VPC network depends on Cloud Router advertisements, Cloud DNS (opens in a new tab) resolution, and VPC Service Controls policy to keep that traffic private.

Cloud Router is the Border Gateway Protocol (BGP) speaker that exchanges routes between the VPC network and the on-premises network. To make APIs reachable, the Cloud Router advertises a custom route for 35.199.192.0/19 back to on premises. First the hybrid connection is established with BGP, then the custom advertisement is added on the Cloud Router in the VPC network that fronts the connection, then the on-premises router installs that route and forwards matching traffic into Google Cloud. Firewall rules on both sides must still allow API and DNS traffic.

DNS steers API names to private VIPs and connects both namespaces. A Shared VPC hybrid setup follows an ordered sequence where forwarding zones, server policies, and routing combine so corp.example.com resolves on premises and gcp.example.com resolves in Google Cloud from either side. VPC Service Controls then places VPC resources, Google-managed services, and the on-premises network inside a service perimeter to control data movement. The perimeter cannot contain projects from different organizations, but perimeter bridges allow cross-perimeter communication. Routing and DNS determine how hosts reach the API VIP, while VPC Service Controls determines whether the API call may move data across the boundary.

2.1Establishing Dedicated Private Connectivity

Cross-Cloud Interconnect is a dedicated physical connection between Google Cloud and Amazon Web Services (AWS) networks that Google provisions on behalf of the customer. The model resembles Dedicated Interconnect because it needs no partner provider, which is why ordering uses --interconnect-type=DEDICATED. Google reserves ports and builds the physical connection, while the customer completes location choice, authorization, VLAN attachment creation, and BGP peering. Each VLAN attachment is a logical connection between a region in the Virtual Private Cloud (VPC) (opens in a new tab) network and AWS resources.

Establishing the connection follows a fixed order where later steps depend on earlier reservations:

1. Choose locations: Identify locations for primary and redundant Interconnect and AWS ports and record the names.
2. Order Google connections: Order primary and redundant connections so Google reserves two ports.
3. Order AWS ports: Order AWS ports, download the letter of authorization (LOA), and send it to Google to trigger establishment.
4. Configure Google Cloud resources: Create a redundant set of VLAN attachments and use Cloud Router to configure a BGP peering session for each attachment.
5. Configure AWS resources: Configure AWS resources, including the AWS-side BGP peering session.
6. Verify connections: Follow verification steps to confirm connectivity.

High availability requires two connections, primary and redundant, in the same Remote location and Google Cloud location to satisfy the service level agreement (SLA). The remote location is the AWS location name used in Google Cloud ordering, while the Google Cloud location is the facility location. Capacity is chosen at order time and sets the number of Link Aggregation Control Protocol (LACP) links, from 10 Gb/s up to 400 Gb/s with 4 x 100 Gb/s links. In gcloud, --link-type sets capacity such as LINK_TYPE_ETHERNET_10G_LR, --requested-link-count sets 1 to 4 links for 10-Gbps or 1 to 2 links for 100-Gbps, plus --location, --remote-location, and --noc-contact-email.

2.2Architecting Hybrid Connectivity with High Availability and Redundancy

High-Availability Virtual Private Network (HA VPN) (opens in a new tab) is the IPsec VPN solution that securely connects a peer network to a VPC network through encrypted tunnels. When an HA VPN gateway is created, Google Cloud automatically assigns two external IP addresses, one per gateway interface, each from a unique pool. Each interface supports multiple tunnels, and multiple gateways can be created in the same region. HA VPN supports only dynamic routing with BGP and supports active/active and active/passive routing, where active/active lets multiple tunnels carry traffic at once for higher volume. Depending on topology, HA VPN provides 99.99% or 99.9% availability, and an external VPN gateway resource stores peer gateway information.

Cloud Interconnect (opens in a new tab) is the private-transport family that extends an on-premises network to VPC networks without traversing the public internet. The family includes Dedicated Interconnect for direct physical connection, Partner Interconnect through a service provider, and Cross-Cloud Interconnect between clouds. Redundancy requires more than one attachment in more than one failure domain, such as two Dedicated Interconnect connections in a common colocation facility with routes exchanged between Cloud Router and the remote gateway. A single Partner Interconnect connection has no SLA, while redundant Partner topologies offer 99.9% to 99.99%, and Cross-Cloud Interconnect offers 99.9% and 99.99% options.

Encryption behavior differs by product. Cloud VPN encrypts with IPsec, where one gateway encrypts and the other decrypts, and it cannot route to the public internet. Cloud Interconnect alone does not encrypt, so encryption must be added with Media Access Control Security (MACsec) or HA VPN over Cloud Interconnect, which combines IPsec encryption with Interconnect capacity and never traverses the public internet. When HA VPN runs over Interconnect, gateway interfaces can use regional internal IP addresses only for gateways associated with VLAN attachments.

2.3Managing Routing, Security Integration, and Trade-Offs

Cloud Router (opens in a new tab) provides BGP-based dynamic routing for hybrid connectivity and is used together with Cloud VPN gateways and Cloud Interconnect, not as a standalone connection. Cloud Router exchanges routes with the on-premises router over HA VPN tunnels and Interconnect VLAN attachments, so traffic flows from the data center to the VPC network over the healthy path and fails over when a tunnel or attachment fails. The physical Interconnect provides ports, the VLAN attachment binds a VPC region to that connection, and the BGP session manages dynamic exchange. For complex environments, Network Connectivity Center (NCC) (opens in a new tab) connects spokes such as VPC networks and hybrid connections to a central hub that manages connectivity and route exchange.

Resilient design weighs SLA, performance, security, cost, reliability, bandwidth, and operational complexity together:

Network security integration ensures VPC firewall rules and hierarchical policies apply once traffic reaches the VPC network. With intranode visibility, Google Kubernetes Engine (GKE) Pod-to-Pod traffic is processed by the VPC network even on the same node, so firewall rules, flow logs, and packet mirroring apply to all Pod communication. Intranode visibility requires GKE 1.15 or later, is not supported with Windows Server node pools, and is disabled by default on Standard clusters and enabled by default on Autopilot clusters.

3.1Analyze and Configure Private Google Access for VPC Resources

Private Google Access (opens in a new tab) is a subnet-level setting that lets virtual machine (VM) interfaces without an external IP address reach Google APIs and services. Traffic from those VMs uses the VPC network's default-internet-gateway as the next hop but stays inside Google's network and does not traverse the public internet. By default a VM without an external address can send only to internal destinations, and Private Google Access removes that limit for its subnet. Google Kubernetes Engine (GKE) automatically enables the setting on subnets where nodes are deployed.

Enablement depends on isolation plus API need. The feature serves *.googleapis.com endpoints, web applications such as Gmail and Google Maps, serverless domains such as *.appspot.com, *.run.app, and *.cloudfunctions.net, files from *.gstatic.com, and external addresses used by App Engine. A VM interface with an external IPv4 or IPv6 address does not need the feature. All requirements must hold at once: the interface sits in a subnet with the feature on, the VPC network meets Google API network requirements, the interface has no external address, and the packet source matches the primary internal IPv4, internal IPv6, or alias IP range. If IPv6 is used, the VM needs a /96 range and software must send from that range.

Routing uses the default-internet-gateway next hop for API ranges. In a normal network the 0.0.0.0/0 default route already points there, so no extra route is needed. When 0.0.0.0/0 is redirected, such as to an on-premises inspection device, explicit routes for API ranges must still point to default-internet-gateway. For hardened perimeters, DNS and routing point to restricted.googleapis.com at 199.36.153.4/30 and 2600:2d00:0002:1000::/56, neither announced to the internet, with a static route sending 199.36.153.4/30 to default-internet-gateway. Enabling on a subnet is per-subnet, so place VMs on the enabled subnet and connect the interface with the default route, usually nic0, there:

1. List subnets: Run gcloud compute networks subnets list filtered by network to find name and region.
2. Enable the feature: Run gcloud compute networks subnets update with --enable-private-ip-google-access.
3. Verify the state: Run gcloud compute networks subnets describe to confirm privateIpGoogleAccess is enabled.

3.2Implement and Contrast Restricted Google Access and Private Service Connect

Restricted Google Access and Private Service Connect (opens in a new tab) endpoints are two private paths that keep traffic within Google's network. Restricted Google Access limits reachability to a VPC Service Controls-compliant subset through the restricted.googleapis.com virtual IP (VIP). Private Service Connect exposes Google APIs through an internal IP address inside the consumer VPC network. Both avoid the public internet but differ in filtering and control.

Restricted Google Access resolves *.googleapis.com via Cloud DNS to restricted.googleapis.com, which maps to 199.36.153.4/30 and 2600:2d00:0002:1000::/56. Those VIPs are not announced to the internet, and using them denies APIs not supported by VPC Service Controls, reducing exfiltration risk. VMs must have only private addresses in a subnet with Private Google Access enabled, with a static route sending 199.36.153.4/30 to default-internet-gateway and firewall rules allowing egress to that range. For on-premises hosts, traffic flows through Cloud VPN or Interconnect, on-premises DNS maps *.googleapis.com to restricted.googleapis.com, and 199.36.153.4/30 is made reachable by static route or BGP advertisement from Cloud Router. The connected VPC network must be in the same service perimeter as the resource or connected by a perimeter bridge.

Private Service Connect endpoints reserve an internal address with purpose PRIVATE_SERVICE_CONNECT and create a global forwarding rule with --target-google-apis-bundle that forwards to Google APIs. A private DNS zone for googleapis.com. maps googleapis.com with an A record to the endpoint IP such as 10.0.1.1 and *.googleapis.com with a CNAME to googleapis.com.. Firewall policy then controls the endpoint IP directly, for example allowing TCP 443 only to 10.0.1.1 while denying all other egress. The vpc-sc bundle aligns with perimeter services, while all-apis needs service patterns to limit unsupported APIs.

3.3Design Private Connectivity for Hybrid and On-Premises Environments

Private connectivity for hybrid environments lets hosts outside Google Cloud reach Google APIs and workloads without crossing the public internet. Traffic flows from the on-premises network over Cloud Interconnect or Cloud VPN into a VPC network, then over Google's internal infrastructure to the API or service. Private Service Connect endpoints and internal load balancers provide private IP entry points with more isolation than the basic path.

Private Google Access for on-premises hosts is the basic configuration. The host sends API traffic through Interconnect or VPN IPsec tunnel into the VPC network, which forwards it over Google's network. Cloud Router exchanges BGP routes with Interconnect, VPN, and Router appliances so return traffic stays private. A Private Service Connect endpoint for hybrid access adds an internal address in a routing VPC network with a private DNS zone for the API name such as run.app. Traffic flows from on premises over Interconnect or VPN to the endpoint IP, then internally to the destination such as a Cloud Storage bucket in a service project, so uploaded data never travels over the internet.

An internal Application Load Balancer adds load-balancing controls without internet exposure. When the routing VPC, application VPC, and hybrid connections are spokes of the same Network Connectivity Center hub, the hub exports and re-exports spoke subranges so external clients reach the load-balanced service privately. If the service must cross administrative boundaries, it can be published with Private Service Connect behind the internal load balancer, with an endpoint created in the consumer network. Gated egress reverses direction in a controlled way: Google Cloud workloads initiate to select private APIs exposed through a gateway, load balancer facade, or Private Service Connect endpoint in an isolated segment, using overlap-free RFC 1918 addresses, IP allowlists, and stateful firewall rules, while direct inbound initiation from the private environment is denied.

4.1Architect Cloud NAT Solutions for Secure Outbound Connectivity

Cloud NAT (opens in a new tab) is a managed egress service that lets private workloads reach the internet without public addresses. Traffic flows from a private VM or Pod endpoint to a Cloud NAT gateway, which translates the private source to a selected outgoing address and forwards it externally. Return traffic flows back through the same gateway to the origin. Because private endpoints never appear directly on the internet, the gateway becomes the central point for controlling which workloads can egress and which identity they present.

Gateway scope defines a project-scoped and zone-scoped control for external North-South traffic, not internal East-West traffic. The configuration names leaf subnets that hold outgoing IP addresses and label selectors that match eligible Pod or VM endpoints, and subnets, endpoints, and traffic must all reside in the same zone and project as the gateway. Egress follows an ordered path where the private endpoint initiates, the gateway matches by label and translates the source, then forwards externally and reverses translation for responses. Only matched endpoints obtain translation, so all other private endpoints stay isolated.

Project default egress NAT is a deprecated automatic model where endpoints labeled egress.networking.gke.io/enabled:true egressed with an automatically assigned project IP. Cloud NAT is now the main solution, and the two models cannot be used together on the same endpoint:

Layering surrounds translation with VPC controls. Private resources keep only internal addresses and reach Google APIs through Private Service Connect or Private Google Access, organizational policies restrict external addresses, and stateful VPC firewall rules filter endpoint-to-gateway and internal traffic with service-account or tag targets. VPC Service Controls perimeters control data movement, and Secure Web Proxy is used when outbound web traffic needs HTTP(S) inspection and identity controls instead of raw translation.

4.2Integrate Cloud NAT with Broader Network Security and Observability Frameworks

Cloud NAT integration combines managed translation with firewall, private-access, and monitoring controls. A Cloud Router holds the gateway configuration as the control plane, while Andromeda software in the VPC network performs source translation on outbound packets and destination translation only for established responses. Cloud NAT never allows unsolicited inbound connections.

VPC firewall rules still govern NAT egress, so a private VM reaches the internet only when egress rules allow it. A Public NAT gateway is tied to one VPC network and serves only selected subnet ranges, and with manual NAT IP assignment it shares a fixed set of external sources that destinations can allowlist. Outbound traffic moves in order: first egress firewall evaluation from the VM internal IP, then source translation at the gateway to a shared external IP and port, then return translation only for established connections. Private NAT performs the same function for private-to-private traffic using a Private NAT subnet range. Traffic to Google APIs bypasses Public NAT through Private Google Access, which takes precedence, creating a boundary where internet egress uses NAT external addresses while API traffic stays private.

Defense in depth around GKE egress separates translation from authorization. Pod traffic in a service mesh leaves through dedicated egress gateway proxies that scale with horizontal Pod autoscaling, and the NAT gateway must provide enough ports to avoid exhaustion. Enforcement divides by layer: VPC firewall rules at Layer 4 for nodes by service account or tag, Kubernetes network policies at Layer 4 for Pods by namespace, and authorization policies at Layer 7 for mesh and egress traffic. Logging is disabled by default and, when enabled, supports compliance recording, debugging of failed flows, analytics of destinations, and accounting by workload. Metrics flow to Cloud Monitoring for dashboards and alerts on port exhaustion, dropped packets, connection growth, or volume spikes, while Network Analyzer (opens in a new tab) publishes NAT insights as a complement.

4.3Configure and Optimize NAT Gateway Parameters and Routing

Cloud NAT configuration tunes how a distributed translation service assigns addresses and ports without exposing private subnets. A Public NAT gateway is bound to one VPC network in one region and serves only selected primary and secondary IPv4 ranges, or internal and external ranges for IPv6 NAT64. It cannot select individual VMs, so every eligible endpoint in chosen ranges shares the gateway, and multiple gateways in the same region and VPC network must use unique subnets or ranges. A Cloud Router holds the configuration while Andromeda hosts enforce it.

Static and dynamic port allocation control division of the NAT IP and port pool:

With manual allocation, reserve enough addresses because an undersized pool drops packets and can cause HTTP 5xx for proxy load balancer endpoints. For regional internet network endpoint groups (NEGs) behind managed proxy load balancers, use 2048 minimum and 4096 maximum ports per VM. For OS updates, specify at least 160 minimum ports per instance. Endpoint-independent mapping (EIM) reuses the same external IP and port for a private endpoint across destinations for application compatibility, but a gateway with EIM enabled cannot use dynamic port allocation or NAT rules. Several changes break established flows, including changing NAT IP network tier or manual addresses, reducing minimum ports with static allocation, any change with dynamic allocation that resets VMs to minimum, or turning off dynamic allocation.

Key Facts

• VPC Network Peering is bilateral and non-transitive, becoming ACTIVE only after both VPC networks create matching peering configurations toward each other.
• Shared VPC shares networks from a central host project with service projects in the same organization, where a project cannot be both host and service and a service project attaches to only one host.
• Private Google Access for on-premises hosts requires Cloud Router to advertise 35.199.192.0/19 to on premises so API traffic flows through Cloud VPN or Cloud Interconnect into the VPC network.
• Restricted Google Access uses restricted.googleapis.com at 199.36.153.4/30 to allow only VPC Service Controls-supported APIs, while Private Service Connect endpoints expose Google APIs through an internal IP with a forwarding rule using --target-google-apis-bundle.
• Cloud NAT translates private VM or Pod sources to selected outgoing addresses for internet egress, never allows unsolicited inbound connections, and is bypassed by Private Google Access for traffic to Google APIs.