Note: I wrote this post for Nimbo, and it was published to their blog a few weeks back.
One of the many benefits to moving your infrastructure to the cloud is the immediate and low cost ability to create a highly available network. In the world of traditional data centers, and even co-located data centers, placing hardware across geographic regions is a costly endeavor. Having the ability to mitigate the risk of a natural disaster wiping out your infrastructure with a few clicks is an incredibly attractive proposition.
Out of the box, neither Azure nor AWS offer cross region redundancy. While they give you the tools to create a highly available infrastructure, they leave the details up to the engineers. If you’re familiar with the tools and technology for distributing a traditional data center, you’ll be comfortable in creating one on Azure as well. There are few quirks though, and this post is intended to guide you through those quirks and help you get up and running quickly.
Up until recently, building a cross regional network meant maintaining the VPN servers and ensuring they were secure, available and reliable. While not a huge administrative burden, it does add to the plate of System Administrators and can cause unwanted outages when the virtual machine is updated or taken offline.
Recently Microsoft released the ability to connect two virtual networks natively using tools built into Azure. You can see some of the cost details at the end of the post.
Watch Video Tutorial
- Create two Virtual Networks in two separate regions.
- Create two corresponding Local Network Connections
- Enter any VPN IP (i.e. 22.214.171.124)
- Use a subnet in the corresponding address space (i.e. Vnet1: 10.0.0.0/16; Vnet1ln: 10.0.1.0/25)
- Select the first Virtual Network and navigate to the Configure page.
- Under the site-to-site connectivity section, select the Connect to local network check box.
- From the Local Network drop down, select the vnet local network that you would like to connect to.
- Azure may create a gateway subnet for you. If not, or if it creates one with a poor design, add a gateway subnet for the new adapter.
- Select the Dashboard section and create a new Dynamic Gateway.
- The Gateway creation process can take up to 20 minutes to complete.
- Repeat steps 3 & 4 for the second virtual network.
- After the two dynamic gateways have been created, transpose the Gateway IP Address from each Virtual Network to that networks corresponding Local Network connect.
- This address is pasted into the VPN Device IP Address section.
- Open a PowerShell prompt with the Azure PowerShell tool installed and connect.
- Run the following commands:
PS C:\> Set-AzureVNetGatewayKey -VNetName [Vnet 1 name here] -LocalNetworkSiteName [Vnet 2 local network name here] -SharedKey [alphanumeric key 8-128 characters]
- Repeat the command for both virtual networks. You will receive a confirmation message after the command has completed successfully.
- Open the Azure Management Portal again and select the first Vnet.
- Click the Connect button from the bottom of the Dashboard
- Repeat this for the second Vnet
- You will see a small amount of data crossing over the connection.
The price to run a Gateway is almost identical to building your own VPN servers. The real benefit comes in the form of uptime, maintenance and ease of use.
- $0.05 per gateway per hour
- Standard Egress rates apply
While we've always had the ability to create vnet-to-vnet cross regional connections by spinning up an application server in each of the regional virtual networks, Microsoft has now given Azure the ability to do this natively. The power of the Dynamic Gateway lies in it's ability to create a consistent, stable and admin free connection between two geographic location on the fly. While the over all setup may end up costing the same, the time saved and networking improvements can easily justify taking the route outlined above.