導入
サーバー台数が数十〜数百台になると、「1台1台にSSHでログインしてパッチを当てる」「設定値をコードに直書きする」といった運用は破綻します。AWS Systems Manager（SSM）は、この手作業の運用をまとめて自動化・標準化するための総合ツールです。
説明
Systems Managerには複数の機能がありますが、SAPで頻出するのは次の4つです。
| 機能 | やること |
|---|---|
| Run Command | 多数のインスタンスに対し、SSH不要でコマンドを一斉実行 |
| Automation | 複数ステップの運用手順（パッチ適用・AMI作成など）をドキュメント化し自動実行 |
| Patch Manager | OS・ミドルウェアのパッチ適用をスケジュール管理 |
| Parameter Store | 設定値・シークレットを一元管理し、コードから参照 |
flowchart TD
SSM["Systems Manager"] --> RC["Run Command<br/>一斉コマンド実行"]
SSM --> AU["Automation<br/>手順のドキュメント化"]
SSM --> PM["Patch Manager<br/>パッチ適用の自動化"]
SSM --> PS["Parameter Store<br/>設定値/シークレット一元管理"]
RC -.SSHもキーペアも不要.-> EC2["管理対象インスタンス群"]
- Run Command / Automation: どちらもSSH不要でIAM権限だけで実行できるため、踏み台サーバーや開いたポートを減らせる（セキュリティ改善にも直結）。Automationは「AMI作成→テスト→タグ付け」のような複数ステップを1つのドキュメントにまとめ、定期実行やイベント駆動で回せる。
- Patch Manager: メンテナンスウィンドウを定義し、対象インスタンス群に段階的（カナリア方式）にパッチを適用できる。手動でのパッチ管理の属人化を解消する。
- Parameter Store: 環境ごとのDB接続文字列やAPIキーを、コードや環境変数に直書きせず一元管理する。KMSと組み合わせて暗号化も可能（より高度なシークレット管理はSecrets Managerが自動ローテーションに対応）。
具体例
200台のEC2を運用する会社で、セキュリティ監査から「全サーバーに緊急パッチを今週中に」と指示が出ました。
手作業の場合：1台ずつSSHでログインしてパッチ適用。200回。SSHのために踏み台サーバーやポートを開けておく必要もあり、それ自体がセキュリティリスク。丸2日仕事で、当て忘れも起きる。
Systems Managerの場合：
- Patch Managerでメンテナンスウィンドウを定義し、200台へ段階的（カナリア方式）に自動適用。まず数台に当てて問題なければ全台へ。
- そもそもRun CommandはSSH不要でIAM権限だけで動くので、踏み台も開いたポートも不要に（セキュリティも改善）。
- 「AMI作成→テスト→タグ付け」のような定型作業はAutomationで1つのドキュメントにまとめ、定期実行。
- DB接続文字列やAPIキーはParameter Storeで一元管理し、コードから直書きを排除。
「多数のEC2にSSHせずパッチ/コマンド＝Run Command/Patch Manager、手順の自動化＝Automation、設定値の外出し＝Parameter Store」。「運用のオーバーヘッド削減」はSSM全般の合図です。
読んでみよう
「多数のEC2にSSHせずコマンドやパッチを適用したい」はRun Command / Patch Manager、「複数ステップの運用作業を自動化・標準化したい」はAutomation、「設定値をコードから外出しして一元管理したい」はParameter Storeが対応します。「運用のオーバーヘッドを削減したい」という要件文がSystems Manager全般を示す合図になります。