AWS Basics · Lesson 730 min read

Ship & Scale: CI/CD + Containers

Two halves of getting software live: an automated pipeline that ships every commit safely, and containers that run it the same way everywhere.

From your mentor

This is where everything you've learned gets delivered. We'll automate the path from git push to running code, then package that code into containers AWS can run at any scale, with the safe-rollout tricks the pros use.

Shipping software is just two things: a pipeline that deploys every commit, and containers that run it the same everywhere.

In 10 minutes you’ll see how code goes from commit to running. You do NOT need Kubernetes depth yet.

Pick your way in, same idea, 5 doors

Two ideas. A container is a lunchbox that packs your app with everything it needs, so it runs the same on any computer. A pipeline is a robot that, every time you save code, packs the lunchbox and ships it. That’s modern delivery.

Next: trace one commit from git push to a running container.

Why a pipeline at all

Manually deploying, SSH in, copy files, restart, is slow, error-prone, and unrepeatable. CI/CD turns 'deploy' into something that happens automatically and identically every time.

In plain English

Think of a factory conveyor belt. You drop raw code on one end (a git push), and it moves through fixed stations, build, test, deploy, coming out as running software with no human carrying it between stations. That belt is your pipeline; if a station fails, the belt stops before anything broken reaches users.

The CodeSuite pipeline, stage by stage

AWS's CI/CD is three services wired together by CodePipeline. Each stage hands an artifact to the next.

Orchestrated end-to-end by AWS CodePipeline

Source

CodeConnections

GitHub / GitLab, a push starts the pipeline

Build & test

CodeBuild

Runs buildspec.yml: compile, test, package

Deploy

CodeDeploy

Ships to ECS / EC2 / Lambda via appspec.yml

A commit flows left → right automatically, no human SSH-ing into a server.

CodeCommit is closed to new customers (since July 2024)

AWS stopped onboarding new CodeCommit (its old git host) customers. Use GitHub or GitLab as your source, connected through AWS CodeConnections (formerly CodeStar Connections). CodeStar is fully retired, and CodeCatalyst closed to new sign-ups too, CodePipeline, CodeBuild, and CodeDeploy remain the supported core.

Two files drive the pipeline: buildspec.yml tells CodeBuild how to build and test, and appspec.yml tells CodeDeploy how to release. Both live in your repo, so the pipeline is version-controlled with the code.

The deployment ladder

How teams release climbs the same naive → best path as everything else in this course.

Deploymentthe climb

Rung 0 · Naive
Manual deploy
SSH into the server, git pull or copy files, restart the process by hand.
Unrepeatable and risky, works differently each time, no record, and a typo at 2am takes prod down.
Better
Automated rolling pipeline
A CodePipeline builds, tests, and rolls the new version out batch by batch on every commit.
Repeatable and hands-off; failed tests stop the belt before bad code ships.
Best practice today
Blue-green / canary with auto-rollback
Shift traffic gradually (or to a parallel environment) with health checks that auto-roll-back on failure.
Near-zero-downtime releases where a bad deploy affects almost no users and reverts itself.

Deployment strategies, visually

CodeDeploy can release the same build in very different ways. The trade-off is speed vs safety.

Rolling

Replace instances batch by batch. No downtime, but old + new run side by side briefly.

Simple, cheap, the default.

Blue / Green

Stand up a full new environment, flip all traffic at once. Instant rollback by flipping back.

Zero-downtime + safe rollback.

Canary

Send a small % to the new version, watch, then shift the rest if healthy.

High-risk changes, big blast radius.

Worth pondering

Rule of thumb: rolling for everyday low-risk changes, canary when a bug would be expensive (send 10% of traffic first, watch the dashboards, then continue), and blue-green when you need an instant, clean rollback switch. CodeDeploy also offers linear, shift a fixed % every N minutes.

Why containers

A container packages your app with everything it needs to run, so it behaves identically on your laptop, in the pipeline, and in production.

In plain English

A container is a shipping container for software. Before standardised containers, cargo was loaded loose and every port handled it differently. After, the box is identical everywhere, ship, train, truck. Your app image is that box: the same artifact runs the same way on any machine, killing “but it works on my machine.”

From Dockerfile to running container

Four steps take your code from a text recipe to containers running on AWS. Learn the chain once and ECS/EKS stop being mysterious.

Dockerfile

The recipe, base image, your code, the start command

Image

docker build → an immutable, portable artifact ("works on my machine", fixed)

Amazon ECR

docker push → AWS’s private image registry

