The Internet's Bad Year: What the Major Outages of 2025 Taught Us About Resilience

If you run infrastructure for a living, 2025 felt like a stress test. Outages weren't just more frequent, they came from completely different places. A power grid, a DNS bug inside a hyperscaler, and damaged undersea cables each knocked services offline, and no single fix could have stopped all three.

Those events are the starting point for Designing for Platform Resilience in an Unpredictable World, the whitepaper we wrote with the NS1 team at IBM. Here's what each one taught us.

When the grid goes down, the network follows

On April 28, 2025, a sudden grid disturbance cut power across most of Spain and Portugal. Data centers, IXPs, and access networks lost electricity at the same time, and millions of people went offline.

We monitored it on our network to gauge and ameliorate the impact to customers. Our Madrid site hit momentary generator issues, and regional transit became unstable as backup power ran out at remote, unmanned carrier sites such as fiber amplification points. Unique source IPs from Spain dropped by up to 75%. Most of that traffic didn't reroute. It simply vanished, because users lost power before they could fall back to another path.

For services that stayed reachable, our global Anycast platform did exactly what it was built to do. It automatically redirected traffic to the nearest healthy locations, mostly Paris and London, with no manual intervention. Direct peering also outperformed transit throughout the event, a reminder that who you're connected to matters as much as how many paths you have.

When a DNS bug takes down a cloud

In October 2025, a defect in internal DNS automation supporting DynamoDB disrupted service discovery in AWS US-EAST-1. The failure cascaded across EC2, Lambda, IAM, and dozens of other core services, then rippled out to thousands of dependent platforms, from messaging apps and gaming services to financial systems.

The lesson is that tightly coupled cloud control planes can turn one bug into a global event. If your architecture is single-cloud, single-region, or dependent on a single DNS provider, you inherit that blast radius.

When the cables are cut

Undersea cables carry more than 99% of intercontinental data traffic, and they're damaged hundreds of times a year, usually by fishing vessels or dredging. On November 17, 2024, a cable linking Sweden and Lithuania and another linking Finland and Germany were damaged in a suspicious incident in the Baltic Sea. Where routes are redundant, events like this rarely cause full outages, but they do drive up latency and packet loss. Redundancy limits the blast radius but it doesn't erase it.

Different failures need different defenses

Put these three events side by side and a pattern emerges. The blackout was a reachability problem. The AWS outage was a control-plane problem. The cable damage was a performance degradation problem. Each called for a different mitigation path.

That's why the whitepaper we developed with IBM NS1 makes the case for designing resilience across three layers: BGP Anycast to keep traffic reaching a viable entry point, authoritative DNS to control which endpoints are eligible to be returned, and traffic steering to choose the best endpoint based on health, performance, and business context. No single layer covers every failure mode. Together, they cover far more.

Go deeper

Read the full whitepaper, free and ungated, including a practical SRE checklist for multi-layer resilience.