---
title: "AWS Secrets Managerとは？料金・ローテーション設定と採用判断を実装者目線で解説【2026年版】"
url: "https://www.issoh.co.jp/tech/details/15888/"
published: 2026-07-30
updated: 2026-10-12
categories: ["セキュリティ"]
publisher: "株式会社一創"
---

# AWS Secrets Managerとは？料金・ローテーション設定と採用判断を実装者目線で解説【2026年版】

AWS Secrets Managerは、データベースのパスワードやAPIキーを暗号化して保管し、アプリケーションからAPI経由で取り出せるようにするマネージドサービスです。単なる保管庫と違うのは、値を定期的に作り替えて配り直すローテーションまで引き受ける点にあります。

この記事では、AWSCURRENTとAWSPENDINGというラベルで動くバージョン管理、ローテーション関数が踏む4つの状態、1件0.40USD/月とAPI1万件0.05USDという課金の積み上がり方、Parameter StoreのSecureStringとの分岐点、取得実装の3パターンを、そのまま実行できるCLI・boto3・設定ファイルつきで整理します。最後に、導入してよい条件と見送ってよい場面を条件付きで示しました。

## まとめ：AWS Secrets Managerの担当範囲とParameter Storeとの分岐点

先に結論を置きます。Secrets Managerを入れる理由は「秘密の値を隠すため」ではありません。値を定期的に入れ替える運用を、アプリを止めずに回すためです。

- **分岐点はローテーション要件の有無**：値がほとんど変わらない設定値なら、Parameter Storeの標準パラメータが追加料金なしで足ります。ローテーションが要件に入った時点でSecrets Managerが優位になります。
- **コストを決めるのは保管数より取得回数**：1件0.40USD/月は小さな額ですが、リクエストごとに取得する実装にすると、API課金とレイテンシとスロットリングが同時に効いてきます。
- **ローテーションは3方式**：RDSなどのマネージドシークレットと、DatadogやSnowflakeなどのマネージド外部シークレットは関数を書かずに回せます。それ以外はLambda関数を自作し、4つの状態遷移を自分で実装します。
- **接続断を避けるなら交代ユーザー方式**：AWSの[ローテーション戦略のドキュメント](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotation-strategy.html)は、単純さから既定でシングルユーザーを勧めつつ、高可用性が要るアプリには交代ユーザーを挙げています。
- **取得は起動時1回へ寄せる**：`GetSecretValue` のレート上限は10,000rps、引き上げ申請は受け付けられません。キャッシュを入れずに移すと、金額よりも先にスロットリングで詰まります。

## Secrets Managerの中身を確かめる｜バージョンとステージングラベルを読む

実装で迷う箇所のほとんどは、シークレットが「値」ではなく「バージョンの集合」である点に由来します。

### Secrets Managerが引き受ける範囲｜保管・認可付き取得・値の更新

このサービスが引き受けるのは、シークレットの保管、認可付きの取得、値の更新という3つの操作です。コードに直書きしたパスワードを、シークレット名を指定したAPIコールへ置き換えるのが基本形になります。AWSの[サービス概要ドキュメント](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html)も、この3操作を軸に構成されています。

1件に入れられる値は最大65,536バイト。JSON形式で複数キーをまとめられるため、DBのホスト名・ポート・ユーザー名・パスワードを1件に収める構成が実務では一般的です。

### GetSecretValueが返す値｜ステージングラベルで進むバージョン管理

値を更新すると、上書きではなく新しいバージョンが作られます。どれが現行かを示すのがステージングラベルです。`GetSecretValue` をラベル指定なしで呼ぶと `AWSCURRENT` が返り、ローテーション中の新しい値には `AWSPENDING`、切り替え前の値には `AWSPREVIOUS` が付きます。

バージョンは1シークレットあたり100件まで。ラベルの付いていないものは100件を超えると自動削除されますが、作成から24時間以内は対象外です。公式ドキュメントは `PutSecretValue` と `UpdateSecret` を10分に1回を超える頻度で呼び続けないよう明記しています。CI/CDから毎デプロイで書き込む設計にすると、削除が追いつかずバージョン上限に当たります。

バージョンを狙って消すAPIはありません。すべてのステージングラベルを外して非推奨の印を付けると、Secrets Managerが背後で回収します。

### クォータを先に読む｜バージョン100件と10,000rpsの上限

