Deployment and CI/CD Concepts on AWS

Deploying a code change to an ECS-based application follows a repeatable path:

Code change
  → build a new image
  → push the image to ECR
  → register a new task definition revision
  → ECS service deployment
  → new tasks start
  → health checks
  → old tasks replaced

Each step builds directly on this module's earlier lessons: the image-build step (Lesson 1), pushing to ECR (Lesson 2), and the task-definition-revision-to-service-deployment steps (Lesson 3).

The key idea worth internalizing: a new version's tasks have to prove themselves healthy first, before the old version's tasks are removed. This protects against deploying a broken update straight into production — if the new tasks never become healthy, the old ones can keep serving traffic instead of the deployment silently taking the application down.

This connects directly to Lesson 1's image/container distinction: the correct way to fix or update a running application is to build a new image and deploy it through this same path — not to open a shell into a running container and manually patch it in place. A manual in-place fix disappears the moment that container is replaced (which happens routinely), isn't reflected in the image other tasks were started from, and isn't tracked anywhere the way a new image build and deployment is. Treating deployments as immutable — build once, deploy the same artifact everywhere — is what makes the rolling-update path above actually trustworthy.

Building on Module 7's environment-variable guidance: ordinary, non-sensitive configuration (a table name, a feature flag, a target Region) is a reasonable fit for environment variables passed into a task. Production secrets — database passwords, AWS access keys, API tokens — should never be baked into a container image or committed alongside its source. An image is something that gets stored in ECR, potentially pulled by multiple people and systems, and kept around across versions; a secret baked into it is effectively distributed everywhere that image goes, indefinitely. Where a genuine secret is needed, an appropriate secrets-management mechanism is the right fit conceptually — this lesson doesn't require building one, but the distinction (configuration in environment variables; secrets somewhere designed to protect them) matters just as much here as it did for Lambda.

An ECS task can be given its own IAM role (following Module 2's least-privilege principle, applied here as it was to Lambda's execution role in Module 7) — granting the application code running inside the task only the specific AWS permissions it actually needs, rather than anything broader. This lesson introduces the concept briefly rather than walking through every configuration detail; the important habit is the same one this entire course has repeated: scope permissions to exactly what the workload needs, never anything wider "to be safe."

A container's logs (its standard output and standard error) and metrics (CPU, memory, task health) flow into CloudWatch, giving the same kind of observability Module 7 introduced for Lambda. During a deployment specifically, watching these signals is what lets a team notice a failed rollout — new tasks repeatedly failing their health check, for example — quickly, rather than discovering it only once users start reporting problems.