Connection Options When Building An Azure Hybrid Cloud Solution

If your business is migrating workloads to Azure the chances are at some point you will probably want to create a form of private interconnect with Azure. There is more than one way to achieve this, so in this post I’ll take a look at what options you have and the most appropriate scenarios for each.

We’ll work through the connection types from simplest (and quickest to provision) to more complex (where you’ll need IP networking expertise and hardware).

Hybrid Connection

This is your baseline interconnect option and is tied to the BizTalk Services offering within Azure. At time of writing the only Azure-based services that can leverage Hybrid Connections are Web Apps (formerly Websites) and Mobile Apps (formerly Mobile Services).

Hybrid Connections are a great way to quickly get access to on-premises resources without the complexity involved in firewall or VPN setups. If you look at the official documentation you’ll see there is no mention of firewall rules or VPN setup!

Your on-premises resources must be running on Server 2008 R2 or above in order to leverage this service offering which at its most restricted can work over standard HTTP(S) ports and nothing more.

• Benefits:
  • Quick to setup (requires no changes on-prem)
  • Typically “just works” with most corporate network edge configurations
  • Doesn’t require a Virtual Network to be configured in Azure
  • Can be shared between multiple Web and Mobile Apps
  • Good for exposing single on-prem resources to consumers in Azure (i.e. DB on-prem / web in Azure).
• Drawbacks:
  • Your security team may be unhappy with you 🙂
  • Performance may not meet your needs beyond simple use cases
  • TCP services requiring dynamic ports aren’t supported (think FTP)
  • Tied to BizTalk Services and utilises a range of other Azure services such as ACS and Azure SQL Database
  • In Preview (no SLA) and not available in all Azure Regions
  • Limited use cases in Azure (Web and Mobile Apps).

Point-to-Site VPN

The next step up from Hybrid Connections is Point-to-Site (P2S) VPN connections. These connections allow you to use a downloaded client to provide an SSTP VPN between a single on-premises (or Azure based) resource and a Virtual Network (VNet) in Azure.

This VPN setup is a good way to test out simple-to-medium complexity hybrid scenarios or proof-of-concepts without the need for dedicated VPN hardware in your corporate environment.

When setting up a P2S VPN you have a few items you need to succeed:

• the IP address range that will be used for clients when they connect
• a subnet defined on your VNet for the Azure Gateway that will host VPN connections
• a running Gateway instance that will allow your VPN clients to connect
• a valid x509 certificate that will be used by the VPN client.

As you can see, there are quite a few extra steps involved beyond the Hyrbid Connection! You can run up to 128 on-prem clients connected to an Azure VNet if needed.

• Benefits:
  • Does not require dedicated on-premises networking hardware
  • SSTP can usually connect OK with most corporate network edge configurations
  • Can co-exist with Site-to-Site connections
  • Allows you expose services on a single on-prem resource to an entire Azure VNet.
• Drawbacks:
  • You’ll need to understand IP networking to setup a VNet in Azure
  • Performance is still relatively limited due to the nature of SSTP
  • Isn’t an ‘always on’ proposition as requires an interactive user session on-prem to run the client
  • Only supports connection from a single on-prem resource running on Windows
  • You’ll need an x509 certificate for use with the VPN client.

Site-to-Site VPN

Now we start to get serious!

If you want to run a Site-to-Site (S2S) connection you will need to have dedicated VPN hardware or Windows Server 2012 (or above) running RRAS on-prem and some private IP address space for your Azure environment that doesn’t overlap with the on-premises network you’ll be connecting with.

This option is the first to really offer you a true hybrid environment where two networks can connect via the VPN. This is often the first step we see many enterprises take when adopting Azure as it is relatively quick to stand up and typically most customers have the necessary devices (or ones that meet Azure’s VPN requirements) available already.

When you setup your Gateway in Azure, the Azure platform will even handily provide you with a configuration script/template for whichever on-prem device you’ve selected.

