Manage Secrets Securely in AWS with Secrets Manager (2026)

AWS Secrets Manager is a service that helps you protect secrets such as API keys, database credentials, and other sensitive information. It enables you to rotate, manage, and retrieve secrets easily, reducing the operational overhead and security risk associated with managing secrets.

Let’s see Secrets Manager in action. Imagine you have a web application running on EC2 that needs to connect to a PostgreSQL database. Instead of hardcoding the database username and password in your application’s configuration file, you can store them securely in Secrets Manager.

Here’s a simplified Python example of how your application might retrieve these credentials:

import boto3
import json

def get_secret(secret_name, region_name):
    session = boto3.session.Session()
    client = session.client(
        service_name='secretsmanager',
        region_name=region_name
    )

    try:
        get_secret_value_response = client.get_secret_value(
            SecretId=secret_name
        )
    except Exception as e:
        raise e
    else:
        if 'SecretString' in get_secret_value_response:
            secret = get_secret_value_response['SecretString']
            return json.loads(secret)
        else:
            decoded_binary_secret = base64.b64decode(get_secret_value_response['SecretBinary'])
            return decoded_binary_secret

# Example usage
secret_name = "my-postgres-credentials"
region_name = "us-east-1"

credentials = get_secret(secret_name, region_name)
db_username = credentials['username']
db_password = credentials['password']

# Now you can use db_username and db_password to connect to your database
print(f"Username: {db_username}")
# In a real application, you wouldn't print the password!
# print(f"Password: {db_password}")

This code snippet demonstrates how your application, running with appropriate IAM permissions, can call the get_secret_value API to retrieve the secret. The secret is returned as a JSON string, which is then parsed to extract the username and password.

The core problem Secrets Manager solves is the secure and centralized management of sensitive credentials and configuration data for your AWS applications and services. Traditionally, developers would embed these secrets directly into application code, configuration files, or environment variables. This approach is highly insecure because:

• Exposure Risk: Secrets can be accidentally committed to version control systems (like Git), exposed in logs, or discovered if an application instance is compromised.
• Management Overhead: Rotating credentials manually across numerous applications and services is tedious, error-prone, and often neglected, leading to stale and vulnerable secrets.
• Access Control Complexity: Granting specific, granular access to secrets to different applications or users is difficult with traditional methods.

Secrets Manager addresses these issues by providing a dedicated, secure store for your secrets. When you create a secret in Secrets Manager, you can choose to store it as a plain text string or as binary data. For common use cases like database credentials, it offers predefined templates that structure the secret as a JSON object, typically containing fields like username, password, host, and port.

The service integrates deeply with other AWS services, allowing you to grant IAM roles for your EC2 instances, Lambda functions, or ECS tasks the permission to retrieve specific secrets. This means your applications don’t need to manage AWS API credentials themselves; they can simply assume an IAM role that has secretsmanager:GetSecretValue permission for the relevant secret.

One of the most powerful features is automatic secret rotation. Secrets Manager can be configured to automatically rotate secrets for supported services like RDS databases, Redshift clusters, and DocumentDB clusters. When rotation is enabled, Secrets Manager invokes a Lambda function at a scheduled interval. This Lambda function performs the necessary steps to update the secret in the target service (e.g., changing the database password) and then updates the secret in Secrets Manager itself. This eliminates the need for manual rotation and ensures your secrets are always current and secure.

The cost of Secrets Manager is based on the number of secrets stored and the number of API requests made. For example, storing 100 secrets and making 10,000 GetSecretValue API calls per month would incur a specific cost structure. You can optimize costs by reusing secrets where appropriate and by considering the rotation schedule for your secrets.

When you configure a Lambda function to retrieve a secret, ensure its IAM execution role has a policy like this:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": "secretsmanager:GetSecretValue",
            "Resource": "arn:aws:secretsmanager:us-east-1:123456789012:secret:my-postgres-credentials-abcdef"
        }
    ]
}

This policy explicitly grants permission to GetSecretValue for a specific secret ARN, adhering to the principle of least privilege.

The next challenge you’ll likely encounter is orchestrating secret rotation for custom applications or services not directly supported by AWS’s built-in rotation capabilities.