AWS Systems Manager運用自動化ガイド｜パッチ管理・リモート接続・インベントリ管理の実践方法

⚡ 3秒でわかる！この記事のポイント

Systems ManagerのSession Managerを使えばSSHキー管理不要で安全にサーバー接続できる
Patch Managerで数百台規模のパッチ適用を自動化し運用負荷を大幅削減できる
Run CommandとAutomationで定型オペレーションをコード化し属人化を解消できる

SES案件でインフラ運用を担当するエンジニアにとって、サーバー管理・パッチ適用・構成管理は避けて通れない業務です。結論から言うと、AWS Systems Manager（SSM）を使いこなせば、運用業務の80%以上を自動化でき、SESエンジニアとしての市場価値も大きく向上します。

この記事はAWS完全攻略シリーズの第31回として、Systems Managerの主要機能と実践的な運用自動化テクニックを解説します。

この記事でわかること

Session Managerの設定方法とSSH代替としての活用法
Patch Managerでパッチ適用を完全自動化する方法
Run Commandで複数サーバーに一括コマンド実行する方法
Parameter Store / Secrets Managerの使い分け
Automationランブックで障害対応を自動化する方法
SES現場で即使えるSSM活用パターン集

AWS Systems Managerとは

SSMの全体像

AWS Systems Managerは、AWSリソースの運用管理を一元化するサービスです。以下の主要機能を提供します。

機能	用途	主な活用シーン
Session Manager	リモート接続	SSH代替、監査ログ付きセッション
Patch Manager	パッチ管理	OS・アプリのパッチ自動適用
Run Command	コマンド実行	複数サーバーへの一括操作
Parameter Store	パラメータ管理	環境変数・設定値の一元管理
Automation	自動化	ランブック実行・障害対応自動化
Inventory	インベントリ	サーバー構成情報の収集・可視化
State Manager	状態管理	構成のドリフト検知・自動修正

SSM Agentの導入

Systems Managerを利用するには、管理対象のインスタンスにSSM Agentをインストールする必要があります。

# Amazon Linux 2023 / Amazon Linux 2
# SSM Agentはプリインストール済み

# Ubuntu
sudo snap install amazon-ssm-agent --classic
sudo systemctl enable snap.amazon-ssm-agent.amazon-ssm-agent.service
sudo systemctl start snap.amazon-ssm-agent.amazon-ssm-agent.service

# 動作確認
sudo systemctl status amazon-ssm-agent

IAMロールの設定も必要です。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ssm:UpdateInstanceInformation",
        "ssmmessages:CreateControlChannel",
        "ssmmessages:CreateDataChannel",
        "ssmmessages:OpenControlChannel",
        "ssmmessages:OpenDataChannel",
        "ec2messages:AcknowledgeMessage",
        "ec2messages:DeleteMessage",
        "ec2messages:FailMessage",
        "ec2messages:GetEndpoint",
        "ec2messages:GetMessages",
        "ec2messages:SendReply"
      ],
      "Resource": "*"
    }
  ]
}

Session Manager — SSHキー不要の安全なリモート接続

SSHの課題とSession Managerの利点

従来のSSH接続には多くの運用課題があります。

SSHの課題：

SSHキーの生成・配布・ローテーション管理
ポート22の開放によるセキュリティリスク
踏み台サーバーの運用コスト
操作ログの取得が困難

Session Managerの利点：

SSHキー不要（IAM認証ベース）
インバウンドポート不要（セキュリティグループでSSH許可不要）
全操作のCloudTrail + S3ログ記録
IAMポリシーによるアクセス制御

Session Managerの設定

# AWS CLIからセッションを開始
aws ssm start-session --target i-0abc123def456

# ポートフォワーディング（RDS接続など）
aws ssm start-session \
  --target i-0abc123def456 \
  --document-name AWS-StartPortForwardingSessionToRemoteHost \
  --parameters '{"host":["mydb.cluster-abc.ap-northeast-1.rds.amazonaws.com"],"portNumber":["5432"],"localPortNumber":["15432"]}'

