🍣
AWS学びなおし(+TF)_Systems Manager

2025/02/28に公開
AWS Systems Manager (SSM) は、AWS 環境全体 (EC2 インスタンス、オンプレミスサーバー、仮想マシンなど) の運用管理を簡素化するサービス群です。まるでシステム管理者向けの多機能ツールボックスのようなもので、様々な運用タスクを自動化・集中管理し、セキュリティと効率性を向上させることができます。
SSM は、以下の主要な機能 (サービス) から構成されています。
1. Run Command:

概要: リモートで EC2 インスタンスやオンプレミスサーバーに対してコマンドを実行できる機能です。スクリプト実行、ソフトウェアインストール、設定変更など、様々な操作を安全かつ大規模に実行できます。

分かりやすい例:
多数の EC2 インスタンスにセキュリティパッチを一括適用する。
全サーバーのログファイルを特定の S3 バケットに収集する。
アプリケーションサーバーの再起動を一括で行う。


ポイント:
エージェントベース: SSM エージェントが対象インスタンスにインストールされている必要があります。
セキュリティ: IAM ロールによる認証・認可、実行ログ記録、コマンド実行履歴管理など、セキュリティ機能が充実しています。
スケーラビリティ: 大規模なインスタンス群に対して並列実行が可能。
柔軟性: シェルスクリプト、PowerShell スクリプト、AWS CLI コマンドなど、様々なコマンドを実行可能。

2. Session Manager:

概要: ブラウザまたは AWS CLI を介して、安全かつインタラクティブなシェルアクセス (SSH や RDP の代替) を提供する機能です。踏み台サーバー (Bastion Host) や SSH キーの管理が不要になり、セキュリティリスクを低減できます。

分かりやすい例:
EC2 インスタンスに直接ログインして、ファイル操作やログ確認を行う。
オンプレミスサーバーにセキュアにアクセスして、トラブルシューティングを行う。


ポイント:
ポート転送: ローカルポートをインスタンスに転送し、GUI アプリケーションへのアクセスも可能。
監査ログ: セッションの開始・終了、実行コマンドなどを CloudTrail で記録。
セキュリティ: IAM ロールによるアクセス制御、セッションログ記録、暗号化通信など、セキュリティが強化されています。
利便性: ブラウザからワンクリックでセッションを開始でき、SSH クライアントや RDP クライアントの準備が不要。

3. Patch Manager:

概要: OS およびアプリケーションのパッチ適用プロセスを自動化する機能です。セキュリティ脆弱性対策、コンプライアンス維持、システム安定性向上に貢献します。

分かりやすい例:
定期的に EC2 インスタンスの OS セキュリティパッチを自動適用する。
特定のアプリケーション (例: Apache, Nginx) の脆弱性パッチを自動適用する。
パッチ適用のスケジュール、承認ワークフロー、レポート作成などを自動化する。


ポイント:
パッチベースライン: 承認済み/拒否済みパッチリストを定義し、パッチ適用ポリシーを柔軟に設定可能。
スケジュール実行: メンテナンスウィンドウと連携して、パッチ適用をスケジュール実行可能。
コンプライアンスレポート: パッチコンプライアンス状況をレポートで確認可能。
統合: AWS Security Hub や AWS Config と連携し、セキュリティとコンプライアンスを強化。

4. State Manager:

概要: インスタンスの設定状態を定義し、それを維持するための機能です。Desired State Configuration (DSC) の AWS 版のようなもので、構成ドリフトを解消し、システムの一貫性を保ちます。

分かりやすい例:
全てのウェブサーバーに同じバージョンの Apache をインストールし、設定ファイルを統一する。
セキュリティ設定 (例: ファイアウォールルール、SELinux 設定) を全サーバーで一貫して適用する。
定期的に設定状態をチェックし、逸脱があれば自動的に修正する。


ポイント:
ドキュメントベース: 設定は SSM ドキュメント (YAML または JSON) で定義。
関連付け (Association): ドキュメントをターゲットインスタンスに関連付け、設定を適用。
継続的なコンプライアンス: 定期的なコンプライアンスチェックと自動修復により、設定ドリフトを防止。
柔軟性: シェルスクリプト、PowerShell スクリプト、AWS Config ルールなど、様々な設定管理手法を統合可能。

