Skip to main content
When designing an Azure ExpressRoute deployment, one of the first decisions is whether to enable private peering only, Microsoft peering only, or both. This choice controls which Microsoft services and endpoints your on‑premises network can reach over the dedicated ExpressRoute circuit and how traffic is routed off the public internet. For more on ExpressRoute fundamentals and connectivity options, see Azure ExpressRoute documentation.

​
What each peering provides

  • Private peering
    • Purpose: Extends your on‑premises network into Azure virtual networks using private IP address space.
    • Typical uses: Infrastructure-as-a-Service (IaaS) such as VMs, managed databases using private endpoints, internal APIs, file shares, hybrid applications, backup, and disaster recovery.
    • Benefits: Low-latency, high-performance private connectivity to VNets; treats Azure as an extension of your datacenter.
  • Microsoft peering
    • Purpose: Provides private connectivity to Microsoft public services and SaaS/PaaS endpoints that are accessed by public IP addresses.
    • Typical uses: Microsoft 365 (Exchange Online, Teams), Dynamics 365, and Azure services with public endpoints (for example, Azure SQL Database public endpoints).
    • Benefits: Keeps SaaS and public-endpoint traffic off the public internet while reaching globally distributed Microsoft services via the Microsoft Edge network—improving performance, compliance posture, and reliability.
  • Both peerings
    • Purpose: Combine the capabilities of private peering (private VNet access) and Microsoft peering (private access to Microsoft SaaS/PaaS).
    • Typical use case: Enterprises that need secure VNet connectivity plus private SaaS connectivity; you can configure and manage routes and advertised services independently for each peering.
Think of this as a layered architecture.
A network diagram showing Azure ExpressRoute connecting a customer's network (via a partner edge) to Microsoft Edge with primary and secondary circuits. It highlights Microsoft Peering for Office 365 and Azure Private Peering for virtual networks.
Blue indicates private peering for your infrastructure and custom workloads.
Red indicates Microsoft peering for cloud productivity tools and managed platforms.

​
Decision factors: when to choose which option

  • Private peering only
    • Choose this when your primary requirement is to extend private network services to Azure (VNets, internal management and monitoring, hybrid apps, backup/DR) and you do not need private connectivity to Microsoft SaaS services.
  • Microsoft peering only
    • Choose this when your focus is on routing user or application traffic to Microsoft-managed public services (for example, Microsoft 365) privately and you do not need VNet-level private connectivity.
  • Both private and Microsoft peering
    • Choose both when you need private connectivity to VNets and you also want SaaS/PaaS traffic to bypass the public internet. Enabling both allows independent routing and advertising policies per peering.

​
Quick comparison

Peering typePrimary purposeTypical examples
Private peeringPrivate connectivity to Azure VNets and IaaSVMs, internal services, backup/DR, private APIs
Microsoft peeringPrivate connectivity to Microsoft public services and SaaSMicrosoft 365, Dynamics 365, Azure public endpoints
BothCombined private VNet access and private SaaS/PaaS accessHybrid apps with internal and SaaS dependencies
Quick checklist:
  • Use private peering for VNet resources and private IP addressing.
  • Use Microsoft peering for Microsoft-managed public services and SaaS accessed via public IPs.
  • Use both when you need secure connectivity to VNets and private access to Microsoft SaaS/PaaS.

​
Operational considerations

  • Routing and security: Private and Microsoft peering are configured separately; you control which prefixes are advertised and which routes are accepted for each peering. Align route filters and BGP policies with your security and compliance requirements.
  • Compliance and performance: Microsoft peering helps keep SaaS traffic off the public internet for compliance or performance reasons. Private peering provides the predictable performance needed for infrastructure workloads.
  • Management: Monitor BGP sessions and circuit health for both peerings. Use ExpressRoute redundancy (primary/secondary) and partner resiliency patterns to meet SLAs.
In summary: private peering = Azure VNets, private IP addressing, and infrastructure. Microsoft peering = Microsoft public services, SaaS/PaaS, and public IPs. Choose the peering configuration that aligns with your application architecture, security posture, and how your organization consumes Microsoft cloud services. Further reading:

Watch Video