Install AWS CLI on Windows 11 and 10: MSI, PowerShell, winget, Without Admin Rights, and Fix "aws Is Not Recognized as an Internal or External Command"

To install the AWS CLI on Windows 11 or 10, download and run the official 64-bit installer, AWSCLIV2.msi, or run msiexec.exe /i https://awscli.amazonaws.com/AWSCLIV2.msi in PowerShell or Command Prompt, or winget install -e --id Amazon.AWSCLI. Then close and reopen your terminal and run aws --version; you should see aws-cli/2.x. The CLI installs to C:\Program Files\Amazon\AWSCLIV2\ and adds itself to the system PATH, and it bundles its own Python, so you need nothing else. If Windows says "'aws' is not recognized as an internal or external command", the terminal was opened before the install (open a new one, and restart VS Code entirely), or that folder is missing from PATH. Without admin rights, the MSI will not install normally: use CloudShell in the browser, a per-user package manager, or extract the MSI into your own folder. Below: every install method (MSI, PowerShell silent install, winget, Chocolatey, without admin, Windows Server, WSL), the PATH fix step by step, configuring credentials, updating, removing an old v1, and the first commands to run.

Jake's first day with AWS on his Windows laptop went like most people's: he downloaded the installer, clicked through it, typed aws --version in the terminal that was already open in VS Code, and got told that 'aws' was not recognized. He reinstalled it. Same message. Ethan walked over, closed VS Code completely, opened it again, and typed the same command. It worked. Nothing had been wrong with the install; the terminal simply did not know about it yet.

New to AWS? The cards below cover CLI credentials, profiles, root vs IAM users and signing in with Identity Center.

What the AWS CLI is, and what you need first

The AWS Command Line Interface (CLI) is a program that lets you control AWS by typing commands, such as aws s3 ls to list your S3 buckets, instead of clicking through the console. It is also what many other tools rely on behind the scenes: scripts, Terraform, CDK and backup tools often expect it to be installed and configured.

What you need before installing:

