GCP Connectivity to Managed Services: A Comprehensive Exam Guide

1. Introduction: Why Private Connectivity?

When you deploy applications on GCP, they often need to interact with platform-managed services. While many services offer public endpoints, connecting privately offers significant advantages:

• Enhanced Security: Traffic never leaves Google's private network, reducing exposure to the public internet and mitigating DDoS attacks, sniffing, etc.
• Improved Performance: Lower latency and higher throughput due to direct internal network routing.
• Simplified Network Architecture: No need to configure NAT gateways or complex firewall rules for public internet access.
• Compliance: Many regulatory frameworks (e.g., PCI DSS, HIPAA) require data to remain within a private network boundaries.

GCP offers several distinct methods to achieve this private connectivity, each designed for different scenarios and service types.

2. Private Services Access (PSA)

2.1. What is Private Services Access?

Private Services Access (PSA), also known as "VPC Service Networking," is the traditional and common way for your Google Cloud resources (VMs, GKE clusters, etc.) within your Virtual Private Cloud (VPC) network to connect privately to Google's managed services.

2.2. How it Works

PSA creates a dedicated, private connection between your VPC network and a Google-owned network, called the Service Producer VPC Network . This connection is established using a VPC Network Peering connection.

1. Allocate an IP Range: You must first allocate an IP address range (e.g., /20 or larger) within your VPC network that Google can use for its managed services. This range is reserved and cannot overlap with any other ranges in your VPC or peered networks.
2. Create a Peering Connection: You perform a one-time API call (`services vpc-peerings connect`) to establish a VPC Network Peering connection between your designated IP range and the Service Producer VPC Network.
3. Provision Managed Services: When you provision a managed service (e.g., Cloud SQL instance), it gets an internal IP address within the allocated Service Networking IP range.
4. Private Communication: Your VMs can then communicate with these managed service instances using their internal IP addresses, with traffic flowing securely and privately over the peering connection, entirely within Google's network.

2.3. Key Characteristics & Considerations

• Associated Services: Cloud SQL, Memorystore (Redis, Memcached), Cloud Spanner, Vertex AI Workbench (managed notebooks), older Apigee variants (Apigee Edge, Apigee hybrid).
• IP Address Management: Requires careful planning of your VPC and allocated IP ranges to avoid overlaps. Google generally recommends a /20 or larger, but the exact size depends on the number and type of services you plan to use.
• VPC Peering: Uses standard VPC Network Peering. Remember that VPC Peering is non-transitive. If your VPC is peered with another VPC, traffic from that peered VPC cannot directly reach the Service Producer VPC.
• Global Access: By default, services provisioned with PSA are often globally accessible within your VPC network, meaning resources in any region of your VPC can communicate with the managed service. Regional access can be configured.
• Firewall Rules: Standard VPC firewall rules apply to traffic going to/from the allocated IP range.
• High Availability: Managed services themselves are highly available; the peering connection is robust.

2.4. Use Cases

• GKE cluster needs to connect to Cloud SQL database privately.
• Compute Engine VMs needing to access a Redis instance on Memorystore.
• Dataflow jobs processing data from internal Cloud Spanner instances.

3. Private Service Connect (PSC)

3.1. What is Private Service Connect?

Private Service Connect is a more modern and flexible connectivity method introduced by Google. It offers two main modes of operation:

• Consumer-side: Allows resources in your VPC to access Google APIs and Google-managed services (like Apigee X) using internal IP addresses. This is primarily an alternative to public IP access or Private Google Access.
• Producer-side: Enables you to expose your own services (running in your VPC, potentially behind an internal Load Balancer) to other consumers (other VPCs, other projects, even other organizations) entirely within Google's network, without using VPC Peering or shared VPC.

PSC primarily uses internal IP addresses and doesn't require allocating a dedicated IP range for Google's services or direct VPC peering with the Service Producer VPC.

3.2. Private Service Connect (Consumer-side for Google APIs)

This allows VMs in your VPC to access most Google APIs (e.g., Cloud Storage, Pub/Sub, BigQuery) without requiring internet access or proxy VMs, and without consuming a dedicated IP range from your VPC for Google's services.

How it Works:

1. Create a Private Service Connect Endpoint: In your VPC, you create a dedicated forwarding rule or `gve` endpoint in a specific subnet and region. This endpoint is configured to point to a specific Google API service (e.g., `all-apis`, `pubsub.googleapis.com`).
2. Internal IP Access: The endpoint is assigned an internal IP address from your subnet. Traffic destined for Google APIs is routed to this internal IP.
3. Secure Routing: Google's network handles the secure and private routing from this internal IP to the actual Google API infrastructure.

