セクション 06 · タスク 2.1 · SAP-C02-049

Systems ManagerによるConfiguration Management

AWS Systems Manager / State Manager / 自動化 / Parameter Store / 設定 / フリート管理

ゴール

多数のサーバーやAWSリソースを運用するときに、設定値、望ましい状態、運用ワークフロー、フリート管理を分離し、Systems Managerの各機能を要件から選択できるようにします。

設定値
        │
        ▼
  Parameter Store
        │
        ▼
希望する設定
        │
        ▼
    State Manager
        │
        ▼
    マネージドノード

運用上の手順 ─→ 自動化
フリート管理  ─→ Fleet Manager

1. 設定管理は「リソースを作る」だけではない

プロビジョニング後も、OSやアプリケーションがどの設定を維持すべきかという要件が残ります。

プロビジョニング
↓
設定
↓
運用

例えば、監視エージェントをインストール済みにする、サービスを稼働にする、共通エンドポイントを設定するといった状態をフリート全体で管理します。

2. Systems Managerとマネージドノード

AWS Systems Managerは、AWS、オンプレミス、他クラウドを含む環境のノードやAWSリソースを管理・自動化する複数機能を提供します。

ノード管理機能を使うマシンはマネージドノードとしてSystems Managerから管理できる状態にします。典型的には次が必要です。

SSM Agent
+
必要なIAM 権限
+
Systems Managerへのネットワーク接続性
↓
マネージドノード

マネージドノードはAmazon EC2だけに限定されず、ハイブリッド / マルチクラウドのマシンも対象にできます。一方、自動化にはAWS APIを呼び出してノード以外のAWSリソースを操作する手順もあるため、Systems Managerの全機能がSSM Agent前提という意味ではありません。

3. 状態マネージャー：望ましい状態を適用・維持する

状態マネージャーは、マネージドノードなどを指定した設定へ揃えるための機能です。

希望する設定
↓
関連付け
↓
対象
↓
マネージドノード

関連付けを繰り返し実行することで、設定の再適用や状態の維持に利用できます。状態マネージャーは常時リアルタイムで全設定を監視するドリフト検出ではなく、関連付けの実行によって希望する設定を適用します。

4. 関連付けは「何を・どこへ・いつ」を定義する

関連付けでは、主に次を設計します。

要素	役割
SSM ドキュメント	何を実行するか
対象	どこへ適用するか
実行タイミング	必要に応じてcron / rateなどのスケジュールを設定

スケジュールなしは定期スケジュールを設定しないことを意味します。ただし関連付けはスケジュール以外の操作や変更を契機に実行される場合があるため、「状態マネージャー全体で絶対に1回だけ」とは一般化しません。

5. 動的対象でフリートの増減へ追従する

インスタンス IDを固定列挙すると、Auto Scalingなどでノードが増えたときに適用漏れが起きやすくなります。状態マネージャー関連付けでは、タグやAWSリソースグループなどを対象として利用できます。

Auto Scalingでノード増減
↓
各ノードへ共通タグ
↓
State Manager 関連付け
対象 = tag:ロール=ウェブ
↓
条件一致ノードへ設定を適用

コマンド / ポリシードキュメントを使うタグ対象では、条件に一致して新たにマネージドノードとなった対象へ関連付けを適用できます。Automationランブックを使う関連付けでは新対象への自動追従条件が異なるため、同じ挙動を無条件には一般化しません。

6. 大規模フリートでは率制御を使う

多数ノードへ設定を適用する場合、同時変更による影響範囲を抑えるために率制御を設計します。

設定	役割
MaxConcurrency	同時に処理する対象数または割合を制限する
MaxErrors	許容する障害数または割合を定義する

MaxErrorsの許容値を超過
↓
現在の関連付け実行で
新しい対象への展開を停止

※すでに実行中の対象は完了し得る

例えばMaxErrors=3なら、3件までは許容し、4件目のエラーで停止指示が出る考え方です。数値そのものより、許容障害を超えたら影響範囲拡大を止めることを理解します。

7. 関連付けコンプライアンスで結果を確認する

状態マネージャー関連付けの実行結果は設定コンプライアンスで確認できます。

関連付け
↓
設定適用
↓
実行 結果
↓
準拠 / 非準拠

これは関連付けの実行結果に基づくコンプライアンスであり、ノード上のあらゆるファイルやパッケージを常時監視する万能な設定スキャナーではありません。

8. 自動化：運用ワークフローをランブック化する

Systems Manager 自動化は、複数手順の運用手順をランブックとして定義・実行します。

停止インスタンス
↓
作成 スナップショット
↓
適用変更
↓
開始 インスタンス
↓
検証

ランブックの手順出力を後続手順の入力に渡すことができ、AWS APIを呼び出す手順によってマネージドノード以外のAWSリソースも操作できます。

9. 状態マネージャーと自動化は責任が違うが組み合わせられる

機能	プライマリ責任
状態マネージャー	関連付けを通じて望ましい状態 / 設定適用を管理
自動化	ランブックによる複数ステップ運用ワークフローを実行

両者は排他的ではありません。状態マネージャー関連付けからAutomationランブックを実行する構成も可能です。

State Manager 関連付け
↓
Automationランブック
↓
複数段階運用

判断では「状態を管理する制御」と「手順を実行するエンジン」を分けます。

10. 自動化をマルチアカウント / マルチリージョンへ拡張する

自動化は中央アカウントから複数AWSアカウント・複数AWSリージョンへランブックを実行するアーキテクチャにも利用できます。

中央運用アカウント
        │
        ├─ アカウント A / リージョン 1
        ├─ アカウント A / リージョン 2
        └─ アカウント B / リージョン 1

大規模環境で同じ運用手順を標準化したい場合の候補です。

