AWS Systems Manager本番運用Vol1｜SSM運用ツール群実装

1. AWS Systems Manager 全体像と本記事の射程

1-1. 本記事のゴール

AWS Systems Manager（SSM）は EC2 インスタンス・オンプレミスサーバー・他クラウド VM を「マネージドノード」として統一的に管理する AWS の統合運用サービスです。単一のコントロールプレーンから、シークレット管理・踏み台レスアクセス・パッチ適用・運用手順の自動化・構成可視化を実現します。

SSM が登場する以前、AWS 上のサーバー運用は多くの課題を抱えていました。踏み台サーバーの管理・SSH キーの配布と失効・パッチ適用の手動スケジューリング・シークレットのハードコーディング・運用手順の属人化 ——— これらは規模が拡大するほど管理コストが指数的に増大します。SSM はこれらを「エージェント＋ IAM 認証＋ AWS マネージドコントロールプレーン」の組み合わせで解決します。

特に、EC2 インスタンスは IAM ロールさえ付与すれば SSM Agent が自動認証され、一切の追加インフラ（踏み台 / VPN / SSH キー配布基盤）なしに全機能を利用できる点が最大の強みです。オンプレ・他クラウドもハイブリッドアクティベーション経由で同一コントロールプレーンに収容でき、クラウドとオンプレを横断した統合運用基盤を構築できます。

本記事を読み終えたとき、読者は次の成果物を手にできます。

• SSM の 10 機能群の全体マップと「設定管理 / アクセス / パッチ / 自動化 / 可視化」の役割分担
• EC2・オンプレ混在環境でのマネージドノード登録手順（SSM Agent / IAM / ハイブリッドアクティベーション / VPC エンドポイント）と公式裏付き精度の罠の回避策
• Parameter Store の Standard/Advanced tier 選択・SecureString/KMS 設計・アプリ・IaC からの参照パターン
• Session Manager による踏み台レス接続・セッションログ記録・ポートフォワーディングの実装
• Patch Manager + Maintenance Windows を使ったパッチベースライン設計とリング展開の本番運用パターン
• Automation Runbook による運用手順のコード化・承認ゲート・レート制御
• Fleet Manager / Inventory / State Manager / Compliance / OpsCenter による運用可視化レイヤーの構築

1-2. 読者像

本記事の想定読者は、EC2 とオンプレミス（または他クラウド）が混在する本番環境を運用する SRE・インフラ運用者 です。具体的には以下のような課題を持つ方を対象にしています。

• 踏み台サーバーの管理コストを削減し、SSH キー紛失や鍵漏洩リスクを排除したい
• Parameter Store と Secrets Manager の使い分けに迷い、シークレット管理が属人化している
• OS パッチ適用が手動運用のまま残っており、コンプライアンス要件への対応が後手になっている
• 運用手順が Wiki に文書化されているだけで、障害時に自動実行する仕組みがない
• EC2・オンプレ混在の全マネージドノードを一画面で把握できていない

AWS 認定試験レベルの基礎知識（IAM・VPC・EC2 の概念）を前提とし、本番環境で SSM を設計・実装できる水準を目標にします。

本記事では AWS CLI・マネジメントコンソール・CloudFormation / Terraform の操作に慣れていることを想定します。各機能の「なぜこの設計にするか」という判断基準と、現場で遭遇しやすい精度の罠（よく出回る誤情報）の回避策に重点を置いています。SAA / SOA / SAP レベルの試験対策としても活用できますが、主眼は本番環境での実装です。

1-3. SSMを構成する機能群の地図

SSM は 10 以上の機能から構成される統合サービスです。本記事では「設定管理 / アクセス / パッチ / 自動化 / 可視化」の 5 カテゴリで整理します。

本記事（Vol1）では上記 10 機能すべてを扱います。Vol2 以降では Change Manager・Change Calendar・Application Manager・大規模マルチアカウント運用を取り上げます。

なお、Run Command（マネージドノードへの任意シェルコマンド実行）は SSM の中核機能の一つですが、Automation / State Manager / Patch Manager の内部実行エンジンとして使われるケースが多く、本記事では各機能の説明の中で自然に言及します。Run Command 単体の詳細な活用方法は本シリーズの応用編で取り上げます。

5 カテゴリの考え方

5 つのカテゴリは「何を管理するか」ではなく「どのフェーズで使うか」で整理しています。

• 設定管理（Parameter Store / State Manager）：デプロイ前の構成値・シークレットの安全な配布と、稼働後の構成ドリフト防止
• アクセス（Session Manager）：踏み台ゼロで、かつ監査ログ付きのシェルアクセスとポート中継
• パッチ（Patch Manager / Maintenance Windows）：OS パッチのスキャン・承認・スケジュール適用と、コンプライアンス記録
• 自動化（Automation / OpsCenter）：Runbook によるプロセスのコード化・承認ゲート・イベント駆動修復
• 可視化（Fleet Manager / Inventory / Compliance）：全マネージドノードの現在状態・構成メタデータ・コンプライアンス状況の一元把握

本番運用では「現状把握（可視化）→ 是正（自動化）→ 維持（パッチ・設定管理）」のサイクルを SSM 内で完結させることが目標です。

1-4. 本記事の差別化と前提知識

既存の AWS 関連記事では、SSM はマルチアカウントガバナンス（AWS Config / Trusted Advisor / Health の文脈）の構成要素の一つとして、またはインシデント対応 Runbook の実装例として断片的に登場します。本シリーズは SSM 運用ツール群そのものを主役 に据えた専用 deep-dive です。

具体的な棲み分けは以下の通りです。

前提知識

本記事を最大限活用するため、以下の AWS 基礎知識を前提とします。

• IAM：ロール・インスタンスプロファイル・マネージドポリシーの概念
• VPC：サブネット・セキュリティグループ・VPC エンドポイントの概念
• EC2：AMI・インスタンスの起動・SSH 接続の基礎

KMS や CloudWatch Logs の基礎知識があると §3（SecureString）・§4（セッションログ）の理解が深まりますが、必須ではありません。各箇所で必要な概念を補足します。

本記事で扱わないこと

本記事はスコープを明確化するため、以下は意図的に対象外としています。

• Systems Manager Incident Manager（別サービス。OpsCenter との連携は §7-5 で言及のみ）
• Change Manager / Change Calendar（リリース管理フロー。Vol2 以降で扱う予定）
• Application Manager（アプリケーション単位の運用統合。Vol2 以降）
• Distributor（ソフトウェアパッケージ配布。State Manager と組み合わせて使うが、本記事では State Manager の設定継続適用に絞る）
• Systems Manager のマルチアカウント / Organizations 連携（別途マルチアカウントガバナンス記事参照）

これらを除外することで、本番環境で最初に必要な 10 機能の本質的な設計判断に集中できます。

マルチアカウントガバナンス全体設計（Organizations・SCP・Config・Health）

それでは §2 で、SSM の全機能を使うための前提環境（マネージドノード登録）を整えます。

2. 前提：SSM Agent・IAM・ハイブリッドアクティベーション・VPCエンドポイント

2-1. マネージドノードとは（EC2 / オンプレ / 他クラウド）

マネージドノードは、SSM Agent が導入され、IAM ロール（EC2 の場合はインスタンスプロファイル）またはハイブリッドアクティベーションによって SSM に登録されたサーバー・VM の総称です。マネージドノードとして登録されると、AWS マネジメントコンソールの「フリートマネージャー」画面に一覧表示され、SSM の全機能（Session Manager・Patch Manager・Run Command・Automation 等）を同一インターフェースから利用できます。

マネージドノードになれるのは以下の 3 種類です。

• EC2 インスタンス：SSM Agent プリインストール AMI を使うか、手動でインストール。インスタンスプロファイルに IAM ロールを紐付けるだけで登録完了。
• オンプレミスサーバー / 仮想マシン：ハイブリッドアクティベーションで発行したアクティベーションコードと ID を使って登録。マネージドノード ID は mi- プレフィックスで識別。
• 他クラウド VM（Azure / GCP 等）：オンプレと同じハイブリッドアクティベーション経由で登録可能。

登録後はマネージドノード ID（i- または mi-）単位でコマンド実行・パッチ適用・セッション接続が可能になります。

2-2. SSM Agent — プリインストール済みAMIと手動導入

SSM Agent は、マネージドノード上で SSM コントロールプレーンと HTTPS 通信するデーモンプロセスです。Agent が稼働・IAM 認証されていることがすべての SSM 機能の前提です。

プリインストール済み AMI（代表例）

