Install AWS CLI and Configure Credentials

You've built on AWS with the console, clicked through dashboards, and maybe even launched an EC2 instance. But as soon as you need to automate anything—sync files to S3, spin up resources, or deploy code—the browser becomes your enemy. Clicking is slow, error-prone, and impossible to script. The AWS CLI turns that around: it gives you direct, terminal-based control over your entire AWS account. In this lesson, you'll install the AWS CLI and securely configure your credentials, so you can run the same actions you'd do in the console, but faster and repeatable. By the end, you'll have a working setup that will be the foundation for every automation you write from here on out.

The problem this lesson solves

If you're a developer, you live in the terminal. You git push, npm install, and docker run without a second thought. But when you need to interact with AWS, the default is the Management Console—a web UI with a thousand menus, region selectors, and permission panels. Here's where it hurts:

• Slow: Every action takes multiple clicks and page loads.
• Not scriptable: You can't write a shell script to click through the console.
• Hard to reproduce: A human can forget a step, making your infrastructure drift.
• Error-prone: One wrong toggle can expose resources or rack up costs.

More critically, the console's security model encourages bad habits. To use the console, you log in with your root or IAM user's password. But for programmatic access, AWS doesn't want you to use passwords—it uses access keys (a key ID and a secret) that authenticate API calls. Without the CLI, you might end up embedding those keys in your application code or configuration files, which is a security disaster waiting to happen (and is one of the top causes of compromised AWS accounts).

The AWS CLI solves all of this: it gives you a clean, scriptable interface to every AWS service, and when configured properly, it keeps your credentials out of your code.

Core concept / mental model

The AWS CLI is like a remote control for your AWS account. Instead of pressing buttons on the dashboard, you type commands that send API requests to AWS's public endpoints. Under the hood, every command you run—whether aws s3 ls or aws ec2 describe-instances—is an HTTP request with two crucial parts:

1. Authentication: Your access key ID and secret access key prove who you are.
2. Authorization: The IAM policies attached to your user determine what you're allowed to do.

Think of it this way: your access keys are like a digital badge that says "I am this IAM user." The CLI attaches that badge to each request. AWS checks the badge and then checks your user's permissions: allowed or denied.

The CLI also introduces a config file (.aws/config) and a credentials file (.aws/credentials) that live in your home directory. The config file holds settings like the default region and output format. The credentials file stores your access keys, but you should never edit it by hand—use the aws configure command to manage it securely.

Here's a simple text diagram of where each piece lives:

Your terminal
  → aws CLI (reads .aws/config and .aws/credentials)
    → makes HTTPS requests to AWS API endpoints
      → IAM validates your access keys
        → your policies allow or deny the action

In this lesson, you'll build each layer of that chain correctly.

How it works step by step

Installing and configuring the AWS CLI follows a logical order. Let's break it down:

1. Install the CLI binary on your machine (macOS, Windows, or Linux).
2. Create an IAM user in the AWS console (or using another tool) that will represent your programmatic identity.
3. Generate an access key pair for that user.
4. Run aws configure to store the keys, default region, and output format.
5. Verify the setup with a simple command like aws sts get-caller-identity.
6. Optionally, improve security with named profiles or environment variables later.

Each step matters. Skipping the IAM user (and using your root account keys) is a serious security mistake—AWS's best practice is to never use root credentials for programmatic access. So we'll create a dedicated IAM user with only the permissions it needs.

Let's get into the hands-on part.

Hands-on walkthrough

We'll go step by step. First, install the CLI on your operating system. Then, create an IAM user and configure your credentials.

Step 1: Install the AWS CLI

Pro tip: The AWS CLI v2 is the current standard. It includes new features and is bundled with everything you need. Don't use the older v1 unless you have a legacy reason.

macOS

If you use Homebrew (and if you're a developer on macOS, you probably do), installing is one line:

brew install awscli

After installation, verify with:

aws --version

You should see something like aws-cli/2.15.3 Python/3.11.8 Darwin/23.5.0 source/x86_64. The version may be newer, but the format is similar.

Windows

Download the installer from the official AWS docs, or if you use a package manager like Chocolatey or Scoop:

choco install awscli
# or
scoop install awscli

Restart your terminal after installing, then run aws --version to confirm.

Linux

For most Linux distributions, use the bundled installer from AWS:

curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"
unzip awscliv2.zip
sudo ./aws/install

Then verify:

aws --version

If you're on a distro with apt or yum, there's also a package manager route, but the official installer ensures you get the latest v2.

Step 2: Create an IAM user (with access keys)

Now that the CLI is installed, you need credentials. Do not use your root account. Here's the console path:

1. Log in to the AWS Management Console as your root user (or an admin IAM user).
2. Go to IAM > Users > Create user.
3. Enter a name like dev-cli.
4. Select Programmatic access (the option to enable access keys).
5. Attach a policy—for development, you might attach AmazonS3FullAccess for a start, but for real projects, use a scoped-down policy.
6. After creation, click Create access key and download or copy both the Access Key ID and Secret Access Key. The secret is shown only once.

Warning: Treat your secret access key like a password. Never share it, never paste it into code or chat. If you lose it, delete the access key in IAM and create a new one.

Step 3: Configure the CLI securely

Now, move to your terminal and type:

aws configure

The CLI will prompt you interactively:

AWS Access Key ID [None]: AKIAIOSFODNN7EXAMPLE
AWS Secret Access Key [None]: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
Default region name [None]: us-east-1
Default output format [None]: json

For the region, choose the one closest to you or your target users (e.g., us-west-2). The output format can be json, text, or table. json is best for scripting.

This command writes two files in your home directory:

• ~/.aws/credentials (contains your keys)
• ~/.aws/config (contains region and output)

You can check them with:

cat ~/.aws/credentials
cat ~/.aws/config

But do not edit them manually—use aws configure or the --profile flag for multiple accounts.

Step 4: Verify your setup

The quickest sanity check is to ask AWS who you are:

aws sts get-caller-identity

You should see output like:

{
    "UserId": "AIDAEXAMPLE",
    "Account": "123456789012",
    "Arn": "arn:aws:iam::123456789012:user/dev-cli"
}

If you see that, congratulations—your CLI is authenticated and ready to make API calls.

Test with a real command, like listing your S3 buckets (if you have none, it will return an empty list):

aws s3 ls

Step 5: (Optional) Use a named profile for multiple accounts

If you manage multiple AWS accounts (e.g., personal and work), don't overwrite your credentials. Use profiles:

aws configure --profile work

This creates separate entries in the credentials file. To use a profile with any command, add --profile work:

aws s3 ls --profile work

You can also set the AWS_PROFILE environment variable to avoid typing it every time.

Compare options / when to choose what

You now have a few ways to configure credentials. Each has its place:

When to choose what: For local development, aws configure with profiles is the sweet spot. For CI/CD pipelines, use environment variables or IAM roles. For long-running EC2 instances, an IAM role is the only secure choice.

Troubleshooting & edge cases

Even with a smooth setup, you'll hit hiccups. Here are the common ones and how to fix them.

"Command not found: aws"

Right after installation, the terminal may not see the CLI. This usually means your PATH isn't updated. Restart your terminal, or log out and back in. On Windows, open a new PowerShell window. If it still fails, reinstall and ensure the installation directory is in your system PATH.

"AccessDenied" when running a command

For example, aws s3 ls returns:

An error occurred (AccessDenied) when calling the ListBuckets operation: ...

This means your IAM user doesn't have permission to list S3 buckets. Either attach the AmazonS3FullAccess policy (for practice) or create a custom policy that allows s3:ListAllMyBuckets. It's not a credential issue—it's a permissions issue.

"InvalidAccessKeyId" error

An error occurred (InvalidAccessKeyId) when calling the ListBuckets operation: ...

This means the access key ID is wrong or missing. Check your ~/.aws/credentials file, or re-run aws configure and paste the correct key ID.

"SignatureDoesNotMatch" error

This means your secret access key is incorrect. You might have a typo or swapped values. Re-run aws configure and carefully paste the secret key.

Using environment variables and not seeing them take effect

If you set AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY, the CLI prioritizes them over the config files. If you're still seeing your old profile's actions, check if the AWS_PROFILE or AWS_DEFAULT_PROFILE environment variables are set and overriding your command-line profile.

Forgot which profile you're using?

You can always run:

aws configure list

This shows which profile, credentials, and region are currently active.

What you learned & what's next

You now have a working AWS CLI with secure credentials. You learned how to install the CLI on your OS, create an IAM user with least-privilege access, generate access keys, and configure them with aws configure. You verified the setup with aws sts get-caller-identity, and you know how to use named profiles for multi-account workflows. You also know the common errors and how to fix them, so you can troubleshoot confidently.

These skills are the foundation for everything else in this AWS Tutorial track. The next lesson will dive into AWS regions and zones—where your resources live and how to choose the right one for performance and cost. You'll use the CLI you just set up to query the available regions and even create your first resource. Onward!