This document helps cloud architects and operations professionals decide how toconnect Google Cloud with other cloud service providers (CSP)such as Amazon Web Services (AWS) and Microsoft Azure. In a multicloud design,connections between CSPs allow data transfers between your virtual networks.This document also provides information on how to implement the option that youchoose.

Many organizations operate on multiple cloud platforms, either as a temporarymeasure during a migration or because the organization has a long-termmulticloud strategy.

For data exchange between Google Cloud and other CSPs, there are multipleoptions discussed in this document:

• Transfer of data through public IP addresses over the internet.
• Using a managed VPN service between Google Cloud and the other CSP.
• Using Partner Interconnect on Google Cloud to connect to a partner that can directly connect with the other CSP.
• Using Dedicated Interconnect on Google Cloud to transfer data to the other CSP through a common point of presence (PoP).
• Using Cross-Cloud Interconnect on Google Cloud for a managed connection to another CSP.

These options differ in terms of transfer speed, latency, reliability, servicelevel agreements (SLAs), complexity, and costs. This document describes eachoption and its advantages and disadvantages in detail and ends with a comparisonof all of the options.

This document covers data transfers between virtual machines residing inGoogle Cloud and other CSP's virtual networks. For data stored in otherGoogle Cloud products such asCloud Storage andBigQuery,seethe section covering these products.

This document can act as a guide to evaluate the options to transfer databetween Google Cloud and one or more other CSPs, based on your requirementsand capabilities.

The concepts in this document apply in multiple cases:

• When you are planning to transfer large amounts of data for a shortperiod of time, for example, for a data migration project.
• If you run continuous data transfers between multiple cloud providers,for example, because your compute workloads run on another CSP while yourbig data workloads use Google Cloud.

Initial considerations

Before you choose how to connect your cloud environments,it's important that you look at whichregions you choose in each environment andthat you have a strategy for transferring data that doesn't reside in virtualnetwork environments.

Choose cloud regions

If both Google Cloud and other CSP's resources are in regions that aregeographically close to each other, there is a cost and latency advantage fordata transfers between cloud providers.

The following diagram illustrates the flow of data between Google Cloudand other CSPs.

Regardless of the method of transfer, data flows from Google Cloud to theother CSP as follows:

• From the Google Cloud region where resources are hosted toGoogle's edge PoP.
• Through a third-party facility between Google Cloud and the other CSP.
• From the other CSP's edge PoP to the region where resources are locatedinside the other CSP's network.

Data that flows from the other CSP to Google Cloud travels the same path, butin the opposite direction.

The end-to-end path determines the latency of the data transfer. For somesolutions, the network costs also increase when the edge PoPs of both providersaren't in one metropolitan area. Details are listed in the following pricingsection of each solution.

Make sure you choose suitable regions in each cloud that can host your intendedworkloads. Visit theLocations page for Google Cloud and similar pages for other CSPs, such as theAWS region table orAzure products by region.For general help in selecting one or multiple locations in Google Cloud,reviewBest practices for Compute Engine region selection.

Transfer of data in Cloud Storage and BigQuery

Only data that resides inside a Google Cloud VPC environment passes aCloud VPN tunnel or aCloud Interconnect connection by default.

If you want to transfer data to and fromother Google services,you can usePrivate Service ConnectandPrivate Google Access for on-premises hosts from the other CSP's environment.

If you want to transfer another CSP's object storage, database, data warehouse,or other products, check their documentation to see if data can pass throughtheir interconnect or managed VPN product. Otherwise, you might be able to passthis data throughproxyvirtual machines that you set up in the respective CSP's environment to make it pass through theconnection you want.

For transferring data to Cloud Storage or BigQuery, youcan also useStorage transfer service orBigQuery transfer service.

Transfer through external IP addresses over the internet

The easiest way to transfer data between Google Cloud and another CSP isto use the internet and transfer the data by using external IP addresses.

