• The AWS Systems Manager CloudWatch Dashboard will no longer be available after April 30, 2026. Customers can continue to use Amazon CloudWatch console to view, create, and manage their Amazon CloudWatch dashboards, just as they do today. For more information, see [Amazon CloudWatch Dashboard documentation](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Dashboards.html). # AWS Systems Manager Patch Manager tutorials The tutorials in this section demonstrate how to use Patch Manager, a tool in AWS Systems Manager, for several patching scenarios. **Topics** + [Tutorial: Patching a server in an IPv6 only environment](patch-manager-server-patching-iPv6-tutorial.md) + [Tutorial: Create a patch baseline for installing Windows Service Packs using the console](patch-manager-windows-service-pack-patch-baseline-tutorial.md) + [Tutorial: Update application dependencies, patch a managed node, and perform an application-specific health check using the console](aws-runpatchbaselinewithhooks-tutorial.md) + [Tutorial: Patch a server environment using the AWS CLI](patch-manager-patch-servers-using-the-aws-cli.md) # Tutorial: Patching a server in an IPv6 only environment Patch Manager supports the patching of nodes in environments that only have IPv6. By updating the SSM Agent configuration, patching operations can be configured to only make calls to IPv6 service endpoints. **To patch a server in an IPv6 only environment** 1. Ensure that SSM Agent version 3.3270.0 or later is installed on the managed node. 1. On the managed node, navigate to the SSM Agent configuration file. You can find the `amazon-ssm-agent.json` file in the following directories: + Linux: `/etc/amazon/ssm/` + macOS: `/opt/aws/ssm/` + Windows Server: `C:\Program Files\Amazon\SSM` If `amazon-ssm-agent.json` doesn't exist yet, copy the contents of `amazon-ssm-agent.json.template` under the same directory to `amazon-ssm-agent.json`. 1. Update the following entry to set the correct Region and set `UseDualStackEndpoint` to `true`: ``` { -------- "Agent": { "Region": "region", "UseDualStackEndpoint": true }, -------- } ``` 1. Restart the SSM Agent service using the appropriate command for your operating system: + Linux: `sudo systemctl restart amazon-ssm-agent` + Ubuntu Server using Snap: `sudo snap restart amazon-ssm-agent` + macOS: `sudo launchctl stop com.amazon.aws.ssm` followed by `sudo launchctl start com.amazon.aws.ssm` + Windows Server: `Stop-Service AmazonSSMAgent` followed by `Start-Service AmazonSSMAgent` For the full list of commands per operating system, see [Checking SSM Agent status and starting the agent](ssm-agent-status-and-restart.md). 1. Execute any patching operation to verify patching operations succeed in your IPv6-only environment. Ensure that the nodes being patched have connectivity to the patch source. You can check the Run Command output from the patching execution to check for warnings about inaccessible repositories. When patching a node that is running in an IPv6 only environment, ensure that the node has connectivity to the patch source. You can check the Run Command output from the patching execution to check for warnings about inaccessible repositories. For DNF-based operating systems, it is possible to configure unavailable repositories to be skipped during patching if the `skip_if_unavailable` option is set to `True` under `/etc/dnf/dnf.conf`. DNF-based operating systems include Amazon Linux 2023, Red Hat Enterprise Linux 8 and later versions, Oracle Linux 8 and later versions, Rocky Linux, AlmaLinux, & CentOS 8 and later versions. On Amazon Linux 2023, the `skip_if_unavailable` option is set to `True` by default. **Note** When using the Install Override List or Baseline Override features, ensure that the provided URL is reachable from the node. If the SSM Agent config option `UseDualStackEndpoint` is set to `true`, then a dualstack S3 client is used when an S3 URL is provided. # Tutorial: Create a patch baseline for installing Windows Service Packs using the console When you create a custom patch baseline, you can specify that all, some, or only one type of supported patch is installed. In patch baselines for Windows, you can select `ServicePacks` as the only **Classification** option in order to limit patching updates to Service Packs only. Service Packs can be installed automatically by Patch Manager, a tool in AWS Systems Manager, provided that the update is available in Windows Update or Windows Server Update Services (WSUS). You can configure a patch baseline to control whether Service Packs for all Windows versions are installed, or just those for specific versions, such as Windows 7 or Windows Server 2016. Use the following procedure to create a custom patch baseline to be used exclusively for installing all Service Packs on your Windows managed nodes. **To create a patch baseline for installing Windows Service Packs (console)** 1. Open the AWS Systems Manager console at [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/). 1. In the navigation pane, choose **Patch Manager**. 1. Choose the **Patch baselines** tab, and then choose **Create patch baseline**. 1. For **Name**, enter a name for your new patch baseline, for example, `MyWindowsServicePackPatchBaseline`. 1. (Optional) For **Description**, enter a description for this patch baseline. 1. For **Operating system**, choose `Windows`. 1. If you want to begin using this patch baseline as the default for Windows as soon as you create it, select **Set this patch baseline as the default patch baseline for Windows Server instances** . **Note** This option is available only if you first accessed Patch Manager before the [patch policies](patch-manager-policies.md) release on December 22, 2022. For information about setting an existing patch baseline as the default, see [Setting an existing patch baseline as the default](patch-manager-default-patch-baseline.md). 1. In the **Approval rules for operating systems** section, use the fields to create one or more auto-approval rules. + **Products**: The operating system versions that the approval rule applies to, such as `WindowsServer2012`. You can choose one, more than one, or all supported versions of Windows. The default selection is `All`. + **Classification**: Choose `ServicePacks`. + **Severity**: The severity value of patches the rule is to apply to. To ensure that all Service Packs are included by the rule, choose `All`. + **Auto-approval**: The method for selecting patches for automatic approval. + **Approve patches after a specified number of days**: The number of days for Patch Manager to wait after a patch is released or updated before a patch is automatically approved. You can enter any integer from zero (0) to 360. For most scenarios, we recommend waiting no more than 100 days. + **Approve patches released up to a specific date**: The patch release date for which Patch Manager automatically applies all patches released or updated on or before that date. For example, if you specify July 7, 2023, no patches released or last updated on or after July 8, 2023, are installed automatically. + (Optional) **Compliance reporting**: The severity level you want to assign to Service Packs approved by the baseline, such as `High`. **Note** If you specify a compliance reporting level and the patch state of any approved Service Pack is reported as `Missing`, then the patch baseline's overall reported compliance severity is the severity level you specified. 1. (Optional) For **Manage tags**, apply one or more tag key name/value pairs to the patch baseline. Tags are optional metadata that you assign to a resource. Tags allow you to categorize a resource in different ways, such as by purpose, owner, or environment. For this patch baseline dedicated to updating Service Packs, you could specify key-value pairs such as the following: + `Key=OS,Value=Windows` + `Key=Classification,Value=ServicePacks` 1. Choose **Create patch baseline**. # Tutorial: Update application dependencies, patch a managed node, and perform an application-specific health check using the console In many cases, a managed node must be rebooted after it has been patched with the latest software update. However, rebooting a node in production without safeguards in place can cause several problems, such as invoking alarms, recording incorrect metric data, and interrupting data synchronizations. This tutorial demonstrates how to avoid problems like these by using the AWS Systems Manager document (SSM document) `AWS-RunPatchBaselineWithHooks` to achieve a complex, multi-step patching operation that accomplishes the following: 1. Prevent new connections to the application 1. Install operating system updates 1. Update the package dependencies of the application 1. Restart the system 1. Perform an application-specific health check For this example, we have set up our infrastructure this way: + The virtual machines targeted are registered as managed nodes with Systems Manager. + `Iptables` is used as a local firewall. + The application hosted on the managed nodes is running on port 443. + The application hosted on the managed nodes is a `nodeJS` application. + The application hosted on the managed nodes is managed by the pm2 process manager. + The application already has a specified health check endpoint. + The application’s health check endpoint requires no end user authentication. The endpoint allows for a health check that meets the organization’s requirements in establishing availability. (In your environments, it might be enough to simply ascertain that the `nodeJS` application is running and able to listen for requests. In other cases, you might want to also verify that a connection to the caching layer or database layer has already been established.) The examples in this tutorial are for demonstration purposes only and not meant to be implemented as-is into production environments. Also, keep in mind that the lifecycle hooks feature of Patch Manager, a tool in Systems Manager, with the `AWS-RunPatchBaselineWithHooks` document can support numerous other scenarios. Here are several examples. + Stop a metrics reporting agent before patching and restarting it after the managed node reboots. + Detach the managed node from a CRM or PCS cluster before patching and reattach after the node reboots. + Update third-party software (for example, Java, Tomcat, Adobe applications, and so on) on Windows Server machines after operating system (OS) updates are applied, but before the managed node reboots. **To update application dependencies, patch a managed node, and perform an application-specific health check** 1. Create an SSM document for your preinstallation script with the following contents and name it `NodeJSAppPrePatch`. Replace *your\$1application* with the name of your application. This script immediately blocks new incoming requests and provides five seconds for already active ones to complete before beginning the patching operation. For the `sleep` option, specify a number of seconds greater than it usually takes for incoming requests to complete. ``` # exit on error set -e # set up rule to block incoming traffic iptables -I INPUT -j DROP -p tcp --syn --destination-port 443 || exit 1 # wait for current connections to end. Set timeout appropriate to your application's latency sleep 5 # Stop your application pm2 stop your_application ``` For information about creating SSM documents, see [Creating SSM document content](documents-creating-content.md). 1. Create another SSM document with the following content for your postinstall script to update your application dependencies and name it `NodeJSAppPostPatch`. Replace */your/application/path* with the path to your application. ``` cd /your/application/path npm update # you can use npm-check-updates if you want to upgrade major versions ``` 1. Create another SSM document with the following content for your `onExit` script to bring your application back up and perform a health check. Name this SSM document `NodeJSAppOnExitPatch`. Replace *your\$1application* with the name of your application. ``` # exit on error set -e # restart nodeJs application pm2 start your_application # sleep while your application starts and to allow for a crash sleep 10 # check with pm2 to see if your application is running pm2 pid your_application # re-enable incoming connections iptables -D INPUT -j DROP -p tcp --syn --destination-port # perform health check /usr/bin/curl -m 10 -vk -A "" http://localhost:443/health-check || exit 1 ``` 1. Create an association in State Manager, a tool in AWS Systems Manager, to issue the operation by performing the following steps: 1. Open the AWS Systems Manager console at [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/). 1. In the navigation pane, choose **State Manager**, and then choose **Create association**. 1. For **Name**, provide a name to help identify the purpose of the association. 1. In the **Document** list, choose `AWS-RunPatchBaselineWithHooks`. 1. For **Operation**, choose **Install**. 1. (Optional) For **Snapshot Id**, provide a GUID that you generate to help speed up the operation and ensure consistency. The GUID value can be as simple as `00000000-0000-0000-0000-111122223333`. 1. For **Pre Install Hook Doc Name**, enter `NodeJSAppPrePatch`. 1. For **Post Install Hook Doc Name**, enter `NodeJSAppPostPatch`. 1. For **On ExitHook Doc Name**,enter `NodeJSAppOnExitPatch`. 1. For **Targets**, identify your managed nodes by specifying tags, choosing nodes manually, choosing a resource group, or choosing all managed nodes. 1. For **Specify schedule**, specify how often to run the association. For managed node patching, once per week is a common cadence. 1. In the **Rate control** section, choose options to control how the association runs on multiple managed nodes. Ensure that only a portion of managed nodes are updated at a time. Otherwise, all or most of your fleet could be taken offline at once. For more information about using rate controls, see [Understanding targets and rate controls in State Manager associations](systems-manager-state-manager-targets-and-rate-controls.md). 1. (Optional) For **Output options**, to save the command output to a file, select the **Enable writing output to S3** box. Enter the bucket and prefix (folder) names in the boxes. **Note** The S3 permissions that grant the ability to write the data to an S3 bucket are those of the instance profile assigned to the managed node, not those of the IAM user performing this task. For more information, see [Configure instance permissions required for Systems Manager](setup-instance-permissions.md) or [Create an IAM service role for a hybrid environment](hybrid-multicloud-service-role.md). In addition, if the specified S3 bucket is in a different AWS account, verify that the instance profile or IAM service role associated with the managed node has the necessary permissions to write to that bucket. 1. Choose **Create Association**. # Tutorial: Patch a server environment using the AWS CLI The following procedure describes how to patch a server environment by using a custom patch baseline, patch groups, and a maintenance window. **Before you begin** + Install or update the SSM Agent on your managed nodes. To patch Linux managed nodes, your nodes must be running SSM Agent version 2.0.834.0 or later. For more information, see [Updating the SSM Agent using Run Command](run-command-tutorial-update-software.md#rc-console-agentexample). + Configure roles and permissions for Maintenance Windows, a tool in AWS Systems Manager. For more information, see [Setting up Maintenance Windows](setting-up-maintenance-windows.md). + Install and configure the AWS Command Line Interface (AWS CLI), if you haven't already. For information, see [Installing or updating the latest version of the AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html). **To configure Patch Manager and patch managed nodes (command line)** 1. Run the following command to create a patch baseline for Windows named `Production-Baseline`. This patch baseline approves patches for a production environment 7 days after they're released or last updated. That is, we have tagged the patch baseline to indicate that it's for a production environment. **Note** The `OperatingSystem` parameter and `PatchFilters` vary depending on the operating system of the target managed nodes the patch baseline applies to. For more information, see [OperatingSystem](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_CreatePatchBaseline.html#systemsmanager-CreatePatchBaseline-request-OperatingSystem) and [PatchFilter](https://docs.aws.amazon.com/systems-manager/latest/APIReference/API_PatchFilter.html). ------ #### [ Linux & macOS ] ``` aws ssm create-patch-baseline \ --name "Production-Baseline" \ --operating-system "WINDOWS" \ --tags "Key=Environment,Value=Production" \ --approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=MSRC_SEVERITY,Values=[Critical,Important]},{Key=CLASSIFICATION,Values=[SecurityUpdates,Updates,ServicePacks,UpdateRollups,CriticalUpdates]}]},ApproveAfterDays=7}]" \ --description "Baseline containing all updates approved for production systems" ``` ------ #### [ Windows Server ] ``` aws ssm create-patch-baseline ^ --name "Production-Baseline" ^ --operating-system "WINDOWS" ^ --tags "Key=Environment,Value=Production" ^ --approval-rules "PatchRules=[{PatchFilterGroup={PatchFilters=[{Key=MSRC_SEVERITY,Values=[Critical,Important]},{Key=CLASSIFICATION,Values=[SecurityUpdates,Updates,ServicePacks,UpdateRollups,CriticalUpdates]}]},ApproveAfterDays=7}]" ^ --description "Baseline containing all updates approved for production systems" ``` ------ The system returns information like the following. ``` { "BaselineId":"pb-0c10e65780EXAMPLE" } ``` 1. Run the following commands to register the "Production-Baseline" patch baseline for two patch groups. The groups are named "Database Servers" and "Front-End Servers". ------ #### [ Linux & macOS ] ``` aws ssm register-patch-baseline-for-patch-group \ --baseline-id pb-0c10e65780EXAMPLE \ --patch-group "Database Servers" ``` ------ #### [ Windows Server ] ``` aws ssm register-patch-baseline-for-patch-group ^ --baseline-id pb-0c10e65780EXAMPLE ^ --patch-group "Database Servers" ``` ------ The system returns information like the following. ``` { "PatchGroup":"Database Servers", "BaselineId":"pb-0c10e65780EXAMPLE" } ``` ------ #### [ Linux & macOS ] ``` aws ssm register-patch-baseline-for-patch-group \ --baseline-id pb-0c10e65780EXAMPLE \ --patch-group "Front-End Servers" ``` ------ #### [ Windows Server ] ``` aws ssm register-patch-baseline-for-patch-group ^ --baseline-id pb-0c10e65780EXAMPLE ^ --patch-group "Front-End Servers" ``` ------ The system returns information like the following. ``` { "PatchGroup":"Front-End Servers", "BaselineId":"pb-0c10e65780EXAMPLE" } ``` 1. Run the following commands to create two maintenance windows for the production servers. The first window runs every Tuesday at 10 PM. The second window runs every Saturday at 10 PM. In addition, the maintenance window is tagged to indicate that it's for a production environment. ------ #### [ Linux & macOS ] ``` aws ssm create-maintenance-window \ --name "Production-Tuesdays" \ --tags "Key=Environment,Value=Production" \ --schedule "cron(0 0 22 ? * TUE *)" \ --duration 1 \ --cutoff 0 \ --no-allow-unassociated-targets ``` ------ #### [ Windows Server ] ``` aws ssm create-maintenance-window ^ --name "Production-Tuesdays" ^ --tags "Key=Environment,Value=Production" ^ --schedule "cron(0 0 22 ? * TUE *)" ^ --duration 1 ^ --cutoff 0 ^ --no-allow-unassociated-targets ``` ------ The system returns information like the following. ``` { "WindowId":"mw-0c50858d01EXAMPLE" } ``` ------ #### [ Linux & macOS ] ``` aws ssm create-maintenance-window \ --name "Production-Saturdays" \ --tags "Key=Environment,Value=Production" \ --schedule "cron(0 0 22 ? * SAT *)" \ --duration 2 \ --cutoff 0 \ --no-allow-unassociated-targets ``` ------ #### [ Windows Server ] ``` aws ssm create-maintenance-window ^ --name "Production-Saturdays" ^ --tags "Key=Environment,Value=Production" ^ --schedule "cron(0 0 22 ? * SAT *)" ^ --duration 2 ^ --cutoff 0 ^ --no-allow-unassociated-targets ``` ------ The system returns information like the following. ``` { "WindowId":"mw-9a8b7c6d5eEXAMPLE" } ``` 1. Run the following commands to register the `Database` and `Front-End` servers patch groups with their respective maintenance windows. ------ #### [ Linux & macOS ] ``` aws ssm register-target-with-maintenance-window \ --window-id mw-0c50858d01EXAMPLE \ --targets "Key=tag:PatchGroup,Values=Database Servers" \ --owner-information "Database Servers" \ --resource-type "INSTANCE" ``` ------ #### [ Windows Server ] ``` aws ssm register-target-with-maintenance-window ^ --window-id mw-0c50858d01EXAMPLE ^ --targets "Key=tag:PatchGroup,Values=Database Servers" ^ --owner-information "Database Servers" ^ --resource-type "INSTANCE" ``` ------ The system returns information like the following. ``` { "WindowTargetId":"e32eecb2-646c-4f4b-8ed1-205fbEXAMPLE" } ``` ------ #### [ Linux & macOS ] ``` aws ssm register-target-with-maintenance-window \ --window-id mw-9a8b7c6d5eEXAMPLE \ --targets "Key=tag:PatchGroup,Values=Front-End Servers" \ --owner-information "Front-End Servers" \ --resource-type "INSTANCE" ``` ------ #### [ Windows Server ] ``` aws ssm register-target-with-maintenance-window ^ --window-id mw-9a8b7c6d5eEXAMPLE ^ --targets "Key=tag:PatchGroup,Values=Front-End Servers" ^ --owner-information "Front-End Servers" ^ --resource-type "INSTANCE" ``` ------ The system returns information like the following. ``` { "WindowTargetId":"faa01c41-1d57-496c-ba77-ff9caEXAMPLE" } ``` 1. Run the following commands to register a patch task that installs missing updates on the `Database` and `Front-End` servers during their respective maintenance windows. ------ #### [ Linux & macOS ] ``` aws ssm register-task-with-maintenance-window \ --window-id mw-0c50858d01EXAMPLE \ --targets "Key=WindowTargetIds,Values=e32eecb2-646c-4f4b-8ed1-205fbEXAMPLE" \ --task-arn "AWS-RunPatchBaseline" \ --service-role-arn "arn:aws:iam::123456789012:role/MW-Role" \ --task-type "RUN_COMMAND" \ --max-concurrency 2 \ --max-errors 1 \ --priority 1 \ --task-invocation-parameters "RunCommand={Parameters={Operation=Install}}" ``` ------ #### [ Windows Server ] ``` aws ssm register-task-with-maintenance-window ^ --window-id mw-0c50858d01EXAMPLE ^ --targets "Key=WindowTargetIds,Values=e32eecb2-646c-4f4b-8ed1-205fbEXAMPLE" ^ --task-arn "AWS-RunPatchBaseline" ^ --service-role-arn "arn:aws:iam::123456789012:role/MW-Role" ^ --task-type "RUN_COMMAND" ^ --max-concurrency 2 ^ --max-errors 1 ^ --priority 1 ^ --task-invocation-parameters "RunCommand={Parameters={Operation=Install}}" ``` ------ The system returns information like the following. ``` { "WindowTaskId":"4f7ca192-7e9a-40fe-9192-5cb15EXAMPLE" } ``` ------ #### [ Linux & macOS ] ``` aws ssm register-task-with-maintenance-window \ --window-id mw-9a8b7c6d5eEXAMPLE \ --targets "Key=WindowTargetIds,Values=faa01c41-1d57-496c-ba77-ff9caEXAMPLE" \ --task-arn "AWS-RunPatchBaseline" \ --service-role-arn "arn:aws:iam::123456789012:role/MW-Role" \ --task-type "RUN_COMMAND" \ --max-concurrency 2 \ --max-errors 1 \ --priority 1 \ --task-invocation-parameters "RunCommand={Parameters={Operation=Install}}" ``` ------ #### [ Windows Server ] ``` aws ssm register-task-with-maintenance-window ^ --window-id mw-9a8b7c6d5eEXAMPLE ^ --targets "Key=WindowTargetIds,Values=faa01c41-1d57-496c-ba77-ff9caEXAMPLE" ^ --task-arn "AWS-RunPatchBaseline" ^ --service-role-arn "arn:aws:iam::123456789012:role/MW-Role" ^ --task-type "RUN_COMMAND" ^ --max-concurrency 2 ^ --max-errors 1 ^ --priority 1 ^ --task-invocation-parameters "RunCommand={Parameters={Operation=Install}}" ``` ------ The system returns information like the following. ``` { "WindowTaskId":"8a5c4629-31b0-4edd-8aea-33698EXAMPLE" } ``` 1. Run the following command to get the high-level patch compliance summary for a patch group. The high-level patch compliance summary includes the number of managed nodes with patches in the respective patch states. **Note** It's expected to see zeroes for the number of managed nodes in the summary until the patch task runs during the first maintenance window. ------ #### [ Linux & macOS ] ``` aws ssm describe-patch-group-state \ --patch-group "Database Servers" ``` ------ #### [ Windows Server ] ``` aws ssm describe-patch-group-state ^ --patch-group "Database Servers" ``` ------ The system returns information like the following. ``` { "Instances": number, "InstancesWithFailedPatches": number, "InstancesWithInstalledOtherPatches": number, "InstancesWithInstalledPatches": number, "InstancesWithInstalledPendingRebootPatches": number, "InstancesWithInstalledRejectedPatches": number, "InstancesWithMissingPatches": number, "InstancesWithNotApplicablePatches": number, "InstancesWithUnreportedNotApplicablePatches": number } ``` 1. Run the following command to get patch summary states per-managed node for a patch group. The per-managed node summary includes a number of patches in the respective patch states per managed node for a patch group. ------ #### [ Linux & macOS ] ``` aws ssm describe-instance-patch-states-for-patch-group \ --patch-group "Database Servers" ``` ------ #### [ Windows Server ] ``` aws ssm describe-instance-patch-states-for-patch-group ^ --patch-group "Database Servers" ``` ------ The system returns information like the following. ``` { "InstancePatchStates": [ { "BaselineId": "string", "FailedCount": number, "InstalledCount": number, "InstalledOtherCount": number, "InstalledPendingRebootCount": number, "InstalledRejectedCount": number, "InstallOverrideList": "string", "InstanceId": "string", "LastNoRebootInstallOperationTime": number, "MissingCount": number, "NotApplicableCount": number, "Operation": "string", "OperationEndTime": number, "OperationStartTime": number, "OwnerInformation": "string", "PatchGroup": "string", "RebootOption": "string", "SnapshotId": "string", "UnreportedNotApplicableCount": number } ] } ``` For examples of other AWS CLI commands you can use for your Patch Manager configuration tasks, see [Working with Patch Manager resources using the AWS CLI](patch-manager-cli-commands.md).