AWS Systems ManagerのSSM Association(State Managerの設定単位)を使えば、タグベースのターゲット絞り込みとRate Controlによる段階適用を組み合わせて、マルチAZ環境のパッチ適用を完全自動化できる。
この記事では、aws ssm associationの基本構造から、マルチAZ環境のパッチ自動化を実現する実践的な構成設計まで解説する。IAMロールの設定・Association作成コマンド・実行結果の確認方法を順を追って説明する。
この記事のポイント
・SSM Association = State ManagerによるDocumentの定期実行設定
・AWS-RunPatchBaselineでマルチAZパッチ適用を自動化できる
・Rate Controlで同時適用を25%に絞りローリング適用が可能
・PatchGroupタグで環境ごとにターゲットを柔軟に絞り込める
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
なぜ SSM Association でパッチ適用を自動化するのか
マルチAZ構成の本番環境でパッチ適用を手動で行おうとすると、次の課題に直面する。・AZをまたいで適用順序を管理しなければならない(AZ-aとAZ-cを同時に落とすと冗長性がゼロになる)
・EC2台数が増えるほど作業工数が線形に増え、メンテナンス窓が圧迫される
・適用結果の成功・失敗ログを手作業で収集する必要がある
SSM AssociationはAWS Systems Manager State Managerの設定単位だ。SSM Document(実行する操作の定義)をターゲットインスタンスに「紐付け」し、指定したcronスケジュールで繰り返し実行する仕組みである。さらにRate Controlを使えば「一度に全体の25%だけ適用し、エラーが1件出たら中止」という安全設計が実現できる。
このRate Controlこそ、マルチAZ環境のパッチ自動化でSSM Associationが重宝される最大の理由だ。AZ-a側の適用が完了してからAZ-c側に移るような段階的なローリング適用が、コードを書かずにパラメータだけで制御できる。
SSM Association の基本構成
1. Association を構成する5つの要素
Associationは以下の5つの要素で定義する。・Document:実行操作の定義(例:AWS-RunPatchBaseline)
・Targets:適用対象EC2(タグまたはインスタンスIDで指定)
・Schedule:実行頻度(cron式またはrate式)
・Parameters:Documentへの入力値(Operation=Installなど)
・Rate Control:同時適用の制限(MaxConcurrencyとMaxErrors)
2. SSM Agent と IAM ロールの前提条件
Associationを動かす前に、EC2側で2つの前提を満たす必要がある。前提1:SSM Agentが起動していること
Amazon Linux 2023 / Amazon Linux 2にはSSM Agentがプリインストールされている。起動状態を確認する。
# SSM Agent の起動確認 systemctl status amazon-ssm-agent # 出力例 * amazon-ssm-agent.service - amazon-ssm-agent Loaded: loaded (/etc/systemd/system/amazon-ssm-agent.service; enabled) Active: active (running) since Sun 2026-10-06 01:00:03 UTC; 1h 12min ago Main PID: 1234 (amazon-ssm-agen) Status: "Agent is running and ready to receive commands"
EC2にアタッチするIAMロールには最低限
AmazonSSMManagedInstanceCore ポリシーが必要だ。CLIで作成する場合は次のコマンドを使う。# IAMロールの作成(EC2用信頼ポリシー) aws iam create-role \ --role-name SSM-EC2-Role \ --assume-role-policy-document '{ "Version":"2012-10-17", "Statement":[{"Effect":"Allow","Principal":{"Service":"ec2.amazonaws.com"},"Action":"sts:AssumeRole"}] }' # AmazonSSMManagedInstanceCore ポリシーをアタッチ aws iam attach-role-policy \ --role-name SSM-EC2-Role \ --policy-arn arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore # インスタンスプロファイルを作成してロールを紐付け aws iam create-instance-profile --instance-profile-name SSM-EC2-Profile aws iam add-role-to-instance-profile \ --instance-profile-name SSM-EC2-Profile \ --role-name SSM-EC2-Role
マルチAZ環境へのパッチ適用を自動化する手順
1. EC2インスタンスにPatchGroupタグを付与する
Associationのターゲット指定にはPatchGroupタグを使うのが定番だ。AZ-aとAZ-cにまたがる全EC2に同じ値のタグを付けておき、Associationでそのタグを指定する。# AZ-a の EC2 に PatchGroup タグを付与 aws ec2 create-tags \ --resources i-0a1b2c3d4e5f67890 \ --tags Key=PatchGroup,Value=prod-linux # AZ-c の EC2 にも同じタグを付与 aws ec2 create-tags \ --resources i-0f9e8d7c6b5a43210 \ --tags Key=PatchGroup,Value=prod-linux
2. Association を作成する(aws ssm create-association)
Association作成の核となるコマンドはaws ssm create-association だ。ポイントはRate Controlの2つのパラメータ「--max-concurrency」と「--max-errors」だ。# Association の作成(毎週日曜 2:00 UTC に実行) aws ssm create-association \ --name "AWS-RunPatchBaseline" \ --association-name "weekly-patch-prod" \ --targets "Key=tag:PatchGroup,Values=prod-linux" \ --schedule-expression "cron(0 2 ? * SUN *)" \ --parameters "Operation=Install" \ --max-concurrency "25%" \ --max-errors "1" \ --output-location "S3Location={BucketName=my-ssm-logs,KeyPrefix=patch-logs/}" # 作成結果(AssociationId を控えておく) { "AssociationDescription": { "Name": "AWS-RunPatchBaseline", "AssociationName": "weekly-patch-prod", "AssociationId": "a1b2c3d4-1234-5678-abcd-ef0123456789", "AssociationVersion": "1", "Date": "2026-10-06T01:30:00+00:00", "Targets": [{"Key": "tag:PatchGroup", "Values": ["prod-linux"]}], "ScheduleExpression": "cron(0 2 ? * SUN *)", "MaxConcurrency": "25%", "MaxErrors": "1" } }
3. Rate Control の設定方針
Rate Controlの2パラメータの意味を整理しておく。・--max-concurrency:同時に処理するインスタンスの上限。「25%」なら全体の1/4ずつ順番に適用する。絶対数(例:「2」)でも指定できる
・--max-errors:失敗を許容するインスタンス数の上限。「1」なら1台でもエラーが出た時点で残りへの適用を中止する
マルチAZ構成でサービス継続を優先するなら、「25%」と「1」の組み合わせが現場での定番設定だ。8台構成なら2台ずつ適用するため、最低でもAZ-aかAZ-c側のいずれかは常時稼働している状態を維持できる。
4. 実行結果の確認
Associationが実行されると、その結果をaws ssm list-association-executions で確認できる。# 直近の実行履歴を確認 aws ssm list-association-executions \ --association-id "a1b2c3d4-1234-5678-abcd-ef0123456789" \ --max-results 5 # 出力例 { "AssociationExecutions": [ { "AssociationId": "a1b2c3d4-1234-5678-abcd-ef0123456789", "AssociationVersion": "1", "ExecutionId": "b2c3d4e5-2345-6789-bcde-f01234567890", "Status": "Success", "DetailedStatus": "Success", "CreatedTime": "2026-10-06T02:00:01+00:00", "LastExecutionDate": "2026-10-06T02:18:47+00:00", "ResourceCountByStatus": "{Success=8,Failed=0}" } ] } # インスタンス単位の詳細を確認 aws ssm list-association-execution-targets \ --association-id "a1b2c3d4-1234-5678-abcd-ef0123456789" \ --execution-id "b2c3d4e5-2345-6789-bcde-f01234567890"
応用設計:環境別パッチ適用のタグ設計
本番・ステージング・開発環境で適用タイミングを変えたい場合は、PatchGroupの値で環境を分離するのが実践的な設計だ。それぞれのAssociationで異なるScheduleを設定する。・PatchGroup=prod-linux:毎週日曜 2:00 UTC(本番。MaxConcurrency=25%、MaxErrors=1)
・PatchGroup=stg-linux:毎週土曜 2:00 UTC(ステージング。MaxConcurrency=50%、MaxErrors=2)
・PatchGroup=dev-linux:毎日 3:00 UTC(開発。MaxConcurrency=100%、MaxErrors=10)
この設計により、本番適用の前にステージングで動作確認できる「パッチ適用のカナリアフロー」が自動化される。新しいパッチで問題が起きても、本番に波及する前にステージングの失敗アラートで検知できる。
トラブルシュート:Association が動かない場合の確認手順
Associationを作成しても実行されない場合の主な原因と対処法をまとめる。# ターゲットインスタンスがSSMに登録されているか確認 aws ssm describe-instance-information \ --filters "Key=tag:PatchGroup,Values=prod-linux" # 出力例(InstanceIdが表示されれば登録済み) { "InstanceInformationList": [ { "InstanceId": "i-0a1b2c3d4e5f67890", "PingStatus": "Online", "LastPingDateTime": "2026-10-06T01:55:12+00:00", "AgentVersion": "3.2.2086.0", "IsLatestVersion": true, "PlatformType": "Linux", "PlatformName": "Amazon Linux", "PlatformVersion": "2023" } ] }
InstanceInformationList に表示されない場合は次の3点を確認する。・SSM Agentの起動確認:
systemctl status amazon-ssm-agent でActiveになっているか・IAMロールの確認:EC2にアタッチされたロールに
AmazonSSMManagedInstanceCore が付いているか。AWSコンソール → EC2 → インスタンス → IAMロールで確認する・VPCエンドポイントの確認:インターネット接続のないプライベートサブネットのEC2は
ssm・ec2messages・ssmmessages の3つのVPCエンドポイントが必要。プライベートサブネット設計を採用している場合は必ず追加する本記事のまとめ
aws ssm associationを使ったマルチAZ環境のパッチ自動化の要点を整理する。| 設定項目 | 推奨値・内容 |
|---|---|
| Document | AWS-RunPatchBaseline |
| ターゲット指定 | Key=tag:PatchGroup,Values=prod-linux |
| スケジュール | cron(0 2 ? * SUN *)(毎週日曜2時) |
| MaxConcurrency | 25%(全体の1/4ずつ順次適用) |
| MaxErrors | 1(1台失敗で残りを中止) |
| IAMロール | AmazonSSMManagedInstanceCoreをアタッチ |
| SSM Agent | Amazon Linux 2023・Linux 2はプリインストール済み |
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、
AWSのEC2セットアップからSSM運用の基礎まで体系的に学べる入門ガイドを無料で公開しています。
>> AWS(Amazon Linux)入門ガイドを見る
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ/30秒/解除は3秒 / 詳細はこちら
- 前のページへ:AWS SSM Port Forwarding をプライベートサブネット設計に組み込む方法|IAMポリシー構成
- この記事の属するカテゴリ:AWS(Amazon Linux)へ戻る

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