AWS Systems Manager(SSM)の機能のひとつ、Patch Managerを使えば、パッチベースライン・メンテナンスウィンドウ・パッチグループの3要素を設計するだけで、複数EC2のOSパッチ適用を自動化できます。この記事では、Amazon Linux 2023環境を前提に、Patch Manager設計の全体像から実際のスキャン・適用・コンプライアンス確認まで、実践手順を解説します。
この記事のポイント
・Patch ManagerはSSM AgentとIAMロールがあれば追加インストール不要で動く
・パッチグループはEC2タグで環境(本番/検証)を分離する設計が基本
・メンテナンスウィンドウでスキャンとインストールを別タスクに分けると安全
・コンプライアンス確認でパッチ未適用インスタンスを一覧で把握できる
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
AWS SSM Patch Managerとは何か(自動化の全体像)
Patch Managerは、Amazon EC2インスタンスへのOSパッチ適用を一元管理するためのAWS Systems Managerの機能です。個別インスタンスにSSHしてyum update を実行する手作業を、スケジュール実行と対象グループの管理で置き換えます。Patch Managerを構成する3つの要素を整理します。
・パッチベースライン:「どのパッチを適用するか」のルールセット。重要度・製品・パッチ分類で絞り込める
・パッチグループ:「どのEC2に適用するか」の分類。EC2タグ「Patch Group」の値で本番・検証を分ける
・メンテナンスウィンドウ:「いつ実行するか」のスケジュール管理。スキャンとインストールを別タスクで制御できる
この3要素を正しく設計することで、環境ごとに適切なパッチを、適切なタイミングで、適切な対象に自動適用できます。
Patch Managerを動かすための前提条件
Patch Managerはインスタンス内のSSM Agentを通じて動作します。Amazon Linux 2023では標準インストール済みのため、追加パッケージは不要です。ただし2点の確認が必要です。1. SSM Agentの稼働確認
EC2インスタンスでSSM Agentが動いているかを確認します。# Amazon Linux 2023 でSSM Agentの状態を確認 $ sudo systemctl status amazon-ssm-agent * amazon-ssm-agent.service - amazon-ssm-agent Loaded: loaded (/usr/lib/systemd/system/amazon-ssm-agent.service; enabled) Active: active (running) since Sat 2026-08-01 03:00:00 UTC; 30min ago Main PID: 1234 (amazon-ssm-agent)
Active: active (running) であれば正常です。停止している場合は以下で起動・自動起動設定を行います。$ sudo systemctl start amazon-ssm-agent $ sudo systemctl enable amazon-ssm-agent
2. IAMインスタンスプロファイルの設定
EC2インスタンスがSSM経由で操作されるには、IAMロールにAmazonSSMManagedInstanceCore ポリシーが必要です。EC2コンソールで当該インスタンスを選択し、「セキュリティ」→「IAMロール」からアタッチ済みポリシーを確認してください。ポリシーがなければ、IAMコンソールで新規ロールを作成し、EC2インスタンスプロファイルとして付与します。プロファイルを変更した後、SSM Agentの再起動は不要ですが、Systems Manager > フリートマネージャーにインスタンスが「マネージドインスタンス」として表示されるまで数分かかる場合があります。
プライベートサブネットに置いたEC2の場合は追加で3つのVPCエンドポイントが必要です。
・
com.amazonaws.<リージョン>.ssm・
com.amazonaws.<リージョン>.ssmmessages・
com.amazonaws.<リージョン>.ec2messagesパブリックサブネット+IGW構成であればエンドポイントは不要です。VPC設計とSSMの組み合わせについて体系的に学びたい方は、AWSマスターセミナー初級編でVPCのサブネット設計からEC2・IAMの基礎をハンズオンで習得できます。
パッチベースラインを設計する
パッチベースラインは「どのパッチを採用するか」を定義するルールセットです。AWSが提供するデフォルトベースラインをそのまま使う場合と、独自のカスタムベースラインを作成する場合があります。1. AWS提供のデフォルトベースラインとカスタムベースラインの違い
| 項目 | デフォルトベースライン | カスタムベースライン |
|---|---|---|
| 管理元 | AWSが定義・更新 | 自分で定義・更新 |
| 対象パッチ | Critical/High(自動承認7日後) | 重要度・製品・CVEで細かく指定可能 |
| 拒否リスト | 設定不可 | 特定パッチを明示的に除外できる |
| 向いている場面 | 開発・検証環境、すぐ始めたい場合 | 本番環境・コンプライアンス要件がある場合 |
AWS-AmazonLinux2023DefaultPatchBaseline です。本番環境でリリース直後のパッチ適用を避けたい場合(変更凍結期間の確保)は、カスタムベースラインを作成します。2. カスタムベースラインの作成(CLIでの手順)
Systems Manager > Patch Manager > パッチベースライン > ベースラインの作成からGUIでも設定できますが、CLI例を示します。# カスタムベースラインを作成(SecurityパッチのCritical/Highを14日後に自動承認) $ aws ssm create-patch-baseline \ --name "my-amzn2023-baseline" \ --operating-system "AMAZON_LINUX_2023" \ --approval-rules '{ "PatchRules": [ { "PatchFilterGroup": { "PatchFilters": [ {"Key": "SEVERITY", "Values": ["CRITICAL","HIGH"]}, {"Key": "CLASSIFICATION", "Values": ["Security"]} ] }, "ApproveAfterDays": 14, "EnableNonSecurity": false } ] }' \ --description "本番環境用 14日承認ベースライン" { "BaselineId": "pb-0a1b2c3d4e5f6789a" }
ApproveAfterDays: 14 はパッチがリリースされてから14日後に自動承認される設定です。リリース直後のパッチ適用を避けることでリグレッションリスクを下げられます。パッチグループを設計してEC2を環境別に分類する
パッチグループは、EC2インスタンスを「環境」や「役割」で分類してベースラインを使い分ける仕組みです。EC2に タグキー:Patch Group(固定)を付けるだけで設定できます。パッチグループ設計の例:
・Patch Group: production → カスタムベースライン(14日承認)を適用
・Patch Group: staging → AWSデフォルトベースライン(7日承認)を適用
・Patch Group: development → 即日承認のベースラインで最新パッチを積極適用
ベースラインとパッチグループの紐付けはCLIで行います。
# パッチグループをカスタムベースラインに紐付け $ aws ssm register-patch-baseline-for-patch-group \ --baseline-id "pb-0a1b2c3d4e5f6789a" \ --patch-group "production" { "BaselineId": "pb-0a1b2c3d4e5f6789a", "PatchGroup": "production" }
# EC2インスタンスにPatch Groupタグを付与 $ aws ec2 create-tags \ --resources i-0123456789abcdef0 \ --tags "Key=Patch Group,Value=production"
メンテナンスウィンドウを設計する
メンテナンスウィンドウは「いつ、どのタスクを実行するか」を管理するスケジューラです。スキャン(状況確認のみ)とインストール(実際に適用)を別ウィンドウで設計することで、本番への影響を最小化できます。1. スキャン専用ウィンドウの作成
# スキャン用メンテナンスウィンドウを作成(毎週水曜02:00 UTC) $ aws ssm create-maintenance-window \ --name "weekly-patch-scan" \ --schedule "cron(0 2 ? * WED *)" \ --schedule-timezone "Asia/Tokyo" \ --duration 2 \ --cutoff 1 \ --allow-unassociated-targets { "WindowId": "mw-0a1b2c3d4e5f0001" }
・--schedule:cron式でスケジュールを指定。
cron(0 2 ? * WED *) は毎週水曜UTC 2:00・--duration:ウィンドウの継続時間(時間単位)
・--cutoff:ウィンドウ終了N時間前で新規タスク開始を打ち切る設定
2. インストール用ウィンドウの作成
# インストール用メンテナンスウィンドウを作成(毎週土曜02:00 UTC・duration 4時間) $ aws ssm create-maintenance-window \ --name "weekly-patch-install" \ --schedule "cron(0 2 ? * SAT *)" \ --schedule-timezone "Asia/Tokyo" \ --duration 4 \ --cutoff 1 \ --allow-unassociated-targets { "WindowId": "mw-0a1b2c3d4e5f0002" }
3. ターゲット登録とタスク設定
作成したウィンドウに、対象インスタンス(パッチグループ)とタスク(AWS-RunPatchBaseline)を登録します。# ターゲットをパッチグループタグで登録 $ aws ssm register-target-with-maintenance-window \ --window-id "mw-0a1b2c3d4e5f0002" \ --resource-type "INSTANCE" \ --targets "Key=tag:Patch Group,Values=production" \ --name "production-instances" { "WindowTargetId": "wt-0a1b2c3d4e5f0003" } # タスクを登録(Installモード・必要な場合のみ再起動) $ aws ssm register-task-with-maintenance-window \ --window-id "mw-0a1b2c3d4e5f0002" \ --targets "Key=WindowTargetIds,Values=wt-0a1b2c3d4e5f0003" \ --task-arn "AWS-RunPatchBaseline" \ --task-type "RUN_COMMAND" \ --max-concurrency "1" \ --max-errors "1" \ --task-invocation-parameters '{ "RunCommand": { "Parameters": { "Operation": ["Install"], "RebootOption": ["RebootIfNeeded"] } } }'
Operation: Install の代わりに Scan を指定するとスキャンのみ実行します。RebootOption: RebootIfNeeded は、パッチ適用後に再起動が必要な場合のみ自動再起動を許可する設定です。本番環境では NoReboot を指定して再起動を別スケジュールで制御する設計もあります。コンプライアンス状況の確認と即時スキャン実行
1. コンプライアンスダッシュボードで確認
Systems Manager > Patch Manager > コンプライアンスレポートを開くと、各インスタンスのパッチ適用状況が一覧で確認できます。・Compliant:ベースライン上の必須パッチがすべて適用済み
・Non-Compliant:未適用のパッチが残っている
CLIでも確認できます。
# コンプライアンス状況の集計を取得 $ aws ssm list-compliance-summaries \ --filters "Key=ComplianceType,Values=Patch,Type=EQUAL" { "ComplianceSummaryItems": [ { "ComplianceType": "Patch", "CompliantSummary": { "CompliantCount": 8, "SeveritySummary": {"CriticalCount": 0, "HighCount": 0} }, "NonCompliantSummary": { "NonCompliantCount": 2, "SeveritySummary": {"CriticalCount": 1, "HighCount": 1} } } ] }
list-compliance-items を使います。# Non-Compliantなインスタンスとパッチ名を取得 $ aws ssm list-compliance-items \ --filters "Key=ComplianceType,Values=Patch,Type=EQUAL" \ "Key=Status,Values=NON_COMPLIANT,Type=EQUAL" \ --query 'ComplianceItems[*].{Instance:Id,Severity:Severity,Title:Title}'
2. メンテナンスウィンドウを待たずに即時スキャンを実行
Run Commandで即時スキャンができます。緊急CVEリリース後の現状確認に使います。# パッチグループ「production」の全インスタンスを即時スキャン $ aws ssm send-command \ --document-name "AWS-RunPatchBaseline" \ --targets "Key=tag:Patch Group,Values=production" \ --parameters '{"Operation": ["Scan"]}' \ --comment "緊急CVE確認スキャン" { "Command": { "CommandId": "a1b2c3d4-e5f6-7890-abcd-ef1234567890", "DocumentName": "AWS-RunPatchBaseline", "Status": "Pending" } } # スキャン結果を確認 $ aws ssm list-command-invocations \ --command-id "a1b2c3d4-e5f6-7890-abcd-ef1234567890" \ --details \ --query 'CommandInvocations[*].{Instance:InstanceId,Status:Status}'
トラブルシュート(よくあるエラーと対処)
1. フリートマネージャーにインスタンスが表示されない
Patch Managerを設定しても対象インスタンスがSystem Managerに表示されない場合の確認事項です。・IAMロール未付与:EC2インスタンスプロファイルに
AmazonSSMManagedInstanceCore がなければ表示されない。IAMコンソールでポリシーを確認・付与する・SSM Agentが停止中:
sudo systemctl status amazon-ssm-agent で確認し、停止していれば start と enable で復旧する・エンドポイント未設定(プライベートサブネット):プライベートサブネットのEC2はSSM用VPCエンドポイント(ssm / ssmmessages / ec2messages)が必要。パブリックサブネット+IGW構成ならエンドポイント不要
2. スキャン結果が「N/A」のまま更新されない
Run Commandでスキャンを実行した直後はコンプライアンスダッシュボードへの反映に数分かかります。5分経っても更新されない場合は、Run Commandの実行履歴でエラーメッセージを確認してください。# Run Commandの実行ログでエラーを確認 $ aws ssm get-command-invocation \ --command-id "a1b2c3d4-e5f6-7890-abcd-ef1234567890" \ --instance-id "i-0123456789abcdef0" \ --query '{Status:Status,Output:StandardOutputContent,Error:StandardErrorContent}'
3. パッチグループを設定してもデフォルトベースラインが使われる
EC2タグのキーがPatch Group でなければパッチグループとして認識されません。スペースを含む2語のタグキーです。PatchGroup(スペースなし)や patch-group(小文字・ハイフン)では機能しないため、タグキーを正確に確認してください。# EC2インスタンスのタグを確認(Patch Groupキーの存在チェック) $ aws ec2 describe-tags \ --filters "Name=resource-id,Values=i-0123456789abcdef0" \ --query 'Tags[?Key==`Patch Group`]' [ { "Key": "Patch Group", "ResourceId": "i-0123456789abcdef0", "ResourceType": "instance", "Value": "production" } ]
本記事のまとめ
| 設計要素 | 設定内容 | CLIコマンド |
|---|---|---|
| パッチベースライン | 重要度・承認日数を定義 | aws ssm create-patch-baseline |
| パッチグループ紐付け | ベースラインとグループを関連付け | aws ssm register-patch-baseline-for-patch-group |
| EC2タグ付与 | EC2に「Patch Group」タグで環境を分類 | aws ec2 create-tags |
| メンテナンスウィンドウ | スキャンとインストールを別スケジュール管理 | aws ssm create-maintenance-window |
| タスク登録 | AWS-RunPatchBaselineでScan/Installを実行 | aws ssm register-task-with-maintenance-window |
| コンプライアンス確認 | 適用済み/未適用インスタンスを一覧確認 | aws ssm list-compliance-summaries |
| 即時スキャン | ウィンドウを待たずに緊急スキャン実行 | aws ssm send-command |
OSパッチ自動化は、AWSインフラの「型」を知っていれば迷わない
SSM Patch Managerを正しく設計するには、VPC・サブネット・IAMロール・セキュリティグループといったAWSインフラの基本設計を理解していることが前提になります。断片的に覚えるより、現場で実際に使われる設計パターンを一度体系的に身につけることで、トラブルなく本番運用できるようになります。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル(図解60P)』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、AWSを含む現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら
- 前のページへ:AWS Elastic BeanstalkでLinuxアプリをデプロイする方法|環境設定とローリングデプロイ・マルチAZ・VPC統合の設計パターン入門
- この記事の属するカテゴリ:AWS(Amazon Linux)へ戻る

無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます