AWS Access Keys: Where to Find Your Access Key ID, Do They Expire, "Last Used" Not Updating, Who Owns a Key, and Rotating Without Downtime

An AWS access key has two parts: an access key ID (20 characters, starting with AKIA for an IAM user's long-term key, or ASIA for temporary credentials) and a secret access key (40 characters) that you can see only once, when you create the key. To find your keys, open the IAM console, choose Users, your user, then the Security credentials tab; on your own computer, aws configure list shows which key the CLI uses, and the keys live in ~/.aws/credentials. If you lost the secret, you cannot recover it: create a new key and delete the old one. Long-term access keys never expire on their own (temporary ones do); you rotate them yourself, and each user can have at most two. The Last used column shows only the most recent date, service and Region, is not updated in real time, and shows only STS when a key is used just to assume a role; for the full picture of where a key is used, search CloudTrail by access key ID. Below: every place to find a key, how to tell which user owns a key ID, rotating without downtime, finding and deleting unused keys, and the safer alternatives to keys.

The shop's old backup script had worked for six years on an access key nobody remembered creating. When Ethan finally cleaned up IAM, he found three users with keys, one of them showing "Last used: 2 hours ago" for a user that belonged to a contractor who had left the year before. That was a bad few minutes. It turned out to be the backup script, running under the wrong user's key all along. The key was not leaked, just forgotten, which is the most common way access keys go wrong.

New to IAM users or the AWS CLI's files? The cards below cover root vs IAM users, leaked keys, Identity Center and the credentials file.

What an AWS access key is

An access key is how a program proves who it is to AWS: the CLI, an SDK in your code, a backup tool, Terraform. You can think of it as a username and password for machines:

• Access key ID, for example AKIAIOSFODNN7EXAMPLE: the "username" part. It is not secret on its own, and appears in logs and error messages.
• Secret access key, for example wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY: the "password" part. Anyone who has both parts can act as that user.

The prefix of the ID tells you what kind of key it is:

Each IAM user can have at most two access keys at a time, which exists so you can rotate: create the second, move everything to it, delete the first. Root user access keys are possible but a bad idea: the root user can do anything in the account, so its keys are the most dangerous credential you can create. Our root vs IAM user guide explains why.

Jake: "So the AKIA part is fine to show people?"

Ethan: "It isn't secret by itself, but the pair is a key to the account. Treat the secret like your bank PIN, and don't post the ID next to it."

Where to find your AWS access key ID

Two commands answer "which credentials am I actually using?":

# Which key, and from where (env, file, profile)
aws configure list

# Who AWS thinks you are: account, user or role ARN
aws sts get-caller-identity

aws configure list shows the last four characters of the key and its source (environment, shared credentials file, SSO). If an environment variable is set, it wins over the file, which is the usual reason "I changed my key but the CLI still uses the old one". Our guide to the config and credentials files covers how profiles and these sources interact.

On Windows, the CLI and SDKs use %USERPROFILE%\.aws\credentials, which you can open in Notepad to see each profile's key ID. AWS Tools for PowerShell can also keep profiles in its own encrypted SDK store; Get-AWSCredential -ListProfileDetail lists every profile it knows and where each one is stored, which explains the common case of PowerShell and the CLI using different keys on the same machine. To replace a key there, Set-AWSCredential -AccessKey ... -SecretKey ... -StoreAs default overwrites the stored profile.

If you sign in through IAM Identity Center (SSO), you have no permanent access keys at all: aws configure sso and aws sso login give you temporary credentials instead, which is the better setup.

How to use an access key: CLI, SDKs and environment variables

Once you have a key pair, every AWS tool reads it from the same few places, in a fixed order. Knowing that order explains most "it is using the wrong key" puzzles:

1. Explicit settings in code, such as keys passed when creating a client. Keys written into code tend to end up in Git, so keep them out of it.
2. Environment variables: AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, and AWS_SESSION_TOKEN for temporary credentials.
3. The shared credentials and config files in your home folder, for the profile named by --profile or AWS_PROFILE, or default.
4. The compute's role: an EC2 instance profile, ECS task role, Lambda execution role and so on.

The everyday setup on your own computer is one command, which writes the files for you:

# Store a key under a named profile
aws configure --profile backup
#   AWS Access Key ID: AKIA...
#   AWS Secret Access Key: ...
#   Default region name: us-east-1

# Use it
aws s3 ls --profile backup

# In Python, the same profile
import boto3
s3 = boto3.Session(profile_name="backup").client("s3")

Named profiles keep keys for different jobs or accounts apart, and aws sts get-caller-identity --profile backup confirms which identity each one is. For a quick one-off in a terminal, environment variables work too (export on Mac and Linux, $env:AWS_ACCESS_KEY_ID = "..." in PowerShell), but remember they override the files until you close that shell, which is the classic cause of a CLI that keeps using an old key after you have updated the credentials file.

Lost your secret access key? Make a new one

You see the secret once, on the screen where you create the key, and never again. Nobody, including AWS Support, can retrieve it. So the fix is always a new key:

1. In the IAM console, open the user, choose Security credentials, and under Access keys choose Create access key. If the user already has two, delete or deactivate one first.
2. Choose the use case (for most CLI or script use, "Command Line Interface" or "Other"), optionally add a description tag such as "backup script on NAS", and create.
3. Copy the secret or choose Download .csv file. This is your only chance; store it in a password manager or secrets store.
4. Put the new key where the old one was used (aws configure on your computer, the app's configuration or secret store).
5. Deactivate the old key, check everything still works, then delete it.

The description tag in step 2 is worth the ten seconds: six years later, it is what tells you which script a key belongs to.

Do AWS access keys expire?

Long-term access keys (AKIA) never expire. A key created today still works in ten years unless someone deactivates or deletes it. That is precisely why they are risky: a key copied into a script or a laptop years ago is still a working key to your account.

Temporary credentials (ASIA) always expire: from 15 minutes up to 12 hours for most role sessions (longer for some setups), after which you see ExpiredToken errors. Our guide to ExpiredToken and session credentials covers those.

Since AWS will not expire long-term keys for you, you set the rules:

• Watch key age. In the IAM console's Users list, add the Access key age column (settings icon above the table); it shows the age of each user's oldest active key.
• Check it automatically. The AWS Config managed rule access-keys-rotated flags keys older than a maximum age you choose (90 days is a common setting), and Security Hub has a matching control.
• Rotate on a schedule, for example every 90 days, and immediately when someone with access to the key leaves.

Jake: "So the contractor's key would have worked forever?"

Ethan: "Forever, from anywhere. Keys don't know people have left. That's our job."

Active and inactive keys, and checking status from the CLI

Every key is either Active (it works) or Inactive (it is refused, but it still exists and can be switched back on). Listing a user's keys shows both states:

aws iam list-access-keys --user-name backup-bot \
  --query "AccessKeyMetadata[].[AccessKeyId,Status,CreateDate]" --output table

# Switch one off, and back on
aws iam update-access-key --user-name backup-bot --access-key-id AKIA...OLD --status Inactive
aws iam update-access-key --user-name backup-bot --access-key-id AKIA...OLD --status Active

Deactivation takes effect within seconds, everywhere, which makes it the right first move for any key you are unsure about: a suspected leak, a key whose owner left, or one you are about to retire. An inactive key still counts toward the limit of two per user, so delete keys you no longer need rather than leaving a pile of inactive ones.

Without --user-name, list-access-keys lists the keys of whoever is running the command, which is a quick way for an IAM user to see their own keys without console access.

"Last used": what it shows, and why it seems not to update

Every access key has Last used information: the date and time of its most recent use, plus the service and Region of that request. In the console it appears next to each key on the Security credentials tab; from the CLI:

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

{
  "UserName": "backup-bot",
  "AccessKeyLastUsed": {
    "LastUsedDate": "2026-10-19T03:12:00+00:00",
    "ServiceName": "s3",
    "Region": "us-east-1"
  }
}

It is a quick hint, not a log, and that explains most "last used is wrong" or "not updating" reports:

• It holds only the latest use. One date, one service, one Region. A key used by three scripts in two Regions shows only whichever ran last.
• It is not real time. A call you just made may not show for a while. Check again later before concluding anything, and use CloudTrail for minute-by-minute truth.
• Keys used only to assume a role show STS. If a script uses the key once to call sts:AssumeRole and then works with the role's temporary (ASIA) credentials, the key's Last used shows sts, and everything the script did afterwards is recorded under the role, not the key.
• "N/A" or empty means the key has never been used since tracking began (April 22, 2015), or the user has no key.
• You may be looking at the other key. With two keys on a user, the app may be using the one you are not watching. Compare the key ID in aws configure list or the app's settings.
• The app may use a different user's key entirely, as the shop's backup script did. Search CloudTrail by key ID (below) to be sure.

Find where and by whom a key is being used: CloudTrail

CloudTrail records API calls with the access key ID that signed them, so you can search for one key and see every call, the source IP address and the tool (user agent):

1. Open CloudTrail, choose Event history.
2. Set the lookup attribute to Access key and paste the key ID.
3. Open a few events and note sourceIPAddress (where the call came from), userAgent (for example aws-cli/2.x, Boto3/... or a backup product's name) and eventSource (which service).

aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=AccessKeyId,AttributeValue=AKIAIOSFODNN7EXAMPLE \
  --max-results 50 \
  --query "Events[].[EventTime,EventName,EventSource]" --output table

Event history covers management events for the last 90 days in the current Region; check each Region where the key might be used, and remember that S3 object reads and writes (data events) only appear if a trail records data events. The source IP and user agent are usually enough to identify the machine: Ethan's search showed a home NAS's IP and a backup tool's user agent, which ended the mystery.

If the IPs are unfamiliar, or the calls are things nobody in your team would do, treat it as a leak: deactivate the key at once and follow our leaked key first-30-minutes guide.

Keys that assume roles: following the trail

A well-built script often uses its access key for exactly one thing: calling sts:AssumeRole to get a role's temporary credentials, then doing all its real work as the role. That is good practice, and it changes where you look:

• The key's Last used shows sts, because assuming the role was the only call the key made.
• CloudTrail's AssumeRole event records the access key ID that made the call, the role, and the role session name the script chose. Every later call made with the role's credentials carries that session name in its user identity.
• Linking the two is therefore a two-step search: find the AssumeRole events for the key ID, note the session names, then search for events from those role sessions.

Two settings make this trail much easier to follow. Have every script set a meaningful RoleSessionName, such as nas-backup, instead of a random string. And where you control the role's trust policy, require a source identity (sts:SetSourceIdentity): it is recorded in CloudTrail and carried through every further role the session assumes, so actions three roles deep still point back to the original caller.

Which user (and account) owns an access key ID?

Sometimes you have a key ID from a log, an error, a config file you found on an old server, or a security alert, and you need to know whose it is before you can decide anything. Work from the outside in: first the account, then the user, then what the user can do.

Which account:

aws sts get-access-key-info --access-key-id AKIAIOSFODNN7EXAMPLE
# returns the 12-digit account ID that owns the key

Which user, inside your account: the IAM console's search box finds users by access key ID; from the CLI, list every user's keys and match:

# Bash
for u in $(aws iam list-users --query "Users[].UserName" --output text); do
  aws iam list-access-keys --user-name "$u" \
    --query "AccessKeyMetadata[?AccessKeyId=='AKIAIOSFODNN7EXAMPLE'].[UserName,Status,CreateDate]" --output text
done

# PowerShell (AWS Tools)
Get-IAMUserList | ForEach-Object {
  Get-IAMAccessKey -UserName $_.UserName | Where-Object AccessKeyId -eq "AKIAIOSFODNN7EXAMPLE"
}

What the user can do: once you know the user, its Permissions tab shows the attached policies, and the Access Advisor tab shows which services the user has actually touched and when. Together with the key's Last used, that tells you how much damage a misused key could do, and whether the key is safe to deactivate.

If you get "The AWS Access Key Id you provided does not exist in our records" when using a key, it was deleted, belongs to another account or partition, or was mistyped; our guide to InvalidAccessKeyId covers each case.

Access key errors, and what each one tells you

The first two are worth telling apart: an invalid token means AWS does not recognize the key ID at all, while a signature mismatch means it recognizes the ID but the secret does not match. That alone tells you which half of the pair to fix. Our guides to "Unable to locate credentials" and InvalidAccessKeyId cover those cases step by step.

Rotating an access key without downtime

Because a user can have two keys, rotation needs no outage:

1. Create the second key while the first is still active: aws iam create-access-key --user-name backup-bot. Save the secret.
2. Update every place that uses the old key: the app's configuration, its secret store, scheduled tasks, CI variables.
3. Wait, then check the old key's Last used (and CloudTrail) to confirm nothing still uses it. A few days covers weekly jobs; a month covers monthly ones.
4. Deactivate first, delete later: aws iam update-access-key --user-name backup-bot --access-key-id AKIA...OLD --status Inactive. Anything still using it now fails, which tells you what you missed.
5. If something breaks, set the old key back to Active, fix that place, and return to step 3.
6. Delete the old key once you are sure: aws iam delete-access-key --user-name backup-bot --access-key-id AKIA...OLD.

Deactivation is the safety net: it is instant and reversible, while deletion is permanent. For the shop, Ethan left the contractor's key deactivated for two weeks, saw no failures beyond the backup script he had already moved, and then deleted it.

Automating it for a key that has to stay. If the key lives in Secrets Manager and the application reads it from there, rotation can run on a schedule: a small Lambda function creates the second key, writes it to the secret, waits for the application to pick it up, then deactivates and later deletes the old one, following exactly the steps above. Secrets Manager's rotation feature calls the function for you on the interval you set. The application must read the secret at start-up or on a timer, rather than having the key baked into its configuration, for this to work without anyone noticing.

When someone leaves: the access key part of the checklist

Keys outlive employment unless someone removes them, which is how the shop ended up with a contractor's key still in use a year later. The leaving checklist Ethan now uses:

• Their own IAM user: deactivate its access keys on the last day, delete them a week later, then delete the user once nothing has failed.
• Shared keys they knew: any key the person could have copied, such as a deployment key in a team password vault, gets rotated, even if nothing suggests misuse.
• Their scripts: anything that ran under their user moves to a dedicated user or, better, a role, before their keys are removed.
• Identity Center access: removing them from the identity provider ends SSO sessions and stops new temporary credentials, which is why SSO makes leaving so much simpler than keys.

Jake: "So the contractor's key should have been switched off the day they left?"

Ethan: "The same day. It's on the list now, right after returning the laptop."

Find and remove unused access keys across the account

The IAM credential report lists every user with their keys' status, last rotation date and last used date, service and Region, as a CSV:

aws iam generate-credential-report
aws iam get-credential-report --query Content --output text > report.b64
# decode report.b64 (base64) to get the CSV, then sort by access_key_1_last_used_date

In the console, the same report is under IAM → Credential report → Download credentials report. Look for:

• Keys that are active but never used, or not used for 90 days or more: deactivate them.
• Keys older than your rotation limit: rotate them.
• Two active keys on one user for a long time: one of them is usually forgotten.
• Any root user access key: delete it unless you have a documented reason.

IAM Access Analyzer can also report unused access keys across an account or organization, which saves building this check yourself.

A 15-minute access key audit

Once a quarter, or before handing over an account, this sequence catches nearly every forgotten or risky key:

1. Download the credential report and open it in a spreadsheet.
2. Check the root row first. Both root access key columns should say false; if either is true, delete that key today.
3. Sort by key age (access_key_1_last_rotated and access_key_2_last_rotated) and list every active key older than your limit.
4. Sort by last used and list active keys unused for 90 days or more, plus active keys never used at all.
5. Look for users with two active keys; one of the pair is usually left over from an unfinished rotation.
6. Match each remaining key to an owner and a job, using its description tag, its Last used service, or a CloudTrail search.
7. Deactivate what nobody claims, wait two weeks for anyone to complain, then delete.

For the shop, the first run of this audit took forty minutes and turned up the contractor's key, an unused key on a test user, and a root key nobody remembered creating. The second run, three months later, took ten minutes and found nothing new. Write the results into the same spreadsheet each time. After two or three quarters, the list of keys that exist and why becomes short and boring, which is exactly the goal.

Keeping track of keys across many accounts

In an organization with many accounts, checking each one by hand does not scale. AWS services can do the watching:

• Security Hub includes controls for this, among them one that flags access keys older than 90 days (IAM.3) and one that flags any root user access key (IAM.4), with findings collected across accounts in one place.
• AWS Config with the access-keys-rotated managed rule, deployed to every account through a conformance pack or StackSet, and an aggregator to see results centrally.
• IAM Access Analyzer unused access analysis, set up at the organization level, reports unused access keys and unused roles in every member account.

Pair those with the service control policy below that limits who can create keys at all, and the number of long-term keys in the organization shrinks over time instead of growing with every new project.

Policies that limit who can create keys

Rotation reminders work only if few keys exist in the first place. Two policies keep the number small:

• Block key creation for people. If everyone signs in through Identity Center, nobody needs iam:CreateAccessKey. A service control policy that denies it, except for a named administrator role, stops new long-term keys appearing quietly in member accounts.
• Self-service only with MFA. Where users manage their own keys, the usual self-service policy allows iam:CreateAccessKey and iam:UpdateAccessKey on arn:aws:iam::*:user/${aws:username} only when aws:MultiFactorAuthPresent is true, so a stolen password alone cannot mint a key.

{
  "Sid": "NoNewAccessKeysExceptPlatformAdmins",
  "Effect": "Deny",
  "Action": "iam:CreateAccessKey",
  "Resource": "*",
  "Condition": {"ArnNotLike": {"aws:PrincipalArn": "arn:aws:iam::*:role/PlatformAdmin"}}
}

Pair the policy with detection: the AWS Config rule for key age, IAM Access Analyzer's unused-access findings, and an EventBridge rule on CreateAccessKey events that notifies the team whenever a key is created anywhere. A new key then becomes a conversation instead of a surprise found years later.

If you must have a key: storing it safely

Some things still need a long-term key: an old backup appliance, a third-party tool without role support. Make that key as harmless as possible:

• One key per job, on a dedicated user with a policy that allows only that job, such as writing to one bucket prefix.
• Keep it in a secrets store, such as AWS Secrets Manager or a password manager, not in a script, a wiki page or a shared spreadsheet. On a laptop, tools that keep keys in the operating system's keychain, or the CLI's credential_process setting, keep it out of a plain-text credentials file.
• Keep it out of Git. Secret scanning in GitHub and similar services detects AWS keys pushed to public repositories, and AWS is notified and may attach a quarantine managed policy to the user, which blocks risky actions while you deal with it. Better not to rely on that: add .aws/ and .env files to .gitignore, and run a secret scanner before pushing.
• Tag and date it. A description such as "NAS backup, owner Ethan, rotate every 90 days" turns a mystery key into a maintained one.

If a key ever does appear somewhere public, deactivate it first and investigate afterwards, following the leaked-key steps linked above.

Access keys in Terraform and CloudFormation: the state file catch

Infrastructure as code can create access keys (aws_iam_access_key in Terraform, AWS::IAM::AccessKey in CloudFormation), and both put the secret somewhere you might not expect. In Terraform, the secret lands in the state file, readable by anyone who can read the state, unless you supply a PGP key so only an encrypted version is stored. In CloudFormation, the secret is only available as a resource attribute, which tends to end up in outputs or parameters.

Two better patterns: create the user and its policy in code but the key by hand, storing the secret straight into Secrets Manager; or, where the consumer runs on AWS, replace the key with a role entirely. If a key must be created in Terraform, keep the state in an encrypted, access-controlled backend and treat state access as access to the key itself.

Recognizing an access key when you see one

Key IDs have a recognizable shape, which is how secret scanners find them in code and logs: 20 characters, uppercase letters and digits, starting with AKIA for long-term keys or ASIA for temporary ones. The secret is 40 characters of letters, digits, slashes and plus signs, with no fixed prefix. A key ID on its own in a log line is normal; CloudTrail records one in almost every event. A key ID next to a 40-character string in a file, a chat message or a screenshot is a key pair, and should be treated as exposed.

If you find such a pair in an old repository or a shared document, check its status with aws sts get-access-key-info (which account) and the IAM console (still active?), and deactivate it if it is yours and still works. Then search the rest of the repository history; a key committed once usually appears in more than one place.

Other AWS "keys" that are not access keys

Several AWS features use the word "key" for something quite different, and searches for "do AWS API keys expire" often mix them up:

• API Gateway API keys identify which client is calling an API for usage plans and throttling. They are not AWS credentials, they are weak as the only protection on an API, and they stay valid until you delete them.
• Amazon Bedrock API keys are a newer credential for calling Bedrock without signing requests yourself. Short-term keys last up to 12 hours (or the rest of your console session, if shorter) and carry the permissions of whoever created them; long-term keys belong to an IAM user, have an expiry date you set, and only work with Bedrock. The same mechanism also covers CloudWatch Logs. Treat long-term ones like access keys: rotate and delete.
• KMS keys are encryption keys, not credentials. Nobody signs in with them; they encrypt data. Each customer managed KMS key has a monthly charge, which is the "AWS key management cost" people look for.
• EC2 key pairs are SSH keys for logging in to Linux instances (or decrypting Windows passwords). They have nothing to do with API access.
• Service-specific credentials, such as SES SMTP passwords, are separate credentials tied to an IAM user for one service, managed on the same Security credentials tab.

If a tool asks for an "AWS key," it almost always means an access key ID and secret access key pair. Anything else names its service.

Safer alternatives to long-term access keys

The best access key is the one you skip creating. For each common use, there is a temporary-credential option:

• People using the CLI: IAM Identity Center and aws configure sso, which hands out short-lived credentials after a browser sign-in. Our Identity Center explainer covers setup.
• Code on EC2, Lambda, ECS or EKS: an IAM role attached to the resource; the SDK picks up temporary credentials automatically.
• CI/CD such as GitHub Actions: OpenID Connect federation to an IAM role, with no stored keys.
• Servers outside AWS (an office NAS, on-premises machines): IAM Roles Anywhere with certificates, or, where a key is truly needed, a dedicated user with a narrow policy, a description tag, and rotation.

Moving a job from a key to a role is usually smaller work than it sounds. For code on EC2 or Lambda, you attach a role and delete the key from the configuration; the SDK finds the role's credentials by itself, with no code change at all. For GitHub Actions, the official AWS credentials action exchanges the workflow's OIDC token for a role session in a few lines of YAML.

The shop's backup script now runs under its own user with permission only to write to one bucket, a key tagged "NAS backup", and a calendar reminder to rotate it every 90 days. Not perfect, but every part of it is now known and owned.

Frequently asked questions

The clean-up took one afternoon: three users, five keys, two deleted, one rotated, two replaced by roles and SSO. Jake added a line to the shop's leaving checklist, right under "return laptop": "Delete their access keys." Ethan's addition was shorter: every new key gets a description tag on day one, so nobody ever has to play detective with CloudTrail again.

Revision note. Written October 19, 2026. Most access key problems are not leaks but keys nobody remembers; a description tag and a rotation date fix most of them.