Overview
Identify AWS Secrets Manager secrets that have not been used for at least 90 days and safely clean them up. The plan helps you inventory and analyze secrets usage, review and approve candidates for deletion, schedule deletion with appropriate recovery windows, and then verify that everything was configured correctly.
By following these phases, you can reduce security risk and cost by removing stale secrets, while keeping tight control over what is deleted and ensuring that there is a recovery period for rollbacks if needed.
Execution Details
Assessment
In this phase, you build a complete picture of your Secrets Manager usage and identify which secrets appear unused.
Inventory secrets and last accessed details
- Define the scope of secrets to evaluate, such as all secrets in the account, specific Regions, or those matching particular tags or name patterns.
- Retrieve the list of in-scope secrets and capture key metadata for each one: name, full ARN, Region, description, creation date, and current status (active or already scheduled for deletion).
- Record usage details, especially the last accessed date and time (when available), and note whether automatic rotation is enabled along with any rotation configuration.
- Collect relevant tags that might influence deletion decisions, such as environment, owner, or compliance classifications.
- Store this inventory in a structured format (for example, a table or JSON document) for use in later steps.
Identify secrets unused for 90+ days
- Use the current date as the reference point to determine how long it has been since each secret was last accessed.
- For each secret, calculate the number of days since its last accessed date, when that data exists.
- Decide how to handle secrets with no recorded last accessed date, such as treating them as unused, flagging them for manual review, or handling them under a separate policy.
- Filter out secrets that are already scheduled for deletion and, optionally, those tagged as permanent, compliance-related, or otherwise protected by organizational policy.
- Produce a refined list of secrets that meet the “unused for 90+ days” criteria, including their identifiers, Regions, last accessed dates, and any notable tags or notes.
- Store this candidate list for user review in the next step.
User review and approval for deletion
- Present you with the list of secrets identified as unused for 90+ days, including name or ARN, Region, last accessed date, rotation status, and relevant tags.
- Clearly highlight secrets that have never been accessed or that lack last accessed information, as well as those that appear to be associated with critical environments or applications based on tags or naming conventions.
- Guide you through selecting which unused secrets should be scheduled for deletion.
- Allow you to mark specific secrets as exceptions that must not be deleted, optionally capturing the reason (for example, regulatory requirement or pending application migration).
- For each secret approved for deletion, capture the desired recovery window in days within the supported range (for example, 7–30 days), or apply a standard default if you do not specify one.
- Produce and store a final, user-approved deletion list, including ARNs, Regions, and chosen recovery windows, to drive the configuration phase.
Configuration
In this phase, the approved unused secrets are scheduled for deletion with appropriate safeguards.
Schedule deletion of approved unused secrets
- Take the user-approved list of secrets, including their ARNs, Regions, and selected recovery windows.
- For each secret, confirm it is not already scheduled for deletion and that the requested recovery window falls within the allowed range, adjusting to a valid value if required by organizational policy.
- Schedule deletion for each approved secret with the specified or adjusted recovery window so that you have time to recover the secret if needed.
- If a secret cannot be scheduled for deletion due to invalid state or other issues, record the error and continue processing the rest.
- After scheduling, retrieve updated metadata to confirm that each targeted secret now has a deletion date set and is marked as pending deletion.
- Generate a summary listing all secrets successfully scheduled for deletion, along with those that failed and the reasons for any failures.
Validation
In this final phase, you verify that secrets are correctly scheduled for deletion and identify any items needing follow-up.
Validate secrets are scheduled for deletion
- Retrieve metadata for all secrets that were requested for deletion in the configuration phase.
- Confirm that each secret is in a pending deletion state and has a deletion date set.
- Check that the deletion date aligns with the expected recovery window calculated from the scheduling date for each secret.
- Identify any secrets from the approved deletion list that are not in the expected pending deletion state.
- Document discrepancies, including known or suspected causes like earlier failures or manual configuration changes, and outline any remediation steps needed.
- Produce a final validation report summarizing which secrets are correctly scheduled for deletion and which require additional investigation or corrective action.