AWS Secrets Managerとは？料金・ローテーションと採用判断を実装者目線で解説

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

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

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

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

• 分岐点はローテーション要件の有無：値がほとんど変わらない設定値なら、Parameter Storeの標準パラメータが追加料金なしで足ります。ローテーションが要件に入った時点でSecrets Managerが優位になります。
• コストを決めるのは保管数より取得回数：1件0.40USD/月は小さな額ですが、リクエストごとに取得する実装にすると、API課金とレイテンシとスロットリングが同時に効いてきます。
• ローテーションは2方式：RDSなどのマネージドシークレットは関数を書かずに回せます。それ以外はLambda関数を自作し、4つの状態遷移を自分で実装する必要があります。
• 接続断を避けるなら交代ユーザー方式：DBユーザーを2つ用意して交互に切り替える構成でないと、切り替え直後に古い認証情報を掴んだプロセスが認証エラーを起こします。

Secrets Managerの定義と内部動作｜バージョンとステージングラベル

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

Secrets Managerの定義｜保管・取得・更新を引き受ける境界

このサービスが引き受けるのは、シークレットの保管、認可付きの取得、値の更新という3つの操作です。コードに直書きしたパスワードを、シークレット名を指定したAPIコールへ置き換えるのが基本形になります。

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

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

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

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

暗号化とKMSキーの関係｜AWSマネージドキーと専用キーの分かれ目

値の暗号化にはKMSキーが使われます。指定しなければAWSマネージドキー aws/secretsmanager が使われ、鍵の保管料は発生しません。カスタマーマネージドキーを指定すると、キーポリシーで「このシークレットを復号できる主体」を独立して縛れる代わりに、KMS側の月額とリクエスト課金が上乗せされます。

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

自動ローテーションの2方式｜マネージドローテーションとLambda関数の4ステップ

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

マネージドローテーションの対象｜関数を書かずに済むマネージドシークレット

Amazon RDS、Aurora、Redshift、DocumentDBの認証情報をSecrets Manager経由で作った場合、ローテーション処理はサービス側が持ちます。利用者はスケジュールを設定するだけで、Lambda関数のコードも実行ロールも管理せずに済みます。

逆に、外部SaaSのAPIキーや自前で建てたMySQLのユーザーはこの方式を使えません。ただし2026年には、SalesforceやSnowflakeなどサードパーティ製品の認証情報を定型フォーマットで扱うマネージド外部シークレットが発表され、自作関数が不要な範囲は広がりつつあります。

Lambdaローテーション関数の4ステップ｜4つの状態遷移と検証の勘所

自作する場合、関数はSecrets Managerから4回呼び出され、引数の Step で処理を分岐させます。順序は固定です。

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

バグが表面化するのは testSecret の手抜きです。接続確認を省いて finishSecret まで進めると、誰も認証できない値が現行として配られます。AWSがローテーション関数テンプレートを公開しているので、まず写経し、対象リソースの差分だけ書き換えるのが安全でしょう。

シングルユーザーと交代ユーザーの選び分け｜接続断の許容可否で決まる方式

シングルユーザーローテーションは、1つのDBユーザーのパスワードだけを更新します。実装は単純。ただし更新の瞬間に古いパスワードでコネクションを張り直すプロセスがあると認証に失敗します。

交代ユーザーローテーションは、権限の同じユーザーを2つ用意し、片方を更新してから切り替える方式です。切り替え後もしばらく旧ユーザーが生きているため、コネクションプールを持つアプリでも接続断が起きません。常時稼働のWeb APIや、再接続時のリトライを持たない古い業務システムでは、こちらを選びます。

ローテーションスケジュールの書式｜rate()の4時間〜999日とウィンドウ1時間

スケジュールは rate() か cron() で指定します。rate(30 days) のように日単位で書くとウィンドウはUTCの深夜0時に始まり、開始時刻を決めたいときは cron(0 18 ? * SAT *) の形で書きます。間隔は最短4時間、最長999日です。

cron式にはSecrets Manager固有の制約があります。ウィンドウが正時開始のため分フィールドは0固定、1年を超える周期を許さないため年フィールドは * 固定。ウィンドウ長は最小1時間で、次のウィンドウに食い込まない範囲に収めます。タイムゾーンはUTC固定なので、日本時間の深夜帯に寄せるなら9時間ずらして書きます。

料金の積み上がり方｜0.40USDの保管費より効いてくる取得回数

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

課金の2軸｜シークレット1件0.40USD/月とAPI1万件0.05USD

課金対象は保管とAPIコールだけです。保管は1件あたり0.40USD/月で、月の途中で作成・削除した分は日割り。APIコールは1万件あたり0.05USDで、新しいバージョンが作られること自体に料金はかかりません。他リージョンへのレプリカは追加のシークレットとして加算され、削除予定で待機中のものは課金対象外です。

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

リクエストのたびに取得する実装は、コール数が数千万件に達すると金額面で無視できなくなり、それ以上にレイテンシとスロットリングを招きます。GetSecretValue のレート上限は10,000rps、BatchGetSecretValue は100rps、CreateSecret や RotateSecret といった制御系は各50rpsで、いずれも引き上げ申請の対象外です。削り方は3つあります。

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

