Last updated on 23rd May 2026

How to Install AWS CLI on Ubuntu and Linux

The AWS Command Line Interface (CLI) is how you talk to AWS from a shell instead of the console. You'll want it on your laptop for ad-hoc commands and on any server that uploads to S3, deploys to ECS, or calls almost any AWS API directly. This guide walks through installing AWS CLI v2 on Ubuntu and other Linux distributions, plus macOS and Windows for completeness, and then configures it so the first aws command actually works.

Note: AWS CLI v1 (the pip install awscli package) is no longer the supported path. AWS CLI v2 is a standalone binary with no Python dependency, faster startup, and the only version that supports newer services and SSO. Install v2 unless you have a specific reason to stay on v1.

Install on Ubuntu and Debian

The official AWS-published bundle is the recommended method on Ubuntu, Debian, and any Debian-derived distribution. It works the same way on Ubuntu 20.04, 22.04, 24.04, and current Debian releases.

sudo apt-get update
sudo apt-get install -y unzip curl

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

The installer drops the aws binary into /usr/local/bin/aws and a support directory at /usr/local/aws-cli/. The download is around 50 MB; allow a minute on a slow connection.

For ARM64 hardware (Graviton instances, Raspberry Pi, Apple Silicon under Linux), use the aarch64 bundle:

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

Clean up the downloaded files when you're done:

rm -rf awscliv2.zip aws/

What about `apt install awscli`?

Ubuntu's official repositories ship AWS CLI v1, often several minor versions behind the upstream release. It's fine for shell experimentation; it's the wrong tool when a runbook depends on a recent service or flag. Stick with the AWS-published bundle for anything reproducible.

What about Snap?

sudo snap install aws-cli --classic works and tracks AWS CLI v2. It's a reasonable choice on desktop Ubuntu where Snap is already the default packaging mechanism. On a server, the AWS-published bundle has fewer moving parts and is easier to mirror or cache for offline installs.

Install on Amazon Linux, Fedora, RHEL, and CentOS

The same bundle works. Amazon Linux 2023 actually ships with AWS CLI v2 preinstalled — check first:

aws --version

If aws --version reports v1 or the command isn't found:

sudo yum install -y unzip curl     # or sudo dnf install -y unzip curl on Fedora/RHEL 9+

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

If a v1 install is in the way, remove it first:

sudo yum remove -y awscli           # or: pip uninstall awscli

Install on macOS

Two options. The .pkg installer is the AWS-recommended path:

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

Homebrew is more idiomatic on a developer machine, and it tracks v2:

brew install awscli

After either install:

aws --version

Install on Windows

Download the MSI installer and run it:

https://awscli.amazonaws.com/AWSCLIV2.msi

Or install silently from PowerShell:

msiexec.exe /i https://awscli.amazonaws.com/AWSCLIV2.msi /quiet

Restart your terminal afterwards so the new PATH is picked up, then verify:

aws --version

Verify the installation

A clean install should respond like this:

aws --version

aws-cli/2.17.14 Python/3.12.6 Linux/6.8.0-31-generic exe/x86_64.ubuntu.24

The exact version will be whatever the bundle was when you downloaded it. To upgrade later, run the install steps again — the AWS-published install script does an in-place upgrade.

Configure credentials

The AWS CLI doesn't carry credentials by default. You give it credentials in one of three ways, listed in order of preference.

1. `aws configure` — for laptops

aws configure

The CLI prompts for four values:

AWS Access Key ID [None]: AKIA...
AWS Secret Access Key [None]: ...
Default region name [None]: us-east-1
Default output format [None]: json

The credentials are written to ~/.aws/credentials and the region/output settings to ~/.aws/config. Both files are plain INI:

# ~/.aws/credentials
[default]
aws_access_key_id = AKIA...
aws_secret_access_key = ...

# ~/.aws/config
[default]
region = us-east-1
output = json

You can edit them directly — useful for adding named profiles:

# ~/.aws/credentials
[default]
aws_access_key_id = AKIA...
aws_secret_access_key = ...

