What the Revolut outage teaches every business about Disaster Recovery 

The lesson is not that cloud infrastructure is unreliable. The lesson is that using the cloud is not the same as having a tested Disaster Recovery and Business Continuity strategy. 

On 20th of October 2026, a power-related event affected Google Cloud's europe west-2-b availability zone in London. The incident disrupted multiple Google Cloud services, while Revolut customers experienced problems with functions including card payments, cash withdrawals and business services. Google's workaround was to move affected workloads to another zone or region "if feasible". 

That wording matters. Moving a complex production environment during an active outage can be difficult because applications often depend on databases, identity, networking, storage and third-party integrations. Recovery should not be designed while the business is already offline. 

A DR plan must be ready to execute 

There is a fundamental difference between saying, "we can rebuild or move our environment somewhere else" and having workloads already replicated, recovery priorities agreed, dependencies mapped and failover procedures tested. 

A credible plan must define which services are restored first, who can declare a disaster, how users and customers reconnect, how data consistency is validated, and how operations return safely to the primary environment. 

Azure Site Recovery changes the conversation 

Microsoft Azure Site Recovery (ASR) is designed to support Business Continuity and Disaster Recovery. Microsoft documents that ASR can replicate Azure virtual machines to a secondary Azure region and orchestrate replication, failover and recovery. During failover, target virtual machines are created from replicated recovery points in the secondary region. 

This can significantly reduce the work required during an outage because replication and the recovery process are configured in advance. Microsoft also recommends regular disaster-recovery drills so organisations can verify the configuration without affecting production workloads. 

Important technical point: ASR should not be described as permantently running full copy of every Azure service. It provides replicated recovery data and orchestated failover for supported workloads. Applications requiring near-zero downtime may also need active-active design, database replication, resilient identity, network failover and geographically distributed application components. 

For critical platforms, active-active should come first 

For highly transactional and always-on platforms such as Revolut, an active-active architecture should be considered for the most critical application and data services. In an active-active design, two or more environments are live at the same time and can serve production traffic. If one site, zone or region becomes unavailable, traffic can be redirected to another active environment rather thatn waiting for infrastructure to be created or applications to be restored. 

The data layer is the most important part of this design. Databases, transaction processing, identity, messaging and network services must be engineered for cross-region availability, data consistency and controlled failover. The objective is to minimise both service interruption and the risk of losing committed transactions, although the achievable RPO depends on the replication method and consistency model selected. 

Active-active does not replace Disaster Recovery. 

It protects against many infrastructure and regional failures, but it may not protect the business from data corruption, software defects, cyberattacks, credential compromise, configuration errors or a wider provider-level incident. A separate, tested DR capability should therefore sit above the active-active production design, with isolated recovery copies, defined recovery points, documented runbooks and regular end-to-end exercises. 

For an organisation like Revolut, the strongest resilience model is layered: active-active architecture for immediate service continuity, combined with a separate Disaster Recovery environment for recovery from severe or systemic incidents. 

Go one step further: consider another cloud provider 

Regional redundancy protects against many failures, but it does not completely remove cloud-provider concentration risk. For organisations where downtime has a severe financial, operational, regulatory or reputational impact, it can be sensible to host the Disaster Recovery environment with a different cloud provider. 

For example, a business running its primary environment in Microsoft Azure cloud maintain selected recovery capabilities in Amazon Web Services or Google Cloud, and the same principle applies in reverse. This architecture prevents the production environment and the only recovery option from sitting within the same provider-level failure domain. 

Multi-cloud DR is not automatically the best answer for every organisation. It can be increase cost and complexity across identity, networking, security controls, licensing, data replication, automation, monitoring and support skills. The right decision depends on the business impact of downtime and the required Recovery Time Objective and Recovery Point Objective. 

Recommended DR scenarios by Recovery Time Objective 

