What Should You Use? ExpressRoute, Route Server, IPv6, and SNAT

These four technologies operate at different parts of a network. They are often mentioned together in enterprise designs, but they do not replace one another. Start with the problem, then choose the capability.

Problem	Technology	What it provides
A private, predictable path from an external network to Microsoft cloud services	ExpressRoute	Private provider connectivity into the Microsoft network
Routes must change dynamically between Azure and routing appliances	Azure Route Server with BGP	Managed exchange of network prefixes and next-hop information
Applications must communicate with IPv6 clients or networks	IPv6 dual stack	IPv4 and IPv6 addressing and reachability
Private backends need outbound Internet connections through a public Load Balancer	Load Balancer SNAT	Source translation and a finite pool of outbound ports

The first two concern hybrid connectivity and routing. IPv6 concerns the addressing protocol. SNAT concerns the identity and port capacity of outbound connections.

ExpressRoute: Solve Private Hybrid Connectivity

Problem: An organization needs to connect an on-premises network, colocation facility, or provider-managed WAN to Azure without sending that traffic across the public Internet.

ExpressRoute extends the external network into the Microsoft cloud through a connectivity provider or ExpressRoute Direct. The ExpressRoute circuit is the logical connection at a peering location. Azure private peering carries private IP routes between the external network and Azure VNets; an ExpressRoute virtual network gateway connects a VNet to the circuit.

Understand the Logical Parts

ExpressRoute is not one cable or one Azure resource. It is an end-to-end design made from several logical parts:

Part	What it does	Typical owner
Customer routers	Connect the organization’s LAN or WAN to the provider, exchange routes through BGP, and forward traffic toward ExpressRoute	Customer
Connectivity provider	Supplies the private connection from the customer location to an ExpressRoute peering location	Provider
Peering location	Physical facility where the connectivity provider hands the connection to Microsoft’s edge. It is normally not the location where the customer’s office connects to the provider, and it is not an Azure region. With ExpressRoute Direct, the customer connects directly to Microsoft at this location.	Provider and Microsoft
ExpressRoute circuit	Logical Azure connectivity resource representing the purchased bandwidth and connection at that peering location	Customer configuration, Microsoft service
Peering	Is configured on the ExpressRoute circuit and defines what the connection can reach. Azure private peering connects the customer network to private addresses in Azure VNets. Microsoft peering connects it to supported Microsoft services through their public addresses.	Customer and Microsoft
ExpressRoute gateway	Connects one or more Azure VNets to the circuit and transfers routes and traffic between them	Customer deployment in Azure
VNet connection	Logical association between the gateway and circuit	Customer configuration
Azure VNet and workloads	The private Azure address spaces that become reachable through Azure private peering	Customer

The customer-to-provider connection and the provider-to-Microsoft handoff are two different boundaries. The customer first connects to the connectivity provider at a customer site or provider access point. The provider then carries that traffic to the ExpressRoute peering location and hands it to Microsoft’s edge routers.

The circuit describes the private connectivity service, but it is not itself placed inside a VNet. It is an Azure resource that coordinates the provider connection, bandwidth, peering, and authorization. The private peering exchanges private routes over that circuit. The ExpressRoute gateway is the Azure-side bridge that attaches the circuit to a VNet. Without the provider path, BGP peering, gateway, and VNet connection working together, the circuit alone does not provide end-to-end reachability.

Peering is configured on the ExpressRoute circuit, normally after the connectivity provider has provisioned it. It is not configured on the VNet or ExpressRoute gateway. The circuit can have Azure private peering, Microsoft peering, or both when their requirements are met.

ExpressRoute uses BGP to exchange routes. It can offer more predictable latency, bandwidth, and availability than an Internet VPN, but private does not mean automatically encrypted. Encryption and traffic inspection remain separate design decisions.

Choose ExpressRoute when:

• private, sustained hybrid connectivity is a business requirement;
• predictable performance or higher bandwidth matters;
• many workloads need access to an established enterprise WAN;
• the organization can support a provider circuit, BGP, cost, and operational ownership.

Do not choose it merely to give one administrator private access to a VM. A site-to-site VPN, point-to-site VPN, Bastion, or Private Link may solve a smaller problem with less infrastructure.

Each circuit has redundant Microsoft-side connections, but one circuit at one peering location is not complete disaster recovery. End-to-end resilience must also account for customer routers, provider paths, gateways, peering locations, and possibly a second circuit or VPN backup.

Route Server and BGP: Solve Dynamic Route Exchange

Problem: Network virtual appliances (NVAs), VPN or ExpressRoute gateways, and Azure networks must learn changing routes without repeatedly maintaining large user-defined route tables.

