Geographic Redundancy and Replication

Geographic redundancy is the practice of deploying duplicate infrastructure—servers, databases, network links, and entire data centers—in physically separate locations to ensure that a single disaster does not cause total service loss. The separation must be sufficient to survive region-scale events: at least tens of kilometers, and often hundreds. For example, AWS offers multiple Availability Zones (AZs) within a Region, each with independent power, cooling, and network connectivity, separated by a few miles. For true disaster recovery, you might replicate data across AWS Regions (e.g., us-east-1 to us-west-2) which are hundreds of miles apart.

Geographic redundancy relies on two core mechanisms: replication and failover. Replication is the process of copying data and state from the primary site to the secondary site. Failover is the automatic or manual switch of traffic to the secondary site when the primary becomes unavailable.

Replication Modes: - Synchronous Replication: The primary system waits for an acknowledgment from the secondary before confirming the write to the client. This ensures zero data loss (RPO=0) but increases latency because every write must traverse the network round-trip. Used for critical databases (e.g., financial transactions) where data loss is unacceptable. Typically requires high-bandwidth, low-latency links (e.g., dedicated fiber). - Asynchronous Replication: The primary system acknowledges the write immediately and sends the data to the secondary later. This reduces latency but risks some data loss if the primary fails before the secondary receives the latest writes (RPO = seconds to minutes). Common for web applications and non-critical data.

Failover Modes: - Active-Active (Active/Active): Both sites handle traffic simultaneously. Load balancers distribute requests across both sites. If one site fails, the other continues serving. This maximizes resource utilization and provides instant failover, but requires careful data synchronization (often using multi-master replication) and conflict resolution. - Active-Passive (Active/Standby): Only the primary site handles traffic. The secondary site runs in standby mode, receiving replicated data but not serving requests. On failure, the standby must be promoted to active. This is simpler and cheaper but introduces a failover delay (RTO = minutes to hours).

Attackers target geographic redundancy to amplify impact. For example, a coordinated attack on both power grids supplying two data centers could take both offline. Defenders must ensure physical separation of power sources and network providers. A common attack is to corrupt data at the primary, which then replicates to the secondary, destroying both copies. Defenders implement immutable backups and point-in-time recovery to allow rollback before corruption spread.

Real Tools and Commands:

aws rds create-db-instance-read-replica \
    --db-instance-identifier my-db-replica \
    --source-db-instance-identifier my-db-instance \
    --region us-west-2

New-AzRecoveryServicesAsrProtectionContainerMapping \
    -Name "ContosoMapping" \
    -Policy $Policy \
    -PrimaryProtectionContainer $PrimaryContainer \
    -RecoveryProtectionContainer $RecoveryContainer

CHANGE MASTER TO
  MASTER_HOST='secondary.example.com',
  MASTER_USER='repl',
  MASTER_PASSWORD='password',
  MASTER_LOG_FILE='mysql-bin.000001',
  MASTER_LOG_POS=107;
START SLAVE;

The SY0-701 exam will present scenarios where you must choose the correct replication mode or failover strategy. Key decision points:

Scenario 1: Financial Services Firm with Active-Active Database

A global trading firm runs its order management system in two AWS Regions: us-east-1 (primary) and eu-west-1 (secondary). They use synchronous replication with Amazon Aurora Global Database. During a normal day, both regions handle read/write traffic. A network issue causes a brief outage in us-east-1. The AWS Global Database automatically promotes eu-west-1 to primary within 30 seconds. The firm's RTO is 1 minute, so this is acceptable. The engineer sees the failover event in CloudWatch as a 'Global Database failover' alarm. The correct response is to verify that the application is still serving requests and then investigate the root cause. A common mistake is to manually fail back immediately without checking data consistency, which could cause data loss if the original primary had uncommitted writes.

Scenario 2: E-Commerce Platform with Active-Passive Setup

An online retailer uses a primary data center in Dallas and a secondary in Phoenix. They use asynchronous SQL Server log shipping with a 5-minute replication delay. A tornado damages the Dallas data center. The IT team manually triggers failover by running a script that brings the Phoenix database online and updates DNS records (TTL set to 60 seconds). The site is fully operational after 12 minutes, meeting their RTO of 15 minutes. However, they lost 4 minutes of orders (RPO=5 minutes, actual loss=4 minutes). The engineer sees that the last log backup shipped was 4 minutes before the outage. The correct response is to accept the data loss and proceed. A common mistake is to try to recover the lost data from the damaged site, which delays failover and increases downtime.

Scenario 3: Healthcare Provider with Compliance Requirements

A hospital system stores patient records in an on-premises data center and replicates to a colocation facility 200 miles away. They use synchronous replication for the electronic health records (EHR) database to ensure zero data loss, as required by HIPAA. During a maintenance window, a technician accidentally disconnects the replication link. The primary database stalls because it cannot get acknowledgment from the secondary. The monitoring system alerts on 'replication latency critical.' The engineer must quickly decide whether to temporarily switch to asynchronous mode or accept the performance impact. The correct response is to switch to asynchronous mode to keep the primary operational, then restore synchronous replication after the link is fixed. A common mistake is to leave synchronous replication enabled, causing a full application outage.