Alright, let’s get you set up with the modern toolbelt. The AWS CLI v2 is a massive improvement over its predecessor—faster, handles IAM roles better, and doesn’t require a separate Python installation. We’re going to do this the right way, which means avoiding the OS package managers (apt, yum, brew) like the plague for this particular install. Their packages are often horrifically out of date, and wrestling with a three-year-old CLI version is a special kind of hell I won’t subject you to. We’re going straight to the source.

The One-Liner Install for Linux/macOS

For most people on Linux or macOS, this is the way. It downloads the latest bundle, unpacks it, and runs the install script. It’s idempotent, meaning you can run it again to update. Open a terminal and run this beautiful mess:

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

For macOS, just swap the URL. The designers, in a rare fit of sense, made it almost identical:

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

Why sudo? Because the installer plops the aws executable into /usr/local/bin and the bulk of the files into /usr/local/aws-cli, both of which are usually owned by root. This keeps things clean and in the standard PATH.

The Manual Install (For the Control Freaks)

Maybe you don’t trust one-liners. Maybe you’re on a weird architecture. Maybe you just like pain. I get it. The manual process gives you total control.

  1. Download the latest package for your OS from the official AWS CLI v2 page. Don’t Google it—you’ll get SEO garbage. Go straight to https://aws.amazon.com/cli/.
  2. Unzip it. For the Linux zip, you’d do:
    unzip awscliv2.zip
  3. Now, run the install script without sudo. This lets you specify your own install directory.
    ./aws/install -i ~/aws-cli -b ~/bin
    Here, -i is where the main files go, and -b is where the symlink to the aws executable is placed. You must then add that ~/bin directory to your PATH in your shell profile (.bashrc, .zshrc).
    echo 'export PATH="$HOME/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc

Verifying the Install Wasn’t a Lie

Once installed, run the following to make sure it actually worked and isn’t some ghost of CLI v1 haunting your machine.

aws --version

You should get back something like aws-cli/2.15.0 Python/3.11.6 Linux/6.2.0-1014-aws botocore/2.15.0. The key is that major version 2.x.x. If you see a 1.x.x, you’ve got an old version lurking somewhere. The PATH is lying to you. Find it and nuke it from orbit.

The “Oh Right, Permissions” Step

The CLI is installed, but if you run aws s3 ls right now, it will scream at you about missing credentials. That’s good! It means it’s working. It has no idea who you are. We fix that by configuring it.

aws configure

This will prompt you for four things:

  1. AWS Access Key ID: Get this from the IAM console for a user with programmatic access. Please tell me you’re not using your root account keys.
  2. AWS Secret Access Key: The password-equivalent for that key. Guard it like one.
  3. Default region name: Type a sensible one like us-east-1 or eu-west-1. This saves you from having to type --region in every single command.
  4. Default output format: I always choose json. It’s the most verbose and parseable. text is for quick eyeballing, and table is for when you’re feeling fancy but regret it later.

This info gets stored in ~/.aws/credentials and ~/.aws/config. You can edit these files directly, which is essential for working with multiple profiles.

Working with Multiple AWS Profiles

You are not a one-account pony. You’ll have a personal account, a work account, a “what was I even doing here” account. The CLI handles this with profiles.

Rerun aws configure but with a --profile flag.

aws configure --profile my-crazy-side-project

Now, when you want to run a command against that profile, you specify it:

aws s3 ls --profile my-crazy-side-project

To make a profile your default, you can just set the AWS_DEFAULT_PROFILE environment variable in your shell startup file:

export AWS_DEFAULT_PROFILE=my-crazy-side-project

The real power users just set the AWS_PROFILE env var on a per-command basis in their terminal. This keeps things clean and explicit.

The Classic “It’s Not Working” Pitfalls

  • “Command not found”: Your PATH is wrong. The install script didn’t put aws in a directory your shell can see. Check where it landed (/usr/local/bin is usually safe) and adjust your PATH or re-install without custom directories.
  • “Unable to locate credentials”: You haven’t run aws configure, your profile name is wrong, or your secret key has spaces/typos. It happens to the best of us.
  • Weird Permission Errors on macOS: If you’re on a newer Mac with Apple Silicon, sometimes the curl -> pkg path can get fussy with permissions. The manual download and install from the .pkg file via the GUI is often more reliable. It’s absurd, but true.

And that’s it. You’re now equipped with the primary tool for not having to click through that godforsaken console. Go forth and automate.