A network virtual appliance (NVA) is networking software that runs as a virtual appliance in Azure. It performs a function that a physical network device might perform in a data center—for example, routing, firewalling, traffic inspection, or SD-WAN connectivity. SD-WAN connects locations such as offices, data centers, and Azure through centrally managed network paths. It can choose between available connections—for example, broadband, private WAN, or mobile links—according to availability and policy. NVAs are commonly supplied by network-security vendors through Azure Marketplace.

Every workload needs a route that answers: Where should I send a packet for this destination? In a static design, administrators write those answers in route tables. When networks or available paths change frequently, maintaining the answers manually becomes difficult.

BGP lets routers share those answers automatically. A router can announce, “Send traffic for this network prefix to me.” It can withdraw the announcement when the path is no longer available.

Basically, Azure Route Server is Azure’s managed BGP service. It is the managed exchange point for route information inside an Azure VNet. Its basic job is:

1. A BGP-capable NVA tells Route Server which networks the NVA can reach.
2. Route Server makes those learned routes available to Azure’s virtual network routing system.
3. Azure workloads can then select the NVA as the next hop for those destinations.
4. Route Server tells the NVA which Azure VNet prefixes are reachable in the other direction.
5. If an appliance or route becomes unavailable, BGP can withdraw that path and advertise another one.

Route Server can also exchange routes between BGP-capable NVAs and an ExpressRoute or VPN gateway. This helps the NVA learn external routes and the gateway learn paths through the NVA without duplicating every prefix in manual route tables.

Route Server is part of the control plane: it communicates where networks are and which paths are available. It is not part of the data plane used by the application packets. Route Server therefore does not inspect, filter, NAT, or forward application traffic. After Azure selects a route, the packet travels directly to the route’s next hop, such as the NVA or gateway.

Use Route Server when route changes must be learned dynamically or when BGP-capable appliances need to integrate with Azure routing. Use a normal route table when the topology is small, static, and a few explicit routes are easier to understand. Use Virtual WAN when the larger problem is a managed global transit architecture across many sites and regions.

IPv6: Solve Addressing and Reachability

Problem: IPv6-only or IPv6-preferred clients and networks must reach the application, or the organization needs an address plan that is not constrained by scarce IPv4 space.

Azure supports dual-stack VNets and subnets, allowing resources to use IPv4 and IPv6. In a dual-stack service, DNS can publish an A record for IPv4 and an AAAA record for IPv6. A capable client selects a usable protocol and connects to the corresponding endpoint.

Adding an IPv6 prefix alone does not make an application IPv6-ready. The entire path must support it:

• VNet and subnet address plans;
• NICs, application listeners, and backend services;
• public IP and load-balancing frontends and rules;
• NSGs, routes, firewalls, and inspection appliances;
• DNS AAAA records, monitoring, logging, and diagnostics.

Azure IPv6 subnets must use a /64 prefix. IPv6 is secure only when it has deliberate controls; an IPv4-only firewall rule does not automatically protect the IPv6 path. Service support is also uneven. For example, Azure Route Server, Virtual WAN, and Azure Firewall currently have important IPv6 limitations. Validate every component rather than assuming that IPv4 support implies IPv6 support.

Use dual stack when both existing IPv4 consumers and IPv6 networks must be served. It is usually a safer migration path than IPv6-only operation, which is not supported by every Azure workload or service.

Load Balancer SNAT: Solve Outbound Identity and Port Sharing

Problem: Private backend instances behind a public Azure Load Balancer need to initiate connections to the Internet, and the destination must see a public source address.

NAT means Network Address Translation. It is the general technique of changing IP address information as traffic crosses between networks. SNAT and DNAT are two forms of NAT:

Translation	What changes	Typical direction	Problem solved
SNAT—Source NAT	Source IP address and usually source port	Outbound	Lets a private workload initiate a connection using a public source address
DNAT—Destination NAT	Destination IP address and usually destination port	Inbound	Sends traffic arriving at a public address to a private destination

Therefore, NAT is the broad concept and SNAT is one specific type of NAT. Azure NAT Gateway uses SNAT to provide outbound connections for a subnet. Azure Load Balancer can use SNAT to provide outbound connections for its backend pool. An inbound Load Balancer rule instead changes the destination of an incoming flow.

Source Network Address Translation (SNAT) replaces a backend’s private source IP and port with the Load Balancer frontend’s public IP and an allocated ephemeral port.

For outbound traffic, choose explicitly:

• Load Balancer outbound rule: Suitable when the VMs are already in its backend pool and the outbound requirement is relatively small.
• NAT Gateway: Better when an entire subnet needs scalable outbound Internet access.
• Private Link: Better when the destination is an Azure PaaS service and traffic should remain private.