AWS Certified CloudOps Engineer - Associate (SOA-C03) #8 Domain 3-2 デプロイ: Systems Manager 運用自動化
#7 で CloudFormation によってインフラをコードでデプロイしたなら、この記事は デプロイされたインスタンスを運用するツール である Systems Manager (SSM) を扱います。SSM は単一のサービスではなく運用機能の集まりであり、SOA-C03 で最も頻繁に登場する名前の一つです。中核機能を運用シナリオ別に見ていきます。
SSM の前提: エージェントと権限 #
SSM 機能のほとんどは 2 つを要求します。
- SSM Agent: 最新の Amazon Linux・Windows AMI には標準で含まれます。インスタンスが SSM と通信します
- インスタンスの IAM Role:
AmazonSSMManagedInstanceCoreポリシー。これがないとインスタンスが SSM に見えません
「インスタンスが Systems Manager コンソールの管理対象リストに表示されない」というシナリオの答えは、ほぼ常に IAM Role の欠落 またはエージェント・ネットワーク (エンドポイント) の問題です。
Parameter Store: 設定とシークレットの管理 #
アプリケーションの設定・接続文字列・シークレットを 中央で管理 するストアです。
| 種類 | 用途 |
|---|---|
| String / StringList | 一般的な設定値 |
| SecureString | KMS で暗号化されたシークレット (パスワード・トークン) |
- 階層型パス (
/app/prod/db/url) で環境別に整理 - バージョン管理で値の変更履歴を追跡
- #3 で見た CloudWatch Agent 設定ストア としても標準で使用
Parameter Store vs Secrets Manager #
試験定番の比較です。
| 項目 | Parameter Store | Secrets Manager |
|---|---|---|
| コスト | 標準は無料 | シークレットごとに有料 |
| 自動ローテーション (rotation) | なし (自前で実装) | 内蔵の自動ローテーション |
| RDS 連携 | 手動 | 認証情報の自動ローテーション統合 |
「DB パスワードを定期的に自動ローテーションせよ」という要求の答えは Secrets Manager です。単純な設定値なら、コストのかからない Parameter Store が適切です。
Session Manager: キーなしの接続 #
インスタンスに SSH キーやインバウンドポートなしで シェルで接続する機能です。
- 22 番ポートを開かなくても よい。ベスチオンホスト不要
- プライベートサブネットのインスタンスにも接続 (VPC エンドポイント経由)
- すべてのセッションを CloudTrail・S3・CloudWatch Logs に記録 して監査
セキュリティと運用の両面で強力な答えです。「プライベートインスタンスに SSH ポートを開かず安全に接続し、接続記録を残せ」はほぼ常に Session Manager です。
Patch Manager: パッチの一括適用 #
インスタンスの OS・アプリケーションのパッチを 自動で一括適用 します。
| 構成 | 役割 |
|---|---|
| Patch Baseline | どのパッチを承認・拒否するかのルール |
| Patch Group | タグでまとめたパッチ対象グループ |
| Maintenance Window | パッチを適用する時間枠 |
「数百台のインスタンスに毎月のセキュリティパッチを決められた時間に自動適用し、未適用のインスタンスを報告せよ」の答えが Patch Manager (+ Maintenance Window + コンプライアンス報告) です。
State Manager: 望ましい状態の維持 #
インスタンスが 常に定められた構成を維持 するよう周期的に適用します。
- エージェントのインストール状態、特定の設定ファイル、ドメイン参加などを 継続的に強制
- ドリフトが生じたら再度合わせます
CloudFormation のドリフト検出が「ずれを報告」するなら、State Manager は「ずれを再度合わせる」です。
Run Command と Automation #
| 機能 | 性格 | 例 |
|---|---|---|
| Run Command | 複数のインスタンスに 一回限りのコマンド を実行 | 全インスタンスにスクリプトを一度実行 |
| Automation | 多段階の 手順 (ランブック) を実行 | #4 の自動復旧 |
Run Command は SSH なしでコマンドを同時に配る道具です。「複数のインスタンスに同一のコマンドをキーなしで実行せよ」の答えが Run Command です。Automation は #4 で見た自動復旧ランブックのそれです。
試験での出題パターン #
- インスタンスが SSM の管理対象に見えない → IAM Role (
AmazonSSMManagedInstanceCore) を確認 - DB パスワードの自動ローテーション → Secrets Manager
- 単純な設定値の中央管理 (無料) → Parameter Store
- プライベートインスタンスにキー・ポートなしで接続 + 監査 → Session Manager
- 数百台のパッチ自動一括適用 + 報告 → Patch Manager + Maintenance Window
- 構成を継続的に強制 → State Manager
- 複数のインスタンスに一回限りのコマンド → Run Command
よくある落とし穴 #
1) SSM にインターネットが必要だと断定する #
プライベートサブネットのインスタンスはインターネットなしでも VPC インターフェイスエンドポイント で SSM に接続します。「プライベートなのに SSM ができない」の答えがエンドポイント構成である場合が多いです。
2) Parameter Store が自動ローテーションをすると考える #
自動ローテーションは Secrets Manager の機能です。Parameter Store は自前で更新する必要があります。
3) Session Manager に 22 番ポートが必要だと誤解する #
Session Manager はインバウンドポートを開きません。セキュリティグループで SSH を塞いでも接続できます。
4) パッチを Run Command で一つずつ回す #
一回限りなら Run Command ですが、定期・コンプライアンス報告 が必要なら Patch Manager が適切です。
まとめ #
この記事で押さえたこと:
- SSM は エージェント + IAM Role (
AmazonSSMManagedInstanceCore) が前提。管理リスト欠落の第一原因 - Parameter Store (無料の設定・SecureString) vs Secrets Manager (有料・自動ローテーション)。シークレットの自動ローテーションは Secrets Manager
- Session Manager でキー・ポートなしの接続 + 全セッションの監査記録。ベスチオン不要
- Patch Manager でベースライン・グループ・メンテナンスウィンドウに基づくパッチ自動化とコンプライアンス報告
- State Manager で望ましい構成を継続的に強制、Run Command で一回限りのコマンド、Automation で多段階のランブック
次: Domain 3-3 コンテナ運用 #
インスタンス運用を押さえたので、次は SOA-C03 で新たに入った コンテナ運用 です。
#9 Domain 3-3 デプロイ: コンテナ運用 (ECS・EKS・ECR) では、ECS と EKS の違い、Fargate と EC2 の起動タイプ、ECR でイメージを管理する方法、コンテナのロギングとモニタリング、そしてデプロイ・スケーリング運用まで SOA-C03 の新しい範囲を整理します。