# Using AWS Resilience Hub Using AWS Resilience Hub AWS Resilience Hub helps you improve the resiliency of your applications on AWS and reduce the recovery time in the event of application outages. **Topics** + [ # AWS Resilience Hub summary ](view-arh-summary-ug.md) + [ # AWS Resilience Hub dashboard ](view-app-dashboard.md) + [ # Describing and managing AWS Resilience Hub Applications ](applications.md) + [ # Managing resiliency policies ](resiliency-policies.md) + [ # Running and managing resiliency assessments in AWS Resilience Hub ](resil-assessments.md) + [ # Running and managing resiliency assessments from Resiliency widget ](resil-assessments-resiliency-widget.md) + [ # Managing alarms ](alarms.md) + [ # Managing standard operating procedures ](sops.md) + [ # Managing AWS Fault Injection Service experiments ](testing.md) + [ # Understanding resiliency scores ](resil-score.md) + [ # Integrating operational recommendations into your application with CloudFormation ](cfn-integration.md) # AWS Resilience Hub summary AWS Resilience Hub summary AWS Resilience Hub provides a visual summary with charts and graphs that gives you an at-a-glance view of your application's resilience posture across multiple AWS services and resources. This comprehensive and concise visual summary enables you to quickly identify potential resilience gaps, prioritize actions, and track progress in enhancing your application's ability to recover from disruptions. When you choose **Export**, and if you are exporting the metrics for the first time, AWS Resilience Hub creates a new Amazon S3 bucket in the Region from which you are accessing AWS Resilience Hub. This Amazon S3 bucket is created only for the first time and will be used to save the exported metrics upon successful completion. Additional charges apply for storing exported data in Amazon S3. For more information about these charges, [Amazon S3 pricing](https://aws.amazon.com/s3/pricing/). The charts and graphs in the widgets help you understand the following: + Overview of the application's overall resilience score and current operational state. + Potential policy violations or deviations from best practices by highlighting applications that are not compliant with established policies or have drifted from recommended configurations. Additionally, it also highlights specific areas that enables you to prioritize and address them. + Critical resources or applications that demand immediate attention. + Recommendations for enhancing resilience practices, such as implementing alarms, conducting AWS Fault Injection Service (AWS FIS) experiments, and establishing standard operating procedures. These recommendations are tracked over time, allowing you to monitor the implementation progress and measure the impact on the application's overall resilience posture. **Topics** + [ ## Application status ](#arh-summary-app-status-ug) + [ ## Top infrastructure recommendations by resource type ](#arh-summary-infra-top-recommendation-ug) + [ ## Infrastructure recommendations ](#arh-summary-infra-recommendation-ug) + [ ## Unimplemented operational recommendations ](#arh-summary-ops-recommendation-ug) + [ ## Alarm recommendations ](#arh-summary-alarms-overtime-recommendation-ug) + [ ## SOP recommendations ](#arh-summary-sop-overtime-recommendation-ug) + [ ## AWS FIS experiment recommendations ](#arh-summary-fis-exp-overtime-recommendation-ug) + [ ## Applications with drifts ](#arh-summary-app-drifts-ug) + [ ## Resiliency score ](#arh-summary-res-score-overtime-recommendation-ug) + [ ## Bottom 10 applications for resiliency score ](#arh-summary-res-score-bottom-ten-app-ug) + [ ## Application state by policy ](#arh-summary-app-state-policy-ug) ## Application status This widget indicates if your applications comply with the resiliency policy or not. Choose the number adjacent to the **Application count** in the pop-up to view all the associated applications in the **Applications** pane. To view all the applications you have created, choose **View applications**. For more information about managing applications in AWS Resilience Hub, see [Viewing an AWS Resilience Hub application summary](view-app-summary.md). ## Top infrastructure recommendations by resource type This widget displays the number of infrastructure recommendations for each resource type of your AWS resources provided in the last successful assessment to improve their resiliency posture. You can identify the details by hovering over them or by navigating to them. To view all the applications you have created, choose **View applications**. For more information about infrastructure recommendations, see [Reviewing resiliency recommendations](resil-recs.md). ## Infrastructure recommendations This widget lists up to 10 applications that have the maximum number of infrastructure recommendations provided in the last successful assessment to improve their resiliency posture. To view all the applications you have created, choose **View applications**. For more information about infrastructure recommendations, see [Reviewing resiliency recommendations](resil-recs.md). You can identify the details using the following: + **Application name** – Name of the application that you provided while defining it in AWS Resilience Hub. + **Count** – Indicates the number of infrastructure recommendations provided by AWS Resilience Hub in the last successful assessment. Choose the number to view all the infrastructure recommendations provided in the assessment report. + **Last assessed** – Indicates the date and time when your application was last assessed successfully. ## Unimplemented operational recommendations This widget lists up to 10 applications that have the maximum number of unimplemented operational recommendations provided in the last successful assessment to improve their resiliency posture. To view all the applications you have created, choose **View applications**. For more information about operational recommendations, see [Reviewing operational recommendations](ops.reqs.md). You can identify the details using the following: + **Application name** – Name of the application that you provided while defining it in AWS Resilience Hub. + **Count** – Indicates the number of operational recommendations provided by AWS Resilience Hub in the last successful assessment. Choose the number to view all the unimplemented operational recommendations in the assessment report. + **Last assessment time** – Indicates the date and time when your application was last assessed successfully. ## Alarm recommendations This widget lists all the Amazon CloudWatch alarm recommendations provided for improving the resilience posture over a selected time period. The different categories (**Implemented**, **Not implemented**, and **Excluded**) indicate their implementation state in your application. You can view the number of Amazon CloudWatch alarm recommendations for each category by hovering over them or by navigating to them. To view all the applications you have created, choose **View applications**. For more information about alarm recommendations, see [Reviewing operational recommendations](ops.reqs.md). ## SOP recommendations This widget lists all the standard operating procedure (SOP) recommendations provided for improving the resilience posture over a selected time period. The different categories (**Implemented**, **Not implemented**, and **Excluded**) indicate their implementation state in your application. You can view the number of SOP recommendations for each category by hovering over them or by navigating to them. To view all the applications you have created, choose **View applications**. For more information about operational recommendations, see [Reviewing operational recommendations](ops.reqs.md). ## AWS FIS experiment recommendations This widget lists all the AWS FIS experiment recommendations provided for improving the resilience posture over a selected time period. The different categories (**Implemented**, **Not implemented**, **Partially implemented**, and **Excluded**) indicate their implementation state in your application. You can view the number of AWS FIS experiment recommendations for each category by hovering over them or by navigating to them. To view all the applications you have created, choose **View applications**. For more information about AWS FIS experiment recommendations, see [Managing standard operating procedures](sops.md). ## Applications with drifts This widget lists all your applications that have drifted from their previous compliant state in the last successful assessment. To view all the applications you have created, choose **View applications**. For more information about managing applications in AWS Resilience Hub, see [Viewing an AWS Resilience Hub application summary](view-app-summary.md). You can identify the details using the following: + **Application name** – Name of the application that you provided while defining it in AWS Resilience Hub. + **Policy drifts** – Choose the number adjacent to the application name to view all the Application Components that complied with the policy in the previous assessment but failed to comply in the current assessment. + **Resource drifts** – Choose the number below to view all the resources that have changed from their configuration in the latest import. ## Resiliency score This widget displays the trend of the application's resiliency score over a selected time period for up to five applications. You can view an application's resiliency score by hovering over the line associated with the application name or by navigating to it, and then choosing the application name to view the application summary. To view all the applications you have created, choose **View applications**. For more information about resilience score, see [Understanding resiliency scores](resil-score.md). ## Bottom 10 applications for resiliency score This widget lists up to 10 applications with the lowest resiliency scores from their most recent assessments, highlighting the applications that require immediate attention to improve their resilience. To view all the applications you have created, choose **View applications**. For more information about resilience score, see [Understanding resiliency scores](resil-score.md). You can identify the details using the following: + **Application name** – Name of the application that you provided while defining it in AWS Resilience Hub. + **Resiliency score** – The overall resiliency score determined by AWS Resilience Hub for your application after running the assessment. + **Last assessment time** – Indicates the date and time when your application was last assessed successfully. ## Application state by policy This widget lists all your policies and the number of applications that have breached, met, or yet to be assessed against them. To view all the policies you have created, choose **View policies**. For more information about resilience score, see [Managing resiliency policies](resiliency-policies.md). You can identify the details using the following: + **Policy name** – Indicates the policy name you provided while defining it in AWS Resilience Hub. + **Type** – Indicates that the type of policy (**Resiliency policy**) attached to the application. + **Policy name** – Indicates the number of applications that have either breached the RTO and RPO targets defined in the resiliency policy. + **Apps met** – Indicates the number of applications that are compliant with the resiliency policy. + **Apps not assessed** – Indicates the number of applications that are yet to be assessed against the resiliency policy. + **Resiliency score** – The overall resiliency score determined by AWS Resilience Hub for your application after running the assessment. + **Last assessment time** – Indicates the date and time when your application was last assessed successfully. # AWS Resilience Hub dashboard AWS Resilience Hub dashboard The dashboard provides a comprehensive view of the resilience status of your application portfolio. The dashboard aggregates and organizes resilience events (for example, unavailable database or failed resilience validation), alerts, and insights from services such as CloudWatch and AWS Fault Injection Service (AWS FIS). The dashboard also generates a resilience score for each application that’s assessed. This score indicates how well your application performs when assessed against recommended resilience policies, alarms, recovery standard operating procedures (SOPs), and tests. You can use this score to measure resilience improvements over time. To view AWS Resilience Hub dashboard, choose **Dashboard** from navigation menu. The **Dashboard** page displays the following sections: ## Application status The application statuses indicate whether the applications have been assessed for compliance with their attached resiliency policy or not. In addition, after an assessment is completed, the status also indicates if the input sources of your applications have been modified or not. Choose a number under each of the following statuses to view all the applications that share the same status in the **Applications** page: + **Applications in policy** – Indicates all the applications that comply with their attached resiliency policy. + **Applications breaching policy** – Indicates all the applications that does not comply with their attached resiliency policy. + **Applications not assessed** – Indicates all the applications whose compliance has not been assessed or tracked yet. + **Applications drifted** – Indicates all the applications that have drifted from their resiliency policy or if their resources have drifted. ## Application resiliency score over time With the application resiliency score over time, you can view a graph of your application's resiliency over the past 30 days. While the dropdown menu can list 10 of your applications, AWS Resilience Hub only shows you a graph of up to four applications at a time. For more information about resiliency score, see [Understanding resiliency scores](resil-score.md). **Note** AWS Resilience Hub does not run scheduled assessments at the same time. As a result, you may need to return to the resiliency score over time graph at a later time to view the daily assessment of your applications. AWS Resilience Hub also uses Amazon CloudWatch to generate these graphs. Choose **View metrics in CloudWatch** to create and view more granular information about your application's resiliency in your CloudWatch dashboard. For more information about CloudWatch, see [Using dashboards](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/create_dashboard.html) in the *Amazon CloudWatch User Guide*. ## Implemented alarms This section lists all the alarms that you have set up in Amazon CloudWatch to monitor all the applications. For more information , see [Viewing alarms](view-alarm.md). ## Implemented experiments This section lists all fault injection experiments that you have implemented in all the applications. For more information, see [Viewing AWS FIS experiments](view-fis-experiment.md). # Describing and managing AWS Resilience Hub Applications Managing applications An AWS Resilience Hub application is a collection of AWS resources that are structured to prevent and recover AWS application disruptions. To describe an AWS Resilience Hub application, you provide an application name, resources from one or more CloudFormation stacks, and an appropriate resiliency policy. You can also use any existing AWS Resilience Hub application as a template to describe your application. After you describe an AWS Resilience Hub application, you must publish it so that you can run a resiliency assessment on it. You can then use recommendations from the assessment to improve resiliency by running another assessment, comparing results, and then reiterating the process until your estimated workload RTO and estimated workload RPO meet your RTO and RPO targets. To view the **Applications** page, choose **Applications** from the navigation pane. You can identify your applications in the **Applications** page by the following: + **Name** – The name of the application you had provided while defining it in AWS Resilience Hub. + **Description** – The description of the application you had provided while defining it in AWS Resilience Hub. + **Compliance status** – AWS Resilience Hub sets the application status as **Assessed**, **Not assessed**, **Policy breached**, or is **Changes detected**. + **Assessed** - AWS Resilience Hub has assessed your application. + **Not assessed** - AWS Resilience Hub has not assessed your application. + **Policy breached** - AWS Resilience Hub has determined your application did not meet your resiliency policy's objectives for Recovery Time Objective (RTO) and Recovery Point Objective (RPO). Review and use the recommendations provided by AWS Resilience Hub before reassessing your application for resiliency. For more information about recommendations, see [Add an application to AWS Resilience Hub](describe-applicationlication.md). + **Changes detected** - AWS Resilience Hub has detected changes made to the resiliency policy associated with your application. You must reassess your application for AWS Resilience Hub to determine if your application meets your resiliency policy's objectives. + **Scheduled assessments** – The resource type identifies the component resource for your application. For more information about scheduled assessments, see [Application resiliency](view-app-summary.md). + **Active** - This indicates your application is automatically assessed daily by AWS Resilience Hub. + **Disabled** - This indicates your application is not automatically assessed daily by AWS Resilience Hub and you must manually assess your application. + **Drift status** – Indicates if your application has drifted or not from the previous successful assessment and sets one of the following statuses: + **Drifted** - Indicates that the application, which was compliant with its resiliency policy in the previous successful assessment, has now breached the resiliency policy and the application is at risk. Additionally, it also indicates if the resources within input sources, which are included in the current application version, were added or removed. + **Not drifted** - Indicates that the application is still estimated to meet its RTO and RPO targets defined in the policy. Additionally, it also indicates that the resources within input sources, which are included in the current application version, were not added or removed. + **Estimated workload RTO** – Indicates the maximum possible estimated workload RTO of your application. This value is the maximum estimated workload RTO of all the disruption types from the last successful assessment. + **Estimated workload RPO** – Indicates the maximum possible estimated workload RPO of your application. This value is the maximum estimated workload RTO of all the disruption types from the last successful assessment. + **Last assessment time** – Indicates the date and time your application was last assessed successfully. + **Creation time** – The date and time that the application was created. + **ARN** – The Amazon Resource Name (ARN) of your application. For more information about ARNs, see [Amazon Resource Names (ARNs)](https://docs.aws.amazon.com//general/latest/gr/aws-arns-and-namespaces.html) in the *AWS General Reference*. **Note** AWS Resilience Hub can fully assess the resiliency of cross-Region Amazon ECS resources only if you are using Amazon ECR for the image repository. In addition, you can also filter the applications list by using one of the following options in the **Applications** page: + **Find applications** – Enter your application name to filter the results by the name of your application. + **Filter last assessment time by a date and time range** – To apply this filter, choose the calendar icon and select one of the following options to filter by the results that matches the time range: + **Relative range** – Select one of the available options and choose **Apply**. If you choose **Customised range** option, enter a duration in **Enter duration** box and select the appropriate unit of time from **Unit of time** dropdown list, then choose **Apply**. + **Absolute range** – To specify the date and time range, provide the start time and end time, and then choose **Apply**. The following topics show the different approaches for describing an AWS Resilience Hub application and how to manage them. **Topics** + [ # Viewing an AWS Resilience Hub application summary ](view-app-summary.md) + [ # Editing AWS Resilience Hub application resources ](application-resources.md) + [ # Managing Application Components ](AppComponent.md) + [ # Publishing a new AWS Resilience Hub application version ](applications-publish.md) + [ # Viewing all the AWS Resilience Hub application versions ](view-application-version.md) + [ # Viewing resources of AWS Resilience Hub application ](view-resources.md) + [ # Deleting an AWS Resilience Hub application ](applications-delete.md) + [ # Application configuration parameters ](app-config.md) # Viewing an AWS Resilience Hub application summary Viewing application summary The application summary page in the AWS Resilience Hub console provides an overview of your application information and resiliency health. **To view an application summary** 1. Choose **Applications** from the navigation pane. 1. On the **Applications** page, choose the name of the application you want to view. The applications summary page has the following sections. **Topics** + [ ## Assessment Summary ](#view-assessment-summary-resiliency) + [ ## Summary ](#view-app-summary-resiliency) + [ ## Application resiliency ](#view-app-resiliency) + [ ## Implemented alarms ](#view-app-alarms) + [ ## Implemented experiments ](#view-app-experiments) ## Assessment Summary This section provides a summary of the last successful assessment and highlights critical recommendations as actionable insights. AWS Resilience Hub uses Amazon Bedrock generative AI capabilities to help focus users on the most critical resilience recommendations provided by AWS Resilience Hub. By focusing on the critical items, you can focus on the most critical recommendations that improves the resilience posture of your application. Choose a recommendation to view its summary and choose **View details** to view more details about the recommendations in the relevant section of the assessment report. For more information about reviewing the assessment report, see [Reviewing assessments reports](review-assessment.md). **Note** This assessment summary is available only in US East (N. Virginia) Region. The assessment summary generated by large language models (LLMs) on Amazon Bedrock are only suggestions. The current level of generative AI technology is not perfect and LLMs are not infallible. Bias and incorrect answers, although rare, should be expected. Review each recommendation in the **Assessment summary** before you use the output from an LLM. ## Summary This section provides a summary of the selected application in the following sections: + **Application info** – This section provides the following information about the selected application: + **Application status** – Indicates the status of the application. + **Description** – The description of the application. + **Version** – Indicates the currently assessed version of the application. + **Resiliency policy** – Indicates the resiliency policy that is attached the application. For more information about resiliency policies, see [Managing resiliency policies](resiliency-policies.md). + **Application drifts** – This section highlights the drifts detected while running an assessment for the selected application to check if it is compliant with its resiliency policy. Additionally, it also checks if any of the resources have been added or removed since the last time the application version was published. This section displays the following information: + **Policy drifts** – Choose the number below to view all the Application Components that complied with the policy in the previous assessment but failed to comply in the current assessment. + **Resource drifts** – Choose the number below to view all the drifted resources in the latest assessment. ## Application resiliency The metrics shown in the **Resiliency score** section are from the most recent resiliency assessment of the application. **Resiliency score** The resiliency score helps you quantify your readiness to handle a potential disruption. This score reflects how closely your application has followed the AWS Resilience Hub recommendations for meeting the application's resiliency policy, alarms, standard operating procedures (SOPs), and tests. The maximum resiliency score that your application can achieve is 100%. The score represents all recommended tests that run in a predefined period of time. It indicates that the tests are initiating the correct alarm, and that the alarm initiates the correct SOP. For example, suppose that AWS Resilience Hub recommends one test with one alarm and one SOP. When the test runs, the alarm initiates the associated SOP, and then runs successfully. For more information about the resiliency score, see [Understanding resiliency scores](resil-score.md). ## Implemented alarms The application summary **Implemented alarms** section lists the alarms that you set up in Amazon CloudWatch to monitor the application. For more information about alarms, see [Managing alarms](alarms.md). ## Implemented experiments The application summary **Fault injection experiments** section shows a list of the fault injection experiments. For more information about fault injection experiments, see [Managing AWS Fault Injection Service experiments](testing.md). # Editing AWS Resilience Hub application resources Editing application resources To receive accurate and helpful resiliency assessments, ensure that your application description is updated and matches your actual AWS application and resources. Assessment reports, validation, and recommendations are based on the listed resources. If you add or remove resources from an AWS application, you should reflect those changes in AWS Resilience Hub. AWS Resilience Hub provides transparency about your application sources. You can identify and edit the resources and the application sources in your application. **Note** Editing the resources modifies only the AWS Resilience Hub reference of your application. No changes are made to your actual resources. You can add resources that are missing, modify existing resources, or remove resources that you don’t need. Resources are grouped into logical Application Components (AppComponents). You can edit the AppComponents to better reflect the structure of your application. Add to or update your application resources by editing a draft version of your application and publishing the changes to a new (release) version. AWS Resilience Hub uses the release version (which includes the updated resources) of your application for running resiliency assessments. **To assess the resiliency of your application** 1. In the navigation pane, choose **Applications**. 1. On the **Applications** page, choose the application name that you want to edit. 1. From **Actions** menu, choose **Assess resiliency**. 1. In the **Run resiliency assessment** dialog, enter a unique name for the report or use the generated name in the **Report name** box. 1. Choose **Run**. 1. After you are notified that the assessment report has been generated, choose the **Assessments** tab and your assessment to view the report. 1. Choose the **Review** tab to view your application's assessment report. **To enable scheduled assessment** 1. In the navigation pane, choose **Applications**. 1. On the **Applications** page, select the application for which you want to enable scheduled assessment. 1. Turn on **Automatically assess daily**. **To disable scheduled assessment** 1. In the navigation pane, choose **Applications**. 1. On the **Applications** page, select the application for which you want to enable scheduled assessment. 1. Turn off **Automatically assess daily**. **Note** Disabling scheduled assessment will disable drift notification. 1. Choose **Turn off**. **To enable drift notification for your application** 1. In the navigation pane, choose **Applications**. 1. On the **Applications** page, select the application for which you want to enable drift notification or edit the drift notification settings. 1. You can edit drift notification by choosing one of the following options: + From **Actions**, choose **Enable drift notification**. + Choose **Enable notification** in **Application drifts** section. 1. Complete the steps in [Setup scheduled assessments and drift notification](scheduled-assessment.md), and then return to this procedure. 1. Choose **Enable**. Enabling drift notification will also enable scheduled assessment. **To edit drift notification for your application** **Note** This procedure is applicable if you have enabled scheduled assessment (**Automatically assess daily** is turned on) and drift notification. 1. In the navigation pane, choose **Applications**. 1. On the **Applications** page, select the application for which you want to enable drift notification or edit the drift notification settings. 1. You can edit drift notification by choosing one of the following options: + From **Actions**, choose **Edit drift notification**. + Choose **Edit notification** in **Application drifts** section. 1. Complete the steps in [Setup scheduled assessments and drift notification](scheduled-assessment.md), and then return to this procedure. 1. Choose **Save**. **To update the security permissions of your application** 1. In the navigation pane, choose **Applications**. 1. On the **Applications** page, select the application for which you want to update the security permissions. 1. From **Actions**, choose **Update permissions**. 1. To update the security permissions, complete the steps in [Setup permissions](setup-permissions.md), and then return to this procedure. 1. Choose **Save and update**. **To attach a resiliency policy to your application** 1. In the navigation pane, choose **Applications**. 1. On the **Applications** page, choose the application name that you want to edit. 1. From **Actions** menu, choose **Attach resiliency policy**. 1. In the **Attach policy** dialog, select a resiliency policy from **Select a resiliency policy** dropdown list. 1. Choose **Attach**. **To edit input sources, resources, and AppComponents of your application** 1. In the navigation pane, choose **Applications**. 1. On the **Applications** page, choose the application name that you want to edit. 1. Choose the **Application structure** tab. 1. Choose the plus sign **\$1** before **Version**, and then select the application version with **Draft** status. 1. To edit input sources, resources, and AppComponents of your application, complete the steps in the following procedures. **To edit the input sources of your application** 1. To edit the input sources of your application, choose the **Input sources** tab. The **Input sources** section lists all the input sources of your application resources. You can identify the input sources by the following: + **Source name** – The name of the input source. Choose a source name to view its details in the respective application. For manually added input sources, the link will not be available. For example, if you choose the source name that is imported from an AWS CloudFormation stack, you will be redirected to the stack details page on the AWS CloudFormation console. + **Source ARN** – The Amazon Resource Name (ARN) of the input source. Choose an ARN to view its details in the respective application. For manually added input sources, the link will not be available. For example, if you choose an ARN that is imported from an AWS CloudFormation stack, you will be redirected to the stack details page on the AWS CloudFormation console. + **Source Type** – The type of input source. Input sources include Amazon EKS clusters, AWS CloudFormation stacks, myApplications applications, AWS Resource Groups, Terraform state files, and manually added resources. + **Associated resources** – The number of resources that are associated with the input source. Choose a number to view all the associated resources of an input source in the **Resources** tab. 1. To add input sources to your application, from the **Input sources** section, choose **Add input sources**. For more information about adding input sources, see [Add resource collections](discover-structure.md). 1. To edit input sources, select the input sources and choose one the following options from **Actions**: + **Reimport input sources (up to 5)** – Reimports up to five selected input sources. + **Delete input sources** – Deletes the selected input sources. To publish an application, it must contain a minimum of one input source. If you delete all the input sources, **Publish new version** will be disabled. **To edit the resources of your application** 1. To edit the resources of your application, choose the **Resources** tab. **Note** To see the list of unassessed resources, choose **View unassessed resources**. The **Resources** section lists resources from the application that you chose to use as a template for your application description. To enhance your search experience, AWS Resilience Hub has grouped resources based on multiple search criteria. These search criteria include AppComponent types, **Unsupported** resources, and **Excluded** resources. To filter the resources based on a search criteria in the **Resources** table, choose the number below each of the search criteria. You can identify the resources by the following: + **Logical ID** – A logical ID is a name used to identify resources in your AWS CloudFormation stack, Terraform state file, manually added application, myApplications application, or AWS Resource Groups. **Note** Terraform lets you use the same name for different resource types. Therefore, you see "*- resource type*" at the end of the logical ID for resources that share the same name. To view the instances of all the application resources, choose the plus (**\$1**) sign before the **Logical ID**. To view all the instances of an application resource, choose the plus (**\$1**) sign before the Logical ID of each resource. For more information about the supported resources, see [AWS Resilience Hub supported resources](supported-resources.md). + **Resource type** – The resource type identifies the component resource for your application. For example, `AWS::EC2::Instance` declares an Amazon EC2 instance. For more information about grouping AppComponent resources, see [Grouping resources in an Application Component](AppComponent.grouping.md). + **Source name** – The name of the input source. Choose a source name to view its details in the respective application. For manually added input sources, the link will not be available. For example, if you choose the source name that is imported from an AWS CloudFormation stack, you will be redirected to the stack details page on the AWS CloudFormation. + **Source Type** – The type of input source. Input sources include AWS CloudFormation stacks, myApplications applications, AWS Resource Groups, Terraform state files, and manually added resources. **Note** To edit your Amazon EKS clusters, complete the steps in **To edit the input sources of your AWS Resilience Hub application** procedure. + **Source stack** – The AWS CloudFormation stack that contains the resource. This column depends on the type of application structure that you selected. + **Physical ID** – The actual assigned identifier for that resource, such as an Amazon EC2 instance ID or an S3 bucket name. + **Included** – This indicates whether AWS Resilience Hub includes these resources in the application. + **Assessable** – This indicates whether the AWS Resilience Hub will assess your resource for resiliency. + **AppComponents** – The AWS Resilience Hub component that was assigned to this resource when its application structure was discovered. + **Name** – Name of the application resource. + **Account** – The AWS account that owns the physical resource. 1. To find a resource that is not listed, enter the resource logical ID in the search box. 1. To remove a resource from your application, select the resource, and then choose **Exclude resource** from **Actions**. 1. To resolve the resources on your application, choose **Refresh resources**. 1. To modify your existing application resources, complete the following steps: 1. Select a resource, and then choose **Update stacks** from **Actions**. 1. In the **Update stacks** page, to update your resources, complete the appropriate procedures in [Add resource collections](discover-structure.md), and then return to this procedure. 1. Choose **Save**. 1. To add a resource to your application, from **Actions**, choose **Add resource** and complete the following steps: 1. Select a resource type from the **Resource type** dropdown list. 1. Select an AppComponent from the **AppComponent** dropdown list. 1. Enter the resource logical ID in the **Resource name** box. 1. Enter the physical resource ID, or resource name, or the resource ARN in the **Resource identifier** box. 1. Choose **Add**. 1. To edit the resource name, select a resource, choose **Edit resource name** from **Actions**, and then complete the following steps: 1. Enter the resource logical ID in the **Resource name** box. 1. Choose **Save**. 1. To edit the resource identifier, select a resource, choose **Edit resource identifier** from **Actions**, and then complete the following steps: 1. Enter the physical resource ID, or resource name, or the resource ARN in the **Resource identifier** box. 1. Choose **Save**. 1. To change the AppComponent, select a resource, choose **Change AppComponent** from **Actions**, and complete the following steps: 1. Select an AppComponent from the **AppComponent** dropdown list. 1. Choose **Add**. 1. To delete a resource, select a resource, and then choose **Delete resource** from **Actions**. 1. To include a resource, select a resource, and then choose **Include resource** from **Actions**. **To edit the AppComponents of your application** 1. To edit the AppComponents of your application, choose the **AppComponents** tab. **Note** For more information about grouping AppComponent resources, see [Grouping resources in an Application Component](AppComponent.grouping.md). The **AppComponents** section lists all the logical components that the resources are grouped into. You can identify the AppComponents by the following: + **AppComponent name** – The name of the AWS Resilience Hub component that was assigned to this resource when its application structure was discovered. + **AppComponent type** – The type of AWS Resilience Hub component. + **Source name** – The name of the input source. Choose a source name to view its details in the respective application. For example, if you choose the source name that is imported from an AWS CloudFormation stack, you will be redirected to the stack details page on the AWS CloudFormation. + **Resource count** – The number of resources that are associated with the input source. Choose a number to view all the associated resources of an input source in the **Resources** tab. 1. To create an AppComponent, from **Actions** menu, choose **Create new AppComponent** and complete the following steps: 1. Enter a name for the AppComponent in the **AppComponent name** box. For reference, we have pre-populated this field with a sample name. 1. Select the type of AppComponent from the **AppComponent type** dropdown list. 1. Choose **Save**. 1. To edit an AppComponent, select an AppComponent, and then choose **Edit AppComponent** from **Actions**. 1. To delete an AppComponent, select an AppComponent, and then choose **Delete AppComponent** from **Actions**. After you make changes to your resource list, you will receive an alert indicating that changes have been made to the draft version of your application. To run an accurate resiliency assessment, you must publish a new version of your application. For more information about how to publish a new version, see [Publishing a new AWS Resilience Hub application version](applications-publish.md). # Managing Application Components An Application Component (AppComponent) is a group of related AWS resources that work and fail as a single unit. For example, if you have a primary and replica database, both the databases belong to the same AppComponent. AWS Resilience Hub has rules that govern which AWS resources can belong to which AppComponent type. For example, a `DBInstance` can belong to `AWS::ResilienceHub::DatabaseAppComponent` and not to `AWS::ResilienceHub::ComputeAppComponent`. The AWS Resilience Hub AppComponents support the following resources: + `AWS::ResilienceHub::ComputeAppComponent` + `AWS::ApiGateway::RestApi` + `AWS::ApiGatewayV2::Api` + `AWS::AutoScaling::AutoScalingGroup` + `AWS::EC2::Instance` + `AWS::ECS::Service` + `AWS::EKS::Deployment` + `AWS::EKS::ReplicaSet` + `AWS::EKS::Pod` + `AWS::Lambda::Function` + `AWS::StepFunctions::StateMachine` + `AWS::ResilienceHub::DatabaseAppComponent` + `AWS::DocDB::DBCluster` + `AWS::DynamoDB::Table` + `AWS::ElastiCache::CacheCluster` + `AWS::ElastiCache::GlobalReplicationGroup` + `AWS::ElastiCache::ReplicationGroup` + `AWS::ElastiCache::ServerlessCache` + `AWS::RDS::DBCluster` + `AWS::RDS::DBInstance` + `AWS::ResilienceHub::NetworkingAppComponent` + `AWS::EC2::NatGateway` + `AWS::ElasticLoadBalancing::LoadBalancer` + `AWS::ElasticLoadBalancingV2::LoadBalancer` + `AWS::Route53::RecordSet` + `AWS:ResilienceHub::NotificationAppComponent` + `AWS::SNS::Topic` + `AWS::ResilienceHub::QueueAppComponent` + `AWS::SQS::Queue` + `AWS::ResilienceHub::StorageAppComponent` + `AWS::Backup::BackupPlan` + `AWS::EC2::Volume` + `AWS::EFS::FileSystem` + `AWS::FSx::FileSystem` **Note** Currently, AWS Resilience Hub supports Amazon FSx for Windows File Server only. + `AWS::S3::Bucket` **Topics** + [ # Grouping resources in an Application Component ](AppComponent.grouping.md) # Grouping resources in an Application Component When the application is imported into AWS Resilience Hub along with its resources, AWS Resilience Hub makes its best effort to group related resources into the same AppComponent when you import your application, but the grouping might not always be 100 percent accurate. Some resources are blocked for manual grouping and will be grouped automatically when applicable because these services have strict dependencies that require specific grouping configurations. For a complete list of services that are blocked for manual grouping, see [Blocked services for manual grouping](blocked-services-for-manual-grouping.md). AWS Resilience Hub performs the following activities after your application and its resources are successfully imported: + Scans your resources to check if they can be re-grouped into new AppComponents to improve the assessment accuracy. + If AWS Resilience Hub identifies resources that can be re-grouped into new AppComponents, it displays the same as recommendations and allows you to either accept or reject the same. In AWS Resilience Hub, the confidence level assigned to a grouping recommendation indicates the degree of certainty with which the resources should be grouped together based on their attributes and metadata. A **High** confidence level indicates that AWS Resilience Hub has a confidence level of 90% or above that the resources in that group are related and should be grouped together. A **Medium** confidence level indicates that AWS Resilience Hub has a confidence level between 70% and 90% that the resources in that group are related and should be grouped together. **Note** AWS Resilience Hub requires the correct grouping so that it can compute estimated workload RTO and estimated workload RPO to generate recommendations. The following are examples of correct groupings: + Group primary databases and replicas under a single AppComponent. + Group Amazon EC2 instances that run the same application under a single AppComponent. + Group Amazon ECS services in one Region and failover Amazon ECS services in another Region under a single AppComponent. For more information about reviewing and including resource grouping recommendations by AWS Resilience Hub, see the following topics: + [AWS Resilience Hub resource grouping recommendations](grouping-recommendation.md) + [Manually grouping resources into an AppComponent](AppComponent-manual-grouping.md) # Blocked services for manual grouping AWS Resilience Hub blocks you from manually grouping resources of certain AWS services to prevent configuration errors that could affect the resilience assessment and recommendations for your application. These services are automatically grouped based on their dependencies and configurations. When you define an application inclusive of these resources on AWS Resilience Hub, it analyzes their relationships, dependencies, and resilience requirements to create optimal groupings that ensure accurate assessment results. List of AWS services blocked for manual grouping: + Amazon API Gateway + Amazon DocumentDB + Amazon DynamoDB + Amazon Elastic Block Store + Amazon Elastic File System + Amazon Relational Database Service + Amazon S3 + Amazon Simple Queue Service + FSx for Windows File Server + NAT Gateway # AWS Resilience Hub resource grouping recommendations This section explains how to generate and review resource grouping recommendations in AWS Resilience Hub. **Note** You can grant the necessary IAM permissions that are required to work with AWS Resilience Hub by using `AWSResilienceHubAsssessmentExecutionPolicy` AWS managed policy. For more information about AWS managed policy, see [AWSResilienceHubAsssessmentExecutionPolicy](security-iam-awsmanpol.md#security_iam_aws-assessment-policy). **To view resource grouping recommendations** 1. In the navigation pane, choose **Applications**. 1. Choose **Add application** page, choose the application name for which you want to review resource grouping recommendations. 1. Choose the **Application structure** tab. 1. If AWS Resilience Hub displays an information alert, choose **Review recommendations** to view all the resource grouping recommendations. Else complete the following steps to manually generate resource grouping recommendations: 1. Choose **Resources**. 1. Choose **Get grouping recommendations** from **Actions** menu. AWS Resilience Hub scans your resources to check how they can be grouped in the best possible way into relevant AppComponents to improve the accuracy of the assessments. If AWS Resilience Hub learns that your resources can be grouped together, it displays an information alert for the same. 1. If the information alert is displayed, choose **Review recommendations** to view all the resource grouping recommendations. You can identify the AppComponents in the **Review resource grouping recommendations** section using the following: + **AppComponent name** – Name of the AppComponent in which the resources will be grouped. + **Confidence level** – Indicates the confidence level of AWS Resilience Hub in the grouping recommendation. + **Resource count** – Indicates the number of resources that will be grouped in the AppComponent. + **AppComponent type** – Indicates the type of AppComponent. **To view resources that will be grouped in AppComponents** 1. Complete the steps in **[To view resource grouping recommendations](#view-resource-grouping)** procedure and then return to this procedure. 1. In **Review resource grouping recommendations** section, select the check box (adjacent to the **AppComponent name**) to view all the resources that will be grouped together within the selected AppComponent. If you select multiple check boxes, AWS Resilience Hub displays a dynamically generated **recommendations selected** section that groups the selected AppComponents under their respective AppComponent type. Choose the number below each AppComponent type to view all the resources that will be grouped together within the selected AppComponent. You can identify the resources that will be grouped in the selected AppComponent in the **Resources** section using the following: + **Logical ID** – Indicates the logical ID of the resource. A logical ID is a name used to identify resources in your AWS CloudFormation stack, Terraform state file, myApplications application, or AWS Resource Groups. + **Physical ID** – The actual assigned identifier for the resource, such as an Amazon EC2 instance ID or an Amazon S3 bucket name. + **Type** – Indicates the type of resource. + **Region** – AWS Region in which the resource is located. **To accept resource grouping recommendations** 1. Complete the steps in **[To view resource grouping recommendations](#view-resource-grouping)** procedure and then return to this procedure. 1. In the **Review resource grouping recommendations** section, select all the check boxes adjacent to the **AppComponent name**. To find a specific AppComponent, enter the AppComponent name in the **Find AppComponents** box. **Note** By default, AWS Resilience Hub displays all the resource grouping recommendations. To filter the table with previously rejected resource grouping recommendations, choose **Previously rejected** from the dropdown menu adjacent to the **Find AppComponents** box. 1. Choose **Accept**. 1. Choose **Accept** in the **Accept resource grouping recommendation** dialog. AWS Resilience Hub displays an information alert if the resource grouping is successful. If you have accepted only a subset of resource grouping recommendations, **Review resource grouping recommendations** section displays all the resource grouping recommendations that you have not accepted. **To reject resource grouping recommendations** 1. Complete the steps in **[To view resource grouping recommendations](#view-resource-grouping)** procedure and then return to this procedure. 1. In **Review resource grouping recommendations** section, select all the check boxes adjacent to the **AppComponent name**. To find a specific AppComponent, enter the AppComponent name in the **Find AppComponents** box. **Note** By default, AWS Resilience Hub displays all the resource grouping recommendations. To filter the table with previously rejected resource grouping recommendations, select **Previously rejected** from the dropdown menu adjacent to the **Find AppComponents** box. 1. Choose **Reject**. 1. Select one of the reasons for rejecting the resource grouping recommendation and then choose **Reject** in the **Reject resource grouping recommendation** dialog. AWS Resilience Hub displays an information alert confirming the same. If you have rejected only a subset of resource grouping recommendations, **Review resource grouping recommendations** section displays all the resource grouping recommendations that you have not accepted. # Manually grouping resources into an AppComponent This section explains how to manually group resources into an AppComponent and assigning different AppComponent to a resource in AWS Resilience Hub. **To group resources** 1. In the navigation pane, choose **Applications**. 1. On the **Applications** page, choose the application name that contains the resources that you want to group. 1. Choose the **Application structure** tab. 1. Under **Version** tab, select the application version with **Draft** status. 1. Choose the **Resources** tab. 1. Select the check boxes that is adjacent to **Logical ID** to select all the resources you want to group. **Note** You cannot choose manually added resources. 1. Choose **Actions**, and then choose **Group resources**. 1. Choose an AppComponent from the **Choose AppComponent** dropdown list in which you want to group the resource. 1. Choose **Save**. 1. Choose **Publish new version**. 1. Choose the **Application structure** tab. 1. To view the published version of your application, complete the following steps: 1. Under **Version** tab, select the application version with **Current release** status. 1. Choose the **Resources** tab. **To assign resources to an AppComponent** 1. In the navigation pane, choose **Applications**. 1. On the **Applications** page, choose the application name that contains the resource you want to regroup. 1. Choose the **Application structure** tab. 1. Under **Version**, select the application version with **Draft** status. 1. Choose the **Resources** tab. 1. Select the check box that is adjacent to **Logical ID** to select the resource. 1. Choose **Change AppComponent** from **Actions** menu. 1. To delete the current AppComponent from the **AppComponent** section, choose **X** in the upper-right corner of the label that displays your current AppComponent name. 1. To group the resource in a different AppComponent, choose a different AppComponent from the **Choose AppComponent** dropdown list. 1. Choose **Add**. 1. Delete any empty AppComponents from the **AppComponents** tab. 1. Choose **Publish new version**. 1. Choose the **Application structure** tab. 1. To view the published version of your application, complete the following steps: 1. Under **Version** tab, select the application version with **Current release** status. 1. Choose the **Resources** tab. # Publishing a new AWS Resilience Hub application version Publish a new application version After you make changes to your AWS Resilience Hub application resources as described in [Editing AWS Resilience Hub application resources](application-resources.md), you must publish a new version of your application to run an accurate resiliency assessment. Also, you might need to publish a new version of your application if you added new recommended alarms, SOPs, and tests to your application. **To publish a new version of your application** 1. In the navigation pane, choose **Applications**. 1. On the **Applications** page, choose the name of the application. 1. Choose the **Application structure** tab. 1. Choose **Publish new version**. 1. In **Publish version** dialog, in the **Name** box, enter a name for the application version or you can use the default name suggested by AWS Resilience Hub. 1. Choose **Publish**. When you publish a new version of your application, this becomes the version that is assessed when you run resiliency assessments. Also, the draft version will be identical to the released version until you make any changes. After you publish a new version of your application, we recommend you to run a new resiliency assessment report to confirm your application still meets your resiliency policy. For information about running an assessment, see [Running and managing resiliency assessments in AWS Resilience Hub](resil-assessments.md). # Viewing all the AWS Resilience Hub application versions Viewing application versions To help track the application changes, AWS Resilience Hub displays the previous versions of your application from the time it was created on AWS Resilience Hub. **To view all the versions of your application** 1. In the navigation pane, choose **Applications**. 1. On the **Applications** page, choose the name of the application. 1. Choose the **Application structure** tab. 1. To view all the previous versions of your application, choose the plus sign (**\$1**) before **View all versions**. AWS Resilience Hub indicates the draft version and recently released version of your application using **Draft** and **Current release** statuses, respectively. You can choose any version of your application to views its resources, AppComponent, input sources and other associated information. In addition, you can also filter the list by using one of the following options: + **Filter by version name** – Enter a name to filter the results by the name of your application version. + **Filter by a date and time range** – To apply this filter, choose the calendar icon and select one of the following options to filter by the results that matches the time range: + **Relative range** – Select one of the available options and choose **Apply**. If you choose **Custom range** option, enter a duration in **Enter duration** box and select the appropriate unit of time from **Unit of time** dropdown list, then choose **Apply**. + **Relative range** – To specify the date and time range, provide the start time and end time, and then choose **Apply**. # Viewing resources of AWS Resilience Hub application Viewing resources of your application **To view resources of your application** 1. In the navigation pane, choose **Applications**. 1. On the **Applications** page, select the application for which you want to update the security permissions. 1. From **Actions**, choose **View resources**. In **Resources** tab, you can identify resources in the **Resources** table by the following: + **Logical ID** – A logical ID is a name used to identify resources in your AWS CloudFormation stack, Terraform state file, myApplications application, or AWS Resource Groups. **Note** Terraform lets you use the same name for different resource types. Therefore, you see "*- resource type*" at the end of the logical ID for resources that share the same name. To view the instances of all the application resources, choose the plus (**\$1**) sign before the **Logical ID**. To view all the instances of an application resource, choose the plus (**\$1**) sign before the Logical ID of each resource. For more information about the supported resources, see [AWS Resilience Hub supported resources](supported-resources.md). + **Status** – This indicates whether the AWS Resilience Hub will assess your resource for resiliency. + **Resource type** – The resource type identifies the component resource for your application. For example, `AWS::EC2::Instance` declares an Amazon EC2 instance. For more information about grouping AppComponent resources, see [Grouping resources in an Application Component](AppComponent.grouping.md). + **Source name** – The name of the input source. Choose a source name to view its details in the respective application. For manually added input sources, the link will not be available. For example, if you choose the source name that is imported from an AWS CloudFormation stack, you will be redirected to the stack details page on the AWS CloudFormation. + **Source type** – The type of the input source. + **AppComponent type** – The type of input source. Input sources include AWS CloudFormation stacks, myApplications applications, AWS Resource Groups, Terraform state files, and manually added resources. **Note** To edit your Amazon EKS clusters, complete the steps in **To edit the input sources of your AWS Resilience Hub application** procedure. + **Physical ID** – The actual assigned identifier for that resource, such as an Amazon EC2 instance ID or an S3 bucket name. + **Included** – This indicates whether AWS Resilience Hub includes these resources in the application. + **AppComponents** – The AWS Resilience Hub component that was assigned to this resource when its application structure was discovered. + **Name** – Name of the application resource. + **Account** – The AWS account that owns the physical resource. 1. Choose **Save and update**. # Deleting an AWS Resilience Hub application Deleting an application After you've reached the maximum limit of 50 applications, you must delete one or more applications before you can add more. **To delete an application** 1. In the navigation pane, choose **Applications**. 1. On the **Applications** page, select the application that you want to delete. 1. Choose **Actions**, and then choose **Delete application**. 1. To confirm the deletion, enter **Delete** in the **Delete** box, and choose **Delete**. # Application configuration parameters AWS Resilience Hub provides an input mechanism to gather additional information about the resources associated with your applications. With this information, AWS Resilience Hub will gain a deeper understanding of your resources and provide better resiliency recommendations. The **Application configuration parameters** section lists all the configuration parameters of your cross-Region failover support for AWS Elastic Disaster Recovery. You can identify the configuration parameters by the following: + **Topic** – Indicates the area of your application that is configured. For example, failover configuration. + **Purpose** – Indicates the reason why AWS Resilience Hub requested the information. + **Parameter** – Indicates the details that are specific to the area of application, which AWS Resilience Hub will be using to provide recommendations for your application. Currently, this parameter uses a key-value of only one failover Region and one associated account. # Updating application configuration parameters This section allows you to update the configuration parameters of your AWS Elastic Disaster Recovery and publish the application to include the updated parameters for resiliency assessments. **To update application configuration parameters** 1. In the navigation pane, choose **Applications**. 1. On the **Applications** page, choose the application name that you want to edit. 1. Choose the **Application configuration parameters** tab. 1. Choose **Update**. 1. Enter the failover account ID in the **Account ID** box. 1. Select a failover Region from the **Region** dropdown list. **Note** If you want to disable this feature, select "**–**" from the dropdown list. 1. Choose **Update and publish**. # Managing resiliency policies This section describes how to create resiliency policies for your applications. Setting resiliency policies correctly enables you to understand your application's resiliency posture. A resiliency policy contains information and objectives that you use to assess whether your application is estimated to recover from a disruption type, such as software, hardware, Availability Zone, or AWS Region. These policies do not change or affect an actual application. Multiple applications can have the same resiliency policy. When you create a resiliency policy, you define the target objectives: recovery time objective (RTO) and recovery point objective (RPO). The objectives determine whether the application meets the resiliency policy. Attach the policy to your application and run a resiliency assessment. You can create different policies for the different types of applications in your portfolio. For example, a real-time trading application would have a different resiliency policy than a monthly reporting application. **Note** AWS Resilience Hub allows you to enter a value zero in the **RTO** and **RPO** fields of your resiliency policy. But, while assessing your application, the lowest possible assessment result is near zero. Hence, if you enter a value zero in the **RTO** and **RPO** fields, the estimated workload RTO and estimated workload RPO result will be near zero and the **Compliance status** for your application will be set to **Policy breached**. The assessment evaluates your application configuration against the attached resiliency policy. At the end of the process, AWS Resilience Hub provides an assessment of how your application measures against the recovery targets in your resiliency policy. You can create resiliency policies in Applications, and also in Resiliency policies. You can access relevant details about your policies, and also modify and delete them. AWS Resilience Hub uses your RTO and RPO targets to measure resiliency for these potential types of disruptions: + **Application** – Loss of a required software service or process. + **Cloud infrastructure** – Loss of hardware, such as EC2 instances. + **Cloud infrastructure Availability Zone (AZ)** – One or more Availability Zones are unavailable. + **Cloud infrastructure Region** – One or more Regions are unavailable. AWS Resilience Hub enables you to create customized resiliency policies or use our recommended, open standard resiliency policies. When you create customized policies, name and describe your policy and choose the appropriate level or tier that defines your policy. These tiers include: Foundational IT core services, Mission critical, Critical, Important, and Non-critical. Choose the tier that is appropriate for your class of application. For example, you might classify a real-time trading system as critical, while you might classify a monthly reporting application as non-critical. When you use our standard policies, you can choose a resiliency policy with a preconfigured tier and values for the RTO and RPO targets by disruption type. If necessary, you can change the tier and the RTO and RPO targets. You can create resiliency policies in Resiliency policies, or when you describe a new application. # Creating resiliency policies In AWS Resilience Hub, you can create a resiliency policy. A resiliency policy contains information and objectives that you use to assess whether your application can recover from a disruption type, such as software, hardware, Availability Zone, or AWS Region. These policies do not change or affect an actual application. Multiple applications can have the same resiliency policy. When you create a resiliency policy, you define the recovery time objective (RTO) and recovery point objective (RPO) targets. When you run an assessment, AWS Resilience Hub determines whether the application is estimated to meet the objectives that are defined in the resiliency policy. The assessment evaluates your application configuration against the attached resiliency policy. At the end of the process, AWS Resilience Hub provides an assessment of how your application measures against the objectives in your resiliency policy. **Note** AWS Resilience Hub allows you to enter a value zero in the **RTO** and **RPO** fields of your resiliency policy. But, while assessing your application, the lowest possible assessment result is near zero. Hence, if you enter a value zero in the **RTO** and **RPO** fields, the estimated workload RTO and estimated workload RPO result will be near zero and the **Compliance status** for your application will be set to **Policy breached**. You can create resiliency policies in Applications, and also in Resiliency policies. You can access relevant details about your policies, and also modify and delete them. **To create resiliency policies in Applications** 1. In the left navigation menu, choose **Applications**. 1. Complete the procedures from [Get started by adding an application](describe-app-intro.md) through [Add tags](add-tags.md). 1. In **Resiliency policies** section, choose **Create resiliency policy**. The **Create resiliency policy** page displays. 1. In the **Choose a creation method** section, select **Create a policy**. 1. Enter a name for the policy. 1. (Optional) Enter a description for the policy. 1. Choose one of the following from **Tier** dropdown list: + **Foundational IT core services** + **Mission critical** + **Critical** + **Important** + **Non critical** 1. For both **RTO** and **RPO** targets, under **Customer Application RTO and RPO**, enter a numeric value in the box, and then choose the unit of time that the value represents. Repeat these entries under **Infrastructure RTO and RPO** for **Infrastructure** and **Availability Zone**. 1. (Optional) If you have a multi-Region application, you may want to define a Region's RTO and RPO targets. Turn-on **Region**. For both Region **RTO** and **RPO** targets, under **Customer Application RTO and RPO**, enter a numeric value in the box, and then choose the unit of time that the value represents. 1. (Optional) If you want to add tags, you can do that later as you continue creating your policy. For more information about tags, see [Tagging resources](https://docs.aws.amazon.com//general/latest/gr/aws_tagging.html) in the *AWS General Reference*. 1. To create the policy, choose **Create**. **To create resiliency policies in Resiliency policies** 1. In the left navigation menu, choose **Policies**. 1. In **Resiliency policies** section, choose **Create resiliency policy**. The **Create resiliency policy** page displays. 1. Enter a name for the policy. 1. (Optional) Enter a description for the policy. 1. Choose one of the following from **Tier**: + **Foundational IT core services** + **Mission critical** + **Critical** + **Important** + **Non critical** 1. For both **RTO** and **RPO** targets, under **Customer Application RTO and RPO**, enter a numeric value in the box and then choose the unit of time that the value represents. Repeat these entries under **Infrastructure RTO and RPO** for **Infrastructure** and **Availability Zone**. 1. (Optional) If you have a multi-Region application, you may want to define a Region's RTO and RPO targets. Turn-on **Region**. For both **RTO** and **RPO** targets, under **Customer Application RTO and RPO**, enter a numeric value in the box and then choose the unit of time that the value represents. 1. (Optional) If you want to add tags, you can do that later as you continue creating your policy. For more information about tags, see [Tagging resources](https://docs.aws.amazon.com//general/latest/gr/aws_tagging.html) in the *AWS General Reference*. 1. To create the policy, choose **Create**. **To create resiliency policies based on a suggested policy** 1. In the left navigation menu, choose **Policies**. 1. In the **Choose a creation method** section, select **Select a policy based on a suggested policy**. 1. In **Resiliency policies** section, choose **Create resiliency policy**. The **Create resiliency policy** page displays. 1. Enter a name for the resiliency policy. 1. (Optional) Enter a description for the policy. 1. Under **Suggested resiliency policies** section, view and choose one of the following predetermined resiliency policy tiers: + **Non-critical application** + **Important Application** + **Critical Application** + **Global Critical Application** + **Mission Critical Application** + **Global Mission Critical Application** + **Foundational Core Service** 1. To create the resiliency policy, choose **Create policy**. ## Accessing resiliency policy details When you open a resiliency policy, you see important details about the policy. You can also edit or delete the resiliency. Resiliency policy details consist of two major views: **Summary** and **Tags**. **Summary** *Basic information* Provides the following information about resiliency policy: Name, Description, Tier, Cost Tier, and Date Created. *Estimated workload RTO and estimated workload RPO* Shows the estimated workload RTO and estimated workload RPO disruption type associated with this resiliency policy. **Tags** Use this view to manage, add, and delete tags internal to this application. **To edit resiliency policies in Resiliency policy details** 1. In the left navigation menu, choose **Policies**. 1. In **Resiliency policies**, open a resiliency policy. 1. Choose **Edit**. Enter appropriate changes in **Basic Info**, and **RTO** and **RPO** fields. Then choose **Save changes**. **To edit resiliency policies in Resiliency policy** 1. In the left navigation menu, choose **Policies**. 1. In **Resiliency policies**, choose a resiliency policy. 1. Choose **Actions**, and then select **Edit**. 1. Enter appropriate changes in **Basic Info**, and **RTO** and **RPO** fields. Then choose **Save changes**. **To delete resiliency policies in Resiliency policy details** 1. In the left navigation menu, choose **Policies**. 1. In **Resiliency policies**, open a resiliency policy. 1. Choose **Delete**. Confirm your deletion, and then choose **Delete**. **To delete resiliency policies in Resiliency policy** 1. In the left navigation menu, choose **Policies**. 1. In **Resiliency policies**, choose a resiliency policy. 1. Choose **Actions**, and then select **Delete**. 1. Confirm your deletion, and then choose **Delete**. # Running and managing resiliency assessments in AWS Resilience Hub Managing resiliency assessments in AWS Resilience Hub When your application changes, you should run a resiliency assessment. The assessment compares each Application Component configuration to the policy and makes alarm, SOP, and test recommendations. These configuration recommendations can improve the speed of recovery procedures. Alarm recommendations help you set alarms that detect outages. SOP recommendations provide scripts that manage common recovery processes, such as recovery from a backup. Test recommendations offer suggestions to verify your configurations work properly. For example, you can test whether an application recovers during automatic recovery processes, such as automatic scaling or load balancing because of network issues. You can test whether application alarms are triggered when resources reach their limits. You can also test how well SOPs work under the conditions that you indicate. **Topics** + [ # Running resiliency assessments in AWS Resilience Hub ](run-assessment.md) + [ # Reviewing assessments reports ](review-assessment.md) + [ # Deleting resiliency assessments ](delete-assessment.md) # Running resiliency assessments in AWS Resilience Hub You can run resiliency assessments from multiple locations in AWS Resilience Hub. For more information about your application, see [Describing and managing AWS Resilience Hub Applications](applications.md). **To run a resiliency assessment from the Actions menu** 1. In the left navigation menu, choose **Applications**. 1. Choose an application from the **Applications** table. 1. Choose the **Assess resiliency** from the **Actions** menu. 1. In **Run resiliency assessment** dialog, you can enter a unique name or use the generated name for the assessment. 1. Choose **Run**. To review the assessment report, choose **Assessments** in your application. For more information, see [Reviewing assessments reports](review-assessment.md). **To run a resiliency assessment from the Assessments tab** You can run a new resiliency assessment when your application or resiliency policy changes. 1. In the left navigation menu, choose **Applications**. 1. Choose an application from the **Applications** table. 1. Choose the **Assessments** tab. 1. Choose **Run resiliency assessment**. 1. In **Run resiliency assessment** dialog, you can enter a unique name or use the generated name for the assessment. 1. Choose **Run**. To review the assessment report, choose **Assessments** in your application. For more information, see [Reviewing assessments reports](review-assessment.md). # Reviewing assessments reports You find assessment reports in the **Assessments** view of your application. **To find an assessment report** 1. In the left navigation menu, choose **Applications**. 1. In **Applications**, open an application. 1. In **Assessments** tab, choose an assessment report from the **Resiliency assessments** section. When you open the report, you see the following: + An overall overview of the assessment report + Recommendations to improve resiliency. + Recommendations to set up alarms, SOPs, and tests + How to create and manage tags to search and filter your AWS resources ## Assessment report This section provides an overview of the assessment report. AWS Resilience Hub lists each disruption type and the associated Application Component. It also lists your actual RTO and RPO policies and determines whether the Application Component can achieve the policy goals. **Overview** Shows the name of the application, the name of the resiliency policy, and the creation date of the report. **Detected resource drifts** This section lists all the resources that were added or removed after they were included in the latest version of the published application. Choose **Reimport input sources** to reimport all the input sources (which contains drifted resources) in the **Input sources** tab. Choose **Publish and assess** to include the updated resources in the application and receive an accurate resiliency assessment. You can identify the drifted input sources using the following: + **Logical ID** – Indicates the logical ID of the resource. A logical ID is a name used to identify resources in your AWS CloudFormation stack, Terraform state file, myApplications application, or AWS Resource Groups. + **Change** – Indicates if an input resource was **Added** or **Removed**. + **Source name** – Indicates the resource name. Choose a source name to view its details in the respective application. For manually added input sources, the link will not be available. For example, if you choose the source name that is imported from an AWS CloudFormation stack, you will be redirected to the stack details page on the AWS CloudFormation. + **Resource type** – Indicates the resource type. + **Account** – Indicates the AWS account that owns the physical resource. + **Region** – Indicates the AWS Region where the resource is located. **RTO** Shows a graphical representation of whether the application is estimated to meet resiliency policy's objectives. This is based on the amount of time that an application can be down without causing significant damage to the organization. The assessment provides an estimated workload RTO. **RPO** Shows a graphical representation of whether the application is estimated to meet resiliency policy's objectives. This is based on the amount of time that data can be lost before a significant harm to the business occurs. The assessment provides an estimated workload RPO. **Details** Provides detailed descriptions of each disruption type using **All results** and **Application compliance drifts** tabs. **All results** tab shows all the disruptions including compliance drifts, and **Application compliance drifts** tab displays only compliance drifts. Disruption type includes **Application**, cloud infrastructure (**Infrastructure** and **Availability Zone**), and **Region**, and provides the following information about it: + **AppComponent** The resources that comprise the application. For example, your application might have a database or compute component. + **Estimated RTO** Indicates whether your policy configuration aligns with your policy requirement. We provide two values, our **Estimated RTO** and your **Targeted RTO**. For example, if you see **2h** value under **Targeted RTO** and **40m** under **Estimated Workload RTO**, it indicates that we provide an estimated workload RTO of 40 minutes, while the current RTO of your application is two hours. We base our estimated workload RTO calculation on the configuration, not the policy. As a result, a multi-Availability Zone database will have the same estimated workload RTO for Availability Zone failure, no matter which policy you select. + **RTO drift** Indicates the duration by which your application has drifted from the estimated workload RTO of the previous successful assessment. We provide two values, our **Estimated RTO** and **RTO drift**. For example, if you see **2h** value under **Estimated RTO** and **40m** under **RTO drift**, it indicates that your application drifts from the estimated workload RTO of the previous successful assessment by 40 minutes. + **Estimated RPO** Shows the actual **Estimated Workload RPO** policy that AWS Resilience Hub estimates, based on the **Targeted RPO** policy that you set for each Application Component. For example, you might have set the RPO target in your resiliency policy for Availability Zone failures to one hour. The estimated result might be calculated near to zero. This assumes that Amazon Aurora, where we commit every transaction, is successful in four out of six nodes, spanning multiple Availability Zones. It might be five minutes for point-in-time restore. The only RTO and RPO target that you can opt not to supply is Region. For some applications, it is useful to plan for recovery when there is a crucial dependency on an AWS service, which might become unavailable in the entire Region. If you choose this option, such as setting RTO or RPO targets for the Region, you’ll receive an estimated recovery time and operational recommendations for such failures. + **RPO drift** Indicates the duration by which your application has drifted from the estimated workload RPO of the previous successful assessment. We provide two values, our **Estimated RPO** and **RPO drift**. For example, if you see **2h** value under **Estimated RPO** and **40m** under **RPO drift**, it indicates that your application drifts from the estimated workload RPO of the previous successful assessment by 40 minutes. # Reviewing resiliency recommendations Resiliency recommendations evaluate Application Components and recommend how to optimize by estimated workload RTO and estimated workload RPO, costs, and minimal changes. With AWS Resilience Hub, you can optimize resiliency using one of the following recommended options in **Why you should choose this option**: **Note** AWS Resilience Hub provides up to three AWS Resilience Hub recommended options. If you set Regional RTO and RPO targets, AWS Resilience Hub displays **Optimize for Region RTO/RPO** in the recommended options. If Regional RTO and RPO targets are not set, **Optimize for Availability Zone (AZ) RTO/RPO** is displayed. For more information about setting Regional RTO/RPO targets while creating resiliency policies, see [Creating resiliency policies](create-policy.md). Estimated workload RTO and estimated workload RPO values for the applications and their configurations are determined by considering the amount of data and individual AppComponents. However, these values are only estimates. You should use your own testing (such as AWS Fault Injection Service) to test your application for actual recovery times. **Optimize for Availability Zone RTO/RPO** The lowest possible estimated workload recovery times (RTO/RPO) during an Availability Zone (AZ) disruption. If your configuration can't be changed sufficiently to meet the RTO and RPO targets, you're informed about the lowest estimated workload AZ recovery times to get your configuration close to the possibility of meeting the policy. **Optimize for Region RTO/RPO** The lowest possible estimated workload recovery times (RTO/RPO) during a Regional disruption. If your configuration can't be changed sufficiently to meet the RTO and RPO targets, you're informed about the lowest estimated workload Region recovery times to get your configuration close to the possibility of meeting the policy. **Optimize for cost** The lowest cost that you can incur and still meet your resiliency policy. If your configuration can't be changed sufficiently to meet the optimization goals, you're informed about the lowest cost that you can incur to get your configuration close to the possibility of meeting the policy. **Optimize for minimal changes** The minimum changes required to achieve your policy targets. If your configuration can't be changed sufficiently to meet the optimization goals, you're informed about the recommended changes that can get your configuration close to the possibility of meeting the policy. The following items are included in the optimization category breakdowns: + **Description** Describes the configurations suggested by AWS Resilience Hub. + **Changes** A list of text changes that describe the necessary tasks to switch to the suggested configuration. + **Base cost** The estimated cost associated with the recommended changes. **Note** **Base cost** can vary based on the usage and it does not include any discounts or offers from Enterprise Discount Program (EDP). + **Estimated Workload RTO and RPO** The estimated workload RTO and estimated workload RPO after changes. AWS Resilience Hub evaluates whether an Application Component (AppComponent) can comply with a resiliency policy. If the AppComponent does not comply with a resiliency policy and AWS Resilience Hub cannot make any recommendations to facilitate compliance, it might be because the recovery time for the selected AppComponent cannot be met within the constraints of the AppComponent. Examples of AppComponent constraints include resource type, storage size, or resource configuration. To facilitate the compliance of the AppComponent with the resiliency policy, change the resource type of the AppComponent or update the resiliency policy to align with what the resource can deliver. # Reviewing operational recommendations Operational recommendations contain recommendations to set up alarms, SOPs, and AWS FIS experiments through AWS CloudFormation templates. AWS Resilience Hub provides AWS CloudFormation template files for you to download and manage the application's infrastructure as code. As a result, we supply recommendations in AWS CloudFormation so that you can add them to your application code. If the size of AWS CloudFormation template file is more than one MB and contains more than 500 resources, AWS Resilience Hub generates more than one AWS CloudFormation template file where the size of each file is not more than one MB and contains up to 500 resources. If the AWS CloudFormation template file is split into multiple files, the AWS CloudFormation template file names will be appended with `partXofY`, where `X` denotes the file number in the sequence and `Y` denotes the total number of files the AWS CloudFormation template file is divided into. For example, if the template file `big-app-template5-Alarm-104849185070-us-west-2.yaml` is divided into four files, the file names would be as follows: + `big-app-template5-Alarm-104849185070-us-west-2-part1of4.yaml` + `big-app-template5-Alarm-104849185070-us-west-2-part2of4.yaml` + `big-app-template5-Alarm-104849185070-us-west-2-part3of4.yaml` + `big-app-template5-Alarm-104849185070-us-west-2-part4of4.yaml` However, in case of large AWS CloudFormation templates, you are requested to provide the Amazon Simple Storage Service URI instead of using CLI/API with local file as input. In AWS Resilience Hub, you can perform the following actions: + You can provision the selected alarms, SOPs, and AWS FIS experiments. To provision alarms, SOPs, and AWS FIS experiments, select the appropriate recommendation and enter a unique name. AWS Resilience Hub creates a template based on your selected recommendations. In **Templates**, you can access your created templates through an Amazon Simple Storage Service (Amazon S3) URL. + You can include or exclude selected alarms, SOPs, and AWS FIS experiments that were recommended for your application at any point of time. For more information see, [Including or excluding operational recommendations](exclude-recommend.md). + You can also search, create, add, remove, and manage tags, for an application and see all the tags associated with it. # Including or excluding operational recommendations AWS Resilience Hub provides an option to include or exclude the alarms, SOPs, and AWS FIS experiments (tests) that were recommended for improving the resiliency score of your application at any point of time. Including and excluding operational recommendations will have an impact on the resiliency score of your application only after you run a new assessment. Hence, we recommend you to run an assessment to get the updated resiliency score and understand its impact on your application. For more information about restricting permissions to include or exclude recommendations per application, see [Limiting permissions to include or exclude AWS Resilience Hub recommendations](include-exclude-limit-permissions.md). **To include or exclude operational recommendations from applications** 1. In the left navigation menu, choose **Applications**. 1. In **Applications**, open an application. 1. Choose **Assessments** and select an assessment from the **Resiliency assessments** table. If you don't have an assessment, complete the procedure in [Running resiliency assessments in AWS Resilience Hub](run-assessment.md) and then return to this step. 1. Select **Operational recommendations** tab. 1. To include or exclude operational recommendations from your application, complete the following procedures: **To include or exclude recommended alarms from your application** 1. To exclude alarms, complete the following steps: 1. Under **Alarms** tab, from **Alarms** table, select all the alarms (with **Not implemented** state) you want to exclude. You can identify the current implementation state of an alarm from the **State** column. 1. From **Actions**, choose **Exclude selected**. 1. From **Exclude recommendations** dialog, select one of the following reasons (optional), and choose **Exclude selected** to exclude the selected alarms from the application. + **Already implemented** – Choose this option if you have already implemented these alarms in an AWS service such as Amazon CloudWatch, or any other third-party service provider. + **Not relevant** – Choose this option if the alarms do not suit your business requirements. + **Too complicated to implement** – Choose this option if you think these alarms are too complicated to implement. + **Other** – Choose this option to specify any other reason for excluding the recommendation. 1. To include alarms, complete the following steps: 1. Under **Alarms** tab, from **Alarms** table, select all the alarms (with **Excluded** state) you want to include. You can identify the current implementation state of the alarm from the **State** column. 1. From **Actions**, choose **Include selected**. 1. From **Include recommendations** dialog, choose **Include selected** to include all the selected alarms in your application. **To include or exclude recommended standard operating procedures (SOPs) from your application** 1. To exclude recommended SOPs, complete the following steps: 1. Under **Standard operating procedures** tab, from **SOPs** table, select all the SOPs (with **Implemented** or **Not implemented** state) you want to exclude. You can identify the current implementation state of an SOP from the **State** column. 1. From **Actions**, choose **Exclude selected** to exclude the selected SOPs from your application. 1. From **Exclude recommendations** dialog, select one of the following reasons (optional), and choose **Exclude selected** to exclude the selected SOPs from the application. + **Already implemented** – Choose this option if you have already implemented these SOPs in an AWS service, or any other third-party service provider. + **Not relevant** – Choose this option if the SOPs do not suit your business requirements. + **Too complicated to implement** – Choose this option if you think these SOPs are too complicated to implement. + **None** – Choose this option if you don't want to specify the reason. 1. To include SOPs, complete the following steps: 1. Under **Standard operating procedures** tab, from **SOPs** table, select all the alarms (with **Excluded** state) you want to include. You can identify the current implementation state of the alarm from the **State** column. 1. From **Actions**, choose **Include selected**. 1. From **Include recommendations** dialog, choose **Include selected** to include all the selected SOPs in your application. **To include or exclude recommended tests from your application** 1. To exclude recommended tests, complete the following steps: 1. Under **Fault injection experiment templates** tab, from **Fault injection experiment templates** table, select all the tests (with **Implemented** or **Not implemented** state) you want to exclude. You can identify the current implementation state of a test from the **State** column. 1. From **Actions**, choose **Exclude selected**. 1. From **Exclude recommendations** dialog, select one of the following reasons (optional), and choose **Exclude selected** to exclude the selected AWS FIS experiments from the application. + **Already implemented** – Choose this option if you have already implemented these tests in an AWS service, or any other third-party service provider. + **Not relevant** – Choose this option if the tests do not suit your business requirements. + **Too complicated to implement** – Choose this option if you think these tests are too complicated to implement. + **None** – Choose this option if you don't want to specify the reason. 1. To include recommended tests, complete the following steps: 1. Under **Fault injection experiment templates** tab, from **Fault injection experiment templates** table, select all the tests (with **Excluded** state) you want to include. You can identify the current implementation state of the test from the **State** column. 1. From **Actions**, choose **Include selected**. 1. From **Include recommendations** dialog, choose **Include selected** to include all the selected tests in your application. # Deleting resiliency assessments You can delete resiliency assessments in the **Assessments** view of your application. **To delete a resiliency assessment** 1. In the left navigation menu, choose **Applications**. 1. In **Applications**, open an application. 1. In **Assessments**, choose an assessment report in the **Resiliency assessments **table. 1. To confirm the deletion, choose **Delete**. The report no longer appears in the **Resiliency assessments** table. # Running and managing resiliency assessments from Resiliency widget Managing resiliency assessments from Resiliency widget AWS Resilience Hub enables you to run assessments for applications created and managed in myApplications in Resiliency widget. Whenever you make modifications to an application, it is recommended to run a resiliency assessment from Resiliency widget or from AWS Resilience Hub console. During this assessment, the configuration of each Application Component is evaluated against established policies and best practices. Based on this evaluation, the assessment generates recommendations for setting up alarms, creating Standard Operating Procedures (SOPs), and implementing testing strategies. Implementing these configuration recommendations can enhance the speed and efficiency of your recovery procedures, ensuring faster incident response and minimizing potential downtime. Alarm recommendations help you set alarms that detect outages. SOP recommendations provide scripts that manage common recovery processes, such as recovery from a backup. Test recommendations offer suggestions to verify your configurations work properly. For example, you can test whether an application recovers during automatic recovery processes, such as automatic scaling or load balancing because of network issues. You can test whether application alarms are triggered when resources reach their limits. You can also test how well SOPs work under the conditions that you indicate. **Topics** + [ # Running resiliency assessments from Resiliency widget ](run-assessment-resiliency-widget.md) + [ # Reviewing assessment summary in Resiliency widget ](review-assessment-resliency-widget.md) # Running resiliency assessments from Resiliency widget For applications created in **myApplications** widget, you can now run resiliency assessments from the **Resiliency** widget and AWS Resilience Hub console. For more information about running resiliency assessments from AWS Resilience Hub console, see [Running resiliency assessments in AWS Resilience Hub](run-assessment.md). **To run a resiliency assessment for an existing **myApplications** application from **Resiliency** widget for the first time** 1. Sign in to the [AWS Management Console](https://console.aws.amazon.com/). 1. Expand the left sidebar and choose **myApplications**. 1. Select the application for which you want to run assessment. As a prerequisite, ensure that you have added the **Resiliency** widget in your AWS Console. To add this widget, complete the following steps. 1. On the upper or lower right of the **Console Home** dashboard, choose **\$1Add widgets**. 1. Choose the **drag indicator**, represented by six vertical dots in the upper left of the widget title bar, and then drag it to your **Console Home** dashboard. 1. Choose **Assess application**. 1. To select an existing IAM role that will be used for accessing resources in the current account, select **Use an IAM role** and then select an IAM role from the **Select an IAM role** dropdown list. If you want to use current IAM user to discover your application resources, choose ** Use the current IAM user permissions** and select **I understand that I must manually configure permissions to enable the required functionality within AWS Resilience Hub** in **Use the current IAM user to discover application resources** section. 1. Choose **Assess**. Alternatively, turn on **Automatically assess daily** to enable AWS Resilience Hub to assess your application daily without any additional costs. AWS Resilience Hub performs the following actions: + Creates an application in AWS Resilience Hub and automatically discovers and maps the associated resources. + Creates and assigns a new resiliency policy with pre-defined values for recovery time objective (RTO) and recovery point objective (RPO). That is, four hours for RTO and one hour for RPO. After you generate an assessment, you can modify the resiliency policy or assign a different policy from the AWS Resilience Hub console. For more information about updating resiliency policy and attaching a different policy, see [ Managing resiliency policies](https://docs.aws.amazon.com/resilience-hub/latest/userguide/resiliency-policies.html?icmpid=docs_resiliencehub_help_panel_resiliency_policies). + Assesses the resilience of the application against RTO and RPO, and continuously monitors resources and configuration changes, and publishes the results. **Note** Before starting assessments, it is advisable to evaluate the potential costs involved in running assessments using AWS Resilience Hub. For detailed pricing information, see the [AWS Resilience Hub pricing](https://aws.amazon.com//resilience-hub/pricing?icmpid=docs_resiliencehub_help_panel_resiliency_policies_hp). **To rerun a resiliency assessment for an existing **myApplications** application from **Resiliency** widget** 1. Sign in to the [AWS Management Console](https://console.aws.amazon.com/). 1. Expand the left sidebar and choose **myApplications**. 1. Select the application you want to reassess. As a prerequisite, ensure that you have added the **Resiliency** widget in your AWS Console. To add this widget, complete the following steps. 1. On the upper or lower right of the **Console Home** dashboard, choose **\$1Add widgets**. 1. Choose the **drag indicator**, represented by six vertical dots in the upper left of the widget title bar, and then drag it to your **Console Home** dashboard. 1. Choose **Reassess** from the **Resiliency** widget. Alternatively, turn on **Automatically assess daily** to enable AWS Resilience Hub to assess your application daily without any additional costs. # Reviewing assessment summary in Resiliency widget The **Resiliency** widget displays a snapshot of the assessment results that will provide you with most important and actionable insights into the myApplications application's resilience, potential vulnerabilities, key performance indicators (KPIs) and recommended actions for improvement. You can learn more about the application's resiliency posture from the most recent assessment using the following: + **Resiliency score history** – This chart displays the trend of the application's resiliency score for up to one year. + **Resiliency score** – Indicates the resiliency score of the application evaluated in the latest assessment. This score reflects how closely your application follows our recommendations for meeting the application's resiliency policy, and for implementing alarms, standard operating procedures (SOPs), and AWS Fault Injection Service (AWS FIS) experiments. Choose the number to view additional information in the **Resiliency score** section under **Summary** tab in the AWS Resilience Hub console. For more information, see [Assessment report](review-assessment.md#review-section). + **Policy breaches** – Choose the number below to view all the Application Components (AppComponents) that breaches the policies attached to your application in the **Assessment report** pane in the AWS Resilience Hub console. For more information, see [Assessment report](review-assessment.md#review-section). + **Policy drifts** – Indicates the AppComponents that complied with the policy in the previous assessment but failed to comply in the current assessment. Choose the number below to view the AppComponents in the **Assessment report** pane in the AWS Resilience Hub console. For more information, see [Assessment report](review-assessment.md#review-section). + **Resource drifts** – Choose the number below to view all the resources that drifted from the latest assessment in the **Assessment report** pane in the AWS Resilience Hub console. For more information, see [Assessment report](review-assessment.md#review-section). + **Go to Resilience Hub ** – Choose this option to open your application in the AWS Resilience Hub console. # Managing alarms When you run a resiliency assessment, as a part of operational recommendations, AWS Resilience Hub recommends setting up Amazon CloudWatch alarms to monitor your application resiliency. We recommend these alarms based on the resources and components of your current application configuration. If the resources and components in your application change, you should run a resiliency assessment to ensure you have the correct Amazon CloudWatch alarms for your updated application. Additionally, AWS Resilience Hub now automatically detects and integrates any already configured Amazon CloudWatch alarms into its resilience assessments, providing a more comprehensive view of your application's resilience posture. This new capability combines AWS Resilience Hub recommendations with your current monitoring setup, streamlining alarm management and enhancing assessment accuracy. If you have implemented an Amazon CloudWatch alarm and AWS Resilience Hub doesn't automatically detect it, you can exclude the alarm and select the reason as **Already implemented**. For more information about excluding recommendation, see [Including or excluding operational recommendations](exclude-recommend.md). AWS Resilience Hub provides a template file (`README.md`) that allows you to create alarms recommended by AWS Resilience Hub within AWS (such as Amazon CloudWatch) or outside AWS. The default values provided in the alarms are based on the best practices that are used for creating these alarms. **Topics** + [ # Creating alarms from the operational recommendations ](create-alarm.md) + [ # Viewing alarms ](view-alarm.md) # Creating alarms from the operational recommendations AWS Resilience Hub creates an CloudFormation template that contains details to create the selected alarms in Amazon CloudWatch. After the template is generated, you can access it through an Amazon S3 URL, download the same and place it in your code pipeline or create a stack through the CloudFormation console. To create an alarm based on AWS Resilience Hub recommendations, you must create an CloudFormation template for the recommended alarms and include them in your code base. **To create alarms in operational recommendations** 1. In the left navigation menu, choose **Applications**. 1. In **Applications**, choose your application. 1. Choose **Assessments** tab. In **Resiliency assessments** table, you can identify your assessments using the following information: + **Name** – Name of the assessment you had provided at the time of creation. + **Status** – Indicates the execution state of the assessment. + **Compliance status** – Indicates if the assessment is compliant with the resiliency policy. + **Resiliency drift status** – Indicates if your application has drifted or not from the previous successful assessment. + **App version** – Version of your application. + **Invoker** – Indicates the role that invoked the assessment. + **Start time** – Indicates the start time of the assessment. + **End time** – Indicates the end time of the assessment. + **ARN** – The Amazon Resource Name (ARN) of the assessment. 1. Select an assessment from the **Resiliency assessments** table. If you don't have an assessment, complete the procedure in [Running resiliency assessments in AWS Resilience Hub](run-assessment.md) and then return to this step. 1. Choose **Operational recommendations**. 1. If not selected by default, choose **Alarms** tab. In **Alarms** table, you can identify the recommended alarms using the following: + **Name** – Name of the alarm that you have set for your application. + **Description** – Describes the objective of the alarm. + **State** – Indicates the current implementation state of the Amazon CloudWatch alarms. This column displays one of the following values: + **Implemented** – Indicates that the alarms recommended by AWS Resilience Hub are implemented in your application. Choosing the number below will filter the **Alarms** table to display all the recommended alarms that are implemented in your application. + **Not implemented** – Indicates that the alarms recommended by AWS Resilience Hub are included but not implemented in your application. Choosing the number below will filter the **Alarms** table to display all the recommended alarms that are not implemented in your application. + **Excluded** – Indicates that the alarms recommended by AWS Resilience Hub are excluded from your application. Choosing the number below will filter the **Alarms** table to display all the recommended alarms that are excluded from your application. For more information about including and excluding recommended alarms, see [Including or excluding operational recommendations](https://docs.aws.amazon.com/resilience-hub/latest/userguide/exclude-recommend.html?icmpid=docs_resiliencehub_help_panel_operational_recommendations_alarms). + **Inactive** – Indicates that the alarms are deployed to Amazon CloudWatch, but the status is set to **INSUFFICIENT\$1DATA** in Amazon CloudWatch. Choosing the number below will filter the **Alarms** table to display all the implemented and inactive alarms. + **Configuration** – Indicates if there are any pending configuration dependencies that needs to be addressed. + **Type** – Indicates the type of alarm. + **AppComponent** – Indicates the Application Components (AppComponents) that are associated with this alarm. + **Reference ID** – Indicates the logical identifier of the AWS CloudFormation stack event in AWS CloudFormation. + **Recommendation ID** – Indicates the logical identifier of the AWS CloudFormation stack resource in AWS CloudFormation. 1. In **Alarms** tab, to filter the alarm recommendations in **Alarms** table based on a specific state, select a number below the same. 1. Select the recommended alarms that you want to set up for your application, and choose **Create CloudFormation template**. 1. In **Create CloudFormation template** dialog, you can use the auto-generated name, or you can enter a name for CloudFormation template in the **CloudFormation template name** box. 1. Choose **Create**. This can take up to a few minutes to create the AWS CloudFormation template. Complete the following procedure to include the recommendations in your code base. **To include the AWS Resilience Hub recommendations your code base** 1. Choose **Templates** tab to view the template you just created. You can identify your templates using the following: + **Name** – Name of the assessment you had provided at the time of creation. + **Status** – Indicates the execution state of the assessment. + **Type** – Indicates the type of operational recommendation. + **Format** – Indicates the format (JSON/ text) in which the template is created. + **Start time** – Indicates the start time of the assessment. + **End time** – Indicates the end time of the assessment. + **ARN** – The ARN of the template 1. Under **Template details**, choose the link below **Templates S3 Path** to open the template object in Amazon S3 console. 1. In Amazon S3 console, from **Objects** table, choose the Alarms folder link. 1. To copy the Amazon S3 path, select the check box in front of the JSON file and choose **Copy URL**. 1. Create an AWS CloudFormation stack from AWS CloudFormation console. For more information about creating an AWS CloudFormation stack, see [https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html). While creating the AWS CloudFormation stack, you must provide the Amazon S3 path that you copied from the previous step. # Viewing alarms You can view all the active alarms that you have set up to monitor the resiliency of your applications. AWS Resilience Hub uses CloudFormation template to store alarm details that is in-turn used for creating the alarms in Amazon CloudWatch. You can access the CloudFormation template using Amazon S3 URL, and can download and place it into your code pipeline or create a stack through the CloudFormation console. To view alarms from the dashboard, choose **Dashboard** from the left navigation menu. In **Implemented alarms** table, you can identify the implemented alarms using the following information: + **Application impacted** – Name of the applications that have implemented this alarm. + **Active alarms** – Indicates the number of active alarms triggered from the applications. + **FIS in progress** – Indicates the AWS FIS experiment that is currently running for your application. **To view the alarms implemented in your application** 1. In the left navigation menu, choose **Applications**. 1. Select an application from the **Applications** table. 1. In the application summary page, the **Implemented alarms** table displays all the recommended alarms that are implemented in your application. To find a specific alarm in the **Implemented alarms** table, in the **Find alarms by text, property, or value** box, select one of the following fields, choose an operation, and then type a value. + **Alarm name** – Name of the alarm that you have set for your application. + **Description** – Describes the objective of the alarm. + **State** – Indicates the current implementation state of the Amazon CloudWatch alarm. This column displays one of the following values: + **Implemented** – Indicates that the alarms recommended by AWS Resilience Hub are implemented in your application. Choose the number below to view all the recommended and implemented alarms in **Operational recommendations** tab. + **Not implemented** – Indicates that the alarms recommended by AWS Resilience Hub are included but not implemented in your application. Choose the number below to view all the recommended and non-implemented alarms in **Operational recommendations** tab. + **Excluded** – Indicates that the alarms recommended by AWS Resilience Hub are excluded from your application. Choose the number below to view all the recommended and excluded alarms in **Operational recommendations** tab. For more information about including and excluding recommended alarms, see [Including or excluding operational recommendations](https://docs.aws.amazon.com/resilience-hub/latest/userguide/exclude-recommend.html?icmpid=docs_resiliencehub_help_panel_operational_recommendations_alarms). + **Inactive** – Indicates that the alarms are deployed to Amazon CloudWatch, but the status is set to **INSUFFICIENT\$1DATA** in Amazon CloudWatch. Choose the number below to view all the implemented and inactive alarms in **Operational recommendations** tab. + **Source template** – Provides the Amazon Resource Name (ARN) of the AWS CloudFormation stack that contains the alarm details. + **Resource** – Displays the resources that this alarm is attached to and was implemented for. + **Metric** – Displays the Amazon CloudWatch metric assigned for the alarm. For more information about Amazon CloudWatch metrics, see [Amazon CloudWatch Metrics](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_concepts.html#Metric). + **Last change** – Displays the date and time an alarm was last modified. **To view the recommended alarms from assessments** 1. In the left navigation menu, choose **Applications**. 1. Select an application from the **Applications** table. To find an application, enter the application name in the **Find applications** box. 1. Choose **Assessments** tab. In **Resiliency assessments** table, you can identify your assessments using the following information: + **Name** – Name of the assessment you had provided at the time of creation. + **Status** – Indicates the execution state of the assessment. + **Compliance status** – Indicates if the assessment is compliant with the resiliency policy. + **Resiliency drift status** – Indicates if your application has drifted or not from the previous successful assessment. + **App version** – Version of your application. + **Invoker** – Indicates the role that invoked the assessment. + **Start time** – Indicates the start time of the assessment. + **End time** – Indicates the end time of the assessment. + **ARN** – The Amazon Resource Name (ARN) of the assessment. 1. Select an assessment from the **Resiliency assessments** table. 1. Choose **Operational recommendations** tab. 1. If not selected by default, choose **Alarms** tab. In **Alarms** table, you can identify the recommended alarms using the following: + **Name** – Name of the alarm that you have set for your application. + **Description** – Describes the objective of the alarm. + **State** – Indicates the current implementation state of the Amazon CloudWatch alarms. This column displays one of the following values: + **Implemented ** – Indicates that the alarm is implemented in your application. Choosing the number below will filter the **Alarms** table to display all the recommended alarms that are implemented in your application. + **Not implemented** – Indicates that the alarm is not implemented or included in your application. Choosing the number below will filter the **Alarms** table to display all the recommended alarms that are not implemented in your application. + **Excluded** – Indicates that the alarm is excluded from the application. Choosing the number below will filter the **Alarms** table to display all the recommended alarms that are excluded from your application. For more information about including and excluding recommended alarms, see [Including or excluding operational recommendations](exclude-recommend.md). + **Inactive** – Indicates that the alarms are deployed to Amazon CloudWatch, but the status is set to **INSUFFICIENT\$1DATA** in Amazon CloudWatch. Choosing the number below will filter the **Alarms** table to display all the implemented and inactive alarms. + **Configuration** – Indicates if there are any pending configuration dependencies that needs to be addressed. + **Type** – Indicates the type of alarm. + **AppComponent** – Indicates the Application Components (AppComponents) that are associated with this alarm. + **Reference ID** – Indicates the logical identifier of the AWS CloudFormation stack event in AWS CloudFormation. + **Recommendation ID** – Indicates the logical identifier of the AWS CloudFormation stack resource in AWS CloudFormation. # Managing standard operating procedures A standard operating procedure (SOP) is a prescriptive set of steps designed to efficiently recover your application in the event of an outage or alarm. Prepare, test, and measure your SOPs in advance to ensure timely recovery in the event of an operational outage. Based on your Application Components, AWS Resilience Hub recommends the SOPs you should prepare. AWS Resilience Hub works with Systems Manager to automate the steps of your SOPs by providing a number of SSM documents you can use as the basis for those SOPs. For example, AWS Resilience Hub may recommend an SOP for adding disk space based on an existing SSM Automation document. To run this SSM document, you require a specific IAM role with the correct permissions. AWS Resilience Hub creates metadata in your application indicating which SSM automation document to run in the case of disk shortage, and which IAM role is required to run that SSM document. This metadata is then saved in an SSM parameter. In addition to configuring the SSM automation, it is also best practice to test it with an AWS FIS experiment. Therefore, AWS Resilience Hub also provides an AWS FIS experiment that calls the SSM automation document - this way, you can proactively test your application to make sure the SOP you've created does the intended job. AWS Resilience Hub provides its recommendations in the form of an CloudFormation template you can add to your application code base. This template provides: + The IAM role with the permissions required to run the SOP. + An AWS FIS experiment you can use to test the SOP. + An SSM parameter that contains application metadata indicating which SSM document and which IAM role is to be run as the SOP, and on which resource. For example: `$(DocumentName) for SOP $(HandleCrisisA) on $(ResourceA)`. Creating an SOP may require some trial and error. Running a resiliency assessment against your application and generating an CloudFormation template from the AWS Resilience Hub recommendations is a good start. Use the CloudFormation template to generate an CloudFormation stack, then use the SSM parameters and their default values in your SOP. Run the SOP and see what refinements you need to make. Because all applications have differing requirements, the default list of SSM documents that AWS Resilience Hub provides will not be sufficient for all of your needs. You can, however, copy the default SSM documents and use them as a basis to create your own custom documents tailored for your application. You can also create your own entirely new SSM documents. If you create your own SSM documents instead of modifying the defaults, you must associate them with SSM parameters, so the correct SSM document is called when the SOP runs. When you've finalized your SOP by creating the necessary SSM documents and updating the parameter and document associations as necessary, add the SSM documents directly to your code base, and make any subsequent changes or customizations there. That way, every time you deploy your application, you'll also deploy the most up-to-date SOP. **Topics** + [ # Building an SOP based on AWS Resilience Hub recommendations ](building-sops.md) + [ # Creating a custom SSM document ](create-custom-ssm-doc.md) + [ # Using a custom SSM document instead of the default ](using-different-ssm-doc.md) + [ # Testing SOPs ](testing-sops.md) + [ # Viewing standard operating procedures ](view-sops.md) # Building an SOP based on AWS Resilience Hub recommendations To build an SOP based on AWS Resilience Hub recommendations, you need an AWS Resilience Hub application with a resiliency policy attached to it, and you need to have run a resiliency assessment against that application. The resiliency assessment generates the recommendations for your SOP. To build an SOP based on AWS Resilience Hub recommendations, you must create an CloudFormation template for the recommended SOPs and include them in your code base. **Create an CloudFormation template for the SOP recommendations** 1. Open the AWS Resilience Hub console. 1. In the navigation pane, choose **Applications**. 1. From the list of applications, choose the application you want to create an SOP for. 1. Choose **Assessments** tab. 1. Select an assessment from the **Resiliency assessments** table. If you don't have an assessment, complete the procedure in [Running resiliency assessments in AWS Resilience Hub](run-assessment.md) and then return to this step. 1. Under **Operational recommendations**, choose **Standard operating procedures**. 1. Select all the SOP recommendations you want to include. 1. Choose **Create CloudFormation template**. This can take up to a few minutes to create the AWS CloudFormation template. Complete the following procedure to include the SOP recommendations in your code base. **To include the AWS Resilience Hub recommendations in your code base** 1. In **Operational recommendations**, choose **Templates**. 1. In the list of templates, choose the name of the SOP template you just created. You can identify the SOPs that are implemented in your application using the following information: + **SOP name** – Name of the SOP that you have defined for your application. + **Description** – Describes the objective of the SOP. + **SSM document** – Amazon S3 URL of the SSM document that contains the SOP definition. + **Test run** – Amazon S3 URL of the document that contains the results of the latest test. + **Source template** – Provides the Amazon Resource Name (ARN) of the AWS CloudFormation stack that contains the SOP details. 1. Under **Template details**, choose the link in **Templates S3 Path** to open the template object in Amazon S3 console. 1. In Amazon S3 console, from **Objects** table, choose the SOP folder link. 1. To copy the Amazon S3 path, select the check box in front of the JSON file and choose **Copy URL**. 1. Create an AWS CloudFormation stack from AWS CloudFormation console. For more information about creating an AWS CloudFormation stack, see [https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html). While creating the AWS CloudFormation stack, you must provide the Amazon S3 path that you copied from the previous step. # Creating a custom SSM document To fully automate the recovery of your application, you may need to create a custom SSM document for your SOP in Systems Manager console. You can modify an existing SSM document as a base, or you can create a new SSM document. For detailed information on using Systems Manager to create an SSM document, see [Walkthrough: Using Document Builder to create a custom runbook](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-walk-document-builder.html). For information about SSM document syntax, see [SSM document syntax](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-doc-syntax.html). For information about automating SSM document actions, see [Systems Manager automation actions reference](https://docs.aws.amazon.com/systems-manager/latest/userguide/automation-actions.html). # Using a custom SSM document instead of the default To replace the SSM document AWS Resilience Hub suggested for your SOP with a custom document you've created, work directly in your code base. In addition to adding your new custom SSM automation document, you'll also: 1. Add the IAM permissions required to run the automation. 1. Add an AWS FIS experiment to test your SSM document. 1. Add an SSM parameter that points to the automation document you want to use as the SOP. Generally, it's most efficient to work with the suggested default values in AWS Resilience Hub and customize them as necessary. For example, add or remove permissions as necessary for the IAM role, change the AWS FIS experiment setup to point to the new SSM document, or change the SSM parameter to point to your new SSM document. # Testing SOPs As previously mentioned, best practice is to add AWS FIS experiments to your CI/CD pipelines to test your SOPs regularly; this ensures they're ready to go if an outage occurs. Test both AWS Resilience Hub-provided and custom SOPs. # Viewing standard operating procedures **To view the implemented SOPs from applications** 1. In the left navigation menu, choose **Applications**. 1. In **Applications**, open an application. 1. Choose **Standard operating procedures** tab. In **Standard operating procedures summary** section, the **Implemented standard operating procedures** table displays the list of SOPs that are generated from SOP recommendations. You can identify your SOPs by the following: + **SOP name** – Name of the SOP that you have defined for your application. + **SSM document** – S3 URL of the Amazon EC2 Systems Manager document that contains the SOP definition. + **Description** – Describes the objective of the SOP. + **Test run** – S3 URL of the document that contains the results of the latest test. + **Reference ID** – Identifier of the referenced SOP recommendation. + **Resource ID** – Identifier of the resource for which the SOP recommendation is implemented. **To view the recommended SOPs from assessments** 1. In the left navigation menu, choose **Applications**. 1. Select an application from the **Applications** table. To find an application, enter the application name in the **Find applications** box. 1. Choose **Assessments** tab. In **Resiliency assessments** table, you can identify your assessments using the following information: + **Name** – Name of the assessment you had provided at the time of creation. + **Status** – Indicates the execution state of the assessment. + **Compliance status** – Indicates if the assessment is compliant with the resiliency policy. + **Resiliency drift status** – Indicates if your application has drifted or not from the previous successful assessment. + **App version** – Version of your application. + **Invoker** – Indicates the role that invoked the assessment. + **Start time** – Indicates the start time of the assessment. + **End time** – Indicates the end time of the assessment. + **ARN** – The Amazon Resource Name (ARN) of the assessment. 1. Select an assessment from the **Resiliency assessments** table. 1. Choose **Operational recommendations** tab. 1. Choose **Standard operating procedures** tab. In the **Standard operating procedures** table, you can understand more about the recommended SOPs using the following information: + **Name** – Name of the recommended SOP. + **Description** – Describes the objective of the SOP. + **State** – Indicates the current implementation state of the SOP. That is, **Implemented**, **Not implemented**, and **Excluded**. + **Configuration** – Indicates if there are any pending configuration dependencies that needs to be addressed. + **Type** – Indicates the type of SOP. + **AppComponent** – Indicates the Application Components (AppComponents) that are associated with this SOP. For more information about supported AppComponents, see [Grouping resources in an AppComponent](https://docs.aws.amazon.com/resilience-hub/latest/userguide/AppComponent.grouping.html?icmpid=docs_resiliencehub_help_panel_operational_recommendations_alarms). + **Reference ID** – Indicates the logical identifier of the AWS CloudFormation stack event in AWS CloudFormation. + **Recommendation ID** – Indicates the logical identifier of the AWS CloudFormation stack resource in AWS CloudFormation. # Managing AWS Fault Injection Service experiments This section describes how to manage AWS Fault Injection Service (AWS FIS) experiments in AWS Resilience Hub. You run AWS FIS experiments to measure the resiliency of your AWS resources and the amount of time it takes to recover from application, infrastructure, availability zone, and AWS Region incidents. To measure resiliency, these AWS FIS experiments simulate disruptions to your AWS resources. Examples of disruptions include network unavailable errors, failovers, stopped processes on Amazon EC2 or AWS ASG, boot recovery in Amazon RDS, and problems with your Availability Zone. When the AWS FIS experiment concludes, you can estimate whether an application can recover from the outage types defined in the RTO target of the resiliency policy. All the experiments in AWS Resilience Hub are built using AWS FIS and they execute AWS FIS actions. AWS FIS experiments use only AWS FIS automation actions that are customized to specific AWS services (such as Amazon EKS action). For more information about AWS FIS actions, see [AWS FIS actions reference](https://docs.aws.amazon.com/fis/latest/userguide/fis-actions-reference.html). You can use the AWS FIS experiments in their default state or customize them based on your requirements. For more information about managing AWS FIS experiments from AWS Resilience Hub console and AWS FIS console, see the following topics: + AWS Resilience Hub console + [Viewing AWS FIS experiments](view-fis-experiment.md) + [To view the list of implemented AWS FIS experiments from applications](view-fis-experiment.md#view-active-fis-experiments) + [To view the recommended AWS FIS experiments from assessments](view-fis-experiment.md#view-recommended-fis-experiments) + [Running AWS FIS experiments](test-assessment-report.md#arh-running-aws-fis-experiments) + [AWS Fault Injection Service experiment failures/status check](test-failures.md) + AWS FIS console + [Managing your AWS FIS experiments](https://docs.aws.amazon.com//fis/latest/userguide/experiments.html) + [Working with the AWS FIS scenario library](https://docs.aws.amazon.com//fis/latest/userguide/scenario-library.html) + [Managing AWS FIS experiment templates](https://docs.aws.amazon.com//fis/latest/userguide/manage-experiment-template.html) # Initiating, creating, and running AWS FIS experiments AWS Resilience Hub simplifies AWS FIS experiments by integrating with AWS FIS experiments. It provides tailored recommendations and allows initiating AWS FIS experiments with pre-populated templates mapped to your Application Components (AppComponents), enabling efficient resilience testing. **To initiate an AWS FIS experiment from Operational recommendations** 1. Open the AWS Resilience Hub console. 1. In the navigation pane, choose **Applications**. 1. From the list of applications, choose the application you want to create a test for. 1. Choose **Assessments** tab. 1. Select an assessment from the **Resiliency assessments** table. If you don't have an assessment, complete the procedure in [Running resiliency assessments in AWS Resilience Hub](run-assessment.md) and then return to this step. 1. Choose **Operational recommendations** tab. 1. Choose the right arrow before **Fault injection experiments**. This section lists all the AWS FIS experiments recommended by AWS Resilience Hub for your application to stress-test and improve its resilience. Based on your implementation, the AWS FIS experiments are categorized into the following states: + **Implemented** – Indicates that the experiments recommended by AWS Resilience Hub are implemented in your application. Choose the number below to view all the implemented experiments in the **Experiments** table. + **Partially implemented** – Indicates that the experiments recommended by AWS Resilience Hub are partially implemented in your application. Choose the number below to view all the partially implemented experiments in the **Experiments** table. + **Not implemented** – Indicates that the experiments recommended by AWS Resilience Hub are unimplemented in your application. Choose the number below to view all the unimplemented experiments in the **Experiments** table. + **Excluded** – Indicates that the experiments recommended by AWS Resilience Hub are excluded from your application. Choose the number below to view all the excluded experiments in the **Experiments** table. For more information about including and excluding recommended experiments, see [Including or excluding operational recommendations](https://docs.aws.amazon.com/resilience-hub/latest/userguide/exclude-recommend.html?icmpid=docs_resiliencehub_help_panel_operational_recommendations_alarms). **Experiments** table lists all the implemented AWS FIS experiments that impact the resiliency score of your application. You can identify the AWS FIS experiments using the following information: + **Action name** – Indicates the AWS FIS action recommended for your application. Choose the action name to view all the recommended AppComponents on the **AWS FIS experiment details** page. When the **State** is set to **Not trackable**, it indicates that the AWS FIS experiment is a scenario. Choose the scenario name to view its details on the **Scenario library** page in the AWS FIS console. + **State** – Indicates the current implementation state of the AWS FIS experiment. That is, **Implemented**, **Partially implemented**, **Not implemented**, and **Excluded**. **Note** AWS FIS scenario is a console-only feature with multiple predefined actions. Hence, AWS Resilience Hub cannot track it and it will set the **State** to **Not trackable**. + **Description** – Describes the objective of the AWS FIS action. 1. Select an AWS FIS action for which you want to initiate an experiment. In the AWS FIS experiment recommendation section, you can understand more about the experiments you need implement on the AppComponents using the following information: + **Name** – Name of the AppComponent in which the resources are grouped into. + **State** – Indicates the current implementation state of the AWS FIS action. That is, **Implemented**, **Partially implemented**, **Not implemented**, and **Excluded**. **Note** AWS FIS scenario is a console-only feature with multiple predefined actions. Hence, AWS Resilience Hub cannot track it and it will set the **State** to **Not trackable**. + **Target selection** – Indicates how the resources will be included in the experiment when you choose **Initiate experiment**. If AWS Resilience Hub doesn't automatically determine target resources, hover over the respective **Target selection** field for guidance on adding them. + **Resources** – Indicates the number of resources grouped under the AppComponent. Choose the number to view these resources in the **Resources** dialog box. You can identify the resources using the following: + **Logical ID** – Indicates the logical ID of the resource. A logical ID is a name used to identify resources in your AWS CloudFormation, Terraform state file, myApplications application, AWS Resource Groups resource, or Amazon Elastic Kubernetes Service cluster. + **Physical ID** – Indicates the actual assigned identifier for the resource, such as an Amazon EC2 instance ID or an Amazon S3 bucket name. + **Type** – Indicates the type of resource. + **Region** – Indicates the AWS Region in which the resource is located. 1. Select an AppComponent and choose **Include** or **Exclude** to include or exclude the AppComponent in the AWS FIS experiment, respectively. 1. Choose **Initiate experiment**. AWS Resilience Hub will redirect you to **Specify template details** page in the AWS FIS console, opening it in a new tab. 1. To create an experiment template, complete the steps in [ To create an experiment template using the console](https://docs.aws.amazon.com/fis/latest/userguide/create-template.html). Additionally, after you enter the template details and choose **Next** in the **Specify template details** page of the AWS FIS console by following the steps in [ To create an experiment template using the console](https://docs.aws.amazon.com/fis/latest/userguide/create-template.html), AWS Resilience Hub automatically tries to map **Actions** and **Targets** for your resource types in the **Actions and targets** page. However, to improve the coverage, you can manually add actions and targets by choosing **Add action** and **Add target**, respectively, and complete the rest of the procedure to create your experiment. ## Running AWS FIS experiments Running AWS FIS experiments After creating an experiment in AWS FIS console, follow the steps in [Start an experiment from a template](https://docs.aws.amazon.com/fis/latest/userguide/start-experiment-from-template.html) to run an experiment in AWS FIS console. If you want AWS Resilience Hub to detect the latest experiments you have run in AWS FIS, you must run a new assessment. For more information about running assessments, see [Running resiliency assessments in AWS Resilience Hub](run-assessment.md). # Viewing AWS FIS experiments In AWS Resilience Hub, view the AWS FIS experiments that you set up to measure the resiliency of your AWS resources and the amount of time it takes to recover from application, infrastructure, availability zone, and AWS Region incidents. To view the list of active AWS FIS experiments from the dashboard, choose **Dashboard** from the left navigation menu. In the **Implemented experiments** table, you can identify the AWS FIS experiments using the following information: + **Experiment ID** – Identifier of the AWS FIS experiment. + **Action** – Indicates the AWS FIS action associated with the AWS FIS experiment. Additionally, if there are more than one action, it highlights the number of AWS FIS actions associated with the AWS FIS experiment. You can identify the details by hovering over them or by navigating to them. + **Experiment template ID** – Identifier of the AWS FIS experiment template that was used to create the AWS FIS experiment. **To view the list of implemented AWS FIS experiments from applications** 1. In the left navigation menu, choose **Applications**. 1. Select an application from the **Applications** table. To find an application, enter the application name in the **Find applications** box. 1. Choose **Fault injection experiments**. In the **Implemented experiments** table, you can identify the AWS FIS experiments implemented in your application using the following information: + **Experiment ID** – Identifier of the AWS FIS experiment. + **Action** – Indicates the AWS FIS action associated with the AWS FIS experiment. Additionally, if there are more than one action, it highlights the number of AWS FIS actions associated with the AWS FIS experiment. You can identify the details by hovering over them or by navigating to them. + **Experiment template ID** – Identifier of the AWS FIS experiment template that was used to create the AWS FIS experiment. **To view the recommended AWS FIS experiments from assessments** 1. In the left navigation menu, choose **Applications**. 1. Select an application from the **Applications** table. To find an application, enter the application name in the **Find applications** box. 1. Choose **Assessments** tab. In the **Assessments** table, you can identify your assessments using the following information: + **Name** – Name of the assessment you had provided at the time of creation. + **Status** – Indicates the execution state of the assessment. + **Compliance status** – Indicates if the assessment is compliant with the resiliency policy. + **Resiliency** – Indicates if your application has drifted from the RTO and RPO targets defined in the attached resiliency policy or not from the previous successful assessment. + **App version** – Version of your application that was assessed. + **Invoker** – Indicates the role that invoked the assessment. + **Start time** – Indicates the start time of the assessment. + **End time** – Indicates the end time of the assessment. + **ARN** – The Amazon Resource Name (ARN) of the assessment. 1. Select an assessment from the **Assessments** table. 1. Choose **Operational recommendations**. 1. Choose the right arrow before **Fault injection experiments**. This section lists all the AWS FIS experiments recommended by AWS Resilience Hub for your application to stress-test and improve its resilience. Based on your implementation, the AWS FIS experiments are categorized into the following states: + **Implemented** – Indicates that the experiments recommended by AWS Resilience Hub are implemented in your application. Choose the number below to view all the implemented experiments in the **Experiments** table. + **Partially implemented** – Indicates that the experiments recommended by AWS Resilience Hub are partially implemented in your application. Choose the number below to view all the partially implemented experiments in the **Experiments** table. + **Not implemented** – Indicates that the experiments recommended by AWS Resilience Hub are unimplemented in your application. Choose the number below to view all the unimplemented experiments in the **Experiments** table. + **Excluded** – Indicates that the experiments recommended by AWS Resilience Hub are excluded from your application. Choose the number below to view all the excluded experiments in the **Experiments** table. For more information about including and excluding recommended experiments, see [Including or excluding operational recommendations](https://docs.aws.amazon.com/resilience-hub/latest/userguide/exclude-recommend.html?icmpid=docs_resiliencehub_help_panel_operational_recommendations_alarms). **Experiments** table lists all the implemented AWS FIS experiments that impact the resiliency score of your application. You can identify the AWS FIS experiments using the following information: + **Action name** – Indicates the AWS FIS action recommended for your application. When the **State** is set to **Not trackable**, it indicates that the AWS FIS experiment is a scenario. Choose the scenario name to view its details on the **Scenario library** page in the AWS FIS console. + **State** – Indicates the current implementation state of the AWS FIS experiment. That is, **Implemented**, **Partially implemented**, **Not implemented**, and **Excluded**. **Note** AWS FIS scenario is a console-only feature with multiple predefined actions. Hence, AWS Resilience Hub cannot track it and it will set the **State** to **Not trackable**. + **Description** – Describes the objective of the AWS FIS action. # AWS Fault Injection Service experiment failures/status check AWS Resilience Hub allows you to track the status of your experiment that you have started. For more information, see the [To view the recommended AWS FIS experiments from assessments](view-fis-experiment.md#view-recommended-fis-experiments) procedure. **Topics** + [ # Analyzing AWS FIS experiment execution using AWS Systems Manager ](test-failures-ssm.md) + [ # AWS FIS experiment failures while testing Kubernetes pods running in your Amazon Elastic Kubernetes Service clusters ](test-failures-eks.md) # Analyzing AWS FIS experiment execution using AWS Systems Manager After running an AWS FIS experiment, you can view the execution details in the AWS Systems Manager. 1. Go to **CloudTrail** > **Event History**. 1. Filter events by **User name** using the experiment ID. 1. View the StartAutomationExecution entry. **Request ID** is the SSM automation ID. 1. Go to **AWS Systems Manager **> **Automation**. 1. Filter by **Execution ID** using SSM automation ID and view the automation details. You can analyze the execution with any Systems Manager automation. For more information, see the [AWS Systems Manager Automation](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-automation.html) user guide. The execution input parameters appear in the **Input parameters** section of the **Execution Detail** and include optional parameters not appearing in the AWS FIS experiment. You can find information on step status and other step details by drilling down to specific steps within the Execution steps. **Common failures** The following are common failures encountered while executing an assessment report: + Alarm template was not deployed before the Test/SOP experiment was executed. This causes an error message during the automation step. + **Failure message:** `The following parameters were not found: [/ResilienceHub/Alarm/3dee49a1-9877-452a-bb0c-a958479a8ef2/nat-gw-alarm-bytes-out-to-source-2020-09-21_nat-02ad9bc4fbd4e6135]. Make sure all the SSM parameters in automation document are created in SSM Parameter Store.` + **Remediation:** Ensure to render the relevant alarm and deploy the resulting template before rerunning the fault injection experiment. + Missing permissions in the execution role. This error message occurs if the provided execution role is missing a permission and appears within the step details. + **Failure message:** `An error occurred (Unauthorized Operation) when calling the DescribeInstanceStatus operation: You are not authorized to perform this operation. Please Refer to Automation Service Troubleshooting Guide for more diagnosis details`. + **Remediation**: Verify you provided the correct execution role. If this was done, add the required permission and rerun the assessment. + Execution succeeded but did not have the expected result. This is the result of incorrect parameters or an internal automation issue. + **Failure message:** The execution succeeded, so no error message is shown. + **Remediation:** Check the input parameters and look at the executed steps as explained in the Analyze AWS FIS experiment execution before examining the individual steps for expected inputs and outputs. # AWS FIS experiment failures while testing Kubernetes pods running in your Amazon Elastic Kubernetes Service clusters The following are common Amazon Elastic Kubernetes Service (Amazon EKS) failures encountered while testing Kubernetes pods running in your Amazon EKS clusters: + Incorrect configuration of IAM roles for AWS FIS experiments or the Kubernetes service account. + **Failure messages:** + `Error resolving targets. Kubernetes API returned ApiException with error code 401`. + `Error resolving targets. Kubernetes API returned ApiException with error code 403`. + `Unable to inject AWS FIS Pod: Kubernetes API returned status code 403. Check Amazon EKS logs for more details`. + **Remediation:** Verify the following. + Ensure that you have followed the instruction in [Use the AWS FIS`aws:eks:pod` actions](https://docs.aws.amazon.com/fis/latest/userguide/eks-pod-actions.html). + Ensure that you have created and configured a Kubernetes Service Account with the necessary RBAC permissions and the correct namespace. + Ensure that you have mapped the provided IAM role (see the output of the CloudFormation stack of the test) to the Kubernetes user. + Unable to start AWS FIS Pod: Max failed sidecar containers reached. This usually happens when the memory is not sufficient to run the AWS FIS sidecar container. + **Failure message:** `Unable to heartbeat FIS Pod: Max failed sidecar containers reached`. + **Remediation:** One option to avoid this error is to reduce the target load percentage to be aligned with the available memory or CPU. + Alarm assertion failed at the beginning of the experiment. This error occurs because the related alarm has no datapoint. + **Failure message:** `Assertion failed for the following alarms`. Lists all the alarms for which the assertion has failed. + **Remediation:** Ensure that Container Insights are correctly installed for the alarms and the alarm is not turned on (in `ALARM` state). # Understanding resiliency scores This section describes how AWS Resilience Hub quantifies application readiness from different disruption scenarios. AWS Resilience Hub provides resiliency score that represents the resiliency posture of the application. This score reflects how closely the application follows our recommendations for meeting the application's resiliency policy, alarms, standard operating procedures (SOPs), and tests. Based on the type of resources the application uses, AWS Resilience Hub recommends alarms, SOPs, and a set of tests for each disruption type. The top resiliency score is 100 points. To achieve the best possible score or the top score, you must implement all the recommended alarms, SOPs, and tests in your application. For example, AWS Resilience Hub recommends one test with one alarm and one SOP. The test runs and fires the alarm and initiates the associated SOP. If they perform successfully and if the application meets the resiliency policy, it receives a resiliency score close to or equal to 100 points. After running first assessment, AWS Resilience Hub provides an option to exclude operational recommendations from your application. To understand the impact of the excluded recommendations on the resiliency score, you must run a new assessment. However, you can always include the excluded recommendations in your application and run a new assessment. For more information about including and excluding alarm, SOP, and test recommendations, see [Including or excluding operational recommendations](exclude-recommend.md). # Accessing the Resiliency score of your applications You can view the Resiliency score of your application by choosing **Dashboard** or **Applications** from the navigation menu. **Accessing the Resiliency score from Dashboard** 1. In the left navigation menu, choose **Dashboard**. 1. In **Application resiliency score over time**, choose one or more applications in the **Choose up to 4 applications** dropdown list. 1. The **Resiliency score** chart displays the resiliency score for all the chosen applications. **Accessing the Resiliency score from Applications** 1. In the left navigation menu, choose **Applications**. 1. In **Applications**, open an application. 1. Choose **Summary**. The **Resiliency score** chart displays the trend of your application's resiliency score for up to one year. AWS Resilience Hub displays action items, resiliency policy breaches, and operational recommendations that need to be addressed for improving and achieving the maximum possible resiliency score using the following: + To view the action items that need to be completed for improving and achieving the maximum possible resiliency score, choose **Action items** tab. When selected, AWS Resilience Hub displays the following: + **RTO/RPO** – Indicates the number of recovery times (RTO/RPOs) that need to be fixed to resolve the breaches in your application's resiliency policy. Choose the value to view the RTO/RPO details in the assessment report of your application. + **Alarms** – Indicates the number of recommended Amazon CloudWatch alarms that need to be implemented in your application. Choose the value to view the Amazon CloudWatch alarms that need to be fixed in the assessment report of your application. + **SOPs** – Indicates the number of recommended SOPs that need to be implemented in your application. Choose the value to view the SOPs that need to be fixed in the assessment report of your application. + **FIS ** – Indicates the number of recommended tests that need to be implemented in your application. Choose the value to view the tests that need to be fixed in the assessment report of your application. + To view the score of each component that affects your resiliency score, choose **Score breakdown**. When selected, AWS Resilience Hub displays the following: + **RTO/RPO compliance** – Indicates how compliant the Applications Components (AppComponents) are with the estimated workload recovery times, and the target recovery times that are defined in your application’s resiliency policy. Choose the value to view the RTO/RPO estimations in the assessment report of your application. + **Alarms implemented** – Indicates the actual contribution of the implemented Amazon CloudWatch alarms compared to its maximum possible contribution towards the resiliency score of your application. Choose the value to view the implemented Amazon CloudWatch alarms in the assessment report of your application. + **SOPs implemented** – Indicates the actual contribution of the implemented SOPs compared to its maximum possible contribution towards the resiliency score of your application. Choose the value to view the implemented SOPs in the assessment report of your application. + **FIS experiments implemented** – Indicates the actual contribution of the implemented tests compared to its maximum possible contribution towards the resiliency score of your application. Choose the value to view the implemented tests in the assessment report of your application. + To view the resiliency policy breaches and operational recommendations, choose the right arrow to expand the **Policy breach and operational recommendations breakdown** section. When expanded, AWS Resilience Hub displays the following: + **Resiliency policy breaches** – Indicates the number of Application Components that breaches your application's resiliency policy. Choose the value next to **RTO/RPO** to view the details in the **Resiliency recommendations** tab of your application's assessment report. + **Operational recommendations** – Indicates the operational recommendations that have not been implemented or executed to enhance the resiliency of your application using **Outstanding** and **Excluded** tabs. Operational recommendations include all the recommendations that are inactive and the ones that have not been implemented. To view the operational recommendations that need to be implemented, choose **Outstanding** tab. When selected, AWS Resilience Hub displays the following: + **Alarms** – Indicates the number of recommended Amazon CloudWatch alarms that need to be implemented. + **SOPs** – Indicates the number of recommended SOPs that need to be implemented. + **FIS** – Indicates the number of recommended tests that need to be implemented. To view the operational recommendations that are excluded from your application, choose **Excluded** tab. When selected AWS Resilience Hub displays the following: + **Alarms** – Indicates the number of recommended Amazon CloudWatch alarms that are excluded from your application. + **SOPs** – Indicates the number of recommended SOPs that are excluded from your application. + **FIS** – Indicates the number of recommended tests that are excluded from your application. # Calculating resiliency scores The tables in this section explains the formulas used by AWS Resilience Hub to determine the scoring components of each recommendation type and the resiliency score of your application. All the resultant values determined by AWS Resilience Hub for scoring components of each recommendation type and the resiliency score of your application are rounded to their nearest point. For example, if two out of three alarms were implemented, the score would be 13.33 ((2/3) \$1 20) points. This value will be rounded to 13 points. For more information about weights used in the formulas within the tables, see [Weights](#weight) section. Some of the scoring components can be obtained only through the `ScoringComponentResiliencyScore` API. For more information about this API, see [ScoringComponentResiliencyScore](https://docs.aws.amazon.com/resilience-hub/latest/APIReference/API_ScoringComponentResiliencyScore.html). **Tables** + [**Formulas to calculate the scoring component of each recommendation type**](#recommendation-type-coverage) + [**Formula to calculate the resiliency score**](#resiliency-score) + [**Formulas to calculate resiliency score for AppComponents and disruption types**](#resiliency-score-AppComponents-disruption-types) The following table explains the formulas used by AWS Resilience Hub to calculate the scoring component of each recommendation type. **Formulas to calculate the scoring component of each recommendation type** | Scoring component | Description | Formula | Example | | --- | --- | --- | --- | | Test coverage (T) | A normalized score (0 -100 points) based on the number of tests that were successfully implemented and excluded, out of the total number of AWS Resilience Hub recommended tests. To calculate the resiliency score, the recommended tests must have run successfully in the last 30 days for AWS Resilience Hub to consider it as implemented. | T = ((Total number of tests implemented) \$1 (Total number of tests excluded)) / (Total number of tests recommended)Parts of the formula are as follows:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/resilience-hub/latest/userguide/calculate-score.html) | If you have implemented 10 and excluded 5 tests out of 20 AWS Resilience Hub recommended tests, the test coverage is calculated as follows:`T = (10 + 5) / 20`That is, `T = .75 or 75 points` | | Alarms coverage (A) | A normalized score (0 -100 points) based on the number of Amazon CloudWatch alarms that were successfully implemented and excluded, out of the total number of AWS Resilience Hub recommended Amazon CloudWatch alarms. To calculate the resiliency score, the recommended alarms should be in **Ready** state for AWS Resilience Hub to consider it as implemented. | A = ((Total number of alarms implemented) \$1 (Total number of alarms excluded)) / (Total number of alarms recommended)Parts of the formula are as follows:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/resilience-hub/latest/userguide/calculate-score.html) | If you have implemented 10 and excluded 5 Amazon CloudWatch alarms out of 20 AWS Resilience Hub recommended Amazon CloudWatch alarms, the Amazon CloudWatch alarms coverage is calculated as follows:`A = (10 + 5) / 20`That is, `A = .75 or 75 points` | | SOP coverage (S) | A normalized score (0 -100 points) based on the number of SOPs that were successfully implemented and excluded, out of the total number of AWS Resilience Hub recommended SOPs. | S = ((Total number of SOPs implemented) \$1 (Total number of SOPs excluded)) / (Total number of SOPs recommended)Parts of the formula are as follows:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/resilience-hub/latest/userguide/calculate-score.html) | If you have implemented 10 and excluded 5 SOPs out of 20 AWS Resilience Hub recommended SOPs, the SOP coverage is calculated as follows:`S = (10 + 5) / 20`That is, `S = .75 or 75 points` | | RTO/RPO compliance (P) | A normalized score (0 -100 points) based on the application meeting its resiliency policy. | P = Total weights of disruption types meeting the application's resiliency policy / Total weights of all disruption types. | If you application resiliency policy meets only for Availability Zone (AZ) and Infrastructure disruption types, the resiliency policy score (P) is calculated as follows:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/resilience-hub/latest/userguide/calculate-score.html) | The following table explains the formula used by AWS Resilience Hub to calculate the resiliency score for your entire application. **Formula to calculate the Resiliency score** | Scoring component | Description | Formula | Example | | --- | --- | --- | --- | | Resiliency score for application (RS) | A normalized resiliency score (0 -100 points) based on your application meeting its resiliency policy. Resiliency score per application is the weighted average of all the recommendation types. That is: RS = Weighted Average (T, A, S, P) | Resiliency score per application is calculated using the following formula: RS = (T \$1 Weight(T) \$1`A * Weight(A) +``S * Weight(S) +``P * Weight(P)) /``(Weight(T) + Weight(A) + Weight(S) + Weight(P))` | Formulas to calculate the coverage of each recommendation type table are as follows: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/resilience-hub/latest/userguide/calculate-score.html)The resiliency score per application is calculated as follows: `RS = ((.75 * .2) + (.75 * .2) + (.75 * .2) + (.5 * .4)) /(.2 + .2 + .2 + .4)`That is, `RS = .65 or 65 points` | The following table explains the formulas used by AWS Resilience Hub to calculate the resiliency score for Application Components (AppComponents) and disruption types. However, you can obtain the resiliency score of AppComponents and disruption types only through the following AWS Resilience Hub APIs: + [DescribeAppAssessment](https://docs.aws.amazon.com/resilience-hub/latest/APIReference/API_DescribeAppAssessment.html) to obtain `RSo` + [ListAppComponentCompliances](https://docs.aws.amazon.com/resilience-hub/latest/APIReference/API_ListAppComponentCompliances.html) to obtain `RSao` and `RSA` **Formulas to calculate resiliency score for AppComponents and disruption types** | Scoring component | Description | Formula | Example | | --- | --- | --- | --- | | Resiliency score per AppComponent and per disruption type (RSao) | A normalized score (0 -100 points) based on the AppComponent meeting its resiliency policy per disruption type. Resiliency score per AppComponent and per disruption type is the weighted average of all the recommendation types. That is: `RSao = Weighted Average (T, A, S, P)`The values for `T, A, S, P` are calculated for all the recommended tests, alarms, SOPs, and meeting resiliency policy of the AppComponent and the disruption type. | The resiliency score per AppComponent and per disruption type is calculated using the following formula:`RSao = (T * Weight(T) + ``A * Weight(A) + ``S * Weight(S) + ``P * Weight(P)) /``(Weight(T) + Weight(A) + Weight(S) + Weight(P))` | `RSao` assumptions for all the recommendation types are as follows:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/resilience-hub/latest/userguide/calculate-score.html)The resiliency score per AppComponent and disruption type is calculated as follows:`RSao = ((.75 * .2) + (.75 * .2) + (.75 * .2) + (.5 * .4)) / `(.2 \$1 .2 \$1 .2 \$1 .4)That is, `RSao = .65 or 65 points` | | Resiliency score per AppComponent ( RSa) | A normalized score (0 -100 points) based on meeting its resiliency policy. Resiliency score per AppComponent is the weighted average of all the recommendation types. That is: RSa = Weighted Average (T, A, S, P)The values for `T, A, S, P` are calculated for all the recommended tests, alarms, SOPs, and meeting resiliency policy of the AppComponent. | The resiliency score per AppComponent is calculated using the following formula: `RSa = ``(T * Weight(T) +``A * Weight(A) +``S * Weight(S) +``P * Weight(P)) /``(Weight(T) + Weight(A) + Weight(S) + Weight(P))` | `RSa` assumptions for all the recommendation types are as follows:[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/resilience-hub/latest/userguide/calculate-score.html)The resiliency score per AppComponent is calculated as follows:`RSa = ((.75 * .2) + (.75 * .2) + (.75 * .2) + (.5 * .4)) / `(.2 \$1 .2 \$1 .2 \$1 .4)That is, `RSa = .65 or 65 points` | | Resiliency score per disruption type ( RSo) | A normalized score (0 -100 points) based on meeting its resiliency policy. Resiliency score per disruption type is the weighted average of all the recommendation types. That is: RSo = Weighted Average (T, A, S, P)The values for `T, A, S, P` are calculated for all the recommended tests, alarms, SOPs, and meeting resiliency policy of the disruption type. | The resiliency score per disruption type is calculated using the following formula:`RSo = (T * Weight(T) + A * Weight(A) + ``S * Weight(S) + P * Weight(P)) /` `(Weight(T) + Weight(A) + Weight(S) + Weight(P))` | `RSo` assumptions for all the recommendation types are as follows: [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/resilience-hub/latest/userguide/calculate-score.html) The resiliency score per disruption type is calculated as follows: `RSo = ((.75 * .2) + (.75 * .2) + (.75 * .2) + (.5 *.4)) /` `(.2 + .2 + .2 + .4)` That is, `RSo = .65 or 65 points` | ## Weights Weights of AppComponents and disruption types AWS Resilience Hub assigns a weight to each recommendation type for the total resiliency score. The following tables show the weight for alarms, SOPs, tests, meeting resiliency policy, and disruption types. Disruptions type include Application, Infrastructure, AZ, and Region. **Note** If you choose not to define Regional RTO or RPO targets for your policy, the weights for the other disruption types are increased accordingly as shown in **Weight when Region is not defined** column. **Weights for alarms, SOPs, tests, policy target** | Recommendation type | Weight | | --- | --- | | Alarms | 20 points | | SOPs | 20 points | | Tests | 20 points | | Meeting resiliency policy | 40 points | **Weights for disruption type** | Disruption type | Weight when Region is defined | Weight when Region is not defined | | --- | --- | --- | | Application | 40 points | 44.44 points | | Infrastructure | 30 points | 33.33 points | | Availability Zone | 20 points | 22.22 points | | Region | 10 points | N/A | # Integrating operational recommendations into your application with CloudFormation Integrating recommendations into applications After you choose **Create CloudFormation template** in the **Operational recommendations** page, AWS Resilience Hub creates an CloudFormation template that describes the specific alarm, standard operating procedure (SOP), or AWS FIS experiment for your application. The CloudFormation template is stored in an Amazon S3 bucket, and you can check the S3 path to the template in the **Template details** tab on the **Operational recommendations** page. For example, the listing below shows a JSON-formatted CloudFormation template that describes an alarm recommendation rendered by AWS Resilience Hub. It's a Read Throttling Alarm for a DynamoDB table called `Employees`. The `Resources` section of the template describes the `AWS::CloudWatch::Alarm` alarm that's activated when the number of read throttle events for the DynamoDB table exceeds 1. And the two `AWS::SSM::Parameter` resources define metadata that allow AWS Resilience Hub to identify installed resources without having to scan the actual application. ``` { "AWSTemplateFormatVersion" : "2010-09-09", "Parameters" : { "SNSTopicARN" : { "Type" : "String", "Description" : "The ARN of the Amazon SNS topic to which alarm status changes are to be sent. This must be in the same Region being deployed.", "AllowedPattern" : "^arn:(aws|aws-cn|aws-iso|aws-iso-[a-z]{1}|aws-us-gov):sns:([a-z]{2}-((iso[a-z]{0,1}-)|(gov-)){0,1}[a-z]+-[0-9]):[0-9]{12}:[A-Za-z0-9/][A-Za-z0-9:_/+=,@.-]{1,256}$" } }, "Resources" : { "ReadthrottleeventsthresholdexceededEmployeesONDEMAND0DynamoDBTablePXBZQYH3DCJ9Alarm" : { "Type" : "AWS::CloudWatch::Alarm", "Properties" : { "AlarmDescription" : "An Alarm by AWS Resilience Hub that alerts when the number of read-throttle events are greater than 1.", "AlarmName" : "ResilienceHub-ReadThrottleEventsAlarm-2020-04-01_Employees-ON-DEMAND-0-DynamoDBTable-PXBZQYH3DCJ9", "AlarmActions" : [ { "Ref" : "SNSTopicARN" } ], "MetricName" : "ReadThrottleEvents", "Namespace" : "AWS/DynamoDB", "Statistic" : "Sum", "Dimensions" : [ { "Name" : "TableName", "Value" : "Employees-ON-DEMAND-0-DynamoDBTable-PXBZQYH3DCJ9" } ], "Period" : 60, "EvaluationPeriods" : 1, "DatapointsToAlarm" : 1, "Threshold" : 1, "ComparisonOperator" : "GreaterThanOrEqualToThreshold", "TreatMissingData" : "notBreaching", "Unit" : "Count" }, "Metadata" : { "AWS::ResilienceHub::Monitoring" : { "recommendationId" : "dynamodb:alarm:health-read_throttle_events:2020-04-01" } } }, "dynamodbalarmhealthreadthrottleevents20200401EmployeesONDEMAND0DynamoDBTablePXBZQYH3DCJ9AlarmSSMParameter" : { "Type" : "AWS::SSM::Parameter", "Properties" : { "Name" : "/ResilienceHub/Alarm/3f904525-4bfa-430f-96ef-58ec9b19aa73/dynamodb-alarm-health-read-throttle-events-2020-04-01_Employees-ON-DEMAND-0-DynamoDBTable-PXBZQYH3DCJ9", "Type" : "String", "Value" : { "Fn::Sub" : "${ReadthrottleeventsthresholdexceededEmployeesONDEMAND0DynamoDBTablePXBZQYH3DCJ9Alarm}" }, "Description" : "SSM Parameter for identifying installed resources." } }, "dynamodbalarmhealthreadthrottleevents20200401EmployeesONDEMAND0DynamoDBTablePXBZQYH3DCJ9AlarmInfoSSMParameter" : { "Type" : "AWS::SSM::Parameter", "Properties" : { "Name" : "/ResilienceHub/Info/Alarm/3f904525-4bfa-430f-96ef-58ec9b19aa73/dynamodb-alarm-health-read-throttle-events-2020-04-01_Employees-ON-DEMAND-0-DynamoDBTable-PXBZQYH3DCJ9", "Type" : "String", "Value" : { "Fn::Sub" : "{\"alarmName\":\"${ReadthrottleeventsthresholdexceededEmployeesONDEMAND0DynamoDBTablePXBZQYH3DCJ9Alarm}\",\"referenceId\":\"dynamodb:alarm:health_read_throttle_events:2020-04-01\",\"resourceId\":\"Employees-ON-DEMAND-0-DynamoDBTable-PXBZQYH3DCJ9\",\"relatedSOPs\":[\"dynamodb:sop:update_provisioned_capacity:2020-04-01\"]}" }, "Description" : "SSM Parameter for identifying installed resources." } } } } ``` ## Modifying the CloudFormation template The easiest way to integrate an alarm, SOP, or AWS FIS resource into your main application is to simply add it as another resource in the template that describes your application template. The JSON-formatted file provided below provides a basic outline of how a DynamoDB table is described in an CloudFormation template. A real application is likely to include several more resources, such as additional tables. ``` { "AWSTemplateFormatVersion": "2010-09-09T00:00:00.000Z", "Description": "Application Stack with Employees Table", "Outputs": { "DynamoDBTable": { "Description": "The DynamoDB Table Name", "Value": {"Ref": "Employees"} } }, "Resources": { "Employees": { "Type": "AWS::DynamoDB::Table", "Properties": { "BillingMode": "PAY_PER_REQUEST", "AttributeDefinitions": [ { "AttributeName": "USER_ID", "AttributeType": "S" }, { "AttributeName": "RANGE_ATTRIBUTE", "AttributeType": "S" } ], "KeySchema": [ { "AttributeName": "USER_ID", "KeyType": "HASH" }, { "AttributeName": "RANGE_ATTRIBUTE", "KeyType": "RANGE" } ], "PointInTimeRecoverySpecification": { "PointInTimeRecoveryEnabled": true }, "Tags": [ { "Key": "Key", "Value": "Value" } ], "LocalSecondaryIndexes": [ { "IndexName": "resiliencehub-index-local-1", "KeySchema": [ { "AttributeName": "USER_ID", "KeyType": "HASH" }, { "AttributeName": "RANGE_ATTRIBUTE", "KeyType": "RANGE" } ], "Projection": { "ProjectionType": "ALL" } } ], "GlobalSecondaryIndexes": [ { "IndexName": "resiliencehub-index-1", "KeySchema": [ { "AttributeName": "USER_ID", "KeyType": "HASH" } ], "Projection": { "ProjectionType": "ALL" } } ] } } } } ``` To allow the alarm resource to be deployed with your application, you now need to replace the hardcoded resources with a dynamic reference in the application stacks. So, in the `AWS::CloudWatch::Alarm` resource definition, change the following: ``` "Value" : "Employees-ON-DEMAND-0-DynamoDBTable-PXBZQYH3DCJ9" ``` to the below: ``` "Value" : {"Ref": "Employees"} ``` And under in the `AWS::SSM::Parameter` resource definition, change the following: ``` "Fn::Sub" : "{\"alarmName\":\"${ReadthrottleeventsthresholdexceededDynamoDBEmployeesONDEMAND0DynamoDBTablePXBZQYH3DCJ9Alarm}\",\"referenceId\":\"dynamodb:alarm:health_read_throttle_events:2020-04-01\",\"resourceId\":\"Employees-ON-DEMAND-0-DynamoDBTable-PXBZQYH3DCJ9\",\"relatedSOPs\":[\"dynamodb:sop:update_provisioned_capacity:2020-04-01\"]}" ``` to the below: ``` "Fn::Sub" : "{\"alarmName\":\"${ReadthrottleeventsthresholdexceededEmployeesONDEMAND0DynamoDBTablePXBZQYH3DCJ9Alarm}\",\"referenceId\":\"dynamodb:alarm:health_read_throttle_events:2020-04-01\",\"resourceId\":\"${Employees}\",\"relatedSOPs\":[\"dynamodb:sop:update_provisioned_capacity:2020-04-01\"]}" ``` When modifying CloudFormation templates for SOPs and AWS FIS experiments, you will take the same approach, replacing hardcoded reference IDs with dynamic references that continue to work even after hardware changes. By using a reference to the DynamoDB table, you allow CloudFormation to do the following: + Create the database table first. + Always use the actual ID of the generated resource in the alarm, and update the alarm dynamically if CloudFormation needs to replace the resource. **Note** You can choose more advanced methods for managing your application resources with CloudFormation such as [nesting stacks](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/resource-import-nested-stacks.html) or [referring to resource outputs in a separate CloudFormation stack](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/walkthrough-crossstackref.html). (But if you want to keep the recommendation stack separate from the main stack, you need to configure a way to pass information between the two stacks.) In addition, third-party tools, such as Terraform by HashiCorp, can also be used to provision Infrastructure as Code (IaC).