5. Parameter Store:

概要: 設定データ (パスワード、API キー、データベース接続文字列、ライセンスキーなど) を安全に一元管理する機能です。機密情報をコードや設定ファイルにハードコードするリスクを排除し、セキュリティを向上させます。

分かりやすい例:
アプリケーション設定ファイルからデータベースパスワードを Parameter Store から取得するように変更する。
環境変数として API キーを Parameter Store から取得するようにアプリケーションを構成する。
開発環境、ステージング環境、本番環境で異なる設定値を Parameter Store で管理する。


ポイント:
階層構造: パラメータを階層的に整理し、管理を容易化。
バージョン管理: パラメータの変更履歴を管理し、ロールバック可能。
暗号化: KMS でパラメータ値を暗号化し、安全に保管。
アクセス制御: IAM ポリシーでパラメータへのアクセス権限を細かく制御。
統合: EC2 インスタンスメタデータ、Lambda 環境変数、ECS タスク定義など、様々な AWS サービスからパラメータを参照可能。

6. Inventory:

概要: EC2 インスタンスおよびオンプレミスサーバーのソフトウェア、ハードウェア、ネットワーク設定などの情報を自動的に収集し、一元的に管理する機能です。資産管理、コンプライアンス監査、脆弱性分析などに役立ちます。

分かりやすい例:
全ての EC2 インスタンスにインストールされているソフトウェアの一覧を把握する。
特定のバージョンのソフトウェアがインストールされているサーバーを特定する。
OS パッチレベル、カーネルバージョン、ネットワークインターフェース設定などを一覧表示する。


ポイント:
カスタムインベントリ: ユーザーが定義したカスタム情報を収集することも可能。
クエリ機能: 収集したインベントリ情報を SQL ライクなクエリで検索・分析可能。
統合: AWS Config と連携し、インベントリ情報の変更履歴を追跡可能。
可視化: ダッシュボードでインベントリ情報を可視化し、状況把握を容易化。

7. Automation:

概要: 複雑な運用タスクやワークフローを自動化する機能です。インフラストラクチャのプロビジョニング、アプリケーションデプロイ、インシデント対応、定期メンテナンスなど、様々な自動化シナリオを実現できます。

分かりやすい例:
EC2 インスタンスの起動からソフトウェアインストール、設定までの一連のプロセスを自動化する。
定期的にデータベースのバックアップを取得し、S3 に保存するワークフローを自動化する。
インシデント発生時に、自動的に診断スクリプトを実行し、通知を送信するワークフローを構築する。


ポイント:
ワークフロー定義: SSM ドキュメント (YAML または JSON) でワークフローを定義。
ステップ実行: ワークフローは複数のステップ (AWS API コール、スクリプト実行、承認ステップなど) で構成。
エラーハンドリング: エラー発生時の処理 (ロールバック、リトライ、通知など) を定義可能。
柔軟性: 様々な AWS サービスと連携し、複雑な自動化シナリオを実現可能。

8. Maintenance Windows:

概要: パッチ適用、ソフトウェアインストール、再起動などのメンテナンス作業を、事前に定義したスケジュールと期間内で実行するための機能です。システムへの影響を最小限に抑え、計画的なメンテナンスを実現します。

分かりやすい例:
毎週日曜日の午前 2 時から 4 時までの間に、EC2 インスタンスの OS パッチを適用するメンテナンスウィンドウを設定する。
月に一度、アプリケーションサーバーの再起動を行うメンテナンスウィンドウを設定する。


ポイント:
スケジュール設定: メンテナンスウィンドウの開始時間、期間、繰り返し頻度を柔軟に設定可能。
タスク登録: メンテナンスウィンドウ内で実行するタスク (Run Command、Automation ドキュメントなど) を登録。
ターゲット制御: メンテナンスウィンドウを適用するターゲットインスタンスを柔軟に指定可能。
可視化: メンテナンスウィンドウの実行状況をダッシュボードで確認可能。

