How to Use AWS CLI on Windows Without WSL: MSI Installer and Credential Setup

Most AWS CLI setup guides assume you're on Linux or macOS, or they push you toward WSL before you've even run a single command. If you're on a Windows machine and want the CLI running natively — no subsystem, no virtualization layer — the MSI installer is the straightforward path, and it works exactly as well as any other installation method.

TL;DR: AWS CLI on Windows Without WSL

StepActionTool
1Download and run the MSI installerAWS official installer
2Verify installationCommand Prompt / PowerShell
3Run aws configureAWS CLI
4Verify credentials workaws sts get-caller-identity

How AWS CLI Credential Resolution Works on Windows

Before touching the installer, it helps to understand where the CLI looks for credentials so you don't end up debugging phantom permission errors later.

When you run any aws command, the CLI resolves credentials in a fixed priority order. Environment variables are checked first. If those aren't set, it reads the credentials file at %USERPROFILE%\.aws\credentials. After that, it checks the config file at %USERPROFILE%\.aws\config, then instance metadata (only relevant on EC2), and finally container credentials. On a developer workstation, the credentials file written by aws configure is what you'll use.

graph TD A["AWS CLI Command Invoked"] --> B{"AWS_ACCESS_KEY_ID
env var set?"} B -- Yes --> E["Use Environment Variables"] B -- No --> C{"%USERPROFILE%\.aws\credentials
file exists?"} C -- Yes --> F["Use Credentials File
(written by aws configure)"] C -- No --> D{"%USERPROFILE%\.aws\config
has credentials?"} D -- Yes --> G["Use Config File"] D -- No --> H["Instance / Container
Metadata (EC2/ECS only)"] H -- Not available --> I["NoCredentialsError"] E --> J["Request Sent to AWS"] F --> J G --> J H --> J
  1. Environment variables — AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN checked first.
  2. AWS credentials file — %USERPROFILE%\.aws\credentials, written by aws configure.
  3. AWS config file — %USERPROFILE%\.aws\config, used for region, output format, and named profiles.
  4. Instance/container metadata — Only relevant when running on EC2 or ECS. Not applicable to a local Windows workstation.

Step 1: Install AWS CLI v2 on Windows Using the MSI Installer

AWS CLI v2 is the current supported version. The MSI installer handles the full installation — binary, PATH registration, and uninstall support — without requiring Python, pip, or any runtime dependency on your machine.

Download the 64-bit MSI installer directly from the official AWS distribution URL:

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

Run the downloaded AWSCLIV2.msi file. The installer wizard requires no custom configuration — accept the defaults and click through. It installs to C:\Program Files\Amazon\AWSCLIV2\ and adds that directory to your system PATH automatically.

If you prefer a silent install for scripted provisioning or machine imaging, run this from an elevated Command Prompt:

msiexec.exe /i AWSCLIV2.msi /qn

No reboot is required, but you may need to open a new terminal window for the PATH change to take effect in your current session.

Step 2: Verify the AWS CLI Installation

Open a new Command Prompt or PowerShell window — not the one you used before the install — and confirm the binary is on your PATH and the version is v2:

aws --version

Expected output looks like:

aws-cli/2.x.x Python/3.x.x Windows/10 exe/AMD64

If you get a 'command not found' error or the shell still resolves to an old v1 install, close all terminal windows and reopen. If the problem persists, verify that C:\Program Files\Amazon\AWSCLIV2\ appears in your system PATH under System Properties → Environment Variables → System variables → Path.

Step 3: Configure AWS Credentials Using aws configure

This is where most first-time setups go wrong — not because the command is complicated, but because people configure credentials for the root account instead of an IAM user, or they skip setting the region and hit confusing errors later.

You need an IAM user with programmatic access (an access key ID and secret access key). If you haven't created one, do that first in the IAM console. Attach only the permissions the user actually needs — not AdministratorAccess unless you have a specific reason.

Run the configuration command:

aws configure

The CLI prompts you for four values:

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
  • Access Key ID — Starts with AKIA for long-term credentials. Get this from the IAM console under your user's 'Security credentials' tab.
  • Secret Access Key — Shown only once at creation time. If you lost it, you must create a new key pair.
  • Default region — Use the region where your resources live, e.g., us-east-1, ap-northeast-2. This becomes the fallback when no --region flag is passed.
  • Default output format — json is the most compatible. table is readable for ad-hoc queries. text is useful for shell scripting.

After running aws configure, two files are written:

%USERPROFILE%\.aws\credentials
%USERPROFILE%\.aws\config

The credentials file holds the key pair. The config file holds region and output format. Keep these files out of version control — add .aws/ to your .gitignore if your home directory is anywhere near a repo root.

Step 4: Verify Credentials Work with aws sts get-caller-identity

Don't assume aws configure completing without error means your credentials are valid. The command only writes what you typed — it doesn't validate against AWS. The fastest way to confirm the credentials actually work is:

aws sts get-caller-identity

A successful response confirms the credentials are valid and shows you exactly which identity you're operating as:

{
    "UserId": "AIDAIOSFODNN7EXAMPLE",
    "Account": "123456789012",
    "Arn": "arn:aws:iam::123456789012:user/your-iam-username"
}

If you get an InvalidClientTokenId or AuthFailure error, the access key ID or secret is wrong. Re-run aws configure and re-enter the values carefully — the secret access key is long and easy to truncate when copying.

Working with Named Profiles

If you work across multiple AWS accounts — a personal account, a work account, a staging environment — storing everything in the default profile creates credential confusion fast. Named profiles solve this cleanly.

Configure a named profile by passing the --profile flag:

aws configure --profile work-account

This writes a separate block in both the credentials and config files under [work-account]. To use it for a command:

aws sts get-caller-identity --profile work-account

Or set it as the active profile for your entire terminal session using an environment variable:

# PowerShell
$env:AWS_PROFILE = "work-account"

# Command Prompt
set AWS_PROFILE=work-account

The environment variable approach is useful when running scripts that don't accept a --profile flag directly.

Depth Signal: The Region Setting That Silently Breaks Cross-Region Calls

Here's a behavioral interaction that catches people off guard. When you set a default region in aws configure, that value is written to %USERPROFILE%\.aws\config under the [default] profile. If you later set the AWS_DEFAULT_REGION environment variable in your terminal session, it overrides the config file value — but only for that session. The config file is unchanged.

The problem surfaces when you have a script that sets AWS_DEFAULT_REGION to us-west-2 for one task, and then a subsequent command in the same session silently operates against us-west-2 instead of your intended region. The CLI never warns you that an environment variable is overriding your config. Always verify the active region with:

aws configure get region

That command reads from the config file. To see what region the CLI will actually use (including environment variable overrides), check:

aws configure list

The output shows the source of each setting — whether it came from the config file, an environment variable, or a CLI argument — which makes the override chain visible.

Experience Signal: The Credential That Looked Right But Wasn't

A common misdiagnosis: you run aws s3 ls and get an AccessDenied error. The immediate assumption is that the IAM policy is missing S3 permissions. You check the policy, it looks correct, you re-attach it, same error.

The actual cause: the credentials in %USERPROFILE%\.aws\credentials belong to a different IAM user than the one whose policy you just checked. This happens when you've run aws configure multiple times, or copied credentials from a colleague's setup guide. Run aws sts get-caller-identity first. Confirm the ARN in the response matches the IAM user whose policy you're editing. If the ARNs don't match, you're debugging the wrong user entirely.

The fix is always the same: verify identity before debugging permissions.

Minimum IAM Policy for Verifying CLI Setup

If you want to test the CLI with a minimal-permission IAM user before granting broader access, the only permission needed to run aws sts get-caller-identity is:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "sts:GetCallerIdentity",
      "Resource": "*"
    }
  ]
}

