The AWS incident: it was not an outage, it was a reality check
Venmo, Fortnite, Snapchat, Zoom, Coinbase... everything started to crash. Not because of ransomware, a large-scale attack or a geopolitical conflict.
Venmo, Fortnite, Snapchat, Zoom, Coinbase... the entire AWS ecosystem started to crash. Not because of ransomware, a large-scale attack or a geopolitical conflict. No. Because a network component in AWS US-EAST-1 went off the rails.
People call it a "technical incident". I call it a symptom. And an admission of systemic fragility.
It was not a hack. It was worse.
When there is an attacker, you can identify an adversary, a vector, an intent. Here, there was none of that. Just a small internal glitch, with massive consequences.
No noise. No alert. Just a brutal silence. And an entire global ecosystem grinding to a halt. Because a single geographic zone concentrates too many dependencies.
That is the real danger. Not the hacker. The silent technical monopoly.
The cloud is not magic. It is mechanical.
Many organisations adopted the cloud the way you take a sleeping pill: to sleep easy. Less infrastructure, less complexity, less cost.
But what we gained in comfort, we lost in control.
Today, a large majority of companies do not know what their services really depend on. They use "off-the-shelf" digital tools, interconnected, stacked, often of external origin. But deep down, everything rests on a few very localised zones, always the same ones.
And those zones, too, can go down.
A governance crisis before a technical one
What this incident reveals is our lack of rigour on critical matters:
- We outsource without a fallback strategy.
- We pile up tools without any real contingency plan.
- We trust blindly without asking the right questions.
In a crisis, it is not the tool that makes the difference. It is the ability to understand fast, to pivot, to decide.
And for that, you need readable maps. Not obsolete diagrams in a folder no one can find.
The three blind spots no one likes to look at
- Geographic concentration: too much data, too many services, too many customers rest on a single critical point. That is not a "hosting strategy", it is a bottleneck.
- The illusion of redundancy: believing you have an alternative when, in fact, everything runs through the same invisible structures (connections, authentications, flows).
- The autonomy deficit: we do not train teams to operate without their favourite tools. The day the tool fails, everyone just waits for it to come back.
Amazon is not the problem. Our collective passivity is.
Amazon does what Amazon must do: optimise, industrialise, deliver.
But it is up to us to keep an architecture designed for failure. It is up to us to reduce the dependent surface. It is up to us to know what happens if our favourite provider has a bad Monday.
The question is not "when will AWS go down again", but "will you be able to cope without it for a few hours?"
Learn more about Christophe Mazzola
Questions fréquentes
What caused the AWS incident?
It was neither ransomware, nor an attack, nor a geopolitical conflict. A network component in the AWS US-EAST-1 zone went off the rails, an internal glitch with global consequences.
Why does the author consider this incident more worrying than a hack?
Facing an attack, you can identify an adversary, a vector and an intent. Here there was nothing to analyse: just a brutal silence revealing a systemic fragility and a silent technical monopoly.
How is this a governance crisis rather than a technical one?
Because we outsource without a fallback strategy, we pile up tools without a contingency plan, and we trust without asking the right questions. In a crisis, what matters is the ability to understand, pivot and decide, not the tool.
What are the blind spots to watch?
Geographic concentration on a single critical point, the illusion of redundancy when everything runs through the same invisible structures, and the lack of autonomy of teams unable to operate without their usual tools.
What question should we ask instead of "when will AWS go down?"
The right question is: "will you be able to cope without it for a few hours?" It is about reducing the dependent surface and keeping an architecture designed for failure.
Sources & méthodologie
L’auteur
Christophe MazzolaJ’écris sur la cybersécurité telle qu’elle se vit vraiment : gouvernance, facteur humain, et tout ce que les rapports d’audit n’osent pas dire au COMEX. Auteur de « Être en cybersécurité ».
Être en cybersécurité
Une feuille de route cyber en clair, pour tout le monde, pas seulement les experts.