9. Incident Manager (旧 Incident Response):

概要: インシデント発生時の対応プロセスを効率化・自動化する機能です。インシデントの検出、通知、エスカレーション、対応手順の実行、事後分析などを支援します。

分かりやすい例:
CloudWatch アラームが発報された際に、自動的にインシデントを作成し、担当者に通知する。
インシデント発生時に、自動的に診断 Run Command を実行し、情報を収集する。
インシデント対応手順を定義した Automation ドキュメントを実行する。


ポイント:
インシデントプラン: インシデントの種類ごとに対応プランを定義。
自動化された対応: インシデント検出から対応までの一連の流れを自動化可能。
コラボレーション: 関係者間のコミュニケーションと情報共有を促進。
事後分析: インシデント発生状況、対応履歴などを記録し、事後分析を支援。

10. Change Manager:

概要: インフラストラクチャおよびアプリケーションへの変更プロセスを制御・承認するための機能です。変更管理ワークフローを定義し、承認プロセスを自動化することで、変更によるリスクを低減し、ガバナンスを強化します。

分かりやすい例:
EC2 インスタンスの設定変更を行う際に、承認ワークフローを必須とする。
データベーススキーマの変更をデプロイする前に、DB 管理者の承認を得るようにする。
変更リクエストの作成、承認、実行、追跡を Change Manager で一元管理する。


ポイント:
変更リクエスト: 変更内容、理由、影響範囲などを定義した変更リクエストを作成。
承認ワークフロー: 変更リクエストに対する承認プロセスを定義。
自動実行: 承認された変更リクエストに基づいて、Automation ドキュメントなどを自動実行可能。
監査ログ: 変更リクエスト、承認履歴、実行ログなどを記録し、監査証跡を確保。

SSM エージェント:
これらの SSM の機能を活用するためには、管理対象の EC2 インスタンスやオンプレミスサーバーに SSM エージェント がインストールされ、起動している必要があります。SSM エージェントは、インスタンスと SSM サービス間の通信を担い、コマンド実行、セッション確立、インベントリ収集などの処理を行います。

 【実務レベルの内容と重要事項】実務レベルで SSM を活用する上で重要な事項は多岐に渡りますが、特に以下の点が重要です。
1. セキュリティ:

IAM ロールの適切な設定: SSM エージェントが動作するインスタンスには、必要最小限の権限を持つ IAM ロールを付与します。AmazonSSMManagedInstanceCore ポリシーは必須ですが、必要に応じて権限を絞り込むカスタムポリシーを作成することを推奨します。

Session Manager のセキュリティ強化: Session Manager のログ記録を有効化し、CloudTrail で監査ログを監視します。ポート転送機能は、必要最小限に制限することを検討します。

Parameter Store のアクセス制御: Parameter Store に保存する機密情報へのアクセス権限は、IAM ポリシーで厳密に制御します。最小権限の原則を徹底し、必要なユーザーまたはサービスのみにアクセスを許可します。KMS 暗号化を必ず有効化します。

Run Command の実行ログ監視: Run Command の実行ログを CloudWatch Logs に出力し、実行履歴やエラーを監視します。不審なコマンド実行を早期に検知できるようにアラート設定も検討します。

パッチ管理の承認ワークフロー: パッチ適用プロセスに承認ワークフローを組み込むことで、意図しないパッチ適用によるシステムへの影響を抑制できます。
2. 運用効率:

SSM ドキュメントの再利用性: SSM ドキュメントはモジュール化し、共通処理を部品化することで、再利用性と保守性を高めます。Parameter Store や変数などを活用して、ドキュメントを汎用的に設計することも重要です。

ターゲットの効率的な指定: Run Command や State Manager などのターゲット指定には、インスタンス ID、タグ、リソースグループなど、様々な方法があります。運用状況に合わせて最適なターゲット指定方法を選択し、効率的な管理を実現します。

自動化の推進: 定型的な運用タスクは Automation ドキュメントで積極的に自動化し、人的ミスを削減し、運用効率を向上させます。

