Microsoft Azure ExpressRoute
By: Siobhan Wood on6 minutes to read
Our infrastructure director explores ExpressRoute…
ExpressRoute is becoming a key connectivity method in to Microsoft’s Azure cloud services. ExpressRoute offers organisations a direct route into Microsoft’s cloud services, removing the need for your IT users to traverse the internet. Not only does this add a level of privacy to your cloud connection, it can also help reduce bandwidth charges and simplifies charging mechanisms when accessing services hosted on Azure.
Currently there are two ways of connecting to Azure through ExpressRoute. These are via Exchange Providers or Network Service Providers. The considerations in choosing between the two connectivity types include factors such as cost, flexibility, management and implementation lead times. I’ll explain further…
Exchange Provider’s have a direct connection in to Azure data centres that you can hook your WAN service on to. This means terminating your existing WAN services in an Exchange Provider’s data centre. This is a very versatile option as typically your WAN provider will already have a presence in the Exchange Provider’s facility and if not, it is likely that you will have a number of connection options to their facility from your existing sites. This can mean shorter lead times to get access to the EP’s data centre but that’s where the issues can start, as it means your EP then needs to “cross connect” your WAN termination point on to their ExpressRoute connection. This typically means being reliant on 3rd parties for 3 key setup activities:
- Setup of the termination of WAN services at your EP’s data centre.
- Installation of data termination equipment (DTE’s) and routers at your EP.
- Your EP cross connecting and configuring your service on their ExpressRoute connection.
Another drawback of Exchange Provider’s services is that in effect you are still paying for Outbound data transfers. The advantage here is that the outbound transfers are provided on a dedicated port speed, which means you can at least predict performance of your service on Azure, if not so easily, your costs.
Network Service Providers
Network Service Providers are slightly different. This is a direct connection into the Azure Data Centres from an existing MPLS WAN service that you may have. MPLS is a method of sharing a vendor’s wide area network in a secure way. It is widely accepted that MPLS is a proportionally secure approach (proportional to cost), of transferring data over large distances. The drawback here is that very few organisations offer this service currently in to Azure and it means you really should have an MPLS WAN already if you wish for short lead times and low levels of change. That said there is nothing stopping you from migrating to an MPLS service or even creating a separate, additional WAN service on MPLS and using a couple of points in your network to route diversely.
The great thing about NSP ExpressRoute is the ability to pay for a set port speed per month, which includes data transfers in and out of Azure. This vastly simplifies your monthly expenditure on Azure and means you can predict your costs far easier. The other major benefit of this type of connectivity is that it reduces the level of 3rd party involvement that you need to engage with, meaning once the setup of MPLS is complete, the actual configuration on Azure is self-service. Therefore you can manage one 3rd party to get MPLS up and running and use your in house expertise to do the last bit of configuration to get the connection actually working.
In short, both options are somewhat similar in general in that they both advertise routes through BGP; the connectivity to your Azure services at the Azure network level is similar (if not the same) and they both have current restrictions in using both ExpressRoute and VPN as part of the same service, which is rumoured to be changing as part of the roadmap over the coming 4 – 5 months.
Of course everybody’s circumstances are slightly different and every organisation will have different priorities such as cost, flexibility, choice, lead times etc and of course it depends on your current WAN setup, number of WAN endpoints and so on… I would look to understand the following about your existing WAN setup and think about the following points before deciding on which connectivity route to Azure you should choose:
- Have an understanding of what capacities - both currently used and what you may need in the future you need, types of services used across your WAN (i.e. is voice in scope, is QOS required etc), number of WAN termination points and dependencies there are on your existing WAN service.
- Understand the contract of your existing WAN service and understand the possibilities of your existing providers with ExpressRoute with those providers offering ExpressRoute either as a Network Provider Service or Exchange Provider.
- Have a plan of how you are going to manage ExpressRoute once in service and try to model the costs and dependencies on your organisation of both options. For example do you have the right resources to manage the service and do you understand what the cost comparison truly looks like between the options?
- Bear in mind the dual running costs of transition between the two connectivity services and ensure you understand lead times of the service you are proposing to migrate to, in relation to the overall plan of your Azure migration.
- Don’t discount VPN and direct Internet connections for smaller sites or for access to services that perhaps don’t require as high a level of security assurance, high bandwidth performance or are expected to be downloading high amounts of data from Azure.
For further information on Shaping Cloud’s Consultancy Services and ExpressRoute please mail us at firstname.lastname@example.org or give us a call on 0161 408 5333.