AWS Secrets Manager & Parameter Store

Overview

AWS Secrets Manager and AWS Systems Manager Parameter Store are both services for managing configuration data and secrets, but they serve different purposes and have different capabilities. Understanding when to use each service is critical for the SAA-C03 exam.

AWS Secrets Manager is purpose-built for managing secrets like database credentials, API keys, and OAuth tokens. It offers automatic rotation, cross-account access, and native integration with RDS, Redshift, and DocumentDB.

AWS Systems Manager Parameter Store is a general-purpose configuration management service that can store both plain text parameters and encrypted secrets. It's simpler and more cost-effective for basic use cases.

For the exam, you must understand the key differences between these services, when to use each one, and how they integrate with other AWS services like Lambda, ECS, and RDS.

Key Concepts

AWS Secrets Manager

Secret Structure

A secret in Secrets Manager contains:

Secret Value Formats

{
  "username": "admin",
  "password": "MySecureP@ssw0rd!",
  "engine": "mysql",
  "host": "mydb.cluster-xxx.us-east-1.rds.amazonaws.com",
  "port": 3306,
  "dbname": "myapp"
}

sk-abc123xyz789secretapikey

Automatic Rotation

Secrets Manager's killer feature is automatic secret rotation:

1. CREATESET  → Lambda creates new secret version (AWSPENDING)
2. SETSET     → Lambda sets credentials in database
3. TESTSET    → Lambda tests new credentials work
4. FINISHSET  → Secrets Manager moves AWSPENDING to AWSCURRENT

Built-in Rotation Support:

• Amazon RDS (MySQL, PostgreSQL, Oracle, SQL Server, MariaDB)
• Amazon Aurora
• Amazon Redshift
• Amazon DocumentDB

AWS Systems Manager Parameter Store

Parameter Types

Parameter Tiers

Parameter Hierarchy

/environment/application/component/parameter

Examples:
/prod/myapp/database/host
/prod/myapp/database/port
/prod/myapp/api/endpoint
/dev/myapp/database/host

This hierarchy enables:

• GetParametersByPath to retrieve all parameters under a path
• IAM policies scoped to specific paths
• Environment separation (dev, staging, prod)

Secrets Manager vs Parameter Store

When to Use Secrets Manager

• Database credentials that need automatic rotation
• Cross-account secret sharing
• Secrets larger than 8 KB
• Native RDS/Redshift credential management
• Audit trail requirements for secret access

When to Use Parameter Store

• Application configuration (non-secret)
• Feature flags
• License keys (without rotation needs)
• Cost-sensitive environments
• Simple encrypted values (SecureString)
• Hierarchical configuration management

How It Works

Secrets Manager Integration

import boto3
import json
from botocore.exceptions import ClientError

def get_secret(secret_name):
    client = boto3.client('secretsmanager')

    try:
        response = client.get_secret_value(SecretId=secret_name)
        secret = json.loads(response['SecretString'])
        return secret
    except ClientError as e:
        raise e

# Usage
db_creds = get_secret('prod/myapp/database')
connection = connect(
    host=db_creds['host'],
    user=db_creds['username'],
    password=db_creds['password']
)

Parameter Store Integration

import boto3

def get_parameters(path):
    ssm = boto3.client('ssm')

    response = ssm.get_parameters_by_path(
        Path=path,
        Recursive=True,
        WithDecryption=True
    )

    params = {}
    for param in response['Parameters']:
        name = param['Name'].split('/')[-1]
        params[name] = param['Value']

    return params

# Usage
config = get_parameters('/prod/myapp/')
# Returns: {'database_host': 'xxx', 'api_key': 'yyy', ...}

CloudFormation Dynamic References

Resources:
  MyDBInstance:
    Type: AWS::RDS::DBInstance
    Properties:
      MasterUsername: '{{resolve:secretsmanager:MySecret:SecretString:username}}'
      MasterUserPassword: '{{resolve:secretsmanager:MySecret:SecretString:password}}'

Resources:
  MyFunction:
    Type: AWS::Lambda::Function
    Properties:
      Environment:
        Variables:
          DB_HOST: '{{resolve:ssm:/prod/myapp/database/host}}'
          API_KEY: '{{resolve:ssm-secure:/prod/myapp/api/key}}'

Use Cases

Use Case 1: RDS Database Credential Rotation

Scenario: Production database requires automatic credential rotation every 30 days for compliance.

Solution:

• Store RDS credentials in Secrets Manager
• Enable automatic rotation (30-day schedule)
• Use AWS-provided rotation Lambda
• Application retrieves credentials at runtime

Benefits:

• No credential in code or config files
• Automatic rotation meets compliance
• Zero downtime during rotation (multi-user strategy)

Use Case 2: Multi-Environment Configuration

