パッチポリシーとメンテナンスウィンドウでのパッチ適用の違いを知りたい
はじめに
こんにちは。コンサルティング部の津谷です。
今回はパッチ適用について記事を書きます。EC2等のサーバを運用する際に、カーネルのアップデートやパッケージのアップデートを定期的に行った経験はありますでしょうか。私も月1で1台ずつWindowsアップデートを手動実行した思い出があります。
AWSでは、System ManagerのPatch Managerという機能であらかじめパッチ適用の設定を組んでおくことができます。
具体的には、以下のような設定が可能です。
- 各OSに対してどういうパッチを当てるのか
- どの頻度でパッチを流すのか
- どのサーバをグループ化して指定するのか
そんな便利な機能ですが2022年12月にはPatch ManagerにはQuick Setupでのパッチポリシー適用が可能となり、従来メンテナンスウィンドウで行うちょっとだけ煩雑な作業（メンテナンスウィンドウ設定、タスク設定、パッチグループの作成、ターゲット指定など、タスクのIAM権限設定など）を簡略化してくれるようになりました。
下記のようにAWSもQuick Setupでのパッチポリシーを推奨しています。
その反面設定が簡略化したことから、細かい設定ができるという観点ではどうなのと疑問が浮かびました。
なので、メンテナンスウィンドウとパッチポリシーどっちを選定すればいいのか迷ったときのために機能比較を整理してみました。
パッチ適用前の準備
前提として、Patch Managerにはいくつか準備をしておく必要があります。
【OS内の準備】
- Pythonのバージョンを確認しましょう。
LinuxやmacOSはバージョン2.6~3.10が対応です。
AlmaLinux,Debian Server,Ubuntu ServerのOSはPython3(3.0~3.1)が対応です。 - SSMAgentのバージョンが2.0.834.0以降であることを確認しましょう。
【AWS側の準備】
-
パッチソースのリポジトリはS3上にあるので、S3への経路を確保しましょう。パブリックIPを持っている場合はインターネットへの経路（Internet Gateway）、持っていない場合はNAT Gateway→Internet Gatewayのインターネット経路を開けるか、S3用のVPCエンドポイントを作成しておいてプライベートアクセスできるようにしておきましょう。
-
IAMの権限はSSMにアクセスできるように設定しましょう。
インスタンスプロファイルに「AmazonSSMManagedInstanceCore」とかを付与しておきます。
（ログをCloudWatchlogsに出力する場合などは、追加で権限もつけるとよいです。）
機能の比較
| 比較項目 | パッチポリシー | メンテナンスウィンドウ |
|---|---|---|
| 適用できるインスタンス | OU配下（クロスアカウント）のインスタンスは全て適用可能、複数リージョン対応 | 同一アカウント、単一リージョンのインスタンスのみ |
| 設定難易度 | 易 | 難 |
| パッチベースライン | 対象インスタンスに1つのパッチルールしか適用不可 | 対象インスタンスに複数のパッチルールを適用可 |
| タスク実行順序の制御 | 不可 | 可 |
簡単に表にまとめてみました。それぞれ、比較してみようと思います。
-
適用できるインスタンス
パッチポリシーの良いところは同じOrganization内にいるマルチアカウント・マルチリージョンのEC2インスタンスを一括でパッチ適用できることです。メンテナンスウィンドウを利用する場合は同じアカウント・同じリージョン内にあるインスタンスしかターゲットとして認識されないので、メンテナンスウィンドウをアカウントごと、リージョンごとに作成する必要があります。Organizationで組織管理する場合や、複数リージョンにまたがってインスタンスを展開しているケースではパッチポリシーに軍配が上がりそうです。補足ですが、組織適用は組織の管理アカウントから設定する必要があります。 -
設定難易度
パッチポリシーの方が楽です。どういうパッチを適用するか（パッチベースラインの選択）、メンテナンスの実行スケジュール、パッチ適用するターゲットを1つのUIで設定できてしまいます。また、デプロイもQuick Setupが独自に作成するロールで実行することが可能です。既存のサービスロール（カスタム）を利用することも可能です。メンテナンスウィンドウの場合は、スケジュールを「メンテナンスウィンドウ」、どのパッチを当てるか・どのターゲットに当てるかを「タスク」でそれぞれ個別に定義する必要があります。タグでターゲットを指定する場合は、個別にあらかじめ検知するタグキーの組み合わせをインスタンスに付与する必要もあります。
個人的な体感としてパッチポリシーと比べて設定に時間がかかることは確かです。
【補足】
カスタムロールにQuickSetupがパッチ適用（RunCommandを実行する）する権限を付与してくれますが
Key: QSConfigId-quick-setup-configuration-id, Value: quick-setup-configuration-id
上記のタグをインスタンスに手動設定していないとエラーが起こります。というのも裏側ではQuickSetupの適用時にポリシーを作成するCloud Formationのスタックがid情報を取得しているからです。 設定をAWSがやっている分、裏側でどういう処理が行われているのか把握しておかないとエラーの原因調査が難しかったりもします。
-
パッチベースライン
パッチポリシーは、各OSごとにパッチを一括で適用できる反面、ポリシー1つにつき1つのパッチしか適用できません。複数のカスタムパッチを逐次的に当てる場合は不向きです。AWSが提供するデフォルトのパッチベースラインを当てるだけであったり、カスタムパッチベースラインを使っている場合も1実行で済むものは、パッチポリシーでよいかなと思いました。
メンテナンスウィンドウでは、複数のタスク（パッチベースラインの指定）を含めることができます。ターゲットも変えられますが、OS、システム、環境ごとに管理がしやすいようメンテナンスウィンドウはそれぞれ分けるのがよいかと思いました。 -
タスク実行順序の制御
パッチポリシーでもScanとInstallのスケジュールは自由に組むことができます。後から柔軟に変更することも可能です。メンテナンスのスケジュール設定という観点では、どちらを採用しても問題なさそうです。ただし、パッチポリシーの場合はOSごとに1つのパッチを一括適用するので複数のパッチを段階的に当てたいであるとか、優先度をつけて逐次的に処理を実行したいなどの場合は不向きです。ならば、パッチポリシーを複数作るというのも管理が煩雑です。
メンテナンスウィンドウであれば作成した複数タスクの実行順を「優先度」で柔軟に制御できます。番号が小さいほど、優先的にRunCommandが実行されます。
さいごに
どちらを使うかはユースケースに応じてという形になりますが、
マルチアカウント・マルチリージョンでデフォルトのパッチをとにかく一括適用という観点であるならば、Quick Setupでパッチポリシーの設定をした方が楽です。ただし、カスタムでパッチを組んで、段階的・逐次的に適用したい（タスク実行のスケジュールを柔軟にしたい）という場合はメンテナンスウィンドウで作りこんだ方がいいかなという所管でした。
皆さんもぜひ試してメリット・デメリット体感してみてください。
