# Automated operating system patching Automated operating system patching Patch management is an ongoing activity that is a key part of the SAP software lifecycle. It is a critical step in improving security, minimizing risk, remaining compliant, and reducing unplanned downtime. You can use AWS Systems Manager to automate system patching activities. Systems Manager can reduce the manual effort that is required to manage the SAP landscape, which saves time and IT resources. An operating system patching strategy should adhere to SAP software lifecycle best practices. Patches should be applied downstream across the landscape, from development, to test, to production. This allows the patches to be tested in less-critical systems before deploying them into production. Because patching is a repeatable process, it can be automated with Systems Manager and can be documented as a standard operating procedures (SOP). This will ensure consistent patch management across the SAP landscape. The SOP should be updated continuously for future maintenance activities. The sections below describe how to use Systems Manager to apply regular patches that are released by operating system vendors. # Automated operating system patching architecture The diagram below highlights the AWS services that you can use to set up automated operating system patching and optional notifications on the patch status using Amazon Simple Notification Service (Amazon SNS). ![\[The patch architecture uses Systems Manager\]](http://docs.aws.amazon.com/sap/latest/sap-netweaver/images/automation-patch-arch.png) The topics below contain descriptions of key components of the automated operating system patching setup. Familiarize yourself with them before continuing to the prerequisites. **Topics** + [ ## Patch Manager ](#automation-os-patch-patchmanager) + [ ## Lifecycle hooks ](#auto-os-patch-lifecycle-hooks) ## Patch Manager Patch Manager is a capability of AWS Systems Manager that automates the process of patching managed nodes with security-related and general operating system updates. You can use Patch Manager to apply patches for operating systems and applications, such as installing service packs on Microsoft Windows nodes and performing minor version upgrades on Linux nodes. Patch Manager helps to patch fleets of Amazon EC2 instances according to operating system type. This includes versions of Red Hat Enterprise Linux (RHEL), SUSE Linux Enterprise Server (SLES), Oracle Linux, and Microsoft Windows Server that are supported by SAP on AWS. You can patch your instances on a schedule or on-demand by creating a patching configuration. You can also scan instances to see a report of missing patches or to automatically install missing patches. Patch Manager integrates with AWS Identity and Access Management (IAM), Amazon CloudWatch Events, and AWS Security Hub to provide a secure patching experience that includes event notifications and the ability to audit usage. ## Lifecycle hooks Patch Manager allows you to add lifecycle hooks that enable a multi-step, custom patching process. These hooks let you perform a custom action on instances when the corresponding lifecycle event occurs. When you patch the operating system of an SAP application, lifecycle hooks can help you perform SAP-specific operations and automate the operating system patching lifecycle. You can automate the following tasks using lifecycle hooks: + Stop the SAP application and necessary database services + Initiate database or storage snapshot backup + Patch the operating system and reboot if necessary + Start the SAP application and the database after successful operating system patch update For more information about lifecycle hooks, see the following documentation: + [About the AWS-RunPatchBaselineWithHooks SSM document](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager-about-aws-runpatchbaseline.html) in the * AWS Systems Manager User Guide* + [Orchestrating multi-step](https://aws.amazon.com/blogs/mt/orchestrating-custom-patch-processes-aws-systems-manager-patch-manager/) in the * AWS Cloud Operations & Migrations Blog* # Automated operating system patching prerequisites In addition to the prerequisites described in the [Automation prerequisites](sap-nw-automation.md#automation-prerequisites) section of this guide, verify the following prerequisites that are specific to automated operating system patching: + Verify the Patch Manager prerequisites. Because the solution described here uses AWS Systems Manager Patch Manager, you must verify that you have satisfied all of the Patch Manager prerequisites. For more information, see [Patch Manager prerequisites](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager-prerequisites.html) in the * AWS Systems Manager User Guide*. + Ensure you have a backup of your SAP system. Before you make changes to the SAP system, verify that a backup is available to support rollback in case you encounter problems. You should have the following backups: + Operating system backup – You should have an Amazon Machine Image (AMI) backup of the Amazon EC2 instance that consists of the base operating file system (`root` for Linux and `C:\` for Microsoft Windows) and the SAP application and database file systems. + Database backup – If patching will occur on the database server, ensure you have the most recent database backup. For data recovery recommendations, see [Plan for data recovery](https://docs.aws.amazon.com/wellarchitected/latest/sap-lens/design-principle-12.html) in the *SAP Lens AWS Well-Architected Framework*. ## Supported operating systems The following operating systems are supported by SAP and Patch Manager. Check the Patch Manager prerequisites for currently supported versions of the operating systems. For more information, see [Patch Manager prerequisites](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager-prerequisites.html) in the * AWS Systems Manager User Guide*. + Oracle Linux **Note** Oracle Linux is required if you are running an Oracle database. + Red Hat Enterprise Linux (RHEL) + SUSE Linux Enterprise Server (SLES) + Microsoft Windows Server **Note** SUSE Linux and Red Hat Linux have SAP versions of the Linux operating system. SAP recommends that you use RHEL for SAP Solutions/Applications or SLES for SAP Applications to run the SAP application. Oracle Linux operating system is required for Oracle Database Server and SAP NetWeaver Application Servers with Oracle client installed. For more information, see [SAP Note 2358420 - Oracle Database Support for Amazon Web Services EC2](https://me.sap.com/notes/2358420/E) (SAP portal access required). For each of these operating systems, you can bring your own subscription to AWS or use the Amazon Machine Images (AMIs) from the [AWS Marketplace](https://aws.amazon.com/marketplace). ## SAP Notes Review the following SAP Notes. You require SAP portal access to check these references from SAP. + SAP Note: [1656099 - SAP Applications on AWS: Supported DB/OS and Amazon EC2 products](https://me.sap.com/notes/1656099) + SAP Note: [2871484 - SAP supported variants of Red Hat Enterprise Linux](https://me.sap.com/notes/2871484) + SAP Note: [2358420 - Oracle Database Support for Amazon Web Services EC2](https://me.sap.com/notes/2358420) + SAP Note: [62988 - Service Packs for MS SQL Server](https://me.sap.com/notes/62988) + SAP Note: [2235581 - SAP HANA: Supported Operating systems](https://me.sap.com/notes/2235581) # Configuring automated operating system patching The sections below contain detailed instructions on how to configure automated operating system patching. # Configure patch baselines Patch Manager uses patch baselines, which include rules for auto-approving patches within days of their release, as well as a list of approved and rejected patches. For information about patch baselines, see [About patch baselines](https://docs.aws.amazon.com/systems-manager/latest/userguide/about-patch-baselines.html) in the * AWS Systems Manager User Guide*. You can use predefined patch baselines or create custom patch baselines. The sections below contain instructions on how to use both. For information about patch baselines that is specific to Linux, see [How patch baseline rules work on Linux-based systems](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager-how-it-works-linux-rules.html) in the * AWS Systems Manager User Guide*. For information about the differences between Linux and Windows patching, see [Key differences between Linux and Windows patching](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-patch-differences.html) in the * AWS Systems Manager User Guide*. If your system landscape has a combination of Windows Server and Linux operating systems, such as Windows Server for SAP application servers and Linux for database servers, you can define a baseline for each operating system type. # Predefined patch baselines Patch manager provides predefined patch baselines for each of the supported operating systems. If your patching requirement patches the predefined baseline configuration, you might be able to use a predefined patch baseline for operating system patching. Alternatively, you can create your own custom patch baselines. This gives you greater control over which patches are approved or rejected for your environment. For information about predefined patch baselines, see [Viewing AWS predefined patch baselines (console)](https://docs.aws.amazon.com/systems-manager/latest/userguide/view-predefined-patch-baselines.html) in the * AWS Systems Manager User Guide*. **Note** SUSE Linux Enterprise Server for SAP Applications and Red Hat Enterprise Linux for SAP Applications require custom patch baselines. The following table is a subset of the predefined patch baselines in the Patch Manager documentation. To view the full list of predefined patch baselines, see [About predefined baselines](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-patch-baselines.html#patch-manager-baselines-pre-defined) in the * AWS Systems Manager User Guide*. The predefined patch baselines listed here are applicable to SAP. | Name | Supported operating system | Details | | --- | --- | --- | | ` AWS-OracleLinuxDefaultPatchBaseline` | Oracle Linux | Approves all operating system patches that are classified as "Security" and that have a severity level of "Important" or "Moderate". Also approves all patches that are classified as "Bugfix" 7 days after release. Patches are auto-approved 7 days after they are released or updated.¹ | | ` AWS-RedHatDefaultPatchBaseline` | Red Hat Enterprise Linux (RHEL) | Approves all operating system patches that are classified as "Security" and that have a severity level of "Critical" or "Important". Also approves all patches that are classified as "Bugfix". Patches are auto-approved 7 days after they are released or updated.¹ | | ` AWS-SuseDefaultPatchBaseline` | SUSE Linux Enterprise Server (SLES) | Approves all operating system patches that are classified as "Security" and with a severity of "Critical" or "Important". Patches are auto-approved 7 days after they are released or updated.¹ | | ` AWS-DefaultPatchBaseline` | Windows Server | Approves all Windows Server operating system patches that are classified as "CriticalUpdates" or "SecurityUpdates" and that have an MSRC severity of "Critical" or "Important". Patches are auto-approved 7 days after they are released or updated.¹ | ¹ For Amazon Linux and Amazon Linux 2, the 7-day wait before patches are auto-approved is calculated from an `Updated Date` value in `updateinfo.xml`, not a `Release Date` value. Various factors can affect the `Updated Date` value. Other operating systems handle release and update dates differently. For information to help you avoid unexpected results with auto-approval delays, see [How package release dates and update dates are calculated](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager-how-it-works-release-dates.html) in the * AWS Systems Manager User Guide*. # Custom patch baselines Unlike predefined patch baselines, custom patch baselines do not have default patch approvals and compliance levels. This gives you greater control over which patches are approved or rejected for your environment and allows you to define your custom repositories. For example, you can assign specific approval rules and compliance values. It is also possible to create a custom patch baseline by copying a predefined patch baseline and specifying the compliance values that you want to assign to patches. You can use Patch Manager to create a custom patch baseline for Linux-based managed nodes, such as Red Hat Enterprise Linux (RHEL), SUSE Linux Enterprise Server (SLES), Oracle Linux. You can also specify patch source repositories for each of these operating systems. See the sections below for additional information about patch sources for each. For instructions on how to create a custom patch baseline for Linux and Windows, see the following documentation: + [Creating a custom patch baseline (Linux)](https://docs.aws.amazon.com/systems-manager/latest/userguide/create-baseline-console-linux.html) in the * AWS Systems Manager User Guide* + [Creating a custom patch baseline (Windows)](https://docs.aws.amazon.com/systems-manager/latest/userguide/create-baseline-console-windows.html) in the * AWS Systems Manager User Guide* ## Patch sources When you use the default repositories that are configured on a managed node for patching operations, Patch Manager scans for security-related patches or installs them. This is the default behavior for Patch Manager. On Linux systems, you can also use Patch Manager to install patches that aren’t related to security or that are in a different source repository than the default repository that is configured on the managed node. In the procedure to create a custom patch baseline, there is an option to specify alternative patch source repositories if you are not using the default repository configuration. In each custom patch baseline, you can specify patch source configurations for up to 20 versions of a supported Linux operating system. For more information about alternative patch sources, see [How to specify an alternative patch source repository (Linux)](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager-how-it-works-alt-source-repository.html) in the * AWS Systems Manager User Guide*. **Note** If you specify alternative repositories, you must also specify the default repositories as part of the alternative patch source configuration if you want those updates to be applied. The sections below contain information about how to obtain patch source details for SLES for SAP Applications, RHEL for SAP Applications, and Oracle Linux. You can use this information to specify a patch source when you create a custom patch baseline. ## Patch sources for SLES for SAP Applications You can use one of the following patch repositories for SUSE Linux Enterprise Server (SLES) for SAP Applications: + SUSE public cloud update infrastructure + Private repository For information about how to use a private patch repository, see [Private and local repositories](auto-os-patch-private-repo.md) in this guide. The public cloud update infrastructure is a global network of update servers maintained by SUSE on AWS Cloud that provides low-latency access to patches from on-demand instances. Customers that use SUSE on-demand instances in AWS automatically connect to the public cloud update infrastructure on boot. You can view the SUSE patch source server details in the `/etc/hosts` directory. You can connect to the public cloud update infrastructure through an internet gateway in a public subnet, NAT gateway in a private subnet, or through a local data center. To see the repository list, run the command `zypper ls`. By default, all repositories are considered for patching. If you want to only patch certain repositories or if you are using multiple patch sources for repositories, you must explicitly add patch sources based on repository configuration. Complete the following steps to identify the patch source for the repository that you would like to use for patching: 1. Navigate to the following directory to view the repository files: ``` /etc/zypp/repos.d ``` 1. Save the name and configuration for each repository file. For example, you might save the following: + Name – `SUSE_Linux_Enterprise_Server_for_SAP_Applications_x86_64:SLE-Product-SLES_SAPXX-SPX-Updates` + Configuration – ``` name=SLE-Product-SLES_SAPXX-SPX-Updates enabled=1 autorefresh=1 baseurl=plugin:/susecloud?credentials=SUSE_Linux_Enterprise_Server_for_SAP_Applications_x86_64&path=/repo/SUSE/Updates/SLE-Product-SLES_SAP/XX-SPX/x86_64/update/ service=SUSE_Linux_Enterprise_Server_for_SAP_Applications_x86_64 ``` 1. Enter this information when you create the custom patch baseline in the **Patch sources** section of **Patch Manager**. For the full list of steps, see [Creating a custom patch baseline (Linux)](https://docs.aws.amazon.com/systems-manager/latest/userguide/create-baseline-console-linux.html) in the * AWS Systems Manager User Guide*. 1. If you add a patch source for any repository, you must add patch sources for all the repositories that you would like to patch, including the default repositories. **Important** Before you deploy the patch, you must accept the license agreement in the `zypper.conf` configuration file. You can find the file in the following directory: ``` /etc/zypp/zypper.conf ``` To accept the license agreement, uncomment the license agreement property and save it as: ``` autoAgreeWithLicenses = yes ``` ## Patch sources for RHEL for SAP Applications You can use one of the following patch repositories for Red Hat Enterprise Linux (RHEL) for SAP Applications: + Red Hat update infrastructure + Local repository For information about how to use a private patch repository, see [Private and local repositories](auto-os-patch-private-repo.md) in this guide. Red Hat update infrastructure is a global network of update servers maintained by Red Hat on AWS Cloud that provides low-latency access to patches from on-demand instances. Customers that use Red Hat on-demand instances in AWS automatically connect to the Red Hat update infrastructure on boot. The RHEL repositories are stored in the following location: ``` /etc/yum.repos.d/ ``` Complete the following steps to identify the patch source for the repository that you would like to use for patching: 1. Run the following command to view the default, enabled repositories: ``` cat /etc/yum.repos.d/* | grep -B 4 -A 6 "enabled=1" ``` This command returns four lines before and six lines after each repository that is enabled. For example, the command might return something like this: ``` [rhui-client-config-server-8-sap-bundle] name=Red Hat Update Infrastructure 3 Client Configuration for SAP Bundle mirrorlist=https://rhui3.REGION.ce.redhat.com/pulp/mirror/protected/rhui-client- config/rhel/server/8/$basearch/sap-bundle enabled=1 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release sslverify=1 sslcacert=/etc/pki/rhui/cdn.redhat.com-chain.crt sslclientcertexample=/etc/pki/rhui/product/rhui-client-config-server-8-sap-bundle.crt sslclientkeyexample=/etc/pki/rhui/rhui-client-config-server-8-sap-bundle.key ``` 1. Save the name and configuration for each repository file. In this example, you would save the following: + Name – `rhui-client-config-server-8-sap-bundle` + Configuration ``` name=Red Hat Update Infrastructure 3 Client Configuration for SAP Bundle mirrorlist=https://rhui3.REGION.ce.redhat.com/pulp/mirror/protected/rhui-client- config/rhel/server/8/$basearch/sap-bundle enabled=1 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-redhat-release sslverify=1 sslcacertexample=/etc/pki/rhui/cdn.redhat.com-chain.crt sslclientcertexample=/etc/pki/rhui/product/rhui-client-config-server-8-sap-bundle.crt ``` 1. For each entry that was returned by the command in the previous step, create a new patch source when you create a custom patch baseline in the **Patch sources** section of **Patch Manager**. For the full list of steps, see [Creating a custom patch baseline (Linux)](https://docs.aws.amazon.com/systems-manager/latest/userguide/create-baseline-console-linux.html) in the * AWS Systems Manager User Guide*. 1. If you add a patch source for any repository, you must add patch sources for all the repositories that you would like to patch, including the default repositories. ## Patch sources for Oracle Linux On Oracle Linux, the patch baseline uses preconfigured repositories on the managed node. All Oracle Linux Amazon Machine Images (AMIs) can access the public YUM repository. Only licensed Oracle Linux systems can access the Oracle ULN repository. The Oracle Linux repositories are stored in the following location: ``` /etc/yum.repos.d/ ``` Complete the following steps to identify the patch source for the repository that you would like to use for patching: 1. Run the following command to view the default, enabled repositories: ``` cat /etc/yum.repos.d/* | grep -B 4 -A 6 "enabled=1" ``` This command returns four lines before and six lines after each repository that is enabled. For example, the command might return something like this: ``` [o18-appsteream] name=Oracle Linux 8 Application Stream ($basearch) baseurl=https://yum$ociregion.$ocidomain/repo/OracleLinux/OL8/appstream/$basearch/ gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-oracle gpgcheck=1 ``` 1. Save the name and configuration for each repository file. In this example, you would save the following: + Name – `o18-appsteream` + Configuration ``` name=Oracle Linux 8 Application Stream ($basearch) baseurl=https://yum$ociregion.$ocidomain/repo/OracleLinux/OL8/appstream/$basearch/ gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-oracle gpgcheck=1 ``` 1. For each entry that was returned by the command in the previous step, create a new patch source when you create a custom patch baseline in the **Patch sources** section of **Patch Manager**. For the full list of steps, see [Creating a custom patch baseline (Linux)](https://docs.aws.amazon.com/systems-manager/latest/userguide/create-baseline-console-linux.html) in the * AWS Systems Manager User Guide*. 1. If you add a patch source for any repository, you must add patch sources for all the repositories that you would like to patch, including the default repositories. Oracle Linux 7 managed nodes use YUM as the package manager, while Oracle Linux 8 managed nodes use DNF as the package manager. Both package managers have an update notice, which is a file named `updateinfo.xml`. The update notice is a collection of packages that fix specific issues. Individual packages aren’t assigned classifications or severity levels, so Patch Manager assigns the attributes of an update notice to the related packages and installs the packages based on the classification filters specified in the patch baseline. Only patches specified in `updateinfo.xml` are applied if you are using the default patch baseline provided by AWS or if you do not select the option to include non-security update patches when you create a custom baseline. If you create a custom baseline and you do select the option to include non-security update patches, the patches in `updateinfo.xml` and the patches that are not in `updateinfo.xml` are applied. For more information, see [How patch baseline rules work on Oracle Linux](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager-how-it-works-linux-rules.html#patch-manager-how-it-works-linux-rules-oracle) in the * AWS Systems Manager User Guide*. Oracle Linux instances require internet access to the public YUM repository or Oracle ULN in order to download packages. If the Amazon EC2 instance is on a private subnet of an Amazon VPC, you can use a proxy server or a local YUM repository to download packages. For more information, see [Oracle Linux Software Management documentation](https://docs.oracle.com/en/operating-systems/oracle-linux/software-management/) in the Oracle documentation. Alternatively, Oracle Linux systems can work with Oracle Linux Manager for YUM package management. An Oracle Linux Manager system can be in a public subnet while Oracle Linux systems can be in a private subnet. For more information, see [Oracle Linux Manager](https://docs.oracle.com/en/operating-systems/oracle-linux-manager/) in the Oracle documentation. ## Windows Server considerations For additional information about security patches for Windows, see [How security patches are selected](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager-how-it-works-selection.html) and [How patches are installed](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager-how-it-works-installation.html) in the * AWS Systems Manager User Guide*. # Create patch groups You can use patch groups to organize instances for patching. This can help you ensure that you only deploy patches to the correct set of instances and that the patches have been adequately tested before they are deployed. After you create the patch group, you can tag your Amazon EC2 instances to add them to the patch group and then add the patch group to a patch baseline. You might want to organize patch groups by: + Operating system – such as Linux and Windows + Environment – such as development, test, and production + Server function – such as SAP database servers and SAP application servers **Note** An Amazon EC2 instance can only be in one patch group at a time. For more information about patch groups, see [About patch groups](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-patch-patchgroups.html) in the * AWS Systems Manager User Guide*. **Tag Amazon EC2 instances to add to the patch group** After you create the patch group, use tags to add Amazon EC2 instances to the patch group. For detailed steps on how to do this, see [Working with patch groups](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-patch-group-tagging.html) in the * AWS Systems Manager User Guide*. **Add the patch group to a patch baseline** To ensure that the correct patches are installed during the patching execution, you must register the patch group with a patch baseline. When the system applies a patch baseline to an instance, the service checks to see if a patch group is defined for the instance. For detailed steps on how to add a patch group to a patch baseline, see [Add a patch group to a patch baseline](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-patch-group-tagging.html#sysman-patch-group-patchbaseline) in the * AWS Systems Manager User Guide*. **Note** Patch groups are not used in patching operations that are based on patch policies. For more information, see the following: [Using Quick Setup patch policies](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager-policies.html) [Configure the home AWS Region](https://docs.aws.amazon.com/systems-manager/latest/userguide/quick-setup-getting-started.html#quick-setup-getting-started-home) [Creating a patch policy](https://docs.aws.amazon.com/systems-manager/latest/userguide/quick-setup-patch-manager.html#create-patch-policy) # Applying patches After you have created the patch baseline and tagged your Amazon EC2 instances to the patch group, you can apply patches. You can schedule patches or run them on-demand. ## Scheduled patching SAP maintenance activities are usually scheduled in advance. The non-critical SAP systems can be patched in an ad-hoc manner, such as a sandbox system. The patching process should be documented in runbooks. After the system is successfully patched, the patching activities for the downstream SAP systems can be scheduled, either using maintenance windows or directly from Patch Manager. For more information about patching schedules, see the following documentation: + [About patching schedules using maintenance windows](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-patch-scheduletasks.html) in the * AWS Systems Manager User Guide* + [Walkthrough: Creating a maintenance window for patching (console)](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-patch-mw-console.html) in the * AWS Systems Manager User Guide* ## On-demand patching The **Patch now** option in Patch Manager allows you to run on-demand patching operations directly from the Systems Manager console. With this option, you do not need to create a schedule to update the compliance status of your managed nodes or to install patches on non-compliant nodes. Scanning the Amazon EC2 instances allows you to identify systems that are potentially non-compliant, vulnerable, or un-patched. We recommend that you schedule system scans frequently, such as weekly. For detailed instructions on how to run on-demand patching, see [Patching managed nodes on demand](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-on-demand.html) in the * AWS Systems Manager User Guide*. ## Patch summary After the patch baseline has run, you can view the patch status in Patch Manager. For details about the patch summary and how to access it in Patch Manager, see [Viewing patch Dashboard summaries (console)](https://docs.aws.amazon.com/systems-manager/latest/userguide/view-patch-dashboard-summaries.html) in the * AWS Systems Manager User Guide*. ## Patch compliance reports Patch compliance reports allow you to view the status of managed nodes. For more information about compliance reports, including detailed instructions on how to view them, see the following documentation: + [Working with patch compliance reports](https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-compliance-reports.html) in the * AWS Systems Manager User Guide* + [Viewing patch compliance results (console)](https://docs.aws.amazon.com/systems-manager/latest/userguide/viewing-patch-compliance-results.html) in the * AWS Systems Manager User Guide* # Monitoring You can view Patch Manager output after each patch is run. By default, Patch Manager stores the first 48,000 characters of the command output. In some cases, you might want to view the complete log, such as for troubleshooting. In this case, the log output can be stored in Amazon S3. For details about how to store log output in Amazon S3, see [Configuring Amazon CloudWatch Logs Logs for Run Command](https://docs.aws.amazon.com/systems-manager/latest/userguide/sysman-rc-setting-up-cwlogs.html) in the * AWS Systems Manager User Guide*. Another option is to output the logs to Amazon CloudWatch Logs for unified logging. For more information, see [Sending SSM Agent logs to CloudWatch Logs](https://docs.aws.amazon.com/systems-manager/latest/userguide/monitoring-ssm-agent.html) in the * AWS Systems Manager User Guide*. For information about how to set up detailed monitoring and notifications, see [Monitoring AWS Systems Manager](https://docs.aws.amazon.com/systems-manager/latest/userguide/monitoring.html) in the * AWS Systems Manager User Guide*. # Private and local repositories If you would like to manage your operating system repository locally, either within your VPC on AWS or an on-premises data center, without using an outbound internet connection for your instance, you can use a private or local repository. Some reasons to use a private repository are: + They provide access to repositories for Amazon EC2 instances that do not have access to the internet for security reasons. + You have additional add-on products from vendors that are not provided through the public cloud update infrastructure. + You want to deploy an organized and consistent set of patches across mission-critical workloads. Using an online repository might introduce new updates which could lead to inconsistency across the landscape. + You want to improve software download times and reduce bandwidth overhead while patching a large fleet of infrastructure. If you are on SUSE Linux Enterprise Server (SLES) and you want to use private repositories, make sure that the operating system repositories are pointing to the local repository instead of the respective vendor repositories before you use Patch Manager. If you are on Red Hat Enterprise Linux (RHEL) or Oracle Linux, you must use a custom baseline to point to local repositories. # Alternative tools for patching In addition to AWS Systems Manager, there are other automated patching tools that you might use, which are listed below. This list is not exhaustive, but is meant to give you a starting point for doing your own research if you decide to consider alternate tools. ## SUSE Manager SUSE Manager is an infrastructure management tool for Linux systems. With SUSE manager, you can automate software management of SLES< RHEL and OEL operating systems. For more information, and a list of Amazon EC2 instances, see [SUSE Manager Documentation](https://documentation.suse.com/suma/). ## Repository Mirroring Tool (For SUSE Linux) Repository Monitoring Tool (RMT) is a service from SUSE Linux that helps manage private repositories by downloading updates and distributing them across the landscape. This reduces network bandwidth usage and allows you to set more restrictive firewall policies. For more information, see the SUSE Linux [Repository Mirroring Tool Guide](https://documentation.suse.com/sles/15-SP1/single-html/SLES-rmt/index.html). ## Red Hat Satellite (For Red Hat Linux) Red Hat Satellite is a system management solution that enables you to deploy, configure, and maintain your systems across physical, virtual, and cloud environments. Satellite Server synchronizes the content from the Red Hat Customer Portal and other sources, and provides functionality such as fine-grained lifecycle management, user and group role-based access control, integrated subscription management, as well as advanced GUI, CLI, or API access. For more information, see the [Red Hat Customer Portal](https://access.redhat.com/). ## KernelCare (For Red Hat Linux) KernelCare is a live patching system that patches Linux kernel vulnerabilities automatically, with no reboots. It works with all major Linux distributions, such as RHEL, CentOS, Amazon Linux, and Ubuntu. It also interoperates with common vulnerability scanners such as Nessus, Tenable, Rapid7, and Qualys. For more information, see [KernelCare](https://aws.amazon.com/marketplace/pp/prodview-aksvbtgd4utj2) on AWS Marketplace. ## Zypper Package Manager (For SUSE Linux) Zypper is a command-line package manager for installing updating, and removing packages. It can also be used to manage repositories. Zypper offers advantages over graphical package managers such as scripting actions. For more information, see the [Zypper package manager](https://documentation.suse.com/smart/linux/html/concept-zypper/index.html) documentation. # Considerations for multiple accounts When you run SAP workloads in AWS, you must consider an AWS account strategy that meets the security controls of your organization. For example, you might separate SAP from non-SAP workloads and separate production from non-production environments. AWS Systems Manager does not support multi-account patching. In every AWS account with SAP workloads, patch baselines should be created and patch execution should be performed to ensure that patching is applied to all SAP systems. In a multi-account environment, this should also follow the SAP best practice of patching in the development account, then test, and finally in the production AWS account.