Multi-Region DR on Cloud

The Case for Multi-Region Disaster Recovery

India faces diverse geographic risks — monsoon flooding in Mumbai, cyclones hitting Chennai and Visakhapatnam, earthquakes in the northern belt, and infrastructure disruptions across tier-2 cities. Relying on a single datacenter, even a well-managed one, leaves your business vulnerable to regional disasters.

Multi-region disaster recovery distributes your infrastructure across geographically separated datacenters so that a localized event cannot take down your entire operation.

Understanding Regions and Availability Zones

Cloud providers organize their infrastructure into:

**Region**: A geographic area containing one or more datacenters (e.g., Mumbai, Chennai, Hyderabad)
**Availability Zone (AZ)**: Isolated datacenters within a region, connected by low-latency links but designed to fail independently

For multi-region DR, you deploy across multiple regions. For high availability within a region, you spread across multiple AZs.

Multi-Region Architecture Patterns

Pattern 1: Active-Passive

One region handles all traffic while the secondary region stays warm or cold:

Primary Region (Mumbai)          Secondary Region (Chennai)
┌─────────────────────┐         ┌─────────────────────┐
│ Load Balancer        │         │ Load Balancer (off)  │
│ App Servers (active) │ ──sync──│ App Servers (standby)│
│ Database (primary)   │         │ Database (replica)   │
│ Cache Layer          │         │ Cache Layer          │
└─────────────────────┘         └─────────────────────┘
         ▲                                ▲
         │           DNS Failover         │
         └──────────┐    ┌────────────────┘
                    │    │
               ┌────────────┐
               │  Global DNS │
               └────────────┘

**Pros**: Lower cost, simpler to manage **Cons**: Secondary region is idle most of the time, failover takes longer

Pattern 2: Active-Active

Both regions serve traffic simultaneously:

Primary Region (Mumbai)       Secondary Region (Chennai)
┌─────────────────────┐      ┌─────────────────────┐
│ Load Balancer        │      │ Load Balancer        │
│ App Servers (active) │      │ App Servers (active) │
│ Database (primary)   │◄sync►│ Database (replica)   │
│ Cache Layer          │      │ Cache Layer          │
└─────────────────────┘      └─────────────────────┘
         ▲                            ▲
         │      Global Load Balancer  │
         └──────────┐    ┌────────────┘
                    │    │
              ┌──────────────┐
              │   GeoDNS /    │
              │ Global LB     │
              └──────────────┘

**Pros**: Zero downtime failover, better latency for users across India **Cons**: Higher cost, complex data synchronization

Pattern 3: Pilot Light

Minimal infrastructure always running in the secondary region. During disaster, auto-scale to full capacity:

Keep database replica and minimal app server running
Use infrastructure-as-code to deploy full stack in minutes
Automate scaling with scripts or Kubernetes HPA

Implementing Multi-Region DR

Step 1: Choose Your Regions

For Indian businesses, consider: - **Mumbai + Chennai**: Good geographic separation, both well-connected - **Mumbai + Hyderabad**: Central India coverage, growing datacenter ecosystem - **Delhi NCR + Chennai**: Maximum north-south separation

Step 2: Set Up Cross-Region Networking

Connect your regions securely:

# Set up WireGuard VPN tunnel between regions
# Mumbai server
[Interface]
Address = 10.100.0.1/24
PrivateKey = <mumbai-private-key>
ListenPort = 51820

[Peer] PublicKey = <chennai-public-key> Endpoint = chennai-server-ip:51820 AllowedIPs = 10.100.0.0/24 ```

Step 3: Configure Database Replication

For PostgreSQL streaming replication across regions:

-- On primary (Mumbai)
ALTER SYSTEM SET wal_level = 'replica';
ALTER SYSTEM SET max_wal_senders = 10;
ALTER SYSTEM SET wal_keep_size = '1GB';

-- Create replication user CREATE USER replicator WITH REPLICATION ENCRYPTED PASSWORD 'secure_password';

-- pg_hba.conf host replication replicator chennai-ip/32 scram-sha-256 ```

Step 4: Implement DNS-Based Failover

Use health checks and DNS failover:

# Route53 failover configuration
dns_failover:
  primary:
    endpoint: mumbai.example.com
    health_check: /api/health
    interval: 30s
    threshold: 3
  secondary:
    endpoint: chennai.example.com
    health_check: /api/health

Step 5: Synchronize Application State

Handle stateful components:

**Session state**: Use Redis with cross-region replication or JWT tokens (stateless)
**File uploads**: Sync via object storage replication
**Search indices**: Replicate via application-level sync or dedicated tools
**Message queues**: Use cross-region queue mirroring

Challenges and Solutions

Data Consistency

Cross-region replication introduces latency. For Indian geography, Mumbai to Chennai round-trip is approximately 20-30 milliseconds.

**Synchronous replication**: Zero data loss but higher latency for writes
**Asynchronous replication**: Lower latency but possible data loss during failover
**Quorum-based writes**: Write to two of three replicas for a balance

Split-Brain Scenarios

When both regions think they are primary:

Use a consensus protocol (etcd, Consul) for leader election
Implement fencing mechanisms to isolate the failed region
Design your application to handle duplicate processing idempotently

Cost Management

Multi-region DR increases costs, but you can optimize:

Use smaller instance types in the secondary region and auto-scale during failover
Reserve instances in both regions for base capacity
Use spot instances for non-critical secondary workloads
Implement intelligent traffic routing to balance load and reduce peak capacity needs

Testing Multi-Region Failover

Conduct regular chaos engineering exercises:

1. **DNS failover test**: Redirect traffic from primary to secondary 2. **Region isolation**: Simulate complete primary region failure 3. **Partial degradation**: Test behavior when one AZ fails 4. **Data integrity check**: Verify data consistency after failover 5. **Failback procedure**: Safely return to primary region

Conclusion

Multi-region disaster recovery is essential for any Indian business that cannot tolerate regional outages. Start with an active-passive architecture if cost is a concern, then evolve toward active-active as your business grows. Automate everything, test regularly, and monitor replication health continuously.

Multi-Region Disaster Recovery on Cloud: Building Resilience Across Indian Datacenters