The following diagram illustrates the elements for this solution.

Between Google's network edge and the other CSP's network edge, data passesthrough the internet or uses a direct peering between Google Cloud and theother CSP. Data can only pass between resources that have public IP addressesassigned.

How Google connects to other networks

Google's edge PoPs are where Google's networkconnects to other networks that collectively form the internet. Google ispresent innumerous locationsaround the world.

On the internet, every network is assigned anautonomous system number(ASN)that encompasses the network's internal network infrastructure and routes.Google's primary ASN is 15169.

There are two primary ways a network can send or receive traffic to orfrom Google:

• Buy internet service from an internet service provider (ISP) that alreadyhas connectivity to Google (AS15169). This option is generally referred to asIP transit and is similar to what consumers and businesses purchase fromaccess providers at their homes and businesses.
• Connect directly to Google (AS15169). This option, calledpeering, lets anetwork directly send and receive traffic to Google (AS15169) without using athird-party network. At scale, peering is generally preferred over transitbecause network operators have more control over how and where traffic isexchanged, allowing for optimization of performance and cost. Peering is avoluntary system; when choosing to peer, network operators decide jointly whichfacilities to connect in, how much bandwidth to provision, how to splitinfrastructure costs, and any other details required to set up the connections.AS15169 has an open peering policy, which means as long as a network meets thetechnical requirements, Googlewill peer with them.

Peering is a private, mutually beneficial agreement between two independentnetworks, and as such, networks generally don't disclose publicly who they peerwith at particular locations, how much bandwidth is available, etc. But due toscale and an open policy, Google is directly peered with almost all major ISPsand cloud services providers in multiple locations and across regions. TheGoogle network team works directly with their counterparts at these networks toprovide sufficient peering capacity to meet demand.

You can read more about how internet peering works atThe Internet Peering Playbook.

Implementation

In this setup, all virtual machines that transfer data betweenGoogle Cloud and other cloud service providers must have a public IPaddress. On one end, the firewall must be opened to allow a connection from thepublic IP address of the other cloud provider. No extra steps are necessarybecause the data exchange happens over the existing internet connectivity.

Transfer speed and latency

While there is no guaranteed speed and latency on the path through theinternet, typically, major CSPs and Google exchange data directly in multiplelocations around the world. Capacity is shared with other customers andservices, but, often due to the direct connection between both providers,latency is similar or lower than other options.

We recommend that you test the latency and bandwidth between Google Cloudand the other CSPs in your chosen regions. You can do a quick benchmark by usingtools such asiperf ornetperf,or run a more complete custom benchmark based on your app. While conditionsmight change over time, the benchmark can provide an indication of theperformance you can expect and if this solution fulfills your needs. If yourequire a dedicated bandwidth between both environments, you should chooseanother solution.

Note that products from different vendors may have performance characteristicsthat might not always align. For example, per-tunnel IPsec VPN capacity might varyfrom vendor to vendor.

Security

Traffic over the internet isn't encrypted and might pass through third-partyinternet service providers (ISPs), autonomous systems, and facilities.Therefore, you should encrypt sensitive traffic at the application layer orchoose another solution.

Reliability and SLA

Google Cloud generally has multiple diverse paths for internetconnectivity from regions, and there are direct peering connections with othermajor CSPs at multiple locations around the globe.

However, Google Cloud doesn't provide any SLAs for connectivity to otherCSPs over the internet. While you should check SLAs for your other CSPs, theytypically only refer to internet connectivity as a whole and not specificproviders.

Providers may have different routing policies which can impact availability.For example, on itspeeringdb page,Amazon explains that many AWS regions announce only local routes, because AWSVPCs are regional only (Google Cloud VPCs are global.) This means customers may berelying on links at a single peering location, as traffic leaving Google Cloud can onlyuse those links to reach the destination. This is fine under normal operationwith traffic being exchanged in-region, but it is advisable for customers toarchitect for multi-region deployments to tolerate regional failures. This couldinclude setting up additional gateways and tunnels, virtual network peering, orother multi-region topologies in the third-party cloud.

