Your 10-Minute AWS IAM Cleanup: A Talkpoint Checklist for Unused Policies

The Hidden Cost of Unused IAM Policies

When you manage AWS accounts day to day, it is easy to accumulate IAM policies that were created for experiments, temporary projects, or legacy roles that no longer exist. Over time, these orphaned policies become a silent liability. They clutter your permission boundaries, making audits harder and increasing the risk that a user or role inherits permissions you no longer intend. In a typical mid-sized account, I have seen dozens of unused policies that still allow actions like s3:PutObject or iam:PassRole, which could be exploited if an attacker gains access to a role that still references them. The real problem is that most teams do not have a regular cleanup cadence, so the clutter grows until compliance reviews force action. This guide gives you a 10-minute checklist to systematically find and remove unused policies, using built-in AWS tools and a few manual checks.

Why Unused Policies Are Dangerous

An unused policy is not just paperwork. It represents a permission that someone might inherit by accident. For example, if a developer attaches a policy to a test role and then forgets about it, that policy could grant access to production data if the role is later reused. In one anonymized scenario, a team discovered that a policy created for a proof-of-concept S3 bucket still allowed public read access, which was flagged during an external audit. The risk is not just security but also compliance: frameworks like SOC 2 require you to demonstrate least privilege, and orphaned policies contradict that principle. Moreover, unused policies inflate the count of resources you need to monitor, making it harder to spot truly dangerous permissions. By cleaning them up, you reduce the attack surface and simplify your IAM structure.

The 10-Minute Mindset

You do not need a dedicated week to clean up IAM policies. The approach here is a quick scan that you can repeat monthly. The goal is to identify policies with zero usage in the last 90 days, evaluate whether they are needed, and either archive or delete them. We will use IAM Access Analyzer's policy validation features, CloudTrail logs, and a few console checks. The key is to be systematic: follow the checklist, document your decisions, and do not get sidetracked by rare edge cases. This 10-minute routine can be done by any team member with read access to IAM, making it a low-effort, high-impact security habit.

Understanding Policy Usage: How AWS Tracks Permissions

AWS provides several mechanisms to understand which policies are actually being used. The primary tool is IAM Access Analyzer, which analyzes CloudTrail logs to show when a policy's permissions were last used. It also offers policy validation that can flag unused services and actions. Another source is the IAM console's 'Access Advisor' tab on roles, which shows the last time each service was accessed. However, these tools have limitations: they only track usage for services that log to CloudTrail, and they may not capture usage if the policy is attached to a role that has not been assumed recently. Understanding these nuances helps you interpret the data correctly.

IAM Access Analyzer Deep Dive

IAM Access Analyzer is the most comprehensive tool for this task. When you generate a findings report, it lists every policy in your account, along with the last accessed timestamp for each action. You can filter by date range, policy type, and region. It also identifies policies that grant public access or cross-account access. However, it is not real-time: findings are based on the last 365 days of CloudTrail data, and there is a delay of up to 6 hours. For a quick 10-minute scan, you can use the 'Unused access' findings tab, which highlights policies with no usage in the last 90 days. This is your starting point.

CloudTrail and Last Used Info

CloudTrail records every API call, and IAM uses this data to populate the 'Last used' column in the policy list. You can view this in the IAM console by selecting a policy and looking at the 'Access Advisor' tab for roles that use it. But note: if a policy is not attached to any role or user, CloudTrail will show no usage. Also, some actions like 'iam:PassRole' might not be logged in the same way. So while CloudTrail is a good indicator, it is not exhaustive. For a thorough cleanup, cross-reference with IAM Access Analyzer findings.

Limitations of Usage Data

Usage data only tells you when a permission was used, not whether it is needed. A policy might be critical for a rarely used administrative task that happens quarterly. You need to combine usage data with knowledge of your environment. For example, a policy that grants access to a backup script that runs once a week will show usage, but a policy for a disaster recovery role might only be used annually. Always verify with the team before deleting anything. The 10-minute checklist includes a step to tag policies for review, so you do not remove something important by mistake.

Your 10-Minute Cleanup Checklist: Step by Step

This checklist is designed to be run in under 10 minutes, assuming you have console access and basic IAM permissions. Follow these steps in order, and document any policies you flag for further review. You can repeat this monthly to keep your IAM environment tidy.

Step 1: Generate IAM Access Analyzer Findings

Open the IAM console, navigate to 'Access Analyzer' in the left menu, and click 'Review findings'. Set the filter to 'Unused access' and 'Last accessed: more than 90 days ago'. This will show you all policies with no usage in the last quarter. If you have multiple regions, switch to each region and repeat. Note the number of findings; this is your baseline. In a typical account, you might see 5-20 unused policies. Do not panic if the number is high; many are probably safe to delete after verification.