メンテナンスウィンドウの活用: 定期的なメンテナンス作業はメンテナンスウィンドウでスケジュール実行することで、システムへの影響を最小限に抑え、計画的な運用を実現します。

ハイブリッド環境の管理: SSM はオンプレミスサーバーも管理対象に含めることができます。ハイブリッド環境全体を SSM で一元管理することで、運用管理の複雑さを軽減できます。
3. 可用性と信頼性:

メンテナンスウィンドウの期間設定: メンテナンスウィンドウの期間は、メンテナンス作業に必要な時間だけでなく、予期せぬ事態に備えて余裕を持たせた設定にすることを推奨します。

パッチ適用の段階的な実施: パッチ適用は、本番環境に直接適用するのではなく、事前に検証環境で十分なテストを行い、問題がないことを確認してから段階的に適用することを推奨します。

ロールバック戦略の検討: パッチ適用や設定変更など、システムに影響を与える可能性のある作業については、事前にロールバック手順を確立しておくことが重要です。Automation ドキュメントでロールバック処理を自動化することも有効です。

監視とアラート: SSM の各種機能の実行状況やエラーを CloudWatch メトリクスや CloudWatch Events で監視し、異常発生時には速やかにアラート通知を受け取れるように設定します。
4. パフォーマンス:

Run Command の並列実行制御: 大規模なインスタンス群に対して Run Command を実行する場合、並列実行数を適切に制御することで、対象インスタンスや SSM サービスの負荷を軽減できます。MaxConcurrency パラメータなどを調整します。

Session Manager のパフォーマンス: Session Manager はインタラクティブな操作を行うため、ネットワーク環境やインスタンスのリソース状況によっては、レスポンスが遅延する場合があります。必要に応じてインスタンスタイプを見直すことも検討します。

Inventory の収集頻度: Inventory の収集頻度を高く設定すると、インスタンスのリソース消費が増加する可能性があります。収集する情報や頻度を適切に調整し、システムへの影響を最小限に抑えるようにします。
5. その他:

SSM エージェントの最新バージョン維持: SSM エージェントは定期的にアップデートされ、機能改善やセキュリティ修正が行われます。常に最新バージョンを維持することが重要です。

タグの活用: EC2 インスタンスやオンプレミスサーバーに適切なタグを付与し、SSM のターゲット指定や管理作業を効率化します。

AWS Organizations との連携: AWS Organizations 環境では、SSM を組織全体で一元管理することができます。クロスアカウントでの Run Command 実行や State Manager 関連付けなどを活用できます。

コスト最適化: SSM の利用料金は、主に Run Command の実行回数や Parameter Store のパラメータ数、Inventory の収集頻度などによって変動します。利用状況をモニタリングし、不要な機能を抑制するなど、コスト最適化を検討します。

 【実務でどの程度使用されるのか】SSM は、AWS 環境を運用する上で非常に頻繁に使用されるサービス群です。特に大規模な環境や、セキュリティ・コンプライアンス要件が厳しい環境では、SSM はほぼ必須のツールと言えるでしょう。
実務での SSM 利用例:

日常的なサーバー管理:
サーバーの起動・停止、再起動
ログファイルの確認、収集
プロセス監視、リソース監視
ソフトウェアのインストール、アンインストール
設定ファイルの編集、変更
ユーザーアカウント管理


セキュリティ運用:
セキュリティパッチの適用 (Patch Manager)
セキュリティ設定の適用、維持 (State Manager)
脆弱性診断ツールの実行 (Run Command)
セキュリティインシデント対応 (Incident Manager)
セキュリティ監査 (Inventory, Compliance)


アプリケーション運用:
アプリケーションのデプロイ、アップデート (Run Command, Automation)
アプリケーション設定の管理 (Parameter Store)
アプリケーションログの収集、分析 (Run Command)
アプリケーション監視 (Run Command, Inventory)
アプリケーションのヘルスチェック (Run Command)