Applications should also be built in such a way that they 'fail open' asGoogle SRE recommends inthe SRE book.For example, if you build an application that relies on being able to reach athird-party service using Internet routing, make sure that the application stillfunctions, or at least returns helpful error messages to the user in the eventof connectivity issues.

When issues with Internet routing do occur, the Google network team will attemptto restore connectivity with the third-party. However, not all issues will beunder Google's control. So in some cases, repair might depend on a third party (ISPor cloud provider) taking restorative action. Customers have the mostinfluence over how operators respond to outages, so make sure you have supportcoverage with all providers and a plan to escalate issues should something gowrong. Also perform periodic BCP (business continuity process) drills to ensurethe resilience of applications architected on multicloud.

Pricing

For data transfers over the internet, normalinternet egress rates apply for traffic leaving Google Cloud. In cases where latency isn'tcritical, using theStandard Network Service Tier provides alower pricing tier.

The other CSPs have their own charges for data transfers. In many cases, theyonly charge for traffic egressing their network. Consult your CSP's price listfor example for AWS, seeEC2 data transfer charges and for Azure, seeBandwidth Pricing Details.

Managed VPN between cloud providers

You can use managed VPN services from both cloud providers, which has twobenefits. It provides an encrypted channel between virtual networks in bothcloud environments, and it lets you transfer data by using private IP addresses.This is an extension to the previous solution oftransferring over the internet without requiring any hardware or partners.

The following diagram illustrates the elements for this solution.

Using this solution, data is encrypted on Google Cloud usingCloud VPN and a VPN solution for the other CSP. The data transferbetween Google Cloud and the other CSP uses the internet like in theprevious solution.

Implementation

Google offersHA VPN as a managed VPN service for encryptedIPsec tunnels, which can be used on the Google end. Other CSPs offer their own managedVPN products, which you can use to build IPsec VPN tunnels between bothenvironments. For example, AWS offersAWS Site-to-Site VPN and Azure offersAzure VPN gateway.You can connect your virtual networks between the environments by using VPN tunnels.

You can connect to another CSP by using HA VPN by itself or youcan set up HA VPN as aNetwork Connectivity Centerhybrid spoke. Network Connectivity Center lets you connect on-premises locations, VPC networks,and other clouds using centralized management.

HA VPN doesn't have built-innetwork address translation (NAT) functionality. However, you can enableHybrid NAT on the connection.

WithCloud Router inglobal dynamic routing mode, you can reach allregions in a global VPC network by using only VPN tunnels to thatregion. For other CSPs, you might need VPN tunnels per region. If you havemultiple virtual networks in a cloud environment that aren't peered, you have toconnect all virtual networks that need to communicate with each otherindependently by using a VPN.

Google Cloud offersinteroperability guides,which have step-by-step instructions for setting up VPN tunnels to other majorcloud providers:

Transfer speed and latency

When you use managed VPN tunnels, data follows roughly the same internet paths asit would without the VPN tunnels. The latency observedshould be similar to the previous option with only a small latency overhead forthe VPN tunnels. The available bandwidth is limited by themaximum bandwidth perVPN tunnel on Google Cloud, the maximum bandwidthof the other CSP's tunnels, and the available bandwidth over the internet path.

For higher bandwidth, you can deploy additional tunnels. For moreinformation on how to deploy such a solution, seeHA VPN topologies to increase bandwidth.

You can test latency and bandwidth as described in the last section, butconditions might vary over time, and there are no guarantees on latency orbandwidth.

Security

Traffic over IPsec VPN tunnels is encrypted by using ciphers accepted by bothCSPs. For more information, seeCloud VPN supported IKE ciphers,AWS VPN FAQ,andAzure VPN IPsec/IKE parameters.

