On September 6, 2025, Microsoft confirmed that multiple undersea fiber optic cable cuts in the Red Sea were degrading performance for Azure customers, warning of "higher latency on some traffic that previously traversed through the Middle East." The disruption forced the cloud provider to reroute data onto longer, often more congested alternate paths, injecting tens to hundreds of milliseconds of additional delay into Asia–Europe and Asia–Middle East connections.

Microsoft's advisory, posted through its Azure Service Health channel, stressed that traffic not crossing the affected corridor remained unaffected. But for enterprises reliant on real-time replication, VoIP, or interactive applications between the continents, the spike in round-trip time (RTT) and jitter immediately raised alarms. The incident underscores a persistent vulnerability: the physical arteries of the internet remain a critical, and sometimes fragile, foundation for cloud services.

What Happened — The Operational Facts

The Azure status update was unambiguous. “We do expect higher latency on some traffic that previously traversed through the Middle East,” the company stated, adding that affected flows had already been rerouted and that daily updates would follow. Independent network monitors and multiple press outlets, including Reuters and the Associated Press, quickly corroborated that several high-capacity submarine cables crisscrossing the Red Sea had sustained damage.

The timing was telling. By Saturday evening local time, Downdetector recorded a spike in outage reports from UAE-based users of e& and du, though it remained unconfirmed whether those consumer outages were directly linked to the cable faults. What was clear, however, was that Azure’s data-plane traffic—the payload that carries customer data—was not failing entirely but instead slowing down noticeably, with error rates and retry requests climbing as applications timed out waiting for responses.

Which Cables and What Remains Uncertain

While neither Microsoft nor cable operators have released a definitive list of damaged systems, historical patterns and real-time network telemetry point toward several high-profile cables. The Red Sea corridor hosts a dense cluster of east–west trunks, including AAE-1, PEACE, EIG, SEACOM, and multiple regional branches. Any or all of these could be among the affected systems. Monitoring services like BGP.tools and submarinecablemap.com typically show aggregated path changes when such events occur, but authoritative fault location data often lags behind early news reports.

The cause of the damage is similarly provisional. Initial speculation ranged from accidental anchor drags to deliberate sabotage, but authoritative attribution requires on-site forensic inspection by repair ships—a process that can take weeks. Past incidents in the region have been traced to everything from abandoned fishing gear to military activity, and experts caution against jumping to conclusions before cable owners and neutral parties release confirmed findings.

Technical Anatomy — Why This Matters to Cloud Users

When a subsea cable is severed, the internet’s routing protocols kick into action. BGP (Border Gateway Protocol) recalculates the shortest path, but with a critical physical link missing, that “shortest” path now detours through longer fiber spans, often via terrestrial backhauls or cables that circle the Horn of Africa. This cascade of changes introduces several degradations:

  • Increased RTT: Light travels through glass at roughly 200,000 km/s, so every extra 100 km of fiber adds about 0.5 ms of one-way delay. A detour of several thousand kilometers can easily tack on 20–50 ms or more.
  • Jitter and packet loss: Congested alternate paths suffer from queuing delays and occasional drops, especially during peak traffic hours. Applications that rely on steady packet streams (voice, video, real-time gaming) are hit hardest.
  • Amplified application errors: Many enterprise apps use fixed, aggressive timeout settings. When RTT doubles or triples, requests begin to fail, triggering cascading retries that further saturate the already strained network.

Microsoft Azure, like other hyperscale clouds, operates a globe-spanning backbone with redundant logical paths. But logical redundancy still depends on physical fiber. When multiple cables in a narrow chokepoint fail simultaneously, the redundancy model gets stress-tested, and client-visible performance degradation—rather than a binary “outage”—becomes the likely scenario.

Microsoft’s Immediate Response and Mitigation

The cloud provider’s public mitigation playbook for this incident includes several standard but crucial steps:

  • Dynamic rerouting: The Azure backbone automatically shifted traffic onto alternate submarine and terrestrial routes, leveraging peering relationships with other carriers.
  • Capacity rebalancing: Engineers worked to redistribute load across available paths, moving latency-insensitive bulk transfers to less congested routes where possible.
  • Control-plane prioritization: Management, monitoring, and orchestration traffic was given higher priority to ensure that users could still access portals, APIs, and configuration tools.
  • Transparent communication: Microsoft committed to daily status updates (or sooner if conditions changed), a practice that helps IT teams make informed triage decisions.

These measures likely prevented a full-scale outage. However, they cannot magically create new fiber capacity. The alternate paths are inherently longer and may already carry significant background traffic, so elevated latency and variable performance will persist until the damaged cables are repaired or supplementary capacity is brought online.

Repair Timeline Realities — Why Fixes Take Time

Submarine cable repair is a slow, specialized, and logistically complex operation. Even under ideal conditions, it follows a rigid timeline:

  • Location and mobilization: A cable repair ship must first be dispatched to the general fault area, which can take days depending on its current location. The global fleet of repair vessels is limited—often just a few dozen ships worldwide.
  • Safe access and permits: The Red Sea crosses areas of geopolitical tension and busy shipping lanes. Securing permission to work in national waters and ensuring the safety of the repair crew can introduce significant delays.
  • Splicing and testing: Once on site, the ship must grapple the cable, haul it to the surface, splice in a new section, and then carefully lower and rebury it. Each splice requires meticulous optical alignment and testing. Depending on water depth and damage extent, this phase can consume several days.
  • Post-repair validation: After the physical repair, operators run extensive end-to-end tests to confirm signal integrity and re-integrate the cable into the global mesh.

