How Google’s New Cross-Cloud Interconnect Fits Into the Multicloud Picture for Research and Education

Last month, Google announced a new service called Google Cross-Cloud Interconnect. This announcement caught my attention as a network geek. Connecting some networks – or rather whole clouds – with big pipes? Yes, please! So naturally, when a colleague asked me to break down the new service and how it fits into the multicloud picture for research and education (R&E), I jumped at the opportunity.

Google Cross-Cloud Interconnect is intended to help enterprises continue to adopt multicloud and establish dedicated high-speed connections at 10 Gbps or 100 Gbps to other Cloud Service Providers (CSPs). Essentially this service enables an enterprise using multiple CSPs to use Google Cloud as a hub with spokes to other cloud providers.

How does this fit into the multicloud picture?

A common network architecture used by cloud customers building into the cloud is to interconnect their data center to the cloud. As their cloud usage increases, they often look to colocate their enterprise resources closer to the cloud provider. Over time, and for a variety of reasons, many organizations end up operating in multiple CSPs.

In the industry space, the largest companies are in multiple cloud regions across the globe. They often interconnect clouds together by routing traffic through their data center or building VPN connections between clouds. VPN connections are a proven technology but are not optimal for high-bandwidth or highly resilient connections.

This leads to why Google is building the Cross-Cloud Interconnect service. Google’s largest cloud customers operate in multiple CSPs at a global scale. Some of the benefits of Cross-Cloud Interconnect include:

• Private connectivity across clouds
• Reliable and highly performant
• Lower total cost of ownership, with less infrastructure to manage

Wait, not so fast! What is this going to cost?

Google does a good job providing a pricing example for Cross-Cloud Interconnect. However, the example only provides the costs for the Google Cloud side of the connection. You still need to consider the costs for the other cloud provider. To build on the Google example, I’ll use the Microsoft Azure pricing calculator to estimate the costs on the Azure side of the example circuits.

But first a disclaimer: The pricing provided in this example uses publicly available pricing tools from Google and Microsoft and does not take into consideration any promotions or specific agreements an entity may have with these cloud providers. These costs should be used as examples only and may not reflect the actual costs you might incur.

The Google pricing example uses what Google calls the “minimum requirement” for the service. That is, minimally, two 10 Gbps connections: a primary and a redundant connection at a single location and using different availability domains. In other words, these two 10G connections will be at a common colocation facility where both cloud providers have network presence and make sure the connections use different physical equipment. Thus, in the event of a hardware failure or system maintenance, both connections won’t go down at the same time. Google claims this is equivalent to three-nines availability.

Google Cross-Cloud Interconnect

Azure ExpressRoute

The total monthly expense using the minimum requirement for the service between Google Cloud and Microsoft Azure, in a single region with 200 TB of egress data from each cloud, would cost $24K per month.

For the sake of argument, even if you passed zero traffic over the circuit, the minimum required connectivity would cost roughly $8,200 for Google Cross-Cloud Interconnect plus $6,800 for Azure ExpressRoute. Bringing the minimum expense for base connectivity in this example to about $15K monthly.

To get more resiliency, you would need to build similar connectivity in a second region. If you are a large enough cloud customer to consider this service, you likely are already leveraging multiple regions to provide service resiliency. I’ll let you take this example and derive the costs for the extra resiliency and any additional providers you’d want to connect to the Google Cloud network hub.

Phew! What other options do I have?

For R&E institutions, there are a few other options to consider:

1. Keep doing the VPN thing and build IPsec tunnels to interconnect campus to cloud and cloud to cloud together. This mostly works well until you desire a more performant circuit, need to handle larger data transfers, or require more reliable and deterministic circuits.
   
2. Place your routing equipment in a colocation facility near the cloud on-ramps. The build-your-own approach comes with a multitude of considerations including procurement/contracting, expenses, logistics, remote support model, and so on.
   
3. Use a commercial Network as a Service (NaaS) provider such as Equinix or Megaport. These providers still require you to get a connection to one of their data centers. Expect to either procure some MPLS circuits for transit or minimally colocate in one of their facilities and get cross-connects to their network.
   
4. Leverage Internet2 Cloud Connect (I2CC) and Cloud Routing. I saved my favorite for last: Internet2 Cloud Connect with Cloud Routing. This is available today and can be used as a building block in your cloud architecture. Keep reading to find out how!

Why Internet2 Cloud Connect?

Internet2 operates a multi-region cloud on-ramp service known as Internet2 Cloud Connect (I2CC). Leveraging Internet2’s network, the Internet2 community can build dedicated, private Layer 2 or Layer 3 connections across the state and regional R&E networks and the Internet2 national backbone right into the CSPs. I2CC is essentially Internet2’s version of commercial NaaS solutions that provide cloud connectivity and multicloud local routing between CSPs.