Azure ExpressRoute and VPN Gateway both connect on-premises networks to Azure, but they solve different hybrid-connectivity requirements. VPN Gateway establishes encrypted IPsec/IKE tunnels across the public internet. ExpressRoute provides private Layer 3 connectivity to Microsoft through a connectivity provider or peering location.

For the current AZ-700 scope, the key design decision is not which service sounds more “enterprise.” It is whether the workload needs the lower cost and rapid deployment of internet-based VPN connectivity, the predictable private path and higher bandwidth of ExpressRoute, or a combination in which one path protects the other.

The comparison should include bandwidth, latency, encryption expectations, provider dependencies, resilience, routing, implementation time, and recovery behavior.

Start with the path the traffic is allowed to use

The most basic distinction is the transport path.

A site-to-site VPN Gateway connection encrypts traffic with IPsec/IKE and sends it across the public internet between the on-premises VPN device and the Azure VPN gateway. The payload is encrypted, but the path depends on internet connectivity and routing conditions outside the organization’s direct control.

ExpressRoute connects the customer network to Microsoft through a private connectivity model. Microsoft’s current guidance describes Layer 3 connectivity through providers, Ethernet exchanges, or direct connectivity models, with BGP used to exchange routes.

That difference can be decisive for workloads with policy or compliance requirements that prohibit production traffic from traversing the public internet even when encrypted. It can also matter for latency-sensitive applications that need a more predictable network path.

Private connectivity does not mean “no security design required.” Authentication, encryption at higher layers, segmentation, and application controls remain necessary. ExpressRoute changes the network path; it does not replace zero-trust principles.

VPN Gateway favors speed, cost, and operational simplicity

VPN Gateway is often the first choice when organizations need hybrid connectivity quickly.

It is useful for:

• branch or datacenter connectivity where internet-based tunnels are acceptable
• smaller or moderate bandwidth requirements
• development and test environments
• temporary migration connectivity
• backup connectivity for another primary path
• locations where ExpressRoute provider connectivity is unavailable or unjustified

Provisioning a gateway still takes time, but the overall implementation can be much faster than ordering a private carrier circuit. The customer typically uses an existing internet connection and compatible VPN device rather than waiting for provider cross-connects or private WAN provisioning.

Cost is also usually lower. Microsoft’s hybrid-connectivity guidance positions VPN Gateway as the lower-cost option, with gateway charges and data-transfer costs rather than a dedicated provider circuit and associated service fees.

The tradeoff is that throughput and latency depend on gateway SKU, tunnel configuration, internet conditions, and the on-premises device. Aggregate gateway throughput is not the same thing as guaranteed throughput for one tunnel.

VPN capacity also needs to be tested with the actual encryption and packet profile. Small packets, many parallel tunnels, and firewall or router CPU limits can produce results well below a simple line-rate assumption. If VPN is intended as an ExpressRoute failover path, size it for the traffic that must survive the outage rather than for normal backup-idle conditions. A backup path that becomes saturated the moment it is needed will extend the application recovery event.

ExpressRoute favors predictable private connectivity and higher scale

ExpressRoute is designed for organizations that need a private, predictable path to Microsoft cloud services.

Current Microsoft guidance highlights benefits such as:

• private Layer 3 connectivity
• BGP-based dynamic routing
• redundant Microsoft edge connections at the peering location
• higher bandwidth options than typical VPN deployments
• predictable latency characteristics compared with public-internet transport

The service is particularly attractive for large migrations, data-intensive hybrid applications, enterprise datacenter integration, and regulated environments that require private network transport.

ExpressRoute has more dependencies. The design involves a provider or colocation relationship, circuit provisioning, peering configuration, and often a longer implementation timeline. Those dependencies should be included in project risk, especially when a migration deadline assumes the private circuit will exist by a specific date.

A network architect should therefore avoid recommending ExpressRoute solely because the application is “critical.” Criticality should be translated into measurable requirements such as throughput, latency, privacy, recovery time, and carrier diversity.

Latency requirements should also be measured end to end. ExpressRoute can provide a more predictable private path, but application response time still includes on-premises LAN delay, provider transport, Azure routing, firewalls, proxies, and the application itself. Private connectivity removes one source of variability; it does not guarantee low latency for a poorly placed or poorly performing workload.

BGP design matters for both services

Dynamic routing is central to resilient hybrid connectivity.

ExpressRoute uses BGP to exchange routes with Microsoft. Each circuit has redundant connections to Microsoft edge routers, and the customer side should be designed with equivalent redundancy rather than terminating both paths on one fragile device.