Industry veterans rarely offer firm repair ETAs early on. Microsoft’s daily updates will be the most reliable indicator of progress, but IT planners should assume that impacts could linger for one to three weeks, and possibly longer if additional complications arise.

Who and What Is Most Exposed

Not all Azure customers are affected equally. The impact is concentrated on:

  • Geographic flows: Any traffic that normally takes the Red Sea shortcut—primarily between Asia and Europe, and between the Middle East and either continent—will see noticeable slowdowns. Intra-region traffic within North America or within Europe is largely untouched.
  • Workload types: Synchronous database replication (e.g., SQL Server Always On, Cosmos DB multi-region writes), real-time communications (Microsoft Teams, Zoom, VoIP), and “chatty” microservice APIs that issue many small, sequential calls are the first to degrade. Less latency-sensitive workloads, like batch data processing or asynchronous backups, may go unnoticed.
  • Architecture patterns: Single-region deployments that rely on cross-region services without proper caching or queuing are at highest risk. Conversely, multi-region active-active configurations, edge-cached static assets via CDN, and services built with idempotent retry logic and exponential backoff will fare much better.

Enterprise IT teams using ExpressRoute or private peering should verify with their connectivity providers whether their circuits normally traverse the Red Sea corridor. Some carriers may offer alternative terrestrial paths via Saudi Arabia, Israel, or Egypt that could bypass the worst congestion.

Actionable Guidance for IT Teams

Given the uncertainty around repair timelines, IT leaders should act now to mitigate business impact. A tiered approach based on workload criticality is advisable:

  1. Monitor proactively: Subscribe to Azure Service Health alerts for your subscriptions and any dependent regions. Set up dashboards that track cross-region latency metrics if available.
  2. Harden timeouts and retries: Adjust socket and API timeouts upward for cross-region calls. Enable exponential backoff with jitter to prevent thundering herd retries. Avoid polling-based interactions; move to event-driven patterns where feasible.
  3. Shift traffic locally: Redirect users to the nearest regional endpoint. Leverage Azure Front Door, CDN profiles, or regional load balancers to serve static and dynamic content from caches collocated with end users.
  4. Temporarily relocate synchronous workloads: If business continuity demands sub-second replication, consider failing over to paired regions within the same continent until latency normalizes. This may involve a short maintenance window and data consistency checks.
  5. Engage support and document impact: Open high-severity tickets through the Azure portal for mission-critical applications. Log all observed latency anomalies, error rates, and business impact—these records may be required for service credit claims or contractual remedies later.
  6. Validate routing with carriers: For ExpressRoute circuits, ask your provider to confirm the physical fiber path and inquire about alternative routes that avoid the Red Sea. Some carriers can manually steer traffic onto less congested paths for premium customers.

Broader Implications for Cloud Architecture

This incident is more than a momentary nuisance; it reinforces a hard truth about cloud resilience. Despite the abstraction of virtual networks and availability zones, the underlying connectivity between regions is still a patchwork of physical cables that snake through geopolitical chokepoints. The Red Sea is one such chokepoint, alongside the Strait of Malacca, the South China Sea, and the Suez Canal region.

For enterprises, the lesson is threefold:

  • Physical route diversity matters: Relying on a single cloud provider or carrier may not be enough if all logical paths converge on the same physical fiber ducts. Multi-cloud and multi-carrier strategies, with explicit audits of physical path diversity, should become standard for latency-critical applications.
  • Resilience must be architected, not bolted on: Active-active multi-region deployments, stateless services, idempotent operations, and graceful degradation pathways are design principles that pay dividends during events like this. Teams that have already implemented the Well-Architected Framework’s reliability pillar will be in a stronger position.
  • Policy and industry coordination lag behind: The world’s fleet of cable repair ships is aging and limited. Governments and consortia should explore incentives to expand repair capacity and to establish emergency fast-track permits for repairs in sensitive regions. Without such cooperation, a single corridor failure could cascade into weeks of degraded service for billions of users.

What’s Confirmed and What’s Provisional

As with any fast-moving network incident, it’s important to separate fact from speculation:

  • Confirmed: Microsoft issued a Service Health advisory on September 6, 2025, citing “multiple undersea fibre cuts in the Red Sea” and warning of higher latency. Independent sources, including Reuters and the Associated Press, reported multiple cable faults and user-visible slowdowns. Microsoft has rerouted traffic and is providing daily updates.
  • Provisional: The exact list of damaged cables, the precise fault locations, and the root cause of the cuts have not been officially confirmed by cable operators. Early media claims about sabotage or a single attacker remain unverified and should be treated with caution until forensic evidence is made public.

Looking Ahead

Microsoft’s engineering response—rerouting, rebalancing, and frequent communication—is the correct playbook to keep Azure running through a major physical infrastructure disruption. However, the ultimate return to baseline latency hinges on factors beyond any single company’s control: the speed of maritime repair logistics, the cooperation of regional authorities, and the residual capacity of alternate paths.

For Azure customers, the coming days will require vigilance and tactical adjustments. The immediate priority is to shield user-facing applications from the worst of the latency surge. Over the longer term, this Red Sea incident should serve as a catalyst to invest in genuine physical route diversity, rigorous multi-region failover testing, and application architectures that treat network geography as a first-class design constraint.

As one network engineer quipped on a specialist forum, “The cloud is just someone else’s computer—and sometimes that computer is connected by a really long, really fragile piece of glass at the bottom of a contested sea.” For now, IT teams would do well to keep a close eye on Azure Service Health and keep their retry logic close.