When you use Cross-Cloud Interconnect, Google provisions physical connections on your behalf between the Google Cloud network and the Microsoft Azure network.
Before Google can establish these connections, you must order ports from both Google and Azure. In preparation for that process, identify the Google Cloud locations and the corresponding Azure locations that you want to use for your connections.
Best practices for selecting a location
When deciding where to place your connections, consider questions such as the following:- Where are most of your Google Cloud resources?
- Where are most of your Azure resources?
If your resources from both clouds are in the same place, then the choice is simple. However, if they are not, consider whether you want your connections to be closer to your Google Cloud resources or closer to your Azure resources. If the connections are closer to your Azure resources, then your traffic spends more time traveling on the Google network, which in general is desirable. However, you should also consider the outbound data transfer costs that you're likely to incur from both clouds.
Factors affected by location
This section describes factors that are affected by your location choice.
VLAN attachments and ExpressRoute circuits
After your Cross-Cloud Interconnect connection is established, you must configure several resources in Google Cloud and Azure. In Google Cloud, these resources include VLAN attachments. A VLAN attachment is a logical connection between your remote cloud network and a single region in your Virtual Private Cloud network.
In Azure, you must create a similar resource. The Azure resource is called an ExpressRoute circuit.
When you choose a location for your ports, you limit the set of regions where you can place both VLAN attachments and virtual interfaces. For this reason, the supported locations table includes columns for the Google Cloud and Azure regions that are served by each port location.
Edge availability domains
Each metropolitan area has two Google Cloud edge availability domains. Two domains in the same metropolitan area are not scheduled to be down for maintenance at the same time. For this reason, when you select a location for a primary and redundant port, each port must use a different edge availability domain within the same metropolitan area. This is true regardless of how you order your ports. However, when you use the Google Cloud CLI, you must specify each edge availability domain explicitly. When you use the Google Cloud console, you simply select a location, and Google Cloud reserves a port for you in each domain.
In the gcloud CLI version of the location name, the edge availability domain is the
second piece of information. For example, if the location name is iad-zone1-1
,
the edge availability domain is zone1
. If the location name is
iad-zone2-1
, the edge availability zone is zone2
.
Colocation facilities
Azure requires that connections are provisioned in the same facility. For that reason, each pair of locations in the supported locations table represents a single facility.
List of supported locations
The following table lists the supported Azure locations and the corresponding Google Cloud locations.
You must specify the Google Cloud location of your Cross-Cloud Interconnect port, and additionally specify where in your other cloud provider to connect it. This latter Azure location is referred to as the remote location in this documentation set and within Google Cloud. Make sure to use the remote location name when you order the Cross-Cloud Interconnect. Your remote cloud provider has a different, although similar, name for the location, which you use when you order the port with that cloud provider.
For each location name, some syntax variations exist. For example:
- The remote location name varies depending on whether you are interacting with Azure or Google Cloud.
- When interacting with Google Cloud, the Google Cloud console displays the remote location description next to the location name to help you choose the correct location.
- In Google Cloud, the Google Cloud console Cloud Interconnect location (not the remote location) shows facility information rather than the actual Cloud Interconnect location name.
Google Cloud regions | Microsoft Azure regions | Metropolitan area | Remote location | Google Cloud locations | |
---|---|---|---|---|---|
Google Cloud | Microsoft Azure | ||||
|
|
Hong Kong | azure-equinix-hong-kong-hk1 | Equinix-Hong-Kong-HK1 |
|
|
|
Osaka | azure-equinix-osaka-os1 | Equinix-Osaka-OS1 |
|
|
|
Seoul | azure-kinx-seoul-gasan | KINX-Seoul-Gasan |
|
|
|
Singapore | azure-equinix-singapore-sg1 | Equinix-Singapore-SG1 |
|
azure-global-switch-singapore | Global-Switch-Singapore |
| |||
|
|
Tokyo | azure-equinix-tokyo-ty4 | Equinix-Tokyo-TY4 |
|
|
|
Sydney | azure-equinix-sydney-sy2 | Equinix-Sydney-SY2 |
|
azure-nextdc-sydney-s1 | NextDC-Sydney-S1 |
| |||
|
|
Amsterdam | azure-equinix-amsterdam-am5 | Equinix-Amsterdam-AM5 |
|
|
|
Frankfurt | azure-interxion-frankfurt-fra11 | Interxion-Frankfurt-FRA11 |
|
azure-equinix-frankfurt-fr7 | Equinix-Frankfurt-FR7 |
| |||
|
|
London | azure-equinix-london-ld5 | Equinix-London-LD5 |
|
|
|
Paris | azure-interxion-paris-par5 | Interxion-Paris-PAR5 |
|
|
|
Zurich | azure-interxion-zurich-zur2 | Interxion-Zurich-ZUR2 |
|
|
|
Mumbai | azure-tata-mumbai-lvsb | Tata-Mumbai-LVSB |
|
|
|
Washington D.C. | azure-equinix-ashburn-dc2 | Equinix-Ashburn-DC2 |
|
azure-equinix-ashburn-dc6 | Equinix-Ashburn-DC6 |
| |||
azure-coresite-reston-va2 | CoreSite-Reston-VA2 |
| |||
|
|
Chicago | azure-equinix-chicago-ch1 | Equinix-Chicago-CH1 |
|
|
|
Dallas | azure-equinix-dallas-da3 | Equinix-Dallas-DA3 |
|
|
|
Montreal | azure-cologix-montreal-mtl3 | Cologix-Montreal-MTL3 |
|
|
|
Portland | azure-edgeconnex-portland-por01 | EdgeConneX-Portland-POR01 |
|
|
|
San Antonio, Texas | azure-cyrusone-san-antonio-1 | CyrusOne-San-Antonio-1 |
|
|
|
San Francisco | azure-coresite-santa-clara-sv7 | CoreSite-Santa-Clara-SV7 |
|
|
|
Seattle | azure-equinix-seattle-se2 | Equinix-Seattle-SE2 |
|
|
|
Toronto | azure-cologix-toronto-tor1 | Cologix-Toronto-TOR1 |
|
Verify availability
After you've identified a location that you want to use, double-check that it has an available 10-Gbps or 100-Gbps ExpressRoute Direct port. This step is helpful because the availability of ports can change without notice.
If you're working in the Azure portal, you can verify availability while ordering your connections. To verify availability in advance, use Azure PowerShell.
Azure PowerShell
Use the Get-AzExpressRoutePortsLocation
command:
Get-AzExpressRoutePortsLocation -LocationName LOCATION
Replace LOCATION
with the name of the location as it's
represented in Azure—for example, Interxion-Frankfurt-FRA11
.
In the command output, look for the AvailableBandwidths
block. Make sure
that it lists the port speed that you need.
For example, the following output shows that the Interxion-Frankfurt-FRA11
has available 10 Gbps
and 100 Gbps
ports:
Name : Interxion-Frankfurt-FRA11 Id : [ID information] ProvisioningState : Succeeded Address : Interxion Deutschland GmbHHanauer Landstraße 298 60314 Frankfurt am Main Deutschland Contact : de.info@interxion.com AvailableBandwidths : [ { "OfferName": "100 Gbps", "ValueInGbps": 100 }, { "OfferName": "10 Gbps", "ValueInGbps": 10 } ]
Note locations and regions
After you've reviewed the previous sections, make a note of the following values:
- The remote location, as it's known in Google Cloud, and the Google Cloud location. You need these values when you order your Cross-Cloud Interconnect connections.
- The remote location, as it's known in Azure, and the region where you want to place the ExpressRoute Direct resources and ExpressRoute circuits. You need these values when you order your Azure ports and create the ExpressRoute circuits.
- The Google Cloud region where you want to place your VLAN attachments. You need this value when you create the attachment, as described in Configure your Google Cloud resources.