Start with the big picture: what you get, who provides it, and what makes it different from an ordinary internet connection.

ExpressRoute is a service that lets you create private connections between your on-premises network and Microsoft cloud services. The word on-premises simply means the computers and networks that sit in your own buildings, such as an office, a factory, or a rented data center, as opposed to computers that live in the cloud. A private connection means your data does not travel across the public internet. It travels across a line that is set aside for you, supplied by a connectivity provider, which is a telecommunications company such as Equinix, Megaport, AT&T, or Verizon that runs the physical cables and hands the connection over to Microsoft.

The connection typically offers more reliability, faster and more consistent speeds, and lower delays than ordinary internet links. Three words are worth defining right away. Bandwidth is how much data can flow per second, like the width of a pipe. Latency is how long a single message takes to travel from one end to the other, like the time a car takes to drive the road. Jitter is how much that travel time varies from one message to the next. The public internet can swing widely on all three. A private line is far steadier.

A short history

In the early days of cloud computing, companies reached the cloud over the internet, often through encrypted tunnels. That was fine for small workloads. But large businesses wanted to move databases, backups, and entire applications to the cloud, and they needed predictable speed and service guarantees, just like the leased lines they already used between their own offices. Microsoft launched ExpressRoute in 2013 to meet that need, partnering with telecommunications companies so that customers could reach Azure through connections they already trusted. Since then the service has grown with higher speeds, a direct-to-Microsoft option for very large customers, link encryption, a feature that joins your own sites together through Microsoft’s network, and many more meeting points around the world.

Every tool exists because something hurt. Here is the pain that ExpressRoute removes.

Suppose a bank wants to run its customer account system partly in Azure and partly in its own data center. The two halves must talk to each other all day long, sending small requests thousands of times per second and large files once per night. If that traffic uses the public internet, several things can go wrong.

First, unpredictable speed. Internet routes change, and a message may take a longer path at some times than at others. Applications that make many small round trips, such as a program that asks a database a hundred questions to build a single page, feel every extra millisecond. Second, shared risk. Congestion, outages at other companies, and attacks aimed at someone else can still slow down your traffic. Third, exposure. Even with encryption, traffic that crosses the open internet passes through many networks owned by strangers, and some regulators and security teams simply do not accept that for sensitive data. Fourth, cost at scale. Moving hundreds of terabytes over the internet is slow and, with encryption overhead, harder to tune.

The usual alternative, a VPN, or virtual private network, builds an encrypted tunnel across the internet. A VPN is simple, cheap, and good for many cases. But the tunnel still rides on the internet, so it inherits the same swings in speed and the same shared risk. When your needs outgrow it, you need something dedicated.

ExpressRoute has its own small vocabulary. Learn these six words and every diagram will make sense.

The central object is the ExpressRoute circuit. A circuit is the logical connection between your network and Microsoft. It is called logical because it is an Azure resource you create in the portal and configure, while the physical wires underneath are handled by the provider. When you create a circuit you choose a provider, a peering location, a bandwidth, and a SKU (the edition, which we will cover in a later chapter).

A peering location, sometimes called a meet-me location, is a real building, usually a large data center, where Microsoft has network equipment and where providers and customers can plug in. Think of it as a train station where your private railway meets Microsoft’s network. It is not the same as an Azure region. An Azure region is where your virtual machines and databases run. The peering location is only where the connection enters Microsoft’s network. From there, Microsoft’s own private backbone carries traffic to the right region.

When you create a circuit, Azure gives you a service key, a long code that works like a ticket number. You hand the key to your provider, and the provider uses it to connect your line to your circuit. The circuit reports a provider status that moves from not provisioned, to provisioning, to provisioned. Only when it says provisioned is the line ready for configuration.

Inside Microsoft’s building sit special routers called Microsoft Enterprise Edge routers, or MSEEs. Every circuit connects to two of them, a primary and a secondary, so that if one fails the other keeps working. Your side has its own routers, called customer edge routers or CE routers.

