AWS Secrets Managerとは?Parameter Storeとの違いと導入判断を解説

AWS運用

APIキーやDBの接続情報が、ソースコードや設定ファイル、環境変数に散らばっていないでしょうか。Webアプリケーションやバッチ処理、外部SaaS連携など、システムが増えるにつれ、認証情報はシステムごと・担当者ごとに個別管理されがちです。その結果、誰がどこで何を使っているのか把握できないまま、漏えいリスクだけが積み上がっていきます。
Parameter Storeで十分なのか、それともAWS Secrets Managerを導入すべきか。料金や監査対応まで含めて、上司に説明できる形で整理したいとお考えの方も多いのではないでしょうか。
本記事では、AWS Secrets Managerの概要からParameter Storeとの違い、設計・監査・料金・ローテーション、導入判断までを解説します。

テクノプロはAWSの構築から運用まで幅広く支援しています

Index

まず結論|AWS Secrets Managerはどのような場合に使うべきか

AWS Secrets Managerは、認証情報やAPIキーなどのシークレットを安全に保管・取得・ローテーション(定期的な入れ替え)するためのサービスです。

Parameter Store(AWS Systems Manager Parameter Store)は、AWS Systems Managerの機能の一つで、設定値やパスワードなどを階層構造のパス(例:/prod/app/db-host)で保存・取得できるサービスです。値は暗号化して保存でき(SecureStringタイプ)、標準(Standard)パラメータなら追加料金なしで使えます。一方、自動ローテーションの機能は備えていません。

導入判断では、主に次の2点を確認します。

  • ローテーションの要否:認証情報を定期的に自動更新する必要があるか
  • 共有・展開の範囲:複数のAWSアカウントやリージョンで利用する必要があるか

自動ローテーションが必要な場合や、複数のAWSアカウント・リージョンにまたがる認証情報を一元的に管理したい場合は、Secrets Managerが有力な選択肢です。一方、更新頻度が低い値や、アプリケーションの設定値を低コストで管理したい場合は、Parameter Storeで十分なことがあります。実際には、対象データの機密性、更新頻度、共有範囲、運用工数、料金を踏まえて判断します。

Secrets Managerが向いているケースと、Parameter Storeで十分なケース

自動ローテーションが必要な場合や、RDSなどのDB認証情報を扱う場合、複数アカウントでシークレットを共有する場合は、Secrets Managerが向いています。一方、更新頻度が低く、設定値に近い情報を低コストで扱いたい場合は、Parameter Storeで十分なことがあります。

  • Secrets Managerが向く場面:自動ローテーション、DB認証情報、アカウント間共有、リージョン間レプリケーション
  • Parameter Storeで十分な場面:ローテーション不要の値、環境ごとの設定値、費用を最小限にしたい用途
  • 併用する場面:設定値はParameter Store、機密性の高い認証情報はSecrets Manager

AWS Secrets Managerとは何か

AWS Secrets Manager とは、シークレットのライフサイクル(作成から更新、廃棄まで)を管理するAWSのマネージドサービスです。単なる保管場所ではなく、取得制御、暗号化、更新までを一元化できる点が特徴です。

解決できる課題と、管理できるシークレットの種類

シークレット管理が属人化すると、ハードコーディング(コードへの直接記述)や手動更新、棚卸し不足が重なり、漏えい時の影響範囲も特定できません。Secrets Managerに集約すると、アクセス権限と更新履歴を一か所で管理できます。管理できる主な対象は、次のとおりです。

  • DB認証情報:RDSやAuroraなどの接続情報
  • APIキー:外部サービスやSaaS連携で使う鍵
  • OAuthトークン:連携アプリの認可情報
  • サイズ:1つのシークレットに最大64KBまで保存可能

基本概念(Secret・Version・Stage・Rotation)

Secretは保管する機密情報の入れ物で、値が更新されるたびにVersionが作られます。各Versionには、現在値を示す「AWSCURRENT」などのStage(ステージラベル)が付き、切り替えや戻しに使われます。Rotationは、この更新を自動で行う仕組みです。

図1|Secrets Managerの基本概念

AWS Systems Manager Parameter Storeとの違い

AWS Systems Manager Parameter Storeは、設定値や機密情報を階層的に保存できるサービスです。Parameter Store 違いのポイントを、主要な観点で表にまとめます。

観点Secrets ManagerParameter Store
主な用途認証情報の管理と更新設定値と簡易な機密管理
ローテーション標準機能として提供組み込みなし。自前で実装
値の上限最大64KBStandardは4KB、Advancedは8KB
他アカウント共有リソースポリシーで共有限定的(Advancedが対象)
費用の考え方シークレット数とAPI呼び出しで課金Standardは保管料なし。Advancedは課金

機能面とセキュリティ面の違い

