# AMS standard patching
AMS supports existing customers using the AMS standard patching model, but this model is not available for new customers and is being retired in favor of AMS Patch Orchestrator.
Typical patch contents for AMS standard patching include vendor updates for supported operating systems and software preinstalled with supported operating systems (for example, IIS and Apache Server).
During AMS onboarding, you specify patching requirements, policy, frequency, and preferred patch windows. These configurations mean you can avoid taking applications offline all at once for infrastructure patching, so you can control what infrastructure gets patched when.
**Note**
The patching process described in this topic applies only to your stacks. AMS infrastructure is patched during a separate process. The AWS Managed Services Maintenance Window (or Maintenance Window) performs maintenance activities for AWS Managed Services (AMS) and recurs the second Thursday of every month from 3 PM to 4 PM Pacific Time. AMS may change the maintenance window with 48 hours notice. You configure the AMS patch window at onboarding, or you approve or reject the monthly patch service notification.
AMS regularly scans managed Amazon EC2 instances for updates available through the operating system update functionality. We also provide regular updates to the AMS base Amazon Machine Images (AMIs) supported in our environment.
After they are validated, AMS AMI releases are shared with all AMS accounts. You can view the available AWS AMI releases by using the [DescribeImages](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeImages.html) Amazon EC2 API call or using the Amazon EC2 console. To find available AMS AMIs, see [Find AMI IDs, AMS](find-ami.md).
AMS performs ad hoc patching schedules only when requested by you.Previously AMS would send a notification; currently, a notification is not sent.
**Note**
By default, AMS uses Systems Manager to apply patches by having the package manager (Linux) or System Update service (Windows) query its default repository to see which new packages are available. If, during the course of your day-to-day operations, you have installed a package on a Linux host using the default package manager, that package manager also picks up new packages for that software when they're available. In such a case, you may want to take a patching action (described in this section) to opt-out for that instance.
## Supported operating systems
**Supported operating systems (x86-64)**
+ Amazon Linux 2023
+ Amazon Linux 2 (**expected AMS support end date June 30, 2026**)
+ Oracle Linux 9.x, 8.x
+ Red Hat Enterprise Linux (RHEL) 9.x, 8.x
+ SUSE Linux Enterprise Server 15 SP6
+ SUSE Linux Enterprise Server for SAP 15 SP3 and later
+ Microsoft Windows Server 2025, 2022, 2019, 2016
+ Ubuntu 20.04, 22.04, 24.04
**Supported operating systems (ARM64)**
+ Amazon Linux 2023
+ Amazon Linux 2 (**expected AMS support end date June 30, 2026**)
## Supported patches
AWS Managed Services supports patching primarily at the operating system level. The patches that are installed may differ by operating system.
**Important**
All updates are downloaded from the Systems Manager patch baseline service remote repositories configured on the instance, and described later in this topic. The instance must be able to connect to the repositories so the patching can be performed.
To opt-out of the patch baseline service for repositories that deliver packages that you want to maintain yourself, run the following command to disable the repository:
```
yum-config-manager DASHDASHdisable REPOSITORY_NAME
```
Retrieve the list of currently configured repositories with the following command:
```
yum repolist
```
+ **Amazon Linux** preconfigured repositories (usually four):
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/managedservices/latest/userguide/patch-overview.html)
+ **Red Hat Enterprise Linux** preconfigured repositories (five for Red Hat Enterprise Linux 7 and five for Red Hat Enterprise Linux 6):
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/managedservices/latest/userguide/patch-overview.html)
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/managedservices/latest/userguide/patch-overview.html)
+ **CentOS 7** preconfigured repositories (usually five):
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/managedservices/latest/userguide/patch-overview.html)
+ For **Microsoft Windows Server**, all updates are detected and installed using the Windows Update Agent, which is configured to use the Windows Update catalog (this doesn't include updates from Microsoft Update).
On Microsoft Windows operating systems, Patch Manager uses Microsoft’s cab file wsusscn2.cab as the source of available operating system security updates. This file contains information about the security-related updates that Microsoft publishes. Patch Manager downloads this file regularly from Microsoft and uses it to update the set of patches available for Windows instances. The file contains only updates that Microsoft identifies as being related to security. As the information in the file is processed, Patch Manager also removes updates that have been replaced by later updates. Therefore, only the most recent update is displayed and made available for installation. For example, if KB4012214 replaces KB3135456, only KB4012214 is made available as an update in Patch Manager.
To read more about the wsusscn2.cab file, see the Microsoft article [Using WUA to Scan for Updates Offline](https://msdn.microsoft.com/en-us/library/windows/desktop/aa387290(v=vs.85).aspx).
## Patching and infrastructure design
AMS employs different patching methods depending on your infrastructure design: mutable or immutable (for detailed definitions, see [AMS key terms](key-terms.md)).
With mutable infrastructures, patching is done using a traditional in-place methodology of installing updates directly to the Amazon EC2 instances, individually, by AMS operations engineers. This patching method is used for stacks that are not Auto Scaling groups, and contain a single Amazon EC2 instance or a few instances. In this scenario, replacing the AMI that the instance or stack was based on would destroy all of the changes made to that system since it was first deployed, so that is not done. Updates are applied to the running system, and you may experience system downtime (depending on the stack configuration) due to application or system restarts. This can be mitigated with a Blue/Green update strategy. For more information, see [AWS CodeDeploy Introduces Blue/Green Deployments](https://aws.amazon.com/about-aws/whats-new/2017/01/aws-codedeploy-introduces-blue-green-deployments/).
With immutable infrastructures, the patching method is AMI replacement. Immutable instances are updated uniformly using an updated AMI that replaces the AMI specified in the Auto Scaling group configuration. AMS releases updated (that is, patched) AMIs every month, usually the week of Patch Tuesday. The following section describes how this works.
# How AMS standard patching works
AMS uses the Systems Manager Run Command service for regularly scheduled monthly and as-needed critical patching, with two principal patching methods, in-place and AMI replacement, depending on your infrastructure deployment strategy (mutable vs. immutable). This section describes the AMS patching service, types, methods, and processes.
AMS defines two patch types, which are scheduled differently:
+ *Critical patching*: Updates are applied as quickly as possible, after acceptance of the notice.
+ *Standard patching*: Regular OS vendor updates and applied monthly.
Patches are applied through either in-place patching or AMI replacement (upon request).
## Update scanning
AMS uses the [Amazon EC2 Run Command Service](https://aws.amazon.com/ec2/run-command/) to contact your Amazon EC2 stacks and deploy the required scanning and patching scripts. AMS uses the native package management component already installed on the supported operating system to perform all the required scanning and patching behavior on the Amazon EC2 stack. For Red Hat and Amazon Linux, the service uses yum. For Windows, the service uses the Windows Update Agent.
Scans are performed daily using [SSM Maintenance Windows](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-maintenance.html) and the AMS default AWS-RunPatchBaseline document. Every reachable Amazon EC2 stack is scanned, using the update repositories for Linux and Windows. The AMS patching process detects all reachable Amazon EC2 stacks and then performs the scans in a batch process so that the stack always remains in a healthy state, even if a failure occurs while running the scan. The scan results are then saved for each Amazon EC2 stack.
To view the scan results for a stack or instance, submit a service request with the stack ID or instance ID.
The default AMS patching process is to install all available patches regardless of patch classification or severity (for example, critical versus standard). The exception to this are patches that you have explicitly excluded for the stack (patches defined as mandatory by AMS should not be excluded).
You're sent a patching service notification 14 days before the proposed maintenance window. This gives you time to test the proposed patches and accept or reject them. If you don't reply to the patching service notification, your instances aren't patched. When the time comes to install the patches, AMS creates a Request for Change (RFC) for each stack, and that RFC appears in your account's RFC list.
## AMS configured maintenance window and notice
With AMS configured patching, each account has a monthly maintenance window, which you define when you onboard your account. The AWS Managed Services Maintenance Window (or Maintenance Window) performs maintenance activities for AWS Managed Services (AMS) and recurs the second Thursday of every month from 3 PM to 4 PM Pacific Time. AMS may change the maintenance window with 48 hours notice.
The patching window is different. The patching outbound service request (also known as a *service notification*) includes a suggested patch window.
**Note**
For information about replying to the patching service notification, see [Actions you can take in AMS standard patching](patch-actions.md).
The patching service notification is sent by email to the contact email address on file for your account. The notification includes a link to the AWS Support console where you can respond to it. You can also respond to the notification using the AMS Service Request page. The service notification includes:
+ A list of update IDs (CSUs, IUs, and OUs) that apply to the stack, and those updates that you have requested be excluded from patching (if any).
+ IDs of instances that will be affected.
+ A proposed patching window when the updates will be applied. You can request a different patching window.
+ A request that you accept the proposed patching, or ask for additional information. AMS gives you time to test the impact of the updates and approve or reject the patching, or ask that specific updates be excluded. If you need more time to test, and want the updates to be applied after your testing, respond to the service notification and describe what you want, or submit a service request for a new patch RFC based on the details of the previous RFC. If you don't reply to the service notification at all, no patching action is taken and the RFC is cancelled.
If you approve the service notification, AMS runs the patch RFC and applies the updates within the agreed-to patch window, as per the service commitment.
When patching is finished, AMS sends you a correspondence in the Service Request, with a summary of the outcome of the patching activity (that is, success or failed).
# In-place patching
In-place patching refers to a method where AMS logs into each stack instance and applies patches.
In-place patching occurs on mutable infrastructures using Amazon EC2 instances running a supported operating system. Patching applies all non-excluded updates available up to that point. When critical patches are released, there is an additional critical patching process.
## Standard patching: in-place
Standard patching occurs on the agreed-to patch schedule suggested in the patch service notification, and includes regular patch updates that are not deemed critical.
Prior to the proposed patching window, and with your affirmative response to the notification, a patch RFC is created and appears in your RFC dashboard.
## Critical patching: in-place
When an OS vendor releases a critical security update, AMS notifies you of the patch RFC by sending you a service notification (to the contact email for your account) for each stack, according to the AMS service commitment. The service notification includes the following for each update:
+ Update release date
+ Update criticality
+ Update details (KB reference, etc.)
+ IDs of stacks affected
You can test the updates listed in the notification, and approve or reject the patches by replying to the service notification. If you approve the notification, you need to provide a specific patch window per stack for installing the updates.
**Note**
Patch windows that are within 24 hours of reply to the service notification may be rescheduled based on available capacity.
If you don't reply within 10 days or if you reject the proposed patching, the patching is canceled.
If you want to apply the updates after the allowed period (provided in the notification), submit a service request for a new patch schedule based on the details of the previous notification.
If you approve the service notification, AMS applies the updates within your specified patch window, according to the service commitment.
In the case of multiple updates, you can exclude specific updates from the patching by specifying the updates to be excluded in your response to the service notification.
AMS sends you a service notification for each stack, of the outcome of each update (that is, success or fail).
# AMI updates patching (using patched AMIs for Auto Scaling groups)
AMI-replacement patching is done on immutable infrastructures by updating the AMI ID that is configured to deploy new Amazon EC2 instances in an Auto Scaling group.
Amazon Machine Images (AMIs) are released on a regular basis for the supported operating systems. Operating system vendors release new patches on a periodic basis. AMS takes the Amazon-provided AMI, updates it with the latest patches, and then adds the appropriate components to enable it to operate in the AMS environment. Then, it makes the new AMS AMI available to all AMS customers by sharing the AMI to the accounts. Your Auto Scaling group stacks can be refreshed on a monthly basis with these newly released AMS AMIs. The following graphic illustrates how AMIs are used in AMS your environments.
![\[AMI updates patching (using patched AMIs for Auto Scaling groups).\]](http://docs.aws.amazon.com/managedservices/latest/userguide/images/AMIsInCustEnviros.png)
Auto Scaling groups create their instances based on the configured AMI for the Auto Scaling group. When AMS shares updated AMIs, you have the following options depending on how you are managing AMI updates:
+ If you are using an application deployment tool (for example, UserData, CodeDeploy, and so forth) that customizes your instances automatically after they are created, you can do the following:
+ Reply to the patching service notification, or submit a service request, for the latest AMS AMI to replace your current Auto Scaling group's configuration AMI. After the AMI ID in your Auto Scaling groups' configuration is replaced, AMS kicks off rolling updates of your instances and your Auto Scaling group instance configurations (for example, installing applications, boot scripts, etc.) are applied to the new instances created with the new AMS AMI automatically.
+ If you are using a custom/golden AMI in your Auto Scaling groups' configuration, you can:
+ Create an instance with the new AMS AMI, customize the instance and create a new golden AMI. Share the new golden AMI with AMS using the Amazon EC2 console, and submit a service request to AMS to update your Auto Scaling groups' configuration to use your new custom AMI.
+ Share your existing golden AMI with AMS by using the Amazon EC2 console, and submit a service request for AMS to update your golden AMI. To do this, AMS creates an instance from your golden AMI, applies the patches to that instance, creates a new golden AMI for you, and then updates your Auto Scaling groups' configuration to use the new AMI. The drawback here is that AMS cannot test that your new custom AMI works the way you want it to. Instead, you should test the instance created with the new AMI and verify that everything works correctly before creating a new golden AMI, sharing it, and requesting that AMS update your Auto Scaling groups. AMS does not recommend this option.
## Standard patching: AMI updates
Every month AMS releases new Amazon Machine Images (AMIs) with service improvements and new patches that apply to the AMIs.
**Note**
New AMS AMIs are generated after Patch Tuesday from updated AWS AMIs. Then, AMS tests them before making them available. After the new AMIs pass testing, AMS shares updated AMIs to managed accounts.
## Critical patching: AMI updates
When needed, AMS provides AMIs updated with critical security patches released since the last monthly AMI release.
The process for critical security updates to immutable infrastructures is identical to the monthly AMI process for immutable infrastructures, except that a new AMS AMI is created outside the normal schedule (Patch Tuesday), based on the release of new critical updates. AMS makes available a new AMI with the critical security patches according to the service level agreements (SLAs) defined for your account. AMS updates of Auto Scaling groups by request only. Use a service request to submit AMI replacement requests.
## AMS standard patching failures
In case of failed updates, AMS performs an analysis to understand the cause of failure and communicates the outcome of the analysis to you. If the failure is attributable to AMS, we retry the updates if it's within the maintenance window. Otherwise, AMS creates service notifications for the failed instance update and waits for your instructions.
For failures attributable to your system, you can submit a service request with a new patch RFC to update the instances.
# Actions you can take in AMS standard patching
In addition to testing new AMIs, there are several actions you can take to manage the patching of your infrastructure:
+ If it took longer to test the updates than the patch window allowed, you can request that AMS apply the updates that were canceled when you're ready by submitting a service request (use the details in the original service notification as the basis).
+ You can request that an important update (IU) or other update (OU) be applied before the next automated update window by submitting a service request providing a list of the updates, the applicable instances, and other details as appropriate. Since this CT is not automated, it takes longer to schedule and run. Check the service level objectives (SLOs) for the appropriate time. For more information, see [AMS service level objectives (SLOs)](apx-slo.md).
Additionally, you can use existing, patched, AMS AMIs to create custom AMIs. For information, see [AMI \$1 Create](https://docs.aws.amazon.com/managedservices/latest/ctref/deployment-advanced-ami-create.html).
**Note**
You can't request a new AMS AMI based on an important update or other update before the next maintenance window because the AMS AMI release process follows a uniform cadence for the benefit of all AMS customers.
## Changing what gets patched/opting out
With AMS configured patching, in your response to the patching service notification or in a Service Request, you can change what resources get patched. You can do the following:
+ Define a list of patches that should be excluded from remediation, per stack and per operating system.
+ Define a list of resources that should be excluded from certain patches or all patching.
+ Define a list of resources that should be always be excluded from all patching.
+ Define a list of resources that should be patched on a certain day and certain time (good if you haven't defined a maintenance window).
To exclude one or more patches, submit a service request, or respond to the patching service notification using the template provided next. Do not submit an RFC. Include in the request the patch name or names that you want excluded and why. Include this information in a Service Request as follows:
+ Name: The name of the patch. For Windows patches, this is the KB name, such as `KB3145384`. For Linux patches, this is the package name, such as `openssh-6.6.1p1-25.61.amzn1.x86_64`.
+ Reason: A comment indicating why the patch is being excluded.
+ Expiration Time: The date/time when the exclusion expires.
If an excluded patch is already installed, it is removed.
The request is reviewed by an operator who will discuss it with you if excluding those patches poses a significant security risk. The expiry date for excluded patches is also negotiated. After the agreed upon expiry date, the exclusion expires, and the patch is installed on any subsequent patching.
Patches on the exclusion list are still returned in scan results, if applicable.
**Note**
Unlike Windows, Linux patches are version-specific. This distinction is important because new versions of an excluded patch are not automatically excluded. It is your responsibility to notify AMS to exclude new versions of a Linux patch if that's what you want to do.
### Patch service notification reply templates
You must reply to patching service notifications, using the specified format, in order for patching to be performed on your instances. You should do this if you haven't already set a maintenance window with AMS.
When you reply to a service notification, use the format given.
If no maintenance window is set, let us know when to patch what as shown following:
```
UTC StartTime StackId InstanceId (Optional)
2019-04-01 15:00 stack-123456789012 i-1234566789
2019-04-01 15:00 stack-123456789013 i-1234566784
2019-04-01 15:00 stack-123456789014 i-1234566783
2019-04-01 15:00 stack-123456789015 i-1234566782
```
If you have a set maintenance window and want certain resources to be excluded from certain patches, use the following format:
```
StackId InstanceId (Optional) Exclude Patches
stack-123456789012 i-1234566789 PATCH
stack-123456789013 i-1234566784 PATCH
stack-123456789014 i-1234566783 PATCH
stack-123456789015 i-1234566782 PATCH
```
If you have a set maintenance window and want certain resources to always be excluded from all patching, use the following format:
```
StackId InstanceId (Optional) Exclude Patches
stack-123456789012 i-1234566789 ALL
stack-123456789015 i-1234566782 ALL
```
## Preparing for patching
To prepare your environment for automated patching, we recommend the following:
+ Be sure you have a complete inventory of all instances to be patched.
+ Ensure that your resources are backed up regularly as part of your Continuity of Business strategy. Additional backups are created as part of the patch sequence, and these are automatically deleted according to your configured Patch Orchestrator retention policy (default is 60 days).
+ Ensure that all relevant licenses are up to date.
+ Modify your stack maintenance windows to stagger patching so that testing stacks are patched before production stacks. That way, any errors with patching are found in the testing stacks and can be identified before production stacks are patched.
## Viewing patch settings
To find out what your current patching configuration is you can do the following:
+ Submit a service request to AMS with the query.
+ Wait for a patch service notification. The patching notice advises you of all patches to be applied and instances to be patched, and also suggests a patch window.
You can submit a service request to modify the following:
+ Scan Interval: The amount of time, in minutes, between compliance scans performed on instances of this stack.
Default is `240` (4 hours).
+ NotificationWindow: How far in advance (in minutes) of a scheduled change (patch) the notification should be sent to you.
Default is `10080` (7 days).
# AMS standard patching FAQs
This section provides answers to some frequently asked questions.
+ Q: How do I opt out of patching globally?
A: To globally opt out of patching, file a service request. Note that you can't opt out of AMS mandatory patches. All stacks will continue to be scanned so that we can report on vulnerabilities.
+ Q: How do I exclude specific stacks from patching?
A: To permanently exclude specific stacks from patching, submit a service request. To exclude certain stacks from a particular patch cycle, respond to the upcoming patching notice with the list of stacks to exclude. For information, see [Changing what gets patched/opting out](patch-actions.md#patch-excluding-patching). Note that you can't opt out of mandatory patches.
+ Q: What happens if I don't approve a patching service notification?
A: You have 14 days to approve a standard patching service request and 10 days to approve a critical patching notice. If you don't approve the service request within the time period, the service commitment is nullified and no patching occurs. In the case of mandatory patching, patches are applied regardless of response to the service request.
+ Q: How do I exclude specific patches and packages from being installed?
A: To permanently exclude specific patches or packages, submit a service request. To exclude certain patches or packages from a particular patch cycle, respond to the upcoming patching notice with the list of patches or packages to exclude. For details, see [Changing what gets patched/opting out](patch-actions.md#patch-excluding-patching). Note that you can't opt out of mandatory patches.
+ Q: What happens if a system fails as a result of patching?
A: AMS monitors each system. AMS sends a service notification to you of the outcome of each update (that is, success or fail) per stack and instance. If a failure is detected, AMS investigates, works to restore the instance, and then an AMS operations engineer attempts to manually patch. For information, see [AMS standard patching failures](patch-overview.md#patching-process-failures).
+ Q: What updates are managed by AMS?
A: AMS manages operating system level updates that AMS is notified of by the vendor. For more information, see [Supported patches](patch-overview.md#patch-supported).
+ Q: What updates are not managed by AMS?
A: Application-level updates are not managed by AMS.
+ Q: How are Auto Scaling groups updated?
A: Auto Scaling groups are updated with an AMI replacement in the Auto Scaling group configuration and preform a rolling update. A rolling update observes the HealthyHostThreshold setting of your patching configuration, which determines how many Amazon EC2 instances in a stack must be maintained active during patching. For more information, see [AMI updates patching (using patched AMIs for Auto Scaling groups)](patching-method-immutable.md).
+ Q: How do I get updates installed outside the normal cycle?
A: For OS-level updates that you want installed outside of the normal patching schedule, submit a service request by using the patching notification that you received. This might happen if your testing of a proposed patch took longer than 21 days (for a standard patch) or 14 days (for a critical patch). Out-of-band patching can be done in-place for standalone Amazon EC2 instances.
+ Q: How are newly deployed stacks or instances patched?
A: When creating a new Amazon EC2 stack instance or Auto Scaling group, you should always specify the latest AMS AMI, which will have the latest patches on it already. For mutable infrastructures, inline patching should be performed as soon as the stack is deployed.