AWS, Azure, Google Cloud: High Availability Compared

If I need the short answer: all three can handle zone failure well, but regional recovery is where the gap shows. AWS gives me more design options, Azure gives me tighter built-in SQL failover, and Google Cloud keeps in-region HA simple but asks me to plan manual regional failover.

For a UK team, I’d boil the choice down to this:

• AWS: more setup choices, more design work, strong fit for custom HA and DR
• Azure: strong Azure SQL story, simple UK region pairing, low failover times in Business Critical
• Google Cloud: easy in-region HA for Cloud SQL, but cross-region failover needs manual promotion
• Zone-level HA: deals with a single site or zone failure
• Multi-region DR: deals with a full regional outage, but costs more and needs tested runbooks
• Uptime maths matters: 99.9% means about 8 hours 46 minutes downtime a year; 99.99% means about 53 minutes
• Cost also matters: built-in HA for managed databases will often roughly double database spend

If I were choosing, I’d start with three questions:

1. What RTO can I live with?
2. What RPO can I live with?
3. How much outage cost, in £, am I trying to avoid?

That gets me to the right shape of setup far faster than vendor feature lists.

::: @figure {AWS vs Azure vs Google Cloud: High Availability & DR Compared} :::

How to Achieve Multi-Cloud Replication and Zero Data Loss Failover | Azure DocumentDB + AWS + GCP

Quick comparison

My main takeaway: for most workloads, I’d start with regional or zonal HA and only add multi-region DR when the outage cost clearly justifies the extra £, extra moving parts, and extra team effort.

AWS high availability: Multi-AZ design, failover and cross-region recovery

AWS splits its infrastructure into Regions, and each Region has at least three Availability Zones (AZs).[6][5] AZs are separate data centres inside a Region, linked by low-latency networking. For a UK business, placing production workloads in eu-west-2 (London) usually gives strong local performance and also allows synchronous replication across AZs in that same Region.

That gives you two layers to think about: resilience across zones, and recovery across regions. Managed HA covers the first part well. After that, you move into DR planning.

RDS Multi-AZ options and failover behaviour

AWS has two different Multi-AZ setups for RDS. That difference matters, because cost and recovery speed can vary quite a bit.

The standard Multi-AZ DB instance keeps one synchronously replicated standby in another AZ. Because replication is synchronous, RPO is effectively zero. Failover will often finish in 60–120 seconds, although large transactions or crash recovery can push that out.[7][9]

Multi-AZ DB clusters place a primary and multiple readable standbys across three AZs. One standby can handle read traffic and also act as the failover target. In practice, failover is usually under 35 seconds.[8] This setup makes sense for transaction-heavy services where even a short interruption can hit revenue.

There is a trade-off, of course. More instances running all the time means a higher monthly bill. So the question is pretty simple: does the cost of downtime outweigh the cost of keeping that standby capacity live?

For lower-priority setups, the answer is often no. Development, test, analytics sandboxes, and internal tools with patient users can often run perfectly well on single-AZ deployments. A sensible way to judge it is to compare the monthly uplift in £ with the likely cost of a short outage, including lost sales, support demand, and reputational harm.

That brings you to the next step: what happens when the issue is not one AZ, but an entire Region?

AWS disaster recovery beyond a single region

Multi-AZ helps with AZ failures. A regional outage is a different beast.

AWS supports cross-region automated backup replication for RDS. This copies daily snapshots and transaction logs, which are captured every 5 minutes, into a second Region.[10] That gives you a recovery point, but restoration is slower than promoting a live replica. So this option tends to fit workloads that can live with a longer RTO.

It is worth noting that automated backup replication is not supported for Multi-AZ DB clusters, only for standard Multi-AZ DB instance deployments - an important constraint when planning a combined HA and DR strategy.[10]

If your targets are tighter, cross-region read replicas are usually the better fit. If the source Region goes down, you can promote the replica to become the new primary. That cuts recovery time compared with doing a full restore.

A common UK setup is to keep production in eu-west-2 (London) for user performance, then replicate data to another European Region such as eu-west-1 (Ireland) to reduce geographic risk.[6] This does add network and data transfer costs, so it is best kept for workloads where a regional outage would cause material loss. In plain terms, don’t pay for cross-region replication unless the RTO and RPO improvement is worth the extra spend and admin work.

