Problem
We need to use Google Cloud to share a VPC (Virtual Private Cloud) for multiple projects and want to see how we can connect to GCP from on-premises. In a previous article, we saw some network security best practices, so let’s continue to learn more about network architecture in GCP and how we can share a VPC and securely connect to GCP.
Solution
Read along to learn how to connect to GCP from on-premises, interconnect networks and share VPCs.
Sharing networks in GCP
As we know, inside GCP, an organization can contain many projects, and inside each project we create VPCs.
Shared VPC
A Shared VPC is helpful if we want to share a network with multiple projects inside an organization. We need to choose a host project and share it with other projects called service projects. This configuration allows resources from different projects to communicate using their internal IP and has the benefit of setting up network security and policies in a single centralized VPC.
See below a representation of a VPC Sharing solution.
source: https://cloud.google.com/static/vpc/images/shared-vpc/shared-vpc-example-concepts.png
VPC Peering
VPC Peering on the other hand is a good option if we have to enable communication between networks that reside in the same or other organizations. There are couple of things to consider like the fact that subnet ranges cannot overlap, each VPC needs to consider their own firewall rules to allow the traffic and a peering request needs to be sent from each of the network to the one it peers with. After the peering connections are established, traffic can flow using the internal IP addresses from each network.
VPC Peering can be seen as a decentralized configuration where each network has its own separate administration, own security rules and policies and removes the need of a VPN or external IPs by using internal IP addresses and lower latency.
Connecting to GCP network
Now let’s see how we can connect to GCP’s network from on-premises and choose the best solution for our needs.
Cloud VPN
If we want to connect a VPC network with on-premises or even with another cloud provider network, we can choose Cloud VPN. It connects two networks using an encrypted IPsec VPN tunnel, it’s especially used for low-volume connections usually up to 3Gbps and you can choose from two types, Classic VPN and HA VPN (High Availability VPN).
Be aware that Google deprecated dynamic routing using BGP (Border Gateway Protocol) from the Classic VPN. See this article on the supported configurations and the recommended actions to take.
Classic VPN
It has 99.9% SLA, has one external IP address and you can configure it to use static or dynamic routing, site-to-site VPN, it supports IKEv1 and IKEv2 ciphers but keep in mind that IPv6 traffic is not supported.
HA VPN
It has 99.99% availability, supports IPv4 and IPv6, it uses 2 external IP addresses, one for each gateway interface and each gateway interface supports multiple tunnels.
You can read more about Cloud VPN at this link.
Cloud Router
As mentioned above, Cloud VPN can use static and dynamic routes. If dynamic routes are used, Cloud Router needs to be configured. It uses BGP to update and exchange routes with no changes to the tunnel. Of course, for this to work, the on-premises VPN gateway has to support BGP.
Let’s imagine an example for this configuration. Say we have a VPC inside GCP, and one network on-premises. The two networks are connected using Cloud VPN. Let’s assume that the current configuration consists only of Test and Prod subnets inside the VPC network, and on-premises has 29 subnets. Cloud VPN is configured and running. Say you need to add one new subnet in GCP (Staging), and another one on-premises. Cloud Router automatically advertises the new subnets between the two networks so that resources from the newly added subnets can exchange traffic right away.
Cloud Interconnect
This solution has 3 ways to connect to GCP: Dedicated Interconnect, Partner Interconnect, and Cross-Cloud Interconnect. This offers dedicated high speed and bandwidth between GCP and on-premises. Let’s see what the differences between them are.
Dedicated Interconnect
It’s a Layer 2 connection solution that offers a dedicated physical connection to Google’s colocation facility where traffic flows between networks without touching the public internet. It offers bandwidth between 10 and 200Gbps, has 99.9% or 99.99% availability depending on the configuration type. You have to provide your routing hardware in a colocation facility and set up a BGP session between a Cloud Router and the on-premises router. See below an example of such architecture.
You can find out more about Dedicated Interconnect here, and an updated list with colocation facilities here.
source: https://cloud.google.com/static/network-connectivity/docs/interconnect/images/single-interconnect.svg
Partner Interconnect
With Partner Interconnect we can connect between the on-premises network and GCP using a service provider. This option comes in handy if we cannot reach a Dedicated Interconnect facility. You can choose from a list of providers found at this link. Each service provider has a dedicated connection to GCP’s network that you can use, and after you are connected with a service provider you can setup Partner Interconnect and choose between a Layer 2 or Layer 3 connection.
In a Layer 2 configuration, traffic goes through the service provider’s network, and you have to set up BGP sessions between the on-premises router and the Cloud Router. See the picture below.
source: https://cloud.google.com/static/network-connectivity/docs/interconnect/images/layer2-basic.svg
In a Layer 3 configuration, traffic is sent to the provider’s network and routed from there to the correct destination (VPC or on-premises). The BGP sessions are created by the provider and configured between the Cloud Router and the router from the partner’s network. There’s no need to configure BGP on routers from your local network. See the diagram below.
source: https://cloud.google.com/static/network-connectivity/docs/interconnect/images/layer3-basic.svg
Partner Interconnect has two options for availability: 99.9% and 99.99% and it covers only the connection between the service provider and your VPC. Connection between your on-premises and the service provider is not covered by this SLA. A detailed resource about SLA types and configuration overview you can find here.
Direct Peering
Using Direct Peering we can create a peering connection from our on-premises network and Google’s edge network. One of the differences from the Interconnect option above is that Peering uses public IPs. You can access GCP’s products including ones that are using public IPs unlike Interconnect options where access is made using internal IPs. Peering is made outside of GCP, you can access APIs for GCP products and also Google Workspace, but you cannot directly access VPC resources that only have an internal IP. It’s a good choice if you want access to Google Workspace, otherwise use Interconnect options.
Here's a resource for edge locations for peering. Also keep in mind that Direct Peering and Carrier Peering that we will cover next, don’t have an SLA.
Carrier Peering
Similar to Direct Peering, but instead of Google’s edge points, it uses a partner’s network. Here’s a list with supported carrier peering providers.
Here You can find a comparison between Cloud Interconnect and Peering options.
To sum up the peering and interconnect options, we can split them by layer and dedicated/shared as shown in below table.
Cross-Cloud Interconnect
As the name implies, this is a dedicated physical connection between GCP and other cloud providers. At this moment, it supports a bandwidth of 10 or 100 Gbps, the currently supported cloud provided are listed here, the available locations for a cross-cloud connection from GCP side are listed here, and the supported SLA is 99.9% or 99.99%.
Cross-Cloud setup process is detailed here where you can learn how to connect to other cloud providers.
Next Steps
- We saw how to link VPCs with multiple projects in Google Cloud, how to connect from on-premises to GCP depending on our requirements, SLA and factors to consider for each setup option. Don’t forget to check the pricing for the setup you choose. A good resource for pricing info is here.
