Managed service egress with Private Service Connect interfaces

If your organization offers managed services to customers, or simply consumes services internally, chances are those services need to be accessed privately, over a VPC. In a Google Cloud environment, customers increasingly turn to Private Service Connect, which creates private and secure connections from your VPCs to Google, third parties, or your own services. And recently, we added PSC interfaces, which allow a service producer to access a consumer’s network by sharing a network interface, while still maintaining the separation of producer and consumer roles.  

In this blog post, we go into depth about PSC interfaces — how they fit into a PSC environment, and how to use them effectively. 

Enabling private access with PSC

Let’s say that you have a new AI SaaS running in Google Cloud, and your customers require fully private access to the service, without leaving Google Cloud. Traditionally, you would use Private Service Connect endpoints to expose that producer service to your customers running in their own VPCs. That access would happen through a PSC endpoint, a single, private IP address that belongs to their address space, and the traffic would remain entirely within Google Cloud.

This is managed service ingress: the traffic flows from the consumer clients to the producer managed service. 

But for your AI service to operate, you also need to initiate connections to the consumer to retrieve data for model training. This is because customer data often resides in various places — in the customer VPC, in a VPC peered to it, over the internet accessed by Cloud NAT from the consumer VPC, or on-prem accessed by Cloud VPN or Cloud Interconnect from the consumer VPC.

This networking pattern is called managed service egress, and exists whenever a managed service needs to initiate connections to its users. This can be for various use cases:

• Data-processing managed services need to access content in databases hosted by their consumers

• Event hubs receive and process event triggers, and initiate egress connections to send events into their consumer VPCs

Private networking challenging to achieve service egress

With PSC endpoints, traffic is only allowed on ingress — it must be initiated from the consumer. This is intentional; consumers don’t want a producer to access their VPC unless they have explicitly authorized it.

One way of achieving service egress is to set up PSC endpoints in reverse, where the service attachment and the load balancer are deployed on the consumer side. This works well at low scale, but is challenging when there are many or frequently changing destinations in the consumer VPC. It also requires more coordination between consumers and producers, which can introduce complexity and friction.

Introducing PSC interfaces

PSC interfaces are a new mode of PSC designed for private, managed service egress, that enable a producer to access a consumer’s network by sharing a network interface (called a PSC interface), while still maintaining the separation of producer and consumer roles.

PSC interfaces are implemented with a cross-organization multi-network interface VM combined with the PSC authorization model. In addition to its local network interface, a producer VM can have one or more PSC interfaces, which actually reside in the consumer VPC. A PSC interface has an IP address from a consumer subnet. (Note: Here, "interface" describes exactly what the PSC interface is on a guest operating system: an explicit networking interface with direct access to another network. It's like plugging an Ethernet cable directly across two organizations' networks to link them together.)

With this network interface as the entry point in the consumer VPC, the producer VM can access consumer resources as if they resided locally in the producer VPC. A PSC interface shows up as a regular network interface in the guest OS of the VM, so you benefit from the whole toolbox of powerful OS-level routing options.

Because a PSC interface is a network interface, transitivity is natively possible, so the producer can access external destinations using the consumer VPC as a transit. No extra configuration is required. Nor does the consumer need to deploy a load balancer and configure the destinations as its targets. All it needs to create is a network attachment. This resource provides control to the consumer over which producers are allowed to connect to it, and which subnet(s) can be used for the PSC interfaces’ IP addresses.

Here’s an example of a network attachment creation:

The output is:

From there, the producer simply creates a VM with a PSC interface that references the network attachment. For example:

Service-to-service communication

PSC interfaces are complementary to PSC endpoints and can be used together in the same VPC. For example, you can use them to enable a third-party analytics service to reach a third-party database that’s owned by a different organization, through the consumer VPC which has a connection to both.

Firewall rules are also compatible with PSC interfaces, so the consumer can use them to control what the producer is authorized to access, be it local or remote targets.

In short, PSC interfaces are a powerful new addition to Private Service Connect that address many of the common challenges of using PSC endpoints to deliver managed service egress. PSC interfaces are available in public preview today, so don’t hesitate to give them a try!