When the Cloud Becomes a Target: What an Attack on Amazon's Bahrain Data Center Means for Your Disaster Recovery Plan
Iran's IRGC claims it hit Amazon data infrastructure in Bahrain with cruise missiles. Eli the Computer Guy asks the question few IT teams have answered: what happens to your business if AWS goes boom?
Contents
What does your disaster recovery plan say about a cruise missile? For most organizations, the honest answer is "nothing," and a recent news story suggests that might be a blind spot worth fixing.
In a recent video, Eli the Computer Guy digs into a CNBC report that Iran says it attacked Amazon infrastructure in Bahrain. The point isn't the geopolitics. It's what this means for those of us who design, run, and depend on cloud infrastructure, and whether we've been taking physical security and resiliency for granted.
Source video: "Iran Destroys Amazon Data Center in Bahrain - USA Big Tech Targets of War" by Eli the Computer Guy (19:29). All credit for the original commentary goes to Eli. This post summarizes his key points.
What Happened
According to the report Eli covers, Iran's Islamic Revolutionary Guard Corps (IRGC) said it attacked Amazon's data infrastructure in Bahrain. The Fars news agency quoted the IRGC as saying it had "attacked the central data infrastructure of the American company Amazon in Bahrain with several cruise missiles and destroyed it."
Eli is quick to flag that this is an IRGC claim and should be treated as propaganda. In the same breath, he argues that every side's messaging during a conflict is propaganda, and that open-source intelligence such as satellite imagery often tells a different story than official statements do.
He also points to a related event: Ukraine's strike on a warehouse belonging to Wildberries, which he describes as Russia's version of Amazon. Per Eli, the attack killed seven employees, injured roughly 30 more, and set the entire warehouse on fire.
The common thread is that civilian technology and logistics infrastructure is increasingly ending up in the line of fire.
Tech Talks About "War," But Doesn't Prepare for It
Eli got into technology through the army and later earned a criminal justice degree before the dot-com era pulled him into IT. From that background, he calls out a contradiction in tech leadership: founders and CEOs like to say "we're already at war," yet many of them:
- Don't harden their infrastructure
- Don't have counterintelligence capability inside their organizations
- Ignore the real-world security implications of the very scenario they keep talking about
His challenge is simple: if we actually are at war, how do you build your systems for resiliency in that environment?
Centralization vs. Decentralization
This is the core technical idea of the video, and it's a trade-off every architect should be able to explain.
Centralization puts resources in one place. That's generally more efficient and cost-effective, because support is easier and cheaper and people and equipment are close together. It's why big data centers and big warehouses exist.
The problem is that centralization is also a massive vulnerability. If one large facility "goes boom," whether from a missile or, as Eli notes, a disgruntled employee setting stock on fire (something he says happened in the US about two months earlier), all of your resources go down with it.
Decentralization spreads resources across many sites. It costs more: more facilities, more links between them, probably more employees, and much more friction overall. But if one site is lost, a properly designed disaster recovery setup keeps things moving, sometimes so smoothly that end users never notice an entire data center disappeared.
Plan for Degradation, Not Just Uptime
Eli frames resiliency in terms of how much capacity you lose:
| Capacity lost | Likely outcome |
|---|---|
| 10% | You apologize to customers, maybe offer discounts, but the business keeps going |
| 50% | Real damage, but you can probably limp along until things cool down |
| 100% | You've basically lost your business |
The goal isn't necessarily perfect uptime. It's making sure a catastrophic event degrades your service instead of ending it.
The Unasked Question: What If Multiple Regions Go Down?
Over the past 15–20 years, Eli notes, we've moved into an "AWS world." Infrastructure as a service lets companies stop managing their own servers, routers, and firewalls. The reasoning is that Amazon, Azure, and the other big providers can invest more in security, resiliency, and replication than any single company can.
But he raises something we haven't seen yet: coordinated attacks on multiple data centers at the same time.
So far, the incidents have involved a single data center being hit. Eli points out that with open-source intelligence work, an adversary could probably work out where a cloud provider replicates data and where failover happens. Then what?
"No Eli, but we invested in multiple regions." What if multiple regions go boom?
He takes it further. Both AWS and Azure hold massive contracts with the federal government, intelligence agencies, and the Pentagon. In a conflict with a peer adversary like China, why wouldn't those facilities be targets? And if they were, what happens to every business that depends on them?
Physical Security Isn't Just Biometrics
Eli also asks data center operators to think about threats at ground level. Biometric locks, raised floors, redundant power supplies, and dozens of fiber connections make a facility feel highly secure. But what happens if a couple of armed people simply walk up to it? He ties this to a history of domestic terrorism in the US and argues that physical threat modeling deserves more attention than it gets.
Announcing Your Weak Spot
One of the sharper points in the video concerns the "AI race." Eli disagrees with the argument, which he attributes to both the Trump and Biden administrations, that whoever wins the AI race wins global supremacy. Whatever you think of that argument, he says, repeating it loudly tells the world exactly where your weakness is: your AI data centers.
He asks pointedly whether the big AI companies have a disaster recovery plan for an AI data center being destroyed.
We've Been Recentralizing the Internet
Eli closes with a bit of history. The internet and TCP/IP were built around decentralized communication. Older communication infrastructure ran through central offices, and if one of those went down, it caused massive problems. Decentralization was the fix.
His argument is that we've spent years recentralizing everything into a small number of hyperscale cloud providers, and that this reintroduces the exact single points of failure the internet was designed to avoid.
Takeaway: Have the Conversation
Eli's practical advice for technology decision makers fits in one question: have you sat down with your CEO and discussed what happens if AWS goes boom?
Based on his points, that conversation should cover:
- Concentration risk. How much of your business depends on one provider, one region, or one facility?
- Degradation targets. Can you survive losing 10% of capacity? 50%? What's your plan for each?
- Correlated failures. Does your multi-region strategy assume regions fail independently? What if they don't?
- Physical threats. Does your threat model include more than hackers?
Whether or not the IRGC claim holds up, Eli's broader warning stands: civilian tech infrastructure is becoming a target, and "the cloud will handle it" isn't a disaster recovery plan.
Watch the full video from Eli the Computer Guy for his complete commentary.
