What Happens on Your Side When AWS Goes Down? The 4-Question Test

July 14, 2026 · 4 min read · SOVALYX Technologies

If a hyperscaler goes down tomorrow morning, the only question that matters is: what actually happens on your side within the following hour? 55% of organisations already experience weekly disruptions, yet only 20% say they are fully prepared for outages. Four questions are enough to know which side you are on.

Outages are no longer a hypothesis — they are an operating condition

The Cockroach Labs survey of 1,000 tech executives, covered among others by TechTarget and Bacancy, sets out two numbers: 55% of organisations experience at least weekly disruptions, and only 20% consider themselves fully prepared for outages.

In other words, unavailability has become a normal operating condition, not an exceptional event. A cloud provider's SLA credits refund a few percent of your bill; they refund neither lost sales, nor contractual penalties, nor customer trust. And for an organisation based in Mauritius, dependence on distant cloud regions adds a further layer: connectivity itself rests on a handful of submarine cables.

This echoes a principle cloud contracts have always stated, though few organisations have followed it through: the provider is responsible for the availability of its platform, not of your service. Redundancy for your applications, replication of your data and the failover path remain your responsibility. That is exactly what most "cloud by default" architectures never formalised — and what the following four questions bring to light.

The 4-question test

1. Do you know exactly what depends on the public cloud?

An outage always reveals dependencies nobody had mapped: the main application, of course, but also authentication (SSO), DNS, outbound email, payments, and the business SaaS tools that themselves run on the same hyperscaler. Good sign: an up-to-date inventory listing, for each critical service, the provider, the region and the indirect dependencies. Warning sign: "we would have to ask each team".

2. Is your RTO measured, or hoped for?

RTO (maximum tolerable downtime) and RPO (maximum data loss) are only worth anything once they have faced a real, timed exercise in near-production conditions. A plan that has never been rehearsed produces "hoped-for" RTOs that blow up at the first incident: forgotten dependencies, outdated procedures, key people unavailable. To set sensible objectives, start by pricing what one hour of downtime costs your services — the method fits in a spreadsheet. The exercise has a side benefit: it exposes the gaps between documentation and reality while they are still painless.

3. Where do you restart if the entire region is unavailable?

Multi-AZ is not multi-region, and multi-region is not multi-provider. Replication across availability zones protects you from a data-hall failure, not from a region-wide incident or a control-plane failure that cuts across the whole provider. A real fallback requires an independent target — another region, another provider, or private infrastructure — with data already replicated and a rehearsed failover path. It is the same reasoning that structures a DR plan built for cyclone season: the recovery target must not share the weaknesses of the source.

4. Who does what during the first 60 minutes?

An outage is also an organisational problem: who detects it (your monitoring must be hosted outside the perimeter that might fail), who decides to fail over, who informs customers, in what order the runbooks unfold. A structured on-call rotation, with written decision criteria, makes the difference between a controlled interruption and an evening of improvisation. That is precisely what monitoring with on-call duty under an SLA formalises — the one SOVALYX operates is deliberately independent from the clouds it watches.

Interpreting your answers

Four good signs: you are part of the 20%. Two or fewer: every week of status quo is a bet on luck — one the survey's statistics make less and less tenable. The good news: questions 1 and 4 can be addressed within weeks, with no architecture overhaul, and immediately give you the visibility to prioritise the rest. And if the exercise reveals too wide a gap between the hoped-for RTO and the measured one, what follows is a management decision, not merely a technical project: close the gap, or accept the risk knowingly — in writing.

🧰 The companion tool: What does one hour of downtime cost you? — free · 2 minutes.

Reviewed and optimised by AI.