How to Find and Remove Inactive AWS Access Keys

Inactive AWS access keys aren’t just clutter — they’re a security liability that can quietly become a compliance issue and a cost blind spot. An unused key sitting in a forgotten repo or on an ex-employee’s laptop is one breach away from making headlines (remember the Uber hack that exposed 57 million riders via keys left in GitHub?).

The good news: cleaning up inactive keys is straightforward. Rather than a big-bang approach, here’s a pragmatic 6-step process you can start today.

6 Steps to Removing Inactive AWS Access Keys

1. Disable or remove inactive keys.

The AWS Identity and Access Management (IAM) console shows the keys that are inactive. Disable or delete the keys you’re certain are unused as a first step. Better yet, generate an IAM credential report to get a full inventory across all users — it shows the last-used date for every key in the account.

Bonus points if there are inactive keys for inactive employees — remove the users while you’re at it. Here is an AWS best practice for managing keys.

Set a policy to flag keys inactive for 30+ days and review them monthly.

2. Don’t store keys in GitHub.

If your app depends on AWS keys and you need time to switch to roles, never store keys in GitHub. Even if you remove them, they may still be visible in the commit history.

Use tools like truffleHog or git-secrets to scan repos and commit history for checked-in credentials. If you find keys in Git, rotate or disable them immediately.

If you must use long-lived keys, store them securely: AWS Systems Manager Parameter Store, AWS Secrets Manager, HashiCorp Vault, or KMS. Not Slack. Not shared across users. And always ask yourself: can I use roles instead?

3. Use roles.

IAM roles eliminate long-term credentials entirely. Instead of embedding keys, you grant permissions to an EC2 instance (or Lambda, ECS task, etc.) to make API calls via temporary credentials. No keys stored in code means nothing to compromise.

Pro tip: don’t limit roles to application workloads — use them for human access too. AWS IAM Identity Center (formerly SSO) lets engineers assume roles with short-lived credentials, so nobody needs permanent keys on their laptops.

4. Control access with least privilege.

AWS Service Catalog lets you create pre-approved, security-hardened resource templates (from simple S3 buckets to multi-tier apps). Engineers can provision without needing broad write permissions — fast for them, compliant for you.

Pair this with IAM Access Analyzer to identify overly permissive policies and tighten them based on actual usage patterns.

5. Continuous monitoring.

You can’t control what you don’t track. Developers will sometimes create keys for local testing — that’s fine. But you need automated monitoring to catch when those keys go stale.

AWS Security Hub and Config rules (like `iam-access-key-rotated`) can flag old keys automatically. Set alerts so stale keys surface before they become a risk.

6. Rotate keys on a schedule.

For any keys that must remain active, enforce rotation every 90 days (or less). Automate this where possible — AWS provides guidance on key rotation and you can script it with the CLI or use automation tools to handle the lifecycle.

—

From Security Hygiene to Cloud Optimization

Getting your access keys under control is a foundational security practice — and it’s part of a larger shift toward visibility and governance across your AWS environment. When you know exactly what’s active, what’s idle, and who owns what, you’re in a stronger position to optimize costs too.

nOps provides unified visibility into your cloud spend across AWS, Azure, and GCP — with cost allocation, anomaly detection, and forecasting built in. And nOps Commitment Management autonomously optimizes your savings plans and reserved instances, pushing effective savings rates above 50% without lock-in risk.→ Get a free savings analysis — connect in under 5 minutes, start saving in 2-4 weeks.