Conceptual illustration—not a map of actual carrier routes.
Two provider names on a network diagram can look like a resilience strategy. They establish that the business has two commercial relationships. They do not, by themselves, establish that the connections can survive the same physical incident.
For enterprises connecting offices, data centers and cloud services across Japan and Asia-Pacific, that distinction belongs in the design review—not in the incident report. A second connection is valuable only to the extent that it protects against the failures the business needs to withstand.
Geoff Huston’s October 14 APNIC analysis of submarine cable resilience explains how cable routes can converge at geographic choke points and how restoration depends on repair resources and access. The enterprise implication is practical: assess shared dependencies and the service that remains available, rather than counting suppliers.
Separate provider diversity from physical route diversity
Using two internet service providers, sometimes described as multihoming, gives an organization more than one network connection. Whether that arrangement protects against a particular outage depends on the underlying design, routing and operating arrangements.
Two connections might use different provider networks but share a local access duct. International services might traverse the same submarine cable or landing station. Routes that separate offshore can still converge on the terrestrial backhaul between a landing station and a metropolitan network.
The engineering concept is well established. IETF RFC 4202, Section 2.3, describes shared-risk link groups: links whose common resource could cause them to fail together. Its example is two fibers in one conduit. The useful question is not simply whether the lines on a diagram are different, but which events could interrupt both.
Start with defined scenarios: loss of an access circuit, a building entry, a provider point of presence, a landing station or a wider geographic corridor. A design can address one scenario while remaining exposed to another.
Ask for evidence from the building to the destination
For each critical connection, ask suppliers to explain the relevant physical dependencies and the limits of their assurance. Structure the review around four layers:
- Site access: Do the circuits enter through different building entries and follow separate ducts and risers? Which access carriers actually deliver them?
- Facilities: Do they terminate on separate equipment, and what power or facility dependencies remain shared?
- Regional transport: Which backhaul routes and provider facilities connect the site to its regional destinations? Where can the paths converge?
- International transport: Where relevant, which submarine cable systems, landing stations and geographic corridors support the services, including their restoration paths?
Ask about both normal operation and failure conditions. A provider’s alternate route may restore connectivity while introducing a dependency shared with the other service.
The response need not be a publicly distributable map of sensitive infrastructure. Request circuit-specific evidence under appropriate confidentiality arrangements, or a written diversity assessment with explicit exclusions. Record which segments the supplier controls and which depend on wholesale partners.
Where disclosure is unavailable, mark the dependency as unknown. Do not turn the absence of information into a claim of independence. The business can then decide whether to accept the uncertainty, commission further verification or change the design.
Put the requirement into procurement and delivery
“Diverse connectivity” is too broad to be an acceptance criterion. Specify the failures the design must tolerate, the segments covered by the diversity commitment and any permitted common infrastructure.
Ask procurement and technical teams to align the supplier’s written commitment with the design. Clarify whether the information describes the installed service or only a proposed route, how changes will be notified, and what happens when emergency restoration alters the agreed separation. Distinguish an availability service-level agreement from an explicit physical-diversity commitment; do not assume one establishes the other.
Before handover, reconcile the delivered circuits with the approved design. Keep the evidence, exceptions, review date and accountable owner together. A project manager should be able to identify which unresolved dependencies require a business decision rather than allowing them to disappear into a completed installation ticket.
Test the business service, not only route convergence
Physical separation and operational failover need different evidence. Supplier documentation helps establish the former; controlled testing helps establish the latter. Neither replaces the other.
For example, AWS’s Direct Connect Resiliency Toolkit distinguishes connections on separate devices in one location from designs spanning multiple locations. Its failover testing can bring down a BGP peering session to check rerouting. That is a useful, bounded test—not proof that every physical dependency is independent.
Define your own acceptance tests around critical applications and representative demand. During an approved exercise, measure interruption time, transaction success, latency, packet loss and usable throughput on the surviving path. Confirm that DNS, identity services, security controls and external application dependencies remain reachable. Check whether changed source addresses or routing behavior affect allowlists and established sessions.
Include a degraded-capacity scenario. Ask what happens when the remaining service must carry priority traffic alongside ordinary workloads, and agree which nonessential transfers can be deferred. A backup link that answers a ping may still be insufficient for the business processes it is meant to protect.
Set success thresholds, safety limits and rollback steps before testing. Record the scenarios actually exercised, the results and the assumptions that remain untested. Test restoration to normal service as well as failover, then revalidate after material circuit, supplier or application changes.
Make the remaining risk visible
The outcome should be a concise decision record: the critical service, the failures it must tolerate, the known shared dependencies, the evidence for separation, and the measured service level after failover. Any unresolved exposure needs an owner and an explicit decision.
This makes the broader recovery questions discussed in Ahead’s article on disaster recovery and security concrete at the network layer. It also connects architecture, supplier selection, deployment and operational handover—where an apparently resilient design must become a working service.
Two providers can be part of a sound design. The confidence comes from knowing what remains shared, what has been verified and whether the surviving connection can support the work that matters.