VPN Gateway can also use BGP. With BGP enabled, route updates can propagate dynamically as network topology changes instead of requiring administrators to maintain every on-premises prefix manually through static local network gateway definitions.

The routing plan should define:

• customer and Azure autonomous system numbers where relevant
• prefixes advertised from on-premises
• prefixes learned from Azure
• route preference when multiple hybrid paths exist
• how default routes are handled
• whether transit through a hub or NVA is expected
• how failover changes the effective path

A second connection does not create useful resilience if routing still prefers a broken path or if both connections depend on the same physical device, carrier, building entrance, or power source.

Resilience requires more than one gateway instance

Both VPN Gateway and ExpressRoute expose high-availability features, but architects must consider the full end-to-end path.

For VPN Gateway, active-active configurations and zone-redundant gateway SKUs can reduce dependence on a single gateway instance or availability zone. The on-premises side should also use redundant devices and internet paths when the business requirement justifies it.

For ExpressRoute, Microsoft provides redundant connections at the peering location, but the customer should still consider provider and physical-path diversity. Two logical connections delivered through the same carrier and building entrance may share more risk than the diagram suggests.

For very high availability, some organizations use multiple ExpressRoute circuits in different peering locations. Others use ExpressRoute as the primary path and VPN Gateway as a backup. Microsoft explicitly documents this combined pattern for environments where ExpressRoute downtime is not acceptable.

The right architecture depends on the failure domains that actually need to be survived, not simply the number of lines drawn between sites.

Encryption requirements need explicit treatment

A common oversimplification is “VPN is encrypted, ExpressRoute is not.” The reality is that ExpressRoute provides a private path, but privacy and encryption are separate concerns.

If an application requires encryption in transit, use application-layer TLS or another supported encryption mechanism regardless of the private transport. ExpressRoute Direct can also support MACsec in relevant configurations, but that is a specific design option rather than a universal property of every ExpressRoute connection.

VPN Gateway inherently uses IPsec/IKE for the site-to-site tunnel, which protects data crossing the public internet between the VPN endpoints.

The architecture document should therefore state both requirements separately:

• Must traffic avoid the public internet?
• Must traffic be cryptographically protected in transit?

One requirement does not automatically satisfy the other.

Throughput numbers need workload context

Microsoft’s current hybrid-connectivity guidance shows a large gap between the upper ranges of VPN Gateway and ExpressRoute. VPN Gateway aggregate throughput depends on SKU and can reach multi-gigabit ranges, while ExpressRoute circuits can scale much higher, with ExpressRoute Direct supporting very high bandwidth options.

Raw bandwidth is only part of the design.

A migration may require sustained high throughput for bulk data transfer even if normal production traffic is modest. A transactional application may care more about predictable latency and jitter than peak bandwidth. A branch network may have many small sites whose combined traffic is substantial even though no individual location needs a large circuit.

Capacity planning should therefore separate:

• steady-state production traffic
• peak business traffic
• backup and replication traffic
• migration waves
• recovery scenarios
• growth headroom

The design should also account for the throughput limitations of firewalls, routers, VPN appliances, and other devices in the path.

ExpressRoute and VPN can coexist

The choice is not always exclusive.

A common enterprise design uses ExpressRoute for primary production traffic and VPN Gateway for backup. If the private circuit becomes unavailable, selected routes can fail over to the VPN path.

That pattern improves resilience, but only if it is tested. Route preference, BGP timers, VPN throughput, firewall rules, and DNS dependencies can all make the backup path behave differently from the primary path.

Another pattern is staged migration: a VPN provides initial hybrid connectivity while the organization waits for ExpressRoute provisioning. Once the private circuit is ready, production routes move to ExpressRoute while VPN remains available for contingency use.

Temporary designs should have an explicit end state. Otherwise, a migration VPN can become a permanent production dependency without the capacity or support model expected of one.

Choose from requirements, then test the failure path

A concise decision model is:

Choose VPN Gateway when encrypted internet-based connectivity, rapid deployment, and lower cost matter more than private transport and very high throughput.

Choose ExpressRoute when the application needs a private path, higher or more predictable bandwidth, more consistent latency characteristics, or policy-driven avoidance of public-internet transport.

Use both when the business requirement justifies an independent backup path or a staged migration design.

Then test the architecture under failure. Remove a tunnel, circuit, BGP session, gateway instance, or carrier path and verify that routes converge as expected and that the surviving path has enough capacity. Hybrid connectivity is resilient only when the backup path is operationally real, not merely present on the diagram.