Right, let’s get your tools sharpened. Setting up the AWS CLI is like getting a master key to the entire AWS kingdom. It’s the no-nonsense, text-based way to tell AWS what to do, and it doesn’t care if you’re in a GUI mood or not. We’re going to set it up properly so it doesn’t come back to bite you later.

First, the installation. You’re not downloading some sketchy .exe from a random website. You’ll use pip, Python’s package manager. Yes, it’s written in Python. No, you don’t need to know Python. The irony is not lost on me.

pip install awscli --upgrade --user

The --user flag is your friend. It installs it just for your user account, avoiding the need for scary sudo commands that can muck up your system’s Python packages. If aws --version doesn’t work immediately after installation, your PATH variable is probably napping. On Unix-like systems, you need to add the user base bin directory to it. It’s usually ~/.local/bin on Linux or ~/Library/Python/3.x/bin on macOS. Go wake it up.

Now, the most important part: credentials. The CLI isn’t psychic; it needs to know who you are. You’ll create an IAM user in the AWS Console, grant it the necessary permissions (start with least privilege, for the love of all that is holy), and generate an Access Key ID and a Secret Access Key. This is your username and password for the API. Guard the Secret Key like it’s the actual password to your bank account, because in cloud terms, it is.

The clean, maintainable way to handle these is with the configure command. It stashes them away in a ~/.aws/credentials file with sane permissions.

aws configure

It’ll prompt you for that Access Key ID, Secret Key, default region (like us-east-1), and default output format (I use json because it’s parseable and readable). This creates a default profile. For anything more serious than a pet project, you’ll use named profiles. This is non-negotiable if you juggle multiple AWS accounts (and you will).

aws configure --profile my-awesome-project-dev

Now you can specify which profile to use with --profile my-awesome-project-dev on any command. To make this even more robust, you can set environment variables like AWS_PROFILE or AWS_ACCESS_KEY_ID directly. The CLI’s hierarchy for finding credentials is a thing of beauty and confusion. It checks in this order: 1) Command line flags, 2) Environment variables, 3) The AWS credentials file (~/.aws/credentials), 4) The CLI config file (~/.aws/config). The first one it finds, it uses. This is powerful but also the source of many “why is it using the wrong account?!” headaches. Be consciously aware of which profile or set of credentials is active.

Let’s test it. Don’t just assume it worked. Run something safe and read-heavy.

aws sts get-caller-identity --profile my-awesome-project-dev

This will tell you exactly which IAM user or role the CLI is using. It’s the cloud equivalent of “who am I?” and it’s the first command you run when things are broken.

Taming the Output

The default output is… fine. But when you describe-instances, you get a firehose of JSON. The AWS CLI has a secret weapon called the JMESPath query language. It lets you slice and dice that JSON output right in the command. It’s the difference between getting a whole cow and getting a perfectly grilled steak.

Want just the Instance IDs and their state from EC2?

aws ec2 describe-instances \
  --query 'Reservations[].Instances[].[InstanceId, State.Name]' \
  --output text

It takes some practice, but it turns the CLI from a blunt instrument into a scalpel. Use --output table for a quick, human-readable view when you’re first constructing your query.

The Rough Edges

Let’s be honest. The AWS CLI is a gigantic, monolithic Python application. The pip install pulls down a beast because it includes every single service client. Updates are all-or-nothing. The argument syntax can be inconsistent; sometimes you pass a JSON blob for a parameter, sometimes it’s a list of strings. You will inevitably forget the syntax for passing a list of values and have to go to the docs. It happens to all of us. The docs, by the way, are excellent. Use aws ec2 run-instances help liberally. It’s not a sign of weakness; it’s a sign of not wanting to accidentally bankrupt your company.