• Benefits:
  • Provides full network-to-network connectivity
  • Supports a growing number of standard VPN appliances
  • Foundation of support for multi-site connectivity
  • Can use Windows Server 2012 RRAS if you don’t have an appliance.
• Drawbacks:
  • Maximum throughput of 100 Mbps
  • Doesn’t support redundant single site to single VNet connections.

Be aware: Forced Tunnelling

Before we move on to the next Azure connection type we do need to talk about Forced Tunelling. The current generation Azure VNet has a default route for all public Internet traffic which is out over Azure’s managed Internet infrastructure (it’s just there and you can’t manage it or turn it off). On some other public cloud platforms you can disable public internet traffic by not adding an Internet Gateway – on Azure that option isn’t currently available.

In order to mitigate some challenges around controlling the path public traffic takes from an Azure VNet, Microsoft introduced Forced Tunelling which can be used to force traffic bound for the Internet back over your VPN and into your on-prem environment.

You must plan your subnets appropriately and only apply Forced Tunelling to those where required. This is especially important if you will consume any of Azure’s PaaS offerings other than Web or Worker Roles which can be added to an Azure VNet.

Almost all of Azure’s PaaS services (even Blob Storage) are exposed as secured public Internet endpoints which means any call to these from a VNet configured for Forced Tunelling will result in that traffic heading back to your on-prem network and out your own Internet Gateway. Performance will take a hit and you will pay data egress charges on those calls as well as they will appear to originate from your on-prem Internet Gateway.

ExpressRoute

The grandpappy of all of them – and the one that requires the most planning and commitment. If you find yourself starting your hybrid journey here then either you have an existing investment in an MPLS WAN or you’re already co-located in an exchange that is providing ExpressRoute services.

The are two connection options for ExpressRoute:

• Network Service Provider (NSP): utilises a new or existing MPLS WAN cross-connect into one or more Azure Region. Speeds 10 Mbps to 1 Gbps supported.
• Exchange Provider (IXP): uses a new paired cross-connect in a data centre location when the IXP and Microsoft’s routers are co-located. Speeds 200 Mbps to 10 Gbps supported.

The officially support list of NSPs and IXPs is pretty small, but you can quite often work with your existing provider to get a connection into an IXP, or look to leverage offerings such as Equinix’s Cloud Exchange as a shortcut (for example, in Sydney 130+ network service providers provide services into Equinix).

Once you’re operating at this level you will definitely need the networking team in your organisation involved as you’ll be doing heavy lifting that requires solid knowledge of IP networking and specifically BGP.

• Benefits:
  • A single ExpressRoute circuit can connect to multiple Azure VNets (up to 10) and across multiple Azure Subscriptions (also up to 10)
  • Redundant connection by default (a pair is provided when you connect)
  • Two peers provided: one for Azure public services and one for your private services. You can choose to not use either peer if you wish
  • Can support bursting to higher bandwidth levels (provider depending)
  • Offers an SLA for availability.
• Drawbacks:
  • Requires that you have a relationship with an NSP or IXP in addition to Azure.
  • NSP bandwidth maximum is 1 Gbps
  • Maximum 4,000 route prefixes for BGP on all peers on a connection.

If you’re unsure how to get started here, but you have an existing WAN or co-location facility it may be worth talking to them about how to get a connection into Azure.

Be Aware: Default Routes and Public Peering

This topic falls under the same category as the earlier section on Forced Tunnelling for S2S VPNs.

When using ExpressRoute you can use BGP to advertise the default route for all your Azure VNets to be back over your ExpressRoute connection to your on-prem environment. Unlike the VPN connection scenario though, where all Azure PaaS services will route back over your on-prem Internet gateway, with ExpressRoute’s peering you can use the public peer as the shortcut back to Azure.

While this is a better option than you get with VPN it still means you are pushing Azure calls back to your ExpressRoute gateway so you will potentially see a performance hit and will see the data included if you are using an IXP connection.

Conclusion

So there we have it – a quick rundown of the techniques you have at your disposal when looking to create a private hybrid network environment that allows you to connect your existing locations with Azure.

HTH.