Megaport Cloud Router Multicloud

Migrating to Megaport Cloud Router for Multicloud

Exploring the benefits of Megaport Cloud Router for moving traffic between clouds and why your business might want to make the move from the standard Megaport model. 

Hybrid multicloud strategies are not just simply being discussed within the roadmap of the enterprise, but are becoming hugely important considerations for businesses moving mission-critical applications to the cloud. In fact, IDC predicts that 65% of A500 organisations will have a multicloud management strategy by 2020. The idea of using multiple public and private clouds, as well as on-premises environments to power their businesses, is fast becoming a reality for companies globally.  

While major public cloud providers strategically select the location to deploy their new regions (based on a variety of requirements and driving factors), it’s inevitable that not all enterprises will be located geographically close to those regions. This means that connectivity often becomes a challenge for those organisations when they need network traffic to flow between their chosen clouds.

Megaport enables enterprises to reach the cloud no matter if they’re located outside of a cloud region. This is one of the Network as a Service provider’s most valuable benefits as this means many underserved locations have the cloud access they need. Let’s take a look at a standard Megaport model accessing multiple public cloud instances: 

When using a standard Megaport model to access the public cloud, connectivity is quick and easy to provision, and is available from any of our Megaport enabled data centres. This is a great model to enable on-premises access to a single or multiple cloud providers.

However, if there’s a requirement for traffic to flow between two clouds, for example, from Google Cloud Platform to Microsoft Azure, the latency will depend on the distance from the on-premises data centre to the public clouds (x ms + y ms, as shown in diagram above), instead of the distance between the public cloud locations, which in some cases, reside within the same data centre.

Megaport Cloud Router (MCR) allows our customers to route data to and between various providers and platforms without hair-pinning traffic back to a data centre or on-premises environment. Let’s take a look at the MCR model:

As you can see, the latency between the public clouds is no longer dependant on the physical distance from the on-premises location, but rather, the traffic is routed between the cloud providers via Layer 3 connectivity. 

An added benefit of moving to the MCR model is to potentially lower the total cost due to only one or two (HA) interstate/international VXCs being required with multiple same metro VXCs versus multiple interstate or international VXCs when using the standard Megaport model for multicloud.

For Megaport customers who are currently running on a standard Megaport model with one or two connections into the public cloud and are looking to deploy MCR, read on, and we’ll look at the steps required to migrate to the MCR model considering a few different cloud providers.

Microsoft Azure

Note: Pre-May 2019, if you wanted to link a virtual network to different ExpressRoute circuits, the circuit would have needed to be from different peering locations. Since May 2019, this has changed (see Microsoft Doc Github History), and you can now link up to four ExpressRoute circuits in the same or different peering locations. Read this article for more information on this.


  1. Log in to your Megaport account and create an MCR
  2. Create a Private VXC from your MCR to your Megaport
  3. Create a second ExpressRoute circuit at a location that is closest to the Azure ExpressRoute peering location
  4. Create VXC(s) from the MCR to ExpressRoute
  5. Connect the ExpressRoute circuit to the ExpressRoute Gateway that is attached to the Virtual Network (VNet) and associate the circuit to the Route Filter for public-facing services
  6. Disable the BGP session(s) to your old VXC(s)
  7. Delete the connection from the ExpressRoute Gateway to your old ExpressRoute circuit
  8. Delete your Private Peering details
  9. Decommission your old VXC(s)
  10. Delete the ExpressRoute circuit once the status has changed to ‘Not Provisioned’



  1. Log in to your Megaport account and create an MCR
  2. Create a Private VXC from your MCR to your Megaport
  3. Create AWS Private VIF VXCs to your Primary and Secondary Onramps
  4. Accept the connection from the Virtual Interface section of the Direct Connect page within your AWS Console
  5. Create an AWS Public VIF VXCs to your Primary and Secondary Onramps
  6. Accept the connection from the Virtual Interface section of Direct Connect page within your AWS Console. Note: You may need to wait for up to 72 hours for AWS to verify this
  7. Disable the BGP session(s) to your old VXC(s)
  8. Delete the VXC(s) from Megaport to AWS

Google Cloud Platform (GCP)


  1. Log in to your Megaport account and create an MCR
  2. Create a Private VXC from your MCR to your Megaport
  3. Create Partner Interconnect VLAN Attachments from the GCP Console
  4. Create VXCs using the Pairing Keys of the VLAN Attachments
  5. Disable the BGP session(s) to your old VXC(s)
  6. Delete the VXC(s) from Megaport to GCP
  7. Delete the VLAN Attachments and Google Cloud Router from the GCP Console

High-performance hybrid multicloud connectivity has never been so easy to implement, whether you are mixing cloud to cloud, data centre to cloud, or data centre to data centre, MCR is the service that joins everything together. The core of your network can now exist virtually without the need to implement and continually manage more hardware. API integrations with the world’s leading cloud providers are built in – leading to better multicloud performance and less hassle on your side.

If you’d like to talk to us about migrating from multiple connections to MCR, feel free to get in touch here.

Steve Tu
Solutions Architect

Tagged under:



2019 in Focus: This Year's Interconnection Trends

See what’s next for enterprise interconnection and how you can get ahead.