インフラストラクチャ自動化:
EC2 インスタンスのプロビジョニング (Automation)
ネットワーク設定の自動化 (Automation, State Manager)
バックアップ、リストア処理の自動化 (Automation)
定期メンテナンス作業の自動化 (Maintenance Windows, Automation)
インシデント対応の自動化 (Incident Manager, Automation)


DevOps パイプラインへの組み込み:
CI/CD パイプラインでのアプリケーションデプロイ (Run Command, Automation)
インフラストラクチャ構築・変更の自動化 (Automation, State Manager)
環境構築後の設定自動化 (State Manager, Run Command)
テスト環境の自動プロビジョニング (Automation)


コンプライアンス対応:
パッチコンプライアンスの維持、レポート作成 (Patch Manager)
設定コンプライアンスの維持、レポート作成 (State Manager)
インベントリ情報の収集、監査証跡の確保 (Inventory)
アクセスログの記録、監査 (Session Manager, Run Command)


ハイブリッドクラウド環境の管理:
オンプレミスサーバーのパッチ管理 (Patch Manager)
オンプレミスサーバーの設定管理 (State Manager)
オンプレミスサーバーへのリモートコマンド実行 (Run Command)
オンプレミスサーバーへのセキュアアクセス (Session Manager)
オンプレミスサーバーのインベントリ収集 (Inventory)

SSM のスキルは市場価値が高い:
クラウドエンジニア、インフラエンジニア、DevOps エンジニア、セキュリティエンジニアなど、AWS 環境に関わる職種においては、SSM の知識・スキルは非常に重要であり、市場価値も高いです。SSM を効果的に活用することで、AWS 環境の運用効率、セキュリティ、可用性を大幅に向上させることができ、企業のビジネスに貢献できる人材として高く評価されます。

 【terraformのコードで記述する場合の基本的内容と実務レベルの内容】Terraform で SSM リソースを記述する場合、主に以下のリソースタイプを使用します。
Terraform での SSM 記述の基本:

aws_ssm_document: SSM ドキュメント (Run Command, Automation, State Manager などで使用) を作成します。
resource "aws_ssm_document" "example_document" {
  name            = "example-document"
  document_type   = "Command"
  content         = <<DOC
{
  "schemaVersion": "2.2",
  "description": "Example Run Command Document",
  "mainSteps": [
    {
      "action": "aws:runShellScript",
      "name": "runShellScript",
      "inputs": {
        "commands": [
          "echo Hello, World!"
        ]
      }
    }
  ]
}
DOC
}

aws_ssm_association: State Manager の関連付けを作成します。
resource "aws_ssm_association" "example_association" {
  name             = aws_ssm_document.example_document.name
  instance_id      = "i-xxxxxxxxxxxxxxxxx" # 特定のインスタンスID
  association_name = "example-association"
}

aws_ssm_parameter: Parameter Store のパラメータを作成します。
resource "aws_ssm_parameter" "example_parameter" {
  name  = "/example/parameter"
  type  = "String"
  value = "example-value"
}
Terraform での SSM 記述の実務レベルの内容:
実務レベルで Terraform を用いて SSM を管理する場合、以下の点を考慮する必要があります。
変数 (Variables) の活用:
環境 (開発環境、本番環境など) や設定値 (パラメータ値、インスタンス ID など) を Terraform 変数として定義し、コードの再利用性と柔軟性を高めます。
variable "environment" {
  type    = string
  default = "dev"
}

resource "aws_ssm_parameter" "example_parameter" {
  name  = "/${var.environment}/example/parameter"
  type  = "String"
  value = "example-value-${var.environment}"
}
モジュール (Modules) の活用:
SSM ドキュメント、関連付け、パラメータなどを機能や役割ごとにモジュール化し、コードの構造化と再利用性を高めます。例えば、パッチ管理モジュール、セキュリティ設定モジュールなどを作成します。
データソース (Data Sources) の活用:
既存の AWS リソースの情報 (例: AMI ID, VPC ID, サブネット ID, セキュリティグループ ID) をデータソースから取得し、コード内で動的に利用します。
動的な SSM ドキュメント生成:

templatefile 関数や jsonencode 関数などを活用して、Terraform の変数やデータソースに基づいて動的に SSM ドキュメントを生成します。これにより、環境や設定に応じて柔軟なドキュメントを作成できます。
data "aws_ami" "amazon_linux_2" {
  most_recent = true
  owners      = ["amazon"]
  filter {
    name   = "name"
    values = ["amzn2-ami-hvm-*-x86_64-gp2"]
  }
}

resource "aws_ssm_document" "install_nginx" {
  name            = "install-nginx"
  document_type   = "Command"
  content = templatefile("documents/install_nginx.yaml", {
    ami_id = data.aws_ami.amazon_linux_2.id
  })
}
documents/install_nginx.yaml テンプレートファイルの例:
{
  "schemaVersion": "2.2",
  "description": "Install Nginx on Amazon Linux 2",
  "parameters": {
    "amiId": {
      "type": "String",
      "description": "(Required) AMI ID for Amazon Linux 2",
      "default": "${amiId}"
    }
  },
  "mainSteps": [
    {
      "action": "aws:runShellScript",
      "name": "installNginx",
      "inputs": {
        "commands": [
          "yum update -y",
          "yum install nginx -y",
          "systemctl start nginx",
          "systemctl enable nginx",
          "echo '<h1>Hello from Nginx!</h1>' > /usr/share/nginx/html/index.html"
        ]
      }
    }
  ]
}
大規模環境でのターゲット指定:

aws_ssm_association リソースの targets ブロックを利用して、タグ、リソースグループ、AWS Config 準拠など、柔軟なターゲット指定を行います。大規模な環境でも効率的に関連付けを管理できます。
resource "aws_ssm_association" "example_association_tags" {
  name             = aws_ssm_document.example_document.name
  association_name = "example-association-tags"

  targets {
    key    = "tag:Environment"
    values = ["production"]
  }
}
Parameter Store のセキュア文字列 (SecureString) の管理:

aws_ssm_parameter リソースで type = "SecureString" を指定し、KMS キー (key_id 引数) を指定することで、Parameter Store にセキュア文字列を安全に保管できます。
resource "aws_ssm_parameter" "db_password" {
  name    = "/${var.environment}/db/password"
  type    = "SecureString"
  value   = "supersecretpassword"
  key_id  = "alias/aws/kms" # KMS キーを指定
}
外部ファイルの SSM ドキュメント:
複雑な SSM ドキュメントは、Terraform コード内に直接記述するのではなく、YAML または JSON ファイルとして外部ファイル化し、file() 関数や templatefile() 関数で読み込むことで、コードの見通しを良くすることができます。
resource "aws_ssm_document" "example_document_external" {
  name            = "example-document-external"
  document_type   = "Command"
  content         = file("documents/example-document.json")
}
冪等性 (Idempotency) の考慮:
Terraform は冪等性を持つツールですが、SSM リソースの作成・変更処理も冪等性を意識して記述します。同じ Terraform コードを複数回実行しても、意図しない変更が発生しないように注意します。特に aws_ssm_association リソースは、既存の関連付けが存在する場合、エラーが発生する可能性があるため、 lifecycle ブロックの ignore_changes などを活用して、意図しない変更を抑制することを検討します。
ドリフト (Drift) 検知と対応:
Terraform の状態管理 (State Management) を適切に行い、実際の AWS 環境と Terraform の状態定義との差異 (ドリフト) を検知し、必要に応じて修正します。 terraform plan コマンドでドリフトを確認し、 terraform apply コマンドで修正します。
Terraform Cloud/Enterprise の活用:
チームでの Terraform 運用を行う場合、Terraform Cloud や Terraform Enterprise を活用することで、状態管理、コラボレーション、ガバナンスなどを強化できます。
Terraform を活用することで、SSM の設定をコードとして管理し、インフラストラクチャ全体の自動化、再現性、バージョン管理を向上させることができます。上記の基本と実務レベルの内容を理解し、Terraform を効果的に活用してください。
【実務レベルの内容と重要事項】

【実務でどの程度使用されるのか】

【terraformのコードで記述する場合の基本的内容と実務レベルの内容】

Discussion