Now let us walk the road from your building to your virtual machine in Azure, stopping at every checkpoint.

A complete ExpressRoute setup has pieces on three sides. On your side are your on-premises network and your customer edge routers. In the middle is the provider’s network and the peering location where the cables meet Microsoft. On Microsoft’s side are the MSEE routers, Microsoft’s private backbone, and finally your virtual network, shortened to VNet, which is your own private network inside Azure.

One more piece is needed to get into the virtual network. An ExpressRoute virtual network gateway is a managed Azure component that sits inside a special slice of your VNet named the gateway subnet. A subnet is a smaller piece of a network. The gateway is the doorman at your VNet’s entrance: it accepts traffic coming from the circuit and delivers it to your virtual machines, and it also sends their replies back out. The link between the circuit and the gateway is called a connection.

flowchart LR
    ONP["On-premises network"] --> CE["Customer edge routers"]
    CE -->|"Provider line"| PROV["Provider network"]
    PROV --> LOC["Peering location"]
    LOC --> MSEE1["Microsoft edge router - primary"]
    LOC --> MSEE2["Microsoft edge router - secondary"]
    MSEE1 --> BB["Microsoft backbone"]
    MSEE2 --> BB
    BB --> GW["ExpressRoute gateway"]
    GW --> VNET["Virtual network"]
    VNET --> VM["Virtual machines and services"]
    

Read the diagram from left to right. A packet leaves your office network, reaches your edge router, and travels over the provider’s line to the peering location. There it enters one of two Microsoft routers. Microsoft’s own backbone, a private global network, carries the packet to the Azure region where your virtual network lives. The gateway there accepts it and hands it to the destination virtual machine. The reply takes the same road in reverse.

There is more than one way to physically reach Microsoft. Which one you can use depends on where you are and who your provider is.

Microsoft describes several connectivity models. Each is a different way for the line to get from your site to the peering location.

The first three are provider-based, which means a connectivity provider sits in the middle and sells you the circuit. The fourth, ExpressRoute Direct, removes the middle step. You rent whole ports on Microsoft’s routers, available at high speeds such as ten or one hundred gigabits per second, and then you carve those ports into one or more circuits yourself. It also unlocks features such as encryption at the link layer, which we will meet in the security chapter.

Circuits come in sizes and editions. Choosing well keeps both performance and cost under control.

For provider-based circuits, bandwidth is picked from a menu that begins at fifty megabits per second and rises through several steps to ten gigabits per second. Larger bandwidths cost more. A useful fact is that you can increase a circuit’s bandwidth later without tearing it down, but decreasing it generally means building a new circuit. For ExpressRoute Direct, the ceiling is the size of your ports, and you divide it among circuits.

The SKU is the edition of the circuit, and there are three. The Local SKU lets you reach only the Azure regions in or near the same metropolitan area as the peering location. The Standard SKU lets you reach all Azure regions inside the same geopolitical area, such as all of Europe or all of North America. The Premium SKU is a global edition: it lets one circuit reach Azure regions around the world, supports more routes and more virtual network links, and is the usual choice for global companies.

Metered and unlimited data

For Standard and Premium circuits you choose how data leaving Azure is billed. With a metered plan you pay a lower monthly circuit fee plus a charge for each gigabyte that flows out of Azure toward your network. Data flowing into Azure is not charged. With an unlimited plan the circuit fee is higher but all outbound data is included. If you move a lot of data, unlimited usually becomes cheaper beyond a break-even point. If traffic is light, metered saves money.

A circuit is only a pipe. Peerings decide what kind of traffic is allowed to flow through it.

The word peering means two networks agreeing to exchange routes and traffic. An ExpressRoute circuit can carry more than one peering, each serving a different purpose. Each peering is a separate routing relationship with its own set of addresses.

Azure private peering

