CH03-06: Hybrid Connectivity with ExpressRoute and VPN
Goal
The previous section introduced hub-spoke networking and shared connectivity. This section explains how Azure connects to on-premises and external enterprise networks.
The goal is to compare VPN and ExpressRoute as architecture choices, not to memorize connectivity product names. A hybrid connection is not just a wire into Azure. It affects routing, reliability, privacy, cost, operations, security review, DNS, and migration sequencing.
The Short Version
Hybrid connectivity means controlled network communication between Azure and networks outside Azure, such as a data center, corporate office, branch location, or partner network.
Azure commonly supports hybrid connectivity with two broad options:
| Option | Plain-Language Meaning | Common Fit |
|---|---|---|
| VPN | Encrypted connectivity over the internet. | Faster start, smaller environments, backup paths, temporary migration paths, or moderate requirements. |
| ExpressRoute | Private dedicated connectivity through a connectivity provider. | Enterprise-scale, predictable, private connectivity where requirements justify cost and setup effort. |
The durable idea is:
Hybrid connectivity is not only a link to Azure; it is a reliability, routing, security, cost, and operating model decision.
Why Hybrid Connectivity Matters
Many organizations do not move everything to Azure at once.
During migration, an Azure workload may still need to reach:
Databases in a data center.
Identity or directory systems.
Internal APIs.
Monitoring or security tools.
File shares or integration systems.
Partner or branch networks.
Administrative jump hosts or management systems.
On-premises systems may also need to reach Azure workloads. For example, a data center application may call a new Azure API, or internal users may access an application hosted privately in Azure.
Hybrid connectivity turns cloud adoption into a network design problem. The application may run in Azure, but its dependencies may still live somewhere else.
VPN in Plain Language
A VPN connection provides encrypted connectivity over the internet.
In Azure, site-to-site VPN commonly uses Azure VPN Gateway. The gateway sits in an Azure VNet and connects to a VPN device or service in the external network.
A simplified view looks like this:
On-premises network
|
| encrypted VPN over internet
v
Azure VPN Gateway
|
v
Hub or workload VNet
VPN is often useful when:
The team needs connectivity quickly.
Traffic volume is moderate.
The workload is early in migration or testing.
Cost needs to stay lower.
The connection is a backup path.
The organization does not need dedicated private connectivity for the workload.
VPN is not automatically weak. It is encrypted and widely used. But because it uses internet paths, teams need to think carefully about throughput, latency, reliability, redundancy, and operational expectations.
ExpressRoute in Plain Language
ExpressRoute provides private dedicated connectivity between Azure and an external network through a connectivity provider.
A simplified view looks like this:
On-premises network
|
| private provider connection
v
ExpressRoute circuit
|
v
ExpressRoute gateway
|
v
Hub or workload VNet
ExpressRoute is often useful when:
Workloads need predictable private connectivity.
Traffic volume is high.
Latency and reliability expectations are stronger.
The organization has enterprise network operations maturity.
Regulatory, risk, or business requirements favor private connectivity.
Many workloads will share the hybrid path over time.
ExpressRoute is not a complete security design by itself. It provides private connectivity, but traffic still needs routing, segmentation, inspection where required, monitoring, DNS, and access control.
VPN and ExpressRoute Compared
Use this comparison as a decision guide, not as a rulebook:
| Decision Factor | VPN | ExpressRoute |
|---|---|---|
| Network path | Encrypted over internet. | Private dedicated provider path. |
| Time to start | Often faster. | Usually requires provider setup and planning. |
| Cost model | Often lower entry cost. | Higher cost and stronger enterprise commitment. |
| Bandwidth and predictability | Suitable for many needs but internet-dependent. | Better fit for predictable, high-volume connectivity. |
| Privacy | Encrypted tunnel over public internet paths. | Private connectivity outside the public internet path. |
| Common use | Testing, smaller workloads, temporary migration, backup. | Production enterprise connectivity, steady-state hybrid platforms. |
| Operational complexity | Still needs routing, redundancy, and monitoring. | Adds provider, circuit, gateway, routing, and operations dependencies. |
The right answer depends on requirements. A small internal tool may not justify ExpressRoute. A high-volume regulated platform with many dependencies may not be comfortable relying only on VPN.
Redundancy and Resilience
Hybrid connectivity is often a critical dependency. If the connection fails, workloads may lose access to data, identity systems, APIs, or users.
Resilience questions include:
Do we need multiple VPN tunnels?
Do we need redundant VPN devices on-premises?
Do we need multiple ExpressRoute circuits?
Do we need provider diversity?
Should VPN act as backup to ExpressRoute?
What happens if one Azure region or gateway has a problem?
Which workloads can tolerate a hybrid outage?
Do not design hybrid networking only for the happy path. A connection diagram that works during a demo may not be enough for production.
Routing and DNS
Hybrid connectivity is not complete until routing and DNS are designed.
Routing answers:
Which Azure address ranges are advertised to on-premises?
Which on-premises ranges are reachable from Azure?
Should traffic pass through a hub firewall?
How do spoke VNets use the hybrid connection?
Are return paths symmetric and predictable?
DNS answers:
How do Azure workloads resolve on-premises names?
How do on-premises systems resolve Azure private names?
How will private endpoints work across the hybrid boundary?
Which team owns DNS forwarding or resolver configuration?
Many hybrid issues are not caused by the connection itself. The tunnel or circuit may be healthy, but traffic still fails because routes, NSGs, firewalls, DNS, or service settings are wrong.
Migration Pattern: Start Small, Grow Deliberately
A migration may use different connectivity at different stages.
For example:
A team starts with VPN for early application testing.
The platform team builds the hub VNet, routing, DNS, and inspection model.
Production migration uses ExpressRoute because workloads need predictable private connectivity.
VPN remains as a backup path or for lower-criticality use cases.
Over time, more spoke VNets consume the shared hybrid path through the hub.
This staged approach can be sensible. The important thing is to know which stage you are in. Temporary connectivity should not become the long-term production design by accident.
Example: Choosing Connectivity for a Claims Platform
Imagine an insurance company is migrating a claims platform to Azure.
During the first phase, the Azure application needs to call one on-premises policy system. Traffic volume is low, and the team wants to test quickly. VPN may be enough for early validation.
During production rollout, the platform will process many claims, call several internal APIs, and support internal users across regions. The business wants predictable private connectivity and stronger operational commitments. ExpressRoute may be justified.
The final design may use:
ExpressRoute into a hub VNet for steady-state production connectivity.
VPN as a backup or temporary path.
Route tables to send spoke traffic through the hub.
Firewall rules for inspection and logging.
DNS forwarding so Azure and on-premises systems resolve the right names.
Monitoring and alerting for gateway, circuit, and route health.
The decision is not simply "VPN or ExpressRoute." The decision is how the business path should operate.
Common Mistakes
Choosing ExpressRoute only because it sounds more enterprise. Requirements should drive the choice.
Using VPN for critical high-volume workloads without checking fit. Encrypted internet connectivity may not meet every reliability or throughput need.
Forgetting redundancy. One connection path can become a single point of failure.
Ignoring DNS. Hybrid name resolution often decides whether applications actually work.
Treating ExpressRoute as a complete security design. Private connectivity still needs segmentation, routing, inspection, monitoring, and access control.
Letting temporary migration connectivity become permanent by accident. Short-term paths should have review points.
If Someone Asks You
If someone asks, "How do you choose between ExpressRoute and VPN for Azure hybrid connectivity?" a clear answer is:
VPN provides encrypted connectivity over the internet and is often useful for faster setup, smaller workloads, testing, backup, or temporary migration paths. ExpressRoute provides private dedicated connectivity through a provider and is often used when workloads need more predictable, private, enterprise-scale connectivity. The choice depends on reliability, privacy, bandwidth, cost, provisioning time, redundancy, routing, DNS, and operational requirements. Neither option replaces segmentation, inspection, monitoring, or access control.
This answer frames hybrid connectivity as a decision, not a product preference.
What You Should Remember
Hybrid networking connects Azure to the rest of the enterprise.
The most important idea is this:
Hybrid networking is designed around the business path, not only the connection type.
Choose VPN, ExpressRoute, or both based on the workload's requirements and the operating model around routing, DNS, resilience, inspection, and support.
Questions to Check Your Understanding
What is the basic difference between VPN and ExpressRoute?
Why is hybrid connectivity an architecture decision, not just a network link?
Why do routing and DNS matter in hybrid migration?
When might VPN be enough?
When might ExpressRoute be justified?