AWSでアプリケーションを構築・運用する際、データベースの接続情報、APIキー、各種設定値などをどこで管理するかは、非常に重要な課題です。これらの情報をソースコードに直接書き込むこと(ハードコーディング)は、セキュリティやメンテナンス性の観点から避けるべきです。 この課題を解決するためにAWSが提供しているサービスとして、AWS Systems Manager Parameter Store(以下Parameter Store)とAWS Secrets Manager(以下Secrets Manager)があります。両サービスは機能的に似ている点も多く、「Parameter Storeの高性能版がSecrets Managerである」というイメージを持たれがちです 確かに、セキュリティ機能の面ではSecrets Managerが優れていますが、コスト、シンプルさ、特定のユースケースにおいては、Parameter Storeが最適な選択となる場面も少なくありません。 この記事では、両サービスを比較し、特にParameter Storeが輝くユースケースを事例とともに解説します。
- 一目でわかる!Parameter Store vs Secrets Manager 比較表
- 事例1 Public Parameterでインフラコードの鮮度を保つ
- 事例2 とりあえずの情報管理としてのSecureString活用
- 事例3 疎結合な値の受け渡し
一目でわかる!Parameter Store vs Secrets Manager 比較表
項目 | AWS Systems Manager Parameter Store | AWS Secrets Manager |
---|---|---|
主に使われている用途 | ・アプリケーションの設定値(APIエンドポイントなど) ・環境ごとの設定 ・一般的なAPIキー、ライセンスキー |
・データベースの認証情報 ・パスワード、OAuthトークンなど機密性が極めて高い情報 ・定期的な更新が必要なシークレット |
料金体系 | 【標準パラメータ】 ・パラメータ保存: 無料 (10,000個まで) ・API呼び出し: 無料 (標準スループット) 【アドバンストパラメータ】 ・パラメータごとに月額$0.05 ・API呼び出しは有料 |
・シークレットごとに月額$0.40 ・API呼び出し10,000回ごとに$0.05 (期間限定の無料利用枠あり) |
自動ローテーション | 非対応 (Lambda等で自前での実装が必要) |
ネイティブで対応 (RDS, Redshift, DocumentDBなどと連携) |
値のサイズ上限 | ・標準パラメータ 4KB ・アドバンストパラメータ 8KB |
64KB (キーと値のペアで構成されるJSON構造全体) |
アクセス制御 | IAMポリシーで制御 | IAMポリシーに加えてリソースベースのポリシーをサポートしており、クロスアカウントでの共有が容易 |
サービス特有の機能 | ・Public Parameter: AWSが提供する公開パラメータ(最新のAMI IDなど)を参照可能 ・高スループット設定: アドバンストパラメータでAPI呼び出しの上限を引き上げ可能 |
・専用SDK: シークレットの取得やキャッシュを容易にするための専用SDKを提供 ・他のAWSサービスとの強力な連携: CloudFormationでデータベースを作成する際に、認証情報を自動で生成・保存するなど |
サービスの考え方 | アプリケーションやインフラが必要とする様々な情報を効率的に共有・参照することが目的 | 絶対に外部に漏れてはならない非公開の機密情報(シークレット)を、そのライフサイクル全体(作成、ローテーション、削除)にわたって徹底的に保護・管理 |
どんな時に選ぶか | ・コストを最優先したい ・一般的な設定情報を管理したい ・自動ローテーションが不要 |
・データベース認証情報を安全に管理したい ・シークレットの自動ローテーションが必須要件 ・複数のAWSアカウントで安全にシークレットを共有したい |
2つのサービスを比較すると、Secrets Managerはその名の通り、セキュリティに特化した機能が豊富です。特に強力な機能として、主に2点が挙げられます。1つ目は、保存されたシークレット(機密情報)を自動で定期的に更新(ローテーション)する機能。2つ目は、IAMポリシーに加えてリソースベースのポリシーによるアクセス制御をサポートしている点です。
これらの機能はParameter Storeにはありません。そのため、複数のAWSアカウントにまたがって利用するクレデンシャル情報のように、特に機密性の高い情報を扱う用途では、料金は発生しますが、Secrets Managerを選択する方がセキュリティ上のメリットは大きいと言えるでしょう。このように、セキュリティが最重要視される状況では、Secrets ManagerはParameter Storeの上位互換に近い働きをします。しかし、それ以外のケースでは、次に示すようにParameter Storeにも明確な優位点があります。
Parameter Storeの最大の優位点は、まずそのコスト効率の良さにあります。 標準パラメータは10,000個まで無料で保存でき、標準スループットでのAPI呼び出しも無料です。これは、有料のSecrets Managerに対する大きなアドバンテージです。
また、コスト面だけでなく、Parameter Storeには「Public Parameter」という独自の機能があります。 これはAWSが公式に提供する読み取り専用のパラメータ群で、最新のAMI IDやサービスの推奨設定などが格納されています。ユーザーは特別な設定や料金なしにこれを自由に参照でき、例えば、常に最新のAMIからEC2インスタンスを起動するといった自動化を簡単に実現できます。
このように、両者は設計思想が異なり、どちらかが一方の劣化版ということではなく、適材適所で使い分けるべきサービスです。
では、実際にどのような場面でParameter Storeが輝くのでしょうか。ここからは、私が経験した具体的な活用事例をご紹介します。
事例1 Public Parameterでインフラコードの鮮度を保つ
AWSTemplateFormatVersion: '2010-09-09' Description: Launch an EC2 instance with the latest Amazon Linux 2023 AMI. Parameters: LatestAmiId: Type: 'AWS::SSM::Parameter::Value<AWS::EC2::Image::Id>' Description: 'Latest Amazon Linux 2023 AMI ID' # ここでパブリックパラメータのパスを指定します Default: '/aws/service/ami-amazon-linux-latest/al2023-ami-kernel-default-x86_64' Resources: EC2Instance: Type: 'AWS::EC2::Instance' Properties: InstanceType: 't3.micro' # Parametersで定義した`LatestAmiId`を参照します ImageId: !Ref LatestAmiId SubnetId: 'subnet-xxxxxxxxxxxxxxxxx' # ご自身の環境のサブネットIDを指定してください SecurityGroupIds: - 'sg-xxxxxxxxxxxxxxxxx' # ご自身の環境のセキュリティグループIDを指定してください Tags: - Key: 'Name' Value: 'My Latest AMI Instance' Outputs: InstanceId: Description: 'Instance ID of the newly created EC2 instance' Value: !Ref EC2Instance
上はPublic Parameterを用いたAmazon Linux 2023 (x86_64)のAMIを使用してEC2インスタンスを起動するCloudFormationテンプレート(YAML形式)です。x86_64形式以外にも軽量版のamiやAmazon Linux以外のUbuntuといったディストリビューションやWindowsにも対応しています。細かい内容については、Parameter StoreのPublic Parameterから確認してください。(以下の画像)
事例2 とりあえずの情報管理としてのSecureString活用
Parameter Store (SecureString) を使う場合ローテーション機能が標準実装されていないため、本格的なクレデンシャル管理には不十分な側面はありますが、Parameter Storeは値を暗号化して保管する機能を備えています。アプリケーションは必要なタイミングでこの値を安全に取得できるため、設定ファイルなどに平文でハードコーディングする場合と比較して、セキュリティを大幅に向上させることが可能です。Secrets Managerほどの高度な機能はありませんが、シークレット管理の第一歩として非常に有効な選択肢と言えるでしょう。
GUIでParameter Store暗号化するための方法
上の画像のようにタイプの部分から安全な文字列を選択することで、値の部分(登録したい情報)を暗号化することができます。
SecureStringの作成に成功するとこのようになります。
事例3 疎結合な値の受け渡し
あるCodeBuildプロジェクトの環境変数をParameter Storeに一時保存し、パイプラインの後続フェーズにある別のCodeBuildプロジェクトへ渡す構成です。
この構成を採用した一番の理由は、buildspec.yml間の密結合を避けるためです。環境変数を直接渡す方法では、2つのビルド定義の依存関係が強くなり、障害が発生した際のデバッグや修正が煩雑になりがちです。
Parameter Storeを経由させることで、以下のようなメリットが生まれます。
デバッグの容易性 AWSマネジメントコンソール(GUI)やCLIから、渡される値が正しく保存されているかを直接確認できます。これにより、問題が発生した際の原因の切り分けが格段に容易になります
高い再利用性と拡張性 Parameter Storeに保存した値はパイプラインから独立しているため、他のCodePipeline、EC2、Lambdaといった様々なサービスから一元的に参照・再利用が可能です。これは、将来的なシステムの拡張において大きな強みとなります
コスト このような一時的な値の読み書きは、無料枠の範囲で収まることがほとんどです
扱う情報は一時的で、漏洩時の影響が限定的なもの(例: ビルドハッシュ、コンテナイメージのタグ)に向いています。