Key Characteristics & Use Cases:

• No IP Range Allocation (for Google Services): Does not require you to designate an IP range for Google's services in your VPC, avoiding potential IP conflicts.
• No VPC Peering: No direct VPC Peering to a Google Service Producer VPC.
• Granular Control: You can create endpoints for specific API bundles (e.g., `all-apis`, `vpc-sc`) or individual services.
• Per-VPC, Per-Region: Endpoints are tied to a specific VPC network and region.
• Use Cases: Any application inside your VPC needing to access Google APIs privately without a public IP or Private Google Access. Ideal for highly secure environments or avoiding internet egress costs/latency.

3.3. Private Service Connect (Consumer-side for Managed Services like Apigee X)

Similar to Google APIs, this allows your VPC to connect to specific Google-managed services (e.g., Apigee X, Dataproc Serverless) that are deployed within a Google-managed VPC.

How it Works:

1. Provision Service: You provision a managed service instance (e.g., Apigee X) which exists in a Google-managed VPC.
2. Create PSC Endpoint: You create a forwarding rule in your VPC that points to the service instance. This forwarding rule receives an internal IP address from your VPC subnet.
3. Bi-directional Communication: Traffic flows privately between an internal IP in your VPC and the internal IP of the managed service in the Google-managed VPC, all facilitated by PSC.

Key Characteristics & Use Cases:

• No IP Conflicts: Unlike PSA, PSC doesn't require an allocated IP range on your side for the service producer's IPs.
• Simpler Management: No direct VPC Peering to manage.
• Use Cases: Connecting to Apigee X, Dataproc Serverless, or other newer Google managed services that specifically leverage PSC.

3.4. Private Service Connect (Producer-side)

This allows you to expose your own services (like a custom SaaS or an internal API running on VMs behind an Internal Load Balancer in your VPC) to other consumers (other projects, other organizations) using internal IPs, without VPC Peering, VPNs, or Shared VPC.

How it Works:

1. Internal Load Balancer (ILB): Your service must be exposed via an Internal Load Balancer in your VPC.
2. Service Attachment: You create a "Service Attachment" resource in your VPC, which references your ILB. This attachment is what consumers connect to. You can control which projects/organizations can access it.
3. Consumer Endpoint: Consumers create a Private Service Connect endpoint (a forwarding rule) in their VPC that points to your service attachment. They get an internal IP in their VPC.
4. Private Flow: Traffic from the consumer's internal IP routes through Google's network to your service attachment, then to your ILB and finally to your service.

Key Characteristics & Use Cases:

• Cross-Project/Cross-Org Connectivity: Securely share services without complex network configurations.
• No IP Overlaps: The producer and consumer VPCs can have overlapping IP ranges, as they don't directly peer.
• Monetization/SaaS: Ideal for building multi-tenant SaaS solutions or securely exposing services to partners/customers.
• Controlled Access: You define who can connect to your service attachment.

4. Serverless VPC Access

4.1. What is Serverless VPC Access?

Serverless VPC Access is specifically designed to allow serverless environments (Cloud Functions, Cloud Run, App Engine standard environment) to connect to resources that have internal IP addresses within your VPC network. Without this, serverless services can only reach public internet endpoints.

4.2. How it Works

When you configure Serverless VPC Access for a region, Google deploys a small, managed set of connector VMs into a designated subnet within your specified VPC network.

1. Connector Deployment: You create a Serverless VPC Access connector in a specific region and subnet in your VPC. This connector uses a `/28` IP range from that subnet.
2. Outbound Routing: Your Cloud Functions, Cloud Run services, or App Engine standard services are configured to use this connector for VPC egress. Any outbound requests with internal IP destinations are routed through the connector.
3. Access VPC Resources: The connector acts as a proxy, forwarding traffic into your VPC, allowing your serverless services to reach resources like Compute Engine VMs, internal load balancers, or Cloud SQL instances that are configured with Private IP within your VPC.

4.3. Key Characteristics & Considerations

