Video: How to Connect Your AWS and Azure Environments Part 2

Our Solutions Architect Kyle Moreta walks you through how to efficiently connect an AWS VPC with a Microsoft Azure VNet with the help of Megaport (Part 2).

Have you watched Part 1 of this video tutorial? If not, start here, then come back. See you soon.

Welcome to Part 2 of my walkthrough of how you can connect an AWS VPC to Microsoft Azure VNet using Megaport and our Megaport Cloud Router (MCR), to build out direct, private connectivity between the two different clouds.

Remember, there’s a few things that are assumed in this video:

• Our AWS Direct Connect gateway and the virtual private gateway (VGW) association to that Direct Connect gateway will already be completed.
• I have already deployed my Azure VNet gateway.
• The subnets and Classless Inter-Domain Routing (CIDR) addresses we’re using in Azure and AWS need to be different in order for them to properly communicate to one another.

Did you miss Part 1 of this video series? You can find it here.

Step 4: Deploy ExpressRoute

After your ExpressRoute is done provisioning, go to that resource and copy down the pairing key. After you’ve copied that down:

1. Click “Add Connection” off of the MCR.
2. Select “Cloud.”
3. In the drop-down, select “Azure” and paste your service key.

With each Azure ExpressRoute, you get access to both primary and secondary ExpressRoute circuits that will land you on separate Azure devices, for HA redundancy and to achieve Azure’s SLA. From this one pairing key or one service key, we can spin up both the primary and secondary. I’m just going to set up my primary ExpressRoute circuit for this video:

1. Choose “Next” and for Peering Type, select “Private.” 
2. Name the connection (I’ll name it “Azure”). You’ll see it’s the same rate limit inherited from the Azure configuration.
3. Click “Next,” “Next,” “Add VXC,” and “Order.”

The Azure process is similar to AWS, where we let the MCR and AWS configure and automatically provision the IP address schemes and the authorization keys.

Step 5: Deploy AWS

While we’re waiting for our Azure circuit to finish spinning up, let’s jump back into our AWS console, where we’ll see the AWS Hosted VIF in a confirming state. We’ll click into that and:

1. Click “Accept” and choose the gateway type you want to land it on – I’m going to leave it as my Direct Connect gateway.
2. Find it in the dropdown and click “Accept.”

We’ll see this state change from a pending state to an “Available” state. Once it transitions to an available state, we’ll actually be able to see that our state will change from pending to available and the BGP status will change to “Up.”

Did you know Hosted VIF is one of three ways you can access AWS’ Direct Connect locations? Read our blog to learn more.

Step 6: Connect Azure VNET to ExpressRoute

Now that we see our Azure peering has been set up, we’re going to connect our VNet gateway to this ExpressRoute.

1. Click “Connections” and “Add Connection.”
2. In the drop-down, choose the subscription and resource group.
3. For the connection type, use ExpressRoute – I’ll name this “ER.”
4. Select your region – I’m going to use “US West 2” or “West US 2.”
5. Next, we’ll choose our settings. We should see our VNet gateway, ExpressRoute circuit, and routing weight – I’ll leave the rest of this as default.
6. Finally, click “Review + Create”.

This step is important on the Azure side because this is what allows Azure to start advertising routes over to our MCR, and in turn, over to AWS. So let’s go ahead and create this.

Now that our AWS Hosted VIF has finished deploying and is in an available state, we can see that BGP has come up. Make sure to check that your Azure resource and your VNet association to an ExpressRoute has finished deploying.

Need help making sense of all the variables in ExpressRoute pricing? Read our blog post here.

Step 7: Validate routes

Now we can jump back over into our Megaport Cloud Router, take a look at the route table and BGP peering, and see what networks, if any, we’re learning right now.

1. Click on the MCR looking glass which will jump you into the Routes Table.
   It looks like peering with Azure is up and established as well as peering with AWS. I have my 10.3 being learned and advertized—that is my VNET Azure—so I’m learning that from Azure. Similarly, I’m learning my AWS VPC CIDR from my peering with AWS. Now, to validate on both the Azure side and the AWS side.
2. Go back into your Azure portal and click “ExpressRoute” again.
3. Click into the ExpressRoute you just deployed.
4. On your Azure peering, on the far right, click “View route table” to see what networks are being learned from the MCR from this route table.
   We see our local networks and we see our “172” network, which is my AWS CIDR block, being learned from the MCR’s IP address.
5. Let’s validate on the AWS side as well. Jump over to “VPC” and take a look at the VPC’s route table associated with your VGW.

It looks like we’re learning Azure VNET CIDR, so now we’ve essentially set up, end to end, the connectivity that we need in order for our AWS instances to talk to our Azure VMs and vice versa.

That’s all of the setup and routing you need in place to get this connectivity up and running!

Learn more in the blog, 3 Ways to Connect Your AWS and Microsoft Azure Environments.

Stay Updated

Keep up to date on Megaport by following us on social media at:

Twitter: @megaportnetwork
LinkedIn: @megaport
Facebook: @megaportnetworks