Private Google Access is a feature that allows virtual machine instances without external IP addresses to reach Google APIs and services using their internal IP addresses. When Private Google Access is enabled on a subnet, traffic to Google APIs flows through the default internet gateway but stays within Google's network infrastructure rather than crossing the public internet. This keeps your workloads secure while still allowing them to communicate with Google Cloud services like Cloud Storage, BigQuery, and Compute Engine APIs.
To enable Private Google Access, go to the subnet configuration in the Google Cloud console and turn on the Private Google Access setting, or use the gcloud command with the --enable-private-ip-google-access flag. Google Kubernetes Engine automatically enables Private Google Access on subnets where nodes are deployed. However, Private Google Access does not support all Google APIs; organizations that need access to additional services or more granular control should consider Private Service Connect as an alternative.
Private Service Connect provides a more flexible way to access Google APIs and services through endpoints in your VPC network. Unlike Private Google Access, Private Service Connect lets you create one or more internal IP addresses that forward requests to Google APIs, giving you precise control over which APIs are accessible. Private Service Connect supports all Google Cloud APIs and most other Google APIs and services, making it the preferred choice for organizations with strict security requirements.
Private Service Connect endpoints are created using global forwarding rules that map an internal IP address to Google's API infrastructure. When you create an endpoint, you can specify whether it should access all Google APIs or a specific subset, and you can configure DNS entries to resolve API domains to your endpoint's IP address. The endpoint stays accessible even from VMs with external IP addresses because the connectivity remains within Google's network.
VPC Service Controls creates security perimeters around Google Cloud resources and managed services to prevent data from leaking out. A service perimeter groups projects and VPC networks together, then restricts access to Google-managed services from outside the perimeter by default. Traffic from outside the perimeter to protected services is blocked unless explicitly allowed through ingress policies, while traffic from inside to services outside is restricted through egress policies.
To implement a VPC Service Controls perimeter, you must first configure private connectivity to Google APIs using either Private Google Access or Private Service Connect. Then you create the perimeter through the VPC Service Controls interface in the Google Cloud console. Organizations should start with dry run mode to identify and resolve any connectivity issues before enforcing the perimeter in production.
Cloud NAT enables VM instances without external IP addresses to initiate outbound connections to the internet without exposing individual VMs to inbound internet traffic. When workloads need internet access for downloading software packages or accessing third-party APIs, Cloud NAT translates internal IP addresses to a limited set of NAT IP addresses, giving you visibility and control over outbound traffic.
Cloud NAT is configured at the region level, with each gateway serving VMs in that region's subnets. You can customize which subnets the NAT gateway serves and configure logging to capture translation events for troubleshooting and auditing. Cloud NAT provides a centralized point for controlling and logging all outbound internet access, complementing the inbound protections provided by VPC Service Controls and firewall rules.
Firewall rules in Google Cloud are stateful and applied to each VM, meaning that if a connection is allowed in one direction, return traffic is automatically permitted. Create firewall rules that allow outbound traffic to Private Service Connect endpoint IP addresses on TCP port 443 while denying broader internet egress to protect against data exfiltration. Use network firewall policies for organization-wide rule management.
IAM policies work alongside network controls to secure API access by defining who can perform operations on Google Cloud resources. The principle of least privilege should guide role assignments, granting only the permissions necessary for each workload to function. For service accounts used by applications, avoid giving too many permissions and consider using workload identity federation for applications running outside Google Cloud.
Organization policies provide additional layers of control by restricting resource configurations that could increase internet exposure. The Define allowed external IPs for VM instances constraint prevents VMs from acquiring external IP addresses by default. The Restrict Protocol Forwarding Based on type of IP Address constraint prevents the creation of forwarding rules with external IP addresses. These policies can be customized at the organization, folder, or project level to allow exceptions for specific use cases while maintaining broad restrictions.
Private Service Connect is a Google Cloud networking capability that allows consumers to privately access Google APIs, Google-managed services, and third-party services using internal IP addresses inside their own VPC network. Traffic sent to a PSC endpoint stays entirely within Google's private network backbone, bypassing the public internet without requiring external IP addresses or complex VPC Network Peering configurations.
Private Service Connect operates using a producer-consumer model. A service producer exposes their workload by creating a service attachment, which manages an authorization list known as the consumer accept list. The service consumer provisions a forwarding rule in their VPC network that references the producer's service attachment, creating a PSC endpoint with a dedicated internal IPv4 address. Alternatively, consumers can create a PSC network endpoint group as a backend for a load balancer, unlocking features such as logging, traffic management, Google Cloud Armor integration, and health monitoring.
Private Service Connect provides architectural and security advantages over Private Google Access and Cloud NAT. While Private Google Access routes traffic to shared Google IP ranges through a default internet gateway, PSC assigns an explicit, dedicated internal IP address from the consumer subnet to each specific service. This dedicated IP address allows network administrators to write strict VPC firewall egress rules that permit traffic only to a specific service IP address while blocking all other outbound destinations.
Unlike private services access, which relies on non-transitive VPC Network Peering and requires large reserved IP address blocks, PSC consumes only individual IP addresses and supports transitive routing across hybrid network topologies. Cloud NAT, by contrast, sends traffic out to the public internet to reach public endpoints of Google services.
Configuring a PSC endpoint requires allocating an internal IP address and creating a forwarding rule that binds that address to a target service or Google API bundle. When deploying in a Shared VPC architecture, administrators must reference the subnet by its complete resource URI, specifying the host project ID to avoid resource discovery errors.
For managed services such as Apigee or Cloud SQL, the consumer first queries the producer instance to retrieve the unique service attachment resource URI. The consumer then provisions a forwarding rule pointing to that URI. The connection remains in a PENDING state until verified against the producer's consumer accept list, transitioning to ACCEPTED once approved.
Consuming services via PSC requires directing client traffic to the internal PSC endpoint IP address through proper DNS management. When a PSC endpoint for Google APIs is created, Service Directory automatically creates DNS records in a private DNS zone, generating fully qualified domain names in the format SERVICE-ENDPOINT.p.googleapis.com. For custom consumer-to-producer setups, administrators configure private zones in Cloud DNS to map standard service hostnames directly to the internal PSC endpoint IP address.
For hybrid architectures extending to on-premises environments, custom DNS policies and Cloud Router advertisements allow on-premises clients to resolve and route traffic to the PSC endpoint seamlessly over Cloud VPN or Cloud Interconnect.
PSC endpoints integrate with VPC Service Controls and IAM to establish defense-in-depth perimeter security. Organizations configure PSC endpoints to target restricted VIP interfaces within a VPC-SC perimeter, preventing data exfiltration by ensuring requests can only reach authorized cloud resources. Administrators can deploy service perimeters in dry run mode to analyze violation logs and validate that legitimate API traffic correctly passes through the PSC endpoint before switching to enforced mode.
Operational management of PSC endpoints requires monitoring connection statuses and resolving policy mismatches. An endpoint status of PENDING indicates that the consumer project ID is missing from the producer's consumer accept list, requiring the producer to update their authorized project configuration. Automated connection failures can surface error codes such as CONNECTION_POLICY_MISSING when no regional service connection policy exists, or CONSUMER_INSTANCE_PROJECT_NOT_ALLOWLISTED when the producer instance location falls outside the policy scope.
Private Google Access is a VPC networking feature that allows Compute Engine virtual machine instances without external IP addresses to reach the external IP addresses of Google APIs and services. PGA is enabled at the subnet level and works by allowing egress traffic from VMs on that subnet to flow through the VPC network's default internet gateway to Google's restricted set of public service endpoints.
For PGA to function, a VM's network interface must be attached to a subnet where PGA is enabled, and the source IP of the traffic must match the VM's primary internal IPv4 address, an IPv6 address from its range, or an alias IP address. The VPC network itself must have the correct routing and firewall configuration to allow this traffic. PGA requires the use of a modern VPC network; legacy networks are not supported. VM instances that do have an external IP address can reach Google APIs without PGA because their traffic uses standard public paths.
Enabling PGA is a subnet-level configuration. You turn it on for each subnet where your private VMs reside. The default firewall rules in a VPC network include an implied allow egress rule, which typically permits the necessary traffic. However, you must ensure no higher-priority firewall rules block egress to the IP ranges used by Google APIs.
There are two main routing configurations for PGA. In the simplest default routing setup, your VPC network uses the system-generated default route with a next-hop of default-internet-gateway. If your network uses this default route, PGA traffic will automatically follow it to Google's services. In a custom routing scenario where the default route points elsewhere, you must create explicit, more specific routes for Google API IP ranges and direct them to the default-internet-gateway.
PGA supports different domain options, which determine the IP addresses your VMs use to reach services. The default domains option uses the standard public IP addresses for services like storage.googleapis.com. No special DNS setup is needed, but routing and firewall must allow egress to those public IPs.
For a more controlled private access method, you can use the private.googleapis.com domain. This method uses a restricted set of VIPs. To use it, you must create DNS records in a private DNS zone that resolve *.googleapis.com to the private.googleapis.com domain. A similar domain, restricted.googleapis.com, is used specifically when VPC Service Controls are enabled, providing a dedicated path for accessing services within a secured perimeter.
PGA can be extended to on-premises hosts through hybrid connections like Cloud VPN or Cloud Interconnect. In this architecture, traffic from on-premises systems flows over the private hybrid link into the Google Cloud VPC. To enable this, you advertise the PGA subnet routes or the IP addresses of private.googleapis.com VIPs from your Cloud Router to the on-premises network via BGP. You must also configure DNS in the on-premises environment so that requests for Google APIs resolve to the private VIPs within Google Cloud, ensuring the traffic route stays private and does not egress to the public internet.
Private Google Access routes traffic to shared Google IP ranges through a default internet gateway, while Private Service Connect creates dedicated internal IP endpoints for each specific service. PSC provides finer-grained firewall control and supports all Google APIs, whereas PGA has more limited API support.
Use Cloud NAT when workloads need general outbound internet access to reach public endpoints beyond Google APIs, such as downloading software packages or accessing third-party services. Use Private Google Access when you only need to reach Google APIs and services from private VMs.
The consumer accept list controls which projects are authorized to connect to a service attachment. When a consumer creates a forwarding rule, the connection remains in a PENDING state until the producer adds the consumer's project ID to their accept list, at which point the connection transitions to ACCEPTED.
Professional Cloud Network Engineer
Prepare and test your skills
Prepare and test your skills
StudyCerts
StudyCerts