Azure private peering connects your on-premises network to your own virtual networks in Azure, using their private IP addresses. Private addresses are the ones used inside company networks, such as those beginning with 10, and they are not reachable from the internet. With private peering your virtual machines look like part of your own network, so you can reach them without public addresses. This is by far the most common peering and the foundation for hybrid designs.

Microsoft peering

Microsoft peering connects your network to Microsoft’s public-facing services, which are reached by public IP addresses. This covers Azure services that live on public addresses, such as storage endpoints, and certain Microsoft online services. You need your own public addresses for network address translation on your side, and you use a route filter, a list that picks exactly which Microsoft services you want to receive routes for. Some Microsoft services follow special rules and approvals for use over ExpressRoute, so check Microsoft’s current guidance before planning around them.

An older third option called Azure public peering has been retired. Its job is now done by private endpoints, which place a private address for a service inside your own virtual network, or by Microsoft peering with route filters.

flowchart TB
    ONP["On-premises network"] --> CIR["ExpressRoute circuit"]
    CIR --> PRIV["Private peering"]
    CIR --> MS["Microsoft peering"]
    PRIV --> VN["Your virtual networks - private IPs"]
    MS --> PUB["Microsoft public services - public IPs"]
    

A private road is useless if no one knows which towns are at the end of it. Routing is how the two sides learn that.

Routers find their way using a shared language called BGP, the Border Gateway Protocol. It is the same language the whole internet uses. In BGP, each side announces, “I can reach these addresses,” and the other side remembers which doorway leads where. A router that learns the same address from two places picks the better one using rules such as the shortest path. ExpressRoute requires BGP between your edge routers and Microsoft’s. Static routes are not used on the circuit itself.

Every network that speaks BGP has an identifier called an autonomous system number, or ASN. Microsoft uses the ASN 12076 for ExpressRoute. You use your own ASN, which may be a private one or a public one. When you set up a peering you also provide a VLAN ID, a tag that separates this peering’s traffic from others on the same physical wire, and a pair of small address blocks called /30 subnets, one for the primary link and one for the secondary link, which give the two ends of each link their own addresses. A BGP session runs over each link, so there are two sessions per peering, one with each Microsoft router.

Choosing between two paths

When you have two circuits or an ExpressRoute plus a VPN, the network may learn the same destination from both. You steer it with BGP tools. AS path prepending makes a path look longer by repeating your ASN, so it becomes less attractive. Longer prefixes win: a route for a small address range beats a route for a large one that includes it. On Azure’s side, a connection weight lets you prefer one circuit over another for traffic leaving a virtual network.

The circuit gets you to Microsoft. The gateway gets you into your own network.

As you saw earlier, an ExpressRoute virtual network gateway sits in a dedicated gateway subnet inside your virtual network. You do not manage servers for it. Azure runs it as a pair of managed instances, and you pick a gateway SKU that decides how much traffic it can handle. Smaller SKUs handle around one gigabit per second, middle ones around two, and the largest ones around ten gigabits per second. Newer zone-redundant versions spread the instances across availability zones, which are physically separate buildings within a region, so the loss of one building does not take the gateway down. A scalable option also exists in which the gateway adds or removes capacity units to match demand.

To use the gateway you create a connection that links it to a circuit. If the circuit belongs to a different Azure subscription, the circuit’s owner creates an authorization, which works like a signed permission slip, and the gateway’s owner uses it to make the link. A single circuit can connect to several virtual networks, and one virtual network can connect to more than one circuit, up to limits that depend on the SKU.

FastPath

Normally every packet from your network to a virtual machine passes through the gateway, which inspects and forwards it. That is one extra step. FastPath is a feature that lets the data skip the gateway and flow directly from the Microsoft routers to the virtual machine. Because the gateway is no longer in the data path, you get lower latency and higher packets per second, especially valuable for very busy workloads such as trading systems or large databases. The gateway is still needed to exchange routes, but the actual data does not go through it. FastPath needs the faster gateway SKUs and has some limits on which features work with it, so check the current list of supported scenarios before relying on it.