Note that sts:GetCallerIdentity requires "Resource": "*" — it does not support resource-level restrictions. This is documented in the AWS Service Authorization Reference.

Wrap-Up and Next Steps for AWS CLI on Windows

At this point you have a working AWS CLI installation on Windows, credentials configured for at least one IAM user, and a verified identity. The native Windows installation is fully supported by AWS and behaves identically to the Linux or macOS versions for all standard CLI operations.

From here, the natural next steps are:

  • Explore AWS IAM Identity Center (SSO) if your organization uses it — the CLI supports SSO-based credential vending via aws configure sso, which avoids long-term access keys entirely.
  • Look into AWS CLI named profiles for managing multiple accounts and roles without re-running aws configure each time.
  • Review the AWS CLI User Guide for the full credential provider chain and advanced configuration options.

Glossary

TermDefinition
Access Key IDThe public identifier component of an IAM user's long-term credentials. Starts with AKIA for standard keys.
Secret Access KeyThe private component of an IAM user's long-term credentials. Shown only once at creation; must be stored securely.
Named ProfileA labeled set of credentials and configuration in the AWS credentials/config files, selected with --profile or AWS_PROFILE.
Credential Provider ChainThe ordered sequence the AWS CLI uses to locate credentials: environment variables, credentials file, config file, instance metadata.
STS (Security Token Service)AWS service that issues temporary credentials and provides identity verification via GetCallerIdentity.

