AWS says some customer data is gone for good. What do you hold outside your region?

On 15 September 2026, Amazon Web Services (AWS) told customers that some data hosted only in its Bahrain region, as well as data stored in one availability zone in its UAE region, could not be restored. Multi-AZ protection worked as designed. It protects against the loss of an individual availability zone within a region, but it does not protect against a wider regional failure.

For small teams, the key question is not whether AWS is reliable. The more important question is what data you keep outside the AWS region you normally operate in. A regional outage can leave data unavailable even when your applications are designed to use multiple availability zones.

Imagine your business is a castle. AWS gives you a castle with several towers. If one tower collapses, the other towers can keep the castle operating. That's Multi-AZ: spreading your systems across multiple Availability Zones within the same AWS region.

But all your towers are still inside the same castle. If the entire castle is destroyed, the towers don't help you. That's the regional failure problem. So you build a small backup castle somewhere else.

You keep:

• a copy of your important possessions
• the building plans
• the tools
• the keys
• the instructions for rebuilding

That's your off-region backup. However, there's one more thing: you actually practise rebuilding the castle. If you discover during the practice that you've lost the keys, the building plans are outdated and nobody knows how to reconstruct the walls, that's good. This is because you've discovered the problem before the real disaster.

Don't just ask whether AWS has a backup of your data. Ask whether your team could actually rebuild the business if your AWS region disappeared.

Key facts

In this article

• What AWS said on 15 September, and what gone for good means
• What availability zones and regions actually promise
• What a startup should hold outside its region
• What the minimum off-region posture costs
• How to test that a backup restores
• Where RocketDevs fits
• Conclusion
• Frequently asked questions

What did AWS say on 15 September, and what does gone for good mean?

AWS said it cannot restore access to resources and data hosted exclusively in its Bahrain region. It also said it cannot restore data hosted exclusively in one of the three availability zones in its UAE region. In practical terms, “gone for good” means that if the only copy of the data was stored there, there is no other copy to recover.

This wording came from AWS’s Health Dashboard and was reported by The Register, Help Net Security, The National and Techzine within two days. For the Bahrain region, me-south-1, AWS said that it was unable to restore access to resources and data hosted exclusively in that region. AWS also explained that the damage affected multiple availability zones and went beyond what its regional and multi-AZ services are designed to withstand.

The situation in the UAE is more limited. AWS said it could not restore resources and data hosted exclusively in mec1-az2, one of the three availability zones in the me-central-1 region. Work continued on the other two zones and on shared regional infrastructure.

The events leading to this point unfolded over several months.

The March reporting is important because it showed the extent of the disruption months before AWS confirmed that some data could not be recovered. InfoQ reported that two of the three availability zones in me-central-1, mec1-az2 and mec1-az3, were impaired, while mec1-az1 remained operational. It also reported that one facility in Bahrain had been affected.

AWS has also explained how customers were able to recover. The company told The National that most customers had been able to restore operations in other regions by using backups or copying data that remained accessible. This highlights the importance of having data available outside the region where your main systems operate.

However, AWS has not published how many customers lost data permanently or how much data was affected. Its statement only describes the customers who were able to recover and does not provide figures for those who could not.

What do availability zones and regions actually promise?

An availability zone is designed to protect you if one location fails. A region does not protect you from a failure that affects the region itself. AWS makes this distinction clear in its documentation. The Bahrain incident did not show that Multi-AZ protection failed. It reached the boundary of what Multi-AZ is designed to protect against.

AWS describes each region as being isolated from other regions. It also states that resources are not automatically replicated between regions. Its guidance on availability zones explains that running EC2 instances across multiple zones can protect an application from the failure of a single location within a region. That protection applies to a single location. It does not extend to the entire region.

S3 provides another clear example. AWS says that S3 stores objects across at least three availability zones within an AWS region. These zones are physically separated by many kilometres, although they remain within 100 km of one another. The familiar “eleven nines” durability figure is also limited to this design. Standard S3 storage classes are designed to withstand the loss of an entire availability zone. That durability does not mean your data is protected if the entire region is affected.

This is not unique to AWS. Google Cloud uses a similar structure. Its regions consist of separate zones, and spreading resources across those zones reduces the risk of an infrastructure outage affecting everything at once. For protection beyond a single region, Google points customers towards backup services in another region.

The reason this distinction can be easy to miss is that redundancy within a region is extensive. Multiple availability zones can make infrastructure highly resilient to the failures they are designed to handle. They cannot protect against every possible type of disaster.

A peer-reviewed study of 597 unplanned outages affecting 32 major internet services between 2009 and 2015 examined why outages still occur despite widespread redundancy. The findings highlight an important principle: redundancy protects against the failures it was designed to handle, but it does not automatically protect against failures outside that design.

