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. ```bash 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: ```bash 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: ```bash 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: ```bash aws --version ``` If `aws --version` reports v1 or the command isn't found: ```bash 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: ```bash sudo yum remove -y awscli # or: pip uninstall awscli ``` ## Install on macOS Two options. The .pkg installer is the AWS-recommended path: ```bash 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: ```bash brew install awscli ``` After either install: ```bash aws --version ``` ## Install on Windows Download the MSI installer and run it: ``` https://awscli.amazonaws.com/AWSCLIV2.msi ``` Or install silently from PowerShell: ```powershell msiexec.exe /i https://awscli.amazonaws.com/AWSCLIV2.msi /quiet ``` Restart your terminal afterwards so the new `PATH` is picked up, then verify: ```powershell aws --version ``` ## Verify the installation A clean install should respond like this: ```bash 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 ```bash 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: ```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**: ```ini # ~/.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: ```bash 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): ```bash 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](https://www.deployhq.com/cheatsheets/bash) 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. ```bash # 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: ```bash aws sts get-caller-identity ``` ```json { "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](https://www.deployhq.com/cheatsheets/aws-cli). 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](Article: deploy-with-cloudformation) 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](https://www.deployhq.com/blog/elevate-your-aws-deployments-introducing-deployhq-s-aws-elastic-beanstalk-integration) — when you want a fully managed PaaS-style flow. - [Serverless deployments to AWS Lambda](https://www.deployhq.com/blog/serverless-deployments-with-deployhq-aws-lambda-vercel-and-netlify) — for the functions case. - [Deploying applications to AWS ECS / EKS using shell servers](https://www.deployhq.com/blog/deploying-applications-to-aws-ecs-eks-using-deployhq-shell-servers) — for container workloads. - [Implementing server backups with AWS S3](https://www.deployhq.com/blog/how-to-implement-server-backups-with-aws-s3) — for the `aws s3 sync` backup pattern. Need help? Email [support@deployhq.com](mailto:support@deployhq.com) or follow [@deployhq on X](https://x.com/deployhq).