ポートフォワーディングにより、プライベートサブネットのRDSにもローカルから安全に接続できます。

セッションログの設定

{
  "schemaVersion": "1.0",
  "description": "Session Manager設定",
  "sessionManagerConfiguration": {
    "s3BucketName": "my-ssm-session-logs",
    "s3KeyPrefix": "session-logs",
    "s3EncryptionEnabled": true,
    "cloudWatchLogGroupName": "/ssm/session-logs",
    "cloudWatchEncryptionEnabled": true,
    "runAsEnabled": true,
    "runAsDefaultUser": "ssm-user",
    "idleSessionTimeout": "30",
    "maxSessionDuration": "120"
  }
}

AWS Systems Manager 運用自動化アーキテクチャ全体像

Patch Manager — パッチ適用の完全自動化

パッチベースラインの設定

Patch Managerはパッチベースラインに基づいて、パッチの承認・適用を自動化します。

# カスタムパッチベースラインの作成
aws ssm create-patch-baseline \
  --name "production-linux-baseline" \
  --operating-system "AMAZON_LINUX_2023" \
  --approval-rules '{
    "PatchRules": [
      {
        "PatchFilterGroup": {
          "PatchFilters": [
            {"Key": "SEVERITY", "Values": ["Critical", "Important"]},
            {"Key": "CLASSIFICATION", "Values": ["Security"]}
          ]
        },
        "ApproveAfterDays": 7,
        "ComplianceLevel": "CRITICAL"
      },
      {
        "PatchFilterGroup": {
          "PatchFilters": [
            {"Key": "SEVERITY", "Values": ["Medium", "Low"]},
            {"Key": "CLASSIFICATION", "Values": ["Bugfix"]}
          ]
        },
        "ApproveAfterDays": 14,
        "ComplianceLevel": "MEDIUM"
      }
    ]
  }'

メンテナンスウィンドウの設定

パッチ適用をスケジュール実行するために、メンテナンスウィンドウを設定します。

# メンテナンスウィンドウの作成（毎週日曜3:00-5:00 JST）
aws ssm create-maintenance-window \
  --name "weekly-patch-window" \
  --schedule "cron(0 18 ? * SAT *)" \
  --duration 2 \
  --cutoff 1 \
  --allow-unassociated-targets

# ターゲット登録（タグベース）
aws ssm register-target-with-maintenance-window \
  --window-id "mw-0abc123" \
  --resource-type "INSTANCE" \
  --targets "Key=tag:PatchGroup,Values=production"

# タスク登録
aws ssm register-task-with-maintenance-window \
  --window-id "mw-0abc123" \
  --targets "Key=WindowTargetIds,Values=target-id" \
  --task-arn "AWS-RunPatchBaseline" \
  --task-type "RUN_COMMAND" \
  --task-invocation-parameters '{
    "RunCommand": {
      "Parameters": {
        "Operation": ["Install"],
        "RebootOption": ["RebootIfNeeded"]
      }
    }
  }'

パッチコンプライアンスの確認

# パッチコンプライアンスの確認
aws ssm describe-instance-patch-states \
  --instance-ids i-0abc123def456

# コンプライアンス違反のインスタンスを一覧
aws ssm describe-instance-patch-states-for-patch-group \
  --patch-group "production" \
  --filters "Key=ComplianceLevel,Values=NON_COMPLIANT,Type=EQUAL"

Run Command — 複数サーバーへの一括コマンド実行

基本的な使い方

# 全プロダクションサーバーでディスク使用量を確認
aws ssm send-command \
  --document-name "AWS-RunShellScript" \
  --targets "Key=tag:Environment,Values=production" \
  --parameters 'commands=["df -h","free -m","uptime"]' \
  --comment "Daily health check" \
  --timeout-seconds 60

# 結果の確認
aws ssm list-command-invocations \
  --command-id "cmd-0abc123" \
  --details

