In the previous part of this series, we decided why an organisation needs ExpressRoute and what kind of ExpressRoute makes sense.
At this point, nothing has been deployed yet, we’ve only made design decisions.
This next step is where we start preparing Azure itself.
Before Azure can connect to anything on-premises, it needs a dedicated component that knows how to handle private connectivity.
That component is the ExpressRoute gateway.
Why a Gateway Is Needed
An Azure virtual network on its own can’t talk to ExpressRoute. It doesn’t understand private circuits, routing exchanges, or how traffic should flow to and from an on-premises network.
The gateway is what makes this possible.
You can think of it as the front door of the virtual network for private connectivity.
All ExpressRoute traffic enters and leaves Azure through this gateway. Without it, there is simply nowhere for the ExpressRoute connection to terminate.
So before we think about circuits, providers, or physical links, we first need to prepare the Azure side properly.
Creating a Virtual Network That Can Support ExpressRoute
The first thing we need is a virtual network that will eventually be reachable from on-premises.
In the Microsoft Learn exercise, this is called Core Services VNet and lives in the East US region.
At this stage, the virtual network doesn’t need workloads or applications.
Its main purpose is to exist as a target for private connectivity. The important part is that it has enough address space and is designed with connectivity in mind, not just workloads.
The Gateway Subnet: A Required Building Block
Azure requires all gateways to live in a special subnet called GatewaySubnet. This subnet is not optional, and the name must be exactly that.
The GatewaySubnet exists purely for the gateway itself. You don’t deploy virtual machines into it, and you don’t share it with other services. Azure uses this space to manage the gateway infrastructure behind the scenes.
In this exercise, the GatewaySubnet is sized as /27, which gives Azure enough room to handle scaling and redundancy.
This is an important design detail, gateways need space, and undersizing this subnet can cause problems later.
By creating this subnet, we’re signalling that this virtual network is intentionally designed for enterprise connectivity.
Creating the ExpressRoute Gateway
Once the virtual network and GatewaySubnet exist, we can create the virtual network gateway.
This is the actual resource that enables ExpressRoute.
When creating the gateway, the most important choice is the gateway type.
Azure supports different gateway types for different kinds of connectivity. In this case, we explicitly choose ExpressRoute.
That choice tells Azure one simple thing:
This gateway is for private connectivity over ExpressRoute, not VPN traffic over the public internet.
It’s also worth knowing that Azure only allows one ExpressRoute gateway per virtual network, which is why this step is deliberate and intentional.
The gateway is deployed into the same region as the virtual network and takes some time to provision.
That long deployment time reflects the fact that this is managed, highly available infrastructure being created on your behalf.
What We Have at the End of This Step
By the time this exercise is complete, nothing is connected to on-premises yet, and that’s expected.
What we’ve done is prepare Azure so that it can accept an ExpressRoute connection when the time comes.
We now have:
- A virtual network designed for private connectivity
- A dedicated GatewaySubnet
- An ExpressRoute virtual network gateway ready to terminate a circuit
In other words, Azure is now ready and waiting.
Note: If you would like the Azure Side preparation in Terraform it’s HERE.