Assessing Application Fault Tolerance with AWS Resilience Hub - Visualizing RTO/RPO Target Achievement

Learn how to assess application fault tolerance with Resilience Hub, configure RTO/RPO policies, and leverage improvement recommendations.

The Need for Resilience Assessment and Resilience Hub's Role

Application fault tolerance (resilience) is quantified by RTO (Recovery Time Objective) - how quickly recovery occurs after failure - and RPO (Recovery Point Objective) - what data point can be recovered to. Even after RTO/RPO targets are set, it remains to verify whether the current architecture can meet those targets. Resilience Hub is a service that quantitatively assesses application fault tolerance and visualizes RTO/RPO achievement. It automatically discovers resource configurations from CloudFormation stacks, Terraform state files, AppRegistry-registered applications, or EKS clusters. Four assessment scenarios are available: AZ failure, region failure, application failure, and infrastructure failure, with individual RTO/RPO targets configurable per scenario. Detected resources include EC2, RDS, DynamoDB, S3, ELB, Lambda, ECS, and EKS, and the service analyzes each resource's configuration (Multi-AZ placement, replication, backup settings) to calculate a fault tolerance score.

Resilience Policy Definition and Assessment Execution

Using Resilience Hub begins with defining a resilience policy. The policy sets RTO/RPO targets for each failure scenario - for example, 'AZ failure: RTO 1 hour, RPO 5 minutes', 'Region failure: RTO 4 hours, RPO 1 hour', 'Application failure: RTO 30 minutes, RPO 5 minutes'. Next, register the application by specifying the CloudFormation stack name, which automatically maps resources and dependencies. Running an assessment analyzes each resource's current settings to estimate RTO/RPO and provides prioritized improvement recommendations for resources that fall short. Examples include converting single-AZ RDS to Multi-AZ, enabling S3 cross-region replication, increasing Auto Scaling group minimums, and enabling DynamoDB point-in-time recovery. Each recommendation includes cost impact and estimated RTO/RPO improvement, and re-assessment after implementation shows the score difference.

FIS Integration and Fault Testing

Resilience Hub integrates with FIS (Fault Injection Service) to generate recommended fault test templates based on assessment results. It verifies whether your application can actually meet RTO/RPO targets under scenarios such as AZ failure, EC2 instance termination, RDS failover, EBS I/O pause, and network latency injection. A results scorecard visualizes each component's fault tolerance level with color coding (green: met, yellow: partially unmet, red: unmet), clarifying improvement priorities. Automated SOP (Standard Operating Procedure) generation standardizes incident response procedures and outputs them as Systems Manager Automation documents. You run the cycle of assessment, improvement, testing, and re-assessment and keep reviewing application resilience.

Continuous Assessment and Operational Integration

Resilience Hub supports ongoing resilience management, not just one-time assessments. When application resource configurations change, drift detection identifies modifications and prompts re-assessment. EventBridge integration automates notifications and follow-up actions triggered by assessment completion, and embedding assessment steps in CI/CD pipelines detects fault tolerance regressions with each deployment. Organizations integration enables centralized management of applications across multiple accounts. Assessments can be scheduled for automatic monthly or quarterly execution in addition to manual runs.

Design Best Practices and Pitfalls

When operating Resilience Hub, you decide the granularity of application definitions. Monolithically grouping all resources into one application makes the scorecard unwieldy, so split applications by business domain or team and assign appropriate RTO/RPO tiers to each. You define tiers such as Tier-1 (mission-critical: RTO 5 min / RPO 1 min), Tier-2 (business: RTO 30 min / RPO 1 hour), and Tier-3 (informational: RTO 4 hours / RPO 24 hours) and set different target levels for each application. A common pitfall is that resources not included in CloudFormation stacks (manually created S3 buckets, DNS records) go undetected. If you register resources in AppRegistry or add them manually via Resource Mapping, you can include them in the assessment. Also note that assessments are static configuration analysis and do not guarantee actual recovery times. Combining FIS fault tests lets you check the scorecard assessment against actual behavior.

Comparison with Other AWS Services

Several AWS services address fault tolerance but serve different roles. AWS Backup provides centralized backup management and restore but does not assess overall architecture fault tolerance. CloudWatch detects anomalies with metrics and alarms but does not compare against RTO/RPO targets or generate improvement recommendations. Health Dashboard notifies you of AWS infrastructure incidents. Resilience Hub combines data from these services, assesses fault tolerance at the application level, and shows a path for improvement. It complements the Well-Architected Tool's reliability pillar: while Well-Architected Review provides qualitative design reviews, Resilience Hub automates quantitative assessment and specific improvement actions.

Resilience Hub Pricing

The original Resilience Hub is priced per application per month, and billing begins once the first resilience assessment is run. FIS test execution incurs separate FIS charges. Select applications for assessment based on criticality, and prioritize business-critical applications rather than assessing all uniformly to manage costs.

Summary

Resilience Hub quantitatively assesses application fault tolerance and visualizes RTO/RPO target achievement at the component level. Define targets per failure scenario in a resilience policy, then automatically discover architecture from CloudFormation stacks, Terraform state files, and EKS clusters to run assessments across four failure scenarios. Improvement recommendations include cost impact estimates, and FIS integration automates fault testing. Drift detection and CI/CD integration enable continuous assessment, and application-level segmentation and RTO/RPO tier design are prerequisites for operation.

References (Official AWS Resources)

The primary sources for this page are the official AWS website and documentation. Check the official pages below for the latest specifications and pricing.

If this page and the official documentation disagree, treat the official documentation as authoritative.

Share