Understanding patch compliance state values
The information about patches for a managed node include a report of the state, or status, of each individual patch.
Note
If you want to assign a specific patch compliance state to a managed node, you can use the put-compliance-items AWS Command Line Interface (AWS CLI) command or the PutComplianceItems API operation. Assigning compliance state isn't supported in the console.
Use the information in the following tables to help you identify why a managed node might be out of patch compliance.
Patch compliance values for Debian Server, Raspberry Pi OS, and Ubuntu Server
For Debian Server, Raspberry Pi OS, and Ubuntu Server, the rules for package classification into the different compliance states are described in the following table.
Note
Keep the following in mind when you're evaluating the
INSTALLED
, INSTALLED_OTHER
, and
MISSING
status values: If you don't 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.04 LTS), xenial-security
(Ubuntu Server 16.04 LTS), bionic-security
(Ubuntu Server 18.04 LTS), focal-security
(Ubuntu Server 20.04 LTS), groovy-security
(Ubuntu Server 20.10 STR), jammy-security
(Ubuntu Server
22.04 LTS), or debian-security
(Debian Server and
Raspberry Pi OS). If you do select the Include nonsecurity
updates check box, patches from other repositories
are considered as well.
Patch state | Description | Compliance status |
---|---|---|
|
The patch is listed in the patch baseline and is
installed on the managed node. It could have been
installed either manually by an individual or
automatically by Patch Manager when the
|
Compliant |
|
The patch isn't included in the baseline or isn't
approved by the baseline but is installed on the
managed node. 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 don't specify |
Compliant |
|
|
Non-Compliant |
|
The patch is installed on the managed node 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 |
|
Packages that are filtered through the baseline and not already installed. |
Non-Compliant |
|
Packages that failed to install during the patch operation. |
Non-Compliant |
Patch compliance values for other operating systems
For all operating systems besides Debian Server, Raspberry Pi OS, and Ubuntu Server, the rules for package classification into the different compliance states are described in the following table.
Patch state | Description | Compliance value |
---|---|---|
|
The patch is listed in the patch baseline and is
installed on the managed node. It could have been
installed either manually by an individual or
automatically by Patch Manager when the
|
Compliant |
|
The patch isn't in the baseline, but it is installed on the managed node. There are two possible reasons for this:
|
Compliant |
|
The patch is installed on the managed node 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 |
|
|
Non-Compliant |
|
The patch is approved in the baseline, but it
isn't installed on the managed node. If you
configure the |
Non-Compliant |
|
The patch is approved in the baseline, but the
service or feature that uses the patch isn't
installed on the managed node. For example, a patch
for a web server service such as Internet
Information Services (IIS) would show
NoteThis compliance state is only reported on Windows Server operating systems. |
Not applicable |
|
The patch is approved in the baseline, but it couldn't be installed. To troubleshoot this situation, review the command output for information that might help you understand the problem. |
Non-Compliant |
¹ For patches with the state INSTALLED_OTHER
and
NOT_APPLICABLE
, Patch Manager omits some data from query
results based on the describe-instance-patches command,
such as the values for Classification
and
Severity
. This is done to help prevent exceeding the
data limit for individual nodes in Inventory, a capability of AWS Systems Manager.
To view all patch details, you can use the
describe-available-patches command.