Secrets Manager billing and metering
Secrets Manager usage is metered on two dimensions: stored versions and get-value API calls. Understanding both helps you estimate cost and design rotation policies.
Metered metrics
| Metric | What is metered |
|---|---|
secrets-versions (per version) | One billable line per stored revision from create/put until destroy or secret delete |
secrets-api-calls (monthly, per path) | Each successful getSecretValue in the UTC calendar month |
Stored versions
Each secret version is billed independently for its lifetime:
- Version 1 is created when you create the secret
- Each
putSecretValueadds a new billable version - Versions remain metered until destroyed or the parent secret is deleted
Version storage is billed by consumed hours, following the same model as KMS key versions.
Rotation and cost
Each rotation adds a billable version. After confirming consumers use the new value, destroy superseded versions to stop billing for old revisions. See Version management.
Get-value calls
Each successful getSecretValue in a UTC calendar month is counted per secret path. Calls are aggregated monthly per path, not per principal.
Applications that reveal secrets frequently at runtime accumulate get-value calls. Cache secrets in memory where appropriate, but balance caching against rotation and security requirements.
Cost optimisation tips
- Destroy old versions after rotation to stop version storage billing
- Delete unused secrets when paths are no longer needed
- Limit reveal frequency — cache at the application layer where safe
- Use project-scoped secrets to attribute usage to teams or workloads
Related documentation
- Version management — Destroy versions and delete secrets
- Best practices — Rotate via versions, destroy superseded revisions
- KMS billing — KMS costs from underlying encrypt/decrypt