In any system of reasonable complexity it is expected that failures will occur. It isgenerally of interest to know how to become aware of these failures, respond tothem, and prevent them from happening again.
With AWS, you can take advantage of automation to react to monitoring data. For example, when a particular metric crosses a threshold, you can trigger an automated action to remedy the problem. Also, rather than trying to diagnose and fix a failed resource that is part of your production environment, you can replace it with a new one and carry out the analysis on the failed resource out of band. Since the cloud enables you to stand up temporary versions of a whole system at low cost, you canuse automated testing to verify full recovery processes.
REL 6: How do you back up data?
Back up data, applications, and operating environments (defined as operating systems configured with applications) to meet requirements for mean time to recovery (MTTR) and recovery point objectives (RPO).
REL 7: How does your system withstand component failures?
If your workloads have a requirement, implicit or explicit, for high availability and low mean time to recovery (MTTR, architect your workloads for resilience and distribute your workloads to withstand outages.
REL 8: How does your system with stand component failures?
Test the resilience of your workload to help you find latent bugs that only surface inproduction. Exercise these tests regularly.
REL 9: How does your system with stand component failures?
Disaster recovery (DR) is critical should restoration of data be required from backup methods. Your definition of and execution on the objectives, resources, locations, and functions of this data must align with RTO and RPO objectives.
Regularly back up your data and test your backup files to ensure you can recover from both logical and physical errors. A key to managing failure is the frequent and automated testing of systems to cause failure, and then observe how they recover. Do this on a regular schedule and ensure that such testing is also triggered after significant system changes. Actively track KPIs, such as the recovery time objective (RTO) and recovery point objective (RPO), to assess a system’s resiliency (especially under failure-testing scenarios). Tracking KPIs will help you identify and mitigate single points of failure. The objective is to thoroughly test your system-recovery processes so that you are confident that you can recover all your data and continue to serve your customers, even in the face of sustained problems. Your recovery processes should be as well exercised as your normal production processes.