Now that we understand why an organisation would consider ExpressRoute in the first place (private, reliable connectivity into Azure), the next step is where most people accidentally start too late:
picking a SKU, clicking through the portal, or trying to “just build the lab.”
But the real design work happens before any deployment
At this stage, you’re not choosing Azure settings. You’re choosing what kind of ExpressRoute capability the organisation needs, based on requirements.
Microsoft Learn frames this clearly:
“your decision comes down to things like performance needs, budget constraints, and how much control the organisation wants.”
Start with the big decision: How do we connect to Microsoft’s network?
The first major fork in the road is choosing between:
- ExpressRoute using a Service Provider
- ExpressRoute Direct
This is basically a choice between managed simplicity and maximum control/performance.
If the organisation is a small-to-medium business that wants a straightforward setup and prefers a provider to manage the connectivity piece, the service provider model is usually the natural fit.
It’s designed for simpler deployments where the organisation wants ExpressRoute but doesn’t need to get deep into controlling physical connectivity.
Microsoft Learn describes this model as a good match when you want a simple setup with managed services.
On the other hand, ExpressRoute Direct exists for the opposite end of the spectrum:
large enterprises, mission-critical applications, and high-performance connectivity requirements.
With Direct, you’re connecting straight into Microsoft’s network, using dual 10-Gbps or 100-Gbps ports, which immediately tells you what type of organisation this is aimed at:
the kind that needs serious bandwidth and wants the most control over how the connection is delivered.
It’s also positioned as being optimised for a single tenant with multiple business units, again, pointing toward larger, more complex organisations.
So in plain English, the decision looks like this: if the organisation needs ExpressRoute but wants it delivered and managed through a provider, you lean toward the service provider model.
If the organisation needs high bandwidth, high control, and enterprise-scale connectivity, you lean toward ExpressRoute Direct.
Next decision: What ExpressRoute SKU coverage do we need?
Once you know how you’ll connect, the next design choice is choosing the ExpressRoute SKU, which is really about geographic coverage and how broadly the organisation needs to connect into Azure.
Microsoft Learn breaks this into three levels:
- Local SKU (if available) is the most geographically focused option. It’s designed for organisations that need connectivity into a single Azure region, particularly when low latency to that specific region matters. If everything lives in one region and the business doesn’t need connectivity beyond it, Local can be appropriate.
- Standard SKU expands that reach. It supports connectivity to multiple Azure regions within the same geopolitical area. This is a good fit when an organisation operates within one region of the world (for example, staying within a single geopolitical boundary) but still needs flexibility to use more than one Azure region in that area.
- Premium SKU is the global option. It extends connectivity to all Azure regions worldwide, making it the obvious fit for multinational organisations that need to connect seamlessly across continents.
In practical terms, this is where you stop guessing and start matching the SKU to the organisation’s reality.
If their Azure footprint is regional, you don’t design like they’re global. If they are global, you don’t constrain them with a SKU that only works locally.
Final choice in this stage: What billing model fits the requirement?
Microsoft Learn also points out that you must choose a billing model.
In this design step, you’re not calculating exact costs, you’re simply deciding which approach aligns with the organisation’s expected usage:
- Unlimited data
- Metered data
- (and potentially) a premium add-on
This comes back to a simple requirement question:
do they expect consistently high data transfer where predictability is worth paying for, or is usage more variable where metering makes sense?