One of the most important things to consider when creating a Landing Zone is how connectivity can be implemented. It is easy to figure out that various options are possible and as cloud technologies including networking are evolving, a Landing Zone that was created in the past might need to be modernized since new technologies and services exist now. The same applies for the future: A Landing Zone can only be built with the available technologies from today, and if there is something new on the market, you might consider changing or modernizing some parts of your landing zone and that – of course – includes connectivity and networking as well.
Most companies tend to implement a hybrid cloud model where some workload remains on-premises. In that case connectivity between the cloud and on-premises must be established.
Connectivity options
So, let’s shortly introduce the different options:
First, there is Google Cloud Interconnect, that provides a high-speed, highly available connection directly to Google’s network. There are two main types:
- Dedicated Interconnect: This provides physical connections between your on-premises network and Google’s network. This is suitable for high-volume, business-critical workloads that require high throughput and low latency. With Google you could have 10 Gbps circuits and 100 Gbps circuits.
- Partner Interconnect: If you want to start smaller, but still want to have an Interconnect, then Partner Interconnect might be right solution. It allows you to connect to Google through a supported service provider. This is a more flexible and cost-effective option if you don’t need the full scale of a dedicated connection.
On the other side, there is Cloud VPN: If you’re looking for a less expensive option than Interconnect and can tolerate the generally higher latency of internet-based connections, Google Cloud VPN is a good choice. It securely connects your on-premises network to your VPC (virtual private cloud) in GCP over the public internet using IPsec VPN tunnels.
If you start your cloud journey, you might consider starting with a VPN and changing later to an Interconnect.
What about MACsec?
MACsec (Media Access Control Security) is a security technology that provides secure communication for Ethernet traffic. It is designed to protect data as it travels on the point-to-point Ethernet links between supported devices or between a supported device and a host. In the context of Google Cloud and hybrid cloud setups, MACsec can be used with Dedicated Interconnect and Partner Interconnect.
Like VPN, MACsec encrypts traffic and hence it is recommended for customers to use in combination with an Interconnect, as the former does not encrypt traffic.
The following figure shows an architectural diagram for MACsec with a Dedicated Interconnect:
In the picture, a VLAN attachment for Cloud Interconnect will be configured at the Cloud Router. Behind the scenes, Cloud Router uses Border Gateway Protocol (BGP) to exchange routes between your Virtual Private Cloud (VPC) network and your on-premises network.
Since shortly, MACsec can be also used for Partner Interconnect. The following picture depicts the architecture:
Connectivity and Beyond
After having described, how to establish connectivity between on-premises between on-premises and the Google Cloud with a Cloud Router, we have discuss how to come up with a design for the workload. As always, the design depends on your requirements, but basically two “flavors” are quite popular:
- If you work, with (Partner/Dedicated) Interconnect and are using few Shared VPCs – for example for different stages like Test, Int or Prod – a feasible option is to create dedicated MACsec connections with having a Cloud Router and a VLAN attachment in every Shared VPC. In that case, the different Shared VPCs are isolated from each other. If you need connection between the different VPCs, you still can setup a VPN between the VPCs or use Private Service Connect to publish services to other VPCs. However, keep in mind that you are limited in the number of VLAN attachment (often between 10 and 15), so you better use Shared VPCs.
- Another way would be to setup a Transit VPC with a MACsec connection and hence use VPNs to connect to other VPCs or Shared VPCs. This approach scales better as you can have much more VPN connections as VLAN attachments.
While we have been discussing MACsec, basically the same considerations apply when using VPN between on-premises and the Google Cloud.
In addition, while there is also the possibility to create a peering between VPCs, please consider its limitations. There is a hard limit on creating peerings and in addition there is no transitive routing between three or more different VPCs.
Another possibility would be to use a Third-Vendor appliance for the connectivity. If you prefer such a solution, that might be possible, but you should check if there is integration between the appliance and the Google Cloud Router – otherwise BGP routes cannot be exchanged.
What about Google Network Connectivity Center?
It is quite important to know that there is also a service called Network Connectivity Center. It is designed to act as a single place to manage global connectivity, providing elastic connectivity across Google Cloud, multicloud, and hybrid networks and giving deep visibility into Google Cloud and tight integration with third-party solutions.
For those of you who have experience with Microsoft Azure Virtual WAN, or AWS Transit Gateway it is interesting to learn that Google Network Connectivity Center basically is designed to work somehow similar. However, at the current time, not all features for the Network Connectivity Center are right now available, so we do not recommend it right now and wait most likely until 2025.
