AWS Secrets Managerの新しい推奨事項を確認してみた

Secrets Managerに設定の推奨機能が追加されたと聞いて、何を見直すように言われるのかが気になりました。特に引っかかったのは暗号化キーです。既定のキーでも暗号化されているはずなので、実際の説明を読んでみることにしました。

検証日は2026年10月5日です。東京リージョンでダミーのシークレットを1件作り、推奨事項と、その先の確認画面まで開きました。今回はAWSコンソールだけで確認できたため、ローカル環境は構築していません。掲載画像は実画面から必要な部分を切り出しています。

Secrets Managerは、パスワードやAPIキーなどを保管・管理するサービスです。2026年10月1日の発表で、AWS Recommended Actionsとの統合が案内されました。コンソール内で、シークレットの状態に応じた設定の提案を確認できます。

Recommended Actionsの説明では、リソースの状態を分析し、ユーザーデータは処理しないとされています。保存した文字列の強度を診断する機能というより、設定を見直す入口として読みました。

提供対象は、Secrets Managerを利用できるすべてのAWS商用リージョンです。推奨機能そのものに追加料金はありません。ただし、検証で作るシークレットの料金は別です。

コンソールの新しいシークレットを保存するから、その他のシークレットのタイプを選びました。実際の認証情報は使わず、キーをdemo、値をnot-a-real-secretにしています。

設定は次のとおりです。

説明欄にも、ダミー値だけを使い、アプリケーションから参照しない検証用であることを残しました。既存のシークレットの値や設定は変更していません。

ローテーションを設定しなかったのは、未設定の状態でどんな提案が出るかを見るためです。RDSやLambda、カスタマーマネージドKMSキーも、この確認のためには作成していません。

保存後にシークレットの詳細を開くと、推奨アクションボタンがありました。押すと右側にパネルが開き、今回のシークレットでは次の3件が表示されました。

コンソールの見出しは日本語ですが、提案とその説明は英語でした。発表で触れられていたローテーションと暗号化に加え、他リージョンへの複製も出たのは少し意外でした。

複製の説明には、単一リージョンの障害でシークレットにアクセスできなくなる可能性と、可用性・災害復旧への言及がありました。今回は単一リージョンで表示を確認するだけなので、レプリカは作成していません。

これは今回の設定で表示された結果です。すべてのシークレットに同じ3件が出ることや、これが推奨事項の全種類であることまでは確認していません。

Setup rotation for this secretを選ぶと、実行前の確認画面が開きました。そこにはRotation function、Rotation window、Rotation scheduleの入力欄がありました。

今回の画面では、ウィンドウに1h、スケジュールにrate(30 days)が入っていました。これは画面で確認した初期表示で、自分で保存した設定ではありません。ローテーション関数は未選択でした。

ここで気になったのは、説明がシークレットの値だけでなく、データベースやサービス側の認証情報の更新にも触れていたことです。保管している値だけを変えても、利用先と合わなくなれば接続できません。

データベース以外のシークレットのローテーション手順にも、Lambda関数の実装と、シークレット・利用先へのアクセス許可が必要だと書かれています。今回のダミー値には利用先がないため、確認画面をキャンセルしました。ローテーションの成功や、実行後に推奨が消えるところまでは検証していません。

一番確認したかったのが、カスタマーマネージドキーへの変更です。

推奨の説明は、既定のAWSマネージドキーで暗号化されていることを前提にしていました。そのうえで、キーポリシーの制御や監査の観点から、カスタマーマネージドKMSキーへの切り替えを提案しています。今回のシークレットが平文で保存されているという指摘ではありません。

ここは提案の見出しだけでは判断しにくいと感じました。Secrets Managerのベストプラクティスでは、通常の用途にはaws/secretsmanagerキーが推奨されています。一方、別アカウントからのアクセスや、暗号化キーに独自のキーポリシーを適用したい場合には、カスタマーマネージドキーを使うと説明されています。

私は、推奨が表示されたら一律にキーを変更するのではなく、アクセス制御や監査の要件と照らして判断するものだと受け止めました。

実際に提案の操作ボタンを選ぶと、Confirm: encrypt with a customer managed keyという確認画面が開きました。変更先のキーを指定する欄と、読み取り側にkms:Decryptが必要だという説明があります。

キーを切り替える前に、シークレットを読むアプリケーション側の権限も確認する必要があります。暗号化のドキュメントには、キー変更時の再暗号化と、旧キーの復号権限がない場合の挙動も説明されています。

今回は変更先のキーを作らず、この画面もキャンセルしました。キー変更後の取得や、古いバージョンへの影響までは検証していません。

検証前に確認しておきたいのは、この費用の分かれ方です。

Secrets Managerの料金ページでは、保管するシークレット数とAPI呼び出しに対して課金されます。掲載例の単価は、1シークレットあたり月額0.40 USD、API呼び出し1万回あたり0.05 USDです。短時間だけ保管する場合の時間按分の例もあります。これらは料金ページの例で、今回の検証の請求実績ではありません。

また、推奨に従ってカスタマーマネージドキーを作ればAWS KMSの料金も確認が必要です。ローテーション用Lambdaの実行や、別リージョンに作るレプリカについても、それぞれの利用料を含めて考えます。

不要になった検証用シークレットは、詳細のアクションから削除を予約できます。削除の公式手順では、復旧期間は最短7日で、削除予定のシークレットに料金はかからないとされています。即時の完全削除を使わなくても、保管料金を止められる点は覚えておきたいです。

推奨事項を開くまでの操作は短く、設定を見直す入口として使いやすいと感じました。一方で、暗号化キーの提案は説明と既存のベストプラクティスを読み合わせないと、意図を取り違えそうでした。

今回は、提案の表示と実行前の入力項目までを確認しました。次は検証用の利用先とローテーション関数を用意し、認証情報の更新後も接続できることと、推奨の表示がどう変わるかを一緒に追いたいと思います。

ここまで読んでいただき、ありがとうございます。もしこの記事の技術や考え方に少しでも興味を持っていただけたら、ネクストのエンジニアと気軽に話してみませんか。

• 選考ではありません
• 履歴書不要
• 技術の話が中心
• 所要時間30分程度
• オンラインOK

エンジニアと話してみる