Set clear RTO and RPO targets. Write down failover runbooks. Then test failover and failback before anything goes wrong.

Azure and Google Cloud follow the same broad split between HA and DR, but their managed database services handle it in different ways.

Azure and Google Cloud high availability: zone resilience, built-in replicas and disaster recovery

Compared with AWS's Multi-AZ setup, Azure and Google Cloud draw the same line between within-region resilience and cross-region recovery, but they handle failover in different ways. The trade-off is pretty simple: less downtime usually means more spend.

Azure SQL Database: zone redundancy, Business Critical tier and geo-replication

Azure groups its infrastructure into regions, such as UK South and UK West, with each region made up of multiple datacentres.[3] In many regions, Azure also offers Availability Zones. These are separate physical locations with their own power, cooling and networking. When a service is zone-redundant, Azure spreads compute and storage across two or three zones in the same region, which helps limit the damage from a single-site failure.[3]

Your pricing tier matters here. Basic and Standard don't support zone redundancy. To use it, you need a vCore-based tier - General Purpose, Business Critical or Hyperscale - or the Premium DTU tier.[3] The Business Critical tier keeps a set of synchronous replicas and, if you switch on zone redundancy, the SLA rises to 99.995%. That works out at roughly 26 minutes of allowed downtime per year, versus about double that at the 99.99% baseline.[2][4]

For cross-region disaster recovery, Azure SQL Database offers active geo-replication. This replicates data asynchronously to as many as four readable secondary databases in other regions.[14] A common UK setup is a primary in UK South with replication to UK West, which is Azure's paired region. That keeps data in the UK while still giving you a live DR target.[13] Because the replication is asynchronous, cross-region RPO is not zero. That's why regular failover testing matters, using sys.dm_geo_replication_link_status.[14]

Google Cloud follows the same broad model, but cross-region recovery depends on manual promotion.

Google Cloud SQL: regional high availability, automatic failover and cross-region recovery

Google Cloud uses the same basic structure. Regions, such as europe-west2 for London, are split into isolated zones inside the region.[11] A Cloud SQL high-availability instance, also called a regional instance, places a primary and standby in separate zones with synchronous replication.[11][12] If Cloud SQL sees that the primary is unhealthy, it fails over to the standby and updates the endpoint. In practice, that means applications usually reconnect with only a short interruption.[11] For zonal failures, RPO is effectively zero and RTO is usually a matter of minutes.[1][11]

That regional HA does not cover a full regional outage. For that, you need cross-region read replicas.[1] You place those in another region - for example, europe-west4 in the Netherlands - and if the primary region goes down, you promote the replica to become the new primary, then update your connection strings.[1][12] That promotion is manual and irreversible, so you need automation and a runbook you've already tested. Google says this setup can deliver an RTO of minutes and an RPO of typically less than one minute when a cross-region replica is already in place and ready to promote.[15]

Azure's fixed region pairs make UK data residency planning more straightforward. Google gives you more choice, but it also puts more weight on your DR plan.

AWS vs Azure vs Google Cloud: high availability compared side by side

Now that the provider-level details are covered, the choice comes down to three things: failover speed, recovery scope, and how much work your team has to do to keep it all running. All three cloud providers support zonal resilience. But the way their managed HA setups work - and the amount of hands-on effort they need - is not the same.

Comparison table: architecture, failover, RPO, RTO and disaster recovery

The table below shows the practical differences that affect day-to-day availability.

Multi-region DR adds cost and runbook overhead. Use it when the cost of an outage makes that extra spend worth it.

What UK businesses should look for when choosing a provider

Once the technical differences are on the table, the buying choice usually comes down to data residency, team skills, and budget.

Start with the outage your business can live with. Customer-facing systems often need automatic failover. Internal tools often don't. The jump from four nines to five nines is the gap between roughly 53 minutes and around 5 minutes of allowed downtime per year. For a payments platform, that gap matters a lot. For an internal reporting tool, maybe not.

UK data residency is usually the next hard limit. Azure's UK South/UK West pairing is the most straightforward option. AWS and Google Cloud need more deliberate replica placement if you want to stay within UK or EU jurisdictions.[13]

