Amazon released the EC2 Run Command in 2015 as the first step to extend a bridge back to datacenter, enterprise, and traditional operations environments. Then in 2016, AWS released its patch management solution under the EC2 Systems Manager. Now, all datacenter-style management tools fall under the AWS Systems Manager.
In AWS’ effort to create a one-stop-shop of tools, it understands that not all customers will have environments that are immutable, throwaway, container-driven, or serverless. Many customers on AWS run long-living EC2 instances or operate a hybrid cloud, which means that patching is not just required but vital to maintaining security at the operating system level. So, can AWS Systems Manager Patch Manager (AWS SMPM) be a one-stop-shop for your company?
Before we dive into an analysis, let’s take a look at the problems AWS is trying to solve: patching Microsoft Windows and patching (various) Linux distributions.
Solving the Patching Problem on Microsoft Windows
Companies have been patching Windows since WinNT days, so this is nothing new. Some companies use third-party applications, while many use Microsoft System Center Configuration Manager (SCCM) and/or Windows Server Update Services (WSUS) to deploy patches to their environment. These tools traditionally patch long-living, highly stateful servers. They maintain system catalogs and have the features you’d expect: patch groups, retries, scans and reports, and deployments.
SCCM is far more feature-rich in that it is a full configuration management utility that can deploy packages and be used to update third-party patches, etc. Microsoft SCCM is a licensed tool that comes with annual licensing. Microsoft WSUS is free, and it–and its predecessor SUS–have been patching Microsoft assets since 2004.
Solving the Patch Problem on Linux Distributions
Linux distributions use different update utilities to deploy patches. YUM, Apt, and Zypper are examples of update utilities for Red Hat/CentOS, Ubuntu, and SLES respectively. Behind the scenes, these tools are very similar across different distributions. Some companies choose to send all of their servers over the WAN to update via primary patch repos; others download patches to a local repo server and patch locally.
Patching in Linux is typically much easier than Microsoft Windows, because Linux isn’t so reliant on reboots (with the exception of kernel updates).
In Comes AWS SMPM
Today, companies can deploy patch solutions directly from their AWS environment. The needed prerequisites entail the different Linux distributions supported, how to deploy the SSM agent (required for all patch-managed systems), and other useful setup information. AWS SMPM also provides a full-feature console and CLI to orchestrate patching.
AWS SMPM comes at no additional charge* on top of what you’re paying for your current EC2 on-demand or reserved instances. The service uses existing OS patch services, such as the wsusscn2.cab for Microsoft Windows or upstream repos in the updateinfo.xml for YUM style Linux distros. This means that update methods and logging for internal operating system patch installations are no different than using existing OS tools, such as Windows Update. This also means that AWS subscribes to OS vendor-provided repos for default patching baselines.
Where AWS SMPM Is a Good Fit
There are many use cases where using AWS SMPM is the right choice. The right decision revolves around how the servers are managed, if there is a large hybrid footprint, if there are heavy customizations of patch management, and whether the workloads they manage will be moving to more sophisticated frameworks (containers, serverless, etc). For companies that are extending their workloads to AWS or lifting and shifting their workloads to AWS, the AWS SMPM is useful. Let’s explore why.
“Amazon First” Users
For companies taking the approach of “Amazon First” for solutions before they buy/build their own, this tool is a natural choice for patching servers. It also comes at no additional charge* in AWS and for up to 1,000 other non-AWS VMs.
Same CLI/SDKs
AWS SMPM is built into the AWS CLI and AWS SDKs, so there is no need for additional tools to manage patching. This means that patching through scripts, via automation jobs, or in applications doesn’t require additional frameworks just to handle patching. It also means that iInfrastructure as Code such as AWS CloudFormation or HashiCorp Terraform can create all the required resources to patch an environment through code.
Scaling Resources Aren’t Utilized (or not the focus)
For companies using pre-canned and patched AMIs (gold images) with stateless configurations, managed patching is not important. Resources can be patched on a single instance and scaled up and down to replace outdated systems.
For companies managing long-living servers, patching is a necessity. Having instances tagged upon creation and joining patch groups is an easy way to bring them under patch management quickly and efficiently. For environments that are highly stateless but still have “one-offs” or “snowflake” servers that are long living, AWS SMPM is a good option to keep them patched without having to configure another solution to patch a handful of systems.
Customized Patching for Most Workloads
AWS SMPM supports patch groups, customizable maintenance windows, patch white/black listings, patch scanning, and patch deployments. In other words, it provides the functionality needed for most patching operations. It’s not sophisticated, but it’s straightforward and quick to start patching.
Single Pane of Glass
For companies that patch a Microsoft Windows/Linux mixed environment, they are either relying on multiple tools and methods to patch, or they are paying for a third-party application to bring that management under a single umbrella. Since the SSM agent can deploy patches to Windows and most major Linux distros, it provides that functionality. It can even help reduce management overhead (cost and tools) if moving to AWS or extending on-premise operations to a hybrid cloud.
Where AWS SMPM Falls Short
Despite all of its perks, there are areas where AWS SMPM is not ideal. Like any wrapped tools, there are limitations to its abilities, and some could be a deal-breaker for adoption.
Microsoft Windows Security/Critical Updates Only
This is a big deal. Although only critical/security updates for Microsoft are an absolute must, most companies install all available operating system patches. Some patches are for optimization, while many are bug fixes or feature updates. This means that all non-critical/security patches would either be deployed through an alternative update server, such as a WSUS or SCCM, or deployed through scripts or automation. No matter which way they’re deployed, this adds unneeded complexity for patch management.
As a side note, Linux can identify alternative repos, which allows it the flexibility to apply non-critical patches.
Doesn’t Scan and Remediate Non-Patch Vulnerabilities
Most organizations remediate vulnerabilities outside of patching. This could be in the form of CIS security benchmarks or as simple as disabling SSL ciphers from operating systems that provide poor security. This means that a company relying on AWS SMPM must use additional tools to augment their security threat awareness and remediation.
Large External Environments Could Be Costly
If the non-AWS environment (per account) exceeds the 1,000 hosts required to be a managed instance, then the company must opt into the advanced on-prem instances management. This means that each instance will cost $0.00695 per hour, per instance. It sounds like so little, but if the environment is 1,500 servers that are online all month, the cost would be (1,500 * $0.00695 * 30 * 24), or $7,506 per month.
Third-Party Patches
Companies of all sizes install third-party patches. Java, Flash Player, Apache Tomcat, and other applications release patches monthly or even more frequently. Some third-party patches are included in Linux or alternative repos, but Microsoft Windows requires SCCM or a third-party tool to install third-party patches. This means something other than AWS SMPM must be used to install non-OS patches. If an alternative tool is in place to install third-party patches, it may be best to deploy operating system patches with the same tool to prevent tool sprawl.
Auditing and Logging: Present, but Not Great
Like many AWS resources, AWS SMPM utilizes AWS CloudWatch for logging and AWS CloudTrail for AWS CLI tracking. By default, logging for all managed instances is pushed from the SSM agent and maintained in CloudWatch for 30 days. If logs are needed longer term, they can be shipped to AWS S3.
That being said, reviewing logs, finding trends, or auditing actions in logs becomes a heavy burden unless logs are shipped to another utility like Splunk or Elasticsearch (which come at a moderate to high cost).
Not Ideal for Security-Compliant Companies
For companies that undergo regulatory auditing such as HIPAA, SOC, ISO, PCI DSS, and others, you’ll require mature patching compliance and reporting. And companies that manage these environments may find some of the AWS SMPM limitations too restrictive.
SSM Agent: Another Agent to Manage
All AWS EC2 instances or on-premise servers/VMs require an SSM agent to be in the pool of AWS SMPM managed instances. The good thing is that all base AWS AMIs for Microsoft Windows since 2016 have the agent installed (which replaced the EC2Config service) as well as most Linux distros. All non-EC2 instances require the agent to be deployed. Even though agents are automatically updated when the Services Manager service is updated at the end of the day, it’s another agent to manage (and troubleshoot).
Summary
The AWS SMPM is an excellent tool in the AWS Systems Manager suite. It can provide patch management for your environment, but it still may not cover all of your needs. Setting up a full patch management tool is a large investment, so qualifying that AWS SMPM is the right fit for your company is critical. As a general rule, if one or more of the cons are a deal-breaker, another solution should be considered. However, it could just be your cloud-controlled patching solution!
