AWS drs documentation change
Summary
Updated terminology from 'failover' to 'recovery' in multiple sections and changed section title from 'Quick start guide' to 'Disaster recovery at scale'
Security assessment
Changes appear to be editorial improvements and terminology alignment without addressing security vulnerabilities or adding security-specific guidance. The modifications focus on clarifying recovery processes and documentation structure.
Diff
diff --git a/drs/latest/userguide/best_practices_drs.md b/drs/latest/userguide/best_practices_drs.md index d5217c4fd..aceea1b7b 100644 --- a//drs/latest/userguide/best_practices_drs.md +++ b//drs/latest/userguide/best_practices_drs.md @@ -57 +57 @@ You should control who can install the AWS Replication Agent in your account. On - 1. **Overview:** DRS makes successful failover possible, by handling ongoing replication, and the on-demand launching of actual Recovery instances. The re-routing of data is not done via DRS, and should be done using your preferred DNS routing service, such as [Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html). Your recovery plan should include details of which service to use, who in your organization owns this service, and what conditions must be met to perform the re-routing (for example: launch Recovery instances using DRS, perform successful launch-validation test, wait for system X, Y, and Z to also launch and pass test, then re-route). + 1. **Overview:** DRS makes successful recovery possible, by handling ongoing replication, and the on-demand launching of actual Recovery instances. The re-routing of traffic (failover) is not done via DRS, and should be done using your preferred DNS routing service, such as [Amazon Route 53](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/Welcome.html). Your recovery plan should include details of which service to use, who in your organization owns this service, and what conditions must be met to perform the re-routing (for example: launch Recovery instances using DRS, perform successful launch-validation test, wait for system X, Y, and Z to also launch and pass test, then re-route). @@ -63 +63 @@ You should control who can install the AWS Replication Agent in your account. On - 4. **Failover dos and don’ts:** Do not use the **Disconnect from AWS** action in the DRS console for servers for which you launched Recovery instances, even in the case of a real recovery event. Performing a disconnect terminates all replication resources related to these source servers, including your Point-In-Time (PIT) recovery points. You may need these PITs while you are in failover state, for regulatory reasons, or to re-launch a Recovery instances for any reason (for instance if you discover that the PIT from which you launched includes corrupt or malicious data, and you want to relaunch from an earlier PIT). While you use your Recovery instances as your primary, and new data is presumably written to them, these recovery instances are not themselves being replicated, and you are not creating any new PITs for these changes. It is possible to configure the recovery instances as new source servers and [replicate them cross-Region](https://docs.aws.amazon.com/drs/latest/userguide/failback-failover-region-region.html), to have disaster recovery for your recovery site. This carries with it additional costs, as noted in [Performing a cross-Region failback](https://docs.aws.amazon.com/drs/latest/userguide/failback-failover-region-region.html) + 4. **Recovery dos and don’ts:** Do not use the **Disconnect from AWS** action in the DRS console for servers for which you launched Recovery instances, even in the case of a real recovery event. Performing a disconnect terminates all replication resources related to these source servers, including your Point-In-Time (PIT) recovery points. You may need these PITs while you are in failover state, for regulatory reasons, or to re-launch a Recovery instances for any reason (for instance if you discover that the PIT from which you launched includes corrupt or malicious data, and you want to relaunch from an earlier PIT). While you use your Recovery instances as your primary, and new data is presumably written to them, these recovery instances are not themselves being replicated, and you are not creating any new PITs for these changes. It is possible to configure the recovery instances as new source servers and [replicate them cross-Region](https://docs.aws.amazon.com/drs/latest/userguide/failback-failover-region-region.html), to have disaster recovery for your recovery site. This carries with it additional costs, as noted in [Performing a cross-Region failback](https://docs.aws.amazon.com/drs/latest/userguide/failback-failover-region-region.html) @@ -111 +111 @@ Using the console -Quick start guide +Disaster recovery at scale