Patch Management

Patch management is a lifecycle, not simply the act of installing updates. Engineers inventory software, identify applicable fixes, assess urgency, test compatibility, deploy approved updates, and verify the resulting state. Security patches address known vulnerabilities, while other patches can resolve reliability defects. A practical policy defines remediation deadlines, maintenance schedules, approval rules, exception handling, and the evidence required to demonstrate completion.

In the cloud shared responsibility model, patching is a shared control applied to different layers, rather than a task that both parties perform on the same components. AWS patches the physical infrastructure and virtualization layers that it operates. For an Amazon EC2 instance, the customer is responsible for patching the guest operating system and customer-installed applications. With managed services, AWS operates and patches more of the stack, but customers still manage applicable maintenance settings, supported versions, and their own code and dependencies. Using a managed service does not eliminate every customer update obligation.

Start with an accurate inventory and ownership model. Classify workloads by operating system, environment, business criticality, exposure, and maintenance requirements. Prioritize vulnerabilities using exploitability, active exploitation, asset importance, and network reachability rather than severity scores alone. An internet-facing server with an actively exploited vulnerability may require an emergency rollout, while a lower-risk update can follow a normal testing cycle. Exceptions should have an owner, an expiration date, and compensating controls.

Automation translates policy into repeatable execution. For example, an operations team can use AWS Systems Manager Patch Manager to scan managed EC2 instances against patch baselines and install approved patches on a schedule. Baselines determine which updates are approved; they are not substitutes for application compatibility testing. Successful execution also depends on supported operating systems, healthy management agents, suitable permissions, and connectivity to management endpoints and package repositories. An unreachable or unmanaged instance must not be mistaken for a compliant instance.

Deploy updates progressively through development, staging, and production. Limit concurrency and stop or investigate when failures exceed defined thresholds. For a load-balanced application, drain and patch a subset of instances while preserving enough healthy capacity. Some updates require a reboot or service restart before the fix becomes effective, so a successful installation command alone does not prove remediation. Prepare backups or replacement capacity and a recovery plan; uninstalling a patch is not always supported or safe.

Immutable deployment is an alternative to modifying running servers. Build and test a patched machine image or container image, deploy replacement workloads, and retire the old versions. Updating an image does not patch instances or containers already running from it. Container users remain responsible for updating image contents and application dependencies, even when the provider manages the underlying compute hosts. Ensure scaling configurations reference the approved image so newly launched capacity does not reintroduce vulnerable software.

Continuous validation closes the loop. Patch compliance reports show whether resources satisfy an approval baseline, while vulnerability scanning identifies known weaknesses within its supported coverage. Amazon Inspector can identify vulnerabilities on supported workloads, but it does not install their patches. After remediation, repeat scans, confirm relevant restarts, run application health checks, and investigate remaining findings. A resource can satisfy its patch baseline yet still contain a vulnerability outside that baseline or scanning scope. Preserve deployment results, exceptions, and validation evidence to support audits and detect drift.