Reliability and SLA

Cloud VPN offers anSLA.Other CSPs sometimes offer SLAs on their managed VPN product, for example,AWS Site-to-Site VPN SLA andAzure SLA for VPN Gateway.However, these SLAs only cover the VPN gateways availability and don't includeconnectivity to other CSPs over the internet, so there is no SLA on theend-to-end solution.

To increase reliability, consider using additional VPN gateways and tunnels onboth Google Cloud and the other CSPs.

Pricing

For the managed VPN service, charges apply. For Google Cloud, an hourlycharge applies seeCloud VPN pricing.For other CSPs, consult their price lists, for example, seeAWS Site-to-Site VPN connection pricing orAzure VPN Gateway pricing.

In addition to hourly pricing for the VPN service, you have to pay for datatransferred through the VPN gateways. For Google Cloud and many CSPs,standard internet data transfer charges apply, as detailed inTransfer through external IP addresses over the internet. In manycases, data transfer charges exceed the fixed cost for this solution.

Partner Interconnect with multicloud enabled partners

Partner Interconnect lets you connect a Virtual Private Cloud to another CSP's virtual networks through the network ofselect partners that offer direct multicloud solutions. You connect bydeploying one or more virtual routing instances that take care of the necessaryBorder Gateway Protocol (BGP) setup.

The following diagram shows a redundant setup using twoPartner Interconnect connections.

Routes are exchanged between Cloud Router and the gateway on the otherCSP's side through a virtual routing instance that is managed by the partnerproviding the interconnect. Traffic flows through the partner network betweenGoogle Cloud and the other CSP.

Implementation

This solution requires you to set up multiple components:

• On the Google Cloud side, you set upPartner Interconnect with aninterconnect service provider that's serving your Google Cloud regions and offering multicloudconnectivity to the other CSP.
• On the other CSP, you have to use their interconnect product to connectto the same partner. For example, on AWS you can useDirect Connect and on Azure you can useExpressRoute.
• On the service provider partner side, you have to configure the virtualrouting equipment providing the BGP sessions to Google Cloud and tothe other CSP.

You can connect using Partner Interconnect by itself or you can set upPartner Interconnect as aNetwork Connectivity Centerhybrid spoke. Network Connectivity Center lets you connect on-premises locations, VPC networks,and other clouds using centralized management.

If IP address space between both CSP environments overlaps, you can enableHybrid NAT on the connection.

Transfer speed and latency

This solution offers dedicated capacity between Google Cloud and otherCSPs. Depending on the partner and the other CSP, the available attachmentcapacity might vary. On the Google Cloud side,Partner Interconnect is available with an attachment capacitybetween 50 Mbps and 50 Gbps.

Latency for this solution is the sum of the following:

• Latency between the region in which your resources are hosted onGoogle Cloud and the interconnect location where the partner connectsto Google Cloud.
• Latency in the partners network to, from, and through the virtualrouting instance towards the other CSP.
• Latency from the other CSP's edge location where the interconnect withthe partner takes place to the region where the resources are hosted in the CSP.

For the lowest possible latency, the edge locations of Google Cloud andthe other CSP should be in the same metropolitan area, along with the virtualrouting instance. For example, you might have a low latency connection if bothCSP's cloud regions as well as the edge PoP and the virtual routing instance arelocated in the Ashburn, Virginia area.

While Google Cloud and many other CSPs offer no latency guarantees fortraffic towards their network edge, because there is a dedicated path andcapacity through the partner, typically the latency in this solution is lessvariable than if you use external IP addresses or a VPN solution.

Security

Traffic over Partner Interconnect isn't encrypted by default. Tohelp secure your traffic, you can deployHA VPN over Cloud Interconnect on the Google Cloud side of the connection. Some other CSPs allow you to use theirmanaged VPN service over an interconnect; for example, AWS Site-to-Site VPN canbe used over AWS Direct Interconnect. Alternatively, you can also use a virtualappliance that encrypts the traffic on the other CSP's side.

