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 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: true for PutResourcePolicy actions
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:SourceVpc or Vpce to 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.