Addressing a long-standing perceived roadblock in enabling systems to span multiple cloud services, Amazon Web Services and Google Cloud have jointly developed a standard for customers to easily bridge their cloud deployments with Layer 3 connectivity.

The idea, according to both companies, is to make it easy for their customers with cloud operations in both clouds to network them together in a private network, reducing the burden of maintaining multicloud connectivity, and perhaps even dispelling fears of cloud lock-in.

Such easy connectivity may even spur customers to create more multicloud applications, thetwo companies pine in the press material.

The open source Connection Coordinator API specification is built on OpenAPI 3.0 customized for easily provisioning dedicated bandwidth between two cloud providers. The two cloud giants want other cloud providers to use the API as well.

AWS implemented the spec in AWS Interconnect – multicloud service, currently in preview. Google Cloud did likewise with Google Cloud’s Cross-Cloud Interconnect. Both companies pledge to “engage in continuous monitoring to proactively detect and resolve issues,” according to the AWS website.

The private lines between Google and AWS will be built on MACsec encryption.

The Problem With Multicloud

To date, customers building systems that span multiple clouds, or want them to run on multiple clouds, had a number of options, each somewhat painful in its own way.

They could connect over public internet to connect between clouds, which offers wildly unpredictable performance in terms of meeting actualservice level agreements (SLAs) of any sort.

Or they could provision private lines joining the clouds, which is not cheap, and often come with long wait times to provision the circuits themselves.

Or they could build out the private lines themselves, which would require considerable network engineering talent.

The Connectivity Services Promise Ease

AWS bills its service as fully managed, and offers an interface through the AWS Management Console, command line interface, or the API.

To provision a private network, the users must (in AWS’ words):

• Specify the target cloud service providers,
• Select the destination region on the other side,
• Pick the required bandwidth.

Source: Google

What Multicloud Could Enable

According to Google, this service’s simplicity is revolutionary, in that its ease of use will encourage more users to think in terms of what could be done across multiple clouds.

In a blog post, two Google engineers offered a number of ways an organization could leverage multicloud connectivity.

One obvious use is disaster recovery. An application can run on both services, with agentic AI applications or database replicas able to quickly synchronize state. So if one cloud service goes down, the other can quickly step in.

Or, a user could build a service on AWS that calls a service running on Google Cloud, such as a critical data warehouse hosted in BigQuery.

This could work in the other direction as well. Google Cloud analytics app can pull large datasets from an AWS S3 or an RDS instance.

In each of these cases, the multicloud application would benefit from the improved performance, the engineers write. And not routing this traffic over the public Internet would also be a security benefit.

Other Ways to Connect

Microsoft Azure was not part of this week’s announcement, though it already offers Azure ExpressRoute and Azure Virtual WAN as ways to connect Azure with other cloud providers or on-prem facilities.

Other third-party cloud exchange services that could get the job done (via their own data centers) include Equinix Cloud Exchange, CoreSite Open Cloud Exchange, and Digital Realty’s Interconnection Fabric.

AWS announced its portion of the news for the kickoff of its annual AWS Re:Invent conference, which is being held this week in Las Vegas.

TRENDING STORIES