Secrets Manager vs SSM Parameter Store — コスト・機能・ローテーションの使い分け

2つのサービスの位置づけ

特徴	Secrets Manager	SSM Parameter Store
主な用途	データベース認証情報、APIキー	設定値、パスワード、設定ファイル
自動ローテーション	✅ ネイティブサポート	❌ Lambda等で自前実装が必要
クロスアカウント	✅ リソースポリシーで可能	❌ 直接共有は不可
料金	$0.40/シークレット/月 + API呼び出し料金	標準: 無料、高度: $0.05/パラメータ/月
バージョン管理	✅ 複数バージョン保持	✅ バージョン管理あり
暗号化	デフォルトでKMS	標準: SSM固有、高度: KMS選択可
レプリケーション	✅ マルチリージョンシークレット	❌

SSM Parameter Storeの詳細

Standard（標準）パラメータ

# 標準パラメータ（無料、最大4KB）
aws ssm put-parameter \
  --name "/myapp/prod/db-password" \
  --value "mysecretpassword" \
  --type SecureString \
  --key-id alias/aws/ssm

# 階層型命名規則を使うと管理しやすい
/myapp/
  prod/
    db-host
    db-password
    api-key
  staging/
    db-host
    db-password

Advanced（高度）パラメータ

# 高度パラメータ（$0.05/月、最大8KB、有効期限設定可）
aws ssm put-parameter \
  --name "/myapp/prod/large-config" \
  --value '{"key": "long value..."}' \
  --type SecureString \
  --tier Advanced \
  --policies '[{
    "Type": "Expiration",
    "Version": "1.0",
    "Attributes": {
      "Timestamp": "2026-12-31T00:00:00.000Z"
    }
  }]'

Secrets Managerの自動ローテーション

# RDS認証情報のローテーション設定
aws secretsmanager create-secret \
  --name "prod/myapp/rds-credentials" \
  --description "RDS credentials for prod" \
  --secret-string '{"username":"admin","password":"initial-password"}'

# ローテーション設定（30日ごと）
aws secretsmanager rotate-secret \
  --secret-id "prod/myapp/rds-credentials" \
  --rotation-lambda-arn arn:aws:lambda:ap-northeast-1:123456789012:function:SecretsManagerRotation \
  --rotation-rules AutomaticallyAfterDays=30

AWSが提供するマネージドローテーション（追加Lambda設定不要）：

対応サービス:
  - Amazon RDS（MySQL, PostgreSQL, Oracle, SQL Server）
  - Amazon Redshift
  - Amazon DocumentDB
  - Amazon Aurora
  → "AWS managed rotation"を選択するだけで自動設定

アプリケーションでの参照

Lambda関数での参照（Secrets Manager）

import boto3
import json
from functools import lru_cache

# キャッシュで毎回APIを呼ばない（コスト削減）
@lru_cache(maxsize=10)
def get_secret(secret_name: str) -> dict:
    client = boto3.client('secretsmanager')
    response = client.get_secret_value(SecretId=secret_name)
    return json.loads(response['SecretString'])

def handler(event, context):
    # シークレットを取得（Lambdaの実行コンテキスト内でキャッシュ）
    db_creds = get_secret('prod/myapp/rds-credentials')
    
    conn = connect_db(
        host=db_creds['host'],
        user=db_creds['username'],
        password=db_creds['password']
    )

ECS Task DefinitionでのSSM参照

// ECSタスク定義でSSM Parameter Storeの値を環境変数として注入
{
  "containerDefinitions": [{
    "name": "app",
    "image": "my-app:latest",
    "secrets": [
      {
        "name": "DB_PASSWORD",
        "valueFrom": "arn:aws:ssm:ap-northeast-1:123456789012:parameter/myapp/prod/db-password"
      },
      {
        "name": "API_KEY",
        "valueFrom": "arn:aws:secretsmanager:ap-northeast-1:123456789012:secret:prod/api-key"
      }
    ]
  }]
}

選択基準

Secrets Manager を選ぶケース:
  - データベース認証情報（自動ローテーション活用）
  - 複数アカウントで共有が必要なシークレット
  - マルチリージョンのシークレット同期が必要
  - 定期的なキーローテーションが規制要件

SSM Parameter Store を選ぶケース:
  - 設定値（環境変数的な使い方）
  - コスト最優先（無料枠で収まるケース）
  - 階層型の設定管理（/app/env/key形式）
  - ローテーション不要のAPIキー等の静的値
  - 大量のパラメータ（Secrets Managerより安価）

試験頻出ポイント

シナリオ	回答
RDSパスワードの自動ローテーション	Secrets Manager
大量の設定値をコスト効率よく管理	SSM Parameter Store（標準、無料）
クロスアカウントでシークレットを共有	Secrets Manager（リソースポリシー）
ECS/Lambdaに安全に認証情報を渡す	両方対応（ECSのsecretsフィールド）
マルチリージョンでシークレット同期	Secrets Manager（マルチリージョンシークレット）

まとめ

ローテーションが必要な認証情報（DBパスワード等）にはSecrets Manager、設定値の管理にはSSM Parameter Storeと使い分けるのが基本だ。コスト観点ではSSM標準が無料で有利だが、シークレット管理の機能面ではSecrets Managerが圧倒的に高機能だ。

S	公式ソース確認済み
A	成功実績多数・失敗例少数
B	賛否両論
C	動作未確認・セキュリティリスク高
Z	個人所感