Project: Deploy a Containerized Application

As with every hands-on project in this course, you can work through this entirely on paper, or build it in a real AWS account if you choose to, following the same two-valid-paths pattern every earlier project has used. QuarryDev itself does not deploy real infrastructure as part of this course — the scenario below is fictional, used to practice applying this module's concepts to something realistic.

A fictional "Course API" needs to run as a containerized, load-balanced application:

Developer
  → builds container image
  → pushes to ECR
  → ECS Service (Fargate launch type)
      → tasks spread across multiple subnets/AZs
  → behind an Application Load Balancer
  → reached by Users via Route 53

Application data lives outside the disposable containers, in whichever of RDS, DynamoDB, or S3 fits the actual data shape (Module 5's access-pattern-first reasoning still applies). Observability runs through CloudWatch (this module's Lesson 5). Permissions run through IAM roles (Module 2, applied throughout this module).

Work through each component and be able to justify its placement:

• Image: built from a Dockerfile, pushed to ECR — versioned and tagged, never containing baked-in secrets (Lesson 5).
• Task definition: the blueprint specifying the image, CPU, and memory the Course API needs (Lesson 3) — not something running by itself.
• Task / Service: the ECS service maintains the desired number of running tasks, replacing any that become unhealthy (Lesson 3).
• Compute: Fargate supplies the compute capacity for those tasks, so no EC2 instances need direct management (Lesson 4) — the servers still exist; AWS operates them.
• Networking: tasks placed across multiple subnets/Availability Zones (Module 6), with a Security Group allowing inbound only from the load balancer — never opened broadly.
• Load balancer: an Application Load Balancer distributes traffic across healthy tasks and performs health checks (Lesson 3) — an unhealthy task stops receiving traffic.
• IAM boundaries: the task's own IAM role (Lesson 5) grants only the specific permissions the Course API's code actually needs (for example, reading from a specific DynamoDB table) — never broad or account-wide access.
• Storage/state: application data lives in RDS, DynamoDB, or S3 as appropriate — never relied upon to persist inside the container itself (Lesson 1).
• Monitoring: CloudWatch logs and metrics for the service and its tasks (Lesson 5), so a failed deployment or an unhealthy task is visible quickly.
• Deployment updates: a code change follows the full path from Lesson 5 — new image, new task definition revision, rolling deployment, health checks, old tasks replaced only once new ones are confirmed healthy.
• Cost: Fargate compute, the load balancer, ECR storage, and CloudWatch logs each have their own independent cost story — review current pricing rather than assuming a small training deployment is free.

If any part of this was built in a real account, work through this checklist before considering the project finished — some of these have dependencies on each other, so order matters:

1. Delete the ECS service first (scaling it down to zero tasks, then removing it), since other resources may depend on it still existing.
2. Deregister old task definition revisions, if you no longer need them (deregistering doesn't delete the revision's history, but stops it from being usable for new deployments).
3. Delete the ECS cluster, if it was created solely for this training exercise and nothing else uses it.
4. Delete the load balancer and its target group(s).
5. Delete the ECR repository and its images, once you're confident you don't need them.
6. Delete the CloudWatch log groups created for this project, if you don't need to keep the logs.
7. Delete the Security Groups and IAM roles/policies created solely for this project, once nothing still references them.
8. Confirm nothing training-related remains by checking the ECS, ECR, load balancer, and IAM dashboards directly — the same "verify, don't assume" discipline every earlier module's project applied to its own resources.