Menu
AWS Systems Manager
User Guide

Working with Patch Manager

To use Patch Manager, complete the following tasks. These tasks are described in more detail in this section.

  1. Verify that the default patch baselines meet your needs, or create patch baselines that define a standard set of patches for your instances.

  2. Organize instances into patch groups by using Amazon EC2 tags (optional, but recommended).

  3. Schedule patching by using a Maintenance Window that defines which instances to patch and when to patch them.

  4. Monitor patching to verify compliance and investigate failures.

Step 1: Verifying Default Patch Baselines, or Creating Your Own

A patch baseline defines which patches are approved for installation on your instances. You can individually specify approved or rejected patches. You can also create auto-approval rules to specify that certain types of updates (for example, critical updates), should be automatically approved. The rejected list overrides both the rules and the approve list. If you plan to use a list of approved patches to install specific packages, then remove all auto-approval rules. If you explicitly identify a patch as rejected, it will not be approved or installed, even if it matches all of the criteria in an auto-approval rule. Also, even if a patch is approved for an instance, it is only installed if it applies to the software on the instance.

Patch Manager has pre-defined patch baselines for each of the operating systems supported by Patch Manager. The following table describes each of the pre-defined patch baselines:

Name Supported Products Details

AWS-DefaultPatchBaseline

Windows (Windows Server 2008 – 2016)

Approves all operating system patches with a classification of CriticalUpdates or SecurityUpdates and an MSRC severity of Critical or Important seven days after release.

AWS-AmazonLinuxDefaultPatchBaseline

Amazon Linux (2012.03 – 2017.09)

Approves all operating system patches with a classification of Security and severity of Critical or Important seven days after release. Also approves all patches with a classification of Bugfix seven days after release

AWS-UbuntuDefaultPatchBaseline

Ubuntu (14.04/16.04)

Immediately approves all operating system security-related patches with a priority of Required or Important. There is no wait before approval because reliable release dates are not available in the repos.

AWS-RedHatDefaultPatchBaseline

Redhat Enterprise Linux (6.5, 6.6, 6.7, 6.8, 6.9, 7.0, 7.1, 7.2, 7.3)

Approves all operating system patches with a classification of Security and severity of Critical or Important seven days after release. Also approves all patches with a classification of Bugfix seven days after release.

