Introduction

When docker login to Amazon ECR returns 400 Bad Request from a PowerShell-based Jenkins step, the problem is usually not Docker itself. It is almost always one of a small set of issues: wrong registry URI, wrong region, outdated login command, mismatched credentials, or PowerShell-specific command handling.

Use the Current ECR Login Flow

The current AWS-recommended login flow is based on get-login-password, not the older get-login command.

With AWS CLI:

aws ecr get-login-password --region us-east-1 |
docker login --username AWS --password-stdin 123456789012.dkr.ecr.us-east-1.amazonaws.com

With AWS Tools for PowerShell:

(Get-ECRLoginCommand -Region us-east-1).Password |
docker login --username AWS --password-stdin 123456789012.dkr.ecr.us-east-1.amazonaws.com

Two details are easy to get wrong:

• the username must be AWS
• the registry should be the ECR host only, not a URL with https://

The Most Common Causes of 400 Bad Request

Wrong Registry Endpoint

The registry must match the target account and region exactly:

123456789012.dkr.ecr.us-east-1.amazonaws.com

If the account or region is wrong, the request reaches the wrong endpoint and authentication fails.

Old Command Style

Older scripts often use aws ecr get-login, which prints a full Docker command. That flow is legacy now and is much easier to break in Jenkins or PowerShell due to quoting and parsing issues.

Region Mismatch

The ECR registry and the --region argument must line up. Logging in with us-west-2 and pushing to a us-east-1 registry will fail.

PowerShell Pipeline Issues

PowerShell can behave differently from Bash when strings, command output, and quoting move through a pipeline. Keeping the command simple and using --password-stdin is the safest route.

A Jenkins-Friendly PowerShell Step

1$region = "us-east-1"
2$registry = "123456789012.dkr.ecr.$region.amazonaws.com"
3
4aws ecr get-login-password --region $region |
5docker login --username AWS --password-stdin $registry

Then verify the AWS identity before blaming Docker:

aws sts get-caller-identity
aws ecr describe-repositories --region $region

If those commands fail, the problem is the Jenkins AWS credentials or region configuration, not the Docker client.

Version and Environment Checks

AWS documentation explicitly recommends updating to a current AWS CLI if login fails. Also check:

• Docker version
• AWS CLI version
• Jenkins agent AWS credentials
• Jenkins agent region variables

On Windows agents, credential-helper issues can also interfere. AWS documents problems with some Docker for Windows wincred setups, so if authentication behaves oddly after login, inspect the Docker credential store configuration too.

What Not to Do

Avoid these patterns:

• using the old get-login output in pasted form
• passing a registry with https:// in front of it
• assuming the Jenkins node has the same AWS profile as your local shell
• hardcoding a password token for reuse

ECR auth tokens are temporary. Generate them at login time inside the pipeline.

Common Pitfalls

The biggest mistake is copying a Linux shell example into PowerShell without checking how the pipeline behaves on the Jenkins Windows agent.

Another mistake is authenticating to one region and pushing to another registry host.

A third issue is debugging Docker before verifying the Jenkins agent can call AWS APIs with the expected identity.

Summary

• Use aws ecr get-login-password or Get-ECRLoginCommand, not the old get-login flow.
• Pass the ECR registry host without https://.
• Make sure the region and account ID match the target registry exactly.
• Verify AWS identity from the Jenkins agent before debugging Docker further.
• If Windows agents still behave strangely, check Docker credential-helper configuration as well.