AWS Systems Manager Parameter Store実践入門｜Secrets Managerとの違い・設定値一元管理・Lambda連携の実践ガイド

クラウド移行を進めると、最初に頭を悩ませるのが「設定値をどこに持つか」問題です。オンプレ時代は`.properties`ファイルや環境ごとのconfigファイルで済んでいたものが、クラウドではLambda・ECS・EC2が混在し、DB接続文字列やAPIエンドポイント、フィーチャーフラグをどこで管理するかが一気に複雑になります。ソースコードにハードコードするのは論外ですし、環境変数に直接書いても環境ごとのデプロイ管理が煩雑になる一方です。

AWSにはこの課題を解決するために、AWS Systems Manager Parameter Store（SSM パラメータストア）が用意されています。無料枠が充実していて、Lambda・ECS・EC2との連携が自然に書ける設計思想は、オンプレから移ってきたエンジニアにとってかなり使いやすいサービスです。

この記事では、Parameter Storeの仕組みから始めて、よく混同されるSecrets Managerとの使い分け基準、パラメータの命名規則、CLIとSDKによる操作手順、Lambda・ECS・EC2との連携パターン、料金体系まで体系的に解説します。

AWS Systems Manager Parameter Storeとは何か

Parameter Storeは、AWS Systems Manager（SSM）の一機能として提供される設定値の一元管理サービスです。テキスト形式の設定値を階層構造で保存・取得でき、バージョン管理も自動で行われます。

AWS Systems Manager自体はEC2やオンプレサーバーの運用管理基盤で、Session Managerによるシェルアクセス、パッチ管理、インベントリ収集などを担います。Parameter Storeはその中の「設定値を安全に保管・配布する」コンポーネントです。

Session Managerを中心としたSSM全体の概要については、AWS Systems Manager（SSM）入門で解説しています。

Parameter Storeが解決する課題は次のとおりです。

・設定値の分散管理を解消する: 本番・ステージング・開発それぞれの設定値を `/prod/myapp/db/host`、`/staging/myapp/db/host` のようにパス形式で整理し、サービス側はパスだけ受け取れば環境切替できます
・機密情報の平文埋め込みを排除する: SecureStringタイプを使えばKMS暗号化が自動で適用され、コードにAPIキーを書く必要がなくなります
・変更履歴を残す: パラメータを更新するたびにバージョンが自動採番され、いつ誰が変更したかをCloudTrailと組み合わせて追跡できます

Secrets ManagerとParameter Storeの違い：使い分け基準

「Parameter StoreとSecrets Manager、どちらを使えばいいか」は、AWSを使い始めたエンジニアが必ずつまずく問いです。同じく設定値・シークレットを管理するサービスですが、設計思想が異なります。

Secrets Managerの詳細についてはAWS Secrets Manager入門を参照してください。

【判断基準】どちらを選ぶか

以下の判断フローで9割のケースはカバーできます。

・定期ローテーションが必要（RDSのマスターパスワード等）→ Secrets Manager一択: 自動ローテーション機能はParameter Storeにはありません
・クロスアカウントで複数チームが参照する共有シークレット → Secrets Manager: Parameter Storeはアカウントをまたいだ参照に非対応です
・上記以外の設定値・平文で管理できる値 → Parameter Store: 無料枠が広く、階層管理が便利です
・SecureStringで機密性を確保しつつコストを抑えたい → Parameter Store + SecureString: 手動ローテーションが許容できるAPIキーや固定のサービスアカウント情報ならこちらでコストを節約できます

現場での経験則として、「ローテーション不要な設定値はParameter Store、RDS・RedshiftのパスワードはSecrets Manager」と使い分けるチームが多いです。

パラメータタイプと命名規則の設計

1. パラメータタイプ

Parameter Storeには3つのタイプがあります。

・String: 平文のテキスト。DB接続先ホスト名、S3バケット名、フィーチャーフラグ（”true”/”false”）など、機密性のない設定値に使います
・StringList: カンマ区切りの文字列リスト。複数のIPアドレスや許可ドメインリストを1つのパラメータで管理したい場合に便利です
・SecureString: KMS（AWS Key Management Service）で暗号化された文字列。APIキー、内部システムのパスワード、Slack Webhookトークンなど、機密性が求められる値に使います。aws/ssm というデフォルトキーを指定するとKMS追加料金なしで利用できます

2. 命名規則（パス設計）

Parameter Storeは `/` をパス区切り文字として階層構造を表現できます。設計の自由度が高い分、チームで命名規則を統一しないと後から混乱します。推奨パターンは次のとおりです。

# 推奨パターン: /{環境}/{アプリ名}/{カテゴリ}/{キー}
/prod/myapp/db/host
/prod/myapp/db/port
/prod/myapp/db/name
/staging/myapp/db/host
/prod/myapp/api/external-service-key
/prod/myapp/feature/new-ui-enabled

