Parameter Store と Secrets Manager の違いを実務目線で整理してみた
AWSで設定値や認証情報を管理する際、
- Systems Manager Parameter Store
- AWS Secrets Manager
のどちらを使うべきか迷うことが多いです。
本記事では「機能」ではなく、現場でどう使い分けるか をまとめます。
🎯 結論（先に）
| 使い分け | サービス |
|---|---|
| APIキー・DBパスワード | Secrets Manager |
| 環境変数・設定値 | Parameter Store |
🧩 役割の違い
| 観点 | Parameter Store | Secrets Manager |
|---|---|---|
| 主用途 | 設定値管理 | 機密情報管理 |
| ローテーション | 手動 | 自動対応 |
| コスト | 安い（無料枠あり） | 高め |
| バージョン管理 | あり | あり |
| 監査ログ | CloudTrail | CloudTrail |
🔐 Secrets Managerが向いているケース
- DBパスワード
- APIシークレット
- トークン
- 外部サービス認証情報
理由
- 自動ローテーション機能
- 暗号化前提設計
- シークレット用途特化
⚙️ Parameter Storeが向いているケース
- フラグ値
- APIエンドポイントURL
- 環境設定値
- バッチ処理パラメータ
理由
- コストが安い
- 設定値の階層管理が楽
- 参照回数が多くても問題なし
💰 コスト視点
Secrets Managerは「安全な鍵金庫」
Parameter Storeは「設定ファイル置き場」
すべてSecrets Managerにするとコストが跳ねます。
🛠 実務でのベスト構成
Secrets Manager → 機密情報のみ
Parameter Store → その他設定値
❗ やりがちな失敗
| ミス | 問題 |
|---|---|
| 設定値もSecretsに入れる | コスト増 |
| パスワードをParameter Storeに平文保存 | セキュリティリスク |
🧠 設計思想の違い
- Secrets Manager = 秘密を守るためのサービス
- Parameter Store = 設定を整理するためのサービス
🏁 まとめ
違いは機能ではなく、
扱う情報の性質
で決めるのが正解でした。
設計を誤るとコストやセキュリティに直結します。