Configuring Credentials Without Footguns

Priya pushed a side project to a public GitHub repo on a Friday evening. Embedded in the code: a hardcoded AWS access key. By Monday morning, the key had been scraped, used to spin up 60 GPU instances for crypto mining, and the bill was at $11,200.

AWS forgave the charges — they do, usually, once. The lesson stuck. This chapter is about never being Priya.

What an Access Key Actually Is

An access key is a pair: an Access Key ID and a Secret Access Key. Together, they authenticate API calls from the SDK or the CLI as a specific IAM user. Anyone who has them is, for AWS's purposes, that user.

Two truths follow:

• A leaked access key is a leaked identity;
• The blast radius is exactly equal to that identity's permissions. This is why long-lived access keys belong to almost nobody. We will see why in the chapter on STS.

The Credential Resolution Order

When your SDK or CLI needs to authenticate, it walks through a fixed search order:

• Environment variables (AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, optionally AWS_SESSION_TOKEN);
• The shared credentials file at ~/.aws/credentials;
• The shared config file at ~/.aws/config;
• Container credentials when running in ECS;
• Instance metadata service (IMDS) for EC2 instances;
• SSO credentials from AWS IAM Identity Center. It uses the first one it finds. This means if you forget to unset an environment variable, it can silently override the profile you thought you were using.

The Right Way on Each Platform

The pattern that scales:

• On your laptop — use named profiles in ~/.aws/credentials with aws sso login instead of long-lived keys whenever possible;
• On EC2 — attach an IAM role to the instance. The SDK fetches credentials automatically from IMDS, no keys on disk;
• In Lambda — the function's execution role provides credentials automatically. Just call the SDK, no setup needed;
• In ECS/Fargate — attach a task role, same idea;
• In GitHub Actions — use OIDC federation to assume a role, never store an access key as a secret. The common thread: roles over keys, every time.

Named Profiles Save You

Most developers work across multiple AWS accounts — personal, work, client A, client B. The ~/.aws/credentials file supports named profiles:

[personal]
aws_access_key_id = AKIA...
aws_secret_access_key = ...
 
[work-prod]
sso_session = work
sso_account_id = 123456789012
sso_role_name = DeveloperRole

Then specify the profile in any CLI or SDK call:

aws s3 ls --profile work-prod

Or set AWS_PROFILE=work-prod in the shell. This prevents the classic mistake of running a delete command against the wrong account.

The Footguns to Avoid

A short list of mistakes that have ended careers, or at least weekends:

• Hardcoding access keys in source code;
• Committing .env files containing AWS keys;
• Sharing an IAM user's keys with a teammate "just for today";
• Using the root user's access key, which should not exist in the first place;
• Embedding keys in a frontend app shipped to user browsers;
• Storing keys in CI/CD secrets when the CI tool supports OIDC instead. Priya now keeps a checklist taped to her monitor. She has not pushed a key since.