Cloud platform for an application that must stay up even if a whole data centre fails

Use a multi-zone deployment in a cloud region: run the application across at least two availability zones and distribute traffic between them. Availability zones are physically separate sites, designed so a failure at one site doesn’t take down the others. (learn.microsoft.com)

For protection against an entire region failing, add a second region with replicated data and a tested failover plan. Multi-zone deployment alone doesn’t cover a region-wide outage. (docs.aws.amazon.com)

Short answer: Any of the big three (AWS, Azure, Google Cloud) can do this. The key decision is whether "whole data centre" means one facility or an entire region. That determines the architecture more than the provider does.

1. Survive one data centre failing: use multiple availability zones (AZs) in one region.

• AZs are the baseline. An Availability Zone is a physically separate location within a region. Each zone has independent power, cooling, and networking, ensuring resilience against data center failures.
• On AWS, replicating across multiple AZs in the same region makes workloads resilient to the failure of an entire data center.
• Use managed services that spread across zones for you. Options include serverless or managed containers (Lambda, Fargate) and managed databases with a standby in another zone. Azure and GCP have equivalents, such as zone-redundant services.
• Check your provider's zone isolation. One source notes that the isolation of Azure's availability zones is not as that of AWS's, so verify this for your chosen platform.

2. Survive an entire region failing: add a second region.

• Multi-AZ does not cover this. Multi-AZ protects against localized failures within a Region, while multi-Region is necessary to mitigate the risk of broader, regional outages.
• Your data needs replicating to the second region. Distances between regions are long, so synchronous replication between them is usually impractical, which means you should expect some data-loss window (RPO) during failover.
• Choose a DR pattern based on cost and recovery speed. AWS lists Backup and Restore, Pilot Light, Warm Standby, and Multi-Site Active/Active as the main options, ranging from cheapest and slowest to most expensive and fastest.
• Keep failover control planes out of the failed region. One guide advises that you keep DNS, secrets, and observability out of any single Region, so failover does not depend on the region that just failed.

3. Practical recommendation

• Minimum: Deploy across three AZs in one region, using managed compute and a multi-AZ database. This handles a single data centre failure.
• If the app must stay up through a region outage: Add a warm standby or active/active setup in a second region, with automated DNS failover. Test it with regular drills.
• Platform choice: Pick the provider your team already knows, since operational skill matters more than small differences. Azure is worth a closer look if you rely on Microsoft tooling, and GCP's regional design is similar to AWS's.

I'd also ask whether you need to meet a specific uptime target or RPO/RTO. Those figures drive whether you need the second region and how much it will cost.

To ensure your application stays up even if an entire data center (or region) fails, you must move beyond basic backups and adopt a multi-region, active-active or active-passive architecture.

No single cloud platform will automatically "keep your application up" during a total data center failure just by hosting it there. Instead, all major cloud providers (AWS, Azure, Google Cloud) provide the tools for you to build this level of resiliency.

1. The Strategy: How to Survive a Data Center Failure

To survive the failure of an entire facility, your architecture must implement the following:

• Multi-Region Deployment: Do not rely on multiple data centers (Availability Zones) within the same region alone. While multi-AZ protects against single-data-center failures, a catastrophic event (like a regional power grid failure) can take out an entire region. For true "staying up" capability, you must deploy your application across at least two geographically distinct Regions.
• Active-Active vs. Active-Passive:
  • Active-Active: Both regions serve traffic simultaneously. If one region fails, the global load balancer automatically routes all traffic to the remaining healthy region. This offers the fastest recovery (often near-zero downtime).
  • Active-Passive (Pilot Light/Warm Standby): One region handles all traffic, while the other sits in a "ready" state. If the primary fails, you fail over to the secondary. This is cheaper but involves some downtime during the transition.
• Global Load Balancing: Use services like AWS Global Accelerator / Route 53, Azure Front Door, or Google Cloud Load Balancing. These act as the "front door" for your users, performing health checks to detect if a region is down and immediately steering traffic away from it.
• Data Replication: This is the hardest part. You must use globally distributed databases or cross-region replication (e.g., Amazon Aurora Global Database, Azure Cosmos DB, Google Cloud Spanner) to ensure that data written in one region is available in the other.

2. Choosing a Platform

All major "hyperscale" providers are equally capable of supporting this architecture. Your choice should depend on where your team has expertise:

• AWS (Amazon Web Services): Offers the most mature set of tools, such as the AWS Application Recovery Controller and extensive multi-region routing options.
• Microsoft Azure: Features strong integration with Azure Front Door and Site Recovery for managing complex multi-region failovers.
• Google Cloud (GCP): Highly regarded for its global network and "multi-region" managed services, which often simplify the complexity of data replication.
• Specialized Platforms (e.g., Control Plane, Northflank): If you want to avoid managing the underlying infrastructure complexity yourself, platforms like Control Plane (for multi-provider active-active) or Northflank (for multi-region PaaS) abstract away much of the manual configuration.

Summary Checklist for Your Team

1. Define RTO/RPO: How much downtime (Recovery Time Objective) and data loss (Recovery Point Objective) can you actually tolerate?
2. Decouple Data: Use a database that supports cross-region synchronous or asynchronous replication.
3. Automate Failover: Use health-checked global traffic management to ensure you aren't manually updating DNS records during an outage.
4. Test: A disaster recovery plan that has never been tested will almost certainly fail. Conduct "chaos engineering" or drills where you intentionally shut down a region to verify the system recovers.

Use a multi-availability-zone (Multi-AZ) architecture on a major cloud platform—such as AWS, Azure, or Google Cloud. Availability zones are isolated groups of data centres; spreading the application across multiple zones in one region is designed to keep it running if a data centre or zone fails. ²⁴⁷

At a minimum, run redundant application instances in two or more zones behind a load balancer, and use a database or storage service configured to replicate and fail over across zones. Simply choosing a cloud provider—or deploying the app in one zone—doesn’t provide this protection; the architecture must be set up for redundancy and failover. ⁷¹⁰

If you also need protection from a whole-region outage, plan for multi-region disaster recovery. ⁴¹²