ECS or EKS runs it

The orchestrator pulls the image and runs containers on Fargate or EC2

ECR is the warehouse, not the runner

ECR (Elastic Container Registry) only stores images. It doesn’t run anything, ECS or EKS pulls the image from ECR and runs it. Build → push to ECR → orchestrator pulls and runs. That’s the whole loop.

ECS vs EKS, and Fargate vs EC2

Two independent choices: which orchestrator runs your containers, and what compute they run on. Don't conflate them.

Amazon ECS

AWS-native orchestrator

Simple, deeply integrated, control plane is free. The default unless you specifically need Kubernetes.

Amazon EKS

Managed Kubernetes

Portable, flexible, huge ecosystem, but more complex and the control plane costs ~$0.10/hr per cluster. Pick it when you need K8s.

… and either one runs your containers on …

AWS Fargate

Serverless, no instances

No servers to manage; pay per vCPU/GB-second while a task runs. Best for variable or spiky workloads.

EC2 launch type

You manage the hosts

Full control, can be cheaper at steady high utilisation, but you patch and scale the instances yourself.

Nice, that’s the win

The clean way to hold it: ECS vs EKS is “how do I orchestrate?” (AWS-native and simple vs Kubernetes and portable). Fargate vs EC2 is “who owns the servers?” (AWS vs you). For most beginners and most apps: ECS on Fargate, no Kubernetes to learn, no servers to manage.

Question	Answer
Just want containers running with least hassle?	ECS on Fargate
Already invested in Kubernetes / need portability?	EKS
Spiky or unpredictable load, no ops team?	Fargate
Steady high utilisation, want lowest cost + control?	EC2 launch type
Where do the images live, either way?	Amazon ECR

What ‘ship & scale’ costs

Pipelines and containers each have a handful of billing dials. Know them so a demo doesn't quietly bill all month.

Service	How it bills	Watch out for
CodePipeline	Per active pipeline per month (first one free)	Idle pipelines still bill
CodeBuild	Per build-minute by compute size	Big build fleets on every commit
ECR	Per GB-month of stored images (500 MB free)	Old image tags piling up
EKS	~$0.10/hr per cluster control plane	A forgotten cluster ≈ $73/month
Fargate	Per vCPU-second + GB-second while tasks run	Over-provisioned task size

The cheapest demo path

ECR’s free tier (500 MB) covers a test image. A single CodePipeline is free. EKS and running Fargate tasks are not free, spin them up, verify, and tear them down the same day.

How this shows up in interviews

Interview angle

“Walk me through how a commit gets safely into production on AWS.”

How to answer it

Trace the pipeline end-to-end, name the services and the two spec files, then show release safety with a deployment strategy. Mention containers + ECR if the stack is containerised.

1Source: GitHub/GitLab connected via CodeConnections (CodeCommit is closed to new customers), a push triggers the pipeline.
2CodePipeline orchestrates the stages; CodeBuild runs buildspec.yml to compile, test, and (for containers) build and push an image to ECR.
3CodeDeploy releases using appspec.yml, to ECS, EC2, or Lambda.
4Use a canary or blue-green strategy with health checks so a bad build affects few/no users and auto-rolls-back.
5For containers: ECS on Fargate by default, no servers, no Kubernetes overhead.

Green flags

Knows CodeCommit is closed and uses GitHub + CodeConnections
Separates orchestrator (ECS/EKS) from compute (Fargate/EC2)
Reaches for canary/blue-green for risky releases

Red flags

Describes SSH-ing in to deploy by hand
Thinks ECR runs containers
Defaults to EKS “because Kubernetes” for a simple app

Q.What’s the status of CodeCommit, and what do you use instead?

A.Closed to new AWS accounts since July 2024. For anything new, use GitHub or GitLab + CodeConnections.

Existing repos keep working but get no new features.
The rest of the suite (CodePipeline, CodeBuild, CodeDeploy) is still current.

They’re checking: That you track AWS’s shifting lineup instead of reciting a 2022 answer.

Q.ECS vs EKS, when each?

A.Default to ECS; reach for EKS only when you genuinely need Kubernetes itself.

ECS

EKS

Control plane: free

Control plane: ~$73/mo per cluster

Ship in a day, AWS-native

Upgrades, add-ons, IRSA to run

Best for: most apps

Best for: k8s API/ecosystem, multi-cloud

They’re checking: Whether you choose by real need, not resume-driven hype.

Q.Fargate vs the EC2 launch type?