# get-parameters-by-path でパス単位に一括取得できる
# 例: /prod/myapp/db/ 配下を全件取得 → アプリ起動時に一度で読み込める

パス設計のポイントをまとめます。

・環境を先頭に置く（`/prod`・`/staging`・`/dev`）ことで、IAMポリシーのパスプレフィックスによる環境分離が容易になります
・アプリ名を2階層目にすることで、マイクロサービス構成でも名前空間が衝突しません
・カテゴリ（db・api・feature など）を3階層目に置くと、`get-parameters-by-path –recursive` での一括取得がカテゴリ単位で絞り込めます

基本的な使い方：AWS CLI操作

1. パラメータの登録

# AWS CLI: Stringタイプで登録
aws ssm put-parameter \
  --name "/prod/myapp/db/host" \
  --value "mydb.cluster.ap-northeast-1.rds.amazonaws.com" \
  --type String \
  --overwrite

# SecureStringタイプ（デフォルトKMSキー使用）
aws ssm put-parameter \
  --name "/prod/myapp/api/external-service-key" \
  --value "sk-xxxxxxxxxxxxxxxx" \
  --type SecureString \
  --overwrite

2. パラメータの取得

# 単一パラメータを取得
aws ssm get-parameter \
  --name "/prod/myapp/db/host" \
  --query "Parameter.Value" \
  --output text

# SecureStringを復号して取得（--with-decryption が必要）
aws ssm get-parameter \
  --name "/prod/myapp/api/external-service-key" \
  --with-decryption \
  --query "Parameter.Value" \
  --output text

# パスプレフィックスで一括取得
aws ssm get-parameters-by-path \
  --path "/prod/myapp/db/" \
  --recursive \
  --with-decryption

3. バージョン確認と履歴参照

# パラメータの詳細（現在バージョン含む）を確認
aws ssm describe-parameters \
  --filters "Key=Name,Values=/prod/myapp/db/host"

# 特定バージョンを明示取得（バージョン番号を":"で指定）
aws ssm get-parameter \
  --name "/prod/myapp/db/host:3" \
  --query "Parameter.Value" \
  --output text

Lambda・ECS・EC2との連携パターン

1. Lambdaとの連携：コールドスタート対策を含めた設計

LambdaからParameter Storeを参照する方法は2通りあります。

方法①: Lambda関数内でSDKを使って実行時取得（シンプル）

# Python（boto3）でParameter Storeから取得
import boto3
import json

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

def get_parameter(name, with_decryption=False):
    response = ssm.get_parameter(
        Name=name,
        WithDecryption=with_decryption
    )
    return response['Parameter']['Value']

def lambda_handler(event, context):
    # ハンドラ外に置くとコンテナ再利用時にキャッシュが効く
    db_host = get_parameter('/prod/myapp/db/host')
    api_key = get_parameter('/prod/myapp/api/external-service-key', True)
    # 処理...

コールドスタートへの対処: `ssm.get_parameter()` をハンドラ関数の外（モジュールレベル）に置くと、Lambda コンテナが再利用される際にキャッシュが効き、毎回SSMへAPIコールしなくて済みます。ただし値の変更が即座に反映されないため、頻繁に更新するパラメータには向きません。

方法②: AWS Lambda 拡張機能（SSM Parameters and Secrets Lambda Extension）

2021年以降、Lambda拡張機能としてParameter StoreとSecrets Managerの値をローカルキャッシュ経由で取得できる仕組みが提供されています。HTTP経由で `localhost:2773/systemsmanager/parameters/get` を叩くだけで取得でき、TTLベースのキャッシュが内蔵されています。大量のパラメータ取得やコスト最適化を意識する場合に有効です。

Lambda関数には `ssm:GetParameter` と `ssm:GetParametersByPath` のIAM権限が必要です。LambdaのIAM実行ロールに以下のポリシーを付与します。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ssm:GetParameter",
        "ssm:GetParametersByPath"
      ],
      "Resource": "arn:aws:ssm:ap-northeast-1:123456789012:parameter/prod/myapp/*"
    },
    {
      "Effect": "Allow",
      "Action": "kms:Decrypt",
      "Resource": "arn:aws:kms:ap-northeast-1:123456789012:key/（KMSキーID）"
    }
  ]
}

2. ECSとの連携：タスク定義でSSM参照

ECSのタスク定義では、環境変数の値としてParameter Storeのパスを直接指定できます。コンテナイメージにシークレットを焼き込まずに済むため、セキュアなデプロイが実現できます。

ECSのタスク設計全般についてはAmazon ECS入門を参照してください。

# ECSタスク定義（JSON抜粋）でのSSMパラメータ参照
{
  "containerDefinitions": [
    {
      "name": "myapp",
      "image": "123456789012.dkr.ecr.ap-northeast-1.amazonaws.com/myapp:latest",
      "environment": [
        {
          "name": "DB_HOST",
          "value": "mydb.cluster.ap-northeast-1.rds.amazonaws.com"
        }
      ],
      "secrets": [
        {
          "name": "DB_PASSWORD",
          "valueFrom": "arn:aws:ssm:ap-northeast-1:123456789012:parameter/prod/myapp/db/password"
        },
        {
          "name": "API_KEY",
          "valueFrom": "arn:aws:ssm:ap-northeast-1:123456789012:parameter/prod/myapp/api/external-service-key"
        }
      ]
    }
  ]
}