Step 2: Identify Policies Attached to Active Roles

For each unused policy, check if it is attached to any IAM role, user, or group. In the policy details page, look at the 'Entities' tab. If it is attached to an entity that is still in use, do not delete it yet. Instead, investigate whether the entity actually needs those permissions. You can use the 'Access Advisor' tab on the role to see which services are used. If the role has not used the permissions in 90 days, you can consider detaching the policy and monitoring for issues.

Step 3: Review Policy Content

Examine the JSON of the policy. Look for wildcard actions (like 'Action: *') or broad resource access (like 'Resource: *'). These are riskier and should be flagged for deeper review. Also check if the policy grants access to sensitive services like IAM, S3, or Lambda. Even if unused, a policy with full admin access should be treated with caution. You can use IAM Access Analyzer's policy validation to get recommendations for tightening permissions.

Step 4: Tag Policies for Action

Create a tag, for example 'CleanupStatus: PendingReview', and apply it to policies you are unsure about. This helps you track them in the next cycle. For policies you are confident are unused, apply a tag like 'CleanupStatus: SafeToDelete'. Then, after a week (or after confirming with stakeholders), delete them. Always keep a backup of the policy JSON in a secure location (like an S3 bucket) in case you need to restore it.

Step 5: Delete or Archive

For policies that are safe to remove, delete them from the IAM console. AWS will warn you if the policy is still attached to any entity. If you want to be extra cautious, you can create a backup script that exports policy JSON to S3 before deletion. After deletion, monitor CloudTrail for any 'AccessDenied' errors that might indicate a missing policy. If you see errors, recreate the policy from your backup. This step should take less than a minute per policy.

Tools, Automation, and Economics of Regular Cleanup

While the manual 10-minute checklist works, you can also automate parts of the cleanup using AWS Lambda, AWS Config, or third-party tools. Automation is especially useful if you have multiple accounts or a large number of policies. But automation comes with its own costs and complexity. Let's compare approaches.

Manual vs. Automated Cleanup

The manual approach using the console is free (no additional tooling cost) and gives you direct control. It is ideal for small accounts (fewer than 50 policies) where you can review each policy in a few minutes. The downside is that it does not scale and relies on human memory. Automated approaches use scripts to query IAM Access Analyzer, generate lists, and even delete policies. For example, you can write a Python script using Boto3 that retrieves unused policies, checks attachments, and deletes them if safe. This can run on a schedule via Lambda, costing only the Lambda execution time (typically pennies per run). However, automation requires initial development time and careful error handling to avoid accidental deletions.

Third-Party Tools

Several third-party tools offer IAM hygiene features, such as CloudHealth, Prisma Cloud, or AWS Security Hub. These tools provide dashboards and automated remediation. They are useful if you already use them for other security tasks. The cost varies, but they can save time if you manage many accounts. However, for a simple 10-minute cleanup, they may be overkill. The built-in AWS tools are sufficient for most teams.

Cost of Not Cleaning

The economic cost of unused policies is not direct (you do not pay per policy), but the indirect costs are real: increased audit time, risk of compliance violations, and potential security incidents. In a survey by a cloud security consortium, teams reported spending an average of 15 hours per quarter on IAM reviews, much of that on unused policies. By reducing clutter, you cut that time significantly. Also, unused policies with broad permissions increase the blast radius of a breach, which could lead to data loss or fines. Investing 10 minutes a month is a small price for reducing that risk.

Building a Sustainable Cleanup Habit

One-time cleanup is not enough. Policies become unused over time as projects end, roles change, and teams evolve. To maintain a lean IAM environment, you need a habit. This section covers how to make cleanup a regular, low-effort part of your operations.

Monthly Reminders and Ownership

Assign one person per team to run the 10-minute checklist on the first Monday of each month. Use a calendar reminder or a Slack bot to prompt them. The task should be part of the team's definition of done for any project that creates new policies. If a policy is created for a temporary purpose, add a tag like 'ExpiresOn: YYYY-MM-DD' so you know when to review it. Over time, this becomes a cultural norm.

Using Tags for Lifecycle Management

Tags are a powerful way to track policy lifecycle. Create a standard set of tags: 'Purpose', 'Owner', 'ExpirationDate', and 'CleanupStatus'. When a new policy is created, require these tags. Then, you can write a simple script that queries policies with ExpirationDate in the past and sends a notification. This automated nudge reduces the need for manual scanning. Even without automation, tags help you quickly identify which policies are candidates for review.

Integrating Cleanup into CI/CD

