Menu
Amazon EC2 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 AWS-DefaultPatchBaseline meets your needs, or create a patch baseline that defines 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 the Default Patch Baseline, or Creating a Patch Baseline

A patch baseline defines which patches should and shouldn't be installed on your instances. You can individually specify approved or rejected patches, or you can use auto-approval rules to specify that certain types of updates (for example, critical updates), should automatically be approved for patching.

Patch Manager has a pre-defined patch baseline that approves all patches classified as critical updates or security updates with a severity of Critical or Important. These patches are automatically approved by this baseline 7 days after they are released by Microsoft. You can use this baseline as it is currently configured (you can't customize it) or you can create your own patch baseline if you want greater control over which patches are approved for deployment.

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

  • Product name: For example, 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.

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:

  • By default, the pre-defined patch baseline that ships with Patch Manager is designated as the default patch baseline. However, you can specify your own patch baseline as the default.

  • For on-premises or non-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 that ships with Patch Manager.

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

  • Only one patch baseline can be used for an instance.

To view an example of how to create a patch baseline by using the AWS CLI, see Systems Manager Patch Manager Walkthrough.

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 environments such as development, test, and production. You can also create patch groups based on server function, for example web servers and databases. Patch groups can help you avoid deploying patches to the wrong set of instances. They can also help you avoid deploying patches too early (before they have been adequately tested).

You create a patch group by using 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 patch baseline is installed during patching.

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-ApplyPatchBaseline 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 Walkthrough. 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. The process 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 EC2 tags, for example, "production servers".

  3. Create a new Maintenance Window task, and specify the AWS-ApplyPatchBaselines 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-ApplyPatchBaselines 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.

To view an example of how to create a patch baseline, patch groups, and a Maintenance Window task that uses the AWS-ApplyPatchBaselines document by using the AWS CLI, see Systems Manager Patch Manager Walkthrough. For more information about Maintenance Windows, see Systems Manager Maintenance Windows.

Step 4: Monitoring Patch Compliance

After the Maintenance Window task is complete, you can view results and patch compliance details in either the Amazon EC2 console or by using the Systems Manager API. You can view an aggregate of compliance details per instance. This aggregate view includes details such as the overall compliance state, the date of the last scan, the number of patches installed, and the number of missing patches. You can review this information on a per-instance basis to view details about specific patches. The specific patches show one of the following states.

  • Installed: Either the patch was already installed, or Patch Manager installed it when the AWS-ApplyPatchBaseline document was run on the instance.

  • Installed_Other: The patch is not in the baseline, but it is installed on the instance. An individual might have installed it manually.

  • Missing: The patch is approved in the baseline, but it's not installed on the instance. If you configure the AWS-ApplyPatchBaseline 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.

  • 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 the Internet Information Services (IIS) web server role would show Not_Applicable if it was approved in the baseline, but IIS is not installed on the instance.

  • 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.

You can view patch compliance details in the Amazon EC2 console on the Managed Instances page. In the filter bar, use the AWS: PatchSummary and AWS: PatchCompliance filters. You can also review a specific instance by choosing the instance in the Managed Instances page, and then choosing the Patch tab. You can also use the DescribePatchGroupState and DescribeInstancePatchStatesForPatchGroup APIs to view compliance details.

DescribePatchGroupState returns high-level aggregated patch compliance information for a patch group, as shown in the following example.

Copy
{ "InstancesWithNotApplicablePatches":0, "InstancesWithMissingPatches":0, "InstancesWithFailedPatches":1, "InstancesWithInstalledOtherPatches":4, "Instances":4, "InstancesWithInstalledPatches":3 }

DescribeInstancePatchStatesForPatchGroup returns the high-level patch state for the instances in the specified patch group, as shown in the following example.

Copy
{ "InstancePatchStates":[ { "OperationStartTime":1481259600.0, "FailedCount":0, "InstanceId":"i-08ee91c0b17045407", "OwnerInformation":"", "NotApplicableCount":2077, "OperationEndTime":1481259757.0, "PatchGroup":"Production", "InstalledOtherCount":186, "MissingCount":7, "SnapshotId":"b0e65479-79be-4288-9f88-81c96bc3ed5e", "Operation":"Scan", "InstalledCount":72 }, { "OperationStartTime":1481259602.0, "FailedCount":0, "InstanceId":"i-0fff3aab684d01b23", "OwnerInformation":"", "NotApplicableCount":2692, "OperationEndTime":1481259613.0, "PatchGroup":"Production", "InstalledOtherCount":3, "MissingCount":1, "SnapshotId":"b0e65479-79be-4288-9f88-81c96bc3ed5e", "Operation":"Scan", "InstalledCount":1 }, { "OperationStartTime":1481259547.0, "FailedCount":0, "InstanceId":"i-0a00def7faa94f1dc", "OwnerInformation":"", "NotApplicableCount":1859, "OperationEndTime":1481259592.0, "PatchGroup":"Production", "InstalledOtherCount":116, "MissingCount":1, "SnapshotId":"b0e65479-79be-4288-9f88-81c96bc3ed5e", "Operation":"Scan", "InstalledCount":110 }, { "OperationStartTime":1481259549.0, "FailedCount":0, "InstanceId":"i-09a618aec652973a9", "OwnerInformation":"", "NotApplicableCount":1637, "OperationEndTime":1481259837.0, "PatchGroup":"Production", "InstalledOtherCount":388, "MissingCount":2, "SnapshotId":"b0e65479-79be-4288-9f88-81c96bc3ed5e", "Operation":"Scan", "InstalledCount":141 } ] }

To view an example of how to review patch compliance details by using the AWS CLI, see Systems Manager Patch Manager Walkthrough.