You can use these baselines as they are currently configured (you can't customize them) or you can create your own patch baselines if you want greater control over which patches are approved or rejected for your environment.

If you create your own patch baseline, you can choose which patches to auto-approve by using the following categories.

  • Operating system: Windows, Amazon Linux, Ubuntu, etc.

  • Product name: For example, RHEL 6.5, Amazon Linux 2014.09, Windows Server 2012, Windows Server 2012 R2, etc.

  • Classification: For example, critical updates, security updates, etc.

  • Severity: For example, critical, important, etc.

For each auto-approval rule that you create, you can specify an auto-approval delay. This delay is the number of days to wait after the patch was released, before the patch is automatically approved for patching. For example, if you create a rule using the Critical Updates classification and configure it for seven days auto-approval delay, then a new critical patch released on January 7 will automatically be approved on January 14.

Note

If a Linux repository doesn’t provide release date information for packages, Systems Manager treats the Auto Approval Delay as having a value of zero.

You can also specify a compliance severity level. If an approved patch is reported as missing, Compliance Level is the severity of the compliance violation.

By using multiple patch baselines with different auto-approval delays, you can deploy patches at different rates to different instances. For example, you can create separate patch baselines and auto-approval delays for development and production environments. This enables you to test patches in your development environment before they get deployed in your production environment.

When you create a patch baseline keep the following information in mind:

  • Patch Manager provides a default patch baseline for each supported operating system. You can also create your own patch baseline and designate that as the default patch baseline for the corresponding operating system.

  • For on-premises or non-Amazon EC2 instances, Patch Manager attempts to use your custom default patch baseline. If no custom default patch baseline exists, the system uses the pre-defined patch baseline for the corresponding operating system.

  • If a patch is listed as both approved and rejected in the same patch baseline, the patch is rejected.

  • An instance can have only one patch baseline defined for it.

  • When you create patch baselines for Amazon Linux and RHEL, if you specify Approved Patches, be aware that Systems Manager supports Bugzilla ID, CVE ID, Advisory ID, and package-name wildcards. If you specify Rejected Patches, Systems Manager only supports package-name wildcards. For Ubuntu baselines, only full package names are supported in both the Approved and Rejected Patches fields.

To view an example of how to create a patch baseline by using the Amazon EC2 console or the AWS CLI, see Systems Manager Patch Manager Walkthroughs.

Important Differences Between Windows and Linux Patching

The following table describes important differences between Windows and Linux patching.

Difference Details

Patch evaluation

Patch Manager uses a different process to evaluate which patches should be present on Windows managed instances versus Linux managed instance. For Windows patching, Systems Manager evaluates patch baseline rules and the list of approved and rejected patches directly in the service. It can do this because Windows patches are pulled from a single repository (Windows Update).

For Linux patching, Systems Manager evaluates patch baseline rules and the list of approved and rejected patches on each managed instance. Systems Manager must evaluate patching on each instance because the service retrieves the list of known patches and updates from the repositories that are configured on the instance.

Not Applicable patches

Due to the large number of available packages for Linux operating systems, Systems Manager does not report details about patches in the Not Applicable state. A Not Applicable patch is, for example, a patch for Apache software when the instance does not have Apache installed. Systems Manager does report the number of Not Applicable patches in the summary, but if you call the DescribeInstancePatches API for an instance, the returned data does not include patches with a state of Not Applicable. This behavior is different from Windows.

Note

Also note the following changes and requirements for Linux patching:

  • To patch Linux instances, your instances must be running SSM Agent version 2.0.834.0 or later. For information about updating the agent, see the section titled Example: Update the SSM Agent in Executing Commands from the EC2 Console.

  • The AWS-ApplyPatchBaseline SSM document is being replaced by the AWS-RunPatchBaseline document.

Step 2: Organizing Instances into Patch Groups

A patch group is an optional means of organizing instances for patching. For example, you can create patch groups for different operating systems (Linux or Windows), different environments (Development, Test, and Production), or different server functions (web servers, file servers, databases). Patch groups can help you avoid deploying patches to the wrong set of instances. They can also help you avoid deploying patches before they have been adequately tested.

You create a patch group by using Amazon EC2 tags. Unlike other tagging scenarios across Systems Manager, a patch group must be defined with the tag key: Patch Group. Note that the key is case sensitive. You can specify any value, for example "web servers," but the key must be Patch Group.

Note

An instance can only be in one patch group.

After you create a patch group and tag instances, you can register the patch group with a patch baseline. By registering the patch group with a patch baseline, you ensure that the correct patches are installed during the patching execution.

When the system executes the task to apply a patch baseline to an instance, the service checks to see if a patch group is defined for the instance. If the instance is assigned to a patch group, the system then checks to see which patch baseline is registered to that group. If a patch baseline is found for that group, the system applies the patch baseline. If an instance isn't configured for a patch group, the system automatically uses the currently configured default patch baseline.

For example, let's say an instance is tagged with key=Patch Group and value=Front-End Servers. When Patch Manager executes the AWS-RunPatchBaseline task on that instance, the service checks to see which patch baseline is registered with Front-End Servers. If a patch baseline is found, the system uses that baseline. If no patch baseline is registered for Front-End Servers, the system uses the default patch baseline.

To view an example of how to create a patch baseline and patch groups by using the AWS CLI, see Systems Manager Patch Manager Walkthroughs. For more information about Amazon EC2 tags, see Tagging Your Amazon EC2 Resources in the Amazon EC2 User Guide.

Step 3: Scheduling Patch Updates Using a Maintenance Window

After you configure a patch baseline (and optionally a patch group), you can apply patches to your instance by using a Maintenance Window. A Maintenance Window can reduce the impact on server availability by letting you specify a time to perform the patching process that doesn't interrupt business operations. A Maintenance Window works like this:

  1. Create a Maintenance Window with a schedule for your patching operations.

  2. Choose the targets for the Maintenance Window by specifying the Patch Group tag for the tag name, and any value for which you have defined Amazon EC2 tags, for example, "production servers".

  3. Create a new Maintenance Window task, and specify the AWS-RunPatchBaseline document.

When you configure the task, you can choose to either scan instances or scan and patch instances. If you choose to scan instances, then Patch Manager scans each instance and generates a list of missing patches for you to review.

If you choose to scan and patch, then Patch Manager scans each instance and compares the list of installed patches against the list of approved patches in the baseline. Patch Manager identifies missing patches, and then downloads and installs all missing and approved patches.

If you want to perform a one-time scan or install to fix an issue, you can use Run Command to call the AWS-RunPatchBaseline document directly.

Important

After installing patches, Systems Manager reboots each instance. The reboot is required to make sure that patches are installed correctly and to ensure that the system did not leave the instance in a potentially bad state.

Related Content