• A 64-bit Windows (Windows 11 and Windows 10 both work, as do current Windows Server versions).
• Administrator rights for the standard installer, because it installs for all users under Program Files. No admin? See the options below.
• Nothing else. Version 2 of the CLI bundles its own Python, so you do not need Python installed, and an existing Python does not interfere.
• For using it afterwards: an AWS account and either an IAM Identity Center sign-in or an access key for an IAM user (never the root user's).

Always install version 2. Version 1 is the older line and is what you get from old guides that say pip install awscli.

Install the AWS CLI on Windows: every method

Method 1: the installer (MSI), with clicks.

1. Download https://awscli.amazonaws.com/AWSCLIV2.msi in your browser.
2. Run the downloaded file and follow the wizard (Next, accept the license, Next, Install). Approve the Windows security prompt.
3. When it finishes, close every open terminal window, including terminals inside VS Code, and open a new one.
4. Run aws --version.

Method 2: one command in PowerShell or Command Prompt (run as administrator):

# Interactive install straight from the download URL
msiexec.exe /i https://awscli.amazonaws.com/AWSCLIV2.msi

# Silent install (no wizard), for scripts and new machines
msiexec.exe /i https://awscli.amazonaws.com/AWSCLIV2.msi /qn

# Silent install with a log file, if something fails
msiexec.exe /i https://awscli.amazonaws.com/AWSCLIV2.msi /qn /l*v "$env:TEMP\awscli-install.log"

Method 3: winget, built into Windows 11 and current Windows 10:

winget install -e --id Amazon.AWSCLI

# Later, to update
winget upgrade -e --id Amazon.AWSCLI

Method 4: Chocolatey, if you already use it:

choco install awscli
choco upgrade awscli

All four install the same thing: version 2 in C:\Program Files\Amazon\AWSCLIV2\, added to the system PATH. Pick whichever matches how you manage your PC:

Jake: "So I reinstalled it three times for nothing?"

Ethan: "It was installed the first time. The terminal you had open just read the old PATH when it started. New window, new PATH."

Check that it works

PS C:\Users\jake> aws --version
aws-cli/2.x.x Python/3.x.x Windows/11 exe/AMD64

PS C:\Users\jake> where.exe aws
C:\Program Files\Amazon\AWSCLIV2\aws.exe

Three things to read in that output:

• aws-cli/2. at the start: you are running version 2. If it says aws-cli/1., an old version 1 is ahead of it in your PATH (see below).
• exe/AMD64: the installed Windows build, not a Python package.
• where.exe aws (in PowerShell, type where.exe, because plain where means something else there): prints the path of every aws Windows can find. More than one line means more than one installation, and the first one wins.

In PowerShell, Get-Command aws gives the same answer with the file version, which is handy when you are checking several machines remotely. If both commands find nothing, go straight to the PATH fix below.

Which terminal: Windows Terminal, PowerShell, Command Prompt or Git Bash

"Install AWS CLI in Windows Terminal" is a common search, and the answer is that there is nothing separate to install. Windows Terminal is a window that hosts shells; the CLI is one program in Program Files, and every shell finds it through PATH. What changes between shells is the syntax around the aws commands:

Git Bash runs the same Windows aws.exe, so you do not need a second install there, but two habits help: set AWS_PAGER to less or to an empty value (Git Bash ships less), and remember that it rewrites arguments that look like Unix paths, so a value starting with a slash, such as an IAM path like /service-role/, can arrive mangled; prefix the command with MSYS_NO_PATHCONV=1 when that happens. If you are choosing fresh, PowerShell 7 inside Windows Terminal is the most comfortable home for the CLI on Windows.

Fix "'aws' is not recognized as an internal or external command"

Command Prompt says:

'aws' is not recognized as an internal or external command,
operable program or batch file.

PowerShell says:

aws : The term 'aws' is not recognized as the name of a cmdlet, function, script file, or operable program.

Both mean Windows looked through every folder in your PATH and found no aws.exe. Work through these in order:

1. Open a new terminal. A terminal reads PATH once, when it starts. Any window opened before the install will never see it. In VS Code, close the whole application and reopen it; opening a new terminal tab inside the same VS Code window is not always enough, because VS Code passes on the PATH it started with.
2. Check the file exists: Test-Path "C:\Program Files\Amazon\AWSCLIV2\aws.exe" in PowerShell. If it says False, the install did not complete; run the MSI again with a log file (Method 2) and read the end of the log.
3. Run it by full path to prove it works: & "C:\Program Files\Amazon\AWSCLIV2\aws.exe" --version. If that works, only PATH is wrong.
4. Look at PATH: $env:Path -split ';' | Select-String Amazon. If nothing comes back, the folder is missing.
5. Add the folder to PATH: press the Windows key, type "environment variables", open Edit the system environment variables, choose Environment Variables, select Path under System variables (or User variables), choose Edit, New, and enter C:\Program Files\Amazon\AWSCLIV2\. Choose OK on every window.
6. Open a new terminal again and run aws --version.

If you prefer a command for step 5, this adds the folder to your user PATH without touching anything else:

$p = [Environment]::GetEnvironmentVariable("Path", "User")
[Environment]::SetEnvironmentVariable("Path", "$p;C:\Program Files\Amazon\AWSCLIV2\", "User")

One command to steer clear of for this: setx PATH "%PATH%;...". It cuts PATH off at 1,024 characters and merges the system and user values into your user PATH, which can quietly break other programs.

Install the AWS CLI without admin rights

The MSI installs for the whole machine, so it needs administrator approval. On a locked-down work laptop, these are the realistic options:

• AWS CloudShell: a terminal in your browser, opened from the AWS console's top bar, with the CLI already installed and signed in as you. Nothing to install at all, and often the best answer for occasional use.
• A per-user package manager: Scoop installs into your user folder without admin rights, and its main bucket includes the AWS CLI (scoop install aws).
• Extract the MSI into your own folder: an administrative extract unpacks the files without installing them system-wide. Then add the folder that contains aws.exe to your user PATH:

# Download first, then extract into your profile
Invoke-WebRequest https://awscli.amazonaws.com/AWSCLIV2.msi -OutFile "$env:TEMP\AWSCLIV2.msi"
msiexec.exe /a "$env:TEMP\AWSCLIV2.msi" /qb TARGETDIR="$env:USERPROFILE\awscli"

# aws.exe ends up under the Amazon\AWSCLIV2 folder inside TARGETDIR
Get-ChildItem "$env:USERPROFILE\awscli" -Recurse -Filter aws.exe

Your company's policy may block running programs from your profile folder; if it does, ask IT to install the MSI for you, which is a one-minute job for them. And if your organization uses IAM Identity Center, ask for the sign-in details at the same time, so you never need an access key on that laptop.

Configure the CLI: credentials and Region

The CLI is installed but does not know who you are yet. Two ways to tell it:

With IAM Identity Center (recommended), no long-term keys on your PC:

aws configure sso
# answers: start URL, Region, then pick account and role in the browser
aws sso login --profile my-sso-profile
aws s3 ls --profile my-sso-profile

With an IAM user's access key:

aws configure
AWS Access Key ID [None]: AKIAIOSFODNN7EXAMPLE
AWS Secret Access Key [None]: wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
Default region name [None]: us-east-1
Default output format [None]: json

aws sts get-caller-identity

The answers are saved in two files in your user profile: %USERPROFILE%\.aws\credentials (the key, in plain text) and %USERPROFILE%\.aws\config (Region and output). aws sts get-caller-identity confirms the setup by printing your account and user. If you see "Unable to locate credentials" instead, our guide to that error walks through it, and our guide to profiles and the two files explains how several accounts fit in.

Two Windows-specific problems show up here often: a PC clock that is off by more than a few minutes causes signature and "time too skewed" errors (our RequestTimeTooSkewed guide covers syncing the clock), and a corporate proxy may need HTTPS_PROXY set before the CLI can reach AWS.

Update the AWS CLI on Windows

• Installed with the MSI: run the latest AWSCLIV2.msi again (or the msiexec command); it upgrades in place and keeps your configuration.
• winget: winget upgrade -e --id Amazon.AWSCLI.
• Chocolatey: choco upgrade awscli.

Your .aws folder (credentials, config, SSO cache) is separate from the program, so updating or reinstalling leaves your settings alone. New AWS services and options arrive in new CLI versions, so if a command or parameter from current instructions "does not exist", an old CLI is the usual reason.

To see how far behind you are, compare the number from aws --version with the newest entry in the AWS CLI changelog on GitHub (the aws/aws-cli repository). New versions come out often, sometimes several in a week, so "a few versions behind" is normal; "a year behind" is when commands start going missing.

Sometimes you want a specific version instead of the newest: to match the rest of a team, to match a build server, or to step back after an update changed some behavior you depend on. Version-numbered MSI files follow the pattern https://awscli.amazonaws.com/AWSCLIV2-2.x.y.msi, with the exact version in place of 2.x.y, and installing one replaces whatever version you had:

# replace 2.x.y with the exact version number you need
msiexec.exe /i https://awscli.amazonaws.com/AWSCLIV2-2.x.y.msi /qn

On shared build machines, pinning the version in the setup script this way makes builds repeatable: the same commands behave the same way next month.

Other install and first-run errors on Windows

"aws --version" shows version 1: removing the old CLI

If aws --version prints aws-cli/1.x after you installed version 2, an older version 1 is earlier in your PATH. It usually came from one of two places:

• An old MSI for version 1: remove "AWS Command Line Interface" (the v1 entry) in Settings, Apps, Installed apps.
• pip: run pip uninstall awscli (or py -m pip uninstall awscli) for every Python that has it.

To see every copy before you remove anything, run Get-Command aws -All in PowerShell (or where.exe aws). A path under Program Files\Amazon\AWSCLIV2 is version 2; a path ending in Python3xx\Scripts\aws.cmd or similar under your Python folder is a pip-installed version 1; a path under Program Files\Amazon\AWSCLI (without V2) is the old version 1 MSI. Chocolatey and Scoop add their own shim folders, which point at whichever version they installed.

Then open a new terminal and run where.exe aws: the only line should be the AWSCLIV2 path. Version 1 and version 2 behave differently in places (output paging, some defaults, binary parameters), so running a mix is a recipe for confusing results.

Windows Server and EC2 Windows instances

The same MSI works on Windows Server. For a fresh server, the silent install in PowerShell is the quickest route, and it suits user data scripts on EC2 Windows instances:

<powershell>
Start-Process msiexec.exe -Wait -ArgumentList '/i https://awscli.amazonaws.com/AWSCLIV2.msi /qn'
</powershell>

On EC2, do not run aws configure with an access key at all: attach an IAM role (instance profile) to the instance, and the CLI picks up temporary credentials automatically. Many AWS-provided Windows AMIs already include the CLI; check with aws --version before installing.

For a whole fleet of existing Windows servers, AWS Systems Manager saves logging in to each one: run the AWS-RunPowerShellScript document through Run Command with the same msiexec line, targeted by a tag such as Role=web, and every managed instance installs or updates the CLI in one go. Windows Server Core, which has no desktop, uses the same silent command; there is simply no wizard to click.

Servers in private subnets with no internet access cannot reach awscli.amazonaws.com. Download the MSI on a connected machine, put it in an S3 bucket the server can reach through a gateway VPC endpoint, copy it down with PowerShell, and install from the local file: msiexec.exe /i C:\Temp\AWSCLIV2.msi /qn. If the server has no CLI yet to copy from S3, AWS Tools for PowerShell (often preinstalled on AWS Windows AMIs) can do the download with Read-S3Object.

The AWS CLI in WSL

Windows Subsystem for Linux is a separate Linux system, so it needs the Linux CLI, installed inside your WSL distribution:

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

If unzip is missing, install it first (sudo apt install unzip on Ubuntu), and on an Arm-based Windows PC use the awscli-exe-linux-aarch64.zip download instead of the x86_64 one. WSL has its own home folder, so its credentials live in ~/.aws inside Linux, separate from Windows' %USERPROFILE%\.aws. To share one set, you can point the Linux CLI at the Windows files with AWS_CONFIG_FILE and AWS_SHARED_CREDENTIALS_FILE, or just run aws configure sso once in each.

One shortcut to know about, and mostly to skip: WSL can run Windows programs by their full name, so typing aws.exe inside WSL starts the Windows CLI with the Windows credentials. It works for a quick check, but Linux paths you pass to it (such as /home/jake/file.txt) mean nothing to a Windows program, so file uploads and file:// parameters fail in confusing ways. Install the Linux CLI inside WSL and use each CLI in its own world. VS Code's WSL mode follows the same rule: its terminal is a Linux terminal and uses the Linux CLI.

"'more' is not recognized" and other output pager problems

The AWS CLI version 2 sends long output through a pager program, so you can scroll a big list a screen at a time. On Windows the default pager is more, with no extra options; on Linux and macOS it is less. Two things go wrong with that on Windows:

• "'more' is not recognized as an internal or external command": you are running the CLI from a shell or tool that cannot find Windows' more.com, such as some Git Bash setups, a stripped-down container, a CI runner or an IDE task with a trimmed PATH.
• Scripts that hang or output that stops at the first screen: the pager is waiting for a key press that never comes, typical in scheduled tasks and when one command's output is fed into another.

The fix is to switch the pager off. For one command, add --no-cli-pager. For every command in your profile, set it in the config file:

aws configure set cli_pager ""

# or for the current PowerShell window only:
$env:AWS_PAGER = ""

# or permanently for your Windows user (new windows only):
setx AWS_PAGER ""

The cli_pager line in %USERPROFILE%\.aws\config wins over the AWS_PAGER variable, which wins over the general PAGER variable. If you like paging but find more clumsy, point it at a better pager you have installed instead, for example setx AWS_PAGER "less" after installing less with winget or Scoop. Version 1 of the CLI had no pager, which is why older scripts and tutorials skip this step.

"aws-adfs", "aws_sso", "okta-awscli" or "aws-azure-login" is not recognized

A whole family of "not recognized" errors are not about the AWS CLI at all. Many companies sign in to AWS through their own identity provider, and colleagues' instructions often include a helper tool that sits next to the CLI: aws-adfs for Active Directory Federation Services, okta-awscli or similar for Okta, aws-azure-login for Microsoft Entra ID (Azure AD), or an internal script with a name like aws_sso. None of these is part of the AWS CLI installer, so a fresh Windows PC will not recognize them even when aws itself works perfectly.

What to do, step by step:

1. Ask which tool your company actually uses. If your organization uses IAM Identity Center, you may not need a helper at all: the built-in aws configure sso and aws sso login commands shown above do the browser sign-in themselves.
2. Install the helper the way it is published. Python-based helpers install with pip (py -m pip install --user aws-adfs), Node.js-based ones with npm (npm install -g aws-azure-login).
3. Add the right folder to PATH. This is the step that causes the error. A pip install --user puts the tool's .exe in your Python user Scripts folder, which Windows does not search by default. Find it with py -m site --user-base, then add the PythonXY\Scripts folder under that path to your user PATH. For npm global tools, npm config get prefix shows the folder (usually %APPDATA%\npm), which must be on PATH too.
4. Open a new terminal and run the tool's --help to confirm Windows finds it.

After the helper signs you in, it normally writes temporary credentials into a profile in %USERPROFILE%\.aws\credentials, and you use that profile with the normal CLI: aws s3 ls --profile work. If the helper works but the CLI still says it cannot find credentials, the two are using different profile names; compare the name the helper prints with what you pass to --profile.

Several accounts: profiles in PowerShell and Command Prompt

Most people end up with more than one AWS account or role: work and personal, test and production. Each gets a named profile:

aws configure --profile personal          # or: aws configure sso --profile work
aws configure list-profiles               # every profile the CLI knows
aws s3 ls --profile personal              # use one for a single command

To use a profile for a whole session instead of typing --profile every time, set AWS_PROFILE. The syntax depends on the shell:

The trap on Windows is old environment variables. If someone, possibly you two years ago, set AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY as Windows environment variables, those keys take priority over the default profile in your files, and the CLI keeps acting as that old identity no matter how often you run aws configure. Two commands show what is really in use:

aws configure list            # the Type column says env, shared-credentials-file, sso ...
Get-ChildItem Env:AWS*        # every AWS_ variable set in this PowerShell window

If aws configure list shows env as the type for the access key, delete the old variables in Settings, System, About, Advanced system settings, Environment Variables (check both the user and system lists), then open a new terminal. An explicit --profile on the command line still takes priority, which is why a command can work with --profile and fail without it. Our guide to profile errors and the two settings files covers the rest of the rules.

JSON and quotes in PowerShell and Command Prompt

Copying a command from Linux instructions into Windows is the most common way to get "Error parsing parameter" or "Invalid JSON". The shells treat quotation marks differently:

• Values with spaces: in PowerShell use single quotes ('my key pair'), which pass text exactly as typed; double quotes also work but expand $variables. In Command Prompt use double quotes.
• Line breaks: Linux examples end lines with a backslash; PowerShell uses a backtick (`) and Command Prompt a caret (^). A leftover backslash at the end of a line in PowerShell becomes part of the command and breaks it.
• JSON in PowerShell: wrap it in single quotes so the double quotes inside are left alone. Windows PowerShell 5.1, the version built into Windows, passes arguments to programs the old way, so the double quotes inside the JSON may also need a backslash in front of each one; PowerShell 7.3 and later pass them correctly in most cases.
• JSON in Command Prompt: wrap it in double quotes and put a backslash before every double quote inside it.

The reliable answer for anything longer than a line is to put the JSON in a file and let the CLI read it, which avoids every shell's quoting rules at once:

aws iam create-policy --policy-name ReadReports --policy-document file://policy.json
aws ec2 run-instances --cli-input-json file://launch.json

# generate a template of every parameter a command accepts:
aws ec2 run-instances --generate-cli-skeleton > launch.json

file://policy.json reads the file from the current folder; a full path also works (file://C:\work\policy.json). Create the JSON file in VS Code or a current version of Notepad, which save plain UTF-8. Be careful with Windows PowerShell 5.1's > operator and Out-File: they write UTF-16 by default, and the CLI then reports invalid JSON for a file that looks perfect on screen. For plain English JSON, Set-Content policy.json -Encoding ascii is a safe way to write it from a script.

Tab completion and auto-prompt in PowerShell

The CLI has hundreds of commands, and two built-in helpers save you from looking them up. The first is auto-prompt, which works in any terminal with nothing to set up: add --cli-auto-prompt to a partial command and the CLI shows a menu of commands, parameters and descriptions as you type.

aws ec2 --cli-auto-prompt

The second is Tab completion in PowerShell, which needs a few lines in your PowerShell profile. Open it with notepad $PROFILE (if the file does not exist, create it first with New-Item -Type File -Path $PROFILE -Force), paste this block, save, and open a new PowerShell window:

Register-ArgumentCompleter -Native -CommandName aws -ScriptBlock {
    param($commandName, $wordToComplete, $cursorPosition)
        $env:COMP_LINE=$wordToComplete
        if ($env:COMP_LINE.Length -lt $cursorPosition){
            $env:COMP_LINE=$env:COMP_LINE + " "
        }
        $env:COMP_POINT=$cursorPosition
        aws_completer.exe | ForEach-Object {
            [System.Management.Automation.CompletionResult]::new($_, $_, 'ParameterValue', $_)
        }
        Remove-Item Env:\COMP_LINE
        Remove-Item Env:\COMP_POINT
}

Now aws s followed by Tab cycles through s3, s3api, sns and the rest, and Ctrl+Space lists every match at once. Version 2 can even complete resource names, such as your DynamoDB table names after --table-name. If PowerShell refuses to load the profile with a "running scripts is disabled" error, allow your own scripts once with Set-ExecutionPolicy -Scope CurrentUser RemoteSigned.

The AWS CLI in batch files, scheduled tasks and exit codes

Once the CLI works by hand, the next step is usually a script: a nightly backup to S3, a report, a cleanup job. Three Windows details decide whether it keeps working when nobody is watching.

1. Use the full path to aws.exe in scheduled tasks. Task Scheduler may not have the same PATH as your terminal. "C:\Program Files\Amazon\AWSCLIV2\aws.exe" always works.

2. Credentials belong to a Windows user. The CLI reads %USERPROFILE%\.aws for whichever account runs it. A task that runs as SYSTEM looks in C:\Windows\System32\config\systemprofile\.aws, finds nothing, and fails with "Unable to locate credentials", even though the same script works when you run it. Run the task as your own user (with "Run whether user is logged on or not"), or point the CLI at specific files with the AWS_CONFIG_FILE and AWS_SHARED_CREDENTIALS_FILE environment variables. On an EC2 instance, use an instance role instead and the user does not matter.

3. Check the exit code. Every CLI command returns a number that tells a script what happened. Read it with $LASTEXITCODE in PowerShell or %ERRORLEVEL% in Command Prompt, right after the command:

A minimal PowerShell backup script that stops on failure and leaves a log you can read the next morning:

$aws = "C:\Program Files\Amazon\AWSCLIV2\aws.exe"
$log = "C:\Backups\s3-backup.log"

& $aws s3 sync "D:\ShopData" "s3://my-shop-backups/shopdata" --no-cli-pager *>> $log
if ($LASTEXITCODE -ne 0) {
    Add-Content $log "$(Get-Date -Format s) backup FAILED with exit code $LASTEXITCODE"
    exit $LASTEXITCODE
}
Add-Content $log "$(Get-Date -Format s) backup OK"

Note the --no-cli-pager: in a scheduled task there is nobody to press a key, so a pager would wait forever.

AWS CLI vs AWS Tools for PowerShell

Windows users have a second option that many never hear about: AWS Tools for PowerShell, a set of PowerShell modules that cover the same AWS services as cmdlets, such as Get-S3Bucket or Get-EC2Instance, instead of aws s3api list-buckets. The two do the same jobs; the difference is what you get back.

• The AWS CLI returns text (JSON, a table, plain text). It is the same on Windows, Mac and Linux, so every tutorial and Stack Overflow answer works, and it is the better choice for one-off commands and anything you share with people on other systems.
• AWS Tools for PowerShell returns .NET objects. You can pipe them into Where-Object, Sort-Object and Export-Csv without parsing JSON, which makes it the nicer choice for PowerShell scripts that build reports or loop over many resources.

Install only the service modules you need:

Install-Module -Name AWS.Tools.Installer -Scope CurrentUser
Install-AWSToolsModule AWS.Tools.S3, AWS.Tools.EC2 -CleanUp

Get-S3Bucket | Select-Object BucketName, CreationDate

Both read the same shared credentials and config files in %USERPROFILE%\.aws, so a profile created with aws configure also works with -ProfileName in the PowerShell cmdlets. Plenty of people install both: the CLI for quick commands and copy-paste from documentation, the PowerShell modules for scripts.

Your first five commands

aws sts get-caller-identity               # who am I?
aws configure list                        # which credentials and Region are in use
aws s3 ls                                 # list your S3 buckets
aws ec2 describe-regions --output table   # Regions available to the account
aws help                                  # built-in help (q to quit)

If the first command prints your account ID and user or role, everything is working: the program is installed, PATH is right, and your credentials are valid. If aws s3 ls then says Access Denied, the setup is fine and the identity simply lacks permission to list buckets, which is a question for whoever manages your AWS account. Add --output table for readable output, --query to pick fields, and --profile NAME to use another account. The CLI pages long output through a pager by default; set AWS_PAGER to an empty value ($env:AWS_PAGER="" in PowerShell) if you want everything printed straight to the window.

Two more habits pay off from the first day. Add --region to try a command in another Region without touching your saved settings (aws ec2 describe-instances --region eu-west-1), which is the quickest way to find the instance that "disappeared" because it lives in a different Region. And before running anything that creates or deletes resources, look for a --dry-run option (EC2 has one) or run the matching describe or list command first, so you see exactly what the change will touch.

Frequently asked questions

Jake's setup took five minutes once the terminal question was out of the way: winget on his next laptop, aws configure sso with the shop's Identity Center, and aws sts get-caller-identity to prove it. He keeps one line pinned in his notes now, under "AWS on a new PC": "Install, then close everything, then open a new terminal." Ethan has given the same advice to every new starter since.

Revision note. Written October 19, 2026. Most failed AWS CLI installs on Windows are successful installs seen through an old terminal.