What You Should Know About Multicloud

By Amber Rasche - Senior Communications Specialist, Internet2

Estimated reading time: 9 minutes

6 Questions for Matt Zekauskas, Internet2 Senior Engineer

Matt Zekauskas is well known in the research and education (R&E) community as a wearer of many hats – Internet2 senior engineer, research scientist, perfSONAR contributor, and this year’s chair of SCinet, the SC Conference’s volunteer-built high-capacity network. When it comes to networking, including networking for cloud, Matt’s many hats have cultivated his unique insights into technically complex but widely used approaches like multicloud, which we explore further in this Q&A.

Matt’s career at Internet2 started as a part-time assigned employee in 1998 with an initial focus on network measurement and application performance. He was part of the team who built the Abilene network in the late 1990s, providing design input and measurement planning for the high-performance network that preceded the Internet2 national network. When Abilene was gearing up for its first major capacity boost – from 2.5 Gbps to the then-massive 10 Gbps – Matt spent a month with colleagues evaluating cutting-edge routers in the heart of Silicon Valley: San Jose, California. 

In this Q&A, Matt shares his cloud networking expertise to help us dig deeper into multicloud as a cloud deployment strategy for the R&E community. He sheds light on the technical components operating behind the scenes to enable dynamic and secure cloud connectivity, discusses the benefits and challenges of a multicloud approach, and shares how Internet2 is supporting the R&E community with multicloud connectivity through its Networking for Cloud solutions.

Internet2 recently finished implementing its most comprehensive set of network upgrades in its 25-year history. With Internet2’s Next Generation Infrastructure (NGI) deployed, can you tell us more about what you’re focusing on now, specifically regarding Internet2 Cloud Connect and other Networking for Cloud solutions?

Matt Zekauskas: Enhancing the functionality of these services is a major thrust this year. So far, we have improved our Google Cloud Partner Interconnect points of presence so community members can self-provision the VLAN, or virtual LAN, attachments from any region and set the MTU, in other words, the maximum packet size that can be transmitted over the connection. We also are continuing to upgrade the interconnection capacity between Internet2 and all of the cloud providers accessible through Cloud Connect to support demand and research use cases. We added 100G ports in Ashburn and San Jose for Microsoft Azure ExpressRoute back in July 2021, and we recently added 100G ports in Ashburn for AWS Direct Connect and Google Cloud Partner Interconnect. Now we are preparing to launch Oracle FastConnect as a new Cloud Connect provider with 100G ports in Ashburn and Dallas. 

Part of our efforts to provide self-service management capabilities into the Cloud Connect portal includes integration of InCommon’s federated identity and access management, including use of the Trusted Access Platform software, into our services. This integration with Internet2 Identity Services (based on the software) includes both user authentication with the portal and also authorization for users to do self-administration of their Cloud Connect workgroups using Grouper.

We are also going through a design process to improve the available features for both Layer 2 connections and Layer 3 virtual routing and forwarding, or VRF, as well as to provide more visibility into the data and performance metrics for these services. All of these efforts are moving us toward a new implementation of Cloud Connect next year – what we’re calling Cloud Connect 2.0, which will be part of the I2 Insight Console. 

In the most basic terms, tell us about “multicloud” as a cloud deployment model. What is it and how are organizations in the R&E community using it as part of their cloud strategies?

Matt Zekauskas: “Multicloud” involves establishing a single connection, or pair of connections, to the Internet2 network that enables you to use more than one cloud service provider to perform a task or series of tasks. Some providers refer to multicloud as a model that includes a “cloud router.”

An example of multicloud could be a researcher who pre-processes data available in one cloud service provider and then ships the results to another provider to continue processing using unique resources in that environment. Another example is having authentication and authorization information hosted by one cloud provider, which is then used to access other cloud providers. A multicloud design can also enable resiliency for a single cloud provider by connecting to multiple regions of the same provider.

In support of all such use cases, Internet2’s Cloud Connect solution has had multicloud available for private, direct connections to cloud providers since the Cloud Connect portal became available in 2018. Our other Networking for Cloud solutions – Rapid Private Interconnect (RPI) and Internet2 Peer Exchange (I2PX) – support multiple clouds. RPI can be added to a Cloud Connect multicloud solution.

Currently about half of the Cloud Connect connections are set up for multicloud, with maybe one-third to one-half of those actually having established connections to more than one cloud.  Simplicity and resilience are two other reasons to make the Cloud Connect circuits multicloud-ready, even if only one cloud is being accessed today. We are investigating other features – for example, configurable route filtering and additional telemetry – as we develop Cloud Connect 2.0.

Behind the scenes, what are the technical components – network infrastructure, routing techniques, orchestration, etc. – that go into a multicloud architecture? How is Internet2’s NGI designed to deliver these technical components and meet the needs for more dynamic and secure cloud connectivity?

