AWS Systems Manager

AWS Systems Manager は、EC2 インスタンスやオンプレミスのサーバー、さらには他クラウド上の仮想マシンまでを対象に、パッチ適用・リモートコマンド実行・設定値の管理・インベントリ収集などの運用作業を一元化するマネージドな運用管理ツール群です。単一のサービスというより、複数の運用機能（ケイパビリティ）の集合体として提供されます。

解決する課題

サーバーが数台のうちは手作業の SSH やリモートデスクトップでも回りますが、台数が増えると運用が破綻します。Systems Manager はこうした課題を解決します。

• 多数のサーバーへ同じコマンドを一括実行したい（個別ログインは現実的でない）
• OS やミドルウェアのパッチを定期的に当ててコンプライアンスを保ちたい
• 踏み台サーバーや SSH 鍵を管理せずに安全に接続したい
• アプリの設定値や機密情報をコードから分離して一元管理したい
• 全サーバーの構成情報を**棚卸し（インベントリ）**して把握したい

主要概念と用語

• マネージドノード: Systems Manager が管理対象とするサーバー。EC2・オンプレミス・他クラウドの VM を含む
• SSM Agent: 各ノードに導入する常駐エージェント。Systems Manager との通信窓口になる
• ドキュメント（SSM Document）: 実行する処理を定義した JSON または YAML の定義ファイル。コマンド系・自動化系などの種類がある
• Session Manager: ブラウザや CLI からシェルセッションを開く接続機能。SSH 鍵や踏み台が不要
• Run Command: 多数のノードに対してドキュメントを一括実行する機能
• Patch Manager: パッチベースラインに沿って OS パッチを適用・評価する機能
• State Manager: ノードを定義した望ましい状態（コンフィグ）に保ち続ける機能
• Automation: 運用手順を自動化するワークフロー機能（AMI 作成や復旧手順など）
• Parameter Store: 設定値や機密情報を階層的なキーで保管するストア
• Maintenance Windows: メンテナンス作業を実行する時間枠のスケジュール定義

仕様・制限・クォータ

• マネージドノードには SSM Agent が必要。新しめの Amazon Linux や Windows Server の AMI にはプリインストールされていることが多い
• エージェントは Systems Manager 側へアウトバウンド接続して通信するため、インバウンドのポート開放は不要。プライベートサブネットからは VPC エンドポイント経由で到達できる
• ノードを管理対象にするには、対象に適切な IAM ロール（インスタンスプロファイル） をアタッチする必要がある
• Parameter Store には標準パラメータと、より大きなサイズや高スループットに対応する上位種別があり、保管できる値のサイズや 1 アカウントあたりの上限はパラメータの種別ごとに異なる
• 各機能には同時実行数や API リクエストレートのクォータが設定されており、必要に応じて引き上げ申請ができる場合がある

内部の仕組み

中核となるのが各ノード上で動く SSM Agent です。エージェントは Systems Manager のエンドポイントへ定期的にポーリングし、実行すべきコマンドやセッション要求を受け取って処理し、結果を返します。接続はノード側からのアウトバウンド主体であるため、サーバー側で受信ポートを開ける必要がありません。

• 実行内容は ドキュメントとして定義され、Run Command や Automation はこのドキュメントを解釈してノード上で処理を進める
• Session Manager のセッションはエージェント経由のストリームとして確立され、SSH のように直接ポートへ接続するわけではない
• プライベートサブネット内のノードからインターネットを経由せず到達させたい場合は、Systems Manager 用の VPC インターフェイスエンドポイントを構成する

設計パターン / ベストプラクティス

• 鍵・踏み台の廃止: SSH やリモートデスクトップの代わりに Session Manager を標準の接続手段にし、セキュリティグループのインバウンドを最小化する
• パッチの定期適用: Patch Manager のパッチベースラインと Maintenance Windows を組み合わせ、メンテナンス時間枠の中で自動適用する
• 設定とコードの分離: 接続文字列や機能フラグを Parameter Store に逃がし、デプロイ済みのアプリは起動時に取得する
• 構成のドリフト防止: State Manager で望ましい状態を宣言し、エージェントや必須ソフトの導入状態を継続的に保つ
• 手順の自動化: 復旧やゴールデン AMI 作成などの定型手順を Automation ドキュメント化し、人手のばらつきをなくす

運用・監視

• コンプライアンスダッシュボードでパッチ適用状況や State Manager の準拠状況を俯瞰できる
• CloudWatch と連携してコマンド実行結果やセッションのメトリクスを監視し、必要に応じてアラームを設定する
• CloudTrail で誰がいつどのセッションを開き、どのコマンドを実行したかを記録する
• Run Command や Session Manager の出力は S3 バケットや CloudWatch Logs に送って長期保管・監査できる
• インベントリ機能で各ノードにインストールされたソフトや構成を収集し、棚卸し情報として活用する

コスト

Systems Manager の基本的な機能の多くは追加料金なしで利用できますが、上位機能や大量利用では課金が発生します。

• Session Manager・Run Command・State Manager・Parameter Store の標準パラメータといった中核機能は、多くの場合追加料金なしで利用できる
• 高度なパラメータや、高スループットなパラメータ取得、一部の上位ケイパビリティは利用量に応じた課金対象になる
• 連携先の CloudWatch Logs・S3・KMS など他サービス側でのログ保管や暗号化に応じた費用は別途発生する

セキュリティ

• 操作権限は IAM ポリシーで細かく制御し、誰がどのノードへ接続・どのドキュメントを実行できるかを最小権限で定義する
• Parameter Store の機密値は KMS で暗号化して保管し、復号権限を限定する
• ノードへの接続にインバウンドポートや SSH 鍵が不要なため、攻撃面を縮小できる
• セッションやコマンドの操作は CloudTrail に記録され、出力先のログと合わせて追跡できる

Well-Architected の観点

• 運用上の優秀性: パッチ・コマンド・自動化を一元化し、手作業を減らして運用を標準化・自動化できる
• セキュリティ: 鍵レス接続による攻撃面の縮小、IAM と KMS による最小権限と暗号化、CloudTrail による監査性
• 信頼性: Automation による復旧手順の標準化と、State Manager による構成ドリフトの抑止
• コスト最適化: 中核機能を追加料金なしで活用しつつ、ログ保管や上位種別の利用量を抑える

試験で問われるポイント

関連サービス・比較

機密情報の保管では AWS Secrets Manager とよく比較されます。Parameter Store は汎用の設定値管理に強く、Secrets Manager は機密情報のローテーションに特化しています。

ハンズオン / CLI例

# パラメータを暗号化して保存（KMS で暗号化される種別）
aws ssm put-parameter \
  --name "/myapp/prod/db-password" \
  --value "S3cr3t!" \
  --type SecureString \
  --description "本番DBパスワード"

# マネージドノードへ一括でコマンドを実行（Run Command）
aws ssm send-command \
  --document-name "AWS-RunShellScript" \
  --targets "Key=tag:Env,Values=prod" \
  --parameters 'commands=["uname -a","df -h"]'

# Session Manager で対象インスタンスへ接続（鍵・踏み台なし）
aws ssm start-session --target i-0123456789abcdef0