10 Best Practices for AWS Secrets Manager [Cheat Sheet]
In a prior post, we learned about AWS Secrets Manager: what it is, why it’s used, and how to get started with it. In this…
In a prior post, we learned about AWS Secrets Manager: what it is, why it’s used, and how to get started with it.
In this post, let’s talk about 10 best practices you should follow if you’re using AWS Secrets Manager in production.
Prefer graphics? We’ve got a downloadable cheat sheet below.
Best Practices Checklist
1- Store credentials and other sensitive information in AWS Secrets Manager
Sounds obvious, but move secrets out of things like environment variables, local files, or wherever else they are hardcoded and/or accessible in plaintext. This is the whole point of using Secrets Manager, so it’s #1 on the list! To get to this point, let’s look at #2.
2- Find unprotected secrets in your code
There are different tools that help with this, but you will need an inventory of what all you have. For Java and Python code, you can use Amazon CodeGuru Reviewer since it integrates with AWS Secrets Manager. Otherwise, check out 3rd party solutions. At this stage, you’re primarily looking for:
- Hardcoded passwords
- Database connection strings
- Usernames
- API keys
- Etc…
3- Choose an encryption key for your secrets
Secrets Manager uses KMS to encrypt data. You can use the AWS-managed KMS key (aws/secretsmanager) to encrypt your secrets at no extra cost.
There are cases when you may want to use your own key instead. It gives you more control over who/what can access the secret, since they need access to the key to decrypt the secret. It also enables you to access the secret from another AWS account. The consideration here, of course, is extra cost.
4- Use caching to retrieve secrets
Instead of constantly having to call the remote Secrets Manager API each time you need to access a secret, you can cache secret values and only update them when necessary.
There’s an AWS Secrets Manager Agent that helps with certain services like Lambda, ECS, EC2, and EKS. Otherwise, you can import AWS libraries for the language of your choice. See footnote [1] for more information.
5- Mitigate risks of using the CLI
Issuing secrets in plaintext for CLI commands can expose them to potential compromise. For recommendations of how to mitigate this risk, see this documentation for more information.
6- Rotate secret values on a regular schedule
Secret rotation can (and should be) automated, and it’s one of the benefits of using a service like Secrets Manager. You can hook it up to a Lambda function that will rotate the secret value in both Secrets Manager and the service needing the secrets (ie: your database).
If you instead use ‘managed secrets’ for services like Aurora, ECS, RDS, or Redshift, then you don’t need to use a Lambda function. AWS takes care of the rotation for you — just set how frequently you want it to happen.
7- Limit access to secrets
There are multiple approaches to limiting access to your secrets stored in Secrets Manager:
- Block broad access to secrets – use
BlockPublicPolicy: trueforPutResourcePolicyactions - Use caution with IP address conditions in policies – IP filters will block the AWS-internal address space, preventing services like Lambda, causing secrets rotation to fail
- Limit requests with VPC endpoint conditions – use
aws:SourceVpcorVpceto limit requests from VPCs and endpoints. However remember that some AWS Services can’t run with endpoints
8- Replicate secrets
While it will increase your cost, you can replicate secrets across regions if you need greater resiliency and disaster recovery, or lower latency. Enabled rotation will auto-apply to all replicas.
9- Monitor secrets
There are multiple AWS-native ways that you can monitor your secrets and the Secrets Manager service:
- Log events with CloudTrail
- Monitor Secrets Manager with CloudWatch
- Monitor secrets for compliance with AWS Config
- Monitor costs with CloudWatch and Cost Anomaly Detection
- Detect threats with GuardDuty
10- Run on private networks
Whenever possible, establish private connections between Secrets Manager and your services housed in VPCs by creating interface VPC endpoints. This routes traffic through AWS’ private networks which means it will never go through the public Internet as long as it’s properly configured. More info on how to properly configure here.
Downloadable cheat sheet
Best Practices for AWS Secrets Manager
What is Secrets Manager, and why use it?
AWS Secrets Manager securely stores and manages sensitive information such as passwords, database credentials, and API keys. Instead of hardcoding credentials in your code, your apps can request them from Secrets Manager when needed. It handles encryption, controls who can access each secret, and can automatically rotate credentials on a schedule.
Best Practices Checklist
Store credentials and other sensitive information in AWS Secrets Manager
Sounds obvious, but move secrets out of things like environment variables, local files, or wherever else they are hardcoded and/or accessible in plaintext. This is the whole point of using Secrets Manager, so it’s #1 on the list! To get to this point, let’s look at #2.
Find unprotected secrets in your code
There are different tools that help with this, but you will need an inventory of what all you have. For Java and Python code, you can use Amazon CodeGuru Reviewer since it integrates with AWS Secrets Manager. Otherwise, check out 3rd party solutions. At this stage, you’re primarily looking for:
- Hardcoded passwords
- Database connection strings
- Usernames
- API keys
- Etc…
Choose an encryption key for your secrets
Secrets Manager uses KMS to encrypt data. You can use the AWS-managed KMS key (
aws/secretsmanager) to encrypt your secrets at no extra cost.There are cases when you may want to use your own key instead. It gives you more control over who/what can access the secret, since they need access to the key to decrypt the secret. It also enables you to access the secret from another AWS account. The consideration here, of course, is extra cost.
Use caching to retrieve secrets
Instead of constantly having to call the remote Secrets Manager API each time you need to access a secret, you can cache secret values and only update them when necessary.
There’s an AWS Secrets Manager Agent that helps with certain services like Lambda, ECS, EC2, and EKS. Otherwise, you can import AWS libraries for the language of your choice. See footnote [1] for more information.
Mitigate risks of using the CLI
Issuing secrets in plaintext for CLI commands can expose them to potential compromise. For recommendations of how to mitigate this risk, see footnote [2] for more information.
Rotate secret values on a regular schedule
Secret rotation can (and should) be automated, and it’s one of the benefits of using a service like Secrets Manager. You can hook it up to a Lambda function that will rotate the secret value in both Secrets Manager and the service needing the secrets (ie: your database).
If you instead use ‘managed secrets’ for services like Aurora, ECS, RDS, or Redshift, then you don’t need to use a Lambda function. AWS takes care of the rotation for you -- just set how frequently you want it to happen.
Limit access to secrets
- Block broad access to secrets - use
BlockPublicPolicy: trueforPutResourcePolicyactions - Use caution with IP address conditions in policies - IP filters will block the AWS-internal address space, preventing services like Lambda, causing secrets rotation to fail
- Limit requests with VPC endpoint conditions - use
aws:SourceVpcorVpceto limit requests from VPCs and endpoints. However remember that some AWS Services can’t run with endpoints
- Block broad access to secrets - use
Replicate secrets
While it will increase your cost, you can replicate secrets across regions if you need greater resiliency and disaster recovery, or lower latency. Enabled rotation will auto-apply to all replicas.
Monitor secrets
There are multiple AWS-native ways that you can monitor your secrets and the Secrets Manager service:
- Log events with CloudTrail
- Monitor Secrets Manager with CloudWatch
- Monitor secrets for compliance with AWS Config
- Monitor costs with CloudWatch and Cost Anomaly Detection
- Detect threats with GuardDuty
Run on private networks
Whenever possible, establish private connections between Secrets Manager and your services housed in VPCs by creating interface VPC endpoints. This routes traffic through AWS’ private networks which means it will never go through the public Internet as long as it’s properly configured. [3]
Secrets Manager vs. SSM Parameter Store
Parameter Store: Choose it for configuration values, feature flags, and simple secrets stored as SecureString when you don’t need built-in rotation. Standard parameters have no storage charge; advanced parameters and higher-throughput API usage cost extra.
Secrets Manager: Choose it for secrets that need automated rotation, managed database credentials, or multi-region replication. You pay per secret and for API calls; replicas add cost.
Rule of thumb: Parameter Store for configuration + simple secrets; Secrets Manager for secrets that need automation or are highly sensitive, since it provides more security controls out of the box.
Use this cheat sheet with AI
Copy a ready-to-use prompt into your preferred AI assistant.
