Concepts of networking: Apigee X

Apogee Network Connectivity Options: Peering vs. Private Service Connect

Key Concepts:

Apogee: Google Cloud’s native API management platform for building, managing, and securing APIs.
Private Service Connect (PSC): A networking service that allows private connectivity to services without using public IP addresses.
VPC Peering: A networking service that allows two VPC networks to connect directly.
Northbound Traffic: Traffic to Apogee (clients calling APIs managed by Apogee).
Southbound Traffic: Traffic from Apogee (Apogee calling backend APIs).
NEG (Network Endpoint Group): Represents a collection of backend endpoints for a load balancer.
Service Attachment: A PSC component that exposes a service.
Endpoint Attachment: A PSC component that allows a consumer to connect to a service attachment.
PSDNAT Subnet: A subnet used for Private Service Connect Network Address Translation.
NCC (Network Connectivity Center): A hub-and-spoke networking service for managing connectivity.
Producer Spoke: A configuration in NCC where Apogee acts as a producer of routes.

Introduction to Apogee and Connectivity Options

Apogee is Google Cloud’s API management platform, offering high-performance API proxies for building, managing, and securing APIs. It’s a fully managed service deployed within a dedicated Google-managed VPC. Connectivity to Apogee can be established using Private Service Connect (PSC), VPC Peering, or a combination of both, depending on the requirements for both northbound and southbound traffic. The choice between these options involves trade-offs related to IP address consumption, operational overhead, and cost.

Northbound Connectivity Patterns

There are two primary patterns for handling traffic to Apogee:

PSC with Application Load Balancer: This involves connecting via an Application Load Balancer (ALB) with a PSC Network Endpoint Group (NEG) linked to the Apogee-provided service attachment. The ALB can be external, internal, global, regional, or cross-regional, offering flexibility based on traffic patterns. Using an ALB allows for bringing your own SSL/TLS certificate for secure connections.
PSC Endpoint Directly: This option is limited to internal traffic only and requires utilizing the Apogee-provided self-signed certificate.

Both patterns allow for flexibility in load balancer configuration (external/internal, global/regional/cross-regional) to match specific traffic requirements.

Southbound Connectivity Patterns

Regardless of whether PSC or VPC Peering is chosen, two core southbound patterns exist:

Internet Egress via Cloud NAT: Apogee can directly access APIs on the public internet through Cloud NAT within its tenant VPC. This utilizes a known, static IP address, enabling destination firewalls to be configured if needed.
Google API Destinations via Private Google Access: When Apogee needs to call Google APIs (like Gemini or BigQuery), Private Google Access is configured within the Apogee tenant VPC, allowing direct, private communication.

PSC-Only Southbound Deployment

If utilizing PSC exclusively, API targets must be exposed as producer services. This involves:

Fronting APIs with an Internal Load Balancer (the specific type doesn’t matter, but the region must match Apogee’s deployment region).
Exposing the service via a Service Attachment with a PSDNAT subnet.
Configuring an Endpoint Attachment in Apogee to point to the Service Attachment.
The backend of the load balancer can utilize various compute options: Compute Engine VMs, serverless NEG, PSC, or even Hybrid NEG for on-prem/other cloud targets.

The video highlights that scaling this pattern can be complex, suggesting the use of an Application Load Balancer’s URL map to expose multiple API targets on a single load balancer. Alternatively, a secure web proxy can be deployed in the NCC environment to simplify routing. This proxy is exposed through a service attachment, and Apogee is configured with an endpoint attachment pointing to it. The proxy then uses DNS within its VPC to route traffic to the final API destination.

VPC Peering Southbound Deployment

When using VPC Peering, it’s crucial to configure Apogee as a “producer spoke” within the Network Connectivity Center (NCC) hub. This ensures NCC propagates all routes from the Apogee tenant VPC, enabling Apogee to route to any API target within any connected VPC – including Compute Engine VMs, services exposed by load balancers, and even on-prem/multicloud environments via interconnects or VPNs.

PSC vs. VPC Peering: Key Considerations

The video outlines three key factors when deciding between PSC and VPC Peering:

IP Consumption: VPC Peering requires /22 and /28 CIDR ranges per instance, which must be unique across the entire connected network. PSC eliminates this IP overlap complexity.
Routing Operational Overhead: PSC, when exposing each API target as a producer service, can create significant operational overhead ("toil"). VPC Peering, using direct routing, avoids this, but at the cost of higher IP consumption.
Cost: The PSC with secure web proxy model offers a balance between IP preservation and reduced operational overhead, but introduces additional costs associated with the proxy.

A previously significant factor, DNS peering support, is no longer a differentiator. Both PSC and VPC Peering now support DNS peering.

Notable Quote

“It’s up to you to determine what’s most important in your unique Apogee deployment for choosing between PSC, VPC peering, or a combination of both.” – Speaker, emphasizing the need for tailored solutions.

Conclusion

Choosing the right connectivity pattern for Apogee requires careful consideration of your specific needs. Evaluate the trade-offs between IP address consumption, operational complexity, and cost. Understand your northbound and southbound traffic patterns, and select the network components that best support your requirements. Consider the location of your target APIs – whether they reside on the internet, within Google APIs, in Google VPCs, or in on-prem/multicloud environments – to determine the most appropriate southbound network pattern.