flowchart LR
    MSEE["Microsoft edge router"] -->|"Normal path"| GW["ExpressRoute gateway"]
    GW --> VM1["Virtual machine"]
    MSEE -->|"FastPath - bypasses gateway"| VM1
    GW -.->|"Still exchanges routes"| MSEE
    

What actually happens, step by step, when an on-premises program talks to an Azure virtual machine?

Suppose an application server in your office sends a request to a database server in Azure at the private address 10.1.0.4. First, your server checks its routing table. It does not own that address, so it sends the packet to its default gateway, a nearby router inside your network. Your internal routers have learned, through your own routing, that traffic for the Azure address range should go to the customer edge router. That router, in turn, has learned through BGP from Microsoft that the Azure range is reachable through the two Microsoft edge routers.

The edge router sends the packet over the provider line to the peering location. Along the way, the provider treats it as ordinary Ethernet frames carrying your VLAN tag. At the peering location, the packet enters one of the Microsoft routers. Both routers can accept traffic, since the pair works in an active-active way, meaning both are working at the same time rather than one waiting idle as a spare. Microsoft’s router sends the packet across the private backbone to the Azure region that holds the destination virtual network. There the gateway, or the direct FastPath route, delivers it to the database server. The reply comes back along the same logical route.

sequenceDiagram
    participant App as Office server
    participant CE as Customer edge router
    participant MS as Microsoft edge router
    participant GW as ExpressRoute gateway
    participant DB as Azure database VM
    App->>CE: Packet for 10.1.0.4
    CE->>MS: Forward over provider line using BGP route
    MS->>GW: Carry across Microsoft backbone
    GW->>DB: Deliver inside virtual network
    DB-->>App: Reply returns by the reverse route
    

Active-active redundancy inside every circuit

Remember that a circuit always has two links to two different Microsoft routers. Your edge routers should establish a BGP session on each and use both at the same time. If one link or one Microsoft router fails, traffic shifts to the other in moments. A feature called BFD, bidirectional forwarding detection, helps both sides notice a broken link in a fraction of a second, instead of waiting for slower timers.

A clever extra: use Microsoft’s network to link your own offices to each other.

Suppose you have an office in London with its own ExpressRoute circuit and another in Singapore with a different circuit. Both already connect to Microsoft. Normally traffic between London and Singapore would use your own expensive wide area links. With Global Reach, you tell Azure to connect the two circuits to each other. Your London and Singapore networks can then exchange traffic across Microsoft’s private global backbone, with no extra provider contract between those two sites.

It is useful for joining data centers, for disaster recovery between two sites, and for reaching an acquired company’s network. Global Reach is available only in selected countries and regions, and only for private peering. Because traffic crosses Microsoft’s backbone, you also pay a Global Reach add-on fee and normal data charges that depend on the zones the traffic crosses.

flowchart LR
    LON["London office"] --> C1["ExpressRoute circuit 1"]
    SIN["Singapore office"] --> C2["ExpressRoute circuit 2"]
    C1 |"Global Reach"| C2
    C1 --> AZ["Azure virtual networks"]
    C2 --> AZ
    

A single circuit can fail in ways that its two internal links cannot cover. Plan for the bigger failures too.

The 99.95 percent availability figure applies to the circuit’s connection to Microsoft, but your real uptime depends on your whole design. Several things can fail outside that promise: the provider’s cable can be cut by a construction crew, your own edge router can break, or the whole peering location can lose power. Microsoft’s guidance describes three levels of resiliency.

flowchart TB
    DC1["Data center A"] --> CA["Circuit A - provider 1"]
    DC2["Data center B"] --> CB["Circuit B - provider 2"]
    CA --> LA["Peering location - metro 1"]
    CB --> LB["Peering location - metro 2"]
    LA --> AZ["Azure region"]
    LB --> AZ
    