設計判断に効く数字は[クォータの一覧](https://docs.aws.amazon.com/secretsmanager/latest/userguide/reference%5Flimits.html)に集まっています。2026年9月時点の主な既定値は次のとおりです。いずれもリージョン単位で、引き上げ可否の列はすべて「No」になっています。

| 項目                  | 既定値        | 引き上げ |
| ------------------- | ---------- | ---- |
| シークレット数             | 500,000件   | 不可   |
| 1件のバージョン数           | 100件       | 不可   |
| 値のサイズ               | 65,536バイト  | 不可   |
| ステージングラベル           | 全バージョンで20個 | 不可   |
| GetSecretValue      | 10,000rps  | 不可   |
| DescribeSecret      | 40,000rps  | 不可   |
| BatchGetSecretValue | 100rps     | 不可   |
| 制御系API              | 各50rps     | 不可   |
| リソースポリシー長           | 20,480文字   | 不可   |

クロスアカウントで呼ぶときは、スロットリングの対象がシークレットの所有アカウントではなく呼び出し元のアカウントになります。共有先が増えるほど、呼ぶ側の上限を先に食う設計です。

### 暗号化キーを決める｜AWSマネージドキーとカスタマーキーの分かれ目

値の暗号化にはKMSキーが使われます。指定しなければAWSマネージドキー `aws/secretsmanager` が使われ、鍵の保管料は発生しません。カスタマーマネージドキーを指定すると、キーポリシーで「このシークレットを復号できる主体」を独立して縛れる代わりに、KMS側の月額とリクエスト課金が上乗せされます。[暗号化のドキュメント](https://docs.aws.amazon.com/secretsmanager/latest/userguide/security-encryption.html)に、どの操作でどの鍵が呼ばれるかの対応が載っています。

アカウントをまたいで共有する構成では、AWSマネージドキーでは復号できないため、カスタマーマネージドキーが必須です。鍵側の設計は[AWS KMSとは？仕組み・料金とキーポリシー設計・採用判断を実装者目線で解説](https://www.issoh.co.jp/tech/details/15884/)で扱っています。

## CLIとSDKでシークレットを作成して取り出す｜最小の実行手順とコード

先に手を動かすと、後半の判断が具体になります。ここではDB接続情報を1件作り、アプリから取り出すまでを通します。

### 最小構成で1件作る｜create-secretとJSON形式の値の入れ方

シークレット名にはスラッシュ区切りの階層をよく使います。環境とシステムと用途を並べておくと、IAMポリシーのリソース指定をワイルドカードで書くことが可能です。[シークレット作成のドキュメント](https://docs.aws.amazon.com/secretsmanager/latest/userguide/create%5Fsecret.html)にコンソール・CLI・SDKの3経路がまとまっています。

```
aws secretsmanager create-secret \
  --name prod/billing/db \
  --description "billing API の RDS 接続情報" \
  --secret-string '{"username":"billing_app","password":"REPLACE_ME","host":"billing.cluster-abc.ap-northeast-1.rds.amazonaws.com","port":5432,"dbname":"billing"}'

aws secretsmanager get-secret-value \
  --secret-id prod/billing/db \
  --query SecretString --output text
```

作成直後の状態は `describe-secret` の `VersionIdsToStages` で見ます。ローテーションを組んだあと、どのバージョンにどのラベルが付いているかを追う場面でも同じコマンドを使います。

### 取り出して起動時に持つ｜boto3とキャッシュライブラリの書き方

アプリ側は[シークレット取得のドキュメント](https://docs.aws.amazon.com/secretsmanager/latest/userguide/retrieving-secrets.html)が示す経路から1つ選びます。Pythonなら、AWSが公開している[キャッシュライブラリのリポジトリ](https://github.com/aws/aws-secretsmanager-caching-python)を挟むのが手数として軽い方法です。次のコードは、TTLを300秒に置いて取得をプロセス内へ閉じ込め、認証失敗を拾ったら強制的に取り直す形にしてあります。

```
import json

import boto3
from aws_secretsmanager_caching import SecretCache, SecretCacheConfig

_client = boto3.client("secretsmanager", region_name="ap-northeast-1")
_cache = SecretCache(
    config=SecretCacheConfig(secret_refresh_interval=300),
    client=_client,
)

SECRET_ID = "prod/billing/db"


def load_credentials(force_refresh=False):
    """DB接続情報を返す。ローテーション直後は force_refresh=True で取り直す。"""
    if force_refresh:
        _cache._cache.pop(SECRET_ID, None)
    return json.loads(_cache.get_secret_string(SECRET_ID))


def connect_with_retry(connect_fn):
    """認証エラーを1度だけ許容し、取り直してから接続をやり直す。"""
    try:
        return connect_fn(**load_credentials())
    except PermissionError:
        return connect_fn(**load_credentials(force_refresh=True))
```

ここで押さえる形は2つです。取得をモジュールの初期化ではなく関数の中に置くこと、そして認証エラーの捕捉と再取得を同じ場所に書くこと。Lambdaなら実行環境の再利用が効くため、ハンドラの外で1回取得してグローバルに持たせる書き方も成立します。

### 権限を2つに絞る｜GetSecretValueとDescribeSecretの付与

アプリに渡す権限は `secretsmanager:GetSecretValue` と `secretsmanager:DescribeSecret` の2つで足ります。リソースにはシークレットのARNを書き、名前の階層をワイルドカードで受けます。IAM側の設計思想は[AWS IAMとは？仕組み・ユーザー/ロール/ポリシーの違いと権限設計のベストプラクティスを実装者目線で解説](https://www.issoh.co.jp/tech/details/15427/)にまとめました。シークレットを読める主体を絞る作業は、ローテーションを組む前に済ませておきます。

取得の記録はCloudTrailに残ります。どのロールがいつ読んだかを追えるため、退職者のアカウントや不要になったバッチが読み続けていないかの棚卸しにも使えます。

## 自動ローテーションを有効にする｜マネージド方式とLambda関数の4ステップ

導入の主目的がローテーションである以上、ここの実装難度が採否を決めます。

### マネージドローテーションで済ませる｜RDSと外部SaaSの対応範囲

Amazon RDS、Aurora、Redshift、DocumentDBのマスターユーザー認証情報をSecrets Manager経由で作った場合、ローテーション処理はサービス側が持ちます。[マネージドローテーションのドキュメント](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotate-secrets%5Fmanaged.html)によれば、ECS Service ConnectのAWS Private CA証明書も対象です。利用者はスケジュールを設定するだけで、Lambda関数のコードも実行ロールも管理せずに済みます。処理は通常1分以内に終わります。

外部SaaSのAPIキーも、マネージド外部シークレットという型に載れば関数が要りません。[統合パートナーの一覧](https://docs.aws.amazon.com/secretsmanager/latest/userguide/mes-partners.html)には、Datadog、Snowflake、Salesforce、GitLab、MongoDB Atlas、Confluent Cloud、Jenkins、Cisco、BigID、Netskope、Paddle、SonarQubeが載っています。パートナーごとに決められたフィールド構成でシークレットを作ると、作成時にローテーションが既定で有効になります。

この型から外れるのは、自前で建てたMySQLのユーザーや、一覧に無いSaaSのトークンです。そこだけがLambda関数の自作対象として残ります。マスターユーザーではなくアプリ専用ユーザーを回す構成も、自作側に入ります。データベース側の前提は[Amazon RDSとは？仕組み・対応エンジンと料金モデル・採用判断を実装者目線で解説](https://www.issoh.co.jp/tech/details/15426/)を参照してください。

### Lambda関数を4ステップで書く｜状態遷移とtestSecretの勘所

自作する場合、関数はSecrets Managerから4回呼び出され、リクエストJSONの `Step` で処理を分岐させます。順序は固定です。[ローテーション関数のドキュメント](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotate-secrets%5Flambda-functions.html)が各ステップの責務を定義しています。

1. `createSecret`：新しい値を `get_random_password` で生成し、`AWSPENDING` ラベルを付けて保存する
2. `setSecret`：生成した値をDBユーザーやSaaSの管理APIなど実リソース側へ反映する
3. `testSecret`：新しい値で実際に接続・認証できるかを読み取り権限で検証する
4. `finishSecret`：`AWSPENDING` を `AWSCURRENT` へ付け替え、旧値を `AWSPREVIOUS` に落とす

バグが表面化するのは `testSecret` の手抜きです。接続確認を省いて `finishSecret` まで進めると、誰も認証できない値が現行として配られます。AWSが[ローテーション関数テンプレートのリポジトリ](https://github.com/aws-samples/aws-secrets-manager-rotation-lambdas)を公開しているので、まず写経し、対象リソースの差分だけ書き換えるのが安全でしょう。

公式ドキュメントが挙げる注意も3つ拾っておきます。第一に、ローテーション関数は別のLambda関数を呼んで代理させられません。第二に、`setSecret` の前に現行値が有効かと、現行と新規が同じユーザー・同じホストかを確かめ、混乱した代理人攻撃の入口をふさぎます。第三に、プロビジョニング済み同時実行数を10より小さく設定すると、実行スレッド不足でスロットリングを招きます。

### シングルユーザーと交代ユーザーを選ぶ｜接続断の許容可否で決める

シングルユーザーローテーションは、1つのDBユーザーのパスワードだけを更新します。実装は単純で、AWS自身も多くの用途にはこちらを推奨する方針です。既存の接続が切られるわけではなく、DB側のパスワードが変わってからシークレットが更新されるまでのわずかな時間だけ、新しい認証情報で拒否される確率が残ります。

交代ユーザーローテーションは、権限の同じユーザーを2つ用意し、片方を更新してから切り替える方式です。最初のローテーションで関数が元ユーザーを複製するため、複製元とは別に `superuser` の認証情報を持つシークレットを渡します。切り替え後も `user` と `user_clone` の両方が有効なので、コネクションプールを持つアプリでも取りこぼしが起きにくくなります。RDS Proxyを挟む構成との相性は[RDS Proxyとは？対応エンジン・料金・接続プールの仕組みと導入手順を解説](https://www.issoh.co.jp/tech/details/6798/)で整理しました。

交代ユーザーには落とし穴も2つあります。複製後に元ユーザーの権限を変えたら、複製側にも同じ変更を入れることが必要です。RDS for MySQLでは複製名に `_clone` の6文字が付くため、元のユーザー名を26文字以内に収めておかないと、上限32文字に当たります。

### スケジュールを組む｜rate式4時間〜999日とウィンドウ1時間

スケジュールは `rate()` か `cron()` で指定します。[ローテーションスケジュールのドキュメント](https://docs.aws.amazon.com/secretsmanager/latest/userguide/rotate-secrets%5Fschedule.html)によると、`rate()` の単位は `hour` と `day` の系列だけで、間隔は最短4時間、最長999日です。ウィンドウは正時に始まり、日単位で書いた場合はUTCの深夜0時が開始点になります。

```
aws secretsmanager rotate-secret \
  --secret-id prod/billing/db \
  --rotation-lambda-arn arn:aws:lambda:ap-northeast-1:123456789012:function:RotateBillingDb \
  --rotation-rules '{"ScheduleExpression":"cron(0 16 1,15 * ? *)","Duration":"2h"}'
```

上の式は毎月1日と15日のUTC16時から2時間のウィンドウ、つまり日本時間の翌1時から3時に回す指定です。cron式にはSecrets Manager固有の制約があります。ウィンドウが正時開始のため分フィールドは0固定、1年を超える周期を許さないため年フィールドは `*` 固定。ウィンドウ長は最小1時間で、次のウィンドウに食い込まない範囲に収めます。日単位のスケジュールでは、開始時刻とウィンドウ長の合計を24時間以内にします。

タイムゾーンはUTC固定です。日本時間の深夜帯へ寄せるなら、時フィールドを9時間ずらして書きます。ローテーションが途中で失敗した場合は、開いているウィンドウの中で全体が何度か再試行されます。

## 請求額を見積もって取得回数を削る｜0.40USDの保管費より効く呼び出し

料金表は2行しかありませんが、請求額を決めるのはほぼ2行目です。

### 課金の2軸を押さえる｜1件0.40USDとAPI1万件0.05USD

課金対象は保管とAPIコールだけです。[Secrets Managerの料金ページ](https://aws.amazon.com/secrets-manager/pricing/)によると、保管は1件あたり0.40USD/月で、月の途中で作成・削除した分は時間割り。APIコールは1万件あたり0.05USDで、新しいバージョンが作られること自体に料金はかかりません。他リージョンへのレプリカは追加のシークレットとして加算され、削除予定で待機中のものは課金対象外です。

| 項目        | Secrets Manager | Parameter Store（標準） | Parameter Store（アドバンスト） |
| --------- | --------------- | ------------------- | ----------------------- |
| 保管料       | 0.40USD/件・月     | 追加料金なし              | 0.05USD/件・月             |
| APIコール    | 0.05USD/1万件     | 標準スループットは無料         | 標準スループットは無料             |
| 高スループット   | 該当なし            | 0.05USD/1万件         | 0.05USD/1万件             |
| 自動ローテーション | あり（3方式）         | なし                  | なし                      |
| 値の最大サイズ   | 65,536バイト       | 4KB                 | 8KB                     |

Parameter Store側の数字は[Systems Managerの料金ページ](https://aws.amazon.com/systems-manager/pricing/)に載っています。標準パラメータは保管もAPIも無料ですが、高スループットモードを有効にするとSecrets Managerと同じ0.05USD/1万件が発生する点だけ、比較表から落とさないでください。

### 取得回数を削る3つの手｜キャッシュ・一括取得・ローカルプロバイダ

リクエストのたびに取得する実装は、コール数が数千万件に達すると金額面で無視できなくなり、それ以上にレイテンシとスロットリングを招きます。削り方は3つあります。

- **プロセス内キャッシュ**：AWSが各言語向けのキャッシュライブラリを提供しています。起動時に1回取得し、TTL付きで保持する形が基本。
- **一括取得でまとめる**：`BatchGetSecretValue` で複数件を1回のAPIにまとめられます。レート上限が100rpsと低いため起動時処理向けです。
- **ローカルプロバイダを挟む**：同一ホスト内のプロセスでキャッシュを共有させ、外向きのAPIコールを集約します。

スロットリングが起きたときの受け方も決めておきます。公式ドキュメントは `ThrottlingException` や `RequestTimeout` を挙げ、指数バックオフとジッタを入れた再試行を推奨する内容です。SDKの既定の再試行だけに任せると、同時起動したタスクが同じ拍で叩き直して波を増幅させます。

### 月額を試算する｜20件100万回とレプリカ・無料プランの扱い方

数字を1つ置きます。シークレット20件を保管し、月100万回取得する構成なら、保管8USD＋API5USDで13USD程度。ここで取得をリクエスト単位にして月5,000万回まで膨らませると、API側だけで250USDになり、保管費との比率が逆転します。

レプリカは複製先リージョンごとに1件として加算されます。東京と大阪の2リージョンに置けば保管費は2倍です。なお2025年7月以降に作成したアカウントは、AWSの無料プランのクレジット枠でこの金額を吸収できる期間があります。検証で使った分をそのまま本番の見積もりに流用しないよう、クレジット控除前の金額で確認してください。

## Parameter Store・KMS・Vaultと比べて置き場所を決める

機密値の置き場所として競合するサービスは複数あります。役割の重なりを整理しましょう。

### SecureStringと分ける｜無料枠とローテーション有無の線引き

Parameter StoreのSecureStringもKMSで暗号化した値を保管でき、標準パラメータなら保管もAPIも無料です。[Parameter Storeのドキュメント](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-parameter-store.html)が示すとおり、決定的な差はローテーション機能を持たない点にあります。値の更新は利用者側のスクリプトやCI/CDに委ねられます。

実務では併用が現実解です。DB接続情報やAPIキーはSecrets Manager、エンドポイントURLや機能フラグはParameter Store、という分け方をします。Parameter Store側の詳細は[パラメータストアとは？AWS Parameter Storeの料金・使い方・Secrets Managerとの違いを解説](https://www.issoh.co.jp/tech/details/3412/)にまとめました。なおParameter Storeからは `/aws/reference/secretsmanager/` 形式のパス指定でシークレットを参照でき、参照系を片方のAPIへ寄せる構成も取れます。

### KMSと役割を分ける｜鍵を守る層と値を配る層の境界線と併用の前提

KMSは鍵そのものを守るサービスで、値を保管する機能を持ちません（直接暗号化できるのは4KBまでのデータに限られます）。Secrets Managerは、その鍵で値を暗号化し、バージョン管理と配布を担う上位層です。両者は競合せず、内部でKMSが呼ばれています。「KMSがあるからSecrets Managerは不要」という設計判断は成立しません。

### VaultとKey Vaultを選ぶ条件｜マルチクラウドと動的シークレット

AWS単独ならSecrets Managerで足ります。オンプレミスや他クラウドが混在し、管理を1か所へ集約したい場合は[HashiCorp Vaultとは？シークレット管理の仕組み・動的シークレット・Kubernetes連携と採用判断を実装者目線で解説](https://www.issoh.co.jp/tech/details/15580/)が候補です。Vaultは要求のたびに短命の認証情報を発行する動的シークレットを持ち、長期の値を配らない設計を取れます。Azure側に本体がある構成なら[Azure Key Vaultとは？シークレット・キー・証明書の一元管理とRBAC・Managed HSMの違いを実装者目線で解説](https://www.issoh.co.jp/tech/details/15531/)が対応します。

ただしVaultの自前運用は、それ自体が可用性とアップグレードの運用対象になります。AWSしか使っていない組織が将来のマルチクラウドに備えてVaultを建てるのは、判断として前のめりです。秘密情報の取り回しを開発プロセス側へ組み込む論点は[DevSecOpsとは？DevOpsとの違い・ライフサイクル・導入判断を実装視点で解説](/tech/details/13538/)で扱っています。

## アプリへシークレットを配る3つの実装｜SDK・プロバイダ・CSIドライバ

どこでシークレットを受け取るかで、実装とセキュリティ境界が変わります。

### SDKで起動時に1回取る｜キャッシュと認証失敗時の再取得経路の設計

最も単純なのは、アプリ起動時にSDKで `GetSecretValue` を呼び、メモリに保持する形です。前掲のboto3コードがその最小形にあたります。

弱点は、ローテーション後も古い値を掴んだままになる点にあります。DB接続エラーを捕捉したら再取得してリトライする、という復帰経路を必ず入れてください。取得はCloudTrailに記録されるため、どのロールがいつ読んだかの監査は容易です。

### ローカルプロバイダを挟む｜TTL300秒とSSRFトークンの前提

従来Secrets Manager Agentと呼ばれていたコンポーネントは、[AWS Workload Credentials Providerのドキュメント](https://docs.aws.amazon.com/secretsmanager/latest/userguide/workload-credentials-provider.html)へ改称されています（2026年9月時点で旧名称が併記され、旧URLは新ページへ転送されます）。Rust実装のOSSで、[GitHubのリポジトリ](https://github.com/aws/aws-workload-credentials-provider)でビルド済みバイナリが配られています。ローカルにHTTPサーバを立て、アプリは `http://localhost:2773/secretsmanager/get` にシークレットIDを付けて叩くだけで値を受け取ることが可能です。EC2・ECS・EKS・Lambdaに対応し、AL2023では `dnf install` でRPMから入ります。

```
[logging]
log_level = "INFO"
log_to_file = true

[capabilities.secrets_manager]
enabled = true
http_port = 2773
region = "ap-northeast-1"
max_roles = 20

[capabilities.secrets_manager.cache]
ttl_seconds = 120
cache_size = 1000

[capabilities.secrets_manager.security]
ssrf_headers = ["X-Aws-Parameters-Secrets-Token"]

[capabilities.secrets_manager.prefetch]
cache_buffer_ratio = 0.6
max_jitter_seconds = 5
secrets = [
    { secret_id = "prod/billing/db" },
]
```

上の設定を `config.toml` として渡し、アプリからはヘッダ付きで叩きます。

```
curl -s -H "X-Aws-Parameters-Secrets-Token: $(cat /var/run/awssmatoken)" \
  "http://localhost:2773/secretsmanager/get?secretId=prod/billing/db&refreshNow=true"
```

設計上の注意は4点あります。第一に、リクエストには `X-Aws-Parameters-Secrets-Token` ヘッダでSSRFトークンを付ける必要があり、無いものは拒否されます。第二に、キャッシュTTLの既定は300秒（設定可能な範囲は0〜3600秒）で、キャッシュ無効化の仕組みを持ちません。ローテーション直後は古い値が返り得るため、確実に最新が要る場面では `refreshNow=true` を付けます。第三に、プロバイダ経由の取得はCloudTrailに残りません。記録されるのはプロバイダからSecrets Managerへの呼び出しだけで、ユーザーエージェントに `aws-workload-credentials-provider` が入ります。第四に、トークンとエンドポイントが見えるホスト全体が信頼境界になるため、同居プロセスが多いホストでは粒度が粗すぎます。

2026年に入って増えた機能も2つ押さえておきます。`roleArn` クエリを付けると、STSのAssumeRoleを経由して他アカウントのシークレットを取れます（同時20ロールまで、超えると400を返して再起動まで戻りません）。起動時プリフェッチを設定すると、指定したシークレットやタグ一致のシークレットをキャッシュへ先に載せられます。

### ECSとEKSへ注入する｜valueFromとCSIドライバの使い分け

ECSではタスク定義の `secrets` に `valueFrom` でシークレットのARNを書くと、コンテナ起動時に環境変数として注入されます。末尾にJSONキーを添えると、1件の中の特定のキーだけを取り出せます。

```
"secrets": [
  {
    "name": "DB_PASSWORD",
    "valueFrom": "arn:aws:secretsmanager:ap-northeast-1:123456789012:secret:prod/billing/db-AbCdEf:password::"
  }
]
```

アプリ側はSDKもプロバイダも要りません。ただし[ECSの機密データ受け渡しドキュメント](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/specifying-sensitive-data.html)が注意するとおり、値が変わったらタスクを起動し直すか、サービスの強制デプロイをかけないと新しい値が入りません。環境変数はプロセス一覧や `docker inspect` から読める前提で扱い、漏れを避けたい場合はサイドカーで共有ボリュームへ書き出す構成に切り替えます。ECSそのものの構成は[AWS ECSとは？コンテナの仕組み・起動タイプ・料金・EKSとの違い【2026年版】](https://www.issoh.co.jp/tech/details/3870/)を参照してください。

EKSでは[Secrets Store CSIドライバ](https://secrets-store-csi-driver.sigs.k8s.io/)とAWS提供のプロバイダを組み合わせ、シークレットをボリュームとしてマウントします。ファイル経由のためローテーション時の再読み込みがしやすく、Kubernetes Secretと同期させることも可能です。[EKSのシークレット管理ドキュメント](https://docs.aws.amazon.com/eks/latest/userguide/manage-secrets.html)には、etcdのエンベロープ暗号化と合わせた設計が載っています。クラスタ側の前提は[Amazon EKSとは？仕組み・ノード提供形態と料金モデル・ECSとの使い分けを実装者目線で解説](https://www.issoh.co.jp/tech/details/15437/)にまとめました。

### クロスアカウントで配る｜roleArnとリソースポリシーの併用

共有アカウントに置いたシークレットを各環境から読む構成では、シークレット側のリソースベースポリシーで読み手のプリンシパルを列挙し、カスタマーマネージドキーのキーポリシーでも同じ主体に復号を許します。AWSマネージドキーでは復号できないため、鍵の作成が前提になります。

読み手側の経路は2つ。アプリから直接AssumeRoleして呼ぶか、ローカルプロバイダの `roleArn` に委ねるかです。前者はロールの寿命をアプリが管理し、後者はプロバイダがロールごとに独立したキャッシュを持ちます。同じシークレットでもロールが違えばキャッシュは別扱いになる点だけ、メモリ見積もりで踏まえておきます。

## 採用する条件と見送る場面を決める｜実装者が引くべき線と失敗パターン

ここからは判断です。導入すべき場面と、入れないほうがよい場面を条件付きで示します。

### 採用してよい条件｜ローテーション要件と権限分離が同時に立つ場面

次の2つが同時に成立するなら導入します。第一に、認証情報を定期的に入れ替える運用要件がある。第二に、値を読める主体をIAMやリソースポリシーで絞り、読み取り履歴を残す必要がある。RDSを使っていてマネージドローテーションが効く構成なら、実装コストはスケジュール設定だけなので迷う理由がありません。アカウントをまたいで同じ認証情報を共有する構成も、リソースベースポリシーで共有範囲を明示できるため向いています。

マネージド外部シークレットの一覧に自社で使っているSaaSが入っているかも、着手前に見ておきます。DatadogやSnowflakeのように載っていれば、Lambda関数を書く工数がまるごと消えます。

### 見送ってよい場面｜更新頻度ゼロの設定値と直せない取得実装の2つ

言い切ります。ローテーションしない値をSecrets Managerに入れるのは過剰です。エンドポイントURL、機能フラグ、外部サービスのアカウントIDのように、暗号化は要るが更新頻度がほぼゼロの値は、Parameter StoreのSecureStringで足ります。無料で、APIレートの制約も緩いためです。

もう1つ、リクエストのたびに認証情報を取りに行く実装を直せない場合も導入は見送ります。キャッシュ層を入れられないなら、移行してもレイテンシとスロットリングの問題を新たに抱えるだけです。先にキャッシュを入れてから移します。

### 失敗パターンを先に避ける｜削除の待機期間・古い値・検証漏れの3つ

実装で踏みやすい落とし穴は3つあります。[削除のドキュメント](https://docs.aws.amazon.com/secretsmanager/latest/userguide/manage%5Fdelete-secret.html)が、1つ目の根拠になります。

- **削除が即時に効かない**：削除は最短7日の待機期間を経て確定し、待機中は `RestoreSecret` で復元できます。同名で作り直すには `--force-delete-without-recovery` を使いますが、こちらは復元不可。レプリカがある主シークレットは、先にレプリカを消さないと削除できません。
- **キャッシュが古い値を返す**：ローテーション周期よりキャッシュTTLが長いと、切り替え直後に認証エラーが出ます。TTLはローテーション間隔より短く設定し、認証失敗時の再取得経路を用意します。
- **ローテーション関数の検証漏れ**：`testSecret` で接続確認をしないと、失敗した値がそのまま現行として配られます。

待機中のシークレットへアクセスが来ていないかは、CloudWatchアラームで見張れます。使われているか分からないシークレットを消すときは、待機期間をアラームの観測期間として使うと安全側に倒せます。

### 移行時に棚卸しする｜ハードコード検出から権限設計と外部委託まで

既存システムからの移行では、コードとリポジトリ履歴に残った認証情報の洗い出しが先です。[オープンソースシークレット検出ツールとして注目を集めるgitleaksとは何か？ソースコード内のシークレット検出機能と用途を徹底解説](https://www.issoh.co.jp/tech/details/10403/)のような検出ツールでコミット履歴まで走査し、対象を確定してから移します。過去のコミットに残った値は移行後もそのまま有効なので、移行と同時に無効化まで済ませてください。

移行の順序は、棚卸し→シークレット作成→取得実装の差し替え→ローテーション有効化、の4段です。3段目まで終えてから4段目に進むと、ローテーション失敗時に切り戻す先が残ります。この順序設計とIAM権限の整理をまとめて外へ出すなら、[インフラ構築（AWS・Google Cloud・Azure）](https://www.issoh.co.jp/service/system/aws/)として設計から運用手順の引き渡しまで請け負えます。

棚卸しの範囲が数十リポジトリに及ぶ場合や、移行後の権限設計まで第三者の目を入れたい場合は、[脆弱性診断・セキュリティ診断](https://www.issoh.co.jp/service/system/vulnerability/)として外部に切り出す選択肢もあります。自社で持つべきなのはローテーション後の運用手順であり、初回の洗い出しと診断を外に出しても運用が回らなくなることはありません。

## よくある質問

導入検討でよく挙がる論点をまとめます。

### AWS Secrets ManagerとParameter Storeはどちらを使うべきですか？

ローテーション要件があるならSecrets Manager、無いならParameter Storeが基準になります。標準パラメータは保管もAPIも追加料金なしで使え、SecureStringならKMSでの暗号化もできますが、値を自動で入れ替える機能はありません。DBパスワードや外部APIキーのように定期更新が要るものをSecrets Manager、更新頻度の低い設定値をParameter Storeへ置く併用が実務では扱いやすい構成です。高スループットモードを有効にした場合は、Parameter Store側にも0.05USD/1万件のAPI料金が発生します。

### Secrets Managerの料金は月にいくらかかりますか？

シークレット1件あたり0.40USD/月と、APIコール1万件あたり0.05USDです。20件を保管して月100万回取得する構成なら、保管8USD＋API5USDで13USD程度。他リージョンへのレプリカは追加のシークレットとして課金され、待機中のものは課金対象外です。金額が跳ねるのは取得回数側なので、キャッシュの有無で見積もりが変わります。

### ローテーション中にアプリケーションが認証エラーになることはありますか？

シングルユーザーローテーションでは起こり得ます。DB側のパスワードが変わってからシークレットが更新されるまでの短い時間に、新旧どちらでもない状態で接続を張り直すと拒否されるためです。ユーザーを2つ用意して交互に切り替える交代ユーザーローテーションなら、切り替え後も旧ユーザーが有効なため取りこぼしが減ります。どちらの方式でも、指数バックオフを入れた再試行と、認証失敗時に取り直す経路をアプリ側へ入れておきます。

### Lambdaやコンテナから毎回GetSecretValueを呼んでも問題ありませんか？

小規模なら動きますが、規模が増えると3つの形で跳ね返ります。API課金、取得のレイテンシ、そして10,000rpsのレート上限です。Lambdaなら実行環境の再利用を前提に初期化処理で取得してグローバルに保持する、コンテナならキャッシュライブラリかローカルプロバイダを挟む、という形へ寄せます。上限は引き上げ申請の対象外です。

### 削除したシークレットを同じ名前で作り直せますか？

通常の削除では待機期間中も名前が予約された状態になるため、同名での再作成はできません。待機中に `RestoreSecret` で復元するか、`--force-delete-without-recovery` を付けて待機なしで削除する必要があります。後者は復元できないため、本番環境では待機期間を残す運用を基本とし、検証環境の作り直しに限って即時削除を使う切り分けが安全です。

## 関連記事

- [AWS KMSとは？仕組み・料金とキーポリシー設計・採用判断を実装者目線で解説](https://www.issoh.co.jp/tech/details/15884/)：シークレットを暗号化する鍵側の設計。
- [パラメータストアとは？AWS Parameter Storeの料金・使い方・Secrets Managerとの違いを解説](https://www.issoh.co.jp/tech/details/3412/)：併用する相方の機能と料金。
- [AWS IAMとは？仕組み・ユーザー/ロール/ポリシーの違いと権限設計のベストプラクティスを実装者目線で解説](https://www.issoh.co.jp/tech/details/15427/)：読める主体を絞る権限設計。
- [Amazon RDSとは？仕組み・対応エンジンと料金モデル・採用判断を実装者目線で解説](https://www.issoh.co.jp/tech/details/15426/)：マネージドローテーションが効く前提。
- [HashiCorp Vaultとは？シークレット管理の仕組み・動的シークレット・Kubernetes連携と採用判断を実装者目線で解説](https://www.issoh.co.jp/tech/details/15580/)：マルチクラウド構成での代替候補。
- [Azure Key Vaultとは？シークレット・キー・証明書の一元管理とRBAC・Managed HSMの違いを実装者目線で解説](https://www.issoh.co.jp/tech/details/15531/)：Azure側の対応サービス。
- [オープンソースシークレット検出ツールとして注目を集めるgitleaksとは何か？ソースコード内のシークレット検出機能と用途を徹底解説](https://www.issoh.co.jp/tech/details/10403/)：移行前のハードコード棚卸し。

---

出典: [AWS Secrets Managerとは？料金・ローテーション設定と採用判断を実装者目線で解説【2026年版】](<https://www.issoh.co.jp/tech/details/15888/>)（株式会社一創）