An AWS access key is two strings that together let a program act as an IAM user: the access key ID, which identifies the key, and the secret access key, which proves it. People search for them under three names, access key and secret key, secret access key, and just AWS secret key, and they are all the same pair. The pair turns up in CLI configs, CI pipelines, and far too often in a Slack message.
This guide covers what the two halves are, how to create and configure them, how to rotate without downtime, what to do when one leaks, and the question that comes up every time a developer joins or a contractor starts: how to hand a secret key to a person without putting it in email.
Access key ID versus secret access key
| | Access key ID | Secret access key |
| --- | --- | --- |
| Looks like | AKIAIOSFODNN7EXAMPLE (20 characters) | 40 characters of mixed case and symbols |
| Role | Identifies which key is signing the request | Signs the request; proves possession |
| Secret? | No, treat it like a username | Yes, treat it like a password |
| Visible later? | Yes, in the IAM console | Never after creation |
Long-term keys start with AKIA. Temporary credentials from STS,
which also come with a session token, start with ASIA and expire on
their own. If you see an ASIA key in a config file, it will stop
working within hours, which is the design.
Neither half grants permissions. The key authenticates as an IAM user, and the user's attached policies decide what that identity can do. A leaked key on a read-only user is a problem. A leaked key on an administrator is an incident.
When you need a long-term key at all
The honest answer is less often than people think.
- Workloads on AWS (EC2, Lambda, ECS, EKS) should use IAM roles. The SDK picks up short-lived credentials automatically and there is nothing to rotate or leak.
- People should sign in through IAM Identity Center or federated
SSO and get temporary credentials from
aws sso login. - CI systems such as GitHub Actions can assume a role through OIDC with no stored key.
- Long-term keys are left for the cases that cannot do any of the above: a tool on a laptop that lacks SSO support, a third-party service that only accepts static keys, a legacy job you have not migrated yet.
If you do need one, create it on a dedicated IAM user with the narrowest policy that does the job, and never on a human's administrator account.
Create and configure a key
In the IAM console, open the user, choose Security credentials, then Create access key. Pick the use case AWS asks about, read the alternative it suggests, and continue. The secret is shown exactly once. Save it straight into your secret store or password manager, or download the CSV and delete it after import. Each IAM user can hold at most two keys at a time, which is what makes rotation possible.
On a machine, configure a named profile rather than the default:
aws configure --profile deploy-tool
# AWS Access Key ID [None]: AKIA...
# AWS Secret Access Key [None]: ...
# Default region name [None]: eu-west-1
That writes ~/.aws/credentials and ~/.aws/config. Lock the file
to your user with chmod 600. For containers and CI, inject
AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY as secrets from the
platform's store, not as plain variables in a YAML file, and never
pass them on a command line where they land in shell history.
Rotate without breaking anything
Rotation is a four-step dance, made possible by the two-key limit.
- Create the second key on the same user.
- Update every consumer to the new key: configs, CI secrets, the secrets manager entry. The IAM console shows each key's last used time, which tells you whether you missed one.
- Deactivate the old key. Wait a day or a deploy cycle. If something breaks, reactivate it, fix the consumer, try again.
- Delete the old key once nothing has used it.
Do this on a schedule for keys that must exist, and on events for all of them: a departure, a vendor change, a laptop lost, a suspected leak. AWS Config and IAM Access Analyzer can flag keys older than your policy allows.
When a key is exposed
Treat a key that appeared in a repository, a log, a ticket or a chat as compromised, even if it was deleted a minute later. Scanners find pushed secrets in seconds.
- Deactivate the key in IAM now. Do not wait to create the replacement first unless the outage would be worse than the exposure.
- Create a replacement and update the consumers.
- Read CloudTrail for every action made with that access key ID since the exposure. Look for new IAM users or keys, new instances, changed bucket policies and unfamiliar regions.
- Check the bill and Cost Explorer for crypto-mining-shaped spikes.
- Remove the secret from code, logs and git history. AWS may
attach the
AWSCompromisedKeyQuarantinepolicy to the user itself when it detects a public leak; leave that in place until the cleanup is done. - Delete the old key, then find out how it got there and close that path.
How to share an AWS secret key with a person
Sometimes the key has to reach a human: a contractor who needs it for a deployment tool, a developer joining a project before SSO is set up, a vendor integration that wants it pasted into their dashboard. Email, Slack and tickets all keep copies, and a 40-character secret in any of them is readable for years.
The safe routine takes a minute:
- Create a key for that person on a dedicated IAM user with the policy their task needs and nothing more. Do not share a key that anything else uses.
- Paste only the secret access key into a one-time secret link. It is encrypted in your browser before it is stored, the stored copy is destroyed the first time the link is opened, and the link expires after an hour, a day or a week if nobody opens it.
- Send the link with one line of context. Send the access key ID, the region and the profile name in a separate message; none of those is secret on its own.
- Add a passphrase on a Pro account for anything beyond read-only, and pass it on by text or on a call.
- Confirm they opened it. If the link says it was already viewed and they did not open it, deactivate the key and start over.
- Deactivate the key when the engagement ends, and delete it after.
The API key guide has the same pattern for other providers, and secure link sharing for developers covers scripting the handoff for onboarding.