表のとおり、最大の差はローテーションです。Secrets ManagerはAWS Lambdaを使った自動更新をサポートし、Parameter Storeは更新処理を自前で組む必要があります。どちらもIAMで権限を絞り、AWS KMSで暗号化できますが、Secrets Managerは保存時に常に暗号化されます。

コスト・制限・用途で見る使い分け

費用だけで選ぶと、ローテーションの自作や運用の手間が後から増えます。シークレットの数が多くても、更新が不要な値はParameter Store、更新が必要な認証情報はSecrets Managerと、役割で分ける方法が現実的です。最新の仕様は公式ドキュメントでご確認ください。

導入時の基本設計

導入時は、取得方法とネットワーク経路を先に決めておきます。

アプリケーションからの取得方式とVPCエンドポイントの考え方

取得には、AWS SDKまたはAWS CLIで、実行時にAPIを呼び出す方法を使います。環境変数に値を直接入れる方法は、漏れやすく更新も難しいため、おすすめしません。

プライベートサブネットのワークロードから使う場合は、VPCエンドポイント(AWS PrivateLink)を設けると、インターネットを経由せずに接続できます。環境ごとにシークレットを分け、命名規則とタグ設計を先に決めておくと、権限や費用の管理が楽になります。

セキュリティ設計の要点(IAM・KMS・リソースポリシー)

シークレットの安全性は、保管よりも「誰が取得できるか」の設計で決まります。IAM、AWS KMS、リソースポリシーを組み合わせて考えます。

IAMは最小権限で設計する

IAMでは、取得に必要なsecretsmanager:GetSecretValueを、対象のシークレットだけに許可します。ワイルドカード指定や、管理者権限の流用は、権限過多の典型です。

  • 用途別のロール:アプリごとにIAMロールを分け、共有しない
  • 対象の限定:シークレットのARN(リソース識別子)やタグで絞る
  • 管理と利用の分離:更新・削除の権限は、取得権限と別にする

暗号化キーの選び方とクロスアカウント利用

暗号化には、AWSマネージドキーとカスタマー管理キーがあります。キーの権限を自社で制御したい場合や、他アカウントと共有したい場合は、カスタマー管理キーを選びます。AWSマネージドキーで暗号化したシークレットは、他アカウントから利用できません。マルチアカウント構成では、①シークレットのリソースポリシー、②KMSのキーポリシー、③呼び出し側アカウントのIAMポリシー(GetSecretValueとkms:Decrypt)の3点で許可する必要があります。いずれかが欠けると取得に失敗します。

図2|シークレット取得に必要な許可の関係

監査・ログ管理と運用ルール

「誰がいつ取得したか」を説明できる状態は、監査対応の前提です。記録、可視化、手順の3点を整えます。

CloudTrailで確認すべきイベントと、アラート設計

CloudTrailは、シークレットの取得、更新、削除、ローテーションのAPI操作を監査ログとして記録します。まず、GetSecretValue、PutSecretValue、DeleteSecret、RotateSecretの4つを確認対象にしてください。

Amazon CloudWatchやAmazon EventBridgeと連携すると、想定外のアクセスや削除を通知できます。Amazon GuardDutyの検知結果も併せて見ると有効です。監査対応では、ログの保管期間と確認の担当者・頻度を手順に明記します。

料金とコスト最適化

AWS Secrets Manager 料金は、保存するシークレットの数と、API呼び出しの回数が基準です。前払いや長期契約はなく、単価は変わるため、最新は公式の料金ページでご確認ください。

料金を左右する要素と、Parameter Storeとの比較ポイント

費用項目は、次の表のとおりです。

費用項目内容確認のポイント
シークレット数保存する数に応じて課金不要なものが残っていないか
API呼び出し呼び出し回数に応じて課金取得が毎回発生していないか
関連サービスKMS、VPCエンドポイント、ログ構成全体の合計で見る
Parameter StoreStandardは保管料なし本当にローテーションが不要か

比較では、単価の差だけでなく、ローテーションの自作や運用にかかる人の工数も含めて見ます。

コストを抑える設計(キャッシュ・統合・棚卸し)

取得結果をキャッシュ(一時保存)して、API呼び出しを減らします。AWSはSDK向けに、キャッシュ用のコンポーネントを提供しています。

  • 統合:関連する値は1つのシークレットにJSONでまとめる
  • 棚卸し:使われていないシークレットを定期的に削除する
  • タグ:コスト配分タグでプロジェクトごとの費用を追跡する

ローテーション設計のポイント

AWS Secrets Manager ローテーションは、シークレットを定期的に自動更新する機能で、侵害された値の有効期間を短くできます。

自動ローテーションの基本とRDS/Auroraでの検討

