ECR & Container Registries on AWS

The plain-language idea

ECR (Elastic Container Registry) is AWS's own container image registry — the same role Docker Hub plays generically, covered in this platform's Docker track's registry lesson: a place images are pushed to and pulled from, tagged and promoted between environments the same way. What's actually different about ECR isn't the registry concept itself; it's two things that follow directly from being AWS-native rather than a separate service with its own account system:

• Authentication is IAM-based, not a separate login. Instead of a Docker Hub username and password, aws ecr get-login-password mints a short-lived registry token from whatever IAM identity is already making the call — the same role an EC2 instance, a Lambda function, or a CI pipeline already has, rather than a second credential system to manage and rotate separately.
• Image scanning on push is a built-in, first-class feature. ECR can scan an image's OS and language-package layers for known CVEs the moment it's pushed, without adding a separate third-party scanning step to the pipeline.

See it in a real thing: pushing the same image, to ECR specifically

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

docker tag myapp:a1b2c3d 123456789012.dkr.ecr.us-east-1.amazonaws.com/myapp:a1b2c3d
docker push 123456789012.dkr.ecr.us-east-1.amazonaws.com/myapp:a1b2c3d

The get-login-password step is the meaningful difference from Docker Hub: it exchanges the caller's existing IAM credentials for a registry token valid for a matter of hours, rather than a persistent login that stays valid until manually revoked. Everything after that — the git-SHA tagging strategy, docker tag adding a name to an existing image rather than rebuilding it, docker push — is exactly the same "build once, promote the same image" pattern from the Docker track's registry lesson, just pointed at ECR's registry URL instead of Docker Hub's.

What people usually miss

Watch out

• ECR tokens are short-lived, not a one-time login. docker login against ECR has to be re-run periodically (via get-login-password again) because the token expires in hours, whereas a Docker Hub login persists until explicitly logged out — a deliberate consequence of using IAM-based short-lived credentials, not a bug or inconvenience to work around.
• ECR repositories are region-scoped, unlike Docker Hub's single global namespace. The same image needs to be pushed to each region's ECR separately (or explicitly replicated) if compute in multiple regions needs to pull it — the same "nothing is cross-region by default" point from this track's multi-region lesson applies here too.
• Scan-on-push finds known vulnerabilities in packages, not application-level logic bugs. It's a real, valuable, and cheap gate — catching a known-CVE base image before it ships — but it's necessary, not sufficient, the same caveat that applies to any dependency/CVE-based scanner regardless of which registry runs it.
• Private doesn't mean single-account-only. A private ECR repository can grant another AWS account explicit pull access via a repository policy — the same ARN-scoped access-grant pattern as an S3 bucket policy — so a separate team's account can pull an image without it ever being made public.

Why this matters in interviews

"How would you set up a container registry for a team's CI/CD pipeline on AWS?" tests whether a candidate names ECR specifically and reasons about IAM-based auth and scan-on-push as concrete answers — versus re-explaining what a registry is in general, which this platform's Docker track already covers and an AWS-specific question is assuming as known.