AWSで機密情報や設定値をどこに置くか。Secrets ManagerとParameter Storeは似て非なるサービスで、選定を誤ると料金と運用が両方こじれます。違いと判断軸を現場目線で整理します。
「DBパスワードやAPIキーをどこに置くか」という問いに、AWSはSecrets ManagerとSystems Manager Parameter Storeという2つの答えを用意しています。どちらも暗号化してキー・バリューを保管し、ECSやLambdaから注入できる点は共通です。しかし料金体系・自動ローテーション・サイズ上限・共有機能が異なり、「とりあえずSecrets Manager」も「全部Parameter Store」も、規模が大きくなると破綻します。本記事では両者を実務目線で切り分け、SIer/情シスの現場で迷わない判断軸を示します。
01まず結論：機密はSecrets Manager、設定値はParameter Store
細かい比較の前に、EMWが現場で使っている大原則を先に置きます。
- ローテーションが要る、または要求される秘密（DB認証情報、外部SaaSのAPIキー、証明書）は
Secrets Manager。 - ローテーションが不要な設定値（エンドポイントURL、フィーチャーフラグ、ARN、環境名、非機密のパラメータ）は
Parameter Storeの標準パラメータ。 - 機密だがローテーション不要でコストを抑えたいもの（外部から払い出された固定トークンなど）は、
Parameter StoreのSecureStringという選択肢もある。
Parameter StoreのSecureStringはKMSで暗号化され、標準パラメータなら保管料は無料です。一方でSecrets Managerは1シークレットあたり月額課金が発生します。つまり「暗号化して隠したいだけ」なら、必ずしもSecrets Managerである必要はありません。ここを取り違えると、数千件のパラメータで無駄な固定費が積み上がります。
02料金体系の違い：固定費か、ほぼ無料か
両者で最も差が出るのが料金です。数値はバージョンや改定で変わるため、必ず公式の最新を確認してください。ここでは執筆時点の考え方を示します。
- Secrets Manager：シークレット1件あたり
$0.40 / 月、API呼び出し$0.05 / 10,000コールが基本（公式料金ページ）。ローテーション機能そのものに追加料金はありませんが、Lambdaローテーションを使う場合はLambdaの実行料金がかかります。 - Parameter Store 標準パラメータ：保管料無料、標準スループットのAPI呼び出しも無料。1リージョンあたり最大10,000件。
- Parameter Store 高度パラメータ：保管料
$0.05 / パラメータ / 月。1リージョンあたり最大100,000件（Systems Manager料金ページ）。API呼び出しは高度ティア固有の課金ではなく、スループット設定に依存します。標準スループットでは標準・高度どちらのパラメータもAPI呼び出しは無料で、Higher Throughput（高スループット）を有効化した場合のみ$0.05 / 10,000 interactionsが標準・高度の両方のパラメータに課金されます。
ざっくり言えば、Parameter Storeの標準パラメータは「タダで暗号化保管できる」のが最大の武器です。逆にSecrets Managerは固定費がかかる代わりに、ローテーションやクロスアカウント参照、細かいバージョン管理といった「秘密を運用するための機能」がパッケージされています。単価は小さく見えても、シークレットが数百・数千件になると年間で無視できない差になります。
03自動ローテーション：ここがSecrets Manager最大の価値
Secrets Managerを選ぶ最大の理由は自動ローテーションです。AWS公式は、ローテーションを「秘密を定期的に更新するプロセス」と定義し、2つの方式を提供しています（Rotate secrets ドキュメント）。
- マネージドローテーション：
RDS/Aurora/Redshift/DocumentDBなど対応サービスの認証情報は、AWSがローテーションを構成・実行します。Lambda関数を用意する必要がありません。 - Lambdaローテーション：それ以外の秘密（外部APIキー等）は、ユーザーが用意（またはAWS提供テンプレートを利用）したLambda関数で秘密と接続先の両方を更新します。
Parameter Storeにはこの自動ローテーション機構がありません。ローテーションが必要な秘密をParameter Storeに置くと、更新の仕組みを自前でスケジューリング・実装することになり、結局Secrets Manager相当を再発明する羽目になります。ローテーション要件がある時点で、Secrets Managerが第一候補です。
ローテーション設計をアプリ側でどう受けるかは、DB接続の観点でRDS Proxyによる接続管理や、暗号鍵まわりのKMS暗号化設計とセットで考えると破綻しにくくなります。
04サイズ・階層・共有：見落としやすい制約
選定でつまずくのが、地味なサイズ上限と階層の非対称性です。公式ドキュメント（Managing tiers）に基づく主な違いを表にします。数値は変わり得るため最新確認を前提としてください。
注意したいのは、Parameter Storeの高度パラメータは標準に戻せない点です。公式は、標準へ戻すと8KB→4KBの切り詰めでデータ損失が起き、ポリシーが失われ、暗号化も変わるため不可としています。不要になったら削除して標準で作り直すしかありません。安易な高度パラメータ化はコストとロックインの両面で後を引きます。
05ECSへの注入：valueFrom で環境変数に渡す
コンテナへの注入は、ECSタスク定義のsecretsフィールドにvalueFromでARNを指定するのが定石です。両サービスとも同じ書式で扱え、実行ロール（executionRole）に取得権限を付けます。
- Parameter Storeなら
arn:aws:ssm:リージョン:アカウント:parameter/名前、Secrets Managerならarn:aws:secretsmanager:...:secret:名前をvalueFromに指定します。 - Secrets ManagerではJSONキー単位・バージョン単位の指定も可能です（
...:secret:名前:jsonキー:ステージ:バージョンID）。 - Fargateでフルコンテンツを環境変数に注入するにはプラットフォームバージョン
1.3.0以降が必要です（公式ドキュメント）。
タスク定義まわりの実装はECSタスク定義の実践、起動タイプの選定はFargateとEC2起動タイプもあわせてご覧ください。
06Lambdaへの注入：拡張機能でキャッシュしてコストを抑える
Lambdaから取得する場合、SDKで毎回Getすると呼び出しごとにAPI課金とレイテンシが乗ります。AWS公式のParameters and Secrets Lambda Extensionを使うと、取得値を実行環境内にキャッシュでき、API呼び出しを削減できます（AWS公式ブログ）。
- 拡張をLambdaレイヤーとして追加し、
localhost:2773のHTTPエンドポイント経由でParameter Store / Secrets Managerの値を取得します。SDK不要でGETできます。 - デフォルトのキャッシュTTLは300秒（5分）で、環境変数で調整できます。ローテーション周期とTTLの整合を取ることが重要です。
- キャッシュにより、高頻度実行のLambdaでもAPI課金とコールドな取得レイテンシを大幅に抑えられます。
ローテーション直後に古い値をキャッシュし続けると認証エラーになるため、TTLは「多少の失敗をリトライで吸収できる長さ」に設定するのが実務のバランスです。Lambda全般の作り込みはLambda本番運用の実践を参照してください。
07IAM設計：最小権限とKMSのDecryptを忘れない
どちらのサービスも、権限設計を雑にするとそこが穴になります。ポイントは3つです。
- リソース単位で絞る：
ssm:GetParameter/secretsmanager:GetSecretValueは、ワイルドカードではなく対象のARN（パスプレフィックス）に限定します。Parameter Storeは/prod/app-a/*のようなパス設計で権限を分割しやすくなります。 - KMSのDecryptを別途付与：
SecureStringやSecrets Managerでカスタマー管理キーを使う場合、対象KMSキーへのkms:Decryptが必要です。AWSマネージドキー（aws/ssm等）なら暗黙で通ることもありますが、CMK運用では明示が必須です。 - 読み取りロールと書き込みロールを分ける：アプリ実行ロールは
Get*のみ、CI/CDやIaCの適用ロールにPutParameter/PutSecretValueを持たせ、権限を職責で分離します。
クロスアカウントで秘密を参照する場合、Secrets Managerはリソースポリシー＋KMSキーポリシーの二段で許可する必要があり、設計が一段複雑になります。ここはIAM最小権限の現実やマルチアカウント統制の考え方とセットで詰めるのが安全です。
kms:Decryptがあるかを真っ先に確認します。CloudTrailでAccessDeniedのイベントソースを見れば、SSM側かKMS側かを即座に切り分けられます。08選定の決定表：迷ったらこの順で当てる
ここまでを実務のフローに落とすと、次の順で判定するのが早いです。
- ローテーションが必要 → Secrets Manager。DB認証情報ならマネージドローテーションでLambda不要。
- 機密だがローテーション不要 → Parameter Store SecureString（標準）。保管無料でコストを抑える。件数が10,000/リージョンを超える、または8KB超・クロスアカウント共有・パラメータポリシーが要るなら高度パラメータへ。
- 非機密の設定値 → Parameter Store 標準（String）。フィーチャーフラグやエンドポイントはここ。
- コンプライアンスで細かい監査・バージョン管理・きめ細かいアクセス制御が要求される機密 → Secrets Manager。固定費を払ってでも運用機能を取る。
ハイブリッド運用も現実的です。DBパスワードはSecrets Manager、その他の環境設定はParameter Store、と役割で使い分けるのが、大手エンタープライズの構成では最もバランスが良い落とし所になります。両者は同じvalueFrom書式でECSに注入できるため、混在させても運用が破綻しません。
—まとめ
Secrets ManagerとParameter Storeは競合ではなく、役割分担するサービスです。ローテーションと監査要件のある機密はSecrets Manager、それ以外の設定値・非機密はParameter Store（機密でもローテーション不要ならSecureString）という一次仕分けを起点に、料金・サイズ・階層・共有の制約を当てはめれば、大きく外しません。ECSは起動時注入・ローテーション後は再デプロイ、Lambdaは拡張機能でキャッシュ、IAMはリソース単位＋KMSのDecryptを忘れない——この4点を押さえれば、コストと運用の両方を破綻させずに済みます。数値や上限はバージョンで変わるため、実装前に必ず公式の最新を確認してください。設計レビューや既存構成の見直しはお気軽にお問い合わせください。