October 2025 delivered a pair of object lessons in cloud fragility within ten days of each other. On 20 October, an issue originating in AWS’s us-east-1 region — rooted in DNS resolution for the DynamoDB service endpoint — cascaded into widespread disruption across dozens of dependent AWS services and the long tail of internet applications that rely on them. On 29 October, Microsoft Azure suffered a major outage tied to its Azure Front Door content delivery and routing layer, degrading access to a broad set of Azure-fronted services. Two different providers, two different root causes, but a shared lesson that the industry keeps having to relearn: the failure domain of a cloud service is almost always larger than the region boundary the architecture diagram implies.

This is not an argument that the cloud is unreliable. By any historical baseline, hyperscaler availability is extraordinary. It is an argument that resilience engineering has to be grounded in how these systems actually fail, not in the regional-isolation mental model that the marketing encourages.

The us-east-1 Gravity Well

The AWS event is the more instructive of the two, because it illustrates a failure mode that surprises teams who believe they have built regional redundancy.

us-east-1 (Northern Virginia) is AWS’s oldest and largest region, and over the years it accreted a special status: a number of global control-plane functions are anchored there. When a regional service like DynamoDB experiences a control-plane disruption in us-east-1, the blast radius is not confined to workloads running in us-east-1. Services elsewhere that depend on global functions homed in that region can be affected, and the internal service-to-service dependencies that hyperscalers do not fully expose mean the cascade propagates in ways that are hard to predict from the outside.

The October DNS issue affecting the DynamoDB endpoint is a textbook example of a control-plane dependency masquerading as a data-plane problem. Many systems treat “my data is replicated across availability zones” as the resilience guarantee. But if the mechanism that resolves or authorizes access to that data depends on a control plane concentrated in one region, the replication does not save you when the control plane is the thing that fails. The data was fine. Reaching it was not.

The general principle: a region is a fault-isolation boundary for the data plane, but it is frequently not a fault-isolation boundary for the control plane. Teams that architect for the former while ignoring the latter discover the gap during exactly these events.

Azure Front Door and the Shared Edge

The Azure Front Door outage illustrates a different but related pattern. Front Door is a global edge layer — it routes, terminates, and accelerates traffic for an enormous number of Azure-hosted applications. When a global edge or routing layer degrades, every application sitting behind it is affected simultaneously, regardless of how well-distributed the backends are across regions.

This is the same structural risk as the AWS case viewed from a different angle. A globally shared service, whether a control plane or a routing fabric, becomes a single failure domain that spans every region it serves. You can run your backends in five regions, but if all five sit behind one global front-end service, that front-end service is your real availability ceiling.

The pattern repeats across providers and across layers: shared DNS, shared identity, shared CDN, shared global routing. Each is a convenience that quietly converts independent regional failures into correlated global ones.

Why Multi-Region Is Necessary But Not Sufficient

The instinctive response to these events is “go multi-region,” and that instinct is not wrong — it is just incomplete. Multi-region deployment defends against the failure of a single region’s data plane. It does not, by itself, defend against:

  • Shared control-plane failures that span regions, like the global functions homed in us-east-1.
  • Shared global services like a CDN or edge router that front all regions at once.
  • Correlated dependency failures where multiple regions depend on the same upstream service that itself fails.

True regional independence requires auditing the full dependency graph, not just the application tier. The questions that matter: Does my failover region depend on any control-plane function in my primary region? Do both regions sit behind the same global front-end? Does my identity provider, my DNS, or my certificate authority introduce a cross-region single point of failure that my data replication does not address?

The single-vendor concentration risk that became impossible to ignore after the CrowdStrike outage in July 2024 applies here too: when a very large fraction of internet infrastructure shares a small number of underlying dependencies, individual organizations’ careful redundancy can be undone by a failure in a layer they neither chose nor control.

Practical Failure-Domain Engineering

Concrete steps that follow from the 2025 events:

  • Map control-plane dependencies explicitly. For each critical service, identify where its control plane lives and whether that location is shared with services you depend on elsewhere. Treat globally homed control-plane functions as cross-region failure domains.
  • Avoid us-east-1 as a control anchor where you can. For AWS workloads, be deliberate about whether global resources (certain IAM, Route 53, and global-service operations) are concentrated in us-east-1, and design failover paths that do not silently route through it.
  • Decouple the global edge. If a single global routing or CDN service fronts all your regions, that service is a failure domain. Multi-CDN or multi-edge strategies, or the ability to bypass the edge layer in a degraded mode, restore independence at the front door.
  • Test failover against control-plane failure, not just data-plane failure. A game-day exercise that kills a region’s compute proves little if the real risk is a control-plane dependency that the exercise leaves intact. Inject control-plane failures and broken dependency resolution, not just node loss.
  • Design for graceful degradation. Static fallback content, cached responses, and read-only modes keep a service partially available when its backing services are unreachable. Full availability during a major provider outage is often unrealistic; partial availability is frequently achievable and far cheaper than true active-active multi-region.
  • Consider cross-provider redundancy for the highest-criticality paths. For the small set of functions where any downtime is unacceptable, the only defense against a provider-wide failure domain is a second provider — accepting the substantial cost and operational complexity that genuine multi-cloud carries.

The Honest Cost Conversation

Every layer of additional resilience costs money, complexity, and operational burden. Active-active multi-region is expensive and hard to operate correctly; the failover paths that are never exercised are the ones that fail when you need them. Cross-provider redundancy multiplies that cost again. The right level of investment is a function of what an hour of downtime actually costs the business, and for most workloads the answer is that graceful degradation plus well-tested single-provider multi-region is the appropriate stopping point.

The mistake the October outages exposed was not insufficient spending on redundancy. It was redundancy aimed at the wrong failure domain — replicating data across zones and regions while leaving a shared control plane or global edge as an unexamined single point of failure. The cheapest resilience improvement available to most teams is not more infrastructure. It is an accurate map of where their dependencies actually concentrate.

Conclusion

The 2025 outages reinforced a lesson that predates the cloud: you cannot engineer around failure domains you have not identified. Multi-region architecture remains a sound foundation, but it defends only against the failures it is designed for. The control planes, global edges, and shared dependencies that span regions are the failure domains that turn isolated regional incidents into internet-wide ones — and they are exactly the parts of the stack that conventional regional-redundancy thinking tends to overlook.

Further Reading

Back to Blog