Secrets Manager vs. Parameter Store: Which One Should You Really Use?
- Ran Isenberg
- 10 minutes ago
- 4 min read
Whenever I review a low-level design from one of my engineers and a secret is required—an API key, database credential, or any sensitive value—someone inevitably asks: Should we use AWS Secrets Manager or SSM Parameter Store (SecureString) to store it?
The answer isn’t always straightforward.
In this blog post, I’ll explain the key differences and pros and cons of the two services and share my recommendation on when to use them based on my real-world experience.
Table of Contents
Services Introduction
Let's see how AWS describes these two services:
SSM Parameter Store
Parameter Store, a tool in AWS Systems Manager, provides secure, hierarchical storage for configuration data management and secrets management - AWS
SSM Parameter Store lets you store configuration data and secrets as key-value pairs. Each parameter has a hierarchical key path (e.g., /service/env/db-password) that helps organize and scope access using IAM. The value can be a simple string, a SecureString (encrypted with KMS), or even structured data like JSON, especially when using the Advanced tier for features like versioning, larger values, and policies. Advanced parameters come with benefits such as increased quota (100,000 from 10,000) and increased size (8KB from 4KB) but at an added cost (read more about limitations and quotas here).
Secrets Manager
AWS Secrets Manager helps you manage, retrieve, and rotate database credentials, application credentials, OAuth tokens, API keys, and other secrets throughout their lifecycles - AWS
As the name suggests, AWS Secrets Manager is purpose-built to manage the full lifecycle of secrets. It offers two types of secret rotations: managed and unmanaged. The Managed secret rotation supports several AWS Database credentials, while with the non-managed secret rotation, you can write a Lambda function that implements the logic rotation. Other features include cross-region replication, versioning, and IaC support. Secrets can be as large as 64KB (I'm not sure why you'd need it, but it's an option!), much more than SSM's 4KB or 8 KB.
While it comes at a higher cost, you're paying for a more feature-rich managed solution.
But do you need all those extra features?
Am I Seeing Double?
The descriptions above are very similar in terms of secret management. However, SSM mentions configuration data management, which has a broader scope and is unrelated to secrets. It also enters the realm of dynamic configuration where AppConfig reigns supreme.
I covered AppConfig, dynamic configurations, and feature flags in my best practices series: AWS Lambda Cookbook - Part 6 - Configuration & Feature Flags Best Practices.
The Showdown
Let's compare the two services from a wide variety of aspects.
Feature | SSM Parameter Store | Secrets Manager |
Storage Cost | Standard: Free Advanced: $0.05/param/month | $0.40 per secret per month. A replica secret is considered a distinct secret and will also be billed at $0.40 per replica per month. For secrets that are stored for less than a month, the price is prorated (based on the number of hours.) |
API Cost | Standard: Free Advanced: $0.05 per 10K API calls | $0.05 per 10,000 API calls. |
Secret Rotation | No built-in rotation Custom via Lambda/EventBridge | Built-in Native RDS/Aurora support |
Encryption | Uses default KMS/CMK | Uses default KMS/CMK |
IAM Access Control | Yes | Yes |
Versioning | Standard: Only latest version Advanced: Up to 100 versions | |
Cross-Account Sharing | Role delegation | Role delegation or resource based policies |
IaC Support | Yes for regular, but not for SecureString (not safe, stored in CF template) | Full support. |
Tag Support | Yes | Yes |
Managed DB secrets integration | No | |
SDKs | ||
Cross region replication | no native support, need to implement yourself | |
Maximum size | Standard: 4 KB Advanced: 8 KB | 64KB |
Max Parameters / Secrets | Standard: 10,000 Advanced: 100,000 | 500,000 secrets per account per region |
Side note: performance is insignificant, as your secrets don't change rapidly. You should fetch and store the values in your in-memory cache to reduce API calls and boost performance.
Let's translate this table into a recommendation.
Summary - Decision Time
In the end, context matters, and it depends on what your needs and constraints are.
I've created the following cheat sheet to help you make a decision:
Use SSM Parameter Store:
For non-sensitive configs or free/low-cost parameter storage. It is ideal for cross-account or cross-stack sharing information such as IDs, ARNs, service domains via CDK or CloudFormation. This is my most common usage for SSM parameter store keys.
You need to store secrets without requiring rotation or secure IaC support. Just note: defining SecureString values inline in IaC (like CDK or CFN) will expose them.
You want to avoid the extra cost of Secrets Manager, and you can live without built-in rotation or replication.
Use Secrets Manager:
For credentials, tokens, and API keys needing one or more of the following: rotation, versioning, and cross-region support.
To get automatically managed secret rotation for Amazon RDS, Amazon Aurora, Amazon Redshift, or Amazon DocumentDB.
You can write your rotation mechanism for other use cases. Just implement the four steps of rotation as described here. This method can even replace third-party access keys.
Best suited for secure IaC usage - for example, AWS CDK or CloudFormation.
A managed secret lifecycle is worth the cost, especially in regulated and enterprise environments.
As you can see from the recommendation above, it's not always straightforward. Context matters and your constraints make a difference. Use the AWS pricing calculator - it's your friend; plan ahead!