Scan & Patch

These actions can perform patching-related operations that provide insights into the patch compliance state of your virtual machines for security updates and other updates.

Scan

The Scan action scans a virtual machine to determine whether there are any patches available for the Patch action to install, and reports the patch compliance state in its output. It also lists all installed packages along with their versions.

Running the Scan action does not install patches, and does not reboot virtual machines.

The Scan action is useful for reporting purposes or to check what the Patch action will install.

Patch

The Patch action attempts to install applicable patches on a virtual machine. Unlike the Scan action, the Patch action does not report the available patches. Instead, it might list updates that failed to install for any reason. In addition, the Patch action lists the installed package versions before and after the patching operation.

The Patch action can reboot virtual machine if any patch is applied to ensure proper installation. This reboot occurs regardless of whether the specific patch actually requires it. You can control reboot behavior using the RebootAllowed parameter. For detailed information on reboot configuration and behavior, please refer to the RebootAllowed parameter description and Reboot behavior section.

Configuration

Both actions have shared configuration options, with the Patch action including all the configuration options of the Scan action.

Proxy settings

The patching process requires internet access. If target virtual machines have their internet access restricted, HttpProxy and HttpsProxy parameters can be specified to configure a proxy server for the patching process.

To bypass the proxy server for specific traffic, use the NoProxy parameter to define a comma-separated list of domains or IP addresses. The default value is set to 169.254.169.254, which is the IP address of cloud metadata endpoint. When specifying NoProxy parameter be aware that Fleet Control needs access to instance metadata endpoint and the default value should be included in the list of bypassed addresses.

info

Only the patching process's traffic is routed through the proxy server, the rest of the virtual machines' traffic is not affected.

Parameters format: <http or https>://<proxy server URL>:<port>
Examples: http://proxy.example.com:8080, https://10.0.0.42:3128

RebootAllowed

Patch action parameter only.

This parameter allows you to decide whether the installation of a patch should automatically trigger a system reboot. This setting is crucial in environments where it is critical to minimize disruptions due to rebooting, such as until a scheduled maintenance window, or when you are confident the patches do not require a reboot at all.

note

Some patches only install if you allow a reboot.

Reboot behavior

The following scenarios outline when reboots are allowed:

• Reboot after installation: A reboot occurs whenever the Patch action installs any patches, regardless of whether the patches explicitly require it.

• Delayed reboot completion: If no new patches are installed during the current Patch action execution, but there were installations in previous executions that did not lead to a system reboot (possibly due to reboot restrictions at that time), a reboot will be executed.

• No installation or delayed reboot: If there are no new installations and no patches are in a pending reboot state from previous Patch action executions, no reboot will occur.

When reboots are not allowed, no reboot occurs after the Patch action. Patch installations remain in a pending reboot state and the host is marked as non-compliant. Host compliance can be restored by either executing a system reboot and a subsequent Scan action during a maintenance window, or by enabling reboot parameter and executing Patch action again.

PatchInstallDelay

The PatchInstallDelay feature allows you to delay patches installation for a number of days specified in the parameter. It's useful when you don't want a patch to install immediately after release but after a certain period.

The Scan action doesn't report patches that don't meet the delay criteria as available.

It has a default value dependent on the PatchPolicy parameter described below. It's 0 for SystemAll and Custom values, and 7 for SecurityOnly.

Patch policies

A patch policy defines the rules for how and when patches are applied or scanned on managed instances.

Fleet Control uses AWS-RunPatchBaseline SSM document to run the PATCH and SCAN actions. By selecting one of the predefined patch policies or creating a custom one, Fleet Control creates a patch baseline definition, which is applied to the BaselineOverride parameter of the aforementioned document. You can also use a default patch baseline definition configured in AWS Patch Manager by selecting CustomerManaged patch policy.

info

Please refer to the official AWS documentation to find out more about AWS SSM Predefined and custom patch baselines

Patch policy configuration options

The patch policy is composed of several configurable options:

• Classification - determines the type of patches the Patch action can install, such as Security or Enhancement.
• Severity - determines the severity of a patch it can install, such as Critical.
• RejectedPatches - this list of patches, separated by commas, will not install. However, if a patch is a dependency of another package that is being installed, it will still install despite being in the Rejected Patches list. The format of the list varies by operating system and Linux type; see the Rejected Patches format section below for details.
• InstallNonSecurity - is relevant only for the Linux operating system. When you select this, it installs non-security patches in addition to security-related ones.

Predefined patch policies

There are two predefined policies:

• SecurityOnly - installs security-focused patches
• SystemAll - installs all available patches

info

By default, the SecurityOnly policy is selected.

To view the settings used by this policy across all supported operating systems, refer to the SecurityOnly patch policy details section.

warning

Predefined policies ignore Classification, Severity and InstallNonSecurity options.

Defining a custom patch policy

Select Custom patching policy to manually configure all available options for each supported OS.

Currently only one set of severities is supported for each available classifications selected.

SecurityOnly patch policy details

The following table illustrates the classifications and severities of patches that are installed for each supported operating system.

OS	Classification	Severity
Windows	CriticalUpdates, SecurityUpdates	Critical, Important
Amazon Linux, CentOS, RHEL	CriticalUpdates, SecurityUpdates Bugfix	Critical, Important All
Ubuntu, Debian	Not supported*	Required, Important, Standard, Optional, Extra
Suse	Security	Critical, Important

*Security-only patches applied with EnableNonSecurity: false option.

SystemAll patch policy details

The following table illustrates the classifications and severities of patches that are installed for each supported operating system.

OS	Classification	Severity
Windows, Amazon Linux, CentOS, RHEL, Suse	All	All
Ubuntu, Debian	Not supported*	All

*All kinds of patches applied with EnableNonSecurity: true option.

Rejected Patches format

• For Windows, it's Microsoft Knowledge Base IDs and Microsoft Security Bulletin IDs, such as:

  • KB2032276
  • KB2124261
  • MS10-048

• For Amazon Linux, CentOS, Oracle Linux, Red Hat Enterprise Linux, SUSE Linux Enterprise Server, it's either full package names, such as:

  • example-pkg-2018.11.4-46.17.1.x86_64.rpm
  • pkg-example-EE-20180914-2.2.amzn1.noarch

  or package names with a single wildcard, such as:

  • example-pkg-2018.11.4-46.17.1.*.rpm
  • example-pkg-EE-2018*.amzn1.noarch

• For Debian Server and Ubuntu Server, it's bare package names, without architecture or versions elements, e.g., ExamplePkg33, which covers all the following:

  • ExamplePkg33.x86.1
  • ExamplePkg33.x86.2
  • ExamplePkg33.x64.1
  • ExamplePkg33.3.2.5-364.noarch