【第9回】AWS Systems Manager攻略マニュアル「PatchManager基本編：概要、導入方法」

Ops Todayでは「面倒なAWSシステム運用を効率化しよう！」をテーマに、AWSリソースを含むシステムの運用をする際に便利なサービス「AWS Systems Manager」に関する記事を複数回にわたってご紹介しています。（記事一覧はこちら）

今回は、パッチ管理が行えるPatch Managerの概要や動作イメージ、実際の開始方法をご業界します。

パッチ管理って何をするの？

Patch Manager という名称から「パッチ管理」という言葉を連想できます。まさしく、パッチ管理を実現できるAWSのサービスが Patch Manager なのですが、パッチ管理とは何かという前提知識から、このサービスの解説を始めます。

パッチとパッチ管理

パッチとは、一般的に”ソフトウェアのリリース後に提供される小規模な修正プログラム”を指します。
その目的は、リリース済みソフトウェアのバグ修正や機能改善、あるいは脆弱性への対応です。

バグ修正を目的としたパッチであれば適用するのは１度で済みそうですが、機能改善や脆弱性の対応となると適応作業は定期的に何度も必要となるでしょう。
特に、セキュリティ攻撃は常日頃新たな手口で行われ、プログラム側は新たな脆弱性を突かれる度に対策を求められます（パッチ適用が必要となります）。

それでは、新たなパッチがリリースされる度に即適用すればいいのかというと、そう単純な話ではありません。

パッチ適用はソフトウェアのプログラムを部分的に更新することになるため、適用の前後でそのソフトウェア自体の動作は当然のこと、連携して動く他のハードウェア（ファームウェア）、ソフトウェアの動作に影響を与える可能性があります。
また、適用するサーバーのスペックや環境仕様によって適用する手順や条件、リスクなども異なる場合があります。

そのため、新たなパッチが出るたびにどんどん適用することにはリスクが有り、適用前後の影響を検証したり、システム単位、サーバー単位で適用の実施有無や適用タイミングを検討することになるので、パッチ適用の状況はあらゆる単位でバラバラになりがちです。

この結果、どのソフトウェアの、どのバージョンのパッチを、どの環境あるいはサーバーに適用したか、あるいは適用していないかといった情報を細かく管理する必要性が生じます。
これが「パッチ管理」です。

パッチ管理の課題

パッチ管理に求められることをもう少し詳しく見てみます。
適用するパッチには、適用にあたって遵守すべき環境要件や前提条件、注意事項があります。
そのため、適用対象となるサーバでは、次の要素を考慮する必要があります。

OSの種類やバージョン
インストールされているソフトウェア
セキュリティ要件
ネットワーク要件（インターネットに接続されていないなどの制限が無いか）
適用可能なタイミング（メンテナンス可能日時）

これらの要件と照らし合わせることで、適用の可否や適用方法などを判断することができるので、管理対象となるシステムおよびサーバについて、これらの情報を日頃から整理しておくことが大事です。

また、パッチ管理では、パッチ適用に関する運用記録を残し、随時更新することも重要です。
例えば、日頃の運用でパッチに関する次のような情報を整理しておく必要があります。

適用したパッチの種類（どのソフトウェアのパッチか）、バージョン
適用済みパッチの適用実施日時
今後適用が必要なパッチの存在および重要度、緊急度
管理対象のパッチに関するステータス情報（仕様調査中、動作検証中など）

常にこれらの情報を更新しておくことで、適用漏れの防止や適用後の問題発覚後の対応に関する判断、今後適用が必要なパッチに関する判断を助けるデータとして活かすことが可能です。
ただ、このようなパッチ管理運用をするとなると、適用調査、適用作業実施、適用データ管理などとタスクは多岐にわたる上、１つ１つのタスクで見ても負担は小さくありません。
パッチ管理の担当者には、パッチ適用に関する高いスキルや見識が求められ、日々の運用も大変です。

Patch Managerは何ができる？

Systems ManagerのPatch Manager機能は、マネージドノードへのパッチ適用プロセスを自動化する機能です。
例えば、次のような作業を自動化できます。

適用すべきパッチがないか定期的にスキャン
適用対象パッチのインストール
適用すべきパッチの選別

また、これらスキャンの結果やインストールの状況を確認できるダッシュボード機能が用意されており、クロスアカウント、クロスリージョンでパッチのコンプライアンス状況を集約して可視化できます。

Patch Managerの動作イメージ

それでは、Patch Managerはパッチ管理に関して何を行い、どのように動作するのでしょうか。
ここでは、Patch Managerの動作を図解します。そのあとPatch Managerの前提条件も紹介するので、先に解説する動作イメージと関連付けて各条件の必要性を理解していただければ幸いです。

