AWS Landscape 22: Disaster Recovery (DR)

Business-critical SAP workloads require a robust disaster recovery (DR) strategy to maintain continuity during regional failures, natural disasters, or operational incidents. AWS Elastic Disaster Recovery (EDR) provides near real-time replication of EC2 instances, EBS volumes, and SAP workloads, enabling rapid failover to a secondary region with minimal data loss and downtime. This approach ensures compliance with RTO (Recovery Time Objective) and RPO (Recovery Point Objective) requirements for SAP systems.

Objective:

• Provide high availability and disaster resilience for SAP workloads.
• Minimize data loss (low RPO) and downtime (low RTO) during disasters.
• Enable regular DR testing without impacting production.
• Use AWS-native services for automated replication, failover, and monitoring.

Example:

• Primary Region: Singapore (ap-southeast-1)
• Secondary (DR) Region: Tokyo (ap-northeast-1)

DR Strategy:

• Continuous replication of SAP EC2 instances, EBS volumes, and OS configurations.
• Standby servers in Tokyo act as a staging area for failover.
• Failover is tested regularly to ensure business continuity.

Components:

• Source Servers: Production SAP App and DB servers in Singapore.
• Replication Server: AWS EDR replication server in Singapore.
• Staging Area: EBS volumes and snapshots in Tokyo ready for failover.
• Failover Process: Launch replicated workloads in Tokyo during outages.

Technical Steps for AWS EDR

Step 1: Set Up EDR

• Navigate to AWS Elastic Disaster Recovery → Get Started.
• Deploy EDR Replication Server in the primary region (Singapore).
• Configure staging area subnets and security groups in the secondary region (Tokyo).

Step 2: Install EDR Agents

• Install EDR agents on all SAP EC2 instances (Linux/Windows).
• Agents replicate data, OS configuration, and application state continuously.

Step 3: Configure Replication Settings

• Define Recovery Point Objective (RPO), e.g., 5 minutes.
• Set replication frequency and select staging instance types.
• Enable encryption at rest and in transit for all replicated data.

Step 4: Test Failover

• Initiate non-disruptive failover to Tokyo.
• Verify EC2 instance launches, SAP app availability, and DB consistency.
• Update DNS and routing to point to DR site during tests.

Step 5: Failback Process

• After the primary site is restored, fail back workloads to Singapore.
• Synchronize any changes that occurred during the DR period.
• Ensure data consistency and validate SAP workloads post-failback.

Step 6: Monitoring and Alerts

• Monitor replication lag, server health, and failover readiness via CloudWatch dashboards.
• Configure alarms for RPO breaches or replication failures.

Diagram – Disaster Recovery Flow

Diagram Highlights:

Primary Site: Singapore (Production SAP systems)

DR Site: Tokyo (Warm standby environment)

Replication: Continuous block-level replication using AWS Elastic Disaster Recovery

Failover: Automated instance launch in Tokyo

Monitoring: CloudWatch + SNS alerts

DR Characteristics:

RPO ---> ~5 minutes

RTO ---> Minutes

DR Type ---> Warm Standby

Testing ---> Non-disruptive DR testing supported