The cloud has redundancy. Does your business?

• Business continuity
• Provider concentration
• Cloud
• SaaS
• Internet exchanges

The shop opens. The tills take payments. Customers keep coming in.

Meanwhile, the team that needs to approve an urgent change cannot open the case file. Finance has an order pending and cannot tell whether anyone approved it. And the person coordinating the response has lost their email, calendar, and the channel they usually use to bring the team together.

Is the business still running?

If we look at that morning’s sales, probably. If we look at how long it can carry on like this, the answer is less comfortable.

The Microsoft 365 incident on 12 and 13 November 2026 brought me back to that question. Several services had access problems or ran in a degraded state. Understandably, the conversation focused on when Microsoft would recover. I am interested in something else: what can we still do in the meantime?

We migrated fast. The dependencies came later

Think about how many companies worked before the pandemic. They might have had cloud email, a few SaaS applications, and workloads with an infrastructure provider. But much of their operation was still spread across systems they ran themselves, local applications, and several suppliers.

The pandemic forced many organisations to accelerate that transition. There was a real problem to solve: get distributed teams working without waiting two years for a transformation project to finish. Cloud services solved much of that problem, and we still benefit from them today.

What is harder to see is how much we have since concentrated in one place. A single platform can handle email and meetings, hold documents, authenticate users, and run the workflows we use to approve changes or purchases.

We bought those capabilities at different times. We use them as if they were separate tools. When they fail together, we discover that some depended on the same place.

Another region solves a specific problem

With infrastructure as a service, if I lose a region, another region can be a good answer. If I need to plan for losing the provider, I have to show that I can operate outside it.

Those are two different scenarios, and both should be considered separately in the recovery plan.

The AWS incident in October 2025 is a good example of why that distinction matters. It began with a DNS resolution problem affecting DynamoDB’s regional endpoints in Northern Virginia and went on to affect other services. That does not make a second region pointless. It means we need to understand which dependencies the primary workload and its fallback share.

When we talk about strategic cloud providers, we usually think of AWS, Microsoft Azure, and Google Cloud. But saying “we have Azure and AWS” is not enough. If bringing up a service in AWS after an Azure failure requires me to sign in with Entra, retrieve a key from an affected service, or follow a procedure that only exists in SharePoint, I still have a problem. There are two providers in the inventory. I still need to show that one can sustain the operation when the other is unavailable.

Does that justify duplicating all our infrastructure? In my view, no. Maintaining two environments costs money, adds work, and requires both to be ready. I would reserve that for workloads whose impact justifies it. Depending on the case, the fallback could be another provider, infrastructure we run ourselves, or a simpler way of delivering the service temporarily.

The internet has points of concentration, too

This is where we tend to stop drawing the diagram too early. We draw two cloud providers and two telecoms operators. We add several lines between them and assume we have diversity.

But where do those lines actually go?

Two operators may share the last mile, a stretch of fibre, a transit provider, or an internet exchange point where they exchange traffic. The problem can also be logical: if a route is withdrawn or propagated incorrectly, the physical links can still be up while the destination we need is unreachable.

Two operators using the same exchange does not mean all their traffic must pass through it. That is exactly what we need to ask: if we lose that path, which other path remains, and what services can we reach through it? Internet exchanges are valuable because they let many networks interconnect. That same concentration deserves attention when we design for continuity.

Switching clouds achieves little if both are unreachable from the site that needs to execute the plan. Before calling the fallback viable, I want to know which path we could lose, from where, and how we have tested it.

With SaaS, we have less room to manoeuvre

With an application I run, I can prepare another installation, replicate data, or bring up a reduced version. With SaaS, I generally cannot start a copy of the provider’s application somewhere else. I can protect some of the data and prepare another way of working. Those are different capabilities.

An email backup can be very useful if I lose a mailbox. During a service outage, the questions change: can I read the messages I need? Can I receive a new one and reply? Can I still do that if the identity service I use to sign in to the alternative is also unavailable?

Documents pose a similar problem. I might have a copy of the procedure, but the operation requires approval. If the usual workflow is unavailable, I need to know who can approve it, how we record the decision, and how it goes back into the system when service returns. Otherwise, I can read the document but still cannot complete the work.

A degraded service can be harder to manage than a clean outage. One email goes out; another stays pending, and I do not know whether the customer received it. Someone resubmits a request because the first one shows no result. When the service returns, there is a practical question: what happened once, what happened twice, and what did not happen at all?

The tills are working. That is only part of the story

Frontline teams may keep working through an incident. That is a good sign, but it describes only part of the business.

Imagine a shop trading normally but unable to escalate a fault to the team that can fix it. Or a supplier that can deliver today’s order but does not receive confirmation for tomorrow’s. The impact may not show up in the first hour. It can build through the day and become visible on the next shift.

We should be selective. Some meetings can wait. Some reports can go out tomorrow. Other decisions, approvals, and communications keep the operation going even though nobody sees them from behind the counter. Those are the ones I want to identify first.

What should we be able to do without the provider?

I would run the exercise with the people who own the business processes and leave the product catalogue closed. Suppose our usual working environment is unavailable for a day. What can wait? What still has to happen? Who can do it, and how?

For some processes, a phone and a procedure we can access outside the platform will be enough. Others need a prepared alternative with independent access and the minimum data required to work. Some processes will have no reasonable fallback. Knowing that in advance lets us decide whether the impact is tolerable or the design needs to change.

A provider can offer an excellent SLA and still be the dependency that concerns us most. Its availability figure describes its service. We need to demonstrate how long our company can keep operating when that service is unavailable.

Next time we review the recovery plan, I would start with a simple test: take away email, chat, and access to the plan. Who can bring the team together and get the first urgent decision made?

Further reading

Official sources for checking and exploring these concepts. This article presents a practical approach; it does not reproduce the references’ full requirements.

• Microsoft 365 Service Health · MO1550821 (University of Pennsylvania mirror)
• AWS · Summary of the Amazon DynamoDB Service Disruption (Northern Virginia)

Examples are illustrative. Implementation decisions should be adapted to each organization’s requirements and dependencies.