A cluster of damaged undersea fibre‑optic cables in the Red Sea forced Microsoft Azure to reroute traffic, injecting significant latency into cloud services for customers across the Middle East and Asia. The incident, which began on 6 September 2025, exposed the fragile physical foundations of the internet and prompted urgent mitigation actions from hyperscalers and network operators alike.
What happened
Multiple trunk submarine cables that normally provide the shortest east–west paths between Asia, the Middle East, and Europe were compromised in a narrow geographic bottleneck near Jeddah and the Bab el‑Mandeb approaches. Microsoft posted an Azure Service Health advisory warning that customers “may experience increased latency” for traffic crossing the Middle East corridor, while independent monitoring groups from NetBlocks and Kentik confirmed degraded connectivity in India, Pakistan, Saudi Arabia, and the United Arab Emirates.
The damage did not cause a platform‑wide outage—Azure’s control plane and regionally contained services continued to function—but data‑plane traffic that had to traverse the damaged corridor saw sharply higher round‑trip times (RTT), jitter, and occasional packet loss. In short, reachability was preserved at the cost of performance.
The physics of cloud latency: why cable cuts bleed performance
Under normal conditions, subsea cables offer the shortest fibre paths, minimizing propagation delay. When those paths are severed, data is forced onto longer, often more congested detours. Each extra kilometre adds roughly five microseconds of one‑way delay; a multi‑thousand‑kilometre reroute can add 50–150 milliseconds to RTT. Multiply that by dozens of network hops—each router adding processing and queueing delay—and latency‑sensitive workloads grind to a crawl. Voice calls drop, video conferencing stutters, and synchronous database replication struggles.
For Azure customers, the symptoms were precisely those: elevated latency and intermittent slowdowns for any flow that normally rode the Red Sea corridor. Traffic that did not traverse the Middle East was reportedly unaffected, underscoring the geographic concentration of the damage.
Which cables were cut — and the unresolved question of cause
Early reports from operators and the International Cable Protection Committee named several major systems that frequently use the Jeddah/Red Sea corridor, including SEA‑ME‑WE 4 (SMW4), IMEWE, and FALCON GCX. Some sources also pointed to AAE‑1 and other regional feeders. However, definitive confirmation of every fault and its exact coordinates requires days of ship‑based diagnostics; all attributions should be treated as provisional until operators publish final reports.
The cause remains officially undetermined. The leading hypothesis from independent analysts is accidental anchor drag by commercial shipping, a common hazard in busy maritime lanes. Yet authorities have not ruled out deliberate interference. Sabotage of undersea cables is not without precedent—similar acts have been documented in the Baltic Sea and, as the BBC noted, in the Red Sea itself just last year. Unverified speculation has circulated, but forensic confirmation is still pending. PC Gamer’s original coverage flagged these uncertainties and stressed that any attribution should be handled with care.
Repair reality: a slow, complex process
Restoring severed submarine cables is not a matter of flipping a switch. Operators must first pinpoint the fault precisely using telemetry and very‑low‑frequency (VLF) detection. A specialised cable‑repair vessel must then be dispatched with grapnels and splice teams to recover the damaged section, haul it aboard, and splice in fresh fibre. In shallow‑water shore‑end breaks, the operation can take days per fault; in geopolitically sensitive waters, permissions and security concerns can stretch timelines further.
Past Red Sea cable repairs have ranged from several days to multiple weeks, and exceptional regional constraints have occasionally extended them even longer. That means traffic‑engineering mitigations—not instant physical repair—are the primary tool cloud providers will lean on for the foreseeable future.
Broader implications: chokepoints, resilience, and geopolitical risk
The incident is a stark reminder that even the most sophisticated cloud architectures rest on a limited set of physical routes. Hyperscalers like Microsoft build global backbones with multiple peering arrangements, but when a narrow maritime chokepoint hosts several trunk systems that are all damaged simultaneously, even the largest providers face degraded performance for cross‑region traffic.
Key takeaways for enterprise architects:
- Strategic chokepoints matter. The Red Sea is a geographic funnel; a handful of fibre faults there ripple across continents.
- Multi‑region deployment is necessary but not sufficient. Logical region diversity often conceals physical‑route correlation. Two Azure regions might both route through the same damaged corridor.
- Physical path diversity must be verified. Ask cloud and carrier providers to demonstrate that critical traffic takes alternate subsea routes, not merely logical abstractions.
- Repair fragility and geopolitical exposure are rising business risks. The limited fleet of cable‑repair ships and the political sensitivity of maritime corridors mean physical recovery can be slow and uncertain.
What Azure customers — and every cloud user — should do now
Microsoft’s advisory and the operational realities point to several immediate, actionable steps for IT teams:
- Check Azure Service Health for targeted advisories affecting your subscriptions and services.
- Profile affected flows with synthetic tests (ping, traceroute, application probes) to quantify latency shifts.
- Reroute critical traffic to local regions or alternative providers where latency meets SLAs. For ultra‑sensitive services, consider temporarily switching to providers with verifiably distinct subsea paths.
- Enable CDN and caching (Azure Front Door, global CDN endpoints) to offload static content and reduce cross‑continental fetches.
- Audit ExpressRoute and direct peering for physical path diversity—private circuits still ride the same submarine cables.
- Implement graceful degradation : build client and server‑side timeouts, retries with exponential backoff, and fallback workflows to preserve user experience under higher latency.
- Update runbooks for prolonged repair windows (days to weeks) and maintain proactive communications with stakeholders.
How Microsoft responded
Microsoft’s operational playbook for corridor‑level subsea incidents was textbook. The Azure Service Health advisory accurately described the symptom (increased latency) and the geographic scope (traffic traversing the Middle East), enabling customers to triage impact quickly. Behind the scenes, engineers rerouted traffic across the global backbone, optimised routing policies, and rebalanced capacity onto alternate subsea systems, terrestrial backhaul, and leased transit. The company committed to daily updates, indicative of a telemetry‑driven, dynamic mitigation effort.
Yet even the most sophisticated traffic engineering cannot replace lost raw fibre capacity. Until physical repairs are completed, Azure users will continue to experience elevated latency on affected routes.
Looking ahead: policy, investment, and a wake‑up call
The Red Sea cable cuts will accelerate calls for stronger subsea infrastructure protection. Policymakers and industry bodies are likely to press for enhanced maritime monitoring around cable landings, faster repair logistics (more repair ships and prepositioned spares), and accelerated investment in alternative routes—whether longer but less contested paths around Africa or new terrestrial overland links. Enterprises will also re‑examine SLAs, force majeure clauses, and insurance coverage for subsea disruptions.
None of this offers a quick fix. The economics of submarine cables and the geopolitics of their environment mean change will be incremental. But the commercial and national‑security stakes are rising, and this incident serves as an operational wake‑up call for any organisation that treats “the cloud” as an abstraction divorced from physical reality.
What remains unknown
Several critical uncertainties persist:
- Root cause : Anchor drag remains the most plausible hypothesis, but deliberate sabotage cannot be dismissed until forensic investigations conclude.
- Full list of affected cables : Initial monitoring suggests SMW4, IMEWE, and FALCON GCX were among the victims, but operator‑confirmed fault coordinates are still forthcoming.
- Repair timeline : Estimates range from days to weeks, heavily dependent on ship availability, weather, and local security conditions. Any specific timeline should be treated as conditional.
For Azure customers, the incident is a pragmatic call to action: verify physical path diversity, harden latency‑sensitive workloads, and keep runbooks ready for disruptions that can last weeks. More broadly, the internet’s backbone has once again proven that it is only as strong as its most vulnerable physical links.