Access Key

An Access Key consists of two parts: an access key ID (starts with AKIA) and a secret access key. Together they authenticate programmatic requests to AWS APIs, including CLI commands, SDK calls, and HTTP requests.

Access keys are long-term credentials that do not expire unless explicitly deactivated or deleted. This makes them a significant security risk: if leaked (in a Git commit, a log file, or a misconfigured server), an attacker has persistent access until the key is revoked. AWS itself recommends temporary credentials through IAM roles as the default, and treats access keys as the fallback for cases where roles are not practical. An IAM user can hold a maximum of two access keys at the same time, and that limit exists precisely to support rotation: you create the new key, migrate your workloads, then disable and delete the old one.

Security Best Practices

• Use IAM roles with temporary credentials instead of access keys wherever possible
• Never embed access keys in application code or commit them to version control
• Rotate keys regularly (90 days maximum per CIS benchmark)
• Use aws:SecureTransport condition to require HTTPS
• Monitor for unused or old keys with IAM Credential Reports and Access Advisor

How It Goes Wrong in Practice

The most common failure mode is depressingly simple: a developer hardcodes a key pair in a config file for a quick test, then pushes the repository to a public GitHub project. Automated scanners, both benign and malicious, continuously crawl public repositories for the recognizable AKIA prefix, and leaked keys are typically probed within minutes, long before a human notices the mistake. The attacker's first calls are usually reconnaissance: identify the account, enumerate what the key is allowed to do, then move to whatever pays, most often launching large EC2 instances for cryptomining, reading S3 buckets for data theft, or creating new IAM users as a persistence mechanism. Because the key never expires on its own, the window stays open until someone deactivates it. The second classic failure is the forgotten key: an employee leaves, their IAM user stays behind, and an active key with production permissions sits unused for years. Unused long-lived credentials are exactly what CIS controls on key rotation and unused credentials are designed to catch. The lesson from both patterns is the same: every long-term credential you avoid creating is one you never have to leak, rotate, or clean up.

Practical Check: Audit Your Keys

Two CLI calls give you a fast picture of key hygiene for a user. First list the keys and their status:

aws iam list-access-keys --user-name alice

The output includes each AccessKeyId, its Status (Active or Inactive), and its CreateDate, which tells you immediately whether a key is overdue for rotation. Then check whether a key is actually being used:

aws iam get-access-key-last-used --access-key-id AKIAIOSFODNN7EXAMPLE

This returns the LastUsedDate, the AWS service the key last called, and the region. A key with no recent usage is a deletion candidate, not a rotation candidate. If you suspect a key has been compromised, pivot to CloudTrail and pull everything it did:

aws cloudtrail lookup-events --lookup-attributes AttributeKey=AccessKeyId,AttributeValue=AKIAIOSFODNN7EXAMPLE

That query works because AccessKeyId is one of the supported lookup attribute keys in CloudTrail event history, and it is usually the fastest way to scope an incident involving a leaked key.

Frequently Asked Questions

How many access keys can one IAM user have?
Two at most. This is a hard limit, and it exists to enable zero-downtime rotation: create the second key, switch your applications over, verify with the last-used API that the old key has gone quiet, then deactivate and delete it.

Can I recover a lost secret access key?
No. The secret access key is only visible at creation time. If you lose it, delete the access key and create a new one. This is by design: AWS does not store the secret in a retrievable form.

Is deactivating a key the same as deleting it?
No. An Inactive key stops working immediately but can be reactivated later, which makes deactivation the right first step during rotation or incident response: if something breaks, you can turn the key back on while you investigate. Deletion is permanent and should follow once you have confirmed nothing depends on the key.

What should I do the moment a key leaks?
Deactivate the key first, then investigate with CloudTrail. Rotating the key alone is not enough: attackers commonly create additional users, keys, or roles as backdoors within minutes of gaining access, so review IAM changes made by the compromised key before you consider the incident closed.