Cross-Region Recovery Across India's Cloud Region Pairs
Cross-region recovery is the set of designs that let a workload be restored or run in a second cloud region when its home region is unavailable: data replication, keys, images, identity, network connectivity and traffic failover. NTSPL builds this plumbing for India region pairs on AWS, Azure and Google Cloud, underneath whichever DR pattern each workload uses.
Delivered on
In scope
The Regional Dependencies That Break Cross-Region Recovery
A DR pattern on paper says 'replicate to the second region'. In practice, cross-region recovery fails on the parts nobody listed: encryption keys that exist only in Mumbai, container images in a single-region registry, secrets that do not replicate, a Direct Connect or ExpressRoute circuit that terminates only near the primary, IAM policies that reference region-specific ARNs, and quotas in the DR region left at defaults. Teams discover these one by one during the first real event, each adding 20-60 minutes to recovery. India adds its own constraints: regulated data must stay in-country, and region pairs differ by provider.
NTSPL treats cross-region recovery as a dependency inventory that has to reach zero. We list every regional dependency a workload has, from data stores to KMS keys, registries, secrets, certificates, DNS zones, private connectivity, partner whitelists and quotas, and give each a replication or pre-provisioning method in the DR region. Traffic failover is designed explicitly, with health checks and a control that does not itself depend on the failed region. We prove the result with a region-isolation test.
When Cross-Region Plumbing Needs Dedicated Design
Signals you need Cross Region Recovery
- Your DR design says 'second region' but a dependency inventory has never been done for keys, images, secrets, certificates and quotas.
- Private connectivity from offices, plants or exchanges terminates only into the primary region.
- A regulator, auditor or exchange asks you to demonstrate recovery at a site in a different seismic zone or city within India.
- Your failover depends on a control plane, DNS zone or identity service hosted in the region you are trying to leave.
- You are combining several DR patterns across 10+ workloads and need a shared second-region foundation rather than one per application.
When to choose something else
- Zone-level redundancy within one region meets your agreed targets and the business has accepted regional risk. Invest in multi-zone and backups first.
- You need DR to a region outside India for data your sector requires to stay in India. Resolve the legal position before any design work.
- You have not chosen a DR pattern per workload yet. Start with the Disaster Recovery Assessment, then design the cross-region layer.
Six Layers of Cross-Region Recovery
Region-pair selection
Choice of DR region per workload considering provider pairing, service availability in the second region, distance, latency and regulator expectations.
Data replication
Replication method, lag target and consistency per data store, including databases, object storage, file shares, queues and search indexes.
Keys, secrets and certificates
Multi-region encryption keys or region-specific keys with re-encryption on copy, replicated secrets and TLS certificates valid in both regions.
Artefacts and configuration
Container registries, machine images, infrastructure code state, parameter stores and feature flags replicated or reproducible in the DR region.
Connectivity and identity
Private links from offices, plants, exchanges or partners into both regions, and identity services that remain available if the primary is lost.
Traffic failover control
DNS or global load balancer failover, with health checks and a control plane that does not depend on the failed region.
How Cross Region Recovery Works, Step by Step
India Region-Pair Recovery Plumbing
A shared DR region foundation holds replicated keys, images, secrets and connectivity for all workloads. Each workload's data replicates by its own method, and a failover control hosted outside the primary region moves traffic once readiness checks pass.
Select any component
India Region-Pair Recovery Plumbing: click any of its 9 components to see its role and the design choice NTSPL makes for it, or trace the 6-step primary path.
Region Pairs and Replication Services in India
Mumbai and Hyderabad are the in-country pair. Multi-Region keys and ECR replication remove the two most common blockers, and Application Recovery Controller provides failover controls hosted on a highly available cluster across multiple Regions.
Central India is paired with South India; West India and India South Central (Hyderabad) are further in-country options. Key Vault is per region, so NTSPL deploys a DR-region vault with keys and secrets synced by pipeline; ACR geo-replication requires the Premium tier.
Mumbai and Delhi form the in-country pair. Google's global VPC simplifies networking, but regional resources such as Cloud SQL, KMS key rings and regional registries still need explicit DR copies.
Region-Pair, Replication and Failover Decisions
Picking the DR region
Default to the provider's in-country pair: AWS Mumbai to Hyderabad, Azure Central India to South India, Google Cloud Mumbai to Delhi. On Azure, South India is the formal pair, which matters for geo-redundant storage and platform-managed recovery. Check service availability first; some newer managed services launch in one Indian region months before the other, which can force a different DR design.
Multi-region keys or re-encryption
Multi-region keys (where offered) let the same key material decrypt in both regions, simplifying database and snapshot copy. Separate per-region keys give stronger blast-radius isolation but require re-encryption during copy and careful mapping in runbooks. NTSPL uses multi-region keys for application data and separate keys for the backup vault account.
Replication lag targets
Set lag alarms at half the RPO. For databases, cross-region asynchronous replication typically runs at seconds; object replication commonly completes in minutes, with optional replication-time guarantees on S3. If a workload needs RPO near zero across regions, synchronous replication is rarely practical at Indian inter-region distances for high-write systems; use application-level dual writes or accept seconds of loss.
Failover control independence
Never make failover depend on a console, API or DNS zone hosted only in the primary region. Use DNS with health checks served globally, global load balancers or routing controls built for this purpose. Keep runbooks and break-glass credentials available offline. Test by blocking access to the primary region from the operations network and running the failover.
Closing the Regional Dependency List
Regional dependency inventory
Every regional dependency per workload is listed from IaC, IAM policies, flow logs and configuration, with a DR treatment assigned to each.
Shared DR foundation
Network, connectivity into the DR region, quotas, key and secret replication, and registries are built once for all workloads.
Workload data replication
Replication is configured per data store, seeded, and lag-alarmed against the agreed RPO.
Failover control and readiness checks
Health checks, routing controls and daily readiness reporting are implemented and verified to work without the primary region.
Region-isolation test
Access to the primary region is blocked for the test scope and workloads are recovered in the DR region using only DR-side resources.
What you receive
Cross-Region Readiness Indicators
| KPI | Typical target |
|---|---|
| Open items in regional dependency register | Zero before sign-off |
| Replication lag within alarm threshold | 99%+ of the time over 30 days |
| Readiness check pass rate | 100% daily, failures fixed within one business day |
| Region-isolation test outcome | All in-scope workloads recovered using DR-side resources only |
| Images and artefacts present in DR region | 100% of current releases |
Cross-Region Recovery Traps and NTSPL Safeguards
| Risk | How NTSPL prevents it |
|---|---|
| Encrypted snapshots cannot be used in DR region | Copy jobs re-encrypt with DR-region keys or use multi-region keys, and a restore from each copied snapshot type is tested. |
| Private connectivity only reaches the primary | Offices, plants and partners get a second path into the DR region, or SD-WAN policies that can re-target the DR region within minutes. |
| Identity unavailable after region loss | Identity providers and directory replicas run in both regions or are global services; break-glass accounts are tested quarterly. |
| Logs lost during failover breach CERT-In retention | Central log archives replicate to the DR region and the DR stack writes to its own in-region log sink from first boot. |
Cross-region recovery vs cross-cloud DR: should our DR be on a different provider?
For almost all Indian enterprises, cross-region on the same provider is the better choice. It reuses the same services, IAM model, tooling and skills, replication is native, and both regions are in India. Cross-cloud DR protects against a provider-wide event or a commercial dispute, but doubles the platform skills needed, forces lowest-common-denominator designs and makes data replication, keys and identity much harder. Consider cross-cloud only for a small set of systems where a regulator or board explicitly requires provider diversity, and then usually as backup copies in the second cloud rather than a running DR stack.
Key facts: Cross Region Recovery
Cross Region Recovery in Practice
2 Cross Region Recovery scenarios, from Capital markets (stock broking order management) and Power distribution (DISCOM consumer billing), plus related platform case studies.
Stock broker's OMS clears its Hyderabad region-isolation test with 38 fixes
State power DISCOM moves billing DR from a same-city site to Azure South India
Specialty chemicals group links 6 plants and HQ to AWS with dual-path hybrid network
Container terminal links TOS, gate automation and Azure over dual ExpressRoute
Cross Region Recovery: Frequently Asked Questions
What does cross-region recovery add to DR cost?
The shared foundation, including connectivity, replicated registries and keys, usually costs INR 1-4 lakh a month for a mid-size estate. Data replication adds inter-region transfer and second-region storage. Workload compute cost depends on the DR pattern chosen. NTSPL itemises each so finance sees what the second region costs regardless of pattern.
Which Indian region pairs are available?
AWS: Mumbai and Hyderabad. Azure: Central India (Pune), South India (Chennai), West India (Mumbai) and India South Central (Hyderabad), with Central India and South India as the formal pair. Google Cloud: Mumbai and Delhi. All pairs keep data in India, which satisfies RBI's payment data storage direction and most sector localisation expectations.
Is Hyderabad far enough from Mumbai for DR?
For most regulators and boards, yes. The cities are several hundred kilometres apart in different seismic and flood zones and on different power grids. Distance also keeps asynchronous replication lag low, typically seconds for databases, which is why it is the default AWS pair for Indian workloads.
How do we handle CERT-In log retention during a failover?
Logs must remain available for 180 days within Indian jurisdiction. NTSPL replicates the central log archive to the DR region and configures the DR stack to write to an in-region log sink immediately, so there is no gap in coverage after failover.
Do we need ExpressRoute or Direct Connect into both regions?
If users, plants or partners reach the application privately, yes, or at least an SD-WAN or VPN path that can be redirected to the DR region. A cloud DR that users cannot reach is not recovery. For internet-facing apps, global DNS or load balancing is enough.
Can we run DR in the second region for only part of the stack?
Yes, but dependencies must be complete. If the application recovers in Hyderabad but authentication still calls a Mumbai-only service, recovery fails. The dependency register is designed to catch exactly these partial setups. Partial DR is fine as long as every dependency of the recovered part is also available in the second region, or has a documented fallback.