ACKF logoACKF
Containers

Amazon ECS

View on GitHub

Amazon ECS

Amazon Elastic Container Service (Amazon ECS) is a regional container orchestration service that runs and manages Docker-compatible containers. It operates by running tasks and services defined with task definitions, and supports multiple compute models (Amazon EC2 and AWS Fargate). ECS typically sits between ingress (load balancers or API gateways) and backend services, scheduling containers and integrating with IAM, logging, and networking services.

🗂 Resource Category

Containers • Compute

🧠 Exam Memory Hook

Think: "Run containers + choice of EC2 or Fargate compute = Amazon ECS"

📖 Ownership

Classification: Shared Responsibility Service

AWS responsibilities: AWS operates and patches the ECS control plane (API endpoints, scheduler, and service management), the underlying AWS infrastructure, the hypervisor, and the physical hardware, and manages the Fargate managed compute runtime when Fargate is used. AWS provides integration endpoints for IAM, CloudWatch, Elastic Load Balancing, and Amazon ECR and maintains the service APIs, consoles, and backend control plane availability.

Customer responsibilities: The customer configures task definitions, container images, IAM roles and policies (task role and execution role), networking (VPC, subnets, security groups), service scaling rules, logging configuration, and any automation or CI/CD pipelines. When using the EC2 launch type the customer provisions, configures, monitors, and patches EC2 instances, container runtimes, and installed packages; the customer also builds, secures, and updates container images and application code for tasks.

Patching responsibilities: AWS patches physical infrastructure and the hypervisor and manages updates to the ECS control plane and the Fargate managed runtime. The customer patches guest operating systems, container runtimes, installed packages, application libraries, dependencies, and container images on EC2 worker instances; for Fargate the customer remains responsible for patching application code and packaged dependencies inside container images.

🏗 Typical Architecture

💡 Top 5 Features

  • Schedules and runs containerized tasks and long‑running services using task definitions.
  • Supports multiple compute models including Amazon EC2 and AWS Fargate launch types.
  • Integrates with IAM to assign fine‑grained task and execution roles for container permissions.
  • Integrates with Elastic Load Balancing to register tasks with Application or Network Load Balancers.
  • Uses task definitions to declare container images, CPU and memory requirements, environment variables, and networking mode.

✅ Top 5 Use Cases

  • Hosting containerized microservices where each microservice is deployed as an ECS service behind a load balancer.
  • Running batch or scheduled workloads as ephemeral ECS tasks initiated from EventBridge, Step Functions, or CI pipelines.
  • Migrating container workloads to AWS while choosing between customer‑managed EC2 instances or serverless Fargate compute.
  • Running stateless web frontends that scale based on request load and integrate with ALB for routing and health checks.
  • Processing asynchronous jobs with worker tasks that pull messages from Amazon SQS and report metrics to CloudWatch.

🏗 Architecture Placement

ECS runs in a customer AWS account within a region and typically operates inside a VPC; it receives traffic routed from load balancers, API Gateways, or internal services and schedules containers onto either Fargate or EC2 compute. It commonly pulls images from Amazon ECR, emits logs and metrics to CloudWatch, and uses IAM for task permissions. Placement and networking depend on the launch type and configured networking mode.

🎯 Commonly Used With

- AWS Fargate
- Amazon EC2
- Amazon ECR
- Amazon VPC
- Amazon CloudWatch

🌍 5 Real-World Examples

  • A retail backend runs product and checkout microservices as ECS services on Fargate to avoid managing EC2 instances while integrating with an Application Load Balancer for customer traffic.
  • A financial data ingestion pipeline runs scheduled ECS tasks on EC2 instances to process inbound feeds and persist results to a database, providing isolated compute for heavy processing windows.
  • A media company runs transcoding worker tasks on ECS that scale out to process queued jobs and report progress and logs to CloudWatch for operational visibility.
  • A healthcare API uses ECS services with VPC networking and task IAM roles to enforce least‑privilege access to protected data stores and audit via CloudWatch.
  • A logistics platform runs background job processors on ECS that consume SQS messages, enabling decoupled asynchronous processing and operational monitoring.

🎓 AWS Exam Clues

  • Choose ECS when a question requires container orchestration with an AWS‑managed control plane and options for EC2 or Fargate compute models.
  • If the scenario mentions task definitions, desired count, or task role permissions, ECS is likely relevant.
  • When the exam describes responsibility for patching guest OS on worker nodes while the control plane is managed, expect a shared responsibility answer (EC2 launch type).
  • If the architecture requires direct integration with ALB/NLB for service traffic and health checks, ECS services can register containers with load balancers.
  • When per‑task IAM permissions or an execution role for pulling images and sending logs is required, prefer ECS with task and execution roles.

📝 Quick Revision

Amazon ECS schedules and runs Docker‑compatible containers as tasks or services and supports EC2 and Fargate compute models. Choose compute model based on operational responsibility and patching: EC2 requires managing instances and OS patching, while Fargate shifts compute runtime management to AWS; always plan for image security, logging, and networking configuration.

🏷 Keywords

task definition • service • task • cluster • Fargate • EC2 launch type • task role • task execution role • container image • capacity provider • service discovery • load balancer integration