AWS Secrets Manager (SM) | Overview.

twtech Overvier of AWS Secrets Manager(SM)

Focus:

•        The concept: AWS Secrets Manager,
•        Secrets Manager vs SSM Parameter Store,
•        How Secrets Are Stored,
•        Secret Rotation,
•        Access Control and Security,
•        Monitoring & Auditing,
•        CloudFormation Example,
•        Best Practices,
•        Advanced Patterns,
•        Cost Optimization.

1. The concept: AWS Secrets Manager.

AWS Secrets Manager (SM) is a fully managed service for securely storing, retrieving, and rotating secrets, such as:

• Database credentials
• API keys
• OAuth tokens
• SSH keys
• Any arbitrary key-value pairs

AWS Secrets Manager (SM) integrates tightly with:

• AWS IAM (for access control)
• AWS KMS (for encryption at rest)
• AWS Lambda (for custom rotation)
• AWS CloudFormation / CDK / Terraform (for automation)

 2. Secrets Manager vs SSM Parameter Store

Feature	Secrets Manager	SSM Parameter Store
Designed for	Secrets / credentials.	Config values
Automatic rotation	✅ Yes (via Lambda).	❌ No (manual or custom)
Cross-account access	✅ Supported via Resource Policies.	✅ Supported via KMS + IAM
Native database integration	✅ RDS, Redshift, DocumentDB.	❌ No
Versioning	✅	✅
Cost	~$0.40 per secret/month + API calls.	Free for Standard, paid for Advanced
Encryption	KMS-managed.	KMS-managed

NB:

Rule of thumb:

•        Use Secrets Manager for sensitive credentials that need rotation or auditing,
•        Use Parameter Store for non-secret configurations.

 3. How Secrets Are Stored

Each secret is an encrypted JSON blob stored in a managed service:

#  json

{

  "username": "twtechadmin",

  "password": "twtechpassword-S3cr3tP@ss",

  "engine": "mysql",

  "host": "twtechdb.cluster-abc123.us-east-2.rds.amazonaws.com",

  "port": 3306

}

Encryption:

• Every secret is encrypted with AWS KMS CMK.
• twtech can use the default AWS-managed key (aws/secretsmanager) or a customer-managed CMK.
• Access to the secret requires both:
• IAM permission to the secret itself
• IAM/KMS permission to use the encryption key

 4. Secret Rotation

Secrets Manager can automatically rotate secrets using AWS Lambda.

Options:

• Built-in rotation templates (RDS, Aurora, Redshift, DocumentDB)
• Custom rotation Lambdas (for external APIs, on-prem apps, etc.)

Rotation process:

1. Secrets Manager calls the rotation Lambda.
2. Lambda creates a new secret and updates the target resource (e.g., RDS password).
3. Lambda marks the new secret version as current.
4. Optionally, old versions can be retained or deleted after a grace period.

Example:

# bash

aws secretsmanager rotate-secret \

  --secret-id twtechDatabaseSecret \

  --rotation-lambda-arn arn:aws:lambda:us-east-2:accountID:function:RotateRDSSecret \

  --rotation-rules AutomaticallyAfterDays=30

 5. Access Control and Security

Access control layers:

1. IAM policies – who can access or modify secrets
2. Resource policies – cross-account or service-based access
3. KMS policies – encryption key access
4. Encryption in transit – enforced via TLS

twtech sample IAM policy:

# json

{

  "Version": "2012-10-17",

  "Statement": [{

    "Effect": "Allow",

    "Action": ["secretsmanager:GetSecretValue"],

    "Resource": "arn:aws:secretsmanager:us-east-2:accountID:secret:prod/twtechdbpassword-*"

  }]

}

twtech sample Resource Policy (cross-account access):

# json

{

  "Version": "2012-10-17",

  "Statement": [{

    "Sid": "twtechCrossAccountAccess",

    "Effect": "Allow",

    "Principal": {"AWS": "arn:aws:iam::accountID:role/twtechCrossAccountAppRole"},

    "Action": "secretsmanager:GetSecretValue",

    "Resource": "*"

  }]

}

6. Monitoring & Auditing

Integration	Purpose
CloudTrail	Logs all secret retrieval, creation, update, and rotation events
CloudWatch Logs	For Lambda rotation logs
CloudWatch Alarms	Notify on rotation or access failures
AWS Config	Detect unrotated or unencrypted secrets

Example Config rule:
secretsmanager-scheduled-rotation-success-check

 7. CloudFormation Example

# yaml

Resources:

  MyDatabaseSecret:

    Type: AWS::SecretsManager::Secret

    Properties:

      Name: /prod/db/twtechprodpassword

      Description: "twtech Database credentials for production environment"

      KmsKeyId: arn:aws:kms:us-east-2:accountID:key/twtechkmskey-abcd1234...

      SecretString: !Sub |

        {

          "username": "twtechAdmin",

          "password": "${RandomPassword}"

        }

  RandomPassword:

    Type: AWS::SecretsManager::RandomPassword

    Properties:

      PasswordLength: 16

      ExcludeCharacters: '"@/\\'

 8. Best Practices

✅   Use customer-managed KMS keys for fine-grained control.
✅   Rotate secrets automatically every 30–60 days.
✅   Avoid embedding secrets directly in Lambda environment variables.
✅   Enable CloudTrail & AWS Config for auditing.
✅   Use naming conventions like /env/service/component/twtechsecretName.
✅   Use least privilege IAM policies with granular resource ARNs.
✅   Leverage cross-account access carefully (use Resource Policies + KMS grants).

 9. Advanced Patterns

 Cross-account Secrets Access

• Use resource-based policies on the secret.
• Grant KMS decrypt permission to the consuming account.
• Ideal for centralized secrets management in a shared services account.

 Dynamic secret generation

• Lambda rotation can dynamically generate credentials in external systems.
• Example: rotate an API key in GitHub or HashiCorp Vault.

 Secrets caching

Use the AWS Secrets Manager caching library to reduce API calls:

from aws_secretsmanager_caching import SecretCache, SecretCacheConfig

cache = SecretCache(config=SecretCacheConfig())

secret = cache.get_secret_string('prod/db/twtecchprodpassword')

 10. Cost Optimization

• Each secret: ~$0.40/month
• Each 10K API calls: ~$0.05
• Rotation adds Lambda cost