Introduction to ECR (and Containers on AWS)

Beanstalk asked "what's your code?" Containers ask a better question: "what's your whole environment?" A Docker image packages your app and its runtime, libraries, and OS dependencies into one artifact that runs identically on your laptop, a teammate's machine, and AWS. This project deploys a containerized app - and it starts with ECR, the place AWS stores your images.

Why containers, in one diagram

   "Works on my machine" (no containers)
   ────────────────────────────────────
   your laptop: Java 21, libX 2.3   ──► app works
   the server:  Java 17, libX 1.9   ──► app breaks
        (different environment = surprise failures)

   Containers
   ──────────
   image = app + Java 21 + libX 2.3 + OS bits, frozen together
   runs the SAME everywhere Docker runs → no "works on my machine"

A container is a lightweight, isolated package of your app and everything it needs to run. The image is the frozen template; a container is a running instance of it. Build once, run anywhere.

The AWS container cast

Three services work together for this project. Keep their roles straight:

   docker build ──► image ──► push to ECR ──► ECS pulls & runs it
   (your machine)            (the registry)    (the runtime)

ECR - Elastic Container Registry

ECR is a managed Docker image registry - like Docker Hub, but inside AWS, private to your account, and integrated with IAM. You push images to it; ECS (or anything else) pulls from it.

Why use ECR instead of Docker Hub:

• Private by default - your images aren't public unless you choose.
• IAM-controlled - the same permission model as the rest of AWS; no separate registry credentials to manage.
• Close to ECS - fast pulls within the same region, no internet round-trip.
• Integrated - scans images for vulnerabilities, manages lifecycle (auto-expire old images).

Repositories and image tags

ECR organizes images into repositories - one repo per application (e.g. telusko-app). Inside a repo, images are distinguished by tags:

   ECR repository: telusko-app
   ├── telusko-app:latest    ← convention for "newest"
   ├── telusko-app:v1
   └── telusko-app:v2        ← deploy a specific version by tag

Each image's full address looks like:

   <account-id>.dkr.ecr.<region>.amazonaws.com/telusko-app:v2
   └──────── the ECR registry for your account/region ────────┘

ECS - Elastic Container Service (a preview)

ECS runs your containers - it pulls images from ECR and keeps the right number of them running, healthy, and (optionally) behind a load balancer. We'll go deep in the cluster page, but the vocabulary to start carrying:

EC2 launch type vs. Fargate

ECS can run your containers two ways - and this is the choice that defines the experience:

   EC2 launch type:  YOU manage the EC2 instances the containers run on
                     (more control, you patch/scale the hosts)

   Fargate:          AWS runs the containers serverlessly - NO servers to manage
                     (you just say "run this task"; AWS finds the capacity)

The project ahead

Here's the route the next pages take, end to end:

The destination is the same as the Beanstalk project - a running app with a database - but the machinery is container-native: portable images in ECR, orchestrated by ECS. First, get the CLI talking to ECR.