How To Install AWS CLI on Ubuntu 26.04 LTS

Install AWS CLI on Ubuntu 26.04

You provisioned a fresh Ubuntu 26.04 LTS box and logged in over SSH. The deployment script then fails on the first line with aws: command not found. That is the most common way people find out the AWS Command Line Interface isn’t there yet.

It’s a small problem with a few traps. Ubuntu 26.04 LTS, codenamed “Resolute Raccoon”, shipped on April 23, 2026, and Canonical lists standard support running to May 2031. A lot of older tutorials were written for Ubuntu 18.04 or 20.04. They tell you to run apt install awscli and move on. On a modern LTS that advice can leave you on the wrong major version, or on a build that trails AWS’s own releases by months.

There are three realistic ways to install the tool. You can run AWS’s official installer, install the Snap package, or use a container image. Each suits a different job. A laptop, a long-lived EC2 instance, a CI runner and a hardened bastion host don’t need the same approach.

This guide covers all three. It starts with the method most admins should use on production servers, then moves through verification, credentials, updates, permissions, performance and security. The troubleshooting section comes last, because that is what you’ll read at 2 AM when a pipeline breaks.

What the AWS CLI Is and Why the Version Matters

The AWS CLI is a unified command-line tool for managing AWS services. One binary talks to S3, EC2, IAM, CloudWatch, Lambda, ECR and the rest of the platform. Admins use it for scripted backups, infrastructure checks, log retrieval, secret rotation and CI/CD deployment steps.

Version 2 is the current generation. AWS documents it as the recommended release and ships it as a self-contained bundle. Version 1 still exists, but AWS only documents it through legacy channels such as the v1/stable Snap channel. If a tutorial tells you to use pip install awscli, it is describing v1.

The practical differences matter more than the version numbers:

  • v2 bundles its own Python runtime, so it doesn’t depend on whatever system Python your distro ships.
  • v2 has better support for IAM Identity Center (SSO) login flows.
  • v2 gives you auto-prompt mode, a built-in pager and improved output handling.
  • v1 installed through apt or pip is tied to system libraries, and it breaks in awkward ways after Python upgrades.

On a distro that moves its Python minor version between releases, the bundled runtime is a real advantage. A major apt upgrade is not going to snap your backup script in half.

Choosing an Installation Method

Pick the method before you type anything. Here is how the options compare in practice.

Method Version tracking Best for Main drawback
Official install script Latest, you update manually Production servers, automation Manual updates unless scripted
Official ZIP installer Any pinned version you choose Reproducible builds, air-gapped hosts A few extra steps
Snap (aws-cli --classic) Auto-refreshes in the background Desktops, quick dev machines Background refreshes can surprise you
Docker image Tag-based Containers, CI runners Credential and volume plumbing
apt install awscli Depends on the Ubuntu archive Rarely the right answer May not be v2, and lags upstream

The Snap package tracks v2 by default, and the v1 line is a separate channel. The Snap needs --classic confinement because the CLI has to read and write across your filesystem, for example ~/.aws and arbitrary upload paths.

For servers, the official installer is the one to default to. It gives you control over exactly when the version changes, and that matters when a deploy pipeline depends on predictable output.

Prerequisites Before You Install

Check a few things first. It takes a minute and avoids most of the beginner errors.

Confirm the OS and architecture.

lsb_release -a
uname -m

You want Ubuntu 26.04 and either x86_64 or aarch64. The architecture decides which installer you download. AWS publishes builds for both Linux x86 (64-bit) and Linux ARM. Graviton instances report aarch64, and grabbing the x86 zip there produces a confusing “cannot execute binary file” error.

Update the package index and install the tools you’ll need.

sudo apt update
sudo apt install -y curl unzip ca-certificates gnupg

A minimal cloud image often ships without unzip. That is one of the most common reasons the ZIP method fails on a fresh instance.

Check that you have sudo and outbound HTTPS.

curl -sI https://awscli.amazonaws.com | head -n 1

An HTTP/2 200 or a redirect means you’re fine. A timeout means your egress rules, proxy or DNS are the real problem, and no installer will fix that.

Know where your credentials will come from. On EC2 you should be using an instance profile. On a laptop or an on-prem server you’ll need an IAM Identity Center profile or a scoped IAM user. Settle this early, because it changes how you configure the tool later.

Method 1: Install AWS CLI v2 with the Official Install Script

AWS now documents a one-line install script as its recommended path. It downloads, verifies and installs the CLI in one step, and supports x86 and ARM.

curl -fsSL https://awscli.amazonaws.com/v2/install.sh | bash

By default this puts files in $HOME/.local/share/aws-cli and creates a symlink in $HOME/.local/bin. That is tidy for a single user, but $HOME/.local/bin isn’t always on PATH in non-interactive shells such as cron jobs and systemd units.