以下の AWS 提供 AMI には SSM Agent がプリインストールされています。

【精度の罠③】「すべての AMI にプリインストール済み」は誤りです。Marketplace AMI・Community AMI のプリインストール有無は AWS 非サポート領域のため保証されません。また、プリインストール済みであっても 最新バージョンとは限りません。旧バージョンの Agent では Session Manager（2.3.68.0 以上）・KMS 暗号化（2.3.539.0 以上）・ポートフォワード（3.0.222.0 以上）などの機能が使えないため、自動更新の設定を必ず行ってください。

Agent の状態確認コマンド

# Linux — Agent の状態確認
sudo systemctl status amazon-ssm-agent

# バージョン確認
amazon-ssm-agent --version

# Windows PowerShell — Agent の状態確認
Get-Service AmazonSSMAgent

手動インストール（Amazon Linux / RHEL 系）

sudo yum install -y amazon-ssm-agent
sudo systemctl enable amazon-ssm-agent
sudo systemctl start amazon-ssm-agent

Agent の自動更新（State Manager 経由・推奨）

State Manager のアソシエーション AWS-UpdateSSMAgent を使うと、全マネージドノードの Agent を自動的に最新版に保てます。スケジュール（cron 式）と対象ノード（タグ・全台）を指定するだけで適用されます。アソシエーションの設定は §7-3 で詳述します。

2-3. IAM設計（インスタンスプロファイル・最小権限）

EC2 インスタンスを SSM に登録するには、インスタンスプロファイルに IAM ロールを紐付け、そのロールに AmazonSSMManagedInstanceCore マネージドポリシーを付与します。このポリシーが SSM の基本通信（Run Command・Session Manager・Patch Manager・State Manager）に必要な最小権限セットです。

機能別の追加権限

最小権限の原則：AdministratorAccess や AmazonSSMFullAccess を付与する必要はありません。AmazonSSMManagedInstanceCore ＋ 機能別追加権限で構成します。IAM ポリシーは用途別に分割し、インスタンスの役割に応じてアタッチします。

インスタンスプロファイルの適用タイミング

EC2 インスタンス起動後にインスタンスプロファイルを追加した場合、SSM Agent の再起動（sudo systemctl restart amazon-ssm-agent）で反映されます。EC2 メタデータエンドポイント（IMDS）経由で IAM クレデンシャルを取得するため、IMDSv2 を強制している環境でも追加設定は不要です。

CloudFormation での IAM ロール定義例

SSMInstanceRole:
  Type: AWS::IAM::Role
  Properties:
 AssumeRolePolicyDocument:
Version: "2012-10-17"
Statement:
  - Effect: Allow
 Principal:
Service: ec2.amazonaws.com
 Action: sts:AssumeRole
 ManagedPolicyArns:
- arn:aws:iam::aws:policy/AmazonSSMManagedInstanceCore

SSMInstanceProfile:
  Type: AWS::IAM::InstanceProfile
  Properties:
 Roles:
- !Ref SSMInstanceRole

トラブルシューティング：マネージドノードに表示されない場合

よくある原因は以下の 3 つです。対象インスタンスで sudo systemctl status amazon-ssm-agent を確認し、Agent が起動しているか検証してください。

1. インスタンスプロファイルが未設定 / IAM ロールに AmazonSSMManagedInstanceCore が未付与
2. SSM Agent が未インストール / 停止中
3. プライベートサブネットで VPC エンドポイントが未設定（インターネット経由もなし）

2-4. プライベートサブネットとVPCエンドポイント

インターネット接続のないプライベートサブネットのインスタンスを SSM に接続する方法は 2 つあります。

セキュリティ要件が厳しい本番環境では VPC エンドポイント方式が推奨です。

必要な VPC エンドポイント

【精度の罠①】「ssm / ssmmessages / ec2messages の 3 つが必須」という情報が広まっていますが、現在の正確な情報は異なります。

SSM Agent 3.3.40.0 以降は ssmmessages を優先し、ec2messages を使用しません。厳密には ssm と ssmmessages の 2 つが必須です。

ただし、東京リージョン（ap-northeast-1）は 2024 年以前のローンチリージョンであるため、旧バージョンの Agent やレガシーな設定が混在する可能性もあります。東京リージョンでは ec2messages も用意するのが安全策です。

セキュリティグループの設定

Interface 型エンドポイントのセキュリティグループには、マネージドノードからの HTTPS（ポート 443）インバウンドを許可します。マネージドノード側のセキュリティグループには アウトバウンド 443 の許可のみで十分です。SSM Agent が全接続をアウトバウンド開始するため、インバウンドポートの開放は不要です。NAT ゲートウェイも不要です。

Private DNS の有効化

Interface 型エンドポイントを作成する際は「プライベート DNS 名を有効化」を ON にします。これにより ssm.<region>.amazonaws.com の名前解決がエンドポイントの Private IP に向き、アプリケーション側の設定変更なしに VPC エンドポイントを経由できます。VPC の enableDnsHostnames および enableDnsSupport が true であることを事前に確認してください。

AWS CLI での一括作成例

# 東京リージョンの例（ssm / ssmmessages / ec2messages の 3 つを作成）
for svc in ssm ssmmessages ec2messages; do
  aws ec2 create-vpc-endpoint \
 --vpc-id vpc-XXXXXXXX \
 --vpc-endpoint-type Interface \
 --service-name com.amazonaws.ap-northeast-1.${svc} \
 --subnet-ids subnet-XXXXXXXX \
 --security-group-ids sg-XXXXXXXX \
 --private-dns-enabled \
 --region ap-northeast-1
done

2-5. ハイブリッドアクティベーション（オンプレ/非EC2の登録）

オンプレミスサーバーや他クラウド VM を SSM で管理するには「ハイブリッドアクティベーション」を使います。

登録手順の概要

1. AWS マネジメントコンソール → Systems Manager → ハイブリッドアクティベーション → アクティベーションを作成
2. アクティベーション ID と アクティベーションコード が発行される（有効期限・最大登録台数を指定）
3. 管理対象サーバーに SSM Agent をインストールし、次のコマンドで登録

sudo amazon-ssm-agent -register \
  -code "<アクティベーションコード>" \
  -id "<アクティベーション ID>" \
  -region "<リージョン>"
sudo systemctl start amazon-ssm-agent

1. 登録後、マネージドノード ID が mi- プレフィックスで発行される（例：mi-0a1b2c3d4e5f67890）

Standard / Advanced Instances Tier

【精度の罠④】「Advanced Instances Tier は EC2 でも必要」という誤解が広まっています。これは 完全に誤り です。

EC2 インスタンスは Standard/Advanced のどちらとも無関係で、常に追加料金なしです。

Advanced Tier が必要になるのは、非 EC2（mi-*）ノードに対して以下のいずれかを行う場合のみです。

1. 非 EC2 ノードを 1,000 台超管理する
2. 非 EC2 ノードへの Session Manager 接続（Standard では利用不可）
3. 非 EC2 ノードへの Patch Manager による Microsoft 公開アプリのパッチ適用

Advanced Tier への切り替えはアカウント / リージョン単位の一括設定（Service Setting）です。有効化すると対象リージョンの全 mi-* ノードに適用され、即時課金が発生します。不要になった場合は Standard に戻せます（ただし Standard 上限 1,000 台の範囲内に収まっている必要があります）。

2-6. ゴール状態の定義

§2 を完了した時点で、以下の状態が整っています。

• EC2 インスタンス：インスタンスプロファイルに AmazonSSMManagedInstanceCore を含む IAM ロールが設定され、SSM フリートマネージャーに i- ID で表示される
• オンプレ / 他クラウド VM：ハイブリッドアクティベーション経由で登録され、mi- ID でフリートマネージャーに表示される
• プライベートサブネットの EC2：VPC エンドポイント（ssm / ssmmessages / 東京は ec2messages 追加推奨）が構成され、NAT ゲートウェイなしで SSM に到達できる
• SSM Agent：全ノードが稼働中・バージョン確認済み・State Manager アソシエーションで自動更新設定済み

この状態を「マネージドノード群の SSM 登録完了」と定義します。§3 以降では、この登録済みノード群を使って各 SSM 機能を本番運用します。

3. Parameter Store：階層設計・SecureString・KMS・参照パターン

3-1. Parameter Storeの位置づけ（Secrets Managerとの使い分け）

Parameter Store と AWS Secrets Manager はともに機密値を安全に保管できますが、ユースケースが異なります。料金と機能の両面で適切なサービスを選択してください。

