目次
【Systems Managerの役割（耐障害性と高可用性）】
🔍 1. 結論
💎 一言でいうと AWS Systems Manager (SSM) は、AWS環境全体の運用（パッチ当て、スクリプト実行、障害対応）を一元管理し、「運用タスクの自動化（Automation）」 を通じて、システムが障害から素早く・人手を介さずに立ち直る弾力性を提供します。
- 障害検知時に SSM Automation (Runbook) を自動実行し、EC2の再起動や設定修正を行う。
- Session Manager を使えば、SSHポート(22)を開けずに安全にEC2にログインしてトラブルシューティングができる。
📈 2. SAAで出やすいポイント
- SSM Automation (Runbook): 一般的なIT運用タスク（AMIの作成、EBSスナップショットの取得、インスタンスの再起動など）が記述された手順書（Runbook）。EventBridgeやConfigと連携し、「違反を見つけたら自動でRunbookを走らせて修復する」構成が頻出。
- Patch Manager: 多数のEC2インスタンス（およびオンプレミスサーバー）に対して、OSやソフトウェアのパッチを自動的にスキャン・インストールする。セキュリティと弾力性の維持に直結する。
- Session Manager: SSH（ポート22）やRDP（ポート3389）のポートをセキュリティグループで開けることなく、ブラウザやAWS CLIから直接・安全にサーバー内にアクセスできる機能（踏み台サーバー不要）。
🗝 3. キーワードでの判断
| 問題文のキーワード | 疑う機能・サービス |
|---|---|
| 🔧 「障害時に自動で復旧スクリプトを実行したい」「運用タスクの自動化」 | Systems Manager Automation (Runbook) |
| 🛡️ 「踏み台(Bastion)サーバーやSSHポート開放なしでEC2にログインしたい」 | Systems Manager Session Manager |
| 💿 「複数のEC2やオンプレにOSパッチを一斉に適用したい」 | Systems Manager Patch Manager |
⚠️ 4. ひっかけポイント
🚫 よくある誤答パターン – 「踏み台（Bastion）ホストを立ててセキュリティを担保する」 → 昔は正解でしたが、現在のAWSベストプラクティスでは、踏み台サーバーの管理コストをなくすために SSM Session Manager を使うのが最も推奨されます。 – 「手動でスクリプトを実行して復旧させる」 → 弾力性の設計原則は「自動復旧」です。CloudWatch → EventBridge → SSM Automation の自動修復パイプラインが正解です。
💡 5. 覚え方
🧠 暗記ショートカット – Systems Manager = 「AWS上の優秀なシステム管理者（ロボット）」。 – パッチ当て（Patch Manager）、マニュアル通りの障害対応（Automation / Runbook）、安全な裏口案内（Session Manager）を全部やってくれる。
📚 6. 関連サービス
| アイコン | サービス名 | Systems Manager との連携 |
|---|---|---|
| 💻 | Amazon EC2 | SSMの管理対象となるメインのリソース（SSM Agentが必須） |
| ⚡ | Amazon EventBridge | アラートを受け取り、SSM Automation（修復作業）の引き金を引く |
| 🛡️ | AWS Config | 非準拠リソースを発見し、SSMを使って自動修復させる |
🗒️ 7. Obsidian管理メモ
- 見返すタイミング: 運用自動化、踏み台サーバーの代替策の学習時
- 関連ノート候補:
AWS_SAA_Session_Manager,AWS_SAA_Automated_Remediation
8. HTMLファイル名:
AWS_弾力性設計_SystemsManager.html