Failure scenarios and recovery

The internet is not your enemy. It makes a fine backup road.

A site-to-site VPN is an encrypted tunnel from your network to an Azure VPN gateway across the internet. It can run side by side with ExpressRoute in the same virtual network, which Microsoft calls coexistence. The usual pattern is to use ExpressRoute as the main path and the VPN as a standby. When the circuit fails, traffic automatically falls back to the VPN. The fallback is slower and less steady, but your applications stay reachable.

For this to work, the network needs to prefer ExpressRoute when both are up. Azure prefers routes learned from ExpressRoute over routes learned from a VPN for the same address range, as long as the prefixes are equal. If your VPN advertises a more specific, longer prefix, it would win instead and quietly steal traffic, so keep the prefixes the same or less specific on the VPN side.

Private does not automatically mean encrypted. Here is how to think about protection.

A common misunderstanding is that ExpressRoute encrypts your data. It does not, by default. The line is private, meaning not shared with the public internet, but the data on it is carried as normal network traffic that your provider could in theory observe. For many companies this level of privacy is enough. For others, regulation or policy demands encryption too. You have several choices, and you can combine them.

Beyond encryption, think about who can reach what. Traffic arriving from ExpressRoute lands inside your virtual network, so it is subject to the same controls as any other internal traffic. Use network security groups, which are rule lists that allow or deny traffic at subnets and machine network cards, and place an Azure Firewall or a partner firewall appliance in a central hub network to inspect traffic between your office and Azure. Use private endpoints so that Azure services such as storage and databases get a private address inside your network, reachable across private peering without ever touching a public address.

At the management level, role based access control decides who can create, change, or delete circuits, gateways, and connections. Deleting a connection or advertising the wrong route can cut your entire hybrid network, so protect these with tight roles and resource locks.

Where you place the gateway shapes how the whole cloud network behaves.

Most companies organize their Azure networks in a hub and spoke pattern. A central hub virtual network holds shared services: the ExpressRoute gateway, a firewall, and management tools. Many spoke virtual networks hold the actual workloads, one for each application or team. VNet peering, a feature that joins two virtual networks so they behave as one for traffic purposes, links each spoke to the hub. The result is that one ExpressRoute gateway and one circuit serve every spoke, and all traffic can be inspected at the hub.

flowchart TB
    OFF["Office and data center"] --> ERC["ExpressRoute circuit"]
    ERC --> HUBGW["ExpressRoute gateway in hub network"]
    HUBGW --> FW["Firewall in hub"]
    FW --> S1["Spoke - application A"]
    FW --> S2["Spoke - application B"]
    FW --> S3["Spoke - data platform"]
    

For companies with many sites and regions, Azure Virtual WAN offers a managed version of this idea. Microsoft runs the hubs, including ExpressRoute gateways, VPN gateways, and routing, and you attach circuits, branches, and virtual networks to them. This takes away much of the manual route management. It suits large and growing networks, while a hand-built hub and spoke gives more control for smaller or highly customized ones.

You cannot manage what you cannot see. Azure shows you the health of every part of the road.

The main tool is Azure Monitor, the central place for numbers, charts, and alerts in Azure. A metric is a measurement taken over time. ExpressRoute publishes metrics for the circuit, for each peering, and for the gateway. A few matter most. ARP availability shows whether the basic link-level handshake with each Microsoft router is working. BGP availability shows whether the routing sessions are up. Bits in per second and bits out per second show how full the pipe is. Dropped bits reveal when traffic is being lost, often a sign of saturation. On the gateway, CPU utilization, the number of routes learned and advertised, and the packets per second show whether it is coping.

A topology view in Azure’s network insights draws a live map of circuits, connections, gateways, and virtual networks, and colors parts that are unhealthy. Connection Monitor in Network Watcher actively sends test traffic between your on-premises machines and Azure machines, measuring real latency and loss along the path. ExpressRoute Traffic Collector can sample the flows on an ExpressRoute Direct circuit and send them to a Log Analytics workspace, a searchable store, so you can see which applications use the bandwidth.