判断指針: DBパスワード・APIキーのように定期ローテーションが必須なシークレットは Secrets Manager、アプリ設定値・フィーチャーフラグなどローテーション不要で大量管理したいパラメータは Parameter Store（Standard tier） で無料運用できます。

3-2. Standard tier vs Advanced tier

Parameter Store にはアカウント・リージョン単位で選択できる Standard と Advanced の2ティアがあります。

【★罠⑤】Standard は無制限ではなく上限 10,000。Advanced への変換後は戻れない

Standard tier のパラメータは Advanced に変換できますが、Advanced → Standard への降格は不可 です。8 KB のデータや Parameter Policies が設定されているパラメータを 4 KB 制限の Standard に戻す手段が存在しないためです。Advanced に移行する前に「戻れない」ことを前提とした設計レビューを必ず実施してください。

Parameter Policies（Advanced のみ） で設定できるポリシータイプ:

• Expiration: 指定日時にパラメータを自動削除
• ExpirationNotification: 有効期限 N 日前に EventBridge 経由で通知
• NoChangeNotification: 最終更新から N 日間変更がなければ通知

スループット（TPS）について: デフォルト TPS と higher-throughput 有効時の上限値は公式 Service Quotas ページを参照してください。SecureString は KMS 側のリクエスト上限にも律速される点に注意が必要です。

3-3. 階層設計と命名規約

Parameter Store のパラメータ名は / を使った 階層パス で構造化できます。階層設計を採用することで、IAM ポリシーでのパス単位アクセス制御と GetParametersByPath による一括取得が可能になります。

推奨命名規則: /service/env/category/key

/myapp/prod/database/endpoint
/myapp/prod/database/password
/myapp/prod/api/external-key
/myapp/staging/database/endpoint
/shared/prod/smtp/host

設計ポイント:

• 第1階層: サービス名 — /myapp/, /platform/, /shared/
• 第2階層: 環境 — /prod/, /staging/, /dev/
• 第3階層以降: 機能カテゴリ・キー名 — /database/endpoint, /api/key
• 最大 15 階層、パス全体は 1,011 文字以内

GetParametersByPath による一括取得:

aws ssm get-parameters-by-path \
  --path "/myapp/prod/" \
  --recursive \
  --with-decryption \
  --query "Parameters[*].{Name:Name,Value:Value}" \
  --output table

起動時に全パラメータを一括取得してキャッシュするパターンが一般的です。個別 GetParameter を多数呼ぶと TPS 上限・コストに影響するため、起動時一括取得 → メモリキャッシュ → 定期再取得のパターンを採用してください。

IAM パスプレフィックス制御:

{
  "Effect": "Allow",
  "Action": ["ssm:GetParameter", "ssm:GetParametersByPath"],
  "Resource": "arn:aws:ssm:ap-northeast-1:123456789012:parameter/myapp/prod/*"
}

