How Google’s New Cross-Cloud Interconnect Fits Into the Multicloud Picture for Research and Education
By Scott Taylor - Network Architect, Internet2
Estimated reading time: 7 minutes
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.
In this example, Google assumes a lot of data – 200 TB – egress across the Cross-Cloud Interconnect circuits. As we model the Azure side of the circuit, we’ll use the same 200 TB data egress headed back toward Google Cloud. Below are screen captures from the pricing tools from Google Cloud and Azure showing the detailed cost of each side of the connection.
Google Cross-Cloud Interconnect
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:
- 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.
- 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.
- 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.
- 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.
Many organizations in the Internet2 community use I2CC and the Layer 3 routing service to connect to cloud providers already. Some have figured out that they can peer all the cloud providers in a region to the same I2 Cloud Router and build a hub and spoke configuration similar to the Google Cross-Cloud Interconnect model.
Key reasons to consider I2CC include:
- Connect to Amazon Web Services, Google Cloud, Microsoft Azure, and/or Oracle Cloud Infrastructure.
- Keep inter-cloud traffic local to a cloud region rather than hair-pinning traffic between clouds through campus.
- Transport from campus, across the state and regional R&E networks and the Internet2 backbone, to a cloud region without any additional cost.
- Flexible bandwidth options mean there’s no need to commit to a full 10G or 100G connection.
- Multiple cloud regions are supported.
- Pair with Internet2 Rapid Private Interconnect (I2RPI) service as an option to connect other service providers to your cloud network.
What are you waiting for? Now’s the time to roll up your sleeves and get building your cloud network with Internet2!
While I still think the Google Cross-Cloud Interconnect announcement is a significant milestone for multicloud, I am equally excited about the value and capabilities that Internet2 provides its community with no extra expense. I hope this blog has helped shed some light on the many options available to help your institution get to the cloud. If you have questions or want more information about Internet2’s Networking for Cloud services, email firstname.lastname@example.org.