How can I verify my EC2 instances are patched in AWS?

By Kevin Cox, AWS SAA, CCSK
Lead Consultant, Impact Makers

The typical process of patching on-premise systems

Most IT environments have a requirement to keep systems up to date on vendor patches. Typically, in on-premise environments there are dedicated systems that scan and update patching targets. The patching targets in this case are the operating systems of servers or virtual machines, including Windows servers and many variants of Linux. Examples of this kind of software include Microsoft Windows Server Update Services, Red Hat Satellite, IBM BigFix, or Ivanti. This blog specifically references operating system patching.

Patches are usually pushed to systems on a schedule that is controlled by IT or an operations team. Often, the patch management product provides a central dashboard that shows patch versions on all clients/targets. There are many products in the marketplace that provide enterprise-scale patching and reporting. Additionally, many basic products are offered by operating system vendors that deliver elemental patching capability without additional cost. A typical IT environment often has compliance, governance, reporting, and audit requirements that mandate regular patching. It is also a best practice to keep all technology up to date to decrease the risk footprint of IT systems.

Screenshot from Windows Server Update Services

The cloud challenge with patching

IT organizations are commonly required to patch all operating systems in a cloud environment and have the ability to provide real-time reporting on the patch version of targets. A common situation faced by an IT organization is to patch all resources in a cloud environment and produce documentation of successful patching. The need for patching by the customer usually applies to Infrastructure-as-a-Service (IaaS) cloud computing service models. In AWS, IaaS includes services like EC2. A user of AWS EC2 is responsible for the related software that is installed on the EC2 virtual machine. Cloud service providers usually retain responsibility for patching in Platform-as-a-Service (PaaS) and  Software-as-a-Service (SaaS) cloud computing service models.

Before we go further into explaining patching in the cloud, let’s cover the different cloud computing service models. Customer responsibilities are different across the SaaS, PaaS, or IaaS cloud computing service models. In the following graphic, the responsibilities are identified by the cloud computing service model.

• The on-premise model is where the customer has complete responsibility. The customer manages the entire environment. Any decisions, configuration, and usage are entirely owned by the customer.
• The IaaS (Infrastructure-as-a-Service) cloud computing model is the closest in alignment to on-premise environments. The customer can usually extend an on-premise process or software with the least challenge in this model. However, there is no visibility into the core network, storage, physical servers, or virtualization hypervisor, or virtual machine monitor. This visibility into the network, storage, physical systems, and virtual hypervisor is owned by the cloud service provider. Patching is the responsibility of the customer for the areas including operating systems and above. In AWS, the customer responsibility for patching starts at the EC2 virtual machines. Customers do not patch the layers like XEN hypervisor, EFS storage, or ELB.
• The PaaS (Platform-as-a-Service) cloud computing model shifts more responsibility to the cloud service provider and less flexibility for the customer. The customer does not have visibility into much of the environment. Items like servers, networking, databases, and other infrastructure are not visible to the customer. Patching is not typically performed by the customer.
• The SaaS (Software-as-a-Service) cloud computing model is almost entirely the responsibility of the cloud service provider. The customer does not have visibility into much of the environment. Patching is almost never performed by the customer in SaaS.

Automation opportunities for managing patching in the cloud

The extension of patching capabilities is a complex task when an organization is beginning to move applications and workloads into the cloud; yet is still required to meet compliance requirements regarding patching.

It is not uncommon to have patch management systems with automation capabilities in on-premises data centers. All decisions, configuration, and patch deployments are the responsibility of internal IT or operations groups. The same patch management system and its requisite processes are easily extensible to IaaS cloud services. The IaaS cloud computing model most closely resembles on-premise environments—particularly when the data center in question is using hypervisors like VMware, Hyper-V, KVM, XenCenter, or other related products. A caveat to extending an on-premise patch management system is the potential cost increase incurred by additional inbound/outbound data transfer costs charged by major cloud platform providers. Additional costs can be incurred, as many patch management systems may charge a fee per agent/target, which means there can be costs for each EC2 instance that is connected to the on-premise system. It is important to consider the broader implications of extending existing patching operations.

An excellent choice is available for the customer in AWS. AWS offers an alternative to “lifting and shifting” an existing patch management system and its processes. AWS native tools, such as Systems Manager, include a fully capable Patch Manager. We want to be clear that AWS Systems Manager has many capabilities in addition to patch management.

“AWS Systems Manager Patch Manager automates the process of patching managed instances with security-related updates. For Linux-based instances, you can also install patches for non-security updates. You can patch fleets of Amazon EC2 instances or your on-premises servers and virtual machines (VMs) by operating system type. This includes supported versions of Windows Server, Ubuntu Server, Red Hat Enterprise Linux (RHEL), SUSE Linux Enterprise Server (SLES), CentOS, Amazon Linux, and Amazon Linux 2. You can scan instances to see only a report of missing patches, or you can scan and automatically install all missing patches.”

The AWS Systems Manager Patch Manager provides patching capabilities for common operating systems, dashboard and reporting functions, and allows for the scheduling of patch cycles. This tool can be much lower in cost than extending an on-premise patching tool into the cloud. There is also an option to extend AWS Systems Manager Patch Manager to an on-premise environment—in addition to the other capabilities that are offered by the AWS Systems Manager cloud service.

The Impact Makers Solution

Impact Makers is an AWS Consulting Partner. We leverage comprehensive and mature practices to enable customers to see all facets of their AWS ecosystem. Every project has unique elements that must be incorporated into a comprehensive strategy in addition to identification and execution of technical work. As Advanced AWS consulting partners, we recognize the impact of patch management on the future of your cloud journey and we will help you optimize your present and future usage of cloud. Our comprehensive framework includes the AWS Well Architected Framework and industry best practices in addition to elements like compliance , asset and metadata management, business strategy alignment, service portfolio management, support model definition, service design and deploy, and much more. We work with our customers to deliver and enable strategic business advantage with cloud services.

To learn more, contact us.