Logistics & Supply Chain

One Region Fails, Half of the Supply Chain Grinds to a Halt

A cloud concentration risk is a supply chain risk. What the us-east-1 outage teaches and why a tested multi-region setup is usually better.

By Andreas Knols July 12, 2026 4 min read

One Region Fails, Half of the Supply Chain Grinds to a Halt

On 20 October 2025, part of the internet ground to a halt. Slack, Snapchat and Atlassian were unreachable for hours, online shops lost orders, and logistics services couldn’t process shipments. The trigger sat in a single AWS region on the US east coast. The outage exposes an uncomfortable truth: cloud concentration isn’t just an IT issue-it’s a supply-chain risk.

Key Takeaways

A single region is enough. The October 2025 AWS outage began with an empty DNS record in us-east-1 and took down Slack, Snapchat and thousands of online shops for more than 15 hours.
Concentration is a supply-chain risk. Inventory management, shipment tracking and payment processing all run through the cloud. When the cloud stalls, so does the physical supply chain.
Multi-cloud is rarely the answer. A second provider doubles complexity and cost, not resilience. For most mid-sized firms, a tested multi-region setup is the better first step.

What happened in us-east-1

The outage started with a tiny error in the DNS management of the DynamoDB database service. A race condition produced an empty DNS record for the regional endpoint. Automation didn’t fix it. DNS is the internet’s phone book. With the entry blank, applications simply couldn’t locate the database.

What began as a three-hour database glitch cascaded outward. EC2 instances refused to launch, Lambda functions and Fargate tasks failed, load balancers and container services collapsed. The initial disruption stretched to more than 15 hours before every dependent service recovered.

How one region can paralyse half the world

us-east-1 is no ordinary region. It’s the oldest and largest AWS region and hosts control-plane functions on which other regions depend. Global services such as IAM updates or DynamoDB Global Tables run centrally out of us-east-1. When it goes down, customers who think they’re hosted elsewhere feel the pain.

That’s the blind spot in many disaster-recovery plans. A company can distribute its application cleanly across multiple regions yet still get snagged because the control plane is concentrated in one place. Paper resilience is not the same as real-world resilience.

The supply-chain problem behind the IT outage

For logistics and retail, such an outage isn’t abstract tech trouble. Warehouse management, shipment tracking, order intake and payment processing increasingly rely on cloud services. When the cloud stops, so does the physical supply chain. One hour of downtime can cost a mid-sized retailer five figures in euros; for larger players the bill is far higher.

Regulators have noticed. With DORA for the financial sector and the broader NIS2 directive, concentration risk is moving into the spotlight. Companies must now prove they understand and manage their dependence on single providers and single regions. A blanket “we’re in the cloud” answer no longer suffices.

Why Multi-Cloud Isn’t Always a True Safeguard

After an outage like this, the knee-jerk reaction is “multi-cloud.” Yet running two providers in parallel doesn’t halve your risk-it doubles complexity and cost without automatically doubling security. If the real dependency sits in a shared control plane or a central service, a second provider does little to help.

Instead, ask the honest question: which services are truly critical, and what real dependencies do they have? For most mid-sized companies, a clean multi-region setup with the existing provider is a better first step than an expensive second-cloud project that nobody has ever rehearsed in earnest.

What Logistics IT Should Check Now

Three questions belong on the table. First: which of our processes grind to a halt if a single cloud region fails? Second: do we have hidden dependencies on central services like IAM or DNS that are regionally concentrated? Third: have we ever tested failover under real-world conditions, not just in a slide deck?

If you can’t answer these, you don’t have a resilience plan-you have a hope. The October 2025 outage was an expensive reminder that the cloud doesn’t absolve you of responsibility for uptime; it merely shifts it elsewhere.

Frequently Asked Questions

What is a cloud concentration risk?

A concentration risk arises when too many critical processes rely on a single provider, region, or central service. If that one point fails, a disproportionate amount of your stack collapses. The AWS outage of October 2025 is a textbook example.

Why was us-east-1 so consequential?

us-east-1 is AWS’s oldest and largest region, hosting global control functions on which other regions depend-think IAM updates and DynamoDB Global Tables. A failure there ripples far beyond its borders.

Does multi-cloud protect against such outages?

Not automatically. Multi-cloud doubles complexity and cost yet doesn’t remove dependencies that live in a shared central service. For many firms, a tested multi-region setup with the incumbent provider is the better first move.

What does regulation require here?

DORA in financial services and NIS2 more broadly demand that companies know and manage their dependencies on single providers and regions. A blanket “we’re in the cloud” no longer suffices; the concentration risk must be documented and controlled.

How do I test cloud resilience properly?

Only a failover that has been rehearsed under real-world conditions is a real failover. Simulate the loss of an entire region and see which processes survive-and which hidden dependencies surface. A failover playbook without a test is just a wish list.