Engineers made this distinction during the March AWS disruption. InfoQ quoted Harshwardhan Choudhary explaining that Multi-AZ is not the same as disaster recovery and is intended to protect against hardware failures rather than a disaster affecting an entire availability-zone cluster in the same area.

Gregor Hohpe made a similar point in the same report: the risk can be regional rather than specific to a cloud provider. If the failure is regional, reducing your exposure to that region becomes the important step.

For a small team, the practical lesson is simple: Multi-AZ can reduce the impact of a zone failure, but it should not be treated as a substitute for having recoverable data in another region.

What should a startup hold outside its region?

At a minimum, a startup should keep a restorable copy of every store of record outside the region where it normally operates. It should also keep the code and configuration needed to rebuild the systems that use that data. If you can restore the data and rebuild the application, you have the foundations of regional disaster recovery.

AWS makes this distinction in its disaster recovery guidance. For a disaster affecting a single physical data centre, a backup-and-restore approach may be enough for a well-designed, highly available workload. If the disaster could affect an entire region, AWS recommends considering more advanced approaches such as a pilot light, warm standby, or multi-site active/active architecture.

AWS also explains that backup and restore involves more than the data itself. The infrastructure, configuration and application code must also be redeployed in the recovery region. A database backup is only useful if you can actually rebuild the application that depends on it.

Here is what a small team should keep outside its primary region.

Two AWS features can cover much of this setup, but both have limitations worth understanding.

S3 Cross-Region Replication copies objects to a bucket in another region. However, it does not automatically copy objects that were already in the bucket before replication was enabled. Those existing objects need a separate one-off batch operation. Without S3 Replication Time Control, AWS says replication normally happens within 24 to 48 hours and does not have an SLA-backed replication time.

RDS can replicate snapshots and transaction logs to a destination AWS region. However, this feature is not supported for Multi-AZ DB clusters. It is available for Multi-AZ DB instances. AWS also sets a default limit of 20 cross-region automated backups per account.

This matters because Multi-AZ DB clusters are a common configuration. If you use one, a scheduled database dump may be the practical way to maintain an off-region copy.

Teams that prefer to manage their own backups can also use open-source tools such as restic. Restic supports Amazon S3 and Backblaze B2 as storage backends and can work with other services through rclone.

The specific backup tool matters less than the architecture. A nightly, encrypted and restorable copy stored outside your primary region is a relatively simple way to protect against a regional failure. The more important step is making sure that the copy actually exists and can be restored.

What does the minimum off-region posture cost?

At AWS list prices, storing a 200 GB database dump in another region costs roughly $4 to transfer and about $0.20 per month to store in S3 Glacier Deep Archive. The bigger cost is not the storage itself. It is setting up a reliable backup process and testing that you can actually restore from it.

The prices below use AWS list prices for US East (N. Virginia) and the prices published by Backblaze and Cloudflare. They were checked on the dates shown in the original sources. The figures exclude some additional costs, including requests, retrieval and early-deletion charges. They should therefore be treated as estimates rather than an invoice.

AWS lists data transfer from N. Virginia to Oregon at $0.02 per GB. Data transferred into Oregon is listed at $0.00 per GB. Internet data transfer out is listed at $0.090 per GB beyond the applicable free tier.

For storage, AWS lists S3 Standard at $0.023 per GB per month for the first 50 TB. S3 Standard-Infrequent Access is $0.0125 per GB-month, while Glacier Flexible Retrieval is $0.0036 per GB per month. Glacier Deep Archive is considerably cheaper at $0.00099 per GB-month, although retrieving data can take up to 12 hours.

Other providers change the calculation, particularly when you need to restore data. Backblaze B2 starts at $6.95 per TB per month and includes free egress up to three times the amount of data stored. Cloudflare R2 charges $0.015 per GB-month for Standard storage and does not charge for internet egress.

For a representative small team, assume a 200 GB database is dumped nightly, with 14 copies retained. Also assume that 1 TB of objects is replicated once and then kept in sync.

The table shows that storage is usually the smaller part of the cost. Data transfer can become much more expensive, particularly when a full database is copied every night. Using incremental or deduplicating backups can therefore have a larger impact on the bill than simply choosing a cheaper storage service.

The other difference appears when you need to recover. AWS charges for internet data transfer out, while Backblaze B2 and Cloudflare R2 offer free egress within their stated pricing terms. This can make an external provider useful for the particular data you may need to bring back during a regional disaster.

For many teams, however, keeping a copy in another AWS region may be sufficient. The important point is that the backup exists somewhere outside the region that could fail and that you have tested the process for restoring it.

For context, the US Bureau of Labor Statistics puts the mean hourly wage for a software developer at $71.20. Even the more expensive backup arrangements in the table therefore represent a relatively small cost compared with the engineering time that could be required to reconstruct lost data manually.

How do you test that a backup restores?

