- **Automatically recover from failure:** By monitoring a workload for key performance indicators (KPIs), you can run automation when a threshold is breached. These KPIs should be a measure of business value, not of the technical aspects of the operation of the service. This allows for automatic notification and tracking of failures, and for automated recovery processes that work around or repair the failure. With more sophisticated automation, it’s possible to anticipate and remediate failures before they occur. - **Test recovery procedures:** In an on-premises environment, testing is often conducted to prove that the workload works in a particular scenario. Testing is not typically used to validate recovery strategies. In the cloud, you can test how your workload fails, and you can validate your recovery procedures. You can use automation to simulate different failures or to recreate scenarios that led to failures before. This approach exposes failure pathways that you can test and fix _before_ a real failure scenario occurs, thus reducing risk. - **Scale horizontally to increase aggregate workload availability:** Replace one large resource with multiple small resources to reduce the impact of a single failure on the overall workload. Distribute requests across multiple, smaller resources to ensure that they don’t share a common point of failure. - **Stop guessing capacity:** A common cause of failure in on-premises workloads is resource saturation, when the demands placed on a workload exceed the capacity of that workload (this is often the objective of denial of service attacks). In the cloud, you can monitor demand and workload utilization, and automate the addition or removal of resources to maintain the optimal level to satisfy demand without over- or under-provisioning. There are still limits, but some quotas can be controlled and others can be managed (see [Manage Service Quotas and Constraints](https://docs.aws.amazon.com/wellarchitected/latest/reliability-pillar/manage-service-quotas-and-constraints.html)). - **Manage change through automation**: Changes to your infrastructure should be made using automation. The changes that need to be managed include changes to the automation, which then can be tracked and reviewed. - **장애 자동 복구**: 주요 성과 지표 (KPI) 에 대한 워크로드를 모니터링하여 임계값 위반 시 자동화를 실행할 수 있습니다.이러한 KPI는 서비스 운영의 기술적 측면이 아니라 비즈니스 가치를 나타내는 척도여야 합니다.이를 통해 장애를 자동으로 알림 및 추적하고 장애를 우회하거나 복구하는 자동 복구 프로세스를 사용할 수 있습니다.보다 정교한 자동화를 통해 장애가 발생하기 전에 이를 예측하고 해결할 수 있습니다. - **테스트복구 절차**: 온프레미스 환경에서는 특정 시나리오에서 워크로드가 제대로 작동하는지 확인하기 위해 테스트를 실시하는 경우가 많습니다.테스트는 일반적으로 복구 전략을 검증하는 데 사용되지 않습니다.클라우드에서는 워크로드가 어떻게 실패하는지 테스트하고 복구 절차를 검증할 수 있습니다.자동화를 사용하여 다양한 장애를 시뮬레이션하거나 이전에 실패로 이어진 시나리오를 재현할 수 있습니다.이 접근 방식은 실제 장애 시나리오가 발생하기 전에 테스트하고 수정할 수 있는 장애 경로를 노출시켜 위험을 줄입니다. - **수평적으로 확장하여 전체 워크로드 가용성을 높이십시오**. 하나의 큰 리소스를 여러 개의 작은 리소스로 대체하여 단일 장애가 전체 워크로드에 미치는 영향을 줄이십시오.요청을 여러 개의 소규모 리소스에 분산하여 공통된 장애 지점을 공유하지 않도록 하세요. - **용량 추측은 이제 그만**: 온프레미스 워크로드에서 발생하는 일반적인 장애 원인은 워크로드에 가해지는 수요가 해당 워크로드의 용량을 초과할 때 발생하는 리소스 포화 (서비스 거부 공격의 목적인 경우가 많음) 입니다.클라우드에서는 수요와 워크로드 사용률을 모니터링하고 리소스 추가 또는 제거를 자동화하여 오버프로비저닝이나 과소 프로비저닝 없이 수요를 충족하는 최적의 수준을 유지할 수 있습니다.여전히 제한이 있지만 일부 할당량은 제어할 수 있고 다른 할당량은 관리할 수 있습니다 (서비스 할당량 및 제약 관리 참조). - **자동화를 통한 변경 관리**: 인프라를 변경하려면 자동화를 사용해야 합니다.관리해야 하는 변경 사항에는 자동화 변경 사항이 포함되며, 이를 추적하고 검토할 수 있습니다.