About patch compliance status values - AWS Systems Manager

About patch compliance status values

After you use Systems Manager Patch Manager to install patches on your instances, compliance status information is immediately available to you in the console or in response to AWS CLI commands or corresponding Systems Manager API actions.

Note

If you want to assign a specific patch compliance status to an instance, you can use the put-compliance-items CLI command or the PutComplianceItems API action. Assigning compliance status is not supported in the console.

In the console, you can view patch compliance data in the following Systems Manager capabilities:

Using the AWS CLI, you can view summary information about patches on an instance by running commands such as the following:

Patch compliance values for Debian and Ubuntu Server

For Debian and Ubuntu Server, the rules for package classification into the different compliance states are described in the following table.

Patch status Description Compliance status
Installed

The patch is listed in the patch baseline and is installed on the instance. It could have been installed either manually by an individual or automatically by Patch Manager when the AWS-RunPatchBaseline document was run on the instance.

Note

If you do not select the Include nonsecurity updates check box when creating or updating a patch baseline, patch candidate versions are limited to patches included in trusty-security (Ubuntu Server 14), xenial-security (Ubuntu Server 16), bionic-security (Ubuntu Server 18), or debian-security (Debian Stretch or Jessie) and are not upgradable). If you do select the Include nonsecurity updates check box, patches from other repositories are considered as well.

Compliant
Installed Other

The patch is not included in the baseline or is not approved by the baseline but is installed on the instance. The patch might have been installed manually, the package could be a required dependency of another approved patch, or the patch might have been included in an InstallOverrideList operation. If you do not specify Block as the Rejected patches action, Installed_Other patches also includes installed but rejected patches.

Note

If you do not select the Include nonsecurity updates check box when creating or updating a patch baseline, patch candidate versions are limited to patches included in trusty-security (Ubuntu Server 14), xenial-security (Ubuntu Server 16), bionic-security (Ubuntu Server 18), or debian-security (Debian Stretch or Jessie) and are not upgradable). If you do select the Include nonsecurity updates check box, patches from other repositories are considered as well.

Compliant
Installed Pending Reboot

The Patch Manager Install operation applied the patch to the instance, but the instance has not been rebooted since the patch was applied. (Note that patches installed outside of Patch Manager are never given a status of INSTALLED_PENDING_REBOOT.) This typically means the NoReboot option was selected for the RebootOption parameter when the AWS-RunPatchBaseline document was last run on the instance. For more information, see Parameter name: RebootOption.

Non-Compliant
Installed Rejected

The patch is installed on the instance but is specified in a Rejected patches list. This typically means the patch was installed before it was added to a list of rejected patches.

Non-Compliant
Missing

Packages that are filtered through the baseline, with the candidate version appearing in trusty-security (Ubuntu Server 14), xenial-security (Ubuntu Server 16), bionic-security (Ubuntu Server 18), or debian-security (Debian Stretch or Debian Jessie), and are upgradable.

Non-Compliant
Failed

Packages that failed to install during the patch operation.

Non-Compliant

Patch compliance values for other operating systems

For all operating systems besides Debian and Ubuntu Server, the rules for package classification into the different compliance states are described in the following table.

Patch status Description Compliance value
INSTALLED

The patch is listed in the patch baseline and is installed on the instance. It could have been installed either manually by an individual or automatically by Patch Manager when the AWS-RunPatchBaseline document was run on the instance.

Compliant
INSTALLED_OTHER

The patch is not in the baseline, but it is installed on the instance. The patch might have been installed manually, or the package could be a required dependency of another approved patch. If you do not specify Block as the Rejected patches action, Installed_Other patches also includes installed but rejected patches.

Compliant
INSTALLED_REJECTED

The patch is installed on the instance but is specified in a rejected patches list. This typically means the patch was installed before it was added to a list of rejected patches.

Non-Compliant
INSTALLED_PENDING_REBOOT

The Patch Manager Install operation applied the patch to the instance (or a patch was applied to a Windows Server instance outside of Patch Manager), but the instance has not been rebooted since the patch was applied. (Note that patches installed outside of Patch Manager are never given a status of INSTALLED_PENDING_REBOOT.) This typically means the NoReboot option was selected for the RebootOption parameter when the AWS-RunPatchBaseline document was last run on the instance. For more information, see Parameter name: RebootOption.

Non-Compliant
MISSING

The patch is approved in the baseline, but it's not installed on the instance. If you configure the AWS-RunPatchBaseline document task to scan (instead of install), the system reports this status for patches that were located during the scan but have not been installed.

Non-Compliant
NOT_APPLICABLE

The patch is approved in the baseline, but the service or feature that uses the patch is not installed on the instance. For example, a patch for web server service such as Internet Information Services (IIS) would show NOT_APPLICABLE if it was approved in the baseline, but the web service is not installed on the instance. A patch can also be marked NOT_APPLICABLE if it has been superseded by a subsequent update. This means that the later update is installed and the NOT_APPLICABLE update is no longer required.

Note

This compliance state is only reported on Windows Server operating systems.

Not applicable
FAILED

The patch is approved in the baseline, but it could not be installed. To troubleshoot this situation, review the command output for information that might help you understand the problem.

Non-Compliant