The following reference architecture illustrate three common resilience levels. The appropriate design depends on application dependencies, data-consistent requirements, acceptable data loss, budget and operational capability. "RTO 0 hours" should be treated as a near-zero interruption objective rather than an absolute guarantee. 

Scenario 1: RTO up to 4 hours- Cross-region DR

Suitable where the business can tolerate a controlled recovery window. Production runs in the primary region, while application data and recovery components are replicated to a secondary region. Failover follows a documented and regularly tested runbook. 

Reference architecture. Final RTO and RPO depend on the complete solution design, testing and operating procedures. 

Scenario 2: RTO up to 2 hours- Warm standby DR 

Suitable for more critical services. Core infrastructure is already provisioned in the secondary region at reduced capacity, with replication, monitoring and orchestrated failover designed to shorten recovery time. 

Reference architecture. Final RTO and RPO depend on the complete solution design, testing and operating procedures. 

Scenario 3: Near-zer RTO- Active-active plus separate DR 

Suitable for always-on and highly transactional services. Two production regions are live simultaneously, with global traffic distribution and an engineered data-consistency model. A separated, isolated DR layer remains necessary for corruption, cyberattack, configuration failure or a wider systemic incident. 

Reference architecture. Final RTO and RPO depend on the complete solution design, testing and operating procedures. 

Backup is not Disaster Recovery 

IBSCY's DisasterProof material draws a clear distincion: backup concerns copies of files and data, while Disaster Recovery covers the complete strategy for responding to an incident. DR includes technology, responsibilities, restoration priorities, RTOs, RPOs, testing and verification. 

A company can have successful backups and still remain offline for hours or days. Backups are essential, but they do not by themselves provide application availability, network connectivity, identity services, recovery coordination or a tested method for restoring business operations. 

The question every organisation should answer 

What IBSCY can offer: 

1. Business Impact and DR Assessment: Identify critical services, dependencies and acceptable downtime; define realistic RTO and RPO targets. 
2. Active-active and High-availability Architecture: Design multi-zone or multi-region application, database, identity and network architecture for critical services that require very low downtime and minimal data loss. 
3. Cross-region Azure DR Architecture: Design replication and failover for sustainable Azure and on-premises workloads using Azure Site Recovery and supporting Azure services. 
4. Hybrid and Multi-cloud DR Design: Evaluate whether secondary-region Azure, another cloud provider, an on-premises recovery platform or a hybrid model provides the correct balance of independence, cost and complexity. 
5. Backup and Off-site Protection: Implement backup as a separate protection layer, with appropriate retention, off-site copies and restore validation. 
6. Runbooks, Roles and Communications: Documents responsibilities, escalation paths, failover steps, validation checks and stakeholder communications. 
7. DR Testing and Improvement: Run scheduled recovery exercises, record results and close gaps before a real incident occurs. 

The real question is not whether an outage will hapen

Google, Microsoft, Amazon, a local data centre, a telecommunications provider or an on-premises server room can all experience disruption. No infrastructure should be treated as incapable of failure. 

The useful question is: "If the infrastructure hosting our most important systems becomes unavailable tomorrow morning, how quickly can we continue operating?" 

Sources

• Google Cloud outage reporting and Revolut impact, 20 October 2026
• Inside the Google Cloud London outage that affected Revolut
• Microsoft Learn: Fail over Azure VMs to a secondary region
• Microsoft Learn: Set up Azure VM disaster recovery to a secondary region
• IBSCY DisasterProof: Business Continuity presentation - Internal IBSCY source

Avgoustinos Constantinides is a partner and Solutions Director of IBSCY LTD. With a BSc in Information Technology from St. Francis College in Brooklyn Heights and MSc in Computer Systems and Networking from the University of Greenwich in the UK, Avgoustinos brings a wealth of academic knowledge to his role.  In addition to his academic achievements, Avgoustinos holds numerous professional certifications from renowned vendors such as Microsoft, Fortinet, Cisco, VMWare, HPE, and many more, demonstrating his commitment to staying at the forefront of technological advancements.