下に示す図は、Patch Managerの動作イメージです。

パッチに関連する処理は、SSMドキュメント（”Documents”の名称で図示）に定義されています。
そして、SSMドキュメントを Systems Manager のRun Command機能より実行することで、パッチ関連の処理が行われます。

その際、中心的な処理であるパッチのスキャンやインストールは、マネージドノードのOS機能を利用して行われ、適用するパッチはパッチソースリポジトリへアクセスして入手します。

これらの処理は、Patch Managerのオンデマンド実行機能を利用して簡単に即時実行（※）できますし、Maintenance WindowやState Managerと連携して定期的にスケジューリング実行させることも可能です。（※即時実行の場合も、裏でState Managerとの関連付けが行われます。）

また、Patch Managerのパッチベースラインを予め設定しておくことで、どのパッチを適用するかフィルタリングして自動選別させることが可能です。

マネージドノードが複数ある場合、どのノードにどのパッチベースラインを適用するかは、パッチグループまたはパッチポリシーという機能で設定します。

パッチに関する処理の実行結果は、Systems ManagerのInventoryやComplianceに記録され、それぞれのコンソールから確認できます。また、Patch Managerのダッシュボードで運用状況を確認することもでき、こちらの方がより分かり易いのでお勧めです。

Patch Manager利用の前提条件

Patch Managerを利用するにあたり、次の前提条件をクリアする必要があります。

管理対象はマネージドノードにしておくこと
Pythonがインストールされていること　※マネージドノードがLinux、MacOSの場合
パッチソースリポジトリへネットワーク的に疎通可能なこと
Systems Managerが用意する特定のS3バケットへアクセス可能なこと
Patch ManagerでサポートしているOSバージョンであること

管理対象はマネージドノードにしておくこと

マネージドノードにする方法は、こちらの別記事をご参照ください。また、SSM Agentのバージョンは、2.0.834.0 以降からサポートされていますが、常に最新のバージョンに更新することを推奨します。

Pythonがインストールされていること

Linux、MacOSのマネージドノードには、Python 2.6～3.10 をインストールする必要があります。また、以下のOSを利用する場合は、Python 3 (3.0～3.10) が必要です。

AlmaLinux
Debian Server
Raspberry Pi OS
Ubuntu Server

PythonはSSMドキュメントを実行する過程で、Systems ManagerのS3バケットよりダウンロードされるモジュールの実行に必要となります。ちなみに、WindowsノードではPowerShellを利用します。

パッチソースリポジトリへネットワーク的に疎通可能なこと

パッチソースリポジトリとは、Patch Managerで適用するパッチが保存される場所です。インターネットに接続されているノードの場合、OSが更新プログラムを入手する際はパッチソースリポジトリにアクセスすることでパッチを入手しています。

Windows：Windows UpdateカタログやWSUS（Windows Server Update Service）
Linux：YumやDnfといったOS設定で指定しているリモートリポジトリ

マネージドノードがインターネットに直接接続していない環境で、VPC エンドポイントでAmazon VPC を使用している場合は、マネージドノードがパッチソースリポジトリに確実にアクセスできるようにしておく必要があります。

Systems Managerが用意する特定のS3バケットへアクセス可能なこと

Patch Managerを含むSystems Managerのあらゆる機能に関する処理過程で、SSM Agent は多数のAmazon S3バケットにアクセスし、バケット内にあるSSMドキュメントを実行します。したがって、使用するSSMドキュメントに応じて、適切なS3バケットへのアクセスを可能な状態にしておく必要があります。

次の表は、使用するSSMドキュメントと、それに応じてアクセスを許可すべきS3バケットARNをまとめたものです。

