AWS Secrets Manager: Stop Hardcoding Credentials

Why it exists

Hardcoding credentials in source code or configuration files is a massive security risk. This “secret sprawl” makes credentials difficult to track, impossible to audit, and painful to rotate. Secrets Manager was created to provide a central, secure, and auditable source of truth for application secrets.

The mental model

Think of Secrets Manager as a password vault for your applications. Instead of embedding a database password in your app's configuration, you give the application an IAM role that lets it ask the vault for the password at runtime. The vault logs every request and can even change the password automatically on a schedule, without you needing to redeploy your app.

How it works

You create a secret, which is an encrypted key-value pair, in the Secrets Manager console or via API. Your application, running with an IAM role that has been granted permission, uses the AWS SDK to call the 'GetSecretValue' API endpoint. Secrets Manager validates the IAM permissions, and if authorized, returns the decrypted secret to your application over a secure TLS connection. All access is logged in AWS CloudTrail for auditing.

When to use it

Use it to store and manage credentials your applications need at runtime. This includes database connection strings, third-party API keys, or other sensitive tokens. It is especially powerful for meeting compliance requirements like PCI DSS or HIPAA, which mandate regular credential rotation and strict access control. You can also use it to securely share secrets across multiple applications or AWS accounts.

When not to use it

Secrets Manager is not for storing large binary data; use S3 for that. It's also not a replacement for a user identity service like Amazon Cognito for managing your application's end-user passwords. For non-secret configuration data, AWS AppConfig or Systems Manager Parameter Store are better-suited and more cost-effective choices. Parameter Store can store secrets, but Secrets Manager provides advanced features like automated rotation.

One canonical example

A web application on an EC2 instance needs to access an RDS database. Instead of putting the password in a config file, you store it in Secrets Manager. The EC2 instance is assigned an IAM role granting it 'GetSecretValue' permission for that specific secret. On startup, the application code fetches the credentials from Secrets Manager and uses them to connect. You then configure a 30-day automatic rotation policy, which Secrets Manager executes without any application downtime or manual intervention.