DEV Community

Cover image for Leaked Your AWS Access Key? What to Do in the First 30 Minutes
Shuwa
Shuwa

Posted on Edited on AI-assisted

Leaked Your AWS Access Key? What to Do in the First 30 Minutes

#aws #devops #security #beginners

You just realized your AWS access key is in a public GitHub repo. Maybe in a .env file, maybe hardcoded in a script you pushed late at night.

Your stomach drops. Take a breath. This post is a calm, ordered checklist for the next 30 minutes.

Why speed matters: in honeypot experiments, attackers found and used AWS keys pushed to public GitHub repos within 1 to 2 minutes. Assume your key has already been seen.

Step 0: Don't just delete the commit

Your first instinct might be to delete the file or force-push over the commit. Do it later if you want, but it doesn't fix anything. Scanners copy keys within minutes, and forks or caches may keep the old commit around.

The key itself is what needs to die. Go straight to Step 1.

Step 1: Deactivate the key (2 minutes)

In the console: IAM → Users → (your user) → Security credentials → Access keys, then choose Actions → Deactivate on the leaked key.

Or from the CLI, using a different, trusted credential:

aws iam update-access-key \
  --user-name my-user \
  --access-key-id AKIAIOSFODNN7EXAMPLE \
  --status Inactive
Enter fullscreen mode Exit fullscreen mode

Deactivating instead of deleting right away has one benefit: if something you rely on breaks, you'll know which key it was using. For most solo projects, nothing important breaks, and you can delete the key in Step 5.

Already got an email from AWS? AWS and GitHub work together to detect exposed keys. AWS may have already attached a policy called AWSCompromisedKeyQuarantineV3 to your IAM user and opened a support case. In one test by Palo Alto Networks' Unit 42, this happened about 10 seconds after the push. That policy blocks some risky actions, but it does not disable the key. You still need to do everything in this post. AWS also advises keeping that policy in place until you've finished cleaning up, since removing it early can affect whether you're eligible for billing concessions.

Step 2: Find out what the key did (10 minutes)

Open CloudTrail → Event history, set the filter to AWS access key, and paste the leaked key ID. Event history covers the last 90 days.

Look especially for these event names:

Event name Why it's alarming
RunInstances Someone launched EC2 instances (often large ones, for crypto mining)
CreateUser, CreateAccessKey Someone created a new identity or key to keep access after you revoke this one
CreateLoginProfile Someone gave a user a console password
AttachUserPolicy, PutUserPolicy Someone granted extra permissions
GetCallerIdentity Someone checked whether the key works. Usually the very first thing attackers do

Important: CloudTrail Event history is per region. Check every region you see activity in. IAM events (like CreateUser) show up in US East (N. Virginia).

From the CLI, this lists recent events for the key in one region:

aws cloudtrail lookup-events \
  --region us-east-1 \
  --lookup-attributes AttributeKey=AccessKeyId,AttributeValue=AKIAIOSFODNN7EXAMPLE \
  --query "Events[].[EventTime,EventName,Username]" \
  --output table
Enter fullscreen mode Exit fullscreen mode

To sweep all regions at once:

for r in $(aws ec2 describe-regions --query "Regions[].RegionName" --output text); do
  echo "== $r"
  aws cloudtrail lookup-events --region "$r" \
    --lookup-attributes AttributeKey=AccessKeyId,AttributeValue=AKIAIOSFODNN7EXAMPLE \
    --query "Events[].[EventTime,EventName]" --output text
done
Enter fullscreen mode Exit fullscreen mode

Step 3: Shut down anything you didn't create (10 minutes)

Attackers love regions you never use. Check them all:

  • Console: Resource Groups & Tag Editor → Tag Editor → Regions: All regions → Resource types: All supported resource types → Search.
  • CLI: list EC2 instances in every region: 
for r in $(aws ec2 describe-regions --query "Regions[].RegionName" --output text); do
  echo "== $r"
  aws ec2 describe-instances --region "$r" \
    --query "Reservations[].Instances[].[InstanceId,InstanceType,State.Name,LaunchTime]" \
    --output text
done
Enter fullscreen mode Exit fullscreen mode

Terminate anything you don't recognize. Also check for unexpected Lambda functions, spot requests, and EC2 launch templates, which attackers sometimes use to relaunch instances after you delete them.

Step 4: Hunt for backdoors (5 minutes)

Revoking one key doesn't help if the attacker created another way in.

  1. IAM → Users: any users you don't recognize? Delete them (after noting their names for your support case).
  2. For every user: check Security credentials for access keys you didn't create.
  3. IAM → Roles and Policies: anything new or recently modified?
  4. Credential report: shows when every password and key was last used: 
aws iam generate-credential-report
aws iam get-credential-report --query Content --output text | base64 -d
Enter fullscreen mode Exit fullscreen mode
  1. Root user: change the password and confirm MFA is on.

Step 5: Replace the key properly

  1. Delete the leaked key: 
aws iam delete-access-key --user-name my-user --access-key-id AKIAIOSFODNN7EXAMPLE
Enter fullscreen mode Exit fullscreen mode
  1. If an app genuinely needs credentials, create a new key and store it outside your code (environment variables that never get committed, or a secrets manager).
  2. Better yet, avoid long-term keys entirely:
    • Code running on AWS (EC2, Lambda, ECS) should use an IAM role, not a key.
    • For your own laptop, use IAM Identity Center (aws configure sso) for short-lived credentials.

Step 6: Deal with the bill

  1. Open Billing and Cost Management → Bills or Cost Explorer to see what the attacker cost you.
  2. If AWS opened a support case about the exposure, reply in that case with what you've done. If not, open one: Support Center → Create case → Account and billing. Billing support is free on every plan, including Basic.
  3. Be specific: when the key leaked, what you deactivated and deleted, which resources you terminated, and what you've changed to prevent it happening again.

AWS reviews billing adjustments case by case. Many developers report getting a courtesy credit for a first incident, but it's never guaranteed, and replies can take days.

Prevent the next one

  • Never put keys in code. Add .env and credential files to .gitignore before your first commit.
  • Turn on GitHub secret scanning and push protection for your repos, so a key gets blocked before it's pushed.
  • Prefer roles and IAM Identity Center over long-term access keys.
  • Never create access keys for the root user. Turn on MFA for it.
  • Set a budget alert and Cost Anomaly Detection so a surprise shows up in your inbox, not on your credit card statement.

The 30-minute checklist

  • [ ] Deactivate the leaked key
  • [ ] Check CloudTrail for that key in every active region (IAM events: N. Virginia)
  • [ ] Terminate unknown resources in all regions
  • [ ] Remove unknown IAM users, keys, roles, and policies
  • [ ] Change the root password and confirm MFA
  • [ ] Delete the leaked key and replace it with a role or a properly stored key
  • [ ] Reply to (or open) an Account and billing support case

Bookmark this. Hopefully you never need it.

A budget alert won't stop a leak, but it can catch one before the bill gets huge. If you want the full prevention routine, I wrote a short PDF guide: a 30-minute setup (MFA, budget alerts, anomaly detection, an all-regions sweep) and a 10-minute monthly checklist. It's $9 on Gumroad: Stop AWS Bill Shock.

More in this series: 5 Reasons Your AWS Bill Keeps Growing

Sources (checked November 2026)

Top comments (0)