AWS SSM Patch ManagerでEC2のOSパッチを自動管理する設計|パッチベースライン・メンテナンスウィンドウ・コンプライアンス確認の実践

宮崎智広 この記事の監修:宮崎智広(Linux実務・教育歴20年以上・受講者3,100名超)
HOMELinux技術 リナックスマスター.JP(Linuxマスター.JP)AWS(Amazon Linux) > AWS SSM Patch ManagerでEC2のOSパッチを自動管理する設計|パッチベースライン・メンテナンスウィンドウ・コンプライアンス確認の実践
「AWSにEC2が増えるほど、OSパッチの適用状況の把握が追いつかない」「手動でSSH接続してyum updateを叩くのを、そろそろ卒業したい」という悩みは、インスタンス台数が増えてきた現場でよく聞きます。

AWS Systems Manager(SSM)の機能のひとつ、Patch Managerを使えば、パッチベースライン・メンテナンスウィンドウ・パッチグループの3要素を設計するだけで、複数EC2のOSパッチ適用を自動化できます。この記事では、Amazon Linux 2023環境を前提に、Patch Manager設計の全体像から実際のスキャン・適用・コンプライアンス確認まで、実践手順を解説します。

この記事のポイント

・Patch ManagerはSSM AgentとIAMロールがあれば追加インストール不要で動く
・パッチグループはEC2タグで環境(本番/検証)を分離する設計が基本
・メンテナンスウィンドウでスキャンとインストールを別タスクに分けると安全
・コンプライアンス確認でパッチ未適用インスタンスを一覧で把握できる


「このままじゃマズい」と感じていませんか?
参考書を開く気力もない、同年代に取り残される不安——
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

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で細かく指定可能
拒否リスト 設定不可 特定パッチを明示的に除外できる
向いている場面 開発・検証環境、すぐ始めたい場合 本番環境・コンプライアンス要件がある場合
Amazon Linux 2023の場合、デフォルトベースラインは 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へのタグ付けはCLIで一括設定できます。

# 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} } } ] }

Non-Compliantのインスタンスを特定するには 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 で確認し、停止していれば startenable で復旧する
エンドポイント未設定(プライベートサブネット):プライベートサブネットの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日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。

無料メルマガで学習を続ける

Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。

登録無料・いつでも解除できます

暗記不要・1時間後にはサーバーが動く

3,100名以上が実践した「型」を無料で公開中

プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。

姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら

Linux無料マニュアル(図解60P) 名前とメールで30秒登録
宮崎 智広

この記事を書いた人

宮崎 智広(みやざき ともひろ)

株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。

趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。