開発者は /myapp/dev/*、本番デプロイロールは /myapp/prod/* のみアクセス可能といった最小権限設計が実現できます。

3-4. SecureString と KMS

SecureString は KMS で暗号化して保存するパラメータタイプです。保存時は KMS で暗号化し、取得時に KMS で復号します。

【★罠⑥】aws/ssm マネージドキーはアクセス制御不可 — きめ細かい制御には CMK を指定

KeyId を省略して SecureString を作成すると SSM が自動で管理する alias/aws/ssm（AWS マネージドキー） が使用されます。このキーは キーポリシーを変更できない ため、誰が暗号化・復号できるかをきめ細かく制御できません。またクロスアカウント共有も不可です。きめ細かいアクセス制御が必要な場合は カスタマー管理キー（CMK）を --key-id で明示指定 してください。対称鍵のみ対応（非対称鍵は使用不可）。

# CMK を明示指定して SecureString を作成
aws ssm put-parameter \
  --name "/myapp/prod/database/password" \
  --type "SecureString" \
  --key-id "alias/myapp-prod-ssm-key" \
  --value "supersecretpassword"

# SecureString の取得 — WithDecryption 必須
aws ssm get-parameter \
  --name "/myapp/prod/database/password" \
  --with-decryption \
  --query "Parameter.Value" --output text

--with-decryption を省略すると暗号文のまま返ります。 boto3 でも WithDecryption=True を忘れないでください。

SecureString アクセスに必要な IAM 権限（CMK 使用時）:

{
  "Effect": "Allow",
  "Action": ["ssm:GetParameter", "ssm:GetParametersByPath"],
  "Resource": "arn:aws:ssm:ap-northeast-1:123456789012:parameter/myapp/prod/*"
},
{
  "Effect": "Allow",
  "Action": ["kms:Decrypt"],
  "Resource": "arn:aws:kms:ap-northeast-1:123456789012:key/<cmk-key-id>"
}

CMK を使う場合は IAM に kms:Decrypt が必須です。aws/ssm マネージドキーの場合は SSM を通じた復号で暗黙的に動作しますが、CMK では明示的な権限付与が必要です。

3-5. アプリ・IaCからの参照パターン

① Boto3（Python）— 起動時一括キャッシュパターン:

import boto3

ssm = boto3.client('ssm', region_name='ap-northeast-1')

def get_all_params(path):
 params = {}
 paginator = ssm.get_paginator('get_parameters_by_path')
 for page in paginator.paginate(
Path=path, Recursive=True, WithDecryption=True):
  for p in page['Parameters']:
key = p['Name'].replace(path, '', 1).lstrip('/')
params[key] = p['Value']
 return params

# Lambda/ECS 初期化フェーズで一括取得してキャッシュ
CONFIG = get_all_params('/myapp/prod/')

② CloudFormation 動的参照:

Resources:
  MyFunction:
 Type: AWS::Lambda::Function
 Properties:
Environment:
  Variables:
 # String パラメータ参照
 DB_ENDPOINT: '{{resolve:ssm:/myapp/prod/database/endpoint}}'
 # SecureString 参照（ssm-secure で復号値を直接設定）
 DB_PASSWORD: '{{resolve:ssm-secure:/myapp/prod/database/password}}'

{{resolve:ssm-secure:}} はデプロイ時に CloudFormation が復号した値を直接設定します。テンプレートに機密値を埋め込む必要がありません。

③ Terraform:

data "aws_ssm_parameter" "db_endpoint" {
  name = "/myapp/prod/database/endpoint"
}

data "aws_ssm_parameter" "db_password" {
  name= "/myapp/prod/database/password"
  with_decryption = true  # SecureString は true 必須
}

resource "aws_lambda_function" "app" {
  environment {
 variables = {
DB_ENDPOINT = data.aws_ssm_parameter.db_endpoint.value
DB_PASSWORD = nonsensitive(data.aws_ssm_parameter.db_password.value)
 }
  }
}

④ EC2 UserData:

#!/bin/bash
DB_ENDPOINT=$(aws ssm get-parameter \
  --name "/myapp/prod/database/endpoint" \
  --region ap-northeast-1 \
  --query "Parameter.Value" --output text)

echo "DB_HOST=${DB_ENDPOINT}" >> /etc/myapp/config

EC2 UserData から SSM を参照する場合、インスタンスプロファイルに ssm:GetParameter 権限が必要です。

⑤ Parameter Store vs Secrets Manager — 参照パターンの整理:

4. Session Manager：踏み台レス接続・ログ記録・ポートフォワーディング

4-1. 踏み台レス接続のアーキテクチャ

SSH踏み台サーバーを使う従来構成では、パブリックサブネットに踏み台EC2を配置し、インバウンドポート22（SSH）をセキュリティグループで開放する必要があった。SSHキーペアの配布・管理・ローテーション、踏み台自体のOS管理・パッチ適用コスト、そして踏み台が侵害された場合の横断移動リスクが常につきまとう。

Session Managerは、このアーキテクチャを根本から変えます。SSM Agentがインスタンス内からSSMサービスエンドポイントへアウトバウンド接続を確立し、オペレーターとインスタンスの通信を仲介します。インバウンドポートの開放・SSHキーペア・踏み台ホストのいずれも不要です。

セキュリティ面での優位点は主に3点です。まずインバウンドポート開放ゼロにより、攻撃者がネットワーク越しに直接アクセスできるエントリーポイントが消えます。次にSSHキー漏洩リスクが消え、IAMポリシーとSCPでアクセスを一元管理できます。最後に、全セッションを自動的にS3/CloudWatch Logsへ記録することで、「誰がいつどのコマンドを実行したか」の完全な監査証跡が残ります。

4-2. 前提とIAM・接続方法

前提条件の確認

オペレーター側のIAMポリシー

オペレーターがSession Managerを使うには以下の権限が最低限必要です。タグ条件（ssm:resourceTag）を使うことで、特定のタグを持つインスタンスへの接続のみを許可できます。

{
  "Version": "2012-10-17",
  "Statement": [
 {
"Effect": "Allow",
"Action": [
  "ssm:StartSession",
  "ssm:DescribeSessions",
  "ssm:GetConnectionStatus",
  "ssm:DescribeInstanceInformation",
  "ssm:TerminateSession"
],
"Resource": "*"
 },
 {
"Effect": "Allow",
"Action": "ssm:StartSession",
"Resource": "arn:aws:ec2:ap-northeast-1:123456789012:instance/*",
"Condition": {
  "StringEquals": {
 "ssm:resourceTag/AllowSSM": "true"
  }
}
 }
  ]
}

本番環境への接続には専用ロールを要求するSCPと組み合わせると、アカウントレベルでの強制が効きます。

接続方法: マネジメントコンソール

1. AWS Systems Managerコンソール → 左メニュー「ノード管理」→「Session Manager」
2. 「セッションを開始」をクリック
3. 対象インスタンスを選択 → 「セッションを開始」

ブラウザ内のターミナルが開き、EC2インスタンスに直接接続できます。

接続方法: AWS CLI

CLIから接続するにはSession Manager Plugin（AWS CLIのプラグイン）の事前インストールが必要です。

# EC2インスタンスへの接続
aws ssm start-session --target i-xxxxxxxxxx --region ap-northeast-1

# 特定のSession Documentを指定して接続
aws ssm start-session \
  --target i-xxxxxxxxxx \
  --document-name AWS-StartInteractiveCommand \
  --parameters command=["bash"]

--targetにはインスタンスIDのほか、mi-xxxxxxxxxx（ハイブリッドアクティベーション登録済みノード）も指定できます。

4-3. セッションログの記録（S3 / CloudWatch Logs / KMS）

Session Managerは接続中のセッション全体（入力コマンドと出力）を記録する機能を標準で持つ。本番運用では必ずログ記録を有効にし、監査証跡を確保すること。

ログ出力の設定

設定は「Systems Manager → Session Manager → 設定」から行う。

両方を同時に有効化することを推奨します。S3に長期ログを保管しつつ、CloudWatch Logsでリアルタイムに特定コマンド（sudo、rm -rf等）の実行を検知できます。

S3の設定

S3バケットにSSMサービスがオブジェクトを書き込めるよう、バケットポリシーが必要です。

{
  "Statement": [
 {
"Effect": "Allow",
"Principal": {"Service": "ssm.amazonaws.com"},
"Action": ["s3:PutObject", "s3:GetEncryptionConfiguration"],
"Resource": [
  "arn:aws:s3:::my-ssm-session-logs-123456789012",
  "arn:aws:s3:::my-ssm-session-logs-123456789012/*"
]
 }
  ]
}

KMS暗号化

KMS CMKでセッションデータとS3/CloudWatch Logsへの出力を暗号化できる（Agent 2.3.539.0以上が必要）。インスタンスプロファイルにkms:GenerateDataKeyとkms:Decryptの権限を追加し、Session Manager設定でCMK ARNを指定する。CMKのキーポリシーで、SSMサービスとインスタンスのIAMロールへの使用許可を付与することも忘れないようにしたい。

セッション履歴の保持

Session Managerコンソールではセッション履歴を30日間確認できる（公式ドキュメント参照）。30日を超えるログはS3またはCloudWatch Logsの保持設定で管理する。

4-4. ポートフォワーディングとSSH over SSM

ポートフォワーディング機能を使うと、セキュリティグループのインバウンドルールを一切開けずに、EC2インスタンスを経由してプライベートなRDS/Redis/その他サービスへアクセスできます。

ローカルポート → EC2インスタンスのポートフォワード

EC2インスタンス自体の特定ポートにローカルからアクセスする場合:

aws ssm start-session \
  --target i-xxxxxxxxxx \
  --document-name AWS-StartPortForwardingSession \
  --parameters '{"portNumber":["3306"],"localPortNumber":["13306"]}'

ローカルの13306ポートに接続すると、EC2インスタンスの3306ポートに転送されます。

ローカルポート → EC2を中継してリモートホストへのポートフォワード

RDS/ElastiCacheはSession Managerのターゲットに直接指定できません。AWS-StartPortForwardingSessionToRemoteHostドキュメントでEC2経由のポートフォワードが実現できます:

# RDSへの接続例 (PostgreSQL)
aws ssm start-session \
  --target i-xxxxxxxxxx \
  --document-name AWS-StartPortForwardingSessionToRemoteHost \
  --parameters '{"portNumber":["5432"],"localPortNumber":["15432"],"host":["mydb.xxxxxxxxxx.ap-northeast-1.rds.amazonaws.com"]}'

# ElastiCache (Redis) への接続例
aws ssm start-session \
  --target i-xxxxxxxxxx \
  --document-name AWS-StartPortForwardingSessionToRemoteHost \
  --parameters '{"portNumber":["6379"],"localPortNumber":["16379"],"host":["my-redis.xxxxxx.0001.apne1.cache.amazonaws.com"]}'

別ターミナルでローカルの127.0.0.1:15432に接続するとRDSに到達できます。RDSセキュリティグループのインバウンドにEC2のSGからの接続を許可するだけで、22番開放は不要です。

SSH over Session Manager

既存のSSH接続を維持しつつ踏み台を廃止する場合、SSH over SSMが有効です（Agent 3.0.222.0以上が必要）。~/.ssh/configに以下を追記します:

Host i-* mi-*
  ProxyCommand sh -c "aws ssm start-session --target %h --document-name AWS-StartSSHSession --parameters 'portNumber=%p'"

この設定後、通常のsshコマンドでEC2インスタンスIDを直接指定できます:

ssh -i my-key.pem ec2-user@i-xxxxxxxxxx
scp -i my-key.pem my-file.txt ec2-user@i-xxxxxxxxxx:/tmp/

SSH over SSMではSSHキーペアは引き続き必要ですが、踏み台サーバーとインバウンドポート開放は不要になります。SCPやrsyncも使えるため、既存ファイル転送ワークフローへの影響を最小化しながらゼロ踏み台構成に移行できます。

4-5. 運用上のガードレール

Session Managerを本番導入する際は「誰でも自由に操作できる」状態にならないよう、複数のガードレールを組み合わせます。

Session Document による接続コンテキスト制限

カスタムSession Documentを作成し、IAMポリシーでデフォルトDocumentへのアクセスを制限することで操作を絞り込めます。ssm:StartSessionリソースをカスタムDocumentのARNに限定することで、許可した操作セットのみをオペレーターが実行できる構成にします。

IAM条件キーによる細粒度制御

ssm:resourceTag条件キーを使うと、EC2タグに基づいてアクセスを制御できます。AllowSSM=trueタグを持つインスタンスのみへの接続を許可し、タグのないインスタンスや本番環境には別ロールを要求する構成が可能です。またaws:SourceIp条件キーで接続元IPアドレスをVPN経由のIPに限定できます。

アイドルタイムアウト設定

Session Manager設定のアイドルセッションタイムアウトはデフォルト20分（設定範囲1〜60分）です。本番環境では適切なタイムアウト値を設定し、使われていないセッションが長時間放置されないようにしましょう。

CloudWatch Logsを使ったリアルタイム検知

CloudWatch Logsに出力されたセッションログに対して、メトリクスフィルターを設定できます。sudoやpasswdなどの危険なコマンドが実行された際にSNSアラートを発報する構成が実現できます。CloudWatch Logs Insightsによる任意期間のコマンド検索も有効です。

SCPとの組み合わせ

Organizations SCPで「本番アカウントへの接続はMFA必須」「接続可能なRegionを限定」といった組織レベルの強制を行えます。SCPはIAMポリシーより上位の制御であるため、インスタンスプロファイルや管理者IAMの設定漏れを補完する最後の防護線となります。

§5 Patch Manager + Maintenance Windowsへ

5. Patch Manager + Maintenance Windows：パッチベースライン・本番運用

5-1. パッチ管理の全体像

AWS Patch Manager は、EC2・オンプレ・他クラウドを含むマネージドノードへのOS/アプリパッチ適用を自動化するサービスです。コア機能は「スキャン」と「スキャン＋インストール」の2モードです。

スキャンのみ（Scan）

パッチのインストールは行わず、各ノードのパッチ適用状況（Compliant / Non-Compliant）を収集・レポートします。本番環境のコンプライアンス状況把握やリスク評価に使用します。スキャン結果はSystems Managerの「コンプライアンス」ビューに反映され、CloudWatch MetricsおよびSecurity Hubとも連携できます。

スキャン＋インストール（Scan and Install）

パッチをスキャンし、ベースラインで承認済みのパッチを自動インストールします。通常はMaintenance Windows（§5-3参照）と組み合わせてスケジュール実行します。Run Commandドキュメント AWS-RunPatchBaseline を使用し、パラメータ Operation=Install を指定します。

対応OS一覧（主要）

スキャン/インストールは AWS-RunPatchBaseline ドキュメントを通じて実行されます。Maintenance Windowsにタスクとして登録するのが本番標準です。

5-2. パッチベースラインとPatch Group

5-2-1. AWS提供の事前定義ベースライン

各OSに対してAWSが事前に提供するベースラインです。設定変更は不可ですが、カスタムベースライン作成時の参照元として機能します。

事前定義ベースラインはCritical/Important（Windows）またはCritical/Security（Linux）分類のパッチをリリースから7日後に自動承認する設定がデフォルトです。本番でより厳格な制御が必要な場合はカスタムベースラインを作成します。

5-2-2. カスタムベースラインと承認ルール

カスタムベースラインで環境・OS・リスク許容度に合わせた承認ルールを定義します。

主要な設定項目：

# カスタムベースライン作成例（Amazon Linux 2 / 14日自動承認）
aws ssm create-patch-baseline \
  --name "MyProdAL2Baseline" \
  --operating-system "AMAZON_LINUX_2" \
  --approval-rules '{
 "PatchRules": [{
"PatchFilterGroup": {
  "PatchFilters": [
 {"Key":"CLASSIFICATION","Values":["Security","Bugfix"]},
 {"Key":"SEVERITY","Values":["Critical","Important"]}
  ]
},
"ApproveAfterDays": 14,
"ComplianceLevel": "CRITICAL",
"EnableNonSecurity": false
 }]
  }' \
  --description "Production AL2 baseline: 14-day auto-approval for Critical/Important"

5-2-3. Patch Group タグとベースライン紐付け（★罠⑧）

Patch Groupはノードをグループ化し、グループ単位でパッチベースラインを紐付ける仕組みです。EC2インスタンスに所定のタグを付与してグループへの所属を宣言します。

【★重要・精度の罠⑧】Patch Groupタグのキー名：

「スペース有りの Patch Group だけが正解」は誤りです。どちらのキー名も有効で、タグの値がグループ名になります。

例外：IMDS tag enabled環境では「PatchGroup」（スペース無し）が必須

EC2インスタンスでIMDS（インスタンスメタデータサービス）のタグアクセスを許可（allow-instance-metadata-tags = enabled）している場合、IMDSはキーにスペースを含む文字列を扱えません。この設定がある環境では PatchGroup（スペース無し） のみが有効です。Patch Group（スペース有り）タグを付けてもPatch Groupとして認識されないため注意が必要です。

# タグ付与例（スペース有り — IMDS tag disabled環境）
aws ec2 create-tags --resources i-0abc1234567890 \
  --tags Key="Patch Group",Value="prod-web"

# タグ付与例（スペース無し — IMDS tag enabled環境では必須）
aws ec2 create-tags --resources i-0abc1234567890 \
  --tags Key="PatchGroup",Value="prod-web"

クォータ:
– パッチベースライン: 50/アカウント/リージョン
– Patch Group/ベースライン: 25グループ/ベースライン

5-2-4. 2022-12-22以降の新規アカウントにおけるUI変更（★罠⑨）

【★重要・精度の罠⑨】2022年12月22日以降に新規利用開始したアカウント・リージョンでは、コンソールの「Patch Groups」直接操作画面が表示されず、Quick Setupのpatch policiesが推奨の設定経路となっています。

これはPatch Manager本体機能のEOL（廃止）ではなく、管理UXの移行です。パッチベースラインの承認ルール・スキャン・インストールのコア機能は引き続き動作します。古い手順書（コンソールからPatch Groupを直接管理）が使えない場合は、AWS CLIまたはpatch policiesで設定するのが確実です。

5-3. Maintenance Windows によるスケジュール適用

Maintenance Windows（メンテナンスウィンドウ）は、定義したスケジュール内でのみタスクを実行する時間枠管理の仕組みです。Patch Managerタスク（AWS-RunPatchBaseline）だけでなく、Automation Runbook・Run Command・Lambda呼び出しも登録できます。

5-3-1. ウィンドウ定義

カットオフを設定することで、ウィンドウ終了間際に開始したタスクが時間内で完了できず中途半端な状態のまま残るリスクを軽減できます。

# メンテナンスウィンドウ作成例
aws ssm create-maintenance-window \
  --name "prod-web-patch-window" \
  --schedule "cron(0 2 ? * SUN *)" \
  --duration 4 \
  --cutoff 1 \
  --allow-unassociated-targets \
  --schedule-timezone "Asia/Tokyo"

5-3-2. ターゲットとタスクの登録

ターゲット登録（タグベース）:

# Patch Groupタグを持つノードをターゲットに追加
aws ssm register-target-with-maintenance-window \
  --window-id "mw-0abc12345" \
  --resource-type INSTANCE \
  --targets "Key=tag:Patch Group,Values=prod-web" \
  --name "prod-web-servers"

パッチタスクの登録:

# AWS-RunPatchBaseline を Maintenance Windows タスクとして登録
aws ssm register-task-with-maintenance-window \
  --window-id "mw-0abc12345" \
  --targets "Key=WindowTargetIds,Values=<target-id>" \
  --task-arn "AWS-RunPatchBaseline" \
  --task-type RUN_COMMAND \
  --max-concurrency "10%" \
  --max-errors "5%" \
  --task-invocation-parameters '{
 "RunCommand": {
"Parameters": {
  "Operation": ["Install"],
  "RebootOption": ["RebootIfNeeded"]
}
 }
  }'

5-3-3. ロールアウト制御（MaxConcurrency / MaxErrors）

本番フリート全体へ一斉にパッチを当てると可用性に影響します。以下のパラメータで安全に段階制御します。

MaxErrors を超えると残りノードへのタスク実行が自動停止します。パッチ起因の障害が発生した場合、全台展開される前にロールアウトを止められます。

再起動ポリシーの選択指針：

• NoReboot: カーネルパッチ等、再起動が必要なパッチもインストールのみ行い再起動しません。ブルーグリーンデプロイや次回のメンテナンスウィンドウで古いインスタンスを自然に入れ替える構成に適しています。
• RebootIfNeeded: 必要な場合のみ再起動します。ウィンドウのDuration内に全台の再起動が完了することをキャパシティ計算してから使用します。

5-4. コンプライアンスレポートと是正

5-4-1. パッチコンプライアンスの確認

スキャン/インストール後、各ノードのコンプライアンス状態がSystems Managerに記録されます。

コンソールの Fleet Manager → コンプライアンス ページで全ノードのサマリを確認できます。Patch Groupや重大度でフィルタリング可能です。

5-4-2. CloudWatch との連携

# Non-Compliantノード数をCloudWatchカスタムメトリクスへ送信（例）
aws cloudwatch put-metric-data \
  --namespace "SSM/PatchCompliance" \
  --metric-name "NonCompliantCount" \
  --dimensions Name=PatchGroup,Value=prod-web \
  --value 3 \
  --unit Count

CloudWatch Alarmsで Non-Compliant 数が閾値を超えたらSNS通知を発報するという運用フローが一般的です。EventBridgeルールと組み合わせ、SSM Compliance Change イベントをトリガーにした自動通知も設定できます。

5-4-3. Security Hub との連携

AWS Security Hub の「Software and Configuration Checks」カテゴリに、Patch Complianceの結果がFindings（検出結果）として自動連携されます。

有効化手順:
1. Security Hub → 統合（Integrations）→「AWS Systems Manager Patch Manager」を有効化
2. Non-Compliantノードが自動的にFindingsとして表示される
3. FindingsをSecurity HubのダッシュボードでCritical/High等の重大度と合わせて優先順位付け

5-4-4. 未準拠ノードの是正フロー

Non-Compliantノード検出
  → CloudWatch Alarm発報 / Security Hub Finding / SNS通知
  → 原因特定
├─ パッチが拒否リストに入っている？ → ベースライン修正
├─ Maintenance Windowの期間が不足？ → Duration拡大またはCutoff調整
└─ ノードがオフライン中だった？ → 復旧後に再実行
  → 手動パッチ適用（Run Command: AWS-RunPatchBaseline / Operation=Install）
  → 再スキャンで Compliant 確認

緊急パッチ（CVSS 9.0以上等）はMaintenance Windowを待たず、Run Commandで即時適用する運用ポリシーを事前に定義しておくことを強く推奨します。

5-5. 本番運用のベストプラクティス

5-5-1. リング展開（段階適用）

Patch Groupを環境・役割ごとに分割し、メンテナンスウィンドウの実行曜日・時刻を段階的にずらすことで、パッチ問題を本番全展開前に早期検出します。

Ring 0/1で障害が発生した場合、当該パッチをベースラインの「拒否リスト」に追加することでRing 2/3への展開を即時停止できます。

5-5-2. State Managerとの組み合わせ

Maintenance Windowsはスケジュール駆動ですが、State Managerのアソシエーションを組み合わせることで、新規インスタンス起動直後のコンプライアンス状態を即座に把握できます。

# 新規ノードを対象とした定期スキャンアソシエーション
aws ssm create-association \
  --name "AWS-RunPatchBaseline" \
  --targets "Key=tag:Environment,Values=prod" \
  --parameters '{"Operation":["Scan"]}' \
  --schedule-expression "cron(0 6 * * ? *)" \
  --compliance-severity "CRITICAL"

5-5-3. InventoryとAthenaによる横断分析

SSM Inventoryのアプリ/パッチデータをResource Data SyncでS3に集約し、Athenaでクエリを実行することで、アカウント・リージョン横断のパッチ状況を分析できます。複数アカウント環境では、各アカウントのS3バケットをCross-Account Resource Data Syncで中央バケットに集約する構成が推奨です。

6. Automation + Runbook：運用自動化・承認制御・カスタムRunbook

6-1. Automationの位置づけ（運用手順のコード化）

AWS Systems Manager Automation は、EC2インスタンスのAMI作成・パッチ適用・タグ是正・起動/停止といった運用手順を Runbook（ドキュメント） としてコード化し、繰り返し実行可能にするサービスです。手動の運用手順書を Runbook に置き換えることで、次の価値が生まれます。

• 再現性: 担当者が変わっても同じ手順が実行される
• 監査証跡: 実行ログ・ステップ結果が30日間 Systems Manager コンソールに保存される
• スケール: 1台から数千台のフリートへ同一Runbookを適用できる
• 安全制御: 承認ゲート・エラー閾値・同時実行上限を Runbook 内に組み込める

Run Command が単発のコマンド実行を担うのに対し、Automation はマルチステップのワークフローを定義し、条件分岐・承認・ロールバックを1つのドキュメントで表現できる点が特徴です。

Automation は Systems Manager の他機能と密接に連携します。Maintenance Windows のタスクとして登録すればスケジュール実行、EventBridge ルールから呼び出せばイベント駆動の自動修復、Change Manager の承認フローと組み合わせれば変更管理プロセスへの組み込みが実現します。

6-2. マネージドRunbook vs カスタムRunbook

6-2-1. マネージドRunbook（AWS-* プレフィックス）

AWS が事前に定義・管理するRunbookで、AWS- プレフィックスで識別します。コンソールの「Documents」から検索可能で、ユーザーは変更できません（コピーしてカスタマイズは可能）。代表的なものを以下に示します。

6-2-2. カスタムRunbook（YAML/JSON形式）

ユーザーが定義するRunbookで、YAML または JSON で記述します。基本構造は以下の通りです。

schemaVersion: "0.3"
description: "カスタムRunbookのサンプル"
assumeRole: "{{ AutomationAssumeRole }}"
parameters:
  AutomationAssumeRole:
 type: AWS::IAM::Role::Arn
  InstanceId:
 type: String
mainSteps:
  - name: stopInstance
 action: aws:changeInstanceState
 inputs:
InstanceIds:
  - "{{ InstanceId }}"
DesiredState: stopped
  - name: createSnapshot
 action: aws:createImage
 inputs:
InstanceId: "{{ InstanceId }}"
ImageName: "backup-{{ global:DATE }}"
  - name: startInstance
 action: aws:changeInstanceState
 inputs:
InstanceIds:
  - "{{ InstanceId }}"
DesiredState: running

代表的なステップアクションを以下に示します。

6-2-3. blocking action の上限制約【★精度の罠⑩】

aws:approve / aws:pause / aws:sleep は blocking action カテゴリに分類されます。これらを含む Automation の同時実行上限は、通常の Automation 実行枠（デフォルト100、adaptive concurrency で最大500）とは別枠の 400 が適用されます。

大規模なフリートで承認付きRunbookを並列実行する場合、この上限へ先に到達する可能性があります。設計時には注意してください。

また、ユーザーコンテキスト（IAMユーザー/ロールで開始した場合）の Automation は最大12時間で強制終了します。承認待ちを含む長時間処理（例: 12時間を超えるパッチ適用フロー）では、assumeRole にサービスロールを指定することが必須です。サービスロールを使うと12時間制限が適用されません。

# 長時間Runbookではサービスロールを明示
assumeRole: "arn:aws:iam::123456789012:role/SSMAutomationRole"

その他の上限（公式ドキュメント参照）:
– ネスト上限: 5段
– 実行履歴保持: 30日
– Rate Control Automation の同時実行: 25 / キュー: 1,000

6-3. 承認制御とレート制御

6-3-1. aws:approve による承認ゲート

aws:approve ステップを Runbook に差し込むことで、ワークフローの途中に人間の承認ゲートを設けられます。代表的なユースケースは本番環境へのデプロイ前承認、大規模パッチ適用前の確認などです。

  - name: WaitForApproval
 action: aws:approve
 timeoutSeconds: 3600# 承認タイムアウト（例: 1時間）
 inputs:
Approvers:
  - "arn:aws:iam::123456789012:role/OpsTeamRole"
Message: "本番EC2への適用を承認してください"
MinRequiredApprovals: 1

承認者（Approvers）には IAM ユーザー ARN・ロール ARN・SNS トピック ARN を指定できます。SNS を使うと承認依頼メールを送信し、コンソールまたは API で承認/拒否を返せます。

承認タイムアウト（timeoutSeconds）を超えると Automation はタイムアウトエラーで終了します。承認待ちが長時間に及ぶ場合は、前述のサービスロールを必ず設定してください。

6-3-2. MaxConcurrency / MaxErrors によるレート制御

複数ターゲットへの一括実行（Rate Control Automation）では、MaxConcurrency と MaxErrors でフリートへの影響範囲を制限します。

aws ssm start-automation-execution \
  --document-name "MyCustomRunbook" \
  --target-parameter-name "InstanceId" \
  --targets "Key=tag:Env,Values=production" \
  --max-concurrency "10%" \
  --max-errors "5%"

MaxConcurrency "10%" を指定すると、全ターゲット台数の10%ずつ段階的に適用します。MaxErrors "5%" を超えた時点で残りターゲットへの実行が停止するため、問題が全体に波及するリスクを抑えられます。

6-3-3. ロールバック設計

失敗ステップの後にロールバックステップを組み込むことで、部分的な失敗から復旧できます。

mainSteps:
  - name: applyChange
 action: aws:executeScript
 onFailure: step:rollbackChange  # 失敗時にロールバックへジャンプ
 nextStep: verifyChange
 inputs:
...
  - name: verifyChange
 action: aws:executeScript
 onFailure: step:rollbackChange
 nextStep: end
 inputs:
...
  - name: rollbackChange
 action: aws:executeScript
 isEnd: true
 inputs:
...

onFailure: step:<stepName> でジャンプ先を指定することで、失敗時の復旧ステップを明示的に定義します。

6-4. トリガー連携（EventBridge / Maintenance Windows / Change Manager）

6-4-1. EventBridge からのイベント駆動トリガー

CloudWatch アラームや EventBridge ルールから Automation を呼び出すことで、自動修復ワークフローを構築できます。

{
  "source": ["aws.ec2"],
  "detail-type": ["EC2 Instance State-change Notification"],
  "detail": {
 "state": ["stopped"]
  }
}

上記のような EventBridge ルールにターゲットとして aws:automation:startAutomationExecution を設定すると、EC2インスタンスが予期せず停止したタイミングで自動的に Runbook が起動します。

6-4-2. Maintenance Windows との連携

Maintenance Windows のタスクタイプに「Automation」を選択すると、メンテナンスウィンドウのスケジュールで Runbook を定期実行できます（§5参照）。パッチ適用後の動作確認 Runbook や、週次のバックアップ Runbook などの用途に適しています。

6-4-3. Change Manager との連携

Change Manager は変更申請→承認→実行を管理するサービスです。承認された変更テンプレートが Automation Runbook を実行する形で統合されます。

フローは「Change Manager に変更申請→承認者が Change Calendar を考慮して承認→Runbook 自動実行→結果が申請に紐付けて記録」という順序です。ITIL準拠の変更管理プロセスをコードで実装できます。

6-4-4. State Manager との連携

State Manager のアソシエーションにドキュメントタイプ Automation を指定すると、設定ドリフト検知時に Runbook を自動実行できます。「必須タグが欠落しているインスタンスにタグを付与する」Runbook を定期実行することで、タグ管理の継続的なコンプライアンスが実現します。

6-5. 運用自動化のユースケース

本節では Automation の典型的なユースケースを紹介します。インシデント発生時の自動修復 Runbook（ロールバック手順・根本原因分析フロー等）については、インシデント対応Runbook詳細 に詳細を委譲します。

AMI 作成の自動化（ゴールデンイメージ管理）

マネージドRunbook AWS-CreateImage または AWS-CreateManagedLinuxAmi を使い、定期的にベースAMIを更新するワークフローを構築します。Maintenance Windows と組み合わせて月次スケジュール実行し、古いAMIを自動削除する後続ステップを加えることで、ゴールデンイメージ管理を無人化できます。

タグ是正の自動化

タグポリシー違反インスタンスを Config ルールで検出し、EventBridge 経由で是正 Runbook を起動するパターンです。aws:executeScript (Python) でタグ付与 API を呼び出し、是正完了を SNS で通知します。

起動/停止スケジューリング

開発環境の夜間停止・朝の自動起動を Maintenance Windows + AWS-StopEC2Instance / AWS-StartEC2Instance で実現します。aws:branch ステップで環境タグを判定し、本番環境への誤適用を防止する構成も容易です。

パッチ適用後の動作確認

AWS-PatchInstanceWithRollback Runbook は、パッチ適用後に動作確認スクリプトを実行し、失敗した場合にスナップショットからロールバックするワークフローを提供します。本番環境では MaxConcurrency "10%" + MaxErrors "2%" を組み合わせて段階展開します。

インシデント対応Runbook詳細はこちら

7. Fleet Manager / Inventory / State Manager / Compliance / OpsCenter

7-1. Fleet Manager（ノードのGUI一元管理）

Fleet Managerは、マネージドノードの状態をAWSマネジメントコンソール上で一元的に可視化・操作するUIレイヤーです。Systems Managerコンソールの「Fleet Manager」から、登録済みのすべてのマネージドノード（EC2・オンプレ・マルチクラウド混在）を一覧で確認できます。Fleet Managerそのものはデータ収集機能を持たず、SSM Agent・Inventory・Complianceが収集したデータをビジュアライズする統合ビューとして機能します。

表示される主な情報

GUI Connect（RDP / SSH接続）

Fleet ManagerはWebブラウザからのRDP（Windowsノード）・SSH接続（Linuxノード）をサポートする「GUI Connect」機能を備えています。Session Managerバックエンドを利用するため、インバウンドポート開放・SSHキー・踏み台ホストが不要です。

⚠️ RDP接続の制限事項（精度の罠⑪）

Fleet ManagerのRDP接続にはSSM・Windows双方の制約があります:

• SSM側制約: GUI Connect同時セッション数は既定5セッション（最大50まで自動承認リクエスト可）。セッションタイムアウト最大60分・アイドル10分で自動切断
• Windowsライセンス制約: Windows標準ライセンスはRDPを同時2接続まで許可。3接続以上にはMicrosoft CAL（クライアントアクセスライセンス）またはAWS向けRDS SAL（リモートデスクトップサービスCAL）が別途必要。これはAWS/SSMの制約ではなくWindowsライセンスポリシーの制約
• ノード推奨上限: Fleet Manager推奨上限は2,400マネージドノード/アカウント/リージョン

ファイルシステム閲覧

Fleet Managerではノードのファイルシステムをコンソールからブラウズできます。設定ファイルの確認やログファイルの閲覧をSSH/RDPなしに実行可能です。LinuxではPosixパス（/var/log/等）、WindowsではCドライブ以下のディレクトリツリーを参照できます。

パフォーマンスカウンタ

CPU使用率・メモリ使用率・ディスクI/Oをリアルタイムで確認できます。詳細なメトリクス監視はCloudWatchに委任しますが、Fleet Managerは接続前の疎通確認・簡易ヘルスチェックの初動調査に適しています。

7-2. Inventory（メタデータ収集と分析）

SSM Inventoryは、マネージドノードのメタデータ（ソフトウェア・OS・ネットワーク設定等）を定期的に収集し、SSM管理データとして保持するサービスです。Patch Managerやコンプライアンスとの連携で「今どのノードに何が入っているか」を把握する構成管理の基盤となります。

収集できる主なデータ型

収集設定（State Manager経由）

Inventoryデータの収集はState ManagerのAssociation（アソシエーション）として実装されます。AWS-GatherSoftwareInventoryドキュメントを使用し、収集間隔（最短30分）・収集対象データ型を指定します。コンソールの「Inventory設定」から簡単にセットアップでき、裏側でState Manager Associationが自動作成されます。

# 手動でAssociationを作成する場合
aws ssm create-association \
  --name "AWS-GatherSoftwareInventory" \
  --targets "Key=InstanceIds,Values=*" \
  --schedule-expression "rate(1 day)" \
  --parameters '{"applications":["Enabled"],"awsComponents":["Enabled"],"networkConfig":["Enabled"]}'

Resource Data Sync（S3集約・マルチアカウント分析）

複数リージョン・複数アカウントのInventoryデータをS3に集約する機能です。S3集約後にAthenaやAWS QuickSightと連携して大規模フリートの構成分析が可能になります。

SSM Inventory（各リージョン・各アカウント）
 ↓ Resource Data Sync（自動同期）
S3バケット（集約先・Athena用パーティション構造）
 ↓ Athena / QuickSight
フリート全体の構成管理・監査レポート

Resource Data Sync設定手順:

1. 集約先S3バケットにSSMサービスへの書き込み権限を付与（バケットポリシーにssm.amazonaws.comを追加）
2. Systems Managerコンソール → フリートマネージャー → Resource Data Sync → 同期の作成
3. 同期タイプ: 「SyncToDestination」(当該アカウント) または 「SyncFromSource」(Organizationsメンバー横断)

AthenaでのInventoryデータ分析例

-- 古いSSM Agentが残存するノードを特定
SELECT resourceid, name, version
FROM "ssm_inventory_db"."aws_ssmagentstatus"
WHERE CAST(SPLIT_PART(version, '.', 1) AS INTEGER) < 3
ORDER BY version;

-- OSバージョン別のノード分布
SELECT platformname, platformversion, COUNT(*) AS node_count
FROM "ssm_inventory_db"."aws_instancedetailedinformation"
GROUP BY platformname, platformversion
ORDER BY node_count DESC;

カスタムインベントリ

標準データ型にないメタデータをCustom:*プレフィックスで定義できます。対象ノードに特定パスへJSONファイル（インベントリスキーマ定義）を配置することで収集対象になります。アプリのリリースバージョン・環境変数設定値・独自タグ情報などの管理に活用できます。

7-3. State Manager（設定ドリフト防止）

State Managerは、マネージドノードの「あるべき状態」をAssociation（アソシエーション）として定義し、定期的に適用する構成管理サービスです。一度設定した状態がドリフト（意図しない変更・設定ずれ）しても、次のスケジュール実行時に自動で是正されます。

アソシエーション（Association）の概念

アソシエーションは「どのノードに」「どのSSMドキュメントを」「いつ・どんなパラメータで」適用するかを定義したルールです。

代表的なアソシエーション活用パターン

1. SSM Agentの自動更新（最重要ユースケース）: AWS-UpdateSSMAgentドキュメントをレート14日で全マネージドノードに適用。Session Manager・Patch Manager等の機能がAgent要件バージョンを前提とするため、自動更新は必須の設定です。

2. CloudWatchエージェントの設定配布: AWS-ConfigureAWSPackageでCloudWatch Agentをインストール・更新。AmazonCloudWatch-ManageAgentで設定ファイルをParameter Storeから取得して配布。設定変更時にAssociationを再実行するだけで全ノードへ伝播します。

3. 設定ファイルの継続配布と是正: AWS-RunShellScript（Linux）やAWS-RunPowerShellScript（Windows）でカスタムスクリプトを定期実行。タイムゾーン設定・カーネルパラメータ・セキュリティ設定等の一貫適用と是正を自動化します。

コンプライアンス追跡

アソシエーションの実行結果（成功/失敗）はComplianceサービスに自動集約されます。失敗ノードの特定とEventBridgeによる自動通知を組み合わせることで、設定ドリフトの即時検知・自動是正トリガーが実現します。

7-4. Compliance（コンプライアンスの集約ビュー）

ComplianceはPatch ManagerとState Managerの結果を一元表示するダッシュボードです。個別サービスを横断して確認することなく、フリート全体の「パッチ適用状態」「アソシエーション実行状態」を集約把握できます。

Complianceの二つのデータソース

Complianceダッシュボードでは、コンプライアンス種別（PATCH / ASSOCIATION / CUSTOM）・重要度・ステータスでフィルタリングし、非準拠ノードの特定・優先度付けができます。

カスタムコンプライアンス

PutComplianceItems APIを使用することで、独自のコンプライアンスチェック結果をComplianceダッシュボードに統合できます。サードパーティツール（CIS Benchmarkスキャン等）のチェック結果やカスタムスクリプトの実行結果をCustom:*型のコンプライアンスアイテムとして登録し、SSMの一元ビューで管理できます。

EventBridgeとの連携

コンプライアンス状態の変化（Compliant → Non-Compliant等）はEventBridgeイベント（SSM Compliance State Change）として発行されます。このイベントをトリガーに、SNS通知・Automation Runbookの自動起動・OpsItem自動起票を実装できます。

7-5. OpsCenter（OpsItemの集約運用）

OpsCenterは、AWS環境の運用課題（OpsItem）を一元管理するインシデント管理機能です。複数のAWSサービスからのアラートや運用課題をOpsItemとして集約し、担当者への割り当て・調査・解決を一つのUIで一元管理します。

OpsItemの自動起票（EventBridge/CloudWatch連携）

CloudWatchアラーム（閾値超過）
 ↓ EventBridgeルール（ターゲット: OpsCenter）
OpsItem自動起票（ステータス: Open）
 ↓ 担当者アサイン・関連リソース情報付与
調査ログ記録・関連Runbook実行
 ↓
解決・ステータス: Resolved

OpsItemには以下の情報が自動付与されます:

• トリガー情報: 発火元アラーム・EventBridgeイベントのARN
• 関連リソース: 影響を受けるEC2インスタンス・CloudFormationスタック等
• Operational Insights: AWS DevOps Guru・Security HubのInsightとの連携（有効化時）
• 推奨Runbook: 関連するAutomation RunbookへのリンクとワンクリックでのRunbook実行

手動OpsItem作成

自動起票だけでなく、コンソールやAPIから手動でOpsItemを作成できます。定期メンテナンス作業の記録・変更管理の起点としても活用できます。

aws ssm create-ops-item \
  --title "月次パッチ適用 - 本番Web層" \
  --description "本番Web層EC2グループへの月次パッチ適用タスク" \
  --priority 3 \
  --source "custom"

インシデントトリアージワークフロー

1. OpsItem一覧でステータス（Open / In Progress / Resolved）・重要度（Critical / High / Medium / Low）でフィルタリングし優先度付け
2. OpsItemを開き、関連リソースの詳細（CloudTrailログ・CloudWatchメトリクス）をコンテキストとして参照
3. 対応するAutomation Runbookをコンソールから直接実行（OpsCenter-Automation統合）
4. ステータスを「Resolved」に更新し解決コメント・根本原因を記録

7-6. ⚠️ SSM CloudWatch Dashboard の廃止（2026-04-30 EOL）

SSM CloudWatch Dashboardは、SSMコンソール内から直接CloudWatchダッシュボードを参照・作成できる統合機能でした。この機能は2026年4月30日をもって提供終了（EOL）となりました。

古いドキュメント・記事・社内手順書の一部には「SSM CloudWatch Dashboard」の操作手順が記載されている場合があります。現在このメニューはSSMコンソールから削除されています。

影響範囲: ダッシュボードの表示・作成UIのみ廃止。SSMが収集するメトリクスデータそのもの、Patch ComplianceのCloudWatch統合、OpsCenter連携には影響ありません。SSMのデータはCloudWatchコンソールから引き続きダッシュボードを作成してモニタリングできます。

8. まとめ・コスト最適化・運用ベストプラクティス

8-1. SSM運用基盤の全体像（本記事のまとめ）

本記事ではAWS Systems Managerを構成する主要機能を運用者視点で体系化しました。SSMは「個別ツールの寄せ集め」ではなく、有機的に連携する統合運用基盤です。

連携フィードバックループ: Patch Managerの結果 → Complianceへ集約 → コンプライアンス変化 → EventBridgeでOpsItem自動起票 → OpsItemからAutomation Runbookで自動修復—このループを確立することが、SSMを「設定しっぱなしのツール群」から「自己修復運用基盤」へ昇華させる鍵です。

8-2. コストの考え方

SSMは「全部無料」でも「全部有料」でもありません。EC2マネージドノードに対するコア機能は広く無料で提供されており、課金が発生するのは特定のAdvanced機能・高スループット設定・ハイブリッドノード（非EC2）のみです。

無料で使える主な機能（EC2マネージドノード中心）

課金が発生するポイント

注記: 料金は変更される可能性があります。本番環境への導入前にAWS Systems Manager 料金ページで最新の料金を必ず確認してください。

8-3. 運用ベストプラクティスまとめ

① タグ設計（パッチグループ・アプリ別）

タグ設計はSSM運用の根幹です。全機能がタグによるターゲティングを前提とするため、命名規約を最初に決定します。

# 推奨タグ構成例
Env:  prd / stg / dev
AppName: frontend / backend / batch
PatchGroup: prd-frontend / prd-backend / stg-all
Role: web / db / worker

PatchGroupタグのキーはスペース有り「Patch Group」・スペース無し「PatchGroup」の両方が有効ですが、IMDSでタグ公開している場合はスペース無しが必須です（§5 精度の罠⑧参照）。

② Runbook標準化とバージョン管理

カスタムRunbookはSSMドキュメントとして管理し、GitリポジトリでIaCと同様にバージョン管理します。

• AWS Organizationsの共有ドキュメント機能で、管理アカウントからメンバーアカウント全体へ展開
• 本番影響操作（インスタンス停止・AMI作成・設定変更）には必ずaws:approve承認ステップを挿入
• MaxConcurrency（例: 10%）とMaxErrors（例: 5%）で大規模フリートへの安全な段階実行

③ Inventoryデータ活用

Resource Data SyncでS3集約したInventoryデータをAthenaでクエリし、フリート全体の構成管理と監査対応を効率化します。

代表的な活用シナリオ:
– EOL（サポート終了）バージョンのソフトウェアが残存するノードの特定
– OSバージョン別・AZリージョン別のノード分布の可視化
– パッチ未適用ノードの週次自動レポーティング（EventBridgeスケジュール + Lambda連携）

④ IAM最小権限設計

⑤ VPCエンドポイントの活用

プライベートサブネットのノードにはNATゲートウェイ経由よりVPCエンドポイント経由を推奨します（コスト削減・データがインターネットに出ない・セキュリティ向上）。必要なエンドポイント: com.amazonaws.<region>.ssm + com.amazonaws.<region>.ssmmessages。東京リージョン（ap-northeast-1）はec2messagesも追加が安全です（§2 精度の罠①参照）。

8-4. 関連記事・クロスリンク

本記事で扱った機能は、より広いAWS運用基盤の一部として以下の記事と深く関連します。

• マルチアカウント環境の一元管理: AWS Organizations・Control Tower・SCPを活用したSSM横断管理。本記事のSSM機能をOrganizations規模で展開するための設計ガイド。
• インシデント対応Runbook自動化: 本記事のAutomation RunbookとOpsCenterを組み合わせた実践的なインシデント自動修復シナリオ。

8-5. 次巻予告

本シリーズVol2では、SSMのエンタープライズ向け高度機能を扱う予定です。

Vol2で予定するテーマ:
– Change Manager / Change Calendar: 変更管理フローの構造化・多段承認ワークフロー・変更フリーズ期間の設定
– Application Manager: アプリケーション単位でのSSMリソース統合管理・CloudFormationスタック連携
– 大規模マルチアカウント運用: Organizations Delegated Adminによる中央管理・アカウント横断Compliance集約

SSM本番運用シリーズ一覧を見る