AWSパッチマネージャーとCloudFormation＿前編

Posted at 2025-04-06

はじめに

前回はQuick Setupからパッチポリシーを作成して
Windows Serverにパッチ適用を行った

今回は、あえてパッチポリシーを使わずに
従来手法に則ってWindows Serverにパッチ適用を行う

なぜ従来手法にこだわるのか？

Quick Setup の開始方法によると、Quick Setupを使うためには
いくつかのロールを作成する必要があり
これらのロールが、まあまあ強力な権限を持っているため
ともすると組織のレギュレーションに合致しないことがあるため

平たく言うと、簡便な手法（パッチポリシーを使う方法）は所属組織が許さないので
手間はかかるが所属組織にとやかく言われない従来手法を試してみよう、というお話である

従来手法と新手法の違い

パッチポリシーとのその他の違いに書かれている通り

項目	従来手法	新手法
パッチグループ	必要／パッチグループに属するように複数のノードをタグ付けし、そのパッチグループに使用するパッチベースラインを指定できる。パッチグループがない場合、Patch Manager では、OS の種類に対する現在のデフォルトのパッチベースラインを使用してパッチが適用される。	不要／パッチポリシーに統合された
Configure patching	有り／パッチを適用するノード、パッチ適用スケジュール、およびパッチ適用オペレーションのデフォルトを指定	無し／パッチポリシーに統合された
コンプライアンス情報	無し	有り／パッチ適用ポリシーの設定に従ってマネージドノードのコンプライアンスをスキャンすると、コンプライアンスデータが利用可能

とりあえずCloudFormationに突っ込む

先人によるこちらのテンプレートをそのまま突っ込んでみたら、エラーなくリソースが生成された
Amazon Linux2向けで、TestPGというタグが付いているグループが対象とのこと

生成されたリソースを確認していく

AWS::SSM::PatchBaseline

ベースライン名、説明、オペレーティングシステムがテンプレート通りであることがわかる

Description: "AmazonLinux2PatchBaseline create by CloudFormation"
Name: AmazonLinux2PatchBaseline
OperatingSystem: AMAZON_LINUX_2

さらに詳細ページをみる
パッチグループが指定通りであることがわかる

  PatchGroups:
    - "TestPG"

また、PatchFilterGroupとしてSecurityグループとBugFixグループの２つがあることがわかる

    Properties:
      ApprovalRules:
        PatchRules:
          - ApproveAfterDays: 7
            PatchFilterGroup:
              PatchFilters:
                - Key: CLASSIFICATION
                  Values:
                    - Security
                - Key: SEVERITY
                  Values:
                    - Important
                    - Critical
          - ApproveAfterDays: 7
            PatchFilterGroup:
              PatchFilters:
                - Key: CLASSIFICATION
                  Values:
                    - Bugfix