We recently put an Azure ExpressRoute circuit in to see whether it would fix a performance problem with a desktop application talking to a database in Azure. We had a business case, a carrier quote, and a quiet assumption that a dedicated private link would obviously beat a VPN.
After a few weeks of building, testing and far too many packet captures, the result was:
ExpressRoute: about 16 ms average to Azure Existing path (MPLS to a data centre, then IPsec into Azure): about 17 ms
One millisecond. Most of the business had never heard of ExpressRoute, and it’s now the question everyone asks: “So was it worth it?”
My honest answer is that it depends what you thought you were buying. If you bought it for raw speed, probably not. If you understand what it actually does, it can still be the right call. Here’s what I learnt.
Latency is mostly physics
This is the part that surprised people. ExpressRoute isn’t a faster kind of cable. Your packets still travel roughly the same physical distance to roughly the same Microsoft edge location. If your existing path is already well engineered, a single millisecond or two is about what you should expect.
Where ExpressRoute tends to show a big improvement is when the existing path is bad. Examples are a VPN over congested public internet, traffic taking a scenic route through another city, or a small firewall struggling to encrypt at line rate. If that describes you, you’ll probably see a real gain.
That last one is worth a moment. Removing IPsec doesn’t only remove header overhead, it removes the encrypt and decrypt cycle and any queuing that happens on an overloaded firewall. On a firewall that’s already at its limit, that can be a genuine latency component rather than just a throughput one.
Ours wasn’t. The firewall had plenty of headroom, so there was nothing much to recover.
In our case the existing path was already short. Traffic went over a private carrier link to a data centre a few kilometres from the Azure region, then through an IPsec tunnel. That route was never going to be dramatically beaten on latency, and it wasn’t.
Lesson one: measure your current path properly before you buy. If your existing latency is already close to the distance-based minimum, and your firewall isn’t struggling, ExpressRoute won’t make your app feel faster.
So what does ExpressRoute actually buy you?
Once we stopped looking at the average ping, the value became clearer.
Consistency
Average latency is a flattering number. What users actually feel is jitter, meaning the spikes and the occasional multi-second stall when something on the public internet gets congested. A private circuit with no internet in the path is far more predictable. For chatty client-server applications that make thousands of small round trips, consistency often matters more than the average.
If you’re testing ExpressRoute, look at the distribution of your results, not just the mean. Run extended tests at busy times of day and compare the worst cases.
An SLA, but check what it covers
A VPN over the internet has no end-to-end service level. You have your ISP’s SLA, Microsoft’s gateway SLA, and a big grey area in between. ExpressRoute comes with an availability SLA from Microsoft, and your carrier will have its own.
Be careful about how that gets written into a business case, though. The ExpressRoute SLA covers the ExpressRoute service. It does not cover your LAN, your firewall, your carrier’s network, or necessarily every Azure component in the path.
Your actual application path looks more like this:
Desktop
|
LAN
|
Firewall
|
Carrier network
|
ExpressRoute circuit
|
Microsoft edge
|
ExpressRoute gateway
|
Azure VNet
|
Database
A failure anywhere along that chain affects the application. So the business case shouldn’t say “ExpressRoute has an SLA” and stop there. It should say which part of the path that SLA covers, and what redundancy exists everywhere else.
If availability is a real reason you’re buying the circuit, design the redundancy. A single circuit on a single path isn’t the resilience story you’re paying for.
No tunnel overhead
IPsec adds headers, which means a smaller effective MTU and the MSS clamping and fragmentation headaches that come with it. If you’ve ever chased an application that works fine until it sends a large packet, you’ll appreciate a path that carries standard 1500-byte frames without the tunnel tax. It also takes encryption load off your firewalls.
Egress costs
Data leaving Azure over the internet is charged per GB. ExpressRoute has its own data plans, including metered and unlimited options. Depending on your traffic profile, that can work out cheaper, especially if you’re pulling large volumes back on-premises for backups, reporting or data replication. Do the maths on your actual traffic before assuming either way.
Staying off the internet
For some organisations, having traffic to core systems never touch the public internet is a governance or compliance requirement in itself. That’s a legitimate reason to buy ExpressRoute regardless of performance.
The catch nobody mentions: it isn’t encrypted
This one deserves its own heading. ExpressRoute private peering is private, but it isn’t encrypted by default. Your traffic crosses your carrier’s network and Microsoft’s edge in the clear.
If you’re moving off an IPsec tunnel, you’re going from encrypted to unencrypted. For many organisations that’s an acceptable risk, since the link is dedicated and not shared with the internet.
But understand what you’ve done: you have removed a security control. Someone will eventually ask why, when, and who approved it. Record that decision wherever your organisation keeps them, whether that’s a change record, a risk register, a security assessment or an architecture decision record. Discovering it during an audit two years later is a worse conversation.
If encryption is required, the options are IPsec over the ExpressRoute circuit, which brings back some of the overhead you were trying to escape, relying on application-layer TLS, or MACsec if you’re on ExpressRoute Direct. Microsoft covers these in its ExpressRoute security guidance.
And it’s not for Microsoft 365
A common assumption is “we’ll have ExpressRoute, so Teams and Outlook will be better too.”
Microsoft’s position is clear enough: ExpressRoute isn’t recommended for Microsoft 365 in most circumstances, authorisation is required for customers who want to use it that way, and Microsoft says it only grants that authorisation in rare scenarios. The detail is in Implementing ExpressRoute for Microsoft 365.
M365 is designed to be reached over the internet, as close to the user as possible, through Microsoft’s globally distributed front doors. Forcing that traffic back through a single private circuit usually makes it worse, not better.
If M365 performance is your problem, look at local internet breakout, bypassing proxies and inspection for M365 endpoints, and DNS resolution close to the user.
ExpressRoute is for your workloads in Azure: VMs, databases, private endpoints. Keep it in that lane.
Some practical lessons from the build
A few things caught us out that are worth passing on.
Test in isolation. We built the test on a spare firewall with its own small LAN, completely separate from production routing. That was the best decision of the project. It meant we could break things freely (and we did) without touching the live network, and measure the new path cleanly against the old one.
BGP up doesn’t mean it works. We had both BGP sessions established to Microsoft but zero routes coming through. The circuit had never been linked to the virtual network gateway. In Azure, the circuit, the gateway and the connection between them are separate objects, and all three must exist.
Hub and spoke needs extra switches flipped. If your workloads sit in spoke networks, the peerings need gateway transit enabled on the hub side and “use remote gateways” on the spoke side. Route tables on the spokes also need gateway route propagation enabled, or the routes learnt over ExpressRoute never reach your subnets.
Old custom routes can quietly break things. A user-defined route pointing at “Virtual network gateway” as the next hop works for VPN gateways but not ExpressRoute. Microsoft documents that next-hop type as unsupported for ExpressRoute gateways. It doesn’t error. It just resolves to nothing. When traffic disappears, check the effective routes on the actual VM network interface rather than what you think the route table says.
Portal saves aren’t always saves. On at least one occasion, a peering change in the portal appeared to save but hadn’t. When something doesn’t behave the way the screen says it’s configured, check it with PowerShell or the CLI.
Check vendor guides line by line. Our provider’s setup guide had a couple of errors, including which side of the peering subnet each party uses. Don’t assume the document is right just because it came from the people who sold you the circuit.
My opinion: should you buy it?
Here’s where I’ve landed.
Buy ExpressRoute if:
- Your core business systems live in Azure and you need predictable, SLA-backed connectivity to them
- Your current path goes over the public internet and suffers jitter or congestion
- You move large volumes of data out of Azure and the egress maths works
- You have a governance requirement to keep traffic off the internet
Think twice if:
- Your only goal is lower latency and your existing path is already short and private
- You’re hoping it will improve Microsoft 365
- You haven’t budgeted for redundancy, because a single circuit on a single path isn’t the resilience story you’re paying for
In our case, one millisecond wasn’t the win. The value we’re weighing is consistency, the SLA, and simplifying a path that currently goes through two hops and a tunnel. That’s a much more honest conversation to have with the business than “it’ll make things faster.”
The real lesson is to write down what problem you’re trying to solve before you order the circuit, and measure against that. If the answer is “speed,” make sure your current path is actually slow first.
References
- Secure your Azure ExpressRoute deployment
- Implementing ExpressRoute for Microsoft 365
- Azure virtual network traffic routing
- Plan hybrid connectivity with VPN and ExpressRoute
From my early days on the helpdesk through roles as a service desk manager, systems administrator, and network engineer, I’ve spent more than 25 years in the IT world. As I transition into cyber security, my goal is to make tech a little less confusing by sharing what I’ve learned and helping others wherever I can.