If you work on Windows and deploy to AWS, running the AWS CLI inside WSL gives you the same Linux shell your CI runners and servers use, so the scripts you write locally work everywhere else. The install takes five minutes. The problems show up later: a clock that drifts after your laptop sleeps, two sets of credentials that don't know about each other, and a sign-in page that won't open. This post covers the setup and the fixes.
You'll need WSL 2 with Ubuntu (or another Debian-based distro) and access to an AWS account with IAM Identity Center enabled.
Install AWS CLI v2
Skip sudo apt install awscli. Depending on your Ubuntu release, the distro package is either an outdated version 1 or not there at all. Use AWS's installer instead:
sudo apt update && sudo apt install -y unzip
curl "https://awscli.amazonaws.com/awscli-exe-linux-x86_64.zip" -o awscliv2.zip
unzip awscliv2.zip
sudo ./aws/install
aws --versionNow check which aws you're actually running:
which awsIt should print /usr/local/bin/aws. WSL adds your Windows PATH to Linux by default, so if the AWS CLI is also installed on Windows and the Linux install failed, aws can quietly run aws.exe instead. That mix-up explains a lot of "it works in PowerShell but not in WSL" confusion.
To update later, newer versions of the CLI have a built-in command:
sudo aws updateOn older versions, rerun the install steps with sudo ./aws/install --update.
Sign in with IAM Identity Center, not access keys
Most tutorials have you paste an access key and secret into aws configure. Those keys never expire, they sit in a plaintext file, and plaintext credentials are never secure. IAM Identity Center gives you short-lived credentials instead: you sign in through your browser, and the CLI gets temporary credentials that expire on their own.
aws configure ssoThe CLI asks for:
- SSO session name: any label, like
my-sso. - SSO start URL: your AWS access portal URL, from the IAM Identity Center console.
- SSO region: the region where Identity Center is set up.
- Registration scopes: press Enter for the default.
It then opens a browser to sign in. Afterward, pick the account and role, set a default region and output format, and give the profile a name.
Use named profiles
Give every account or client its own profile and pass it explicitly:
aws s3 ls --profile wakoOr set it for the whole shell session:
export AWS_PROFILE=wakoTerraform's AWS provider reads the same profiles, so AWS_PROFILE=wako terraform plan uses the credentials you just signed in with. When the session expires, run aws sso login --profile wako again.
Fixing the WSL-specific problems
"SignatureDoesNotMatch", "RequestExpired", "InvalidSignatureException", after your laptop sleeps
WSL 1 runs in a lightweight virtual machine, and its clock can fall behind Windows after the laptop sleeps or hibernates, sometimes by minutes or even hours. AWS rejects signed requests that are too far off the real time, so commands that worked yesterday suddenly fail with signature or request expired errors.
Compare date in WSL with the Windows clock. If they differ, resync from inside WSL:
sudo hwclock -sIf that doesn't work on your distro, restart WSL from PowerShell:
wsl --shutdownIf you can upgrade to WSL 2+ as Microsoft implemented a automate fix for this error.
wsl.exe --set-version Ubuntu 2The sign-in page doesn't open
Since version 2.22.0, the CLI signs you in by opening a browser and waiting for it to redirect back to a local address. From WSL, the browser may not open at all, or the redirect may never reach the CLI. If the browser doesn't open, the CLI prints the sign-in URL, which you can copy into your Windows browser. If the sign-in still doesn't complete, switch to the device-code flow, which works without the redirect:
aws sso login --profile wako --use-device-codeOpen the link it prints in any browser and enter the code it shows.
Windows and WSL have separate credentials
Windows keeps its AWS configuration in C:\Users\you\.aws, and WSL keeps its own in ~/.aws. They don't share profiles or sign-ins. Pointing WSL at the Windows folder through /mnt/c is tempting, but file permissions don't map cleanly across that boundary, and it's easy to end up debugging the wrong config. The simpler fix is to pick one environment for AWS work. If you need both, run aws configure sso once in each.
Slow commands in /mnt/c
Files under /mnt/c live on the Windows drive, and WSL reaches them through a slower file-sharing layer. Keep your repositories in your Linux home folder (for example, ~/projects) rather than /mnt/c/Users/.... Git, Terraform and anything that reads a lot of files will be noticeably faster.
Check that it works
aws sts get-caller-identity --profile wakoThis prints the account and role you're signed in as. If it works, the CLI, your profile and your credentials are all set up.
Next
With the CLI working, the next post covers how this site runs on S3 and CloudFront for close to nothing a month, deployed by Terraform and GitLab CI.