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 の強みの一つといえる。