Connect to services on another VPC via Private Service Connect

In today's blog, we're looking at a tricky problem in Google Cloud Platform (GCP): linking services on different Virtual Private Cloud (VPC) networks. Usually, organisations struggle with two main issues. Either they have to plan their IP setups in advance, which hardly anyone does, or teams can't link their services because they're using private VPCs. Deciding whether to use a Shared VPC or private VPC is tough, especially when you're not sure if you'll need more connections in the future or if more people will need access to a service.

This is where Private Service Connect (PSC) comes in. I've tried it out and think it's a great way to solve these problems with a smart approach. In today's video, I'm going to talk about the usual troubles with VPC networking and show you how PSC can really help.

The problem with cross VPC connectivity

Let's consider the following typical network setup, which I've seen happening across 4 medium ~ large organisations in the past few years

• Team A owns a GCP project, it contains a private VPC and a Shared VPC.
• Team B owns another GCP project, it contains a Shared VPC as well as a private VPC.

In this network configuration, the two Shared VPCs are typically set up to allow routing, as their network CIDR ranges' IP spaces are pre-planned to avoid any IP clashes. However, this is not the case with private VPCs. By design, private VPCs are not meant to be interconnected or even aware of each other's presence.

This means, even if we, on a later date, try to peer a private VPC with a Shared VPC, it could be physically impossible due to IP conflicts

Or what I see some organisations try to do is to migrate all of their services from the private VPC to a Shared VPC

While feasible, transferring all live services from one network to another often involves a considerable amount of work, typically resulting in chaos and is generally not recommended. Unless there are no alternatives, it's unwise to allocate the valuable time of engineers to such a task.

Private Service Connect

Private Service Connect (PSC) is a capability of Google Cloud networking that allows consumers to access managed services privately from inside their VPC network. Similarly, it allows managed service producers to host these services in their own separate VPC networks and offer a private connection to their consumers.

There are three ways PSC can be utilised

• Endpoint - these are internal IP addresses in a consumer VPC network that can be directly accessed by clients in that network
• Backend - let Google Cloud load balancers send traffic through Private Service Connect to reach published services or Google APIs
• Interface - it's like a Endpoint, but with two key differences
  • A Private Service Connect interface lets a producer network initiate connections to a consumer network (managed service egress), while an endpoint lets a consumer network initiate connections to a producer network (managed service ingress).
  • A Private Service Connect interface connection is transitive. This means that a producer network can communicate with other networks that are connected to the consumer network.

Private Service Connect Endpoint Interface is still in Preview at the time this blog post is written

In this blog post, the focus will be Endpoint only, which in my opinion is the easiest and most straight forward option to solve our problem at hand, to connect to a service from an unplanned VPC network.

Use PSC to connect to services on another VPC

Now, instead of faffing around with planning on IP spaces upfront or trying to decide which type of VPC network to use, the network setup becomes a lot easier

The way it works is very straight forward

1. Team B wants to public their service for Team A, or other teams on Google Cloud to gain access.
2. Team B public their service by creating a service attachment and make it accessible to one or multiple GCP projects
3. In this scenario, Team A can then self service creating their PSC Endpoint, by connecting it to the published service attachment.
4. Now, an IP address is created on a subnet within Team A's private VPC and the service is now routable.

You can see this involves no IP planning across VPC networks what so ever, hence making it incredibly easy to make network routing possible between any VPC networks.

The best aspect is the self-service capability for creating PSC endpoints. In an organisation where VPC Service Controls (VPC SC) are active, it's typically considered secure enough to allow all projects to gain access to the service attachment. This means once Team A sets up their service attachment, no further action is required. Regardless of the number of teams needing access to the service, they can independently create their own PSC Endpoint. However, it's important to note that this is just at the network level. Most services still maintain an IAM authentication layer, adding an extra layer of security to ensure that services are accessible only to authorised consumers, not to everyone.

The future design of microservices networking using PSC

I think there are opportunities to take this to the next level by orchestrating network routing in a entirely new way via Private Service Connect. So consider the following setup

In this example, we have Team B and Team B both published their services by creating a service attachment where Team A is the consumer for both services.

I believe this presents some amazing opportunities for connecting services on Google Cloud, regardless of their location or ownership. Crucially, it avoids confusion about the origin of services. The service attachment acts as a "publisher", while the "endpoint" functions as a subscriber. Being "resources" on Google Cloud, it's straightforward to export data and create a visual graph to identify the publishers and subscribers. This can be incredibly beneficial in a large organisation.

Finally, consider these pros & cons or watch the summary on YouTube.

• PSC overcomes the limitations & security concerns of VPC peering
• PSC makes changing networking design extremely easy
• In the PSC world, all teams are decentralised yet connected

• Extra steps required if it’s cross region
• Don’t make these changes overnight, test it out and make sure necessary controls are in place