11. Parameter Store：設定値を中央管理する

Systems Manager Parameter Storeは設定データやシークレットをキー-値形式で保存します。

/prod/web/api-endpoint
/prod/web/approved-ami
/prod/app/ログレベル

階層で整理でき、パラメータにはバージョンがあります。アプリケーションコードへ環境固有値を厳格なコードする代わりに、中央保管先から取得できます。

12. Parameter Storeは設定を適用する機能ではない

Parameter Storeへ値を保存しただけでは、マネージドノード上の実設定が自動的に変わるとは限りません。

Parameter Store
設定値
      │
      ▼
State Manager / 自動化 / アプリケーション
      │
      ▼
実際の設定

ストレージと適用処理を分離します。

13. SecureStringとSecrets Managerの境界

Parameter StoreのSecureStringでは、パラメータ値をAWS KMSで暗号化できます。

SecureString 値
↓
AWS KMSで暗号化

パラメータ名前や説明などのメタデータまで暗号化されるわけではありません。

データベース認証情報などで自動ローテーションやシークレットライフサイクル管理が要件なら、AWS Secrets Managerを候補にします。

14. Fleet Manager：マネージドノードを可視化・管理する

Fleet Managerはマネージドノード群を中央コンソールから確認・管理するための機能です。

Fleet Manager
├─ 処理
├─ ログ
├─ ファイル
├─ OS ユーザー / グループ
└─ ノード管理

Fleet Managerは望ましい状態を継続適用する機能ではありません。その責任は状態マネージャーです。

15. 設定管理アーキテクチャを組み合わせる

各機能の責任を組み合わせると、次のように整理できます。

Parameter Store
設定値
        │
        ▼
State Manager
希望する状態
        │
        ▼
マネージドフリート
        │
   ┌────┴────┐
   ▼         ▼
自動化   Fleet Manager
ランブック      管理

要件	中心機能
設定値を中央管理	Parameter Store
希望する設定を適用・維持	状態マネージャー
複数手順の運用を自動化	自動化
マネージドノードを可視化・トラブルシューティング	Fleet Manager

16. シナリオ：Auto Scaling フリート

ウェブサーバーがAuto Scalingで増減し、全ノードへ同じエージェント設定を適用したいとします。

Auto Scalingノード
↓
共通タグ
↓
State Manager 関連付け
↓
タグ対象
↓
MaxConcurrency / MaxErrors
↓
設定適用

インスタンス IDを固定列挙するより、フリートの増減に追従しやすい設計です。

17. シナリオ：運用ランブック

複数アカウント / リージョンで同じメンテナンス手順を実施したい場合は、Automationランブックが中心になります。

中央運用
↓
Automationランブック
↓
アカウント / リージョンターゲット
↓
停止 → バックアップ → メンテナンス → 開始 → 検証

18. シナリオ：値と状態を分離する

アプリケーションエンドポイントを中央管理し、本番サーバー全体でその値に基づく設定を維持したい場合：

Parameter Store
エンドポイント値
↓
State Manager等
設定適用
↓
マネージド フリート

Parameter Store単体で設定の強制適用が完成するわけではありません。

19. 障害モード

誤った設計	問題
Systems Managerを単一のリモートコマンド機能と考える	状態 / ワークフロー / 値 / フリート管理の責任を分離できない
マネージドノードのエージェント・権限・接続性を考慮しない	ノード管理機能が成立しない
スケジュールなしを「絶対に1回だけ」と一般化する	関連付けの実行契機を誤解する
Auto Scalingグループ自体を状態マネージャーの対象として固定する	タグ対象などの正しい対象指定を見失う
MaxErrorsに到達した瞬間に必ず全実行が停止すると考える	しきい値超過と実行中対象の扱いを誤る
状態マネージャーと自動化を排他的に考える	関連付けからランブックを利用する構成を見落とす
Parameter Storeへ値を保存すれば設定も自動反映されると考える	ストレージと適用を混同する
SecureStringなら名前や説明も暗号化されると考える	メタデータの機密性を誤認する
認証情報ローテーションが必要でもParameter Storeだけで完結させる	シークレットライフサイクル要件を満たせない
Fleet Managerを望ましい状態の適用に利用する	管理と設定管理を混同する

20. SAP-C02判断フロー

設定 / 運用要件
        ↓
ノードを管理？
        ↓
マネージドノード前提を整える
        ↓
何を管理する？

値を保存
→ Parameter Store

希望する状態を適用・維持
→ State Manager

複数ステップ 手順を実行
→ 自動化

フリートを可視化・管理
→ Fleet Manager

大規模フリートでは、対象指定と率制御も合わせて設計します。

まとめ

AWS Systems Managerは複数の管理機能を持ち、ノードやAWSリソースの運用を支援する。
マネージドノードでは典型的にSSM Agent、必要な権限、Systems Managerへの接続性が必要。
状態マネージャーは関連付けを使って希望する設定を適用・維持する。
関連付けはドキュメント、対象、必要に応じた実行スケジュールを設計する。スケジュールなしは定期スケジュールなしを意味する。
タグ / AWSリソースグループなどで対象を定義でき、大規模フリートではMaxConcurrency / MaxErrorsを利用する。
自動化はランブックによる複数ステップ運用ワークフローを実行し、状態マネージャー関連付けと組み合わせることもできる。
自動化は複数アカウント / リージョンへ運用手順を展開できる。
Parameter Storeは設定値を中央管理するが、設定の強制適用そのものではない。
SecureStringは値をKMSで暗号化する。自動ローテーション等が必要ならSecrets Managerを検討する。
Fleet Managerはマネージドノードの可視化・管理を担当する。

理解確認

このページの内容を15問で確認します。

理解確認15問へ →

ゴール