You test it by actually restoring the backup on a regular schedule. Do this in an empty account or region and record how long the process takes. A backup that has never been restored is an assumption, not a proven recovery plan.

AWS makes the same point in its disaster recovery guidance: a backup strategy should include testing the backups. AWS also notes that AWS Backup provides restore capabilities but does not currently provide scheduled or automatic restoration. The scheduling therefore has to be handled by the team.

This matters because restoring a backup can depend on the availability of the cloud provider's control plane. If that control plane is unavailable during a disaster, having a backup is not enough. A copy that has already been restored and verified can remove that dependency when you need it most.

The quarterly restore drill

These limits are exactly the kind of details that a restore drill can uncover. Deep Archive keeps storage costs low, but its retrieval window can become important during a recovery. Cross-region replication without Replication Time Control can also leave a gap between the primary data and the copy in the second region.

RDS's default limit of 20 cross-region automated backups per account is another example. It may be more than enough for a small setup, but that can change as the number of environments grows.

Most importantly, the drill tells you something AWS cannot: how long your own recovery actually takes with your team, infrastructure and application. AWS can document its service limits, but only a real restore can show whether your recovery plan works in practice.

Where RocketDevs fits

The technical requirements for an off-region backup are not especially complicated. A small team can use managed AWS features, infrastructure as code and a scheduled backup job to create a second copy of its critical data. The harder part is making sure someone owns the work, maintains it and tests it regularly.

That is where staffing becomes part of the disaster-recovery plan. A backup that was configured six months ago but has never been tested is not much use when the team needs to recover from a regional outage. The same applies to infrastructure code that has not been updated, credentials that have expired, or a restore process that depends on an engineer who is no longer with the company.

For a small startup, this does not necessarily mean hiring a dedicated disaster-recovery engineer. It means having someone on the engineering team who treats resilience as part of the system they are responsible for. The off-region copy, restore process and quarterly drill need an owner.

RocketDevs assesses developers for 6–8 hours per developer before a client meets them and accepts the top 2% of applicants. That assessment process gives clients a way to look for engineers who think beyond simply making an application work. For this particular problem, that means asking practical questions about where data is stored, how it can be recovered and what happens if the primary region disappears.

A useful first-month task for an engineer joining a small team is therefore not simply to learn the codebase. They can also map the application's critical data, identify where each copy lives, check whether any data exists only in the primary region and run the first restore drill. That turns disaster recovery from an undocumented assumption into something the team has actually tested.

The same principle applies when an existing team is already stretched. An engineer does not need to spend every day working on disaster recovery. The important thing is that the work is assigned, documented and revisited. A scheduled backup without an owner can eventually become a forgotten configuration. A quarterly restore drill gives the team a regular point at which to discover what has changed.

RocketDevs can help with the staffing side of that work. The platform connects companies with vetted developers who can take responsibility for infrastructure and application work as part of a wider engineering role. The 14-day risk-free trial also gives a new engagement an opportunity to test how the engineer approaches the existing stack and its operational requirements before making a longer-term commitment.

That does not make the trial a substitute for a disaster-recovery plan. The value is that a real restore drill can be part of the engineer's early work, rather than something left on the backlog indefinitely.

If the first question an engineer asks when reviewing your infrastructure is where the second copy of your critical data lives, that is a useful sign that resilience is being treated as part of the system rather than as an emergency task. If that is the engineer you want, build a vetted team with RocketDevs.

Related reading: why your cloud bill is rising while your AI bill falls, the access checklist most small teams skip, what your build trusts by default, and how a remote team documents what it runs.

Conclusion

AWS did not suddenly become unreliable on 15 September. What changed was the size of the failure that customers had to think about. Multi-AZ protection continued to do what it was designed to do. The problem was that the failure extended beyond that design boundary.

That distinction matters for every startup running in the cloud. A region is not a backup. Multi-AZ is not a backup. A database that can be restored only from infrastructure in the same region is not protected from a regional disaster.

The minimum answer is much less complicated than it sounds. Keep a recoverable copy of critical data somewhere outside your primary region. Keep the infrastructure, application code, configuration, secrets and other components needed to rebuild the application. Then restore the copy regularly and record how long the process actually takes.

The cost can be surprisingly small. The difficult part is not buying enough storage. It is assigning ownership. Someone has to configure the backup, check that it is running, understand its limits and perform the restore drill. Without that ownership, even a sophisticated backup strategy can become another piece of infrastructure that everyone assumes somebody else is watching.

The question every small team should be able to answer is simple: if our AWS region disappeared today, where is our data, and how long would it take us to get the business running again?

If the answer involves opening the AWS console and hoping the backups are there, the work is not finished. If the answer includes a known copy in another location, infrastructure that can be rebuilt and a restore process that the team has already tested, you have something much more valuable than a backup: you have a recovery plan.

