AWS: Command Not Found | Fix AWS CLI Path Issues

Guide / By

The “aws: command not found” error means the AWS CLI is missing from your system path or not installed correctly.

AWS: Command Not Found Error At A Glance

This message appears when your shell cannot find the aws program in any folder listed in the PATH variable. The AWS CLI might not be installed, might live in a folder that PATH does not scan, or might belong to another user account on the same machine. Sorting out which situation you have saves time and keeps you from changing settings that already work.

Think of PATH as a list of streets where your shell searches for tools. If none of those streets hold an aws file with execute permission, you end up with the aws: command not found warning. The fix is either to install the AWS CLI or to place the existing aws binary on a street that PATH already knows, or to extend PATH so it includes the folder where aws lives.

Why The Aws Command Not Found Message Appears

Several common patterns cause this error. Sorting them into simple buckets helps you test your own setup with clear steps instead of guesswork or random reinstall attempts that may not change anything.

  • No Aws Cli Installed — The aws tool is simply absent because the AWS CLI package was never installed on the device.
  • Installed For Another User — Someone installed the AWS CLI with a user flag or a virtual Python setup, so your current shell session cannot see it.
  • Path Does Not Include The Aws Folder — The AWS CLI lives in a directory that PATH never scans, such as a local bin folder that your profile does not add.
  • Old Shell Session — You installed the AWS CLI in one window but still use a shell session that started earlier and does not know about the new PATH settings.
  • Wrong Command Name — You typed a misspelled command such as awscli or used PowerShell aliases that do not point where you expect.

Each cause leaves a slightly different trail. If a package is missing, your system has no aws file at all. If PATH is the issue, you can often run aws by pointing to the full path, such as /usr/local/bin/aws on macOS, while the plain aws command still fails. That hint tells you to work on shell variables instead of reinstalling from scratch.

Fixing Aws Command Not Found On Linux And Mac

On Linux and macOS, the AWS: Command Not Found message almost always ties back to your package manager or shell profile. A short checklist keeps the work tidy and repeatable across machines so you can get the AWS CLI ready on both laptops and servers.

Check Whether Aws Exists Anywhere

  • Run Which Aws — In a terminal, type which aws or command -v aws to see whether the shell knows any path for aws.
  • Search Common Paths — If which returns nothing, run ls /usr/local/bin/aws /usr/bin/aws 2>/dev/null to see whether an aws file hides in those standard folders.
  • Try Full Path Execution — When you spot an aws binary with ls, run that full path directly, such as /usr/local/bin/aws --version, to confirm it works.

If the aws binary runs with a full path, your installation is fine and PATH needs a small tweak. If the binary is absent, you should install the AWS CLI fresh using a trusted package or the official bundle.

Install Or Reinstall With Your Package Manager

  • On Debian And Ubuntu — Use sudo apt-get update followed by sudo apt-get install awscli for the v1 package, or follow the official v2 installer instructions for newer features.
  • On Fedora And RHEL — Use sudo dnf install awscli or sudo yum install awscli depending on the release you run.
  • On Mac With Homebrew — Run brew install awscli, which usually places the aws binary in /opt/homebrew/bin on Apple silicon or /usr/local/bin on Intel Macs.
  • Install With Pip If Needed — When package managers lag behind, you can use pip install awscli --user, which drops aws into a user level bin folder such as ~/.local/bin.

Many machines already have Python and pip. A user level installation from pip keeps the AWS CLI separate from system packages, which can help on shared servers where you lack full root access. Just note that user level installs place aws in a folder that PATH might not include yet.

Fix Your Path So Aws Is Visible

  • Check Current Path — Run echo $PATH and scan for folders such as /usr/local/bin or ~/.local/bin where aws may live.
  • Add A Missing Folder — Edit ~/.bashrc, ~/.zshrc, or your shell profile and append a line like export PATH="$HOME/.local/bin:$PATH".
  • Reload Your Shell — Run source ~/.bashrc or open a new terminal window so the new PATH takes effect.
  • Test Again — Type aws --version with no path prefix to confirm the aws: command not found issue has cleared.

Shell profiles vary across Linux distributions and macOS versions, so the exact file name may change from machine to machine. The core pattern stays consistent though: export the bin folder that holds aws, reload the shell, then confirm that the aws command works without extra path hints.

Fixing Aws Command Not Found On Windows