Understanding the order of events helps you plan the calendar, because some steps depend on people outside your company.

Setting up ExpressRoute is part cloud work and part physical-world work. The cloud steps take minutes, but the provider’s cable and equipment steps can take days or weeks, so start early. A typical sequence looks like this.

ExpressRoute is a premium service. Knowing how the bill is built is the best way to keep it friendly.

The bill has several parts. The first is the circuit fee, a monthly charge that depends on bandwidth and SKU. The second is the data charge: with a metered plan you pay per gigabyte leaving Azure, while an unlimited plan includes it. The third is the gateway, billed by the hour according to its size. Fourth come the provider’s own charges for the line itself, which are separate from the Azure invoice and can be a large share of the total. Optional extras include Global Reach, ExpressRoute Direct ports, and premium add-ons. Data coming into Azure is generally free.

No tool is right for everything. A fair look at both sides helps you choose with open eyes.

The big trade-offs

Cost versus predictability. You pay more to get steadier performance, so the question is whether your workloads genuinely need it. Simplicity versus resilience. One circuit is simple but fragile, while two circuits in two metros is strong but more expensive and complex. Privacy versus encryption. A private line is not an encrypted line, so strong security needs extra layers that may cost some speed. Control versus convenience. A hand-built hub and spoke lets you control every route, while Virtual WAN takes over most of the work but hides some details.

A pattern is a proven recipe. These recipes appear again and again in healthy ExpressRoute designs.

Choosing among connection options

An anti-pattern is a habit that looks sensible but leads to pain. Learn these now so you do not learn them in an outage.

A short checklist that separates calm operations from late-night emergencies.

Common mistakes

• Paying for a circuit that is not provisioned. Billing may start before the provider finishes the line.
• Forgetting the gateway limits. The circuit is large, but the gateway is small, and it limits speed.
• Misconfigured VLAN or address blocks. Mismatches between your router and the Azure peering keep BGP from coming up.
• Letting a VPN prefix win. A more specific route over the VPN can silently draw traffic away from ExpressRoute.
• Ignoring DNS. Names for Azure services and on-premises systems must resolve across the connection, or applications fail even though the network works.
• Assuming ExpressRoute speeds up internet access. It does not. It only improves the path to Microsoft’s network.

Where does ExpressRoute actually shine? These are the jobs it is most often chosen for.

No. A VPN builds an encrypted tunnel across the public internet. ExpressRoute uses a private connection through a provider and does not cross the public internet, though it is not encrypted by default.

Not by default. You can add TLS in your applications, MACsec on ExpressRoute Direct ports, or IPsec tunnels over the circuit.

A circuit is the logical connection to Microsoft. A peering is a routing relationship on that circuit, such as private peering for virtual networks or Microsoft peering for public Microsoft services.

So that if one link or one Microsoft router fails, the other keeps traffic flowing. You should connect and use both.

BGP. Static routes are not used on the circuit itself, and you run a BGP session on each of the two links.

No. The peering location is the building where your line meets Microsoft’s network. The region is where your Azure resources run. Microsoft’s backbone carries traffic from one to the other.

Yes. Local reaches nearby regions, Standard reaches the whole geopolitical area, and Premium reaches regions around the world.

Data coming into Azure is generally free. Data leaving Azure is charged on a metered plan and included in an unlimited plan.

A feature that lets traffic skip the gateway and flow directly to virtual machines, lowering latency and raising performance for demanding workloads.

A feature that connects two of your ExpressRoute circuits together so that your on-premises sites can exchange traffic through Microsoft’s backbone.

Yes. ExpressRoute and a site-to-site VPN can coexist, with ExpressRoute preferred and the VPN taking over if the circuit fails. Test it for asymmetric routing.

No. It improves the private path between your network and Microsoft’s cloud, not general internet access.