`environment` は平文の環境変数、`secrets` がSSM/Secrets Managerから取得する秘匿値の指定です。コンテナ起動時にECSがSSMから値を取得し、環境変数として注入します。タスクロールに `ssm:GetParameters` の権限を付与するのを忘れずに。

3. EC2との連携：IAMロールで透過的にアクセス

EC2インスタンスからは、インスタンスプロファイル（IAMロール）を通じてParameter Storeにアクセスします。アクセスキーをインスタンス内に配置する必要がなく、最小権限の原則を維持できます。

EC2のIAMロール設計についてはAmazon EC2入門を参照してください。

# EC2インスタンス上でのパラメータ取得（シェルスクリプト例）
#!/bin/bash
DB_HOST=$(aws ssm get-parameter \
  --name "/prod/myapp/db/host" \
  --region ap-northeast-1 \
  --query "Parameter.Value" \
  --output text)

API_KEY=$(aws ssm get-parameter \
  --name "/prod/myapp/api/external-service-key" \
  --with-decryption \
  --region ap-northeast-1 \
  --query "Parameter.Value" \
  --output text)

export DB_HOST API_KEY

EC2の起動スクリプト（user data）やSystemdのExecStartPre内でこのシェルを実行し、アプリケーションの環境変数として渡すパターンが現場では広く使われています。

料金の仕組み（2026年10月時点）

Parameter Storeの料金体系はシンプルで、Standardパラメータは実質無料です。

ほとんどの用途はStandardパラメータで賄えます。Advancedが必要になるのは、「パラメータ数が10,000を超える大規模マイクロサービス環境」か、「有効期限ポリシーで定期ローテーションのリマインダーをEventBridgeに飛ばしたい」といったケースに限られます。

コスト試算の注意点: SecureStringタイプを使う場合、KMSキーの呼び出し料金が別途発生します（$0.03/10,000回コール、デフォルトのaws/ssmキー使用時）。Lambda関数がParameter Storeを毎回のハンドラ呼び出しで参照するような実装をすると、高トラフィック時にKMSコールが積み上がります。前述の「モジュールレベルキャッシュ」や「Lambda Extensions」によるキャッシュ活用でコールを抑制するのが現場のセオリーです。

よくあるトラブルと対処法

1. 「AccessDeniedException」でパラメータが取得できない

最も多いトラブルです。原因は大抵3つのどれかです。

・IAMポリシーのResourceのARNが間違っている: `arn:aws:ssm:リージョン:アカウントID:parameter/パス` の形式で、先頭の `/` が必要です。`parameter/prod/myapp/*` と `parameter/prod/*` では対象範囲が異なります
・SecureStringなのにkms:Decryptが付いていない: SecureStringの取得には `ssm:GetParameter` に加えて `kms:Decrypt` も必要です
・リージョンが違う: SDKのクライアント初期化時にリージョンを明示していないと、デフォルトリージョン（`AWS_DEFAULT_REGION`環境変数）が使われ、パラメータを作成したリージョンと食い違うことがあります

2. SecureStringを取得したのに暗号文字列が返ってくる

`–with-decryption`（CLIの場合）または `WithDecryption=True`（SDKの場合）を指定し忘れていると、暗号化された生の文字列が返ります。SecureStringを使う際は必ずこのオプションを付けてください。

3. 値を更新したのにアプリに反映されない

Lambda・ECSのコンテナはParameter Storeの値を起動時にキャッシュする実装が多く、値を更新してもコンテナが再起動されるまで反映されません。緊急で設定変更を反映したい場合は、Lambda関数の再デプロイ（コード変更なしの強制デプロイ）やECSサービスの強制再デプロイ（`–force-new-deployment`）が必要です。

4. 「ParameterNotFound」エラーが出る

パスの大文字・小文字や末尾スラッシュを確認してください。Parameter Storeはパスが完全一致しないとエラーになります。`get-parameters-by-path` を使う場合、`–path` に指定するのはパスプレフィックスで末尾スラッシュは不要（`/prod/myapp/db` で `/prod/myapp/db/host` も取得できます）という点も混乱しやすいポイントです。

本記事のまとめ

AWS Systems Manager Parameter Storeは、クラウド設計の中でも特に「地味だけど重要」な基盤コンポーネントです。主なポイントを整理します。

オンプレでは「configファイルをサーバーに手作業で配置」していた作業を、Parameter Storeを使うことで「パスを指定して自動取得・自動注入」に変えられます。デプロイパイプラインとの連携も自然で、インフラの設定管理を一段クラウドネイティブな形に引き上げるサービスです。