Related Posts

Comments

Post a Comment

Popular posts from this blog

EC2 No Internet Access in Custom VPC: Fix Internet Gateway and Route Table

EC2 no internet access in a custom VPC is one of the most common launch-day failures — the instance is running, but outbound connectivity is completely silent. TL;DR: EC2 No Internet Access — Fix Checklist Step What to Do Why It Matters Complexity 1 Create and attach an Internet Gateway to the VPC Without an IGW, the VPC has no path to the public internet Low 2 Add a default route (0.0.0.0/0) pointing to the IGW in the subnet's route table The IGW exists but traffic has no route to reach it Low 3 Assign a public IP or Elastic IP to the instance Private IPs are not routable on the public internet Low 4 Verify Security Group allows outbound traffic A restrictive outbound rule silently drops all egress Low 5 Verify Network ...
Read more

EC2 SSH Connection Timeout: Which Security Group Rules to Check

An EC2 SSH connection timeout is one of the most common blockers when launching a new instance — the fix is almost always a missing or misconfigured inbound rule in your Security Group. TL;DR — Diagnostic Steps at a Glance Step What to Check Common Fix 1 Security Group inbound rules Add SSH (TCP 22) from your IP 2 Subnet route table Ensure 0.0.0.0/0 routes to an Internet Gateway 3 Network ACL rules Allow inbound TCP 22 and ephemeral return ports 4 Instance public IP / Elastic IP Confirm a public IP is assigned 5 Key pair and SSH username Use correct private key and AMI-specific username Why SSH Times Out Instead of Refusing A connection refused error means the TCP handshake reached the host but nothing is listening. A connection timed out error means packets never arrived — or replies never returned. On EC2, that silence is almost always a network-layer block, not an OS-level problem. The Se...
Read more

Difference Between IAM User and IAM Role: Which One Should Your EC2 Use?

Understanding the difference between IAM User and IAM Role is critical — choosing wrong means either hardcoded credentials in your app or a silent security exposure you won't catch until an audit. TL;DR: IAM User vs IAM Role at a Glance Dimension IAM User IAM Role Identity type Permanent, named human or service identity Assumable identity with temporary credentials Credential type Long-lived access keys or password Short-lived STS tokens (auto-rotated) Attached to EC2? No native attachment — keys must be embedded Yes — via Instance Profile, injected automatically Rotation required? Manual — your responsibility Automatic — AWS STS handles it Recommended for EC2 → S3? No Yes — always Cross-account access Requires separate user per account Native — assume role across accounts Audit trail Tied to user identity Tied to role + session name in CloudTrail What IAM User and IAM Role Actual...
Read more