Another option is to encrypt your traffic at the application layer instead ofusing VPN.

Reliability and SLA

This solution involves three different SLAs: one from Google, one from theinterconnect partner, and one from the other CSP.

When using Partner Interconnect redundantly, Google offers99.9% - 99.99% monthly SLAs depending on thetopology chosen. There is no SLA on a single Partner Interconnectconnection.

See the other CSP's documentation for the SLA on their interconnect product, forexample,AWS Direct Connect SLA or on AzureSLA for ExpressRoute.

Consult the documentation or terms of the partner service provider for thePartner Interconnect for their SLA on the availability of theconnectivity and virtual routing instance. For example, see theMegaport Global Services Agreement.

Pricing

On the Google Cloud side, there is a monthly fee for eachPartner Interconnect attachment, depending on the bandwidth.Traffic egressing through the Partner Interconnect gets chargedat a lower rate than internet traffic. For more information, see thePartner Interconnect pricing page.

Consult the other CSP's pricing page for their interconnect product, for exampleAWS Direct Connect pricing orAzure ExpressRoute pricing.Typically, pricing also has a monthly charge for the interconnect and datatransfer charges through the interconnect at a lower rate than over theinternet.

The partner provides interconnect services charges according to their ownpricing, which can be found on their website or by consulting their sales teamfor a quote. Typically, if all data transfers happen in the samemetropolitan area,charges are much lower than if data has to travel a longer distance on a partnernetwork.

When data is transferred regularly at sufficiently high volumes, depending onthe other CSP's prices, this solution can sometimes offer the lowest total costdue to the discounted egress rates. Even when adding in monthly costs for theinterconnect forPartner Interconnect,the other CSP, and the service provider partner, using this solution can providesignificant savings. As partners and other CSP's prices can change withoutnotice, make your own comparison using up-to-date quotes from all involvedparties.

Dedicated Interconnect through a common PoP

By using one or more physical routing devices at a common interconnect facilitybetween Google Cloud and the other CSP, you can connect both cloudproviders by using Dedicated Interconnect on theGoogle Cloud side and an equivalent product at the other CSP. Theinterconnect location isn't necessarily at the same location as the region inwhich your resources are located.

The following diagram shows a redundant setup using twoDedicated Interconnect connections:

Routes are exchanged between Cloud Router and the gateway on the otherCSP's side through a physical router that you place in a common interconnectfacility. Traffic flows through this router between Google Cloud and theother CSP.

Implementation

This solution requires that you host and maintain physical routing devices at acolocation facility where Google and the CSP you want to connect to are present.From this routing device, you order two physical connections with the facility:one toward Google Cloud usingDedicated Interconnect,and one towards the other service provider using an equivalent product, forexample,AWS Direct Connect orAzure ExpressRoute.On your routing device, you need to configure BGP to allow route exchangesbetween the two cloud environments.

Check theColocation facility locations list from Google Cloud and your other CSP, for exampleAWS Direct Connect Locations orAzure ExpressRoute peering locations,to identify suitable locations for this setup.

You can connect using Dedicated Interconnect by itself or you can set upDedicated Interconnect as aNetwork Connectivity Centerhybrid spoke. Network Connectivity Center lets you connect on-premises locations, VPC networks,and other clouds using centralized management.

If IP address space between both CSP environments overlaps, you can enableHybrid NAT on the connection.

This solution is effective if you use the dedicated connectivity to also connectback to your on-premises environment, in addition to the connection to anotherCSP.

In other cases, this solution is complex because it requires you to own andmaintain physical equipment and have a contract with a colocation facility. Weonly recommend this solution if at least one of the following is true:

• You already have equipment in a suitable facility for another purposeand an existing contract with the facility.
• You transfer large amounts of data regularly so this is a cost effectiveoption or you have bandwidth requirements that partners cannot fulfill.

