ひとことで言うと
アプリのコードやプロンプトから、資格情報という文字列を追い出す場所です。データベース認証情報・APIキー・OAuthトークンを、動的な呼び出しで取得する形に置き換えます。
要するに、値そのものを預けるロッカーです。KMSが「鍵の使用権を貸す仕組み」なのに対し、Secrets Managerは「中身（パスワードやトークンそのもの）を預かって、必要なときだけ渡す」係です。生成AIの文脈では、Knowledge BasesがConfluence・SharePoint・Salesforceに接続するときのOAuthトークンや、サードパーティベクトルストアの認証情報が、まさにここに預けられます。
なぜ生まれたか
| Secrets Managerが無いと | 受け皿 |
|---|---|
| RAGのデータソース接続情報がコードや環境変数にハードコードされる | 実行時にAPI呼び出しで動的に取得 |
| 長期間同じ資格情報を使い続け、漏えい時の被害が長引く | 自動ローテーション（Lambda関数による定期的な入れ替え） |
| OAuthのアクセストークンが期限切れになると同期ジョブが失敗する | Confluence等のコネクタがリフレッシュトークンで自動更新（更新にはsecretsmanager:PutSecretValueが必要） |
何に使うか
| 用途 | 使い方 | 関連ドメイン |
|---|---|---|
| Knowledge BasesのConfluence/SharePoint/Salesforce連携 | OAuth2のアクセス・リフレッシュトークンを保管 | D1・D2 |
| サードパーティベクトルストア（Pinecone、Redis Enterprise Cloud） | 接続認証情報をSecrets Managerの秘密情報として保管 | D1 |
| Web Crawlerデータソースの認証 | 認証が必要なサイトのクレデンシャルを保管 | D1 |
| 資格情報の定期ローテーション | Lambda関数による自動ローテーションスケジュール設定 | D3 |
試験でどう問われるか
| 問われ方 | 正解に寄る条件 | 引っかけの選択肢 |
|---|---|---|
| Knowledge BasesをConfluenceに接続するが、OAuthトークンをどう管理するか | Secrets Managerにアクセス・リフレッシュトークンを保管し、サービスロールにGetSecretValue（更新が要る場合はPutSecretValueも）を付与 | トークンをKnowledge Baseの設定にそのまま貼り付ける |
| Confluenceの同期ジョブ中にOAuthアクセストークンが期限切れになる | リフレッシュトークンで自動的に再取得される仕組みがあるので、更新権限を渡しておけば通常は失敗しない | 手動でトークンを都度更新する運用を組む |
| サードパーティのベクトルストアに接続するための認証情報を、コード内の定数として持ちたくない | Secrets Managerで動的取得に切り替える | 環境変数に平文で置く |
| データベース認証情報を定期的に自動で入れ替えたい | Secrets Managerの自動ローテーション（Lambdaベース） | アプリの再デプロイのたびに手動で値を変える |
Secrets Managerの秘密情報を暗号化する鍵を自分でCMKに変更した場合、KMSの通常料金が別途かかります。既定のaws/secretsmanagerマネージドキーを使う限りは暗号化自体は無料です。
実務でどう使うか
- Secrets ManagerとKMSの鍵をまたぐ呼び出しは、キーポリシーの
kms:ViaService条件がsecretsmanager.<region>.amazonaws.comになっている必要があります。 S3向けの条件をそのまま流用すると復号に失敗します - 自動ローテーションはLambda関数の実行料金が別途かかります。 マネージドローテーション（AWSが管理する一部のデータベース向け）でない限り、Lambda料金を見込んでおく必要があります
- 秘密情報にはコスト配分タグが付けられます。 RAGパイプラインごとに使う秘密情報を分け、タグでコストを追跡すると運用が楽になります
削除をマークした秘密情報には課金されませんが、即座には削除されません。誤って重要な接続情報を削除マークしても、復旧できる猶予期間がある前提で運用設計するのが安全です。
取り違えやすいもの
| 迷う相手 | 切り分けの一言 |
|---|---|
| AWS KMS | Secrets Managerは値そのもの（パスワード・トークン）を預かる。KMSはその値を暗号化するための鍵を管理する。Secrets Managerの中身自体もKMSで暗号化されている親子関係 |
| AWS Systems Manager Parameter Store | Secrets Managerはローテーション機能・きめ細かいアクセス制御が前提の秘密情報向け。用途を明確に秘密情報に絞る場合の選択として位置づけられる |
| Amazon Cognito | Secrets Managerはアプリやサービスが使う資格情報の保管。Cognitoはエンドユーザー自身の認証情報・IDの管理で対象が異なる |
| IAM | Secrets Managerは秘匿な値を保管する。IAMはその値を取得する権限（GetSecretValue等）を制御する側 |
想起チェック
Q1. Knowledge BasesがConfluenceに接続する際、OAuthトークンをどこに保管し、更新にはどの権限が要る？
Secrets Managerに保管します。アクセストークンが期限切れになった際、リフレッシュトークンで再生成するため、サービスロールにsecretsmanager:GetSecretValueに加えて**secretsmanager:PutSecretValue**（更新用）が必要です。
Q2. Secrets ManagerとKMSの役割分担を一言で言うと？
Secrets Managerは秘匿な値そのものを保管・ローテーションする係、KMSはその値（や他のリソース）を暗号化するための鍵を管理する係です。Secrets Managerの秘密情報自体もKMSで暗号化されています。