はじめに
こんにちは。hiranoです。
日々の運用の中でも「パッチ適用」って特に考えることも多くて、大変と感じることはないですか。
例えば、この更新は当てていいのか、このサーバ群は今月対象とするのか、いつ実行するのがベストなのか
等々、判断ポイントが多くて人によって基準がズレたり、対応の粒度が変わったり。
結果として、手順は残っていても“運用方針”がブレて、属人化してしまう印象があります。
そこで本記事では、AWS Systems Managerの Patch Manager を使って、パッチ適用を 「ポリシー管理」と「定期実行」 の形に落とし込み、運用を仕組み化するところまで実践してみたいと思います。
そもそもパッチとは
ここでいうパッチは、OSやミドルウェアに対する更新プログラムのことです。
脆弱性の修正、バグ修正、安定性向上などが目的で配布されます。一方で、当て方を誤るとアプリの互換性やサービス影響につながる可能性もあるため、「当てる/当てない」「いつ当てる」等、慎重な判断が必要です。
Patch Managerの位置付け
Patch Managerは、このパッチ適用における判断を「何を・どれに・いつ」という形で整理して、
ポリシーとして管理し、定期的に実行できるようにする仕組みです。
似た機能としてSSM Automationがあります。Automationは手順を自動で動かせますが、「どの更新を当てるか」「どういう周期で回すか」といったルール作成の難易度は高めです。
その点Patch Managerは、パッチ運用に必要な要素（ベースライン、対象切り分け、定期実行）が最初から揃っていて、運用方針のブレを抑えた形に落とし込みやすくなってます。
目次
本記事の流れ
今回はPatch Managerを使ってパッチ適用をポリシー管理＋定期実行で仕組み化する為に、
次の3点で運用として定義していきます。
・何を：どの種類のパッチを適用対象にするか（ポリシー）
・どれに：どのEC2に適用するか（タグで対象を切り分け）
・いつ：いつ実行するか（メンテナンスウィンドウで定期実行）
なお、実践の環境として、ターゲットEC2はPrivate Subnetに配置し、Systems Managerへの通信はVPCエンドポイント経由で行う構成とします。（SSMへの通信はインターネット不要で運用できます。一方で、パッチ適用に必要なS3やOSリポジトリへの到達性は別途考慮します。）
また、実践にあたり以下は事前に用意しています。
・VPC
・プライベートサブネット
- ターゲットEC2は本サブネットに配置
・パブリックサブネット
- NAT Gateway 配置用
・NAT Gateway
・ターゲット用のEC2(Amazon Linux 2023)×2
- いずれもSSM Agentが稼働、「AmazonSSMManagedInstanceCore」を許可したIAMロールを付与済み
・SSM通信用のVPCエンドポイント（ssm、ec2messages、ssmmessages）
・S3 Gateway Endpoint
- AWS-RunPatchBaseline(※後述します) が実行時に参照するペイロード（S3）へ到達できるようにするため
実践
1.パッチベースライン（ポリシー）の作成
まずは「何を」に関して、パッチベースラインに定義するため、方針を決めます。
今回は簡単に以下2点で設計することにします。
・セキュリティ関連は優先して当てたい
・バグ修正も取り込みたいが、即日は控える
それではパッチベースラインを作成していきます。
※コンソールには「パッチポリシー」という導線もありますが、本記事ではまず「何を当てるか」を明確にするため、
パッチベースライン（承認ルールみたいなもので、承認されて初めてメンテナンス日に適用されるイメージです）で進めます。
①AWS Systems Manager>パッチマネージャー>パッチベースライン>「パッチベースラインを作成する」を押下
②以下の設定値を入力
- パッチポリシー名：blog-amazonlinux-baseline（任意の名前で可）
- 対象OS：Amazon Linux
③承認ルールを設定
ルール①
- 分類：Security
- 自動承認の遅延：0日
ルール②
- 分類：Bugfix
- 自動承認の遅延：7日
④「パッチベースラインを作成」を押下
2.タグで適用対象（ターゲット）を管理
続いて、作成したベースラインに対して「どれに」当てるかをタグで機械的に決められる状態にしたいので、ターゲットとなるEC2に以下のタグを付与していきます。
・PatchGroup=AmazonLinux
今後は対象が増えても、サーバ追加時にタグを付けるだけで運用に乗るようします。
Patch Managerでは、このようにタグの値を使って「このインスタンス群にはこのベースライン」という形で紐づけができます。つまり、対象の追加/入れ替えは タグの付け替えだけで済むということです。
3.メンテナンスウィンドウでパッチ適用を定期運用に組み込む
実践1、実践2で決めた
・何を：パッチベースライン（Security即時、Bugfixは7日遅らせる）
・どれに：PatchGroup=AmazonLinux のEC2
に対して「いつ」を定義していきます。
今回は「毎週日曜 03:00〜05:00（JST）をパッチ枠とし、この時間内にスキャン＋インストールを実行する」としましょう。
まずはメンテナンスウィンドウを作成します。
①AWS Systems Manager>メンテナンスウィンドウ>「メンテナンスウィンドウの作成」を押下
②以下の設定値を入力し、作成を押下
名前：mw-amazonlinux-weekly（任意の名前で可）
スケジュール：
- Cron スケジュールビルダー：日単位 ごと日曜日の03:00
- 期間：2時間
- タスクの開始を停止する：1（4:00以降は新しいタスクを開始させないように という意味で1にします）
- タイムゾーン：Asia/Tokyo
続いて、ターゲットを登録します。
①作成したメンテナンスウィンドウ>アクション>「ターゲットの登録」を押下
②ターゲットの選択：インスタンスタグを指定
③以下を設定し、「Add」を押下
- タグキー：PatchGroup
- タグの値：AmazonLinux
④「Register target」を押下
正常に登録できると「ウィンドウのターゲットID」が発行されます。
次に、メンテナンスウィンドウ用の実行ロールを用意します。
タスクには SSMが実行に使うサービスロールが必要なためです。
EC2側ロール（AmazonSSMManagedInstanceCore）と、メンテナンスウィンドウ側ロールは別物になります。
①IAM>ロール>「ロールを作成」 を押下
②信頼されたエンティティタイプ：AWSのサービス を選択
③ユースケース：Systems Manager を選択し、「次へ」を押下
④許可ポリシー：AmazonSSMMaintenanceWindowRole を選択
⑤ロール名：ssm-mw-role-amazonlinux-weekly とし、「ロールを作成」を押下
ここまで作成できたら、いよいよ定期実行するタスクを登録します。
今回はメンテナンスウィンドウのタスクとしてスキャン用、インストール用を作成しますが、どちらもRun Commandの「AWS-RunPatchBaseline」を使います。
このドキュメントを使用すれば基本的なスキャン/インストールをそのまま実行することができます。
スキャンタスクの登録
①作成したメンテナンスウィンドウ>アクション>「Run Command タスクの登録」を押下
②名前：Scan
③タスクの優先度：1
④コマンドドキュメント：AWS-RunPatchBaseline を選択
⑤ターゲット：作成した「ウィンドウのターゲットID」を選択
⑥レート制御：
- 同時実行数：1ターゲット（安全運転、対象は2台だけなので十分）
- エラーのしきい値：0エラー（失敗が出たら停止）
⑦IAMサービスロール：作成したロール（ssm-mw-role-amazonlinux-weekly）を選択
⑧パラメータ：
- Operation：Scan
- RebootOption：デフォルト（スキャン時は再起動は発生しないため）
⑨「Run Command タスクの登録」を押下
インストールタスクの登録
①作成したメンテナンスウィンドウ>アクション>「Run Command タスクの登録」を押下
②名前：Install
③タスクの優先度：2 ※スキャンタスクの後に実行するため
④コマンドドキュメント：AWS-RunPatchBaseline を選択
⑤ターゲット：作成した「ウィンドウのターゲットID」を選択
⑥レート制御：
- 同時実行数：1ターゲット
- エラーのしきい値：0エラー
⑦IAMサービスロール：作成したロール（ssm-mw-role-amazonlinux-weekly）を選択
⑧パラメータ：
- Operation：Install
- RebootOption：RebootIfNeeded（メンテナンスウィンドウで再起動も終わらせる想定）
⑨「Run Command タスクの登録」を押下
4.実行結果の確認
タスクの登録が完了したら、正常にタスクが実行されるか確認しましょう。
メンテナンスウィンドウで指定した実行期間を過ぎた後に「履歴」タブを選択すると過去の実行内容が見れます。
※検証の為、実行時間を調節しています。
試しに「ウィンドウ実行ID」を一つ選択して「詳細の表示」を押下します。
実行されたタスクが確認できます。
個々のタスクの詳細を確認する際は「タスク呼び出し」から「詳細の表示」を押下します。
さらにインスタンスIDを押下すると、各ステップで出力されたログを確認できます。
「何のパッチが当たったのか確認したい」「タスクで失敗した理由を確認したい」といった時は、このログから参照できます。
※下図は失敗時のログ例
まとめ
本記事では、パッチ適用で判断がブレやすいポイントを「何を適用対象にするか」「どのサーバに適用するか」「いつ実行するか」に分けて整理し、それぞれをPatch Manager／SSMの設定として形にすることで、属人化しにくい定期運用の流れを作ってきました。ここまで読み進めていただいたことで、パッチ適用を“仕組み”として回していくイメージは掴めたのではないかと思います。
また、今回は「適用してよい更新の基準」を明確にしやすいパッチベースラインを中心に扱いましたが、対象や運用の枠組みまで含めてまとめて管理したい場合には「パッチポリシーを作成する」という選択肢も有効です。
さらに、実行についても「AWS-RunPatchBaseline」のようなRun Commandでシンプルに始められる一方で、パッチ前後に停止・切り離し・確認・ロールバックといった手順まで含めて統制したい等の場面では、Automationなどで手順全体を組み立てていく考え方が必要になります。
このように、Patch Managerは運用の成熟度に合わせて拡張していける余地があります。
ぜひ機能の理解を深めながら、自分たちの運用に合う形で活用してみてください。