ローテーションは、Lambda関数が新しい値を作成し、データベース側の認証情報も更新し、検証して切り替える流れで進みます。Amazon RDSやAmazon Aurora、Amazon Redshiftなどには、対応するテンプレートが用意されており、最初に検討しやすい対象です。

図3|自動ローテーションの流れ

失敗しやすい点と、緊急ローテーション

失敗の原因で多いのは、次の3点です。

  • 接続プール:古い認証情報のまま接続が残る
  • 切替タイミング:更新直後に取得が失敗する
  • 権限不足:Lambdaが更新や検証をできない

漏えいが疑われる場合は、手動で即時にローテーションを実行し、CloudTrailで利用状況を確認します。手順は平時に決め、訓練しておくことが重要です。

導入判断と推奨ロードマップ

導入は、棚卸し、PoC、本番移行の順に、段階的に進めます。

既存シークレットの棚卸しとPoCで確認する項目

まず、APIキーやDB認証情報の保管場所、利用者、更新頻度を一覧にします。次に、影響の小さい対象でPoC(小規模な検証)を行い、次の項目を確認します。

  • 権限:最小権限で取得でき、不要な権限がないか
  • 取得:アプリから安定して取得でき、キャッシュも効くか
  • ログ:CloudTrailで操作を追跡できるか
  • 料金:想定の利用量で、費用が許容範囲か

本番移行時の注意点と、成熟度を高める指標

切り替え時は、新旧の取得方法を一定期間併存させ、戻せる手順を用意します。旧い保管場所の値は、移行後に必ず失効させます。運用が安定したら、ローテーション対象の割合、権限の見直し頻度、未使用シークレットの数を指標にします。移行計画に迷う場合は、専門家への相談も有効です。

AWS Secrets Managerでよくある質問

Parameter StoreではなくSecrets Managerを使うべきケースは何ですか?

自動ローテーションが必要な認証情報、他アカウントへの共有、DB認証情報の管理がある場合です。

Secrets Managerの料金は何で決まりますか?

保存するシークレットの数とAPI呼び出しの回数です。最新の単価は公式ページでご確認ください。

ローテーションは必ず設定すべきですか?

必須ではありませんが、DB認証情報など重要な値は優先して設定します。外部サービスのAPIキーは、相手側の仕様を確認します。

環境変数でシークレットを管理してもよいですか?

おすすめしません。漏えいしやすく、更新も難しいため、実行時にSecrets Managerから取得する方法が安全です。

まとめ|安全なシークレット管理を導入判断につなげる

AWS Secrets Managerは、APIキーやDB認証情報などのシークレットについて、保管、アクセス制御、ローテーション、監査を一元的に管理できるサービスです。Parameter Storeとの使い分けでは、ローテーションの要否や、複数のAWSアカウント・リージョンで利用する必要があるかを確認します。

IAMとAWS KMSを用いて最小権限と暗号化を設計し、AWS CloudTrailで操作履歴を確認できる状態を整えることが重要です。また、取得結果のキャッシュや定期的な棚卸しにより、API呼び出しと不要なシークレットを減らすことが、コストの最適化につながります。まずは、自社の機密情報について、保管場所、利用者、更新頻度を棚卸しし、影響の小さい対象からPoCを始めるとよいでしょう。

一方、導入時に手が止まりやすいのが、既存環境の棚卸しと移行設計です。ソースコードや設定ファイル、環境変数、各担当者が個別に管理している情報まで確認する必要があります。さらに、既存システムを停止させずにシークレットの取得方法を切り替える手順や、マルチアカウント環境におけるIAM、AWS KMS、リソースポリシーの設計も必要です。

テクノプロは、AWSアドバンストティアサービスパートナーとして、AWS認定資格の取得数が累計3,000件を超える技術者基盤を活かし、お客様の体制や課題に応じた支援を提供しています。

  • 請負・準委任:チーム体制により、シークレットの棚卸し、権限設計、移行、運用ルールの整備などを支援します。
  • 技術者派遣:AWSやセキュリティ設計の知見を持つ技術者がプロジェクトに参画し、お客様のチームと連携しながら移行を支援します。
  • 技術者教育:移行後の運用を自社で継続するために必要なAWS人材の育成を支援します。

「Parameter StoreとSecrets Managerのどちらを選ぶべきか整理したい」「現在の保管状況を棚卸しするところから相談したい」といった段階でも、テクノプロまでお気軽にご相談ください。

監修者

テクノプロ・ホールディングス株式会社

ITエンジニアとして25年のキャリアを持ち、チーフマネージャーとしてテクノプロ・エンジニアリング社にて金融・商社・製造業など多業界でのインフラ基盤構築に従事してきた。2008年から2024年まで、オンプレミス環境でのストレージ・サーバ統合基盤の設計・構築を手掛け、特に生成AI・データ利活用分野のソリューション開発実績が評価されている。現在は技術知見を活かしたマーケティング戦略を推進している。