カスタムドキュメントの作成

定型業務をSSMドキュメントとして定義し、再利用可能にします。

{
  "schemaVersion": "2.2",
  "description": "アプリケーションログのローテーションと圧縮",
  "parameters": {
    "LogDirectory": {
      "type": "String",
      "default": "/var/log/app",
      "description": "ログディレクトリパス"
    },
    "RetentionDays": {
      "type": "String",
      "default": "30",
      "description": "ログ保持日数"
    }
  },
  "mainSteps": [
    {
      "action": "aws:runShellScript",
      "name": "rotateAndCompressLogs",
      "inputs": {
        "runCommand": [
          "#!/bin/bash",
          "LOG_DIR='{{ LogDirectory }}'",
          "RETENTION='{{ RetentionDays }}'",
          "echo \"Rotating logs in $LOG_DIR (retention: $RETENTION days)\"",
          "find $LOG_DIR -name '*.log' -mtime +1 -exec gzip {} \\;",
          "find $LOG_DIR -name '*.gz' -mtime +$RETENTION -delete",
          "echo \"Log rotation complete\""
        ]
      }
    }
  ]
}

Parameter Store — 設定値の一元管理

パラメータの階層構造

# パラメータの作成（階層構造）
aws ssm put-parameter \
  --name "/app/production/database/host" \
  --value "mydb.cluster-abc.ap-northeast-1.rds.amazonaws.com" \
  --type "String"

aws ssm put-parameter \
  --name "/app/production/database/password" \
  --value "super-secret-password" \
  --type "SecureString" \
  --key-id "alias/app-key"

# 階層ごとの一括取得
aws ssm get-parameters-by-path \
  --path "/app/production/" \
  --recursive \
  --with-decryption

アプリケーションからの参照

# Python (boto3)でのParameter Store参照
import boto3

ssm = boto3.client('ssm', region_name='ap-northeast-1')

def get_db_config() -> dict:
    """Parameter StoreからDB設定を取得."""
    response = ssm.get_parameters_by_path(
        Path='/app/production/database/',
        Recursive=True,
        WithDecryption=True,
    )
    config = {}
    for param in response['Parameters']:
        key = param['Name'].split('/')[-1]
        config[key] = param['Value']
    return config

# ECSタスク定義でのSSMパラメータ参照
# {
#   "name": "DATABASE_HOST",
#   "valueFrom": "arn:aws:ssm:ap-northeast-1:123456789:parameter/app/production/database/host"
# }

Parameter Storeとの使い分けについてはAWS IAMセキュリティガイドも参照してください。

Automation — 障害対応の自動化

ランブックの作成

障害対応手順をAutomationランブックとして定義し、自動実行します。

# EC2インスタンスの自動復旧ランブック
description: "EC2インスタンスのヘルスチェック失敗時の自動復旧"
schemaVersion: "0.3"
assumeRole: "{{ AutomationAssumeRole }}"
parameters:
  InstanceId:
    type: String
    description: "対象インスタンスID"
  AutomationAssumeRole:
    type: String
    description: "Automationの実行ロール"
