Up to this point in the ExpressRoute journey, everything we’ve built has lived entirely inside Azure.
- We created a virtual network.
- We added a GatewaySubnet.
- We deployed an ExpressRoute gateway.
That prepared Azure to accept a private connection, but there still isn’t one.
This next step is where the private connection itself comes into existence.
That’s exactly what an ExpressRoute circuit is.
What an ExpressRoute Circuit Really Is
An ExpressRoute circuit is best thought of as a reserved private connection between an organisation and Microsoft’s network.
At this stage, it is not connected to your on-premises environment yet. Instead, you are doing three important things:
- Reserving capacity on Microsoft’s side
- Defining where you will physically connect to Microsoft
- Creating a hand-off point for your connectivity provider
Once the circuit exists, Microsoft generates something called a service key. That key is what allows your connectivity provider (for example, Equinix) to complete the physical provisioning on their side.
Until that happens, the circuit exists, but it’s not active.
Why This Is a Separate Step from the Gateway
It’s important to understand that the gateway and the circuit are two different concerns:
- The gateway lives inside your Azure virtual network
- The circuit represents the private link outside Azure, at the edge of Microsoft’s network
- You can build either one without the other, but nothing flows until both exist and are linked.
This separation is deliberate. It allows organisations to:
- Design Azure first
- Coordinate with providers later
- Avoid blocking cloud work while waiting on physical provisioning
Choosing Where and How to Connect
When creating the circuit, you are making some very real-world decisions.
In this exercise, the circuit is created in East US 2, but the peering location is Seattle. That might look odd at first, but it highlights an important concept:
The Azure region where the circuit resource lives is not the same thing as the physical location where you connect to Microsoft.
The peering location is the physical building where your provider connects into Microsoft’s network. In the real world, this is driven by:
- Where your data centre is
- Which provider you use
- Where they have available capacity
Microsoft recommends choosing a network resource provider geographically close to the peering location, not because Azure requires it, but because it makes operational and latency sense.
Provider, Bandwidth, and SKU (In Plain Terms)
When we create the circuit, we also lock in some commercial and technical characteristics.
The provider (Equinix in this case) is the company that will physically deliver the connection.
- The bandwidth (50 Mbps here) represents how much capacity we are reserving on Microsoft’s side. In a real environment, this would be sized based on traffic patterns and business criticality.
- The SKU (Local, Standard, or Premium) determines how broadly this circuit can reach Azure regions. In this lab, we’re using Standard, which is the most common choice and aligns with a regional footprint.
- The billing model (Metered or Unlimited) controls how outbound data is charged. This can be changed later in one direction (Metered → Unlimited), but not the other, which is why this is a conscious design decision.
Once the circuit is created, billing begins immediately, because Microsoft has now reserved capacity for you.
The Service Key: The Handover Point
As soon as the circuit exists, Azure generates a service key.
This key is the most important output of this entire exercise.
The service key is:
- Unique to the circuit
- Required by the connectivity provider
- What allows the provider to complete provisioning
Until the provider uses that key, the circuit remains in a not provisioned state on their side.
From Azure’s perspective, the circuit is enabled and waiting.
Understanding Circuit Status (Without the Jargon)
There are two status values to care about:
- Provider status – what the connectivity provider is doing
- Circuit status – whether Azure has enabled the circuit
When you first create the circuit:
- Provider status: Not provisioned
- Circuit status: Enabled
When the provider starts work:
- Provider status: Provisioning
- Circuit status: Enabled
When everything is ready:
- Provider status: Provisioned
- Circuit status: Enabled
Only in that final state is the circuit actually usable.
Visual Overview: What We’ve Built So Far
At this point:
- Azure has a gateway waiting inside the virtual network
- Microsoft’s edge has a circuit reserved
- A provider has a service key to complete the physical connection
The final step — linking the circuit to the gateway, comes next.
If you want the terraform to create the Express Route circuit click HERE.