• Serverless Egress: Primarily for *outbound* connections from serverless services *into* your VPC. Inbound connections to serverless services remain largely public (unless using Load Balancers/IAP for Cloud Run).
• Connector Resource: The connector consumes a `/28` IP range and incurs some cost (for the underlying VMs). It is provisioned per region.
• Latency: Introducing the connector might add a small amount of latency compared to direct internal VM-to-VM communication.
• Associated Services: Cloud Functions, Cloud Run, App Engine standard environment.
• Connects to Private IPs: Allows serverless services to connect to any resource reachable via an internal IP in your VPC, including Cloud SQL instances configured with Private IP (which implicitly use PSA).

4.4. Use Cases

• Cloud Function reads/writes data to a Cloud SQL instance that only has a private IP.
• Cloud Run service calls an internal API running on a Compute Engine VM or an Internal Load Balancer within your VPC.
• App Engine standard application needs to access internal services hosted in a GKE cluster.

5. Comparison and Summary

Choosing the right connectivity method depends on the services involved and your architectural requirements.

6. Advanced Concepts & Best Practices

6.1. DNS Resolution (Cloud DNS)

• PSA/Serverless VPC Access: For services accessed via PSA (e.g., Cloud SQL private IP), you often rely on Cloud DNS. Ensure instances can resolve the FQDNs of your managed services to their internal IP addresses.
  You typically need to enable Cloud DNS private zones or DNS forwarding to resolve service producer DNS names. For Cloud SQL, the private IP is auto-registered.
• PSC (Consumer-side): When creating PSC endpoints for Google APIs, you often need to create corresponding DNS entries (e.g., `storage.googleapis.com` pointing to your PSC endpoint's internal IP) within a Cloud DNS private zone, and configure your VMs to use this private zone.

6.2. Shared VPC Integration

• All the discussed connectivity options can work effectively with Shared VPC.
  • PSA: The service networking connection is typically configured in the host project, and service instances can be created in service projects, leveraging the host project's network.
  • PSC (Consumer): Endpoints can be created in host or service project networks, allowing resources in either to access services.
  • PSC (Producer): Your services can be exported from a host or service project network.
  • Serverless VPC Access: Connectors can be deployed in a subnet of the shared VPC (in a service project or host project), allowing serverless functions in any attached service project to use it.

6.3. Firewall Rules

• For all methods, ensure that your VPC firewall rules (and potentially custom routes) allow the necessary traffic.
  • PSA: Allow traffic from your workload VMs to the PSA-allocated IP range.
  • PSC (Consumer): Allow traffic to the internal IP of the PSC endpoint.
  • PSC (Producer): Ensure your ILB and backend VMs allow traffic from the PSC service attachment (via internal IPs).
  • Serverless VPC Access: Allow traffic from the Serverless VPC Access connector's IP range to your target resources within the VPC.

6.4. Security and Least Privilege

• Always apply the principle of least privilege. Only allow necessary protocols and ports, and restrict source/destination IP ranges where possible.
• Monitor network flows (VPC Flow Logs) to understand traffic patterns and identify anomalous behavior.
• For PSC Producer, carefully manage which projects or organizations are allowed to connect to your service attachment.

6.5. Network Topography

• Consider your overall network design. PSC often simplifies cross-project/cross-organization connectivity compared to managing numerous VPC peerings.
• For egress to the internet from VMs that also need private access to managed services, generally use Cloud NAT in conjunction with Private Google Access (for public service endpoints) or Private Service Connect (for specific internal-only access).

7. GCP Exam Tips

• Key Distinctions: Be able to articulate the fundamental differences between PSA, PSC (consumer), PSC (producer), and Serverless VPC Access. Know when to use each.
• IP Allocation: Remember which solution requires you to allocate an IP range for Google's services (PSA) versus just using an internal IP from your subnet (PSC endpoint) or a connector range (Serverless VPC Access).
• VPC Peering: PSA fundamentally relies on it; PSC and Serverless VPC Access do not establish direct VPC peering with Google's service producer VPCs.
• Service Coverage: Know which common services are typically associated with each connectivity method (e.g., Cloud SQL/Memorystore=PSA; Cloud Run/Functions connecting to VPC=Serverless VPC Access; Apigee X/Google APIs=PSC).
• Direction of Flow:
  • PSA & PSC (consumer/producer): Bi-directional.
  • Serverless VPC Access: Primarily outbound from serverless services into your VPC.
• DNS: Understand the role of Cloud DNS in resolving internal IP addresses for privately accessed services.
• Shared VPC & Firewalls: Remember how these standard networking constructs interact with each private connectivity method.