Right, let’s get you set up so you can actually do things with AWS instead of just staring at the login page. This is where we move from being a tourist to a resident. The CLI and SDKs are your primary tools, and they all have one thing in common: they need to know who you are. They do this using credentials. Let’s demystify how you give them those credentials without accidentally uploading your secret access key to a public GitHub repo (a classic rookie move, we’ve all had that heart-stopping moment).

The main way you’ll do this is with the aws configure command. It’s the friendly, get-you-started wizard. It asks you four things, and I’ll explain why each one matters.

$ aws configure
AWS Access Key ID [None]: AKIAIOSFODNN7EXAMPLE
AWS Secret Access Key [None]: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
Default region name [None]: us-west-2
Default output format [None]: json

Your Access Key ID is like your username—semi-public, often seen in logs. The Secret Access Key is your password. Treat it like one. If it gets out, someone can run up a truly impressive bill mining cryptocurrency on a thousand EC2 instances before you even get an alert. The aws configure command saves these, but where? This brings us to the most important file in your AWS world.

Where Your Secrets Actually Live

When you run aws configure, it writes to two files in a hidden directory (~/.aws/ on Linux/Mac or %USERPROFILE%\.aws\ on Windows):

  1. ~/.aws/credentials: This file holds the juicy bits—your access keys.
  2. ~/.aws/config: This file holds the less-sensitive settings—your region and output format.

This separation is actually a pretty sane design choice. It means you can tightly lock down the credentials file with strict file permissions (and you absolutely should) while the config file can be a bit more relaxed. Let’s look at the format.

The Credentials File: A Peek Under the Hood

Open your ~/.aws/credentials file. You’ll see something like this:

[default]
aws_access_key_id = AKIAIOSFODNN7EXAMPLE
aws_secret_access_key = wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

[project-alpha]
aws_access_key_id = AKIAI44QH8DHBEXAMPLE
aws_secret_access_key = je7MtGbClwBF/2Zp9Utk/h3yCo8nvbEXAMPLEKEY

See those brackets? [default] is your default profile. When you run an AWS CLI command without any extra flags, it uses this profile. The others ([project-alpha]) are named profiles. You use them by adding --profile project-alpha to your commands. This is how you juggle credentials for different accounts or projects without losing your mind. To use a named profile, you simply specify it:

# This uses the [default] profile
aws s3 ls

# This uses the [project-alpha] profile
aws s3 ls --profile project-alpha

The Config File: Your Default Settings

Now look at ~/.aws/config. It’s similar but has different settings:

[default]
region = us-west-2
output = json

[profile project-alpha]
region = eu-central-1
output = text

Notice the syntax for named profiles here is [profile profile-name]. This is a weird, inconsistent bit of syntax that trips everyone up. Why isn’t it just [project-alpha] like the credentials file? No one knows. It’s just one of those things you have to remember. The AWS designers presumably had a reason, but it’s lost to history.

The Hierarchy: How AWS Really Finds Your Credentials

This is critical. The AWS tools don’t just check the credentials file. They follow a specific chain of precedence, checking each location until it finds what it needs. Here’s the order, from highest to lowest priority:

  1. Command Line Options: --region, --profile, --aws-access-key-id (You wouldn’t actually use this last one; it’s a terrible idea.)
  2. Environment Variables: AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN, AWS_DEFAULT_REGION
  3. AWS Credentials File: ~/.aws/credentials
  4. AWS Config File: ~/.aws/config
  5. Container Credentials: (For ECS tasks)
  6. Instance Profile Credentials: (For EC2 instances using IAM roles)

Why does this matter? Let’s say you have AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY environment variables set and a [default] profile in your credentials file. The environment variables will win. This is a common source of confusion when you’re sure you configured a profile but the CLI seems to be using different keys. Always know what’s at the top of the hierarchy.

Best Practices and Pitfalls

  • Never, Ever Commit Your Credentials File: Add ~/.aws/ to your .gitignore_global file right now. I’ll wait. The number of exposed keys on GitHub is staggering and automated bots will find them and use them.
  • Set Strict File Permissions: Your credentials file should be readable only by you. The CLI might yell at you if you don’t. Heed its warning.
    chmod 600 ~/.aws/credentials
chmod 600 ~/.aws/config
  • Use Named Profiles for Everything: I barely use the [default] profile. Instead, I create explicit named profiles like [work-admin] and [personal-s3]. It prevents accidental actions in the wrong account. It forces you to be intentional.
  • For God’s Sake, Use IAM Roles: This is the biggest one. Access keys are for humans on their local machines. For anything else—EC2 instances, Lambda functions, ECS tasks—use IAM roles. Roles are the secure, managed, automatically-rotated way to grant permissions. Using hard-coded access keys on an EC2 instance is like storing your password on a post-it note stuck to the server. Just don’t.

The aws configure command is your easy on-ramp, but understanding the files it creates and the hierarchy it operates in is what separates a beginner from a proficient user. Now go configure something.