Scenario: Application needs different configurations for dev, staging, and prod environments.

Solution:

• Use Parameter Store with hierarchical naming
• /dev/myapp/*, /staging/myapp/*, /prod/myapp/*
• Application reads parameters based on environment variable
• IAM policies restrict access by environment

Use Case 3: Cross-Account Secret Sharing

Scenario: Central security account manages secrets, application accounts need access.

Solution:

• Create secrets in security account
• Add resource policy allowing cross-account access
• Application accounts assume role or use direct access
• Audit all access in CloudTrail

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::123456789012:root"
      },
      "Action": [
        "secretsmanager:GetSecretValue"
      ],
      "Resource": "*"
    }
  ]
}

Use Case 4: ECS Task with Secrets

Scenario: ECS containers need database credentials injected at runtime.

Solution:

• Store credentials in Secrets Manager
• Reference secret in ECS task definition
• ECS injects as environment variables
• Container never sees raw credentials in config

{
  "containerDefinitions": [
    {
      "name": "myapp",
      "secrets": [
        {
          "name": "DB_PASSWORD",
          "valueFrom": "arn:aws:secretsmanager:us-east-1:123456789012:secret:prod/db"
        }
      ]
    }
  ]
}

Best Practices

Secrets Manager Best Practices

1. Enable automatic rotation

   • Use built-in rotation for supported databases
   • Create custom Lambda for other secrets
   • Set appropriate rotation schedule (30-90 days)

2. Use resource policies for sharing

   • Prefer resource policies over IAM for cross-account
   • Scope permissions to specific secrets
   • Audit access with CloudTrail

3. Use hierarchical secret names

   • /environment/application/component/secret
   • Enables IAM policies by path
   • Easier management at scale

4. Cache secrets in application

   • Use AWS SDK caching libraries
   • Reduces API calls and latency
   • Handle cache invalidation on rotation

5. Use customer-managed KMS keys

   • For cross-account access
   • For compliance requirements
   • Enables key policy control

Parameter Store Best Practices

1. Use SecureString for sensitive data

   • API keys, license keys, passwords
   • Encrypts with KMS at rest
   • Decrypted only when retrieved

2. Implement naming conventions

   • Consistent hierarchy across teams
   • Environment prefixes
   • Application namespacing

3. Use Advanced tier when needed

   • Parameter policies for expiration
   • Higher throughput requirements
   • Larger parameter sizes

4. Leverage GetParametersByPath

   • Retrieve all config in one call
   • Reduces API calls
   • Simplifies application code

Common Exam Scenarios

Common Pitfalls

Pitfall 1: Using Parameter Store for Rotatable Secrets

Mistake: Storing database passwords in Parameter Store when rotation is required.

• Why it fails: Parameter Store has no built-in rotation capability
• Correct approach: Use Secrets Manager for any secret requiring automatic rotation

Pitfall 2: Hardcoding Secrets in Task Definitions

Mistake: Putting database passwords directly in ECS task definitions.

• Why it fails: Secrets visible in console, CloudFormation templates, version control
• Correct approach: Reference Secrets Manager ARN in task definition secrets field

Pitfall 3: Forgetting KMS Permissions

Mistake: Granting secretsmanager:GetSecretValue but not kms:Decrypt.

• Why it fails: Secret is encrypted; retrieval fails without KMS permission
• Correct approach: Include both Secrets Manager and KMS permissions in IAM policy

Pitfall 4: Not Using Caching

Mistake: Calling GetSecretValue on every request.

• Why it fails: High latency, throttling, increased costs
• Correct approach: Use AWS SDK caching (default 1 hour) or implement custom cache

Pitfall 5: Cross-Account Without Resource Policy

Mistake: Trying to access secrets across accounts with only IAM policies.

• Why it fails: Secrets Manager requires resource policy for cross-account
• Correct approach: Add resource policy to secret allowing target account principal

Related Services

Quick Reference

Secrets Manager Pricing

Parameter Store Pricing

API Operations

IAM Policy Examples

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "secretsmanager:GetSecretValue"
      ],
      "Resource": "arn:aws:secretsmanager:*:*:secret:prod/*"
    },
    {
      "Effect": "Allow",
      "Action": [
        "kms:Decrypt"
      ],
      "Resource": "arn:aws:kms:*:*:key/key-id"
    }
  ]
}

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "ssm:GetParameter",
        "ssm:GetParameters",
        "ssm:GetParametersByPath"
      ],
      "Resource": "arn:aws:ssm:*:*:parameter/prod/*"
    }
  ]
}

Quiz Questions

Further Reading

• Secrets Manager User Guide
• Parameter Store User Guide
• Secrets Manager Rotation
• Parameter Store SecureString
• Secrets Manager vs Parameter Store