Team skills and day-to-day overhead also shape the choice. AWS gives you the most building blocks. That's a good fit for teams that want close control, but it asks for more design work up front. Azure can suit teams that want database and platform services to work together with less assembly. Google Cloud makes regional HA fairly simple to switch on, but cross-region DR depends on manual promotion steps. That means you need automation and a well-practised runbook before it's ready for production.

Cost follows architecture. The more resilience you buy, the more spare capacity, testing, and process work you need to pay for. Zone redundancy is usually the best-value resilience option across all three platforms. For customer-facing e-commerce or payments systems, the extra spend on multi-region DR often makes sense. For a small internal application, zone redundancy on its own is almost always enough.

Cost, operations and support trade-offs

The technical choice is only half the story. The other half is the cost and effort of keeping the system steady month after month. High availability is not just a box you tick in the console. It is an operating commitment that affects how your team works.

Turn on Multi-AZ in RDS, zone redundancy in Azure SQL, or regional HA in Cloud SQL, and the setup changes straight away. Your team now has to monitor more closely, plan patching with more care, test failover paths, and budget for the extra spend every month. The hard part is not switching HA on. The hard part is keeping it workable in day-to-day operations.

Built-in HA will usually roughly double managed database spend because you are paying for standby capacity. And the bill is only part of it. HA also changes the operating model. Patching and schema updates need tighter scheduling because managed platforms may roll out updates in a way that triggers failovers. That means ops teams need to plan around UK business hours and busy traffic periods. They also need to watch the things that matter in practice:

• Replica health
• Replication lag
• Failover events
• Reconnect behaviour

When built-in managed high availability is enough

Once that operating model is clear, the next step is simple: does the business even need multi-region recovery?

For internal systems and lower-risk customer portals, zonal or regional HA is often enough. It gives you cover for common failures without dragging in a second layer of cost and admin. Multi-region DR sounds safer on paper, but it also brings duplicate environments, DNS failover, and runbook upkeep. If the business gain is small, that extra load is hard to justify.

When multi-region disaster recovery is worth the added cost

Multi-region DR makes sense when the cost of an outage is plainly higher than the extra infra spend and operational load. That is often the case for fintech platforms with contractual SLAs, regulated services, or systems where a regional outage could lead to direct financial penalties.

But this is where things get heavy. Multi-region DR means dealing with cross-region replication, DNS failover routing, application state consistency between regions, and a runbook that the on-call team has actually practised.[22] In plain terms, it is not just more kit. It is more moving parts, more failure modes, and more pressure on the people supporting it.

One fintech case study found that active-passive multi-region DR met strict RTO/RPO targets at roughly 30% of the cost of active-active, with a tested RTO of 12 minutes.[21] That is a strong result. Still, it only matters if the team can test it, maintain it, and trust it under stress. If they cannot, then simpler zonal HA, backed by strong backups and a restore process the team has rehearsed, is the better call.

That trade-off is what separates a resilient design from one that is simply expensive.

Conclusion: matching your cloud choice to your availability and recovery needs

This comparison comes down to three things: control, orchestration and operating overhead.

AWS gives you the most room to design around your own needs - with Multi-AZ, cross-region replication and a range of DR patterns. That makes it a strong choice for complex, mission-critical workloads. Azure stands out for built-in SQL resilience. Zone-redundant setups, the Business Critical tier and auto-failover groups take care of much of the orchestration for you. Google Cloud goes in a simpler, more opinionated direction. Cloud SQL’s regional HA model cuts down configuration work and suits teams that want solid defaults without a long list of settings to manage.

Pick based on workload criticality, team capacity, user location and budget. The main point isn’t which provider sounds best on paper. It’s which setup matches your RTO, RPO and budget. A regulated UK financial services platform will need a very different design from an internal reporting tool, and the architecture should show that difference.

For most workloads, regional HA is the sensible place to start. Add multi-region DR only when a quantified review of downtime costs - measured in pounds sterling, not vague risk scores - shows that the extra spend makes sense.

Start with workload requirements, not provider marketing. Define your RTO and RPO in plain English, map them to architecture options, cost them out in GBP, and test what you build. Set RTO and RPO first, then pick the simplest architecture that meets them.

FAQs