This solution offers dedicated capacity between Google Cloud and anotherCSP. On the Google Cloud side, Dedicated Interconnect isavailable by using one or multiple10 or 100 Gbps physical connections.

The latency for this solution is a sum of the following:

• Latency between the region in which your resources are hosted onGoogle Cloud and the interconnect location where you interconnect withGoogle Cloud.
• Latency through the facility and your physical equipment, which isusually negligible when compared with any latency due to fiber length.
• Latency from the interconnect location through the other CSP's network tothe region where the resources are hosted in the CSP.

While no latency guarantees are offered, this solution typically allows for thelowest latency and highest transfer speeds between Google Cloud and othercloud environments over private IP addresses.

Security

Traffic over Dedicated Interconnect isn't encrypted by default.To help secure your traffic, you can deployHA VPN over Cloud Interconnect on the Google Cloud side of the connection. Some other CSPs allow you to use theirmanaged VPN service over an interconnect; for example, AWS Site-to-Site VPN canbe used over AWS Direct Interconnect. Alternatively, you can also use a virtualappliance encrypting the traffic on the other CSP's side.

Another option is to encrypt your traffic at the application layer instead ofusing VPN.

Reliability and SLA

When using Dedicated Interconnect redundantly, Google offers99.9%-99.99% monthly SLAs depending on the chosentopology.There is no SLA on a single Dedicated Interconnect connection.

For more information, see the other CSP's documentation for the SLA on theirinterconnect product, for example,AWS Direct Connect SLA orAzure SLA for ExpressRoute.

The colocation facility or hardware vendor for the physical routing equipmentmight also offer SLAs on their services.

Pricing

On the Google Cloud side, there is a monthly fee for eachDedicated Interconnect port as well as for each VLAN attachmentthat connects to a VPC environment. Traffic that egresses throughDedicated Interconnect is charged at a lower rate than internettraffic. For more information, see theDedicated Interconnect pricing page.

Consult the other CSP's pricing page for their interconnect product, forexample,AWS Direct Connect pricing orAzure ExpressRoute pricing.Typically, pricing also has a monthly charge for the interconnect and datatransfer charges through the interconnect at a lower rate than over theinternet.

In addition, you need to factor in charges for the colocation facility servicesproviding space, electrical power, and physical connections towards both cloudenvironments as well as any cost and ongoing service contracts with the vendorfor the physical routing equipment. If the connection between both CSPs cannothappen in the same facility and you need to procure connectivity betweenfacilities, pricing might be much higher for these services.

Cross-Cloud Interconnect managed connections

You can connect your Google Cloud VPC networks to yourvirtual networks in another CSP over Google's network fabric. In a sense, this setup works likePartner Interconnect, but with the Google SLA covering both theGoogle networksand the interconnections themselves.

The following diagram shows a Cross-Cloud Interconnectconfiguration with the minimum number of connections.

Routes are exchanged between Cloud Router and the gateway on the otherCSP's side over Google's network fabric. Traffic flows through this fabricbetween Google Cloud and the other CSP.

Implementation

When you buy Cross-Cloud Interconnect, Google provisions adedicated physical connection between the Google network andthat of another cloud service provider. You can use this connection to peeryour Google Cloud Virtual Private Cloud (VPC) network with a network that'shosted by asupported cloud serviceprovider.

After you provision the connection, Google supports the connection up to thepoint where it reaches the network of the other cloud serviceprovider. Google does not guarantee uptime from the other cloud serviceprovider. However, Google remains the primary point of contact for the fullservice and will notify you if you need to open a support case with the otherCSP.

This solution requires you to follow thesetup process for the other CSP, including choosing where the two networks are going tointerconnect. Only certainCSPs are supported.

You can connect using Cross-Cloud Interconnect by itself or you can set upCross-Cloud Interconnect as aNetwork Connectivity Centerhybrid spoke. Network Connectivity Center lets you connect on-premises locations, VPC networks,and other clouds using centralized management.

