Macie & Secrets Manager
Find sensitive data; rotate secrets by identity.
You cannot protect sensitive data you do not know you have, and you cannot rotate a credential that lives in a config file. Macie answers the first problem; Secrets Manager answers the second. Together they turn "data and secrets sprawl" into governed, monitored resources.
Know where sensitive data lives
Amazon Macie uses managed and custom data identifiers to discover and classify sensitive data — PII, credentials, financial data — across your S3 estate, and flags buckets that hold it while being public, unencrypted, or shared externally. That inventory is what lets you apply the right controls to the right buckets instead of guessing, and it feeds Security Hub so sensitive-data risk sits alongside your other findings.
# App reads the secret at startup via its task/instance role — nothing in the# image, env file, or repo. Every GetSecretValue is logged in CloudTrail.DB_URL=$(aws secretsmanager get-secret-value \--secret-id prod/api/db --query SecretString --output text)# Rotation is owned by the manager: a Lambda creates a NEW credential on the# backend, tests it, promotes it (AWSCURRENT), and retires the old one.aws secretsmanager rotate-secret --secret-id prod/api/db \--rotation-lambda-arn arn:aws:lambda:eu-west-1:222222222222:function:rotate-db \--rotation-rules AutomaticallyAfterDays=30
Secrets as governed resources
Secrets Manager gives each secret fine-grained IAM, KMS encryption, versioning, automatic rotation, and an audit event on every retrieval — everything a KMS-encrypted config file lacks. Workloads fetch at runtime by identity, so access can be revoked centrally without a redeploy, and rotation is a scheduled backend job rather than a manual scramble. Use the dual-secret overlap pattern on rotation so consumers refresh within the window before the old credential is retired.