Explanation
Why the waste happens and who it affects.
Secrets are created freely by infrastructure-as-code modules, CI pipelines, database provisioning and per-environment deployments, but they are rarely removed when the application, database user or environment they belong to is retired. Over time an account accumulates secrets that no workload has retrieved in months.
Each secret is inexpensive, which is why the waste grows unnoticed: large organizations can hold thousands of stale secrets spread across accounts and Regions. Unused secrets are also a security liability, since they can still grant access to anyone with permission to read them. The AWS Config managed rule secretsmanager-secret-unused targets this condition, and its documentation notes that deleting unused secrets revokes unnecessary access and can reduce Secrets Manager cost.
Billing model
The pricing dimensions that drive this cost.
Secrets Manager charges for secrets stored and API calls made.
- Secret storage
- A fixed monthly charge per secret stored ($0.40 per secret per month in the pricing example), prorated by the hours the secret exists
- Replica secrets
- Each replica in another Region is a distinct secret billed at the same per-secret monthly rate
- API calls
- Charged per 10,000 API calls ($0.05 per 10,000 in the pricing example), including GetSecretValue and DescribeSecret requests
- Scheduled deletion
- There is no charge for secrets marked for deletion during their recovery window
How to detect
5 checks to find it in your estate.
- Enable the AWS Config managed rule secretsmanager-secret-unused, which marks a secret NON_COMPLIANT when it has not been accessed within unusedForDays (default 90 days), and aggregate results across accounts
- Run describe-secret (or list-secrets) and check LastAccessedDate; the field is omitted if the secret has never been retrieved in the Region, and ReplicationStatus shows a LastAccessedDate for each replica Region
- Check OwningService to identify secrets created and managed by other AWS services, which should be removed through the owning service rather than deleted directly
- Review CloudTrail for GetSecretValue calls on candidate secrets to identify any remaining consumers, including infrequent jobs such as quarterly reports or disaster recovery tooling
- Group candidates by tag, name prefix and creating stack to find whole sets left behind by retired environments or applications
How to fix
5 ways to remove the waste.
- Schedule deletion of confirmed unused secrets with delete-secret and a recovery window (at least 7 days); the secret becomes inaccessible immediately, is not charged while pending deletion, and can be restored with restore-secret until the deletion date
- During the recovery window, use a CloudWatch alarm on CloudTrail GetSecretValue errors for secrets marked for deletion to catch any application that still depends on them
- Remove replicas that serve no workload in their Region with remove-regions-from-replication, since each replica is billed as its own secret; a primary secret cannot be deleted until its replicas are removed
- Delete secrets that belong to infrastructure-as-code stacks by removing them from the stack, so they are not recreated on the next deployment
- Keep the Config rule active and add ownership tags to new secrets so unused secrets are flagged and routed to an owner continuously
Documentation
Vendor references for pricing and configuration.