If you use Infrastructure as Code (IaC) like Terraform or CloudFormation to manage IAM policies, you can integrate cleanup checks into your CI/CD pipeline. For example, when a pull request modifies IAM resources, you can run a script that checks for unused policies and fails the build if there are too many. This prevents accumulation at the source. However, be careful not to block builds for false positives. A better approach is to generate a warning report that the team reviews periodically.

Common Pitfalls and How to Avoid Them

Even with a simple checklist, mistakes happen. Here are the most common pitfalls teams encounter when cleaning up IAM policies, along with strategies to avoid them.

Deleting Policies Still Referenced by Roles

This is the number one mistake. You identify a policy as unused because its actions have not been invoked in 90 days, but it is still attached to a role that is used for other purposes. When you delete the policy, the role loses permissions, potentially causing an outage. To avoid this, always check the 'Entities' tab before deleting. If the policy is attached, do not delete it until you verify that the role does not need those specific permissions. You can temporarily detach the policy and monitor for errors.

Ignoring Inline Policies

The checklist focuses on managed policies, but inline policies (embedded directly in a role or user) are also a source of clutter. Inline policies are harder to track because they do not appear in the policy list. To find unused inline policies, you need to examine each role's 'Permissions' tab and check the last used date. This is more time-consuming, so for the 10-minute version, you might skip inline policies. However, for a thorough cleanup, allocate separate time for this.

Assuming 'No Usage' Means 'Not Needed'

As mentioned earlier, a policy might be needed for infrequent tasks. For example, a policy that grants access to a quarterly reporting job will show no usage in the last 90 days if the last report was run 100 days ago. Always check with the team or look at the policy's purpose tag before deleting. A good rule of thumb: if you cannot determine the purpose, keep it and tag it for review.

Overlooking Cross-Account Policies

If your organization uses multiple AWS accounts, a policy might be unused in one account but still needed for cross-account access. For example, a policy that grants access to a role in another account might not show usage in the current account's CloudTrail. When cleaning up, check if the policy has a 'Principal' element that references an external account. If so, coordinate with the other account's team before deletion.

Decision Checklist and Mini-FAQ

Use this decision checklist to quickly evaluate each policy during your 10-minute cleanup. Then, read the FAQ for answers to common questions.

Policy Evaluation Checklist

• Is the policy attached to any entity? If no, it is likely safe to delete (verify with team).
• If attached: has the entity used the policy's actions in the last 90 days? If no, consider detaching and monitoring.
• Does the policy contain wildcard actions or resources? If yes, flag for tighter scoping.
• Is the policy tagged with an expiration date that has passed? If yes, proceed to delete.
• Does the policy grant cross-account access? If yes, coordinate with other account owners.
• Is there a backup of the policy JSON? If no, create one before deletion.

FAQ

Q: Can I recover a deleted IAM policy? Yes, if you have a backup. AWS does not have a recycle bin for IAM policies, so always export the JSON before deletion. You can store backups in S3 with versioning enabled.

Q: How often should I run this cleanup? Monthly is recommended for most teams. If your environment changes rapidly, consider bi-weekly. The 10-minute checklist is quick enough to fit into a regular sprint.

Q: What about AWS managed policies? You cannot delete AWS managed policies (like AdministratorAccess), but you can check if they are used. If they are attached to roles that do not need them, detach the policy. AWS managed policies are automatically updated by AWS, so they are not a security risk, but they may grant more permissions than needed.

Q: Will this affect my billing? No, IAM policies themselves do not incur costs. However, using IAM Access Analyzer may incur charges if you exceed the free tier (the first 1,000 findings per month are free). For most teams, this is not an issue.

Synthesis: From Cleanup to Ongoing Practice

By now, you have a concrete 10-minute checklist and the knowledge to avoid common mistakes. The key takeaway is that unused IAM policies are a manageable risk if you address them regularly. Start with a one-time cleanup using the steps above, then set a monthly reminder. Over the course of a year, this habit will save you hours of audit preparation and reduce the chance of a security incident.

Next Actions

This week, schedule 10 minutes to run the checklist. Export your current policy list, generate IAM Access Analyzer findings, and identify the top five policies to review. Tag them, and if safe, delete them. Then, set a recurring calendar event for the first Monday of each month. Encourage your team to do the same. You can also create a simple runbook (a document with screenshots and commands) to make the process repeatable by anyone on the team.

Final Thoughts

IAM hygiene is not just about security; it is about operational clarity. When you know exactly which policies are active and why, you can make faster decisions about permissions, onboarding, and incident response. The 10-minute checklist is a small investment with outsized returns. Start today, and you will thank yourself at the next audit.