SSM（AWS Systems Manager）

## なぜ SSM が必要なのか サーバーが数台の段階では SSH でログインして作業すれば十分だが、台数が増えると話は変わる。数十台に同じパッチを当てる、全台のインストール済みパッケージを把握する、障害時にログを一括取得する——こうした作業を手作業で回すのは現実的ではない。SSM はこれらの運用タスクを AWS コンソールや CLI から一括実行する仕組みを提供する。

## 主要機能 SSM は単一のサービスではなく、複数の機能群で構成されている。代表的なものを挙げる。**Run Command** は、管理対象ノードに対してシェルスクリプトや PowerShell コマンドをリモート実行する機能である。

SSH ポートを開放する必要がなく、IAM で実行権限を制御できるため、セキュリティ面でも運用面でも従来の SSH 接続より扱いやすい。追加料金は発生しない。**Parameter Store** は、データベースの接続文字列や API キーといった設定値を安全に保管・配布する機能である。

KMS による暗号化に対応しており、アプリケーションから `aws ssm get-parameter` で取得する形が定番になっている。**Patch Manager** は OS パッチの適用状況をスキャンし、ベースラインに基づいて自動適用する。メンテナンスウィンドウと組み合わせることで、業務時間外にパッチ適用を完了させる運用が可能になる。

**Session Manager** はブラウザベースのシェルアクセスを提供する。踏み台サーバーが不要になり、セッションの操作ログが CloudTrail と S3 に自動記録される点が監査要件の厳しい環境で重宝される。## SSM Agent の仕組み SSM の各機能は、管理対象ノードにインストールされた **SSM Agent** を介して動作する。

Amazon Linux 2 や Windows Server の AMI にはプリインストールされているため、EC2 であれば追加セットアップなしで利用を開始できる場合が多い。オンプレミスサーバーやエッジデバイスでは手動インストールが必要になるが、ハイブリッドアクティベーションという登録手順を踏めば EC2 と同じように管理対象に加えられる。筆者の経験では、SSM Agent のバージョン差異がトラブルの原因になることがあった。

Run Command が特定のノードだけ失敗する場合、まず Agent のバージョンを疑うのが定石である。## 料金体系 Run Command、Session Manager、Parameter Store（Standard パラメータ）は追加料金なしで利用できる。Parameter Store の Advanced パラメータや、OpsCenter の OpsItem 操作など、一部の上位機能では料金が発生する。

大規模環境でも基本的な運用管理コストが抑えられるのは SSM の強みの一つといえる。