Path Diversity

Path diversity reduces the chance that a single network failure disconnects an application, site, or cloud environment. The objective is not simply to purchase two circuits, but to understand which physical and logical components those circuits share. Two connections can have different circuit identifiers and still traverse the same building entrance, underground conduit, carrier aggregation router, or cloud interconnection facility. A failure at any shared component can interrupt both connections.

Start by defining the failures the architecture must tolerate. Surviving a router failure requires different measures from surviving a fiber cut, an entire colocation facility outage, or the loss of an on-premises site. Trace each path from the application network through customer routers, firewalls, access circuits, carrier networks, cloud connectivity locations, and cloud routing attachments. Document shared dependencies and ask carriers to confirm physical route separation. Different carrier names alone do not prove independence because carriers can lease the same underlying fiber.

For an AWS hybrid network, a common design uses AWS Direct Connect connections at separate Direct Connect locations, with independent customer routers and diverse access circuits. Connections on different devices at one location improve device resilience but still share a location-level failure domain. A link aggregation group increases aggregate capacity and can tolerate individual member-link failures, but its links terminate on the same AWS device and do not provide location diversity. Requirements for higher resilience can justify multiple connections at each of multiple locations.

AWS Site-to-Site VPN can provide an alternative path over the internet when Direct Connect connectivity fails. Its independence depends on the underlying internet access: a VPN using the same customer router, carrier access circuit, or building entrance as Direct Connect may fail at the same time. Each VPN connection supplies two tunnels for AWS-side endpoint redundancy, but those tunnels do not by themselves eliminate a shared customer gateway or internet circuit. Greater customer-side resilience requires additional gateway devices and appropriately independent connectivity.

Physical diversity must be paired with deliberate routing. BGP can exchange reachable prefixes and withdraw routes when a session or path fails. Configure route advertisements and preferences for the intended active-active or active-passive behavior, and evaluate both traffic directions. AWS route-selection rules vary by gateway and route type, so do not assume that a preferred outbound path automatically becomes the preferred return path. More-specific advertisements, static routes, or inconsistent filtering can prevent the expected failover. Asymmetric routing can also disrupt traffic through stateful firewalls.

For example, a company might connect two edge routers to two Direct Connect locations and maintain an internet-based VPN as an additional recovery path. If one location becomes unavailable, the remaining Direct Connect path should carry the required workload. If both private paths fail, the VPN may preserve critical applications, provided its throughput, latency, tunnel configuration, and routing policies are suitable. Backup capacity must be evaluated under failure conditions rather than normal load alone.

The trade-offs include additional circuit charges, equipment, carrier coordination, routing complexity, and operational testing. Diversity does not guarantee uninterrupted sessions: failure detection and routing convergence take time, and some failures leave routing sessions established while application traffic is impaired. Test circuit, router, tunnel, and location failures; measure packet loss and convergence; and verify application recovery. The strongest evidence of useful path diversity is demonstrated connectivity through the failures the design is intended to withstand.