mainSteps:
  - name: describeInstance
    action: aws:executeAwsApi
    inputs:
      Service: ec2
      Api: DescribeInstances
      InstanceIds:
        - "{{ InstanceId }}"
    outputs:
      - Name: InstanceState
        Selector: "$.Reservations[0].Instances[0].State.Name"
        Type: String

  - name: checkIfRunning
    action: aws:branch
    inputs:
      Choices:
        - NextStep: stopInstance
          Variable: "{{ describeInstance.InstanceState }}"
          StringEquals: "running"
      Default: startInstance

  - name: stopInstance
    action: aws:executeAwsApi
    inputs:
      Service: ec2
      Api: StopInstances
      InstanceIds:
        - "{{ InstanceId }}"

  - name: waitForStop
    action: aws:waitForAwsResourceProperty
    inputs:
      Service: ec2
      Api: DescribeInstances
      InstanceIds:
        - "{{ InstanceId }}"
      PropertySelector: "$.Reservations[0].Instances[0].State.Name"
      DesiredValues:
        - stopped
    timeoutSeconds: 300

  - name: startInstance
    action: aws:executeAwsApi
    inputs:
      Service: ec2
      Api: StartInstances
      InstanceIds:
        - "{{ InstanceId }}"

  - name: waitForRunning
    action: aws:waitForAwsResourceProperty
    inputs:
      Service: ec2
      Api: DescribeInstances
      InstanceIds:
        - "{{ InstanceId }}"
      PropertySelector: "$.Reservations[0].Instances[0].State.Name"
      DesiredValues:
        - running
    timeoutSeconds: 300

  - name: sendNotification
    action: aws:executeAwsApi
    inputs:
      Service: sns
      Api: Publish
      TopicArn: "arn:aws:sns:ap-northeast-1:123456789:ops-alerts"
      Message: "EC2 {{ InstanceId }} の自動復旧が完了しました"
      Subject: "[SSM Automation] EC2自動復旧完了"

CloudWatch Alarmsとの連携

CloudWatchアラームをトリガーにしてAutomationランブックを自動実行する設定を行います。

# CloudWatchアラーム → SNS → Lambda → SSM Automation
aws cloudwatch put-metric-alarm \
  --alarm-name "ec2-status-check-failed" \
  --metric-name "StatusCheckFailed" \
  --namespace "AWS/EC2" \
  --statistic "Maximum" \
  --period 60 \
  --evaluation-periods 3 \
  --threshold 1 \
  --comparison-operator "GreaterThanOrEqualToThreshold" \
  --dimensions "Name=InstanceId,Value=i-0abc123def456" \
  --alarm-actions "arn:aws:ssm:ap-northeast-1:123456789:automation-definition/EC2-AutoRecover"

CloudWatchの詳細はAWS CloudWatch監視ガイドを参照してください。

Inventoryによる構成管理

インベントリ収集の設定

管理対象インスタンスのソフトウェア・ネットワーク・OS情報を自動収集します。

# インベントリの関連付け作成
aws ssm create-association \
  --name "AWS-GatherSoftwareInventory" \
  --targets "Key=tag:Environment,Values=production" \
  --schedule-expression "rate(12 hours)" \
  --parameters '{
    "applications": ["Enabled"],
    "awsComponents": ["Enabled"],
    "networkConfig": ["Enabled"],
    "windowsUpdates": ["Enabled"],
    "customInventory": ["Enabled"]
  }'

SES現場でのSSM活用パターン

パターン1: セキュアなDB接続

踏み台サーバー不要で、Session Managerのポートフォワーディングを使ってRDSに安全に接続する構成は、SES案件で最も需要が高いパターンです。

パターン2: パッチコンプライアンス自動化

金融系やヘルスケア系のSES案件では、パッチ適用状況の証跡が求められます。Patch Managerのコンプライアンスレポートを活用することで、監査対応を自動化できます。

パターン3: 運用ランブック標準化

SES案件の引き継ぎ時に最も問題になるのが属人化された運用手順です。SSM Automationでランブックを標準化することで、誰でも同じ品質で運用作業を実行できます。

まとめ

AWS Systems Managerは、SES案件のインフラ運用を劇的に効率化する強力なサービスです。

SSM活用で押さえるべきポイント：

Session ManagerでSSHキー管理から解放され、全操作の監査ログも自動取得
Patch Managerで数百台規模のパッチ適用を安全に自動化
Run Commandで定型オペレーションを一括実行し属人化を解消
Parameter Storeで設定値を一元管理し環境ごとの差異を吸収
Automationランブックで障害対応を自動化しMTTRを短縮

SSMのスキルはSESインフラ案件の単価を大きく左右します。まずはSession ManagerとPatch Managerから導入し、段階的にAutomationへ拡張していきましょう。