For a server where several accounts or services need the tool, install it system-wide:

curl -fsSL https://awscli.amazonaws.com/v2/install.sh | sudo bash -s -- --system

The --system flag installs to /usr/local/aws-cli and links into /usr/local/bin, and it requires sudo. You can list the other options with --help.

Piping a remote script into a root shell makes some sysadmins uncomfortable, and that instinct is healthy. On a locked-down production host, download the script first, read it, then run it:

curl -fsSL -o aws-install.sh https://awscli.amazonaws.com/v2/install.sh
less aws-install.sh
sudo bash aws-install.sh --system

It adds ten seconds and makes the change reviewable. If your change-management process requires an artifact, use Method 2 instead.

Method 2: Manual ZIP Installation with Signature Verification

This is the most controlled method. Use it when you need to pin a version, install on an air-gapped network, or prove the package wasn’t altered.

Step 1: Download the installer

For x86_64:

cd /tmp
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o "awscliv2.zip"

For ARM (Graviton, Raspberry Pi 4/5 on a 64-bit OS):

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

Step 2: Verify the download (recommended)

AWS publishes a detached GPG signature next to each archive, the same URL with .sig appended. Import AWS’s public key from the official documentation page and check that its fingerprint matches the one printed there. Don’t copy a fingerprint from a blog post, this one included. Then verify:

curl -o awscliv2.sig https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip.sig
gpg --verify awscliv2.sig awscliv2.zip

You’re looking for Good signature. A warning that the key isn’t certified with a trusted signature is normal, since you haven’t built a web of trust. What matters is that the fingerprint equals the one AWS publishes.

Step 3: Unzip and install

unzip -q awscliv2.zip
sudo ./aws/install

The -q flag stops unzip flooding your terminal with thousands of lines. Without extra flags, the installer puts files in /usr/local/aws-cli and creates a symlink in /usr/local/bin.

Step 4: Clean up

rm -rf aws awscliv2.zip awscliv2.sig

Leaving installer directories in /tmp or a home folder invites confusion later. Someone will run ./aws/install from the wrong place six months from now.

Pinning a Specific Version

Reproducibility matters in regulated or heavily audited environments. AWS lets you append the version to the filename. For example, awscli-exe-linux-x86_64-2.0.30.zip fetches 2.0.30:

curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64-2.0.30.zip" -o "awscliv2.zip"

That version is only AWS’s documentation example. Choose the release you actually need from the AWS CLI v2 changelog on GitHub. Pinning is useful when a newer release changes output or default behavior and you need to hold the line until you’ve tested.

Installing Without Root

Shared hosts and locked-down accounts sometimes don’t give you sudo. The installer accepts custom directories you can write to:

./aws/install -i ~/aws-cli -b ~/bin

Make sure ~/bin is on your PATH, or the command will still report “not found”.

Method 3: Install with Snap

Ubuntu ships with snapd, so this is the shortest route:

sudo snap install aws-cli --classic

The --classic flag is mandatory. Without it, Snap refuses and warns that the package uses classic confinement and can make changes outside the sandbox. That is expected behavior, not an error to work around.

Snap tracks v2 by default, and the v1 line lives in its own channel. One reviewer summed up the trade-off as a reasonable choice on desktop Ubuntu where Snap is already the default packaging mechanism.

On servers, be deliberate about Snap’s automatic refreshes. They keep you current, which is good for security. They also mean the CLI can change underneath a long-running job. If that bothers you, you can hold refreshes:

sudo snap refresh --hold=72h aws-cli
snap list aws-cli

Be careful with --hold durations. Holding indefinitely is a quiet way to end up with an outdated tool nobody remembers pinning.

Method 4: Run the AWS CLI in a Container

In CI or ephemeral jobs, you may not want to install anything on the host. AWS maintains official images, and the documentation lists the ECR Public and Docker images as supported options:

docker run --rm -it public.ecr.aws/aws-cli/aws-cli --version

To use your existing credentials and local files:

docker run --rm -it \
  -v ~/.aws:/root/.aws:ro \
  -v "$PWD":/aws \
  public.ecr.aws/aws-cli/aws-cli s3 ls

Mounting ~/.aws read-only limits the damage if something misbehaves. An alias in your shell profile makes this feel native, but the container is slower to start than a native binary, which adds up in tight loops.

Verify the Installation

aws --version
which aws

You should see something like aws-cli/2.x.x Python/3.x Linux/.... The documentation’s example output shows the format, with the Python version bundled inside the CLI and not necessarily matching your system Python.

Check which aws too. If you previously installed v1 through apt or pip, an old binary can shadow the new one. When aws --version prints aws-cli/1.x, you’re running the wrong copy:

type -a aws
hash -r

hash -r clears bash’s cached command location, which fixes the “I installed it but it still shows the old version” case surprisingly often.

Configure Credentials the Right Way

Installing the binary is half the job. Using it safely is the other half.

Option A: IAM Identity Center (SSO), preferred for humans

aws configure sso
aws sso login --profile my-profile

This issues short-lived credentials and avoids long-lived keys sitting on disk. It’s the best fit for engineers who log into servers interactively.

Option B: Instance profiles, preferred for EC2

If the server runs on EC2, attach an IAM role through an instance profile and run no aws configure at all. The CLI picks up temporary credentials from the instance metadata service automatically. Nothing is stored on disk, and nothing can leak from a backup of the home directory.

Option C: Access keys, for everything else

aws configure

You’ll be prompted for the access key ID, secret access key, default region and output format. Then tighten the permissions:

chmod 700 ~/.aws
chmod 600 ~/.aws/credentials ~/.aws/config

Credentials land in ~/.aws/credentials, and the file stays plain text. Never commit it to Git. Never bake it into an AMI or a Docker image. Rotate keys on a schedule, and give each key only the permissions the job needs.

Named Profiles and Environment Variables

Real servers usually talk to more than one account:

aws configure --profile staging
aws s3 ls --profile staging
export AWS_PROFILE=staging
export AWS_DEFAULT_REGION=ap-southeast-3

Environment variables take precedence over the shared files, which is useful in CI and a classic source of confusion when a stale AWS_ACCESS_KEY_ID is still exported in someone’s shell.

Test the Identity

aws sts get-caller-identity

This is the best first command to run. It needs no special permissions and tells you which account and principal you’re acting as. A surprising number of “S3 access denied” tickets turn out to be someone using the wrong profile.

Troubleshooting Common Errors

These are the failures that come up repeatedly in real environments.

aws: command not found

The binary isn’t on PATH. Check where it landed:

ls -l /usr/local/bin/aws ~/.local/bin/aws 2>/dev/null
echo $PATH

If you used the default user-level script install, add ~/.local/bin to PATH:

echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.bashrc
source ~/.bashrc

Cron has its own minimal PATH. Use the absolute path to aws in crontabs.

unzip: command not found

sudo apt install -y unzip

cannot execute binary file: Exec format error

You downloaded the wrong architecture. Check uname -m and fetch the matching installer.

You must specify a region

aws configure set region ap-southeast-3

You can also pass --region per command or export AWS_DEFAULT_REGION.

Unable to locate credentials

The CLI found no credentials in any of its sources. Run aws configure list to see where it is looking. On EC2, confirm the instance profile is attached and that IMDS isn’t blocked by a hop limit when you’re inside a container.

An error occurred (InvalidClientTokenId) or SignatureDoesNotMatch

Common causes:

  • A mistyped or truncated secret key
  • A trailing space copied from a password manager
  • A deactivated or deleted key
  • Clock skew

Check the clock first:

timedatectl status

AWS rejects requests signed with a clock that is off by more than a few minutes. Make sure systemd-timesyncd or chrony is active.

An error occurred (ExpiredToken)

Temporary credentials have lapsed. For SSO, run aws sso login again. For assumed roles, request fresh credentials. A stale AWS_SESSION_TOKEN in the environment will keep failing even after you fix the config file.

SSL validation failed or certificate errors

This usually points to a corporate proxy intercepting TLS, or missing CA certificates:

sudo apt install --reinstall -y ca-certificates
sudo update-ca-certificates

For a proxy with a custom CA, set AWS_CA_BUNDLE to the PEM file. Do not use --no-verify-ssl as a permanent fix. It disables the protection you actually want.

error: This revision of snap "aws-cli" was published using classic confinement

Add --classic to the install command.

Hangs with no output in scripts

Set AWS_PAGER="" as covered earlier, and check for a prompt waiting on input. Add --no-cli-pager in automation if you prefer an explicit flag.

Old version still appears after installing

Run type -a aws. Remove any v1 copy installed through apt or pip, then hash -r. If you want to clean it out:

sudo apt remove -y awscli
pip list 2>/dev/null | grep -i awscli

Debugging anything else

Add --debug to see request details, endpoints and the credential chain it tried:

aws s3 ls --debug 2>&1 | head -n 60

Scrub the output before sharing it. Debug logs can contain sensitive headers.

r00t is an experienced Linux enthusiast and technical writer with a passion for open-source software. With years of hands-on experience in various Linux distributions, r00t has developed a deep understanding of the Linux ecosystem and its powerful tools. He holds certifications in SCE and has contributed to several open-source projects. r00t is dedicated to sharing her knowledge and expertise through well-researched and informative articles, helping others navigate the world of Linux with confidence.

Related Posts