An AWS data center was set on fire by a drone. SLA won't help
Contents
On March 1, 2026, AWS’s Middle East region (ME-CENTRAL-1/UAE, ME-SOUTH-1/Bahrain) was physically destroyed by a drone attack. This is the first time in history that cloud infrastructure has been damaged by military action.
It’s a nightmare for people who thought they were safe because it was in the cloud, but the nightmare was even worse when they read the contents of the SLA.
what happened
On February 28, the United States and Israel carried out a large-scale attack on Iran (Operation Epic Fury). In retaliation, Iran fired drones and missiles at U.S. military bases and civilian infrastructure across the Gulf (Operation True Promise 4).
The damage to AWS is as follows.
- ME-CENTRAL-1 (UAE): 2 facilities were directly hit by drones. A fire broke out and the fire department cut off the main power supply and emergency generator. Water damage caused by firefighting activities
- ME-SOUTH-1 (Bahrain): Physical damage caused by blast from nearby impact. Single AZ power outage spreads
38 services are out of order in the UAE region and 46 services are out of order in the Bahrain region. Major services such as EC2, S3, RDS, Lambda, EKS, and VPC were all down. AWS recommends customers “back up their data and migrate to another region” and warns that “the operating environment remains unpredictable.”
As a result of spillover damage, financial institutions such as Anthropic Claude (front end went down globally), Snowflake, Emirates NBD, and ADCB were also affected.
SLA won’t help
“war” is specified in the force majeure clause
AWS Customer Agreement Section 11.3:
Except for payment obligations, neither party nor any of their affiliates will be liable for any delay or failure to perform any obligation under this Agreement where the delay or failure results from any cause beyond its reasonable control, including acts of God, labor disputes or other industrial disturbances, electrical or power outages, utilities or other telecommunications failures, earthquake, storms or other elements of nature, blockages, embargoes, riots, acts or orders of government, acts of terrorism, or war.
war'' and acts of terrorism” are explicitly listed. No matter how you look at it, this drone attack falls within the scope of force majeure, and AWS has no obligation to provide services. Not eligible for SLA credits.
The destructive power of “Except for payment obligations”
The phrase “Except for payment obligations” at the beginning of this clause is really harsh.
In other words, this is what happens.
- AWS obligation (to provide services) → exempted by force majeure
- Customer’s obligation (to pay) → not exempted even by force majeure
Customers continue to pay even if the service is down. That’s what the contract says.
Things that continue to be charged even though they are stopped
Reserved Instance (RI) is a contract to reserve capacity,'' not a contract where you pay only for what you use.” If you pay in full in advance, you have already paid for 1/3 years and there are no refunds. Hourly charges continue even if you pay monthly. Even if the instance doesn’t physically exist.
Same goes for Savings Plans. The committed amount will be charged regardless of usage.
EBS volumes are charged as long as the volume exists even if the attached EC2 is dead. S3 is also charged as long as the data exists.
Only On-Demand instances are not charged while they are stopped, but there are very few companies that run production using On-Demand in the first place. You’re supposed to be buying RIs and Savings Plans to optimize costs, but it backfires.
SLA credits are not compensation in the first place.
What will happen even if force majeure is not applied and SLA credits are issued?
According to Uptime Institute analysis, the average cost of downtime is 40M or more.
On the other hand, AWS SLA credits look like this.
- Monthly uptime less than 99.0% (down for 7 hours and 18 minutes or more): 10% of the monthly fee
- Monthly uptime less than 95.0% (down for 36 hours or more): 30% of the monthly rate
If your 1 in credits. Moreover, the credits are not cash, but service credits that can only be used with AWS. You can’t get it unless you measure your own downtime and apply.
Additionally, RI prepayments are excluded from SLA credit calculations. The most expensive expenditure is not included in the calculation of compensation.
SLA credits are only a “penalty” rather than “compensation.” The amount is designed to have little impact on the provider’s profits and does not cover actual losses suffered by the customer. And this time it’s force majeure, so even that penalty won’t occur.
Multi-AZ was also powerless.
AWS Availability Zones (AZ) provide redundancy against logical and software failures. The power supply system is independent and physically separated.
However, this time, 2 out of 3 AZs in the UAE region were simultaneously hit by drones. Even for customers who had a multi-AZ configuration, the entire region became unusable.
AZ’s design philosophy is to “withstand failures in individual data centers,” and does not assume a case in which “the entire region becomes a battlefield.” Multi-AZ only provides redundancy within a region and cannot deal with the risk of the region itself disappearing.
So what should I do?
AWS 4-stage DR pattern
AWS defines a four-stage DR strategy in its official whitepaper.
1. Backup & Restore (lowest price, RPO/RTO: hours to days)
Back up only the data in another region and rebuild the entire infrastructure in the event of a failure. The basic idea is to copy S3 Cross-Region Replication (CRR) or RDS snapshots to another region.
Cost: $0.02/GB (US-to-US) for S3 inter-region transfers. Middle East → Europe is a little more expensive. Storage costs are doubled. Although it takes time to recover, it is effective as a minimum to ensure that no data is lost.
2. Pilot Light (low to medium cost, RPO/RTO: minutes to hours)
Only the core parts (DB, etc.) are kept running in a separate region. Deploy and switch application tiers to different regions in the event of a failure.
Data is always replicated and infrastructure is instantly deployable with IaC. For many organizations, this is the realistic line.
3. Warm Standby (medium to high cost, RPO/RTO: minutes)
A reduced version of the production environment is always running in a separate region. Scale up and switch during failures. Combine Route 53 health checks and failover routing.
4. Multi-Site Active/Active (highest cost, RPO/RTO: almost zero)
Process production traffic in multiple regions simultaneously. Ideal, but the infrastructure costs are almost double. Applications also need to be designed to support multiple regions, making data integrity management complicated.
What you should do at least
Active/Active is ideal, but for many organizations the cost is not worth it. At least consider the following.
- S3 CRR: Replicate only the data to another region. Data remains even if the region disappears
- RDS Cross-Region Read Replica: Real-time DB replication. Can be promoted to primary in case of failure
- IaC preparation: If you fully code your infrastructure with CloudFormation or Terraform, you can deploy to another region in minutes.
- Route 53 Failover: Automatic switching configuration at DNS level
Is multicloud realistic?
Multi-cloud DR, such as “If AWS doesn’t work, switch to Azure,” is theoretically the strongest, but in reality it’s quite difficult. If you depend on each provider’s managed services (RDS, Lambda, EKS, etc.), you will not be able to use another provider as is. You need to make it portable with Kubernetes + Terraform, or create a multi-cloud based architecture from the beginning.
Since costs and operational loads will skyrocket, “multi-region services from the same provider” is a realistic option unless there is a very good reason.
Data sovereignty issues
If the reason for using the Middle East region is “legal requirements to store data in the Middle East,” migrating to another region will not be so easy. If there are restrictions on the transfer of personal data overseas, such as the UAE’s data protection law or Bahrain’s PDPL, legal confirmation will be required to determine whether replication to the European region is possible, even for DR purposes.
If you set up just S3 CRR, the data will remain even if the region physically disappears. It’s cheap when you consider that the premium is only a few dollars a month.