A.Same containers, different host owner. Start on Fargate; move hot, steady workloads to EC2.

Fargate

EC2 launch type

AWS runs the nodes

You run the instances

Pay per vCPU / GB-second

Pay per instance (Spot / Savings Plans)

Best for: spiky, low-ops

Best for: steady high-util, GPUs, custom AMIs

They’re checking: That you weigh cost-at-utilisation against ops burden, and state a default.

Q.Blue-green vs canary?

A.Canary when blast radius matters most; blue-green for the cleanest instant cutover.

Blue-green

Canary

Flips 100% at once

Shifts 5–10% first, then ramps

Bad release hits everyone briefly

Bad release hits a fraction

Rollback: flip back, instant

Rollback: auto on alarm

Cost: two full stacks

Cost: slower, more wiring

They’re checking: That you tie each to blast radius and rollback speed, not just define them.

Q.What do buildspec.yml and appspec.yml do?

A.buildspec.yml = how to build (CodeBuild); appspec.yml = how to deploy (CodeDeploy).

buildspec.yml

appspec.yml

Read by: CodeBuild

Read by: CodeDeploy

Defines: phases + artifacts

Defines: hooks + traffic shift

Keys: install, build

Keys: BeforeInstall, AfterAllowTraffic

Both live in the repo, so the pipeline is versioned with the code.

They’re checking: That you know which service reads which file, and why they’re in-repo.

Your turn, build & push a container image

The container half is the cheapest to try: create a registry and push an image (ECR free tier covers it). About 15 minutes.

Now do it in your own account

~15 min Steps 1–4 stay in the free tier

You’ll build a container image and push it to AWS’s private registry (ECR), then optionally run it live on Fargate. Throughout, replace <acct> with your 12-digit account ID and <region> with your region (e.g. us-east-1).

Before you start

4 to have ready

An AWS account with an IAM admin user (not root), created in Lesson 1.

AWS CLI v2, installed and signed in (it should print your account, not an error).

aws sts get-caller-identity

Docker installed and running locally.

docker --version

A folder with a Dockerfile. No app? The Containers → GitOps starter has one ready.

1
Grab your account ID, you’ll paste it into the commands below.
Free tier
Your terminal
aws cli
```
$ aws sts get-caller-identity --query Account --output text
```
You should see: your 12-digit account ID, e.g. 123456789012.
2
Create a private ECR repository for your image.
Free tier
Your terminal
aws cli
```
$ aws ecr create-repository --repository-name hello-aws --region <region>
```
AWS docs: ecr create-repository
You should see: a JSON blob with a repositoryUri ending in /hello-aws, that’s your image’s address.
3
Log Docker in to ECR (the token is temporary, about 12 hours).
Free tier
Your terminal
aws cli
```
$ aws ecr get-login-password --region <region> | docker login --username AWS --password-stdin <acct>.dkr.ecr.<region>.amazonaws.com
```
AWS docs: ecr get-login-password
You should see: Login Succeeded.
If a later push fails with “denied”, your token expired, just run this line again.
4
Build your image, tag it for ECR, and push it.
Free tier
Your terminal, in the folder with your Dockerfile
aws cli
```
$ docker build -t hello-aws .
docker tag hello-aws:latest <acct>.dkr.ecr.<region>.amazonaws.com/hello-aws:latest
docker push <acct>.dkr.ecr.<region>.amazonaws.com/hello-aws:latest
```
You should see: push prints layer digests, then the image appears under ECR → Repositories → hello-aws in the console.
5
Optional: run it live on Fargate to watch it serve, then stop it.
Costs money
Console → ECS → Clusters → Create cluster
aws cli
```
$ aws ecs create-cluster --cluster-name hello-aws
```
AWS docs: ecs create-cluster
You should see: the cluster shows ACTIVE; once you add a service/task it reaches RUNNING.
Fargate bills per second. The moment you’ve seen it run, do the teardown on the right.

Last step: tear it down

Once you’ve seen it work, remove everything so nothing keeps billing.

Delete the repo and its images.

aws ecr delete-repository --repository-name hello-aws --force

Ran step 5? Stop the task and delete the cluster. Fargate bills per second while a task is RUNNING.

Confirm the ECS console shows no running tasks and no service before you walk away.

Next day, glance at the Billing console. A $0.00–$0.01 line is normal; anything more means something’s still on.

Next up

That’s the AWS Basics track

You've gone from a locked-down account to identity, compute, storage, networking, and shipping containers, the core a junior cloud engineer is expected to operate. Next: put it together in a capstone.