Parameter Store・KMS・Vaultとの違い｜寄せる範囲の境界

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

SecureStringとの分岐点｜無料枠とローテーションの有無

Parameter StoreのSecureStringもKMSで暗号化した値を保管でき、標準パラメータなら保管もAPIも無料です。決定的な差はローテーション機能を持たない点にあります。値の更新は利用者側のスクリプトやCI/CDに委ねられます。

実務では併用が現実解です。DB接続情報やAPIキーはSecrets Manager、エンドポイントURLや機能フラグはParameter Store、という分け方をします。Parameter Store側の詳細はパラメータストアとは？AWS Parameter Storeの料金・使い方・Secrets Managerとの違いを解説にまとめました。なお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連携と採用判断を実装者目線で解説が候補です。Vaultは要求のたびに短命の認証情報を発行する動的シークレットを持ち、長期の値を配らない設計を取れます。Azure側に本体がある構成ならAzure Key Vaultとは？シークレット・キー・証明書の一元管理とRBAC・Managed HSMの違いを実装者目線で解説が対応します。

ただしVaultの自前運用は、それ自体が可用性とアップグレードの運用対象になります。AWSしか使っていない組織が将来のマルチクラウドに備えてVaultを建てるのは、判断として前のめりです。

取得実装の3パターン｜SDK・ローカルプロバイダ・CSIドライバ

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

SDK直呼びとキャッシュ｜起動時1回に寄せる基本形と復帰経路

最も単純なのは、アプリ起動時にSDKで GetSecretValue を呼び、メモリに保持する形です。必要な権限は secretsmanager:GetSecretValue と secretsmanager:DescribeSecret の2つで、IAMロールに絞って付与します。

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

ローカルプロバイダ経由の取得｜TTL300秒とSSRFトークンの前提

従来Secrets Manager Agentと呼ばれていたコンポーネントは、公式ドキュメント上でAWS Workload Credentials Providerへ改称されています（2026年7月時点の記載）。Rust実装のOSSで、ローカルにHTTPサーバを立て、アプリは http://localhost:2773/secretsmanager/get にシークレットIDを付けて叩くだけで値を受け取れます。EC2・ECS・EKS・Lambdaに対応。

設計上の注意は3点あります。第一に、リクエストには X-Aws-Parameters-Secrets-Token ヘッダでSSRFトークンを付ける必要があり、無いものは拒否されます。第二に、キャッシュTTLの既定は300秒で、キャッシュ無効化の仕組みを持ちません。ローテーション直後は古い値が返り得るため、確実に最新が要る場面では refreshNow=true を付けます。第三に、プロバイダ経由の取得はCloudTrailに残りません。記録されるのはプロバイダからSecrets Managerへの呼び出しだけです。プロセス単位で読み取りを監査したい環境では、この点が要件と衝突します。

ECS・EKSでの注入｜valueFromとCSIドライバの使い分け

ECSではタスク定義の secrets に valueFrom でシークレットのARNを書くと、コンテナ起動時に環境変数として注入されます。アプリ側はSDKもプロバイダも要りません。ただし環境変数はプロセス一覧やコアダンプから読める前提で扱うべきで、ローテーション時にはタスクの再デプロイが要ります。

EKSではSecrets Store CSIドライバとAWS提供のプロバイダを組み合わせ、シークレットをボリュームとしてマウントします。ファイル経由のためローテーション時の再読み込みがしやすく、Kubernetes Secretと同期させることも可能です。

Secrets Managerを採用する条件と見送る場面｜実装者が引くべき線

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

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

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

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

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

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

失敗パターン｜削除の待機期間・キャッシュ由来の古い値・検証の省略

実装で踏みやすい落とし穴は3つあります。

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

移行時の棚卸しと外部委託の線引き｜ハードコード検出から権限設計まで

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

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

よくある質問

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

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

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

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

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

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

シングルユーザーローテーションでは起こり得ます。切り替わった直後に古い値でコネクションを張り直すプロセスがあると失敗するためです。ユーザーを2つ用意して交互に切り替える交代ユーザーローテーションなら、切り替え後も旧ユーザーが有効なため接続断を避けられます。加えて、認証失敗時に再取得してリトライする経路をアプリ側へ入れておきます。

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

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

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

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

関連記事

• AWS KMSとは？仕組み・料金とキーポリシー設計・採用判断を実装者目線で解説：シークレットを暗号化する鍵側の設計。
• パラメータストアとは？AWS Parameter Storeの料金・使い方・Secrets Managerとの違いを解説：併用する相方の機能と料金。
• HashiCorp Vaultとは？シークレット管理の仕組み・動的シークレット・Kubernetes連携と採用判断を実装者目線で解説：マルチクラウド構成での代替候補。
• Azure Key Vaultとは？シークレット・キー・証明書の一元管理とRBAC・Managed HSMの違いを実装者目線で解説：Azure側の対応サービス。
• オープンソースシークレット検出ツールとして注目を集めるgitleaksとは何か？ソースコード内のシークレット検出機能と用途を徹底解説：移行前のハードコード棚卸し。