使用するSSMドキュメント	アクセスを許可すべきS3 バケット ARN
パッチベースラインスナップショットに関する SSMドキュメント・AWS-RunPatchBaseline ・AWS-RunPatchBaselineAssociation ・AWS-RunPatchBaselineWithHooks ・AWS-ApplyPatchBaseline	arn:aws:s3:::patch-baseline-snapshot-region/* または arn:aws:s3:::patch-baseline-snapshot-region–unique-suffix/*
パッチ適用オペレーションに関する SSMドキュメント・AWS-RunPatchBaseline ・AWS-RunPatchBaselineAssociation ・AWS-RunPatchBaselineWithHooks ・AWS-InstanceRebootWithHooks ・AWS-PatchAsgInstance ・AWS-PatchInstanceWithRollback	arn:aws:s3:::aws-patch-manager-region–unique-suffix/*

Patch ManagerでサポートしているOSバージョンであること

たとえSystems Manager の他の機能でサポートされているOSバージョンであっても、必ずしもPatch Manager でもサポートされているわけではありません。Patch Managerでは、次のOSおよびバージョンをサポートしています。（2025年1月現在）

Windows

Windows Server 2008-2025（R2バージョンを含む）
※2008については、バージョン2.3.1644.0以降のSSM Agentのみサポート

Linux

AlmaLinux 8.x, 9.x
Amazon Linux 2012.03～2018.03
Amazon Linux 2（バージョン2.0 以降のすべてのバージョン）
Amazon Linux 2022
Amazon Linux 2023
Red Hat Enterprise Linux (RHEL) 6.5～8.x、9.x
CentOS 6.5～7.9、8.x
CentOS Stream 8、9
Debian Server 8.x、9.x、10.x、11.x、および 12.x
Oracle Linux 7.5～8.x、9.x
Raspberry Pi OS (旧称: Raspbian) 9 (Stretch)
Rocky Linux 8.x、9.x
SUSE Linux Enterprise Server (SLES) 12.0 および 12.x 以降のバージョン、15.x
Ubuntu Server 14.04 LTS、16.04 LTS、18.04 LTS、20.04 LTS、20.10 STR、22.04 LTS、23.04、23.10、24.04、および 24.10

Mac OS

11.3.1、11.4～11.7 (Big Sur)
12.0～12.6 (Monterey)
13.0～13.5 (Ventura)
14.x (Sonoma)

※Patch Manager では、macOS のOSアップデートやアップグレードをサポートしていません（Apple に組み込まれている OS アップグレードメカニズムの使用を推奨）。

Patch Managerを始めてみよう

Patch Managerを実際に始めてみましょう。AWSマネジメントコンソールから、クリック操作で簡単に開始することができます。初めてPatch Managerにアクセスすると、次の画面が表示されます。画面右上にある「パッチポリシーを作成」をクリックしましょう。

「パッチポリシーを作成」画面が表示されます（Systems ManagerのQuick Setup機能からもPatch Managerを開始することができますが、その場合も以下画面にたどり着きます）。

パッチポリシーとは、パッチを適用する際の基本方針を定義するPatch Managerの機能で、マルチアカウント、クロスリージョンで一元的に管理対象を制御できるのが特徴です。
※パッチポリシーは、一部のリージョンでサポートされておらず、大阪リージョンはサポートしていません（2025年1月時点）。

パッチポリシーの設定項目について、主要なものを解説していきます。

スキャンとインストール

パッチの「スキャン」のみ行うか、スキャンに加えてインストールまで行うかを設定する項目です。
スキャン処理では、マネージドノードのインストール済みパッチとパッチベースラインで承認しているパッチリストを比較し、承認済みに関わらずノードにインストールされていないパッチをレポートします。

また、ここでスキャンのスケジューリングをデフォルトから変更することも可能です。
デフォルト値は毎日午前１時にスキャンを実行しますが、「日単位」を選ぶことで毎日の実行時刻を変更でき、CRONを利用して週ごと、曜日ごとなど、より複雑なスケジューリングも可能です。

パッチベースライン

適用するパッチをフィルタリングするルールを定めた「パッチベースライン」を、パッチポリシーに紐付ける設定です。

Patch Manager導入時は推奨設定を選択することになりますが、独自のパッチベースラインを作成した後は、カスタムパッチベースラインとしてパッチポリシーと紐づけることが可能です。

ログストレージにパッチ適用

パッチ適用処理のログをS3バケットに保存することができます。
ダッシュボード等で確認できるものより遡ってログを確認したい場合、S3バケットに出力するようにしておけば確認することができます。

ターゲットノード

Patch Managerの管理下におくターゲットノードの指定方法を設定する項目です。

デフォルトはアカウントに属するすべてのマネージドノードにパッチポリシーを適用しますが、タグやリソースグループ、あるいは手動でターゲットとなるマネージドノードを指定させることもできます。

レートの制御

スケジューリングによる定期実行の際、このパッチポリシーを実行するノードの同時実行数やエラーを許容する数を指定できます。

パッチのダウンロードやインストールには多くのハードウェアリソースやネットワークパフォーマンスを必要とし、時間も必要とします。台数が多い環境で同時実行を100%許可すると、その間システム全体が長時間正常に利用できない状態になる個とも考えられ、適切なチューニングが必要です。

また、多くのリソースを必要とすることによるオーバーワークが原因でパッチ関連の処理はエラーになる可能性があります。ある程度エラーを許容することで、処理をスムーズに進めることが可能です。この「エラーのしきい値」に設定したノードの割合に収まる範囲であれば、パッチポリシーをエラー状態にせずに処理を進めることが可能です。

すべての項目を設定し、画面最下部にある「作成」をクリックするとパッチポリシーの作成処理が開始します。作成処理の実行直後、次のポップアップが表示されますが、「確認」をクリックして問題ありません。