Matt Zekauskas: Internet2’s Cloud Connect multicloud solution creates a private routing instance, known as a VRF, on Internet2’s hardware routers. With a VRF instance, you get all the benefits of the routing hardware, including line speed forwarding and buffering, with no bandwidth restrictions and no additional software licenses needed.

With the recent deployment of Internet2’s Next Generation Infrastructure, all four Cloud Connect access points (Ashburn, Virginia; Chicago, Illinois; Dallas, Texas; and San Jose, California) now have two routers, each with independent connections to the cloud provider and also independent connections back to the Internet2 network backbone. Therefore, no one failure of a component or circuit will disrupt access to the provider. There are some nuances with respect to resilience in how a given campus may choose to configure Cloud Connect – with one or two virtual connections to a given cloud provider at one site, or at multiple sites – but ultimately what NGI has enabled is new capabilities for increased resilience.

What are some of the other major benefits of a multicloud approach?

Matt Zekauskas: Multicloud offers multiple benefits, which ultimately come down to more efficient paths, fewer restrictions, and more flexibility.

First, you can communicate from private instances in one cloud to another without having to bring traffic back to campus. For example, you can read permissions and access data in an Azure Active Directory instance from virtual machines in GCP, AWS, or Oracle. Another example might be a multicloud research workflow, with computation using specific GPUs in GCP and then rendering the results for display in Azure. 

Second, you can set up multiple cloud instances in the same or different cloud providers, while only needing to establish one or two connections to campus. This limits the number of VLANs that need to be created between a campus and the Internet2 network. 

Third, with Internet2’s Cloud Connect solution, you get all the benefits of our hardware capabilities without the bandwidth limitations of solutions that use a cloud router. Those other solutions limit the total bandwidth through the cloud router and then price that accordingly. 

Fourth, Internet2 allows access through any of our Cloud Connect locations in Ashburn, Chicago, Dallas, and San Jose for no additional fee for connections up to 5G. Other providers’ solutions have distance-based charging with capacity limits from your attachment point through to the network.

What are some of the challenges to keep in mind when considering or preparing for a multicloud approach?

Matt Zekauskas: Right-sizing connections initially can be a challenge. All of the cloud providers charge for capacity, so it is prudent to start small and grow connections as necessary. Our observation is that people typically start too large, using very little of the provisioned capacity – so testing and trials are important. 

Understanding the security requirements of your applications can be another challenge. Cloud Connect and Rapid Private Interconnect segment traffic but do not encrypt traffic. Most applications benefit from segmentation – which offers separation and prohibits general internet connectivity – and with the resulting smaller attack surface, they don’t need encryption. If encryption is required, it can be done end-to-end, which is often best anyway. 

How does Internet2 support the research and education community with multicloud and other cloud connectivity?

Matt Zekauskas: We know there’s no one way to get to the cloud, and our Networking for Cloud solutions are designed with that in mind. 

The first thing Internet2 does is provide ample public IP address peering with multiple cloud providers – over 3.34 Tbps to AWS, Azure, GCP, and Oracle – through I2PX. For many research applications, this is sufficient. The path through Internet2 is known and it should not drop packets or otherwise throttle capacity for high-performance data transfers. Other than the cloud provider’s charges for transferring data out (which can often be mitigated through data egress fee waivers, at least for transfers directly to a university over Internet2), there are no additional fees charged and no special setup is needed. 

Cloud Connect is an option for those that require private access to cloud resources. An example might be private IP access to cloud resources connecting to an instrument on campus. Multicloud through Cloud Connect offers direct private cloud-to-cloud communication as I mentioned before. Cloud Connect also offers the advantage of lower data-out charges. However, it’s important to note that cloud service providers charge for contracted Cloud Connect bandwidth too, and – as with public peering – campuses may be able to take advantage of data egress fee waivers, so the total cost calculation is complex.

Internet2 allows Cloud Connect circuits to be provisioned dynamically and programmatically, currently through the Cloud Connect portal, with additional capabilities planned for the new I2 Insight Console supporting Cloud Connect 2.0. With sufficient planning, connections – including multicloud configurations – can be turned up or down in minutes.

We also strive to get ample headroom on the Cloud Connect circuits so that higher data transfer rates can be supported on demand. We are working toward 100G physical connections to all providers but have been limited to multiple 10G physical connections at most locations due to provider availability. We do have 100G physical connections to all providers at our Ashburn location.

Today, the Cloud Connect connections have a 5 Gbps limit, with most cloud providers not allowing a connection greater than 10 Gbps. For those who need additional bandwidth, 10 Gbps connections are available on Cloud Connect for a modest fee, and 10 and 100 Gbps low-cost options are also available through RPI.

Learn More About Networking for Cloud

Learn more about Internet2’s Networking for Cloud solutions on our website, including Internet2 Peer Exchange, Cloud Connect, and Rapid Private Interconnect. If you have questions or want further details, email cloudconnect_request@internet2.edu.

ICYMI

• Internet2 Next Generation Infrastructure Operational, Transition to Fully-Automated, 400G National Infrastructure Complete