On Windows, the aws: command not found message often appears inside PowerShell or Command Prompt once you start using AWS training material or scripts. The AWS CLI installer for Windows sets up most details for you, yet settings can slip out of place after account changes, path edits, or partial uninstalls.

Confirm Aws Cli Is Installed

  • Check The Start Menu — Open the Start menu and search for “AWS Command Line Interface” to see whether the program group exists.
  • Use Apps Settings — Open Settings, go to the list of installed apps, and search for “AWS Command Line Interface” to confirm the package version.
  • Open The Aws Folder — Use your file manager to open C:\\Program Files\\Amazon\\AWSCLIV2\\ and double click the aws executable.

If the AWS CLI runs from its installation folder but not from PowerShell or Command Prompt, you are facing a PATH problem instead of a missing program. When the CLI is absent even in Explorer, reinstalling from the official MSI installer is the cleanest route.

Repair Your Windows Path

  • Open Variable Settings — In the Start menu, search for the system variable dialog and open it, then click the button that edits variables for your account.
  • Edit The Path Entry — Under your user variables or system variables, select Path, click Edit, and look for entries that point to the AWS CLI folder path.
  • Add The Awscli Folder — If the AWS CLI path is missing, add a new entry such as C:\\Program Files\\Amazon\\AWSCLIV2\\ or the path where your aws.exe file lives.
  • Restart Your Shell — Close all PowerShell and Command Prompt windows, then open a fresh one and run aws --version to confirm success.

Older Windows setups can hold multiple PATH entries that reflect old tools, some of which might even point to earlier AWS CLI versions. Cleaning those entries while you add the new aws path keeps later upgrades smoother and reduces surprises later on.

Checking Your Aws Cli Installation And Version

Once aws works again, a quick health check helps you trust the tool during scripts that touch live cloud resources. The checks vary slightly by operating system but share the same idea: confirm that the aws command points to the expected file and that the CLI version matches your plans.

System Check Command Typical Aws Path
Linux which aws && aws --version /usr/bin/aws or /usr/local/bin/aws
macOS which aws && aws --version /opt/homebrew/bin/aws or /usr/local/bin/aws
Windows where aws & aws --version C:\\Program Files\\Amazon\\AWSCLIV2\\aws.exe

The version output tells you whether you run AWS CLI v1 or v2. More recent documentation and new service features usually assume v2, so plan upgrades on lab machines first, then roll out to shared workstations once you feel comfortable with the behavior.

Test Credentials And Simple Commands

  • Run Aws Configure — Use aws configure to set your access id, secret value, region, and output format in an interactive prompt.
  • List S3 Buckets — Run aws s3 ls to see whether the CLI can reach your account and list bucket names without permission errors.
  • Check The Config Files — On Linux and macOS, review ~/.aws/config and ~/.aws/credentials, and on Windows check the same paths under your user profile.

Running these quick commands after clearing an aws: command not found error proves that the CLI does more than simply exist on disk. You confirm that authentication works and that network access to core AWS services is in place before you run longer automation tasks.

Keeping Aws Cli Working Smoothly Long Term

Once you can run aws on every machine you care about, a bit of routine care keeps that state stable. Many aws: command not found problems show up months later when someone resets a shell profile, migrates to a new laptop, or changes how Python or package managers are installed.

Use Predictable Install Methods

  • Standardize Across Machines — Pick one install method such as distro packages, Homebrew, or the official bundle and use the same path pattern on each device.
  • Document Paths And Commands — Keep a short text file or internal runbook that lists the chosen install path and the exact commands you use.
  • Avoid Mixing Methods — Try not to mix pip, package managers, and manual bundles on the same machine, since each may expect a different aws location.

When everyone on a team follows the same pattern, scripts, documentation, and screen recordings line up. New members do not have to guess which path holds aws or which installer ran last year on a given laptop.

Watch For Profile And Shell Changes

  • Track Shell Updates — After updates to your terminal app or shell, confirm that PATH still includes the folders that hold aws.
  • Review New Dotfiles — When you adopt a new dotfile template or theme set, check that it does not override your existing PATH setting.
  • Keep Backup Copies — Save backups of your .bashrc, .zshrc, or profile scripts before large edits so you can restore them if aws vanishes again.

Most people meet the AWS: Command Not Found issue only once or twice before they settle on a simple pattern that works across their tools. With a clear sense of where the aws binary should live and how PATH exposes it to your shell, you can fix the error quickly whenever it appears and keep your workflow steady. Everything stays tidy.