AWS prescriptive-guidance documentation change
Summary
Updated document title in breadcrumb and refined disaster recovery testing guidance with minor wording improvements
Security assessment
Changes emphasize disaster recovery preparedness but don't address specific vulnerabilities. Enhanced DR testing recommendations are operational best practices rather than security fixes or new security features.
Diff
diff --git a/prescriptive-guidance/latest/resilience-lifecycle-framework/post-deployment.md b/prescriptive-guidance/latest/resilience-lifecycle-framework/post-deployment.md index 113d3b742..431ca4592 100644 --- a//prescriptive-guidance/latest/resilience-lifecycle-framework/post-deployment.md +++ b//prescriptive-guidance/latest/resilience-lifecycle-framework/post-deployment.md @@ -5 +5 @@ -[Documentation](/index.html)[AWS Prescriptive Guidance](https://aws.amazon.com/prescriptive-guidance/)[Resilience lifecycle framework](introduction.html) +[Documentation](/index.html)[AWS Prescriptive Guidance](https://aws.amazon.com/prescriptive-guidance/)[Resilience lifecycle framework: A continuous approach to resilience improvement](introduction.html) @@ -19 +19 @@ Assessing resilience doesn't stop after you deploy your application into product -In [Stage 2: Design and implement](./stage-2.html), you developed disaster recovery (DR) strategies as part of your system. During Stage 4, you should test your DR procedures to ensure that your team is fully prepared for an incident and your procedures work as expected. You should test all your DR procedures, including failover and failback, on a regular basis and review the results of each exercise to determine if and how your system's procedures should be updated for the best possible outcome. When you initially develop your DR test, schedule the test well in advance and ensure that the entire team understands what to expect, how the outcomes will be measured, and what feedback mechanism will be used to update procedures based on the outcome. After you become proficient in running scheduled DR tests, consider running unannounced DR tests. Real disasters don't occur on a schedule, so you need to be prepared to exercise your plan at any time. However, unannounced doesn't mean unplanned. Key stakeholders still need to plan the event to ensure that proper monitoring is in place and that customers and critical applications are not adversely impacted. +In the [Stage 2: Design and implement](./stage-2.html) stage, you developed disaster recovery (DR) strategies as part of your system. During Stage 4, you should test your DR procedures to ensure that your team is fully prepared for an incident and your procedures work as expected. You should test all your DR procedures, including failover and failback, on a regular basis and review the results of each exercise to determine if and how your system's procedures should be updated for the best possible outcome. When you initially develop your DR test, schedule the test well in advance and ensure that the entire team understands what to expect, how the outcomes will be measured, and what feedback mechanism will be used to update procedures based on the outcome. After you become proficient in running scheduled DR tests, consider running unannounced DR tests. Real disasters don't occur on a schedule, so you need to be prepared to exercise your plan at any time. However, unannounced doesn't mean unplanned. Key stakeholders still need to plan the event to ensure that proper monitoring is in place and that customers and critical applications are not adversely impacted.