Submarine Cable Resilience: Check Real Route Diversity

Two internet contracts do not necessarily provide two independent paths. Submarine cable resilience depends on the physical routes, landing sites, terrestrial backhaul, and facilities behind those contracts. If both services share the same vulnerable segment, changing the carrier name does not remove the shared failure.

APNIC's October 14, 2026 discussion of submarine cable resilience provides a timely prompt to examine this distinction. For a small technical team, the practical response is not to map the entire global cable system. It is to ask specific questions about the dependencies that connect users, offices, and hosted services.

Define the traffic that matters

List the connections whose loss would stop useful work: customer access to a region, staff access to the identity provider, payment processing, support tools, and backups. Identify the source and destination regions rather than treating all international traffic as one path.

A Singapore office reaching a European service has a different dependency chain from a Japanese customer reaching a local application region. Do not assume that a provider's general resilience statement covers every route. Ask which traffic classes and destinations the statement actually describes.

Separate availability from acceptable performance. A backup path can remain connected while latency or packet loss makes a voice call, remote desktop, or interactive application unusable. Write down the minimum tasks that must continue, then specify measurable tolerances for those tasks.

Ask about shared physical dependencies

Request evidence of diversity at several layers:

• The office entrance and local access route.
• The building meet-me room and nearby aggregation facility.
• Terrestrial backhaul toward the coast or regional hub.
• Cable systems and landing stations where relevant.
• Upstream transit and restoration arrangements.

These questions are procurement checks, not a demand for publicly exposing sensitive infrastructure maps. Providers may share only limited information. Record the limitation rather than converting a verbal assurance into a verified fact.

Ask whether the second service is delivered over another company's wholesale circuit. A reseller may provide excellent support while still sharing the first provider's underlying route. Also ask whether normal and restoration paths are diverse. Two services can be separate in normal operation but converge during a regional disruption.

What traceroute can and cannot prove

Traceroute is useful for observing an IP-level path at a particular moment. It does not reliably reveal the physical cable, buried conduit, building power supply, or contract behind every hop. Routers may not answer probes, and forward and return traffic can follow different routes.

Use it as supporting evidence, not a certificate of physical independence. Capture observations from both links toward several important destinations at different times. Keep the date, source network, and destination with each result. A single screenshot without context becomes weak evidence after routing changes.

If two paths look different, ask what that difference means physically. If they look identical, investigate, but don't immediately conclude that every segment is shared. Tunnels, aggregation, and non-responsive devices can hide details. Provider documentation and observed application behavior should inform the interpretation together.

Design a failover test around work

Use an approved maintenance window to disconnect the primary link at a controlled point. Confirm that the backup carries the applications you listed. Test DNS resolution, login, payment test flows, and access to incident communications rather than stopping after a successful ping.

Record the time between failure and usable service. Existing sessions may fail even when new sessions work. For example, a call may drop because the public source address changes, while a new call starts successfully. Decide whether that meets the business requirement.

Repeat the test after the primary returns. A badly configured failback can repeatedly move traffic between paths and create more disruption than remaining on the backup. Confirm that monitoring distinguishes the primary outage from the deliberate test so responders receive useful information.

Consider capacity during a wider incident

Backup bandwidth is not just the advertised circuit rate. During a regional failure, other customers may also use restoration capacity. Ask about contention and the provider's service commitments under those conditions. Avoid assuming that a best-case speed test predicts incident capacity.

Prepare a degraded operating mode. Pause large software downloads, non-essential replication, and background media traffic where appropriate. Protect identity, customer support, and essential transaction paths. The exact priorities belong to your organization; a generic network rule cannot decide them for you.

If the backup has a smaller allowance or different billing model, estimate the cost of a day and a week of essential traffic. This is an original scenario calculation, not a prediction of an outage. Include the trigger and authority for activating any paid capacity increase.

Keep a readable evidence record

Maintain a short register with service name, route assurance, evidence date, shared facilities, restoration limits, and the next review owner. Compare updated provider statements with Text Diff after redacting sensitive details. The tool compares text; it cannot verify a cable route.

Our cloud outage dependency map addresses software and service dependencies. Add physical connectivity dependencies to that map rather than treating connectivity as an independent, perfectly reliable box.

Conclusion

Real route diversity combines provider evidence, physical dependency questions, and application-level failover tests. Two bills can be a useful start, but they are not the proof. The strongest plan states what is independent, what is shared, and what still works when the primary path disappears.