AWS sap documentation change
Summary
Removed all references to Short Distance Disaster Recovery (SDDR) and streamlined documentation to focus exclusively on Long Distance Disaster Recovery (LDDR) fenced testing. Updated explanations, removed SDDR architecture diagrams, and refined DR testing procedures.
Security assessment
The changes remove outdated content about SDDR but maintain existing security protocols for LDDR (network isolation, DNS separation). No vulnerability fixes or security incident responses are mentioned. The core security feature (fenced testing isolation) remains documented without enhancements.
Diff
diff --git a/sap/latest/general/rise-fenced-dr-testing.md b/sap/latest/general/rise-fenced-dr-testing.md index 0ec76f476..c4c3e3e59 100644 --- a//sap/latest/general/rise-fenced-dr-testing.md +++ b//sap/latest/general/rise-fenced-dr-testing.md @@ -7 +7 @@ -Benefits of fenced DR TestingArchitecture OverviewLDDR Fenced TestingSDDR Fenced Testing +Benefits of fenced DR TestingArchitecture OverviewLDDR Fenced Testing @@ -11 +11 @@ Benefits of fenced DR TestingArchitecture OverviewLDDR Fenced TestingSDDR Fenced -Fenced DR Testing is a disaster recovery testing capability for RISE with SAP customers using Long Distance Disaster Recovery (LDDR) or Short Distance Disaster Recovery (SDDR). It uses network isolation to create a segregated testing environment where production and DR systems operate simultaneously, eliminating the need for planned downtime during DR validation. The isolation is maintained at multiple layers, including network routing, DNS resolution, and application connectivity, which prevents cross-contamination between environments. +Fenced DR Testing is a disaster recovery testing capability for RISE with SAP customers using Long Distance Disaster Recovery (LDDR). It uses network isolation to create a segregated testing environment. Production and DR systems operate simultaneously, eliminating the need for planned downtime during DR validation. Isolation spans multiple layers: network routing, DNS resolution, and application connectivity. These layers prevent cross-contamination between environments. @@ -15 +15 @@ Fenced DR Testing is a disaster recovery testing capability for RISE with SAP cu -AWS best practices recommend using multiple AWS Regions for disaster recovery. The term "Short Distance Disaster Recovery" (SDDR) is SAP-specific terminology used within the RISE with SAP context. In standard AWS terminology, deploying across multiple Availability Zones within a single Region provides high availability (HA), not disaster recovery. For more information about AWS disaster recovery strategies, see the [AWS Well-Architected Framework – Reliability Pillar](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html). +We recommend using multiple AWS Regions for disaster recovery. For more information about AWS disaster recovery strategies, see the [AWS Well-Architected Framework – Reliability Pillar](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/welcome.html). @@ -19 +19 @@ AWS best practices recommend using multiple AWS Regions for disaster recovery. T -Fenced DR Testing is available in all AWS regions if you subscribe to RISE with SAP Long Distance Disaster Recovery (LDDR) or Short Distance Disaster Recovery (SDDR). +Fenced DR Testing is available in all AWS Regions if you subscribe to RISE with SAP Long Distance Disaster Recovery (LDDR). @@ -86 +86 @@ Fenced DR Testing creates a parallel network environment that mirrors your produ -Long Distance Disaster Recovery (LDDR) Fenced Testing allows you to validate your DR environment without disrupting production. During a fenced test, the DR system in the standby AWS Region is isolated from production. Your primary system continues to run normally in the primary Region, including local high-availability replication across Availability Zones. While the test is active, replication to the standby Region is paused, meaning there is no cross-region protection during this window; a regional failure could result in data loss. After testing is complete, replication resumes automatically and the DR system re-synchronizes with production. +With Long Distance Disaster Recovery (LDDR) Fenced Testing, you can validate your DR environment without disrupting production. During a fenced test, SAP isolates the DR system in the standby AWS Region from production. Your primary system continues to run normally in the primary Region. Local high-availability replication across Availability Zones remains active. During the test, SAP pauses replication to the standby Region. During this window, cross-region protection is unavailable, and a regional failure might result in data loss. After testing is complete, replication resumes automatically and the DR system re-synchronizes with production. @@ -96 +96 @@ The following diagram shows the network topology for LDDR Internal Fencing. - + @@ -102 +102 @@ You must configure network separation on-premises to isolate the DR landscape, t -DR site is completely isolated; you provide specific IPs for testing team access to fenced environment. +The DR site is completely isolated. You provide specific IP addresses for the testing team to access the fenced environment. @@ -106 +106 @@ The following diagram shows the network topology for LDDR Complete Fencing. - + @@ -108 +108 @@ The following diagram shows the network topology for LDDR Complete Fencing. -The DR site is completely isolated from both the production SAP RISE systems and external networks. You must provide specific IP addresses or ranges for testing team access to the isolated DR systems. Testing IPs will have access to both primary and DR sites, so teams must carefully verify which environment they are working in during tests. No data replication occurs between sites during DR testing, preventing production users from accidentally accessing the DR environment. +The DR site is completely isolated from both the production SAP RISE systems and external networks. You must provide specific IP addresses or ranges for testing team access to the isolated DR systems. Testing IPs have access to both primary and DR sites, so you must carefully verify which environment you are working in during tests. No data replication occurs between sites during DR testing, preventing production users from accidentally accessing the DR environment. @@ -110,27 +110 @@ The DR site is completely isolated from both the production SAP RISE systems and -## SDDR Fenced Testing - -Short Distance Disaster Recovery (SDDR) Fenced Testing allows you to validate your DR environment within a single AWS Region. During a fenced test, an isolated DR system is used in a third Availability Zone (AZ3), separate from your production workloads. Your primary system continues to operate normally in AZ1, and high-availability replication to AZ2 remains active and unaffected. While the test is running, replication to the fenced system in AZ3 is paused. After testing is complete, replication resumes and the DR system re-synchronizes automatically. - -The same two scenarios apply to SDDR. - -### SDDR Internal Fencing - -Similar to LDDR Internal Fencing, Production in AZ1/AZ2 and DR (AZ3) remain accessible to you with complete network isolation between Production and DR sites. No cross-traffic between AZ1/AZ2 and AZ3. - -You configure on-premises network separation to prevent accidental DR access during testing. - -The following diagram shows the network topology for SDDR Internal Fencing. - - - -### SDDR Complete Fencing - -Similar to LDDR Complete Fencing, DR site is completely isolated; you provide specific IPs for testing team access to fenced environment. - -The following diagram shows the network topology for SDDR Complete Fencing. - - - -The DR site is completely isolated from both the production SAP RISE systems and external networks. You must provide specific IP addresses or ranges for testing team access to the isolated DR systems. Testing IPs will have access to both primary and DR sites, so teams must carefully verify which environment they are working in during tests. No data replication occurs between sites during DR testing, preventing production users from accidentally accessing the DR environment. - -We recommend that you coordinate with SAP on DR test procedures, as you might have existing DR Standard Operating Procedures (SOPs) that can be adapted. As part of the DR test preparation, create a Responsible, Accountable, Consulted, and Informed (RACI) matrix for all parties involved, that is, you, your vendors, and SAP. +We recommend that you coordinate with SAP on DR test procedures, because you might have existing DR Standard Operating Procedures (SOPs) that can be adapted. As part of the DR test preparation, create a Responsible, Accountable, Consulted, and Informed (RACI) matrix for all parties involved, that is, you, your vendors, and SAP.