• The AWS Systems Manager CloudWatch Dashboard will no longer be available after April 30, 2026. Customers can continue to use Amazon CloudWatch console to view, create, and manage their Amazon CloudWatch dashboards, just as they do today. For more information, see [Amazon CloudWatch Dashboard documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html).
# Diagnosing and remediating
Using the unified Systems Manager console, you can identify problems across your fleet in a single diagnosis operation. For organizations, you can then attempt remediation on all or only select targets using a single Automation operation. For an organization, as a delegated account administrator, you can select targets across all accounts and Regions. If you are working in a single account, you can select targets in a single Region at a time.
Systems Manager can diagnose and help you remediate several types of deployment failures, as well as drifted configurations. Systems Manager can also identify Amazon Elastic Compute Cloud (Amazon EC2) instances in your account or organization that Systems Manager isn't able to treat as a *managed node*. The EC2 instance diagnosis process can identify issues related to misconfigurations for a virtual private cloud (VPC), in a Domain Name Service (DNS) setting, or in an Amazon Elastic Compute Cloud (Amazon EC2) security group.
**Note**
Systems Manager supports both EC2 instances and other machine types in a [hybrid and multicloud](operating-systems-and-machine-types.md#supported-machine-types) environment as *managed nodes*. To be a managed node, AWS Systems Manager Agent (SSM Agent) must be installed on the machine, and Systems Manager must have permission to perform actions on the machine.
For EC2 instances, this permission can be provided at the account level using an AWS Identity and Access Management (IAM) role, or at the instance level using an instance profile. For more information, see [Configure instance permissions required for Systems Manager](setup-instance-permissions.md).
For non-EC2 machines, this permission is provided using an IAM service role. For more information, see [Create the IAM service role required for Systems Manager in hybrid and multicloud environments](hybrid-multicloud-service-role.md).
**Before you begin**
In order to use the **Diagnose and remediate** feature to detect unmanaged EC2 instances, you must first onboard your organization or account to the unified Systems Manager console. During this process, you must choose the option to create IAM roles and managed policies required for these operations. For more information, see [Setting up Systems Manager unified console for an organization](systems-manager-setting-up-organizations.md).
Use the following topics to help you identify and fix certain common types of failed deployments, drifted configurations, and unmanaged EC2 instances.
**Topics**
+ [
# Diagnosing and remediating failed deployments
](remediating-deployment-issues.md)
+ [
# Diagnosing and remediating drifted configurations
](remediating-configuration-drift.md)
+ [
# Diagnosing and remediating unmanaged Amazon EC2 instances in Systems Manager
](remediating-unmanaged-instances.md)
+ [
# Remediation impact types of runbook actions
](remediation-impact-type.md)
+ [
# Viewing execution progress and history for remediations in Systems Manager
](diagnose-and-remediate-execution-history.md)
# Diagnosing and remediating failed deployments
Systems Manager can diagnose and then help you remediate the following types of failed deployments:
+ Core setup for organization member accounts
+ Core setup for delegated administrator account
+ Core setup for your account
Use the following procedure to attempt to remediate these types of issues.
**To diagnose and remediate failed deployments**
1. Open the AWS Systems Manager console at [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. In the navigation pane, choose **Diagnose and remediate**.
1. Choose the **Deployment issues** tab.
1. In the **Failed deployments** section, review the list of findings for failed deployments.
1. In the **Setup step** column, choose the name of a finding to review additional details about the issue. For example: **Core setup for organization member accounts**.
1. In the detail page for that failed deployment, you can view a list of accounts and how many Regions in each have experienced deployment failures.
1. Select an account ID to view information about the reason for failures in that account.
1. In the **Failed Regions** area, examine the information provided for **Status reason**. This information can indicate a reason for the failed deployment, which might provide insight into configuration changes that need to be made.
1. If you want to retry the deployment without making configuration changes, choose **Redeploy**.
# Diagnosing and remediating drifted configurations
Systems Manager can diagnose and then help you remediate the following types of drifted configurations:
+ Core setup for organization member accounts
+ Core setup for delegated administrator account
+ Core setup for your account
Use the following procedure to attempt to remediate these types of drifted configurations.
**To diagnose and remediate drifted configurations**
1. Open the AWS Systems Manager console at [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. In the navigation pane, choose **Diagnose and remediate**.
1. Choose the **Deployment issues** tab.
1. In the **Drifted deployments** section, review the list of finding for failed deployments.
-or-
To run a new diagnosis, choose **Detect drift**.
1. In the **Setup step** column, choose the name of a finding to review additional details about the issue. For example: **Core setup for organization member accounts**.
1. In the detail page for that failed deployment, you can view a list of accounts and how many Regions in each have experienced configuration drifts.
1. Select an account ID to view information about the reason for configuration drifts in that account.
1. In the **Drifted resources** area, the **Resource** column reports names of resources that have experienced drift. The **Drift type** column reports whether the resource was modified or deleted..
1. To redeploy the intended configuration, choose **Redeploy**.
# Diagnosing and remediating unmanaged Amazon EC2 instances in Systems Manager
To help you manage your Amazon Elastic Compute Cloud (Amazon EC2) instances with Systems Manager, you can use the unified Systems Manager console to do the following:
1. Run a manual or scheduled diagnosis process to identify which EC2 instances in your account or organization aren't currently managed by Systems Manager.
1. Identify network or other issues that are preventing Systems Manager from taking over management of the instances.
1. Run an Automation execution to automatically remediate the problem, or access information to help you manually address the issue.
Use the information in the following topics to help you diagnose and remediate issues that are preventing Systems Manager from managing your EC2 instances.
## How Systems Manager counts impacted nodes for the 'Unmanaged EC2 instance issues' list
The number of nodes reported as unmanaged on the **Unmanaged EC2 instances issues** tab represents to the total number of instances with any of the follow status values at the diagnosis scan time:
+ `Running`
+ `Stopped`
+ `Stopping`
This number is reported as **Impacted nodes** in the **Issue summary** area. In the following image, this number of impacted nodes not currently managed by Systems Manager is `40`.
![\[The "Issue summary" area showing 40 impacted nodes in the Diagnose and remedidate page\]](http://docs.aws.amazon.com/systems-manager/latest/userguide/images/2-unmanaged-EC2-instance-count.png)
Unlike the report of unmanaged EC2 instances on the **Review node insights** page, this count of EC2 instances is not dynamic. It represents findings made during the last reported diagnostic scan, shown as the **Scan time** value. We therefore recommend running a diagnostic scan for unmanaged EC2 instances on a regular schedule to keep this reported number of impacted nodes up to date.
For information about unmanaged instance counts on the **Review node insights** page, see [What is an unmanaged instance?](review-node-insights.md#unmanaged-instance-definition) in the topic [Reviewing node insights](review-node-insights.md).
**Topics**
+ [
## How Systems Manager counts impacted nodes for the 'Unmanaged EC2 instance issues' list
](#unmanaged-instance-scan-count)
+ [
# Categories of diagnosable unmanaged EC2 instance issues
](diagnosing-ec2-category-types.md)
+ [
# Running a diagnosis and optional remediation for unmanaged EC2 instances
](running-diagnosis-execution-ec2.md)
+ [
# Scheduling a recurring scan for unmanaged EC2 instances
](schedule-recurring-ec2-diagnosis.md)
# Categories of diagnosable unmanaged EC2 instance issues
This topic lists the major categories of EC2 management issues, and the specific issues in each category, that Systems Manager can help you diagnose and remediate. Note that for some of the issues, Systems Manager can identify the issue, but not provide automatic remediation. In those cases, the Systems Manager console directs you to information to help you manually resolve an issue.
The diagnosis process examines each group of EC2 instances at once according to the virtual private cloud (VPC) they belong to.
**Topics**
+ [
## Problem category: Security group configuration and HTTPS communications
](#unmanaged-ec2-issue-security-groups)
+ [
## Problem category: DNS or DNS host name configuration
](#unmanaged-ec2-issue-dns-configuration)
+ [
## Problem category: VPC endpoint configuration
](#unmanaged-ec2-issue-vpc-endpoint-configuration)
+ [
## Problem category: Network ACL configuration
](#unmanaged-ec2-issue-nacl-configuration)
## Problem category: Security group configuration and HTTPS communications
A diagnosis operation might find that SSM Agent isn't able to communicate with the Systems Manager service over HTTPS. In those cases, you can choose to execute an Automation runbook that attempts to update security groups that are attached to the instances.
**Note**
Occasionally, Systems Manager might not be able to automatically remediate these issues, but you can manually edit the affected security groups.
**Supported issue types**
+ **Instance security group**: Outbound traffic is not allowed on port 443
+ **`ssm` VPC endpoint’s security group**: Inbound traffic is not allowed on port 443
+ **`ssmmessages` VPC endpoint's security group**: Inbound traffic not allowed on port 443
+ **`ec2messages` VPC endpoint's security group**: Inbound traffic not allowed on port 443
For more information, see [Verify ingress rules on endpoint security groups](troubleshooting-ssm-agent.md#agent-ts-ingress-egress-rules) in the topic [Troubleshooting SSM Agent](troubleshooting-ssm-agent.md).
## Problem category: DNS or DNS host name configuration
A diagnosis operation might find that Doman Name System (DNS) or DNS host names aren't properly configured for the VPC. In those cases, you can choose to execute an Automation runbook that attempts to enable the `enableDnsSupport` and `enableDnsHostnames` attributes of the affected VPC.
**Supported issue types**
+ DNS support is disabled in a VPC.
+ A DNS hostname is disabled in a VPC.
For more information, see [Verify your VPC DNS-related attributes](troubleshooting-ssm-agent.md#agent-ts-dns-attributes) in the topic [Troubleshooting SSM Agent](troubleshooting-ssm-agent.md).
## Problem category: VPC endpoint configuration
A diagnosis operation might find that VPC endpoints aren't properly configured for the VPC.
If VPC endpoints required by SSM Agent don't exist, Systems Manager attempts to execute an Automation runbook to create the VPC endpoints and associates them with one subnet in each relevant regional availability zone (AZ). If VPC the required endpoints exist but aren't associated with a subnet in which the issue is found, the runbook associates the VPC endpoints to the affected subnet.
**Note**
Systems Manager doesn't support remediating all misconfigured VPC endpoint issues. In those cases, Systems Manager directs you to manual remedy instructions instead of running an Automation runbook.
**Supported issue types**
+ No `ssm.region.amazonaws.com` endpoint for PrivateLink was found.
+ No `ssmmessages.region.amazonaws.com` endpoint for PrivateLink was found.
+ No `ec2messages.region.amazonaws.com` endpoint for PrivateLink was found.
**Diagnosable issue types**
Systems Manager can diagnose the following issue types, but currently no runbook is available for remediating their issues. You can edit your configuration manually for these issues.
+ An instance's subnet is not attached to an `ssm.region.amazonaws.com` endpoint.
+ An instance's subnet is not attached to an `ssmmessages.region.amazonaws.com` endpoint.
+ An instance's subnet not attached to an `ec2messages.region.amazonaws.com` endpoint.
For more information, see [Verify your VPC configuration](troubleshooting-ssm-agent.md#agent-ts-vpc-configuration) in the topic [Troubleshooting SSM Agent](troubleshooting-ssm-agent.md).
## Problem category: Network ACL configuration
A diagnosis operation might find that network access control lists (NACLs) aren't properly configured for the VPC, blocking necessary traffic for Systems Manager communication. NACLs are stateless, so both outbound and inbound rules must permit Systems Manager traffic.
Systems Manager can identify NACL configuration issues and provide guidance for manual remediation.
**Supported issue types**
+ **Instance subnet NACL**: Outbound traffic is not allowed on port 443 to Systems Manager endpoints
+ **Instance subnet NACL**: Inbound traffic is not allowed on ephemeral ports (1024-65535) for Systems Manager responses
**Diagnosable issue types**
Systems Manager can diagnose the following NACL configuration issues, but manual remediation is required:
+ An instance's subnet NACL blocks outbound HTTPS (port 443) traffic to Systems Manager endpoints
+ An instance's subnet NACL blocks inbound ephemeral port traffic (1024-65535) required for Systems Manager responses
For more information, see [Troubleshooting SSM Agent](https://docs.aws.amazon.com/systems-manager/latest/userguide/troubleshooting-ssm-agent.html), and [Custom network ACLs for your VPC](https://docs.aws.amazon.com/vpc/latest/userguide/custom-network-acl.html#nacl-ephemeral-ports).
# Running a diagnosis and optional remediation for unmanaged EC2 instances
Use the following procedure to diagnose the network-related and VPC-related issues that might be preventing Systems Manager from managing your EC2 instances.
The diagnosis operation can detect and group together issues of the following types:
+ **Network configurations issues** – Types of networking issues that might be preventing EC2 instances from communicating with the Systems Manager service in the cloud. Remediation operations might be available for these issues. For more information about the network configuration issues, see [Categories of diagnosable unmanaged EC2 instance issues](diagnosing-ec2-category-types.md).
+ **Unidentified issues** – A list of findings for cases where the diagnostic operation was unable to determine why EC2 instances are not able to communicate with the Systems Manager service in the cloud.
**To run a diagnosis and remediation for unmanaged EC2 instances**
1. Open the AWS Systems Manager console at [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. In the navigation pane, choose **Diagnose and remediate**.
1. Choose the **Unmanaged EC2 instances issue** tab.
1. In the **Issue summary **section, choose **Run new diagnosis**.
-or-
If this is your first time to diagnose unmanaged EC2 issues, in the **Diagnose unmanaged EC2 instances** section, choose **Execute**.
**Tip**
While the diagnosis is running, choose **View progress** or **View executions** to monitor the current state of the execution. For more information, see [Viewing execution progress and history for remediations in Systems Manager](diagnose-and-remediate-execution-history.md).
1. After the diagnosis completes, do the following:
+ For any issues reported in the **Unidentified issues** section, choose the **Learn more** link for information about resolving the problem.
+ For issues reported in the **Network configurations issues** section, continue with the next step.
1. In the list of finding types, in the **Recommendations** column, for a particular issue, choose the link, such as **2 recommendations**.
1. In the **Recommendations** pane that opens, choose from the available mitigations:
+ **Learn more** – Open a topic with information about how to resolve an issue manually.
+ **View runbook** – Open a pane with information about the Automation runbook you can execute to resolve the issue with your EC2 instances, as well as options for generating a *preview* of the actions that runbook would take. Continue with the next step.
1. In the runbook pane, do the following:
1. For **Document description**, review the content, which provides an overview of the actions the runbook can take to remediate your unmanaged EC2 instance issues. Choose **View steps** to preview the individual actions the runbook would take.
1. For **Targets**, do the following:
+ If you are managing remediations for an organization, for **Accounts**, specify whether this runbook would target all accounts, or only a subset of accounts you choose.
+ For **Regions**, specify whether this runbook would target all AWS Regions in your account or organization, or only a subset of Regions you choose.
1. For **Runbook preview**, carefully review the information. This information explains what the scope and impact would be if you choose to execute the runbook.
**Note**
Choosing to execute the runbook would incur charges. Review the preview information carefully before deciding whether to proceed.
The **Runbook preview** content provides the following information:
+ How many Regions the runbook operation would occur in.
+ (Organizations only) How many organizational units (OUs) the operation would run in.
+ The types of actions that would be taken, and how many of each.
Action types include the following:
+ **Mutating**: The runbook step would make changes to the targets through actions that create, modify, or delete resources.
+ **Non-mutating**: The runbook step would retrieve data about resources but not make changes to them. This category generally includes `Describe*`, `List*`, `Get*`, and similar read-only API actions.
+ **Undetermined**: An undetermined step invokes executions performed by another orchestration service like AWS Lambda, AWS Step Functions, or AWS Systems Manager Run Command. An undetermined step might also call a third-party API. Systems Manager Automation doesn’t know the outcome of the orchestration processes or third-party API executions, so the results of the steps are undetermined.
1. At this point, you can choose one of the following actions:
+ Stop and do not execute the runbook.
+ Choose **Execute** to run the runbook with the options you have already selected.
If you choose to run the operation, choose **View progress** or **View executions** to monitor the current state of the execution. For more information, see [Viewing execution progress and history for remediations in Systems Manager](diagnose-and-remediate-execution-history.md).
# Scheduling a recurring scan for unmanaged EC2 instances
You can run an on-demand scan for Amazon EC2 instances in your account or organization that Systems Manager isn't able to manage due to various configuration issues. You can also schedule this scan to occur automatically on a regular schedule.
**To schedule a recurring scan for unmanaged EC2 instances**
1. Open the AWS Systems Manager console at [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. In the navigation pane, choose **Diagnose and remediate**.
1. Choose the **Unmanaged EC2 instances issue** tab.
1. In the **Diagnose unmanaged EC2 instances** section, turn on **Schedule recurring diagnosis**.
1. For **Diagnostic frequency**, select whether to run the diagnosis once a day or once a week.
1. (Optional) For **Start time**, enter a time, in 24-hour format, for the diagnosis to begin. For example, for 8:15 PM, enter **20:15**.
The time you enter is for your current local time zone.
If you don't specify a time, the diagnostic scan runs immediately. Systems Manager also schedules the scan to run in the future at the current time. If you specify a time, Systems Manager waits to run the diagnostic scan at the specified time.
1. Choose **Execute**. The diagnosis runs immediately, but will also run on the schedule you have specified.
# Remediation impact types of runbook actions
Systems Manager can run diagnosis operations that discover certain types of failed deployments and drifted configurations, as well as certain types of configuration issues that are preventing Systems Manager from managing EC2 instances. The results of the diagnosis might include recommendations for Automation runbooks that you can execute to attempt to remedy a problem. For more information about these diagnosis operations, see the following topics:
+ [Diagnosing and remediating failed deployments](remediating-deployment-issues.md)
+ [Diagnosing and remediating drifted configurations](remediating-configuration-drift.md)
+ [Diagnosing and remediating unmanaged Amazon EC2 instances in Systems Manager](remediating-unmanaged-instances.md)
When Systems Manager identifies an issue that might be fixed by running an Automation runbook on the affected resources, it provides you with an *execution preview*. The execution preview provides information about the *types* of changes the runbook execution would make to your targets. This information includes how many of each of three types of changes the diagnosis identified.
These change types are as follows:
+ `Mutating`: A runbook step would make changes to the targets through actions that create, modify, or delete resources.
+ `Non-Mutating`: A runbook step would retrieve data about resources but not make changes to them. This category generally includes `Describe*`, `List*`, `Get*`, and similar read-only API actions.
+ `Undetermined`: An undetermined step invokes executions performed by another orchestration service like AWS Lambda, AWS Step Functions, or Run Command, a tool in AWS Systems Manager. An undetermined step might also call a third-party API or run a Python or PowerShell script. Systems Manager Automation can't detect what the outcome would be of the orchestration processes or third-party API executions, and therefore can't evaluate them. The results of those steps would have to be manually reviewed to determine their impact.
See the following table for information about the impact type of supported Automation actions.
## Impact types of supported remediation actions
The table presents the impact type—Mutating, Non-mutating, and Undetermined—of various actions that can be included in a remediation runbook.
| Action¹ | Impact type |
| --- | --- |
| aws:approve | Non-mutating |
| aws:assertAwsResourceProperty | Non-mutating |
| aws:branch | Non-mutating |
| aws:changeInstanceState | Mutating |
| aws:copyImage | Mutating |
| aws:createImage | Mutating |
| aws:createStack | Mutating |
| aws:createTags | Mutating |
| aws:deleteImage | Mutating |
| aws:deleteStack | Mutating |
| aws:executeAutomation | Undetermined |
| aws:executeAwsApi | Undetermined |
| aws:executeScript | Undetermined |
| aws:executeStateMachine | Undetermined |
| aws:invokeLambdaFunction | Undetermined |
| aws:invokeWebhook | Undetermined |
| aws:loop | Varies. Depends on the actions in the loop. |
| aws:pause | Non-mutating |
| aws:runCommand | Undetermined |
| aws:runInstances | Mutating |
| aws:sleep | Non-mutating |
| aws:updateVariable | Mutating |
| aws:waitForAwsResourceProperty | Non-mutating |
¹ For more information about Automation actions, see [Systems Manager Automation actions reference](automation-actions.md).
# Viewing execution progress and history for remediations in Systems Manager
You can view a list of all in-progress and completed remediation operations made using the **Diagnose and remediate** feature in Systems Manager.
Data in the execution history list reports the following types of information:
+ The type of execution, `Diagnosis` or `Remediation`.
+ The execution status, such as `Success` or `Failed`.
+ The times that the execution started and ended.
**To view execution progress and history for remediations**
1. Open the AWS Systems Manager console at [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/).
1. In the navigation pane, choose **Diagnose and remediate**.
1. Choose **View executions**.
**Tip**
When an execution is running, you can also choose **View progress** to open the **Execution history** page.
1. (Optional) In the search (![\[The search icon\]](http://docs.aws.amazon.com/systems-manager/latest/userguide/images/search-icon.png)) box, enter a phrase to help narrow down the execution list, such as **EC2** or **VPC**.
1. (Optional) To view additional details about an execution, in the **Execution name** column, choose an operation name, such as **AWS-DiagnoseUnmanagedEC2NetworkIssues**.
In the details pane, you can review information about all the steps attempted during the operation, and about all the inputs and outputs for the execution.