# Understand patch management in AMS Accelerate **Important** Accelerate Patch reporting periodically deploys an AWS Glue resource-based policy. Be advised that AMS updates to the patching system overwrite existing AWS Glue resource-based policies. **Important** You can specify alternative patch repositories for managed nodes. While AMS implements your requested patch configurations, you are responsible for selecting and validating the security of your chosen repositories. You must also accept any risks from using these repositories, such as supply chain risks. The following are best practices for the security of your patch management process: Use only trusted, verified repository sources Default to standard OS vendor repositories when possible Regularly audit custom repository configurations You can use the AMS Accelerate patching system, Patch Add-On, to patch your instances with security-related and other types of updates. Accelerate Patch Add-On is a feature that provides tag-based patching for AMS instances. It leverages AWS Systems Manager (SSM) functionality so you can tag instances and have those instances patched using a baseline and a window that you configure. The AMS Accelerate Patch Add-On is an onboarding option, if you did not obtain it during onboarding your Accelerate account, contact your cloud service delivery manager (CSDM) to get it. AMS Accelerate patch management uses the Systems Manager patch baseline functionality to control the definition of the patches that are applied on an instance. The patch baseline contains the list of patches that are pre-approved; for example, all security patches. The compliance of the instance is measured against the patch baseline associated to it. AMS Accelerate, by default, installs all patches available to keep the instance up to date. **Note** AMS Accelerate applies only operating system (OS) patches. For example, for Windows, only Windows updates are applied, not Microsoft updates. For information on reports, see [AMS host management reports](ams-host-man.md). AMS Accelerate provides a range of operational services to help you achieve operational excellence on AWS. To gain a quick understanding of how AMS helps your teams achieve overall operational excellence in AWS Cloud with some of our key operational capabilities including 24x7 helpdesk, proactive monitoring, security, patching, logging and backup, see [ AMS Reference Architecture Diagrams](https://d1.awsstatic.com/architecture-diagrams/ArchitectureDiagrams/AWS-managed-services-for-operational-excellence-ra.pdf). **Topics** + [ ## Patching recommendations ](#acc-patching-recos) + [ # Create a patch maintenance window in AMS ](acc-p-maint-window.md) + [ # Patch with hooks ](acc-p-hooks.md) + [ # AMS Accelerate patch baseline ](acc-patch-baseline.md) + [ # Creating an IAM role for on-demand patching of AMS Accelerate ](acc-p-user-access.md) + [ # Understand patch notifications and patch failures in AMS Accelerate ](acc-patch-mon-remediate.md) ## Patching recommendations If you are involved in application or infrastructure operations, you understand the importance of an operating system (OS) patching solution that is flexible and scalable enough to meet the varied requirements from your application teams. In a typical organization, some application teams use an architecture that involves immutable instances whereas others deploy their applications on mutable instances. For more information on AWS Prescriptive Guidance for patching, see [ Automated patching for mutable instances in the hybrid cloud using AWS Systems Manager](https://docs.aws.amazon.com/prescriptive-guidance/latest/patch-management-hybrid-cloud/welcome.html). **Note** Accelerate Patch Add-On is a feature that provides tag-based patching for AMS instances. It leverages AWS Systems Manager (SSM) functionality so you can tag instances and have those instances patched using a baseline and a window that you configure. The AMS Accelerate Patch Add-On is an onboarding option, if you did not obtain it during onboarding your Accelerate account, contact your cloud service delivery manager (CSDM) to get it. ### Patch responsibility recommendations The patching process for persistent instances should involve the following teams and actions: + **The application (DevOps) teams** define the patch groups for their servers based on application environment, OS type, or other criteria. They also define the maintenance windows specific to each patch group. This information should be stored on tags attached to the instances. Recommended tag names are 'Patch Group' and 'Maintenance Window'. During each patch cycle, the application teams prepare for patching, test the application after patching, and troubleshoot any issues with their applications and OS during patching. + **The security operations team** defines the patch baselines for various OS types that are used by the application teams, and make the patches available through Systems Manager Patch Manager. + **The automated patching solution** runs on a regular basis and deploys the patches defined in the patch baselines, based on the user-defined patch groups and maintenance windows. + **The governance and compliance teams** define patching guidelines and exception processes & mechanisms. For more information, see [ Patching solution design for mutable EC2 instances](https://docs.aws.amazon.com/prescriptive-guidance/latest/patch-management-hybrid-cloud/design-standard.html). ### Guidance for application teams + Review and become familiar with creating and managing maintenance windows; see [AWS Systems Manager Maintenance Windows](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-maintenance.html) and [Create an SSM Maintenance window for patching](https://docs.aws.amazon.com/managedservices/latest/accelerate-guide/acc-patching.html#acc-p-maint-window) to learn more. Understanding the general structure and use of maintenance windows helps you understand what information to provide if you are not the person creating them. + For High Availability (HA) setups, plan to have one maintenance window per availability zone and per environment (Dev/Test/Prod). This will ensure continued availability during patching. + Recommended Maintenance Window duration is 4 hours with a 1-hour cutoff, plus 1 additional hour per 50 instances + Patch Dev and Test versions with enough time between each to allow you to identify any potential issues prior to Production patching. + Automate common pre- and post-patching tasks via SSM automation and run them as maintenance window tasks. Note that for post-patching tasks you must ensure that there is sufficient time allotted, as tasks will not launch once the cutoff is reached. + Become familiar with Patch Baselines and their features—particularly around auto-approval delays for patch severity types that can be used to ensure that only the patches that were applied in Dev/Test get applied in Production at a later date. See [About patch baselines](https://docs.aws.amazon.com/systems-manager/latest/userguide/about-patch-baselines.html) for details. ### Guidance for security operations teams + Review and become familiar with patch baselines. Patch approval is handled in an automated fashion and has different rule options. See [About patch baselines](https://docs.aws.amazon.com/systems-manager/latest/userguide/about-patch-baselines.html) for more information. + Discuss needs around patching Dev/Test/Prod with application teams and develop multiple baselines to accommodate these needs. ### Guidance for governance and compliance teams + Patching should be an "Opt Out" function. A default maintenance window and automated tagging should exist to ensure nothing goes unpatched. AMS Resource Tagger can help with this; discuss this option with your cloud architect (CA) or cloud service delivery manager (CSDM) for guidance on implementation. + Requests for exemption from patching should require documentation justifying the exemption. A Chief Information Security Officer (CISO) or other approval officer should approve or deny the request. + Patching compliance should be reviewed on a regular schedule via the Patch Manager console, Security Hub, or a vulnerability scanner. ### Example design for high availability Windows application ![\[Patch Tuesday schedule showing development, test, and production environments with baseline approval timelines.\]](http://docs.aws.amazon.com/managedservices/latest/accelerate-guide/images/acc-maint-window.png) **Overview:** + One Maintenance Window per AZ. + One Set of Maintenance Windows per Environment. + One Patch Baseline per Environment: + Dev: Approve all severity and classification after 0 days. + Test: Approve critical security update patches after 0 days and all other severity and classifications after 7 days. + Prod: Approve critical security update patches after 0 days and all other severity and classifications after 14 days. **CloudFormation Scripts:** These scripts are setup to build out the maintenance windows, baselines, and patching tasks for a two availability zone Windows HA EC2 application using the baseline approval settings described above. + Windows Dev CFN Stack Example:  [HA-Patching-Dev-Stack.json](samples/HA-Patching-Dev-Stack.zip) + Windows Test CFN Stack Example:  [HA-Patching-Test-Stack.json](samples/HA-Patching-Test-Stack.zip) + Windows Prod CFN Stack Example:  [HA-Patching-Prod-Stack.json](samples/HA-Patching-Prod-Stack.zip) ### Patch recommendations FAQs Q: How do I handle unscheduled patching for "0" day exploits? A: SSM supports a **Patch Now** feature that uses the current default baseline for the instance's OS. AMS deploys a default set of Patch Baselines that approves all patches after 0 days. However, when using the **Patch Now** feature, a pre-patch snapshot is not taken, as this command runs the AWS-RunPatchBaseline SSM document. We recommend that you take a manual backup prior to patching. Q: Does AMS support patching for instances in Auto-Scaling Groups (ASGs)? A: No. At this time, ASG patching is not supported for Accelerate customers. Q: Are there any limitations for Maintenance Windows to keep in mind? A: Yes, there are a few limitations you should be aware of. + Maintenance Windows per Account: 50 + Tasks per Maintenance Window: 20 + Maximum number of concurrent automations per Maintenance Window: 20 + Maximum number of concurrent Maintenance Windows: 5 For a full list of default SSM limits, see [AWS Systems Manager endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/ssm.html). # Create a patch maintenance window in AMS A patch maintenance window runs AMS patch automations on a set schedule for targeted Amazon EC2 instances. Targets are defined by a tag or tags for a group of instances. You can set schedules based on days and times around Patch Tuesday, or you can define a schedule using a *cron expression*. For more information, see [Reference: Cron and rate expressions for Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/reference-cron-and-rate-expressions.html) in the *AWS Systems Manager User Guide*. Before patching, AMS creates a snapshot of each instance's root volume. If AMS detects that patching impacts the instance's health, or if you notify AMS of application impact from patching, then AMS uses this snapshot to restore the root volume to a pre-patch state. ## AMS Accelerate patch maintenance window limits AMS patching uses AWS Systems Manager (Systems Manager). In addition to Systems Manager service limits, AMS patching has a limit of 300 target instances per patch maintenance window. Given a general patch completion time of 30 mins per instance, the following table provides examples for numbers of maintenance windows and durations. | Instances to patch | Maintenance windows duration (hrs) | Concurrent maintenance windows needed | | --- | --- | --- | | 100 | 1 | 1 | | 200 | 1 | 1 | | 300 | 2 | 1 | | 600 | 3 | 2 | | 800 | 4 | 3 | | 1200 | 6 | 4 | | 1500 | 8 | 5 | **Important** These examples assume no other Systems Manager maintenance windows are active and no other automations are running. For more information on limits, see [AWS Systems Manager endpoints and quotas](https://docs.aws.amazon.com/general/latest/gr/ssm.html). **Topics** + [ ## AMS Accelerate patch maintenance window limits ](#acc-p-maint-limit) + [ # Create a recurring "Patch Tuesday" maintenance window from the AMS console (recommended) ](acc-p-maint-window-ams-console.md) + [ # Create a patch maintenance window using CloudFormation for AMS Accelerate ](acc-p-maint-window-cfn.md) + [ # Create a maintenance window from the Systems Manager console for AMS Accelerate ](acc-p-maint-window-console.md) + [ # Create a maintenance window with the Systems Manager command line interface (CLI) for AMS Accelerate ](acc-p-maint-window-cli.md) # Create a recurring "Patch Tuesday" maintenance window from the AMS console (recommended) Microsoft releases patches for its operating systems on the second Tuesday of each month, also know as Patch Tuesday. It is common to schedule patching for both Windows and Linux instances relative to Patch Tuesday. To schedule recurring patch maintenance windows on the first or second weekends after Patch Tuesday, visit the AMS console and follow these steps: 1. Provide a name for your patch maintenance window. 1. [optional] Provide a description for the patch maintenance window. 1. Select a day relative to Patch Tuesday. 1. Enter a time for the patch maintenance window to start in hh:mm. For example, midnight is **00:00** and 11pm is **23:00**. Then select a timezone. 1. [optional] Change the duration to suit your needs. AMS recommends a four hour minimum duration. 1. Enter a patch tag key and value for the target. For information, see [What are tags?](https://docs.aws.amazon.com/managedservices/latest/accelerate-guide/acc-tag-intro.html#acc-tag-what-is). 1. [optional] Expand the optional parameters to adjust concurrency, error rate, and maintenance window cut-off. 1. Concurrency controls how many target instances are patching at the same time. For example, a 50% concurrency for 10 target instances will patch no more that 5 instances at a time, while 100% concurrency will patch all 10 at once. 1. Error rate controls the tolerance for errors before patching is suspended. For example, an error rate of 100% for 10 target instances will patch all instances regardless of how many fail, while a 50% error rate will suspend patching once 5 instances have failed to patch. AMS recommends a 100% error rate. 1. Patch maintenance window cutoff prevents breach of the patch maintenance window by suspending the start of new patching activities the specified hours before the end of the patch maintenance window. For example a cutoff of 1 hour (recommended), ceases new patch activities 1 hour before the end of the patch maintenance window. **Important** Verify the next execution time. Visit the [SSM Maintenance Window console](https://console.aws.amazon.com/systems-manager/maintenance-windows) , search for your newly created patch maintenance window, and verify the next execution time. If you have any questions or need to edit your patch maintenance window, create a service request to talk with an AMS patch expert To schedule a CRON-based patch maintenance window using CloudFormation, see [Create a patch maintenance window using CloudFormation for AMS Accelerate](acc-p-maint-window-cfn.md). # Create a patch maintenance window using CloudFormation for AMS Accelerate To create an AMS Accelerate patch maintenance window using AWS CloudFormation, first log into your Accelerate account and select the AWS Region where your target instances reside. Then follow these steps on the [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/): 1. Select one of two custom Accelerate patching CloudFormation templates. + Patch Tuesday Scheduling: Microsoft releases patches for its operating systems on the second Tuesday of each month, also know as Patch Tuesday, to schedule patch maintenance windows on the first or second weekends after Patch Tuesday: Once logged into the Accelerate console, use this link [ PatchTuesdayScheduling CloudFormation template](https://console.aws.amazon.com/cloudformation/home?#/stacks/create/parameters?templateURL=https://ams-patch-templates-us-east-1.s3.amazonaws.com/AmsPatchMaintenanceWindowTemplatePatchTuesdayScheduling.yml) . + CRON Scheduling: To create patch maintenance windows using CRON to define the start day, use this link [ CRONScheduling CloudFormation template](https://console.aws.amazon.com/cloudformation/home?#/stacks/create/parameters?templateURL=https://ams-patch-templates-us-east-1.s3.amazonaws.com/AmsPatchMaintenanceWindowTemplateCronScheduling.yml). Remember that Systems Manager CRON numbers days 1-7 (for details on Systems Manager CRON, see [Reference: Cron and rate expressions for Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/reference-cron-and-rate-expressions.html)). Choosing one of these links causes the template to load automatically on the CloudFormation console. Then click **Next**. 1. On the **Specify stack details** page (step 2 of the Create Stack pages), enter a stack name and template parameters (default parameters shown are AMS recommended defaults, select day and times for your use case). When finished, click **Next**. 1. Configure Stack Options (Optional). For information on the options, see [Setting AWS CloudFormation stack options](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-add-tags.html). When finished, click **Next**. 1. Review your stack values (Optional). For information on reviewing stack details to estimate costs, see [Reviewing your stack and estimating stack cost](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-using-console-create-stack-review.html). When ready, click **Create stack**. The stack may take up to a minute to create. Once the stack is created successfully, your patch maintenance window runs at the specified time. You can make changes to your patch maintenance window by creating and executing a CloudFormation change set (recommended) (for details on doing this, see [Creating stacks using changesets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stacks-changesets.html)), or by updating the patch maintenance window on the Systems Manager **Maintenance window** console ([https://console.aws.amazon.com/systems-manager/maintenance-windows](https://console.aws.amazon.com/systems-manager/maintenance-windows)). [![AWS Videos](http://img.youtube.com/vi/https://www.youtube.com/embed/6fSfFeFn6Vc/0.jpg)](http://www.youtube.com/watch?v=https://www.youtube.com/embed/6fSfFeFn6Vc) # Create a maintenance window from the Systems Manager console for AMS Accelerate To create an AMS Accelerate maintenance window from the Systems Manager console, follow these steps: 1. In the left navigation bar in the **Change management** area, click **Maintenance Windows**, and then click **Create Maintenance Window** at the top right of the screen. Fill in the form. For details on any of the options, see [Create a maintenance window (console)](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-maintenance-create-mw.html). When finished, click **Create maintenance window**. The maintenance windows list page opens. 1. Select the newly created maintenance window. The maintenance window details page opens. 1. Go to the **Targets** tab and choose **Register target**. The **Register target** page opens. 1. Add your Accelerate target. For information on targets, see [Assign targets to a maintenance window (console)](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-maintenance-assign-targets.html). When finished, click **Register target**. Make note of the target as you need it later. The maintenance windows details page reopens on the **Targets** tab with a list including the new target. 1. On the **Tasks** tab of the maintenance window details page, choose **Register Task**, and then pick **Register Automation task** from the drop-down list. Fill in the form. Accelerate notes: + Provide a meaningful task name. For example: AcceleratePatch. + In the **Automation document** area click in the search box, choose **Owner**, then **Shared documents**. + Select the automation document by clicking in the search box and choosing **Document name prefix** --> ** Equals** and then typing: **AWSManagedServices-PatchInstance**. Then select the **AWSManagedServices-PatchInstance** document by selecting its radio button. + Under document version, choose **Default version at runtime**. + In the **Targets** section: + Set **Target by:** to **Selecting registered target groups**. + In the list of targets, select the target you registered in the **Targets** tab. + In the **Input parameters** section, fill in the form. + **InstanceId**: `{{TARGET_ID}}` + **StartInactiveInstances**: `True` to start the instances if they are stopped during the patch maintenance window. **Note** The **InstanceId** parameter value is case sensitive and the **StartInactiveInstances** parameter value can be either True or False. Stopped instances cannot be started when targeted by tags. For more information, see [No Invocations to Execute](https://aws.amazon.com/premiumsupport/knowledge-center/ssm-no-invocations-automation). + In the **Rate control** section, choose percentages. AMS Accelerate recommends **100%** for **Concurrency** and **100%** for **Error threshold** to attempt to patch all instances simultaneously, regardless of automation errors. If you wish to patch half your targets at a time, for example, to keep a half of the target instances behind a load balance running, set **Concurrency** to 50%. + In the **IAM service role** section,choose **Use a custom service role**, then choose the **ams\$1ssm\$1automation\$1role**. Click **Register Automation task**. The patching maintenance window is created. Under the **Description** tab, you can see the **Next execution time**. # Create a maintenance window with the Systems Manager command line interface (CLI) for AMS Accelerate To create an AMS Accelerate maintenance window with the command line interface: 1. Follow the SSM [ Tutorial: Create and configure a maintenance window (AWS CLI) ](https://docs.aws.amazon.com/systems-manager/latest/userguide/maintenance-windows-cli-tutorials-create.html). For each step of the tutorial, here are sample CLI commands for patching. **Note** These examples are specific to Linux or macOS. The commands can also be run from AWS CloudShell which may be simpler than configuring `awscli` on a local machine. For details, see [Working with AWS CloudShell](https://docs.aws.amazon.com/cloudshell/latest/userguide/working-with-cloudshell.html). 1. In step 1 of the tutorial, to create a maintenance window: ``` aws ssm create-maintenance-window \ --name Sample-Maintenance-Window \ --schedule "cron(0 30 23 ? * TUE#2 *)" \ --duration 4 \ --cutoff 1 \ --allow-unassociated-targets \ --tags "Key=Environment,Value=Production" ``` On successful completion, `window-id` is returned. 1. In step 2 of the tutorial, to register a target node: ``` aws ssm register-target-with-maintenance-window \ --window-id "mw-xxxxxxxxx" \ --resource-type "INSTANCE" \ --target "Key=tag:Environment,Values=Prod" ``` On successful completion, `WindowTargetID`s are returned. 1. In step 3 of the tutorial, to register a task: ``` aws ssm register-task-with-maintenance-window \ --window-id "mw-xxxxxx" \ --targets "Key=WindowTargetIds,Values=63d4f63c-xxxxxx-9b1d-xxxxxfff" \ --task-arn "AWSManagedServices-PatchInstance" \ --service-role-arn "arn:aws:iam::AWS-Account-ID:role/ams_ssm_automation_role" \ --task-invocation-parameters "{\"Automation\":{\"DocumentVersion\":\"\$DEFAULT\",\"Parameters\":{\"InstanceId\":[\"{{TARGET_ID}}\"],\"StartInactiveInstances\":[\"True\"]}}}" \ --max-concurrency 50 \ --max-errors 50 \ --name "AutomationExample" \ --description "Sample Description" \ --task-type=AUTOMATION ``` # Patch with hooks You can configure AMS patching to run operating-system (OS) level commands before and after patching, using AMS patch hooks. Use AMS patch hooks to run SSM Command documents to stop a service before patching and then start the service after patching, or to run commands to confirm that your application is healthy after patching. To use AMS patch hooks, you need to do the following: 1. Create SSM Command documents to use as patch hooks. 1. Create an AMS patch maintenance window, or use an existing AMS patch maintenance window. For details, see [AMS patch maintenance window](https://docs.aws.amazon.com/managedservices/latest/accelerate-guide/acc-p-maint-window.html). 1. Configure an AMS patch maintenance window to use your SSM Command documents for AMS patch hooks. ## AMS patch hooks RACI The responsible, accountable, consulted, and informed, or RACI, matrix assigns the primary responsibility to either the customer or AMS for a variety of activities. The following table provides an overview of the responsibilities of customer and AMS for activities in an application that uses AMS patch hooks. + R stands for the responsible party that does the work to achieve the task + A stands for the accountable party + C stands for consulted; the party whose opinions are sought, typically as subject matter experts; and with whom there is bilateral communication + I stands for informed; the party that is informed on progress, often only on completion of the task or deliverable | Activity | Customer | AMS | | --- | --- | --- | | Create pre/post patch SSM Command document and document content | R | C | | Configure patch hook parameters for AMS patching | R | C | | Execute pre/post patch SSM Command document | I | R | | Triage and respond to patch hook failures | I | R | | Notify customer of patch hook failure | I | R | | Rollback to a pre-patch state if requested by customer | C | R | ## Create SSM documents for patch hooks AMS patch hooks use Amazon EC2 Systems Manager (SSM) documents during patching. Create an SSM Command document, or share an existing SSM Command document, with the account where patching occurs. For information about SSM documents, including limitations, see [Sharing SSM documents](https://docs.aws.amazon.com/systems-manager/latest/userguide/documents-ssm-sharing.html). To create an SSM Command document, follow these steps: 1. Create an [SSM document with **Document Type** = "Command"](https://docs.aws.amazon.com/systems-manager/latest/userguide/create-ssm-console.html). 1. Enter your command(s) in the **Content** section. For more information, see [Creating SSM document content](https://docs.aws.amazon.com/systems-manager/latest/userguide/documents-creating-content.html). **Note** SSM documents for AMS patch hooks can also be created with AWS CLI or CloudFormation. If you need assistance creating SSM documents for your AMS patch hooks, contact your Cloud Architect. ## Configure AMS patch maintenance window to use your SSM Command documents as AMS patch hooks An AMS patch maintenance window is a Systems Manager maintenance window that executes your configured AMS patch automation. To edit an AMS patch maintenance window to use patch hooks, follow these steps: 1. On the [https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/), under **Change Management Tools** in the left navigation pane, select **Maintenance Windows**. A page listing existing maintenance windows opens. 1. Select a Window ID that starts with **mw-**. The details page for that maintenance window opens. 1. Select the **Tasks** tab and the Window Task ID with the Task ARN of **AMS-PatchInstance** and click **Edit**. ![\[AWS Systems Manager maintenance window tasks interface showing three AWSManagedServices-PatchInstance tasks.\]](http://docs.aws.amazon.com/managedservices/latest/accelerate-guide/images/mwindow-detail-edit-border.png) 1. Scroll down to the **Parameters** section and update the following parameters. AMS patch hook parameters: + **PrePatchHook**: The name of the SSM document with type "Command" that you want to run before patching. Leave this blank or type "AWS-Noop" (case-sensitive) if you aren’t running a command before patching. + **PostPatchHook**: The name of the SSM document with type "Command" that you want to run after patching. Leave this blank or type "AWS-Noop" (case-sensitive) if you aren’t running a command after patching. + **ExecutePatchBasedOnPreHookStatus**: Run patching based on the success or failure of the PrePatchHook run, choose one: + **OnPreHookSuccess**: Only run AMS patch automation when the PrePatchHook is successful. + **Always**: Run AMS patch automation when the PrePatchHook is successful and when it fails. + **OnPreHookFailure** - Run AMS patch automation only when the PrePatchHook fails. + **Never**: Do not run AMS patch automation. This may be useful when testing your PrePatchHook. + **ExecutePostHookBasedOnPatchStatus**: Run the post-patch hook based on success or failure of the AMS patch automation, choose one: + **OnPatchSuccess**: Only run the PostPatchHook when AMS patch automation runs successfully. + **Always**: Run the PostPatchHook when AMS patch automation is successful and when it fails. + **OnPatchFailure** - Run the PostPatchHook only when AMS patch automation fails. **Note** If any of these variables are missing their text box, remedy this by scrolling up to the **Automation document** section on the same page and selecting a different document and then re-selecting the original document. This refreshes input parameters so you can edit them. # AMS Accelerate patch baseline A patch baseline defines which patches are approved for installation on your instances. You can specify approved or rejected patches one by one. 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. ## Default patch baseline When you onboard to AMS Accelerate patching, the default patch baselines are overridden by the AMS Accelerate default patch baselines for the following operating systems. + **Windows** + **Amazon Linux 1** + **Amazon Linux 2** + **CentOS** + **Suse** + **Rhel** + **Ubuntu** **Important** Default patch baselines are managed by AMS. Do not edit default patch baselines as your changes may be lost. Instead, create a custom patch baseline. See [Custom patch baseline with AMS Accelerate](acc-patch-baseline-custom.md) **Note** The AMS Accelerate patch baselines defined as **product = \$1** mean that all patches are applied to the instance of all security and classifications. # Custom patch baseline with AMS Accelerate To use a custom patch baseline with AMS Accelerate, first make sure that you have a patch group, and then create the custom baseline. For more information, see the following resources: + [ Working with patch groups](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-patch-group-tagging.html) + [ Creating a custom patch baseline (Windows)](https://docs.aws.amazon.com/systems-manager/latest/userguide/create-baseline-console-windows.html) + [ Creating a custom patch baseline (Linux)](https://docs.aws.amazon.com/systems-manager/latest/userguide/create-baseline-console-linux.html) + [ Updating or deleting a custom patch baseline (console)](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-baseline-update-or-delete.html) # Creating an IAM role for on-demand patching of AMS Accelerate After your account is onboarded to AMS Accelerate patching, AMS Accelerate deploys a managed policy, **amspatchmanagedpolicy**. This policy contains the required permissions for on-demand patching using the AMS automation document `AWSManagedServices-PatchInstance`. To use this automation document, the account administrator creates a IAM role for users. Follow these steps: **Create a role using the AWS Management Console**: 1. Sign in to the AWS Management Console and open the [IAM console](https://console.aws.amazon.com/iam/). 1. In the navigation pane of the console, choose **Roles**, then **Create role**. 1. Choose the **Another AWS account** role type. 1. For **Account ID**, enter the AWS account ID that you want to grant access to your resources. The administrator of the specified account can grant permission to assume this role to any IAM user in that account. To do this, the administrator attaches a policy to the user, or a group, that grants permission for the **sts:AssumeRole** action. That policy must specify the role's Amazon Resource Name (ARN) as the resource. Note the following: + If you are granting permissions to users from an account that you do not control, and the users will assume this role programmatically, then choose **Require external ID**. The external ID can be any word or number that is agreed upon between you and the administrator of the third-party account. This option automatically adds a condition to the trust policy that enables the user to assume the role only if the request includes the correct **sts:ExternalID**. For more information, see  [ How to use an external ID when granting access to your AWS resources to a third party](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html). + If you want to restrict the role to users who sign in with multi-factor authentication (MFA), choose **Require MFA**. This adds a condition to the role's trust policy that checks for an MFA sign-in. A user who wants to assume the role must sign in with a temporary one-time password from a configured MFA device. Users without MFA authentication can't assume the role. For more information about MFA, see  [Using multi-factor authentication (MFA) in AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa.html). 1. Choose **Next: Permissions**. IAM includes a list of policies in the account. Under **Add Permissions**, enter **amspatchmanagedpolicy** in the filter box and select the checkbox for this permissions policy. Click **Next**. 1. Under **Role details**, enter a Role name such as PatchRole, add a description for the role (recommended), also add tags to help you identify this role. Role names aren't case sensitive, but must be unique within the AWS account. When finished, click **Create Role**. **Note** Role names can't be edited after they've been created. # Understand patch notifications and patch failures in AMS Accelerate **Important** Beginning February 1, 2025, AMS customers will no longer receive notifications for empty Patch Maintenance Windows in their managed accounts. ## Patch service requests and email notifications AMS creates a new service request four days before the next Patch Maintenance Window. For example, four days before a Patch Maintenance Window named **App1 PROD** runs, AMS creates a service request titled **April Patch Maintenance Window for App1 Prod for Account [account id]**. Use the patch service request to communicate with AMS if you need adjustments to your scheduled patch, or to skip an upcoming patch. When a service request is created, an email is sent to your patch notification address with a link to the service request. You receive an additional email each time that AMS updates the service request. **Note** AMS creates a new service request, even if the Patch Maintenance Window is created less than four days before it's scheduled to run. The [Patch Maintenance window must be in an “enabled” state](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-maintenance-disable.html) to receive Service Request notifications. One hour before patching begins, AMS notifies you through the patch service request. After patching completes, AMS updates the patch service request with a link to the Patch Manager console. Use the link to view patch compliance for the instances targeted by the Patch Maintenance Window. **Note** The links in the Patch Manager console show the current compliance of the instances. Patch Manager shows an instance as non-compliant if new patches are released between the time that AMS completes patching and you access the link. ## Patch notifications through CloudWatch Events AMS sends CloudWatch Events three times during the patch process including the following: + Four days before the Patch Maintenance Window runs. + One hour before the Patch Maintenance Window runs. + When the Patch Maintenance Window completes. The following is the Patch Maintenance Window advanced notice event schema: ``` { "version": "0", "id": "37004d81-458d-2cef-fe1c-8afa8af30406", "detail-type": "AMS Patch Window Execution State Change", "source": "aws.managedservices", "account": "145917996532", "time": "2021-05-20T02:00:00Z", "region": "us-east-1", "resources": [ "arn:aws:ssm:us-east-1:123456789012:maintenancewindow/mw-00000001235", "arn:aws:ec2:us-east-1:123456789012:instance/i-0000000aaaaaaaaaa", "arn:aws:ec2:us-east-1:123456789012:instance/i-0000000aaaaaaaaab" ], "detail": { "State": "PREEMPTIVE", "StartTime": "2021-05-24T02:00:00.000000", "WindowArn": "arn:aws:ssm:us-east-1:123456789012:maintenancewindow/mw-00000001235", "Results": "[{\"instanceId\": \"i-0000000aaaaaaaaaa\"}, {\"instanceId\": \"i-0000000aaaaaaaaab\"}]" } } ``` The following table describes the Patch Maintenance Window advance notice event schema: **Patch notification details** | Property name | Description | Sample values | | --- | --- | --- | | State | The state of the patching maintenance window | PREEMPTIVE - The patching window scheduled to begin soon | | Status | The status of the patching maintenance window | SUCCESS - All instances were patch without failure FAILED – At least one instance has failed to patch | | StartTime | The start time, in ISO format, of the patching maintenance window | 2021-02-03T22:14:05.814308 | | WindowArn | The unique identifier of the Patching Maintenance Window | arn:aws:ssm:us-east-1: 123456789012:maintenancewindow/mw-00000001235 | | Results | The list of instances that are targeted by the patch window | InstanceId – the instance ID of the targeted instance | The following is the Patch Maintenance Window end event schema: ``` {"version": "0", "id": "0f25add5-44a9-0702-d2bc-bd2102affefe", "detail-type": "AMS Patch Window Execution State Change", "source": "aws.managedservices", "account": "123456789012", "time": "2021-02-03T22:14:06Z", "region": "us-east-1", "resources": [ "arn:aws:ssm:us-east-1:123456789012:maintenancewindow/mw-00000001235", "arn:aws:ec2:us-east-1:123456789012:instance/i-0000000aaaaaaaaaa", "arn:aws:ec2:us-east-1:123456789012:instance/i-0000000aaaaaaaaab" ], "detail": {"State": "[COMPLETED]", "Status": "SUCCESS", "StartTime": "2021-02-03T22:12:00.814308", "EndTime": "2021-02-03T22:14:05.814309", "WindowArn": "arn:aws:ssm:us-east-1:123456789012:maintenancewindow/mw-00000001235", "WindowExecutionId": "e32088eb-c05f-4c63-b766-6866e163c818", "Results": "[{\"instanceId\": \"i-0000000aaaaaaaaaa\", \"status\": \"Success\", \"missing_critical_patch_count\": 0, \"missing_total_patch_count\": 0} }, {\"instanceId\": \"i-0000000aaaaaaaaab\", \"status\": Success}, \"missing_critical_patch_count\": 0, \"missing_total_patch_count\": 0}]" } } ``` The following table describes the Patch Maintenance Window end event schema: **Patch window end details** | Property name | Description | Sample values | | --- | --- | --- | | State | The state of the patching maintenance window | COMPLETED – The patching window is finished | | Status | The status of the patching maintenance window | SUCCESS – All instances were patch without failure FAILED – At least one instance has failed to patch | | StartTime | The start time, in ISO format, of the patching maintenance window | 2021-02-03T22:14:05.814308 | | EndTime | The end time, in ISO format, of the patching maintenance window | 2021-02-03T23:14:05.814308 | | WindowArn | The unique identifier of the patching maintenance window. | arn:aws:ssm:us-east-1: 123456789012:maintenancewindow/mw-00000001235 | | WindowExecutionId | The window execution ID, which can be seen from the SSM Maintenance Window Console | e32088eb-c05f-4c63-b766-6866e163c818 | | Results | The list of instances that will be targeted by the patch window | InstanceId – the instance ID targeted status – the instance patch status missing\$1critical\$1patch\$1count - the count of critical patches missing on the instance missing\$1total\$1patch\$1count - the count of total patches missing on the instance | You can use the CloudWatch Events event to trigger a CloudWatch rule that notifies you when a Patching Maintenance Window advance notice is sent. To do this, configure the CloudWatch rule with the following configuration: ``` { "source": [ "aws.managedservices" ], "detail-type": [ "AMS Patch Window Execution State Change" ], "detail": { "State": ["PREEMPTIVE"] } } ``` **Note** Patch failure alerts aren't created for instances that have unsupported operating systems, or that are stopped during the maintenance window. ## Patch failure investigation in AMS AWS Managed Services (AMS) manages patching and includes patch failure remediation. When patching fails, AMS Operations is alerted and attempts remediation by following AWS and AMS best practices to address the issue. If a patch fails, then AMS creates an SSM OpsItem in the account with the following title: **AWS Managed Services – Patch Instance failure for instance **. AMS then investigates the OpsItem. If AMS can correct the failure without your intervention, then AMS resolves the OpsItem. If your intervention is required, then AMS notifies you through a service request that contains the investigation results and the recommended remediation steps. If you don't take action to resolve the issue, then AMS attempts to patch the instance during the next scheduled Patch Maintenance Window. **Note** Patch failure OpsItems aren't created for instances that have unsupported operating systems, or that are in the Stopped state during the Patch Maintenance Window.