[staging]
aws_access_key_id = AKIA...
aws_secret_access_key = ...

Then target a profile with --profile staging on any command, or set the AWS_PROFILE environment variable for the duration of a shell:

export AWS_PROFILE=staging
aws s3 ls

2. Environment variables — for CI and one-off scripts

The CLI reads AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_DEFAULT_REGION, and optionally AWS_SESSION_TOKEN (for temporary credentials):

export AWS_ACCESS_KEY_ID=AKIA...
export AWS_SECRET_ACCESS_KEY=...
export AWS_DEFAULT_REGION=us-east-1

aws sts get-caller-identity

This is the right pattern for CI jobs and short-lived scripts. See the bash cheatsheet for clean patterns to load secrets from .env files without leaking them into shell history.

3. IAM roles — for EC2, ECS, Lambda, and other AWS-hosted compute

If the AWS CLI is running on an EC2 instance, ECS task, or Lambda function that has an attached IAM role, don't set any credentials at all. The CLI automatically picks up the instance role from the EC2 metadata service. This is the most secure pattern because there's no long-lived secret on disk for an attacker to steal.

# On an EC2 instance with an attached role — no configure step needed
aws sts get-caller-identity

If you see Unable to locate credentials and you're sure a role is attached, check that the metadata service isn't blocked by your VPC or firewall.

Smoke-test the configuration

aws sts get-caller-identity is the universal "are my credentials working?" command. It returns the IAM identity the CLI is currently using:

aws sts get-caller-identity

{
    "UserId": "AIDAEXAMPLEUSER",
    "Account": "123456789012",
    "Arn": "arn:aws:iam::123456789012:user/deploy-bot"
}

If you see your account ID and the IAM ARN you expected, configuration is complete.

Common installation problems

unzip: command not found — Install unzip first: sudo apt-get install -y unzip on Debian/Ubuntu, sudo yum install -y unzip on RHEL/Amazon Linux.

aws: command not found after installing — The installer placed the binary in /usr/local/bin/aws. Confirm that /usr/local/bin is in your PATH: echo $PATH | tr ':' '\n' | grep /usr/local/bin. If missing, add export PATH="/usr/local/bin:$PATH" to your shell profile.

Old aws binary still runs after upgrade — A v1 install via pip or the OS package may be earlier in your PATH. which -a aws shows every aws on the system; remove the old one with pip uninstall awscli or the relevant apt/yum command.

Could not connect to the endpoint URL — Usually a region problem: the service isn't available in your configured region, or the region name is wrong (us-east-1 not us-east1). Less commonly, the host has no network egress to AWS — check from inside the network with curl -fsSI https://sts.amazonaws.com.

Unable to locate credentials — Either no credentials are configured, or the AWS_PROFILE you've selected doesn't exist. aws configure list shows where the CLI is reading each setting from.

SSL certificate errors on older Linux — Update your CA bundle: sudo apt-get install -y ca-certificates && sudo update-ca-certificates. AWS CLI v2 bundles its own Python runtime but still uses the system trust store for TLS validation.

Next: actually use it

Once the CLI is working, the everyday commands for S3, EC2, ECR, and IAM are in the AWS CLI cheatsheet.

For DeployHQ users running AWS commands as part of a deployment, you don't need to install AWS CLI on your deploy server at all. The Custom Action protocol runs amazon/aws-cli:latest inside a curated Docker container during deployment, so an aws s3 sync or aws cloudformation deploy step happens with a clean, up-to-date AWS CLI every time — no host-side install to keep patched.

A few related guides on getting AWS workloads deployed from Git:

Deploy to AWS Elastic Beanstalk from DeployHQ — when you want a fully managed PaaS-style flow.
Serverless deployments to AWS Lambda — for the functions case.
Deploying applications to AWS ECS / EKS using shell servers — for container workloads.
Implementing server backups with AWS S3 — for the aws s3 sync backup pattern.

Need help? Email support@deployhq.com or follow @deployhq on X.