Frequently asked questions

Is multi-AZ the same as multi-region?

No. Multi-AZ and multi-region protect against different types of failure. AWS describes Multi-AZ as protection against the failure of a single location within a region. AWS also treats regions as isolated from one another and does not automatically replicate resources between them.

Multi-AZ can keep an application running if one availability zone fails. Multi-region protection requires resources or backups outside the primary region. For most small teams, this does not mean maintaining a second live production environment. A restorable backup in another region is often the simpler starting point.

How much does it cost to keep a copy of my database in another region?

The cost depends on how much data you have, how often you back it up and how many copies you retain. At the AWS list prices used in this article, transferring 1 GB between the relevant US regions costs $0.02, while S3 Glacier Deep Archive storage costs $0.00099 per GB-month.

That means a single 200 GB dump costs roughly $4 to transfer and about $0.20 per month to store. Keeping 14 nightly full dumps would generate far more transfer because the entire database is copied each time. Incremental and deduplicating backups can therefore make a significant difference to the cost.

Should a startup use a second cloud provider for backups?

Not necessarily. A second AWS region is a sensible minimum because it protects against a failure that affects the primary region. It also avoids the additional complexity of operating across multiple cloud providers.

A second provider can add another layer of protection. It can help if the problem involves the cloud account itself rather than the physical region. It can also change the cost of restoring data because providers have different egress policies.

The right approach depends on the risk you are trying to protect against. If your immediate concern is losing an AWS region, start with an off-region copy. If account compromise or provider-wide failure is also part of your threat model, consider keeping a separate copy with another provider.

How often should we test a restore?

A quarterly restore drill is a practical starting point for a small team. Restore the newest scheduled backup into an empty environment, rebuild the infrastructure and application, verify the important data and record how long the entire process takes.

AWS's own guidance says that a backup strategy should include testing the backups. AWS Backup provides restore capabilities, but the restore process itself still needs to be tested and managed by the customer.

The most important number from the exercise is the actual recovery time. It tells you how long your team needs to get from a backup to a working system, rather than how long you expect the process to take on paper.

Is having a second copy enough to protect us?

No. A second copy only helps if you can actually restore it. Replication can also have delays, configuration limits or gaps in what gets copied. For example, S3 Cross-Region Replication does not automatically replicate objects that existed before replication was enabled.

Your recovery plan needs to cover both the copy and everything required to use it. That includes infrastructure configuration, application code, secrets and DNS. The safest way to verify the whole process is to perform regular restore drills in an empty environment and confirm that the application works with the recovered data.

James Hitch, COO at RocketDevs.LinkedIn

Sources

• The Register, AWS says wartime damage means some Middle East cloud resources are gone for good, Dan Robinson, 16 September 2026
• Help Net Security, Iranian strikes on AWS facilities left customer data beyond recovery in Bahrain, UAE, 17 September 2026
• The National, Amazon Web Services unable to restore Bahrain data network knocked out by Iran, 15 September 2026
• Techzine, AWS can't recover all data from data centers hit in Middle East, 16 September 2026
• InfoQ, War in Iran Damages Multiple AWS Data Centers, Challenging Multi-AZ Assumptions, Renato Losio, 18 March 2026
• Gadget Review, AWS Confirms Permanent Cloud Data Loss in Bahrain and UAE After Iran War Damage, 17 September 2026
• TechPolicy.Press, The Legal and Policy Fallout from Data Center Strikes in the Middle East War, 12 March 2026
• AWS EC2 User Guide, Regions and Zones
• Amazon S3 User Guide, Data protection in Amazon S3
• Amazon S3 User Guide, Replicating objects within and across Regions
• Amazon RDS User Guide, Replicating automated backups to another AWS Region
• AWS Whitepaper, Disaster recovery options in the cloud
• AWS Customer Agreement
• AWS Shared Responsibility Model
• AWS Price List API, Amazon S3, us-east-1
• AWS Price List API, AWS Data Transfer
• AWS, Amazon S3 Glacier storage classes
• Backblaze, B2 Cloud Storage pricing
• Cloudflare Developers, R2 pricing
• Google Cloud, Regions and zones
• Gunawi et al., Why Does the Cloud Stop Computing? Lessons from Hundreds of Service Outages, ACM SoCC 2016
• Uptime Institute, Annual Outage Analysis Report 2026, press release, 13 May 2026
• Eurostat, Enterprises using paid cloud computing services, isoc_cicce_use
• restic on GitHub
• GitHub API, restic/restic
• npm registry downloads API, @aws-sdk/client-s3
• Stack Exchange API, amazon-web-services tag
• Hacker News via Algolia, item 49719249
• Wikimedia pageviews, Amazon Web Services, September 2026
• US Bureau of Labor Statistics, software developers, hourly mean wage