If IP address space between both CSP environments overlaps, you can enableHybrid NAT on the connection.

Transfer speed and latency

This solution offers dedicated capacity between Google Cloud and anotherCSP. On the Google Cloud side, Dedicated Interconnect isavailable by using one or multiple pairs of10 Gbps or 100 Gbps physical connections.

The latency for this solution is a sum of the following:

• Latency between the region in which your resources are hosted onGoogle Cloud and the cross-cloud location.
• Latency between the Google edge location and the other CSP's edge location(often in the same facility)
• Latency from the other CSP's edge location where theCross-Cloud Interconnect is deployed to the region where theresources are hosted in the CSP.

Although no latency guarantees are offered, this solution typically allows for thelowest possible latency and highest possible transfer speeds betweenGoogle Cloud and other cloud environments over private IP addresses.

Security

Because traffic over Cross-Cloud Interconnect isn't encrypted, werecommend using application layer encryption for sensitive traffic.

If all traffic needs to be encrypted, virtualappliances that are available from Google Cloud partners in theCloud Marketplace can provide solutions for encrypting the traffic to the other CSP'senvironment.

Reliability and SLA

Cross-Cloud Interconnect uses the Cloud InterconnectSLA.To qualify for the SLA, your Cross-Cloud Interconnectconfiguration must use one or more pairs of connections, as described in theService-level agreementsection of the Cross-Cloud Interconnect overview.

The SLA covers everything on the Google side up to the edge of the othercloud provider's network. It does not cover the other CSP's network.For more information, see the other CSP's documentation for the SLA on theirinterconnect product; for example,AWS Direct Connect SLA orAzure SLA for ExpressRoute.

Pricing

There is an hourly fee for each Cross-Cloud Interconnectconnection as well as for each VLAN attachmentthat connects to a VPC environment. Traffic that egresses throughCross-Cloud Interconnect is charged at a lower rate than internettraffic. For more information, seeCross-Cloud Interconnect pricing.

Consult the other CSP's pricing page for their interconnect product, forexample,AWS Direct Connect pricing orAzure ExpressRoute pricing.Typically, there is a monthly charge for the interconnect. Charges for datatransfer through the interconnect are typically lower than charges for datatransfer over the internet.

There are no separate costs for interconnect locations orequipment.

Comparison of options

The presented options vary in speed, availability, complexity, security, andpricing. You should evaluate all options thoroughly according to your needs.

The following diagram guides you through the process of choosing one of thesolutions mentioned in this document through a flow chart.

Typically, we can recommend the following choices:

• For many scenarios where data is exchanged occasionally or at lowvolume and transfers aren't critical, transferring data over the internetis the simplest option and still provides relatively low latency and highbandwidth.
• If encryption or transfer of smaller amounts of data using private IP addresses isrequired, consider using Cloud VPN and a managed VPN service onthe other CSP's side.
• If you transfer larger amounts of data, usingPartner Interconnect with a multicloud enabled partnerprovides multiple benefits: Dedicated capacity, lower cost for datatransfers, and depending on the topology, an SLA for each part of the solution.Partner Interconnect capacity is normally lessthan 10 Gbps per connection.
• If you connect your on-premises equipment to multiple clouds, usingDedicated Interconnect through a common PoP is a commonoption. It comes with additional complexity of managing your own hardwareand relationships with a colocation facility. Unless you already have theinfrastructure in place, this solution is reserved to cases where typicaldata transfer rates are 10 Gbps or more.
• If you don't want the overhead of managing cross-connects androuting equipment in remote PoPs, Cross-Cloud Interconnectprovides a managed solution where Google handles all of that for you.

What's next

• Review the series aboutHybrid and multicloud patterns and practices.
• Explore reference architectures, diagrams, and best practices about Google Cloud.Take a look at ourCloud Architecture Center.