Steve Kinney

Setting Up the AWS CLI

The AWS Management Console is fine for clicking around and exploring, but you’re not going to deploy a frontend by clicking buttons. The AWS CLI (Command Line Interface) is how you’ll interact with AWS from your terminal—syncing files to S3, creating CloudFront invalidations, invoking Lambda functions, and everything else you’ll do in this course. It’s also what your CI/CD pipeline will use under the hood.

If you want AWS’s canonical version of the profile and credential file setup, the AWS CLI configuration file guide is the official reference.

If you’ve used tools like vercel or netlify CLI, the AWS CLI serves a similar purpose. The difference is that it covers every AWS service, so the surface area is much larger. You won’t need to memorize it all—just the commands for the services you’re using.

Installing AWS CLI v2

AWS CLI v2 is the current version. Don’t install v1—it’s effectively deprecated and missing features you’ll want.

macOS

The simplest path is the official .pkg installer:

curl "https://awscli.amazonaws.com/AWSCLIV2.pkg" -o "AWSCLIV2.pkg"
sudo installer -pkg AWSCLIV2.pkg -target /

If you prefer Homebrew:

brew install awscli

Linux

Download, unzip, and run the installer:

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

For ARM-based Linux (like Graviton instances):

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

Verify the Installation

aws --version

You should see something like aws-cli/2.x.x Python/3.x.x followed by your platform info. If you get “command not found,” the install didn’t add aws to your PATH—check that /usr/local/bin is in your $PATH.

Creating Access Keys

Before you can configure the CLI, you need access keys for your IAM user. Access keys are a pair of credentials—an Access Key ID and a Secret Access Key—that let the CLI authenticate as your IAM user.

  1. Sign into the AWS Console as your admin user (not root—remember, root stays locked away).
  2. Navigate to IAM > Users > admin.
  3. Click the Security credentials tab.
  4. Scroll to Access keys and click Create access key.
  5. Select Command Line Interface (CLI) as the use case.
  6. Acknowledge the recommendation about alternatives (AWS wants you to know that short-lived credentials via IAM Identity Center are more secure—true, but access keys are simpler for learning).
  7. Click Create access key.
Security credentials tab for an IAM user showing the Access keys section and the Create access key button.

You’ll see your Access Key ID and Secret Access Key. This is the only time the secret key is shown. Copy both values and store them in your password manager.

If you lose the secret access key, you can’t retrieve it. You’ll have to delete the key pair and create a new one. Treat these credentials like passwords—they grant the same level of access as logging into the console as that user.

Configuring the CLI

Run aws configure to set up your default profile:

aws configure

It prompts for four values:

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

Enter your access key ID, secret access key, us-east-1 as the region, and json as the output format. These values get written to two files in your home directory:

  • ~/.aws/credentials—stores your access keys
  • ~/.aws/config—stores region and output preferences

We use us-east-1 throughout this course because it’s the region where CloudFront certificates and Lambda@Edge functions must be created. Using a single region for everything keeps things simple while you’re learning.

Named Profiles

The default profile works fine when you have one AWS account. But if you ever have a personal account and a work account—or a staging environment and a production environment—you’ll want named profiles.

Create a named profile by adding --profile to the configure command:

aws configure --profile personal

This creates a separate set of credentials stored under the personal profile name. To use it, add --profile personal to any CLI command:

aws s3 ls \
  --profile personal \
  --region us-east-1 \
  --output json

The underlying file structure looks like this:

~/.aws/credentials

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

[personal]
aws_access_key_id = AKIAI44QH8DHBEXAMPLE
aws_secret_access_key = je7MtGbClwBF/2Zp9Utk/h3yCo8nvbEXAMPLEKEY

~/.aws/config

[default]
region = us-east-1
output = json

[profile personal]
region = us-east-1
output = json

Notice the asymmetry: in the credentials file, the section header is just [personal]. In the config file, it’s [profile personal]. This inconsistency is annoying, but it’s how AWS designed it. (Honestly, I don’t know why. It trips everyone up at least once.) The [default] profile doesn’t use the profile prefix in either file.

You can also set the AWS_PROFILE environment variable to avoid typing --profile on every command:

export AWS_PROFILE=personal

Verifying Your Credentials

The best way to confirm your CLI is properly configured is the get-caller-identity command:

aws sts get-caller-identity \
  --region us-east-1 \
  --output json

This returns the identity associated with your credentials:

{
  "UserId": "AIDAIOSFODNN7EXAMPLE",
  "Account": "123456789012",
  "Arn": "arn:aws:iam::123456789012:user/admin"
}

If you see your account ID and the ARN of your admin user, everything is working. This command requires no special permissions—it works even if the user has no policies attached. It’s the AWS equivalent of whoami.

If you get an error like The security token included in the request is invalid, your access keys are wrong. Double-check what you entered, or delete the key pair in the console and create a new one.

Run aws sts get-caller-identity any time you’re unsure which credentials the CLI is using. It’s especially useful when you have multiple profiles and want to confirm you’re not accidentally running commands against your production account.

A Quick Test: List S3 Buckets

Let’s make sure the CLI can actually talk to a service. Run:

aws s3 ls \
  --region us-east-1 \
  --output json

If you haven’t created any buckets yet, you’ll get an empty response. That’s fine—it means the CLI authenticated successfully and S3 responded. If you get an access denied error, your admin user’s permissions might not be set up correctly—revisit the user setup in Creating and Securing an AWS Account.

Security Hygiene for Access Keys

A few rules to keep your credentials safe:

  • Never commit access keys to version control. Add ~/.aws/ to your global .gitignore. If a key ends up in a public GitHub repo, bots will find it within minutes and start spinning up resources.
  • Don’t put access keys in environment variables in CI/CD unless you’re using secrets management. GitHub Actions has encrypted secrets. Use them.
  • Rotate keys periodically. You can have two active access keys per IAM user, which means you can create a new key, update your configuration, verify it works, and then deactivate the old key without downtime.
  • Delete keys you’re not using. If you created a key for testing and no longer need it, delete it. An unused key is an attack surface with no benefit.

If you ever suspect a key has been compromised—you accidentally logged it, it appeared in a build output, anything—deactivate it immediately in the IAM console. Don’t wait to create a replacement first. Deactivate, then create a new one. Minutes matter.

You now have a working AWS CLI installation connected to your IAM user. Every CLI command in the rest of this course assumes this setup. When we create S3 buckets, configure CloudFront, or deploy Lambda functions, we’ll be using these same credentials from the same terminal.

Last modified on .