CH13-02: Connectivity with ExpressRoute, VPN, and Hub-Spoke Networks

Goal

The previous section framed hybrid architecture as dependency flow. The first visible piece of that flow is usually connectivity: how Azure reaches existing networks and how existing networks reach Azure.

Connectivity is important, but it should not be chosen as a badge of maturity. A VPN can be the right answer for one stage. ExpressRoute can be the right answer for another. Hub-spoke networking can make either option usable by many workloads without each team building its own path.

The durable idea is:

Connectivity choice should match privacy, reliability, bandwidth, lead time, cost, and operating needs.

The Short Version

Azure hybrid connectivity commonly starts with two broad options:

Option	Plain-Language Meaning	Common Fit
VPN Gateway	Encrypted connectivity over the internet.	Pilots, smaller workloads, backup paths, faster setup, temporary migration, or moderate traffic needs.
ExpressRoute	Private connectivity through a provider path.	Enterprise-scale production connectivity where predictability, privacy, bandwidth, or business requirements justify the cost and setup.

The choice is not only technical. It affects procurement, routing, redundancy, monitoring, change control, incident response, and cost.

The network shape often looks like this:

On-premises network
  -> VPN or ExpressRoute
  -> Azure hub network
  -> workload spokes

VPN Gateway

VPN Gateway provides encrypted network connectivity over internet paths. In many designs, it is the fastest practical way to start validating a hybrid workload.

VPN can fit when:

The team is building a pilot or proof of concept.
Traffic volume is moderate.
The workload can tolerate internet-path variability.
The organization wants a lower entry cost.
The connection is temporary during migration.
VPN is used as a backup path to another primary connection.

VPN is not automatically a weak design. It can be secure and useful. The key is to match it to the reliability, bandwidth, latency, and operating expectations of the workload.

ExpressRoute

ExpressRoute provides private connectivity between Azure and an external network through a connectivity provider. It avoids sending traffic over the public internet path, though it still requires routing, security, monitoring, and operations.

ExpressRoute can fit when:

Many workloads will share the hybrid path.
Traffic volume or predictability requirements are high.
The organization needs private provider connectivity.
Production applications depend heavily on on-premises systems.
Enterprise network teams can operate circuits, gateways, routing, and provider relationships.
Business or regulatory requirements favor a private connectivity model.

ExpressRoute is not a magic production stamp. It can be the right foundation, but it still needs redundancy, route control, DNS design, firewall inspection where required, monitoring, and support ownership.

Decision Comparison

Use the comparison as a starting point:

Decision Factor	VPN Gateway	ExpressRoute
Network path	Encrypted over internet.	Private provider connectivity.
Setup speed	Often faster to start.	Usually needs provider planning and lead time.
Entry cost	Usually lower to begin.	Usually higher and more enterprise-oriented.
Predictability	Depends on internet path and design.	Better fit for predictable enterprise connectivity.
Bandwidth fit	Good for many moderate needs.	Better for high-volume or shared production paths.
Privacy model	Encrypted tunnel across public network paths.	Private path outside the public internet route.
Common role	Pilot, temporary, smaller, or backup connectivity.	Long-running production hybrid platform connectivity.
Operating model	Still needs routing, redundancy, and monitoring.	Adds provider, circuit, gateway, routing, and operations dependencies.

The strongest designs do not ask, "Which one is better?" They ask, "Which one fits this stage, workload, risk, cost, and support model?"

Hub-Spoke as the Shared Connectivity Shape

Chapter 3 introduced hub-spoke networking. In hybrid architecture, the hub often becomes the shared connectivity and inspection point.

On-premises network
  -> VPN or ExpressRoute
  -> Hub VNet
       +-- gateway
       +-- firewall or inspection
       +-- DNS resolver or forwarding
       +-- shared management paths
  -> Spoke VNets for workloads

This lets the platform or network team operate one governed hybrid path instead of asking every workload team to build separate tunnels or circuits.

Spokes can hold workload resources, private endpoints, application subnets, data access paths, and environment-specific controls. The hub can hold shared connectivity, inspection, DNS, and routing services.

The important phrase from Chapter 3 still applies:

Peering creates reachability. Architecture decides whether that reachability should be used.

Hub-spoke does not automatically make the environment secure. Route tables, firewall rules, NSGs, DNS, monitoring, and ownership still define the real behavior.

Redundancy and Monitoring

Hybrid connectivity often becomes a critical dependency. If it fails, Azure applications may lose access to databases, users, APIs, identity systems, file shares, or monitoring tools.

Plan for questions such as:

Are there redundant tunnels, gateways, circuits, or provider paths?
Which workloads can continue during a hybrid outage?
Is VPN a backup to ExpressRoute, or is it a separate lower-criticality path?
Who monitors gateway health, circuit status, route changes, tunnel state, and latency?
Which alerts go to the network team, platform team, or application owner?
How are planned maintenance and provider incidents communicated?

Connectivity without monitoring is a quiet risk.

Example: Pilot to Production

A manufacturing company wants to test an Azure-hosted reporting app that reads from an on-premises SQL Server. The first pilot uses VPN because setup is faster and traffic is small.

During production planning, the team discovers that several applications will move to Azure while ERP and identity dependencies remain in the data center. Traffic will grow, support expectations are higher, and several workload spokes will need the same hybrid path.

The design evolves:

Pilot
  -> VPN Gateway into a test hub
  -> limited routes and test workloads

Production
  -> ExpressRoute into a shared hub
  -> firewall inspection and DNS services
  -> workload spokes consume the shared path
  -> VPN considered for backup or lower-criticality scenarios

This is a healthy progression because each stage has a reason. The danger would be keeping the pilot VPN as a production dependency without review.

Common Mistakes

Choosing ExpressRoute only because it sounds more enterprise.
Using VPN for critical high-volume production dependencies without testing fit.
Letting every workload build its own hybrid connection.
Forgetting route propagation, return paths, DNS, inspection, and monitoring.
Building a hub that becomes a bottleneck because ownership and change process are unclear.
Designing only the primary path and ignoring redundancy or maintenance behavior.

If Someone Asks You

How do you choose hybrid connectivity for Azure?

A good answer is:

I choose by requirements and operating model. VPN Gateway provides encrypted connectivity over the internet and often fits pilots, smaller workloads, temporary migration, backup paths, or moderate needs. ExpressRoute provides private provider connectivity and often fits enterprise production paths that need more predictability, bandwidth, or privacy. In either case, I design routing, DNS, inspection, redundancy, monitoring, and ownership. Hub-spoke networking often lets many workloads share the governed hybrid path.

What You Should Remember

Hybrid connectivity is a shared platform path, not a one-off workload shortcut.

Questions to Check Your Understanding

How do VPN and ExpressRoute differ?
Why does hub-spoke design help hybrid environments?
What should be monitored in hybrid connectivity?