At this stage in the ExpressRoute journey, a lot of groundwork has already been done.
Azure is ready to accept a private connection, and Microsoft has reserved capacity at the edge of its network.
You’ve created a virtual network with an ExpressRoute gateway, and you’ve provisioned an ExpressRoute circuit with a chosen provider, bandwidth, and peering location.
Structurally, everything is in place.
But one fundamental question still hasn’t been answered:
What kind of traffic are we actually going to send over this private connection?
That is the role of ExpressRoute peering.
Peering isn’t about fibre, cables, or physical connectivity. It’s about rules.
It defines what traffic is allowed to flow across the circuit once the physical connection exists.
What Peering Means in Plain English
Peering is how you tell Microsoft and Azure how this private connection should behave.
It defines which IP addresses are allowed to communicate, what type of traffic is permitted, which Azure services can be reached, and how routes are exchanged between your on-premises network and Microsoft’s network.
Until peering is configured, an ExpressRoute circuit is effectively unusable. It’s like building a private road but never deciding who’s allowed to drive on it, in which direction, or at what speed.
Microsoft offers two peering models because there are two very different use cases for ExpressRoute traffic.
Private Peering: Making Azure Part of Your Private Network
Private peering is what most people are referring to when they talk about ExpressRoute.
In simple terms, private peering tells Azure:
“Treat my Azure virtual networks as an extension of my internal network.”
With private peering in place, Azure resources use private IP addresses, just like systems in your datacentre.
Routes are exchanged dynamically between environments, and traffic never traverses the public internet at any point.
This is the model used to connect virtual machines, internal applications, databases, and line-of-business systems.
From a networking perspective, it feels very similar to plugging a remote site into your existing LAN.
There is one critical rule to understand: private peering cannot access public IP addresses.
If a resource is exposed via a public endpoint, private peering will not use it. Everything must live in private address space, and address ranges must not overlap with your on-premises network.
Microsoft Peering: Private Access to Public Microsoft Services
Microsoft peering exists for a different reason entirely. Instead of extending your private network into Azure, it answers this question:
“How do I reach Microsoft’s public services privately?”
Microsoft peering allows access to services such as Microsoft 365, Dynamics 365, and certain Azure PaaS services.
The important distinction is that traffic still uses public IP addresses, but it travels across Microsoft’s private backbone rather than the open internet.
This is often where confusion arises. The IP addresses are public, but the path is private.
Traffic doesn’t traverse the internet, but it also doesn’t provide the same network isolation as private peering.
Microsoft peering is about predictable performance and controlled routing to Microsoft services, not about extending your private network.
Why You Have to Choose a Peering Model
Private peering and Microsoft peering solve different problems and follow different rules. You don’t choose between them based on performance alone, you choose based on what you are trying to reach.
If the goal is to connect networks to networks, private peering is the correct choice. If the goal is to access Microsoft SaaS and public-facing platform services privately, Microsoft peering is the right option.
In real-world deployments, many organisations use both. They are configured independently and managed separately, even though they use the same ExpressRoute circuit.
Peering Location: Where the Physical World Meets Azure
Peering also forces you to think about physical reality.
A peering location is a real, physical colocation facility where Microsoft’s edge routers are installed and where connectivity providers attach their fibre.
This is why the peering location is not the same thing as an Azure region.
In practice, peering locations are chosen based on proximity to your datacentre or office locations, the availability of network service providers, expected bandwidth requirements, and cost.
Azure itself doesn’t care where your datacentre is, but latency, operational complexity, and pricing certainly do.
What Actually Changes After Peering Is Configured
Once peering is configured, Azure knows which routes it’s allowed to exchange and what type of traffic the circuit is meant to carry.
From Microsoft’s perspective, the circuit is now logically usable.
However, there is still one final dependency.
The connectivity provider must physically complete the connection using the service key that was generated when the circuit was created.
- Peering defines the rules.
- The provider builds the road.
Only when both are in place does traffic actually flow.
Visualising the Big Picture
At this point in the journey, Azure has a gateway ready, Microsoft has reserved circuit capacity, peering defines what traffic is allowed, and the provider completes the physical connection.
Everything is aligned for ExpressRoute to function as intended.
Where This Fits in the Overall Journey
This step represents the final logical configuration before ExpressRoute becomes fully operational.
So far, the journey has looked like this:
You started by understanding why ExpressRoute exists. You then prepared Azure with an ExpressRoute gateway, reserved a private connection by creating a circuit, and finally defined what traffic is allowed by configuring peering.
The next topic builds directly on this foundation:
Designing ExpressRoute for resiliency.
That’s where multiple circuits, redundancy, failure scenarios, and real production-grade design considerations come into play and where ExpressRoute stops being a lab exercise and starts looking like something you’d confidently deploy in a real enterprise environment.