アプリをデータベースにつなぐパスワード、外部の API を呼ぶためのキー。動かすことを優先すると、設定ファイルや環境変数に平文で書いてしまいがちです。「Secrets Manager を使うべき」とは聞くけれど、Parameter Store とどう違うのか、ローテーションとは何が起きることなのか、アプリはいつ値を取りに行くのかが分からないまま、構成図の箱だけを覚えていませんか。この記事は、秘密の値をコードの外に出す理由から始めて、2つの置き場の仕組みと選び方を、IAM と KMS の役割を分けて整理します。
この記事の結論
- パスワードや API キーをコードに書くと、コードが複製される場所すべてに秘密が広がり、変えるたびにコードの修正とデプロイが要ります。
- AWS Secrets Manager は秘密の値を保管し、ローテーション（定期的な作り直し）とアカウントやリージョンをまたぐ共有まで受け持つサービスです。
- Systems Manager Parameter Store は設定値を階層の名前で一元管理する置き場で、SecureString の型にすると KMS で暗号化して保存できます。
- どちらも、読めるかどうかは IAM のポリシーで決まり、暗号化された値を開くには KMS キーを使う許可も要ります。
- 自動のローテーションが要る認証情報は Secrets Manager、設定値と、ローテーションの要らない秘密を低い費用で置くなら Parameter Store が基本の選び方です。
パスワードや API キーをなぜコードに書かないのか
秘密の値をソースコードに書くと、困ることが3つあります。
1つ目は、秘密が広がることです。コードはリポジトリに入り、開発者の端末に複製され、ビルドの成果物やログにも残ります。コードを読める人は全員、その秘密も読めます。公開のリポジトリに一度でも上げれば、履歴から消しても取り戻せません。
2つ目は、変えにくいことです。パスワードを変えるたびにコードを直してデプロイし直すことになり、変える頻度が下がります。漏れたかもしれないと分かったときに、すぐ差し替えられません。
3つ目は、誰がいつ使ったかが分からないことです。コードの中の文字列は、読まれた記録を残しません。
AWS Secrets Manager と Parameter Store は、この3つを逆にするための置き場です。秘密はコードの外の保管庫に置き、読める人を IAM で絞り、値はアプリが実行時に取り出し、取り出した記録は CloudTrail に残ります。たとえるなら、合鍵を机の引き出しに入れておくのをやめて、鍵の保管庫に預けることです。誰が鍵を出してよいかは名簿（IAM のポリシー）で決め、鍵は定期的に作り直し（ローテーション）、使う人は必要なときに借ります。
CHECK 1ここまでの確認
アプリのデータベースのパスワードを、ソースコードの中に書かないほうがよい一番の理由は何ですか?
答えと解説
答え: 1. コードを読める人と、コードが置かれた場所すべてに秘密が広がり、変えるときにコードの修正と配布が要るから
コードはリポジトリ・ビルドの成果物・端末に複製されます。秘密もそこへ一緒に広がり、変えるたびにデプロイが要ります。「パスワードや API キーをなぜコードに書かないのか」を読み直してください。
Secrets Manager と Parameter Store とは（何を置く場所か）
AWS Secrets Manager
Secrets Manager は、データベースの認証情報・API キー・OAuth のトークンのような秘密の値を保管するためのサービスです。1つの秘密をシークレットと呼び、ユーザー名とパスワードのように複数の項目を JSON でまとめて持てます。値は KMS で暗号化して保存されます。
秘密の値のために作られているので、Parameter Store にない機能を持っています。
- 自動のローテーション（Lambda 関数による作り直し、または対応するサービスが受け持つ管理型のローテーション）
- シークレットごとのリソースポリシー（別のアカウントに読ませるときに使う）
- 別のリージョンへのレプリケーション（災害対策の側でも同じ名前で最新の値を読める）
Systems Manager Parameter Store
Parameter Store は、AWS Systems Manager の機能の1つで、設定値を /myapp/prod/db/host のような階層の名前で一元管理する置き場です。値の型は3つあります。
- String（ふつうの文字列）
- StringList（カンマ区切りの並び）
- SecureString（KMS で暗号化して保存する文字列。パスワードなどの秘密に使う）
パラメータには標準とアドバンストの2つの階層があります。公式ドキュメントでは、標準は1つの値が 4 KB まで、アカウントとリージョンごとに 10,000 個まで、追加の料金なし。アドバンストは 8 KB まで、100,000 個まで、有効期限などのパラメータポリシーが使え、料金がかかります。Parameter Store には自動のローテーションの機能はありません。
| 観点 | Secrets Manager | Parameter Store |
|---|---|---|
| 主な用途 | 秘密の値（DB の認証情報・API キー） | 設定値全般と、秘密の値（SecureString） |
| 暗号化 | 常に KMS で暗号化 | SecureString のときに KMS で暗号化 |
| 自動のローテーション | あり（Lambda 関数か管理型） | なし |
| アカウントをまたぐ共有 | リソースポリシーとカスタマー管理キーで可能 | アドバンストパラメータを AWS RAM で共有（読み取りだけ） |
| 別リージョンへの複製 | あり | リージョンごとに置く |
| 料金 | シークレットの数と API の呼び出しに応じて | 標準パラメータは追加料金なし。アドバンストは有料 |
TWO PLACES2つの置き場
作り直しまで任せるならSecrets Manager、設定をまとめるならParameter Store
Secrets Manager
秘密の値のための保管庫
- 常に KMS で暗号化
- 自動のローテーション
- リソースポリシーで別アカウントへ
- 別リージョンへ複製
Parameter Store
設定値を階層の名前で一元管理
- SecureString で KMS 暗号化
- ローテーションの機能は無い
- /myapp/prod/ のような階層
- 標準パラメータは追加料金なし
なお、Parameter Store の /aws/reference/secretsmanager/ から始まる名前で取り出すと、Secrets Manager のシークレットを Parameter Store の API で読めます。設定値の読み込みを Parameter Store にそろえたまま、秘密だけ Secrets Manager に置く、という組み方ができます。
ローテーションはどう動くのか
ローテーションは、秘密の値を定期的に新しいものに作り直し、データベースなどの側の値も同時に変えることです。漏れていたとしても、その値が使える期間を短くできます。
Secrets Manager では、ローテーションを Lambda 関数（ローテーション関数）が4つの段階で進めます。シークレットには版（バージョン）があり、どの版が今使うものかをステージングラベルという印で区別します。
ROTATIONローテーションの4段階
新しい値を作って・変えて・試してから印を移す
-
createSecret
新しい値を AWSPENDING の版で保存
-
setSecret
DB の側のパスワードを新しい値に
-
testSecret
新しい値で接続できるか試す
-
finishSecret
AWSCURRENT を新しい版へ。古い版は AWSPREVIOUS
- createSecret — 新しい値を作り、AWSPENDING の印を付けた版として保存する
- setSecret — データベースやサービスの側の認証情報を、新しい値に変える
- testSecret — 新しい値で実際に接続できるかを試す
- finishSecret — AWSCURRENT の印を新しい版へ移す。古い版には AWSPREVIOUS が付く
アプリは「AWSCURRENT の版をください」と取り出すので、ローテーションが終わった瞬間から新しい値を受け取ります。
単一ユーザーと交代ユーザー
データベースのローテーションには、2つのやり方があります。単一ユーザー方式は、1人のユーザーのパスワードを変えます。いちばん単純ですが、パスワードを変えてからシークレットが更新されるまでの短い間に、古い値での接続が断られることがあります。交代ユーザー方式は、同じ権限のユーザーを2人用意し、ローテーションのたびに交互にパスワードを変えます。切り替えの最中も、どちらかの有効な値をアプリが受け取れるので、接続が断られにくくなります。その代わり、ユーザーを複製するための権限の強いユーザーの認証情報を、別のシークレットとして用意します。
RDS などの一部のサービスは、サービスの側がローテーションを受け持つ管理型のローテーションに対応していて、その場合は Lambda 関数を自分で用意しません。
CHECK 2ここまでの確認
Secrets Manager のローテーションで、新しい値を試している途中のバージョンに付くラベルはどれですか?
答えと解説
答え: 2. AWSPENDING
新しい値は AWSPENDING の印で作られ、試し終えてから AWSCURRENT に移ります。古い値には AWSPREVIOUS が付きます。「ローテーションはどう動くのか」を読み直してください。
暗号化とアクセス制御はどこで効くのか
秘密を読めるかどうかは、2つの門で決まります。1つ目は IAM のポリシーで、シークレットやパラメータを読む操作（secretsmanager:GetSecretValue や ssm:GetParameter）が許されているか。2つ目は KMS で、値を暗号化したキーを使って復号する操作（kms:Decrypt）が許されているかです。どちらかが閉じていれば、値は取り出せません。
TWO LOCKS読み取りの門
読む許可と復号の許可がそろったときだけ値が出てくる
IAM（GetSecretValue）と KMS（Decrypt）
- 同読み取り＋復号を許可 値を受け取る同じアカウントの実行ロール
- 同読み取りだけ許可 復号できないKMS の許可が無い
- 別別アカウントのロール 許した分だけリソースポリシー＋自分のキー
- 別別アカウントのロール 読めないAWS マネージドキーのまま
KMS による暗号化
Secrets Manager のシークレットは、何も指定しなければ aws/secretsmanager という AWS マネージドキーで暗号化されます。公式ドキュメントは多くの場合このキーで足りるとしていますが、別のアカウントに読ませたいときや、キーポリシーで使える人を絞りたいときは、自分で作るカスタマー管理キーが要ります。AWS マネージドキーで暗号化したシークレットは、別のアカウントからは読めません。Parameter Store の SecureString も、同じように KMS キーで暗号化されます。KMS のキーポリシーや鍵の作り直しの仕組みは、この記事では深入りせず別の記事で扱います。
IAM でのアクセス制御
読み取りの許可は、使う側の IAM ロールに付けます。Lambda 関数なら実行ロール、ECS のタスクならタスク実行ロールかタスクロールに、必要なシークレットやパラメータだけを読む許可を付けます。Parameter Store は名前が階層になっているので、/myapp/prod/ の下だけを読ませる、という絞り方がしやすくなっています。別のアカウントのロールに読ませるときは、シークレットのリソースポリシー、カスタマー管理キーのキーポリシー、読む側の IAM のポリシーの3つで許可を揃えます。
READ ALSO — 未経験向け・段1 入口
IAM ポリシーの評価の仕組み｜許可と拒否はどの順で決まるか
CHECK 3ここまでの確認
別のアカウントのアプリにシークレットを読ませたいとき、IAM のポリシーのほかに何が要りますか?
答えと解説
答え: 1. シークレットのリソースポリシーと、カスタマー管理キーのキーポリシーでの許可
アカウントをまたぐ読み取りには、読む側の IAM のポリシーに加えて、シークレットのリソースポリシーと、暗号化に使った KMS キーの許可が要ります。AWS マネージドキーではアカウントをまたげません。「暗号化とアクセス制御はどこで効くのか」を読み直してください。
アプリはどう取り出すのか
取り出す時点を決める
アプリが値を取り出す時点は、大きく2つあります。
- 起動するときに1回だけ取り出す。ECS のタスク定義で、シークレットやパラメータを環境変数として渡す形がこれです。公式ドキュメントのとおり、あとで値がローテーションされても、動いているコンテナには届きません。新しいタスクを起動し直すまで古い値のままです。
- 使うときに取り出す。アプリが SDK で Secrets Manager や Parameter Store を呼びます。ローテーションに追随できますが、呼び出しのたびに API の呼び出し回数と待ち時間が増えます。
キャッシュで呼び出しを減らす
使うときに取り出す形では、取り出した値を一定時間だけ手元に置いておくキャッシュを挟むのが基本です。Lambda には、Secrets Manager と Parameter Store の値をキャッシュする AWS Parameters and Secrets Lambda Extension があり、関数からはローカルの HTTP で値を受け取れます。EC2・ECS・EKS・Lambda で同じ形を使いたいなら、AWS Workload Credentials Provider（旧称 Secrets Manager Agent）があります。
キャッシュの保持時間は、ローテーションの頻度と合わせて決めます。保持時間が長いと API の呼び出しは減りますが、ローテーションの直後に古い値を使い続ける時間が長くなります。交代ユーザー方式のように、切り替えの直後も古い値がしばらく有効なやり方と組み合わせると、この時間のずれで接続が断られにくくなります。
| 取り出し方 | ローテーションへの追随 | 向いている場面 |
|---|---|---|
| 起動時に環境変数で渡す | 起動し直すまで古い値 | ローテーションしない設定値、再起動を伴う更新 |
| 使うたびに SDK で取り出す | すぐに追随 | 呼び出しが少ない処理 |
| キャッシュを挟んで取り出す | 保持時間のぶん遅れる | 呼び出しが多い処理、Lambda・コンテナ |
Secrets Manager と Parameter Store はどちらを選ぶのか
迷ったときは、次の順に問いを当てると決めやすくなります。
- 自動のローテーションが要るか。データベースの認証情報を定期的に作り直したいなら Secrets Manager です。
- 別のアカウントや別のリージョンから同じ秘密を読ませたいか。そうなら Secrets Manager のリソースポリシーやレプリケーションが使えます（Parameter Store もアドバンストパラメータなら AWS RAM で別のアカウントに読み取りだけ共有できます）。
- どちらでもなく、設定値（接続先の名前・機能の切り替え・AMI の ID など）か、ローテーションの要らない秘密を低い費用で置きたいなら、Parameter Store の String や SecureString で足ります。
実際の構成では両方を使うのがふつうです。接続先やタイムアウトのような設定値は Parameter Store の階層に置き、データベースのパスワードは Secrets Manager に置いて自動でローテーションする。アプリからは Parameter Store の参照の名前でまとめて取り出す、という分け方です。
秘密の扱いでやってはいけない3つ
- パスワードや API キーをソースコード・設定ファイル・ログに平文で残す
- すべてのシークレットを読める広い許可を、アプリのロールにまとめて付ける
- ローテーションを有効にしたのに、アプリが起動時に読んだ値を使い続ける作りのままにする
Cloudory 執筆者（AWS 認定 全冠）
構成図で Secrets Manager の箱を見たら、「誰が読めるか（IAM）」「何で暗号化しているか（KMS）」「いつ取り出すか（起動時かキャッシュか）」の3つを確かめると、その構成の秘密の扱いが読めます。箱があるだけで安全になるわけではありません。
参照ソース
- What is AWS Secrets Manager?（AWS Secrets Manager ユーザーガイド） — Secrets Manager の役割と保管する秘密の種類（2026年10月時点の記載）
- Lambda rotation functions（AWS Secrets Manager ユーザーガイド） — ローテーション関数の4つの段階とステージングラベル（2026年10月時点の記載）
- Lambda function rotation strategies（AWS Secrets Manager ユーザーガイド） — 単一ユーザー方式と交代ユーザー方式の違い（2026年10月時点の記載）
- Managed rotation for AWS Secrets Manager secrets（AWS Secrets Manager ユーザーガイド） — サービスが受け持つ管理型のローテーション（2026年10月時点の記載）
- Access AWS Secrets Manager secrets from a different account（AWS Secrets Manager ユーザーガイド） — アカウントをまたぐ読み取りに要るリソースポリシー・キーポリシー・IAM のポリシーと、AWS マネージドキーが使えないこと（2026年10月時点の記載）
- Using the AWS Workload Credentials Provider（AWS Secrets Manager ユーザーガイド） — 旧 Secrets Manager Agent によるキャッシュと取り出し（2026年10月時点の記載）
- Use Secrets Manager secrets in Lambda functions（AWS Lambda デベロッパーガイド） — Lambda 拡張機能によるキャッシュと保持時間の考え方（2026年10月時点の記載）
- AWS Systems Manager Parameter Store（AWS Systems Manager ユーザーガイド） — Parameter Store の役割と SecureString（2026年10月時点の記載）
- Choosing parameter tiers in Parameter Store（AWS Systems Manager ユーザーガイド） — 標準とアドバンストの値の大きさ・個数・パラメータポリシー・料金の有無（2026年10月時点の記載）
- Working with shared parameters in Parameter Store（AWS Systems Manager ユーザーガイド） — アドバンストパラメータの AWS RAM による共有（2026年10月時点の記載）
- Referencing AWS Secrets Manager secrets from Parameter Store parameters（AWS Systems Manager ユーザーガイド） — /aws/reference/secretsmanager/ からの参照（2026年10月時点の記載）
- Pass Secrets Manager secrets through Amazon ECS environment variables（Amazon ECS デベロッパーガイド） — 環境変数で渡した値がローテーション後に自動で更新されないこと（2026年10月時点の記載）
- AWS Secrets Manager の料金 と AWS Systems Manager の料金 — 料金の形（金額は公式ページで確認。2026年10月時点）
