Cloud concentration risk for Indian banks and NBFCs on AWS: zone failures, RBI exit-plan rules and multi-AZ design

According to the Google Cloud incident page, multiple services had issues in the europe-west2 (London) region from 11:38 to 19:30 IST on 20 October 2026. Google gave the cause plainly: "A power event caused an outage within europe-west2-b zone." Services in that zone were unavailable, and some services in the wider region saw elevated errors. Google has said it will publish an analysis after its internal investigation.

As reported by the Guardian, Downdetector showed disruption at Royal Mail, Revolut, HSBC and Lloyds, among others. Problems appeared to peak at about 9am UK time and were somewhat resolved by mid-afternoon. The report does not say which zone each firm's services ran in.

This is not evidence that one cloud is safer than another. The same report recalls a larger AWS us-east-1 outage about a year earlier. Zone and Region incidents happen on every hyperscaler. The useful question is whether your design and your documents are ready for one.

• Provider concentration: many critical services depend on one cloud provider, or a whole sector relies on a few. RBI addresses this directly through concentration-risk assessment and exit strategy.
• Architectural concentration: a workload is pinned to one zone, one Region, one account or one database instance. RBI addresses this through its resilience, business continuity and DR clauses.

A bank can use several providers and still run a payments service from a single zone. Both kinds of concentration need an owner and evidence.

Commercial banks are covered by the Reserve Bank of India (Commercial Banks – Managing Risks in Outsourcing) Directions, 2025, dated 28 November 2025, and by the Reserve Bank of India (Commercial Banks – Cybersecurity, Technology: Risk, Resilience and Assurance Framework) Directions, 2026, dated 31 July 2026 and shown as updated on 1 October 2026. NBFCs are covered by the Reserve Bank of India (Non-Banking Financial Companies – Managing Risks in Outsourcing) Directions, 2025.

The IT chapter of the Outsourcing Directions applies to material outsourcing of IT services, which include "cloud computing services". The third-party paragraphs of the Cybersecurity Directions (126 to 135) apply only to arrangements outside the Outsourcing Directions, so material cloud outsourcing is read against the Outsourcing Directions first.

For the logging, CSOC and testing clauses, see our RBI Cybersecurity Directions control map for AWS. NBFCs and fintechs that expose payout APIs can also read our guide to payout API security for NBFCs and fintechs on AWS.

A DR plan says how you recover a service after a failure of a zone, a Region or a component. An exit strategy says how you move off a provider in an orderly way, whether the trigger is termination, failure of the provider or a regulatory direction. RBI asks for both, and good DR design does not replace an exit strategy.

The exit strategy should cover:

• Plans for different exit scenarios, each with a minimum period to execute it.
• Alternative arrangements, such as another provider or bringing the service in-house.
• Return of data, with completeness and portability, and secure purge from the provider's environment.
• No erasing or altering of data by the provider during transition, and the provider's cooperation with any new provider.

RBI requires the exit strategy to be documented, and business continuity and DR to be tested. In our view it is also good practice to walk through parts of the exit plan, such as a sample data export, so the minimum execution period is realistic. Infrastructure as code, a dependency inventory and documented data export formats make an exit strategy credible.

AWS defines an Availability Zone as "one or more discrete data centers with redundant power, networking, and connectivity in an AWS Region". AZs in a Region are many kilometres apart, and all are within 100 km of each other. Mumbai and Hyderabad each have three AZs.

The AWS Well-Architected reliability practice REL10-BP01 lists two common anti-patterns: a production workload in a single AZ, and a multi-Region architecture where multi-AZ would meet business requirements.

• Spread compute across AZs, for example with EC2 Auto Scaling behind load balancers that can reroute traffic if one AZ is impaired.
• Replicate data across AZs. Amazon S3 and Amazon DynamoDB do this by default. With self-managed storage such as Amazon EBS, you manage it yourself.
• Size for the loss of a zone, so the remaining AZs can carry the load.
• Use Amazon Application Recovery Controller zonal shift to move traffic for supported resources away from an impaired AZ. Resources must be opted in, you must prescale first, and shifts are temporary: you set an initial expiry from one minute up to 72 hours, which you can extend. Zonal autoshift lets AWS start the shift when its telemetry shows an AZ impairment.
• Use AZ IDs, not AZ names, when you coordinate zones across accounts.

None of these makes a bank compliant on its own. They can be evidence for the resilient architecture that para 92(vii)(d) asks for.

Multi-AZ absorbs a zone failure, not an event that affects a whole Region. REL10-BP01 notes that some workloads need resilience beyond one Region, where data residency requirements allow. The Cybersecurity Directions also ask that DC and DR sites be geographically well separated.

Mumbai and Hyderabad are the two AWS Regions in India, so pairing them keeps both copies in India. The recovery tier between them, from backup and restore to pilot light or continuous replication with AWS Elastic Disaster Recovery, is a cost and recovery-time decision. Our AWS Backup and DR guide for Mumbai and Hyderabad walks through that choice.

For commercial banks, the Cybersecurity Directions require DR drills for critical systems at least half-yearly, and a switch-over that runs the DR site as primary for at least a full working day. DR must meet defined RTO and RPO, with minimal RTO and near-zero RPO for critical systems, and testing must extend to critical vendors and partners.

• AWS Resilience Hub reports whether an application has met or breached the RTO and RPO targets in its resiliency policy for each disruption type: application, and cloud infrastructure (infrastructure, Availability Zone and Region).
• AWS Fault Injection Service offers an "AZ Availability: Power Interruption" scenario that simulates many symptoms of a complete power interruption in one AZ, by default 30 minutes of interruption followed by 30 minutes of recovery.

Check the current AWS Regional Services list for Mumbai and Hyderabad before planning a test. Fault injection supports, but does not replace, the full DR switch-over drills.

• Critical services listed by provider, Region and AZ.
• RTO and RPO for each critical system.
• Multi-AZ status, with single-zone exceptions owned and dated.
• A second-Region path and recovery tier where needed.
• A documented exit strategy for each material cloud arrangement, with a minimum execution period.
• Date and result of the last DR drill.
• CSP DR drill evidence.
• Contract clauses on audit, data return, portability and secure purge.

Upvantix is an AWS Select Tier Services Partner. We can review AWS workloads for single-zone and single-Region dependencies, map them to the RBI clauses above, and help design and validate multi-AZ and Mumbai to Hyderabad recovery.

We are not RBI, we are not the bank's auditor, we do not certify RBI compliance and we do not give legal or regulatory opinions. This guide summarises the public RBI directions named above, Google's incident page, reporting by the Guardian and AWS documentation, as read on 22 October 2026. Confirm your obligations with your compliance and legal teams and the current RBI website.