Skip to content

ECS Mental Model for Kubernetes Engineers

Goal

Build a mental model of ECS that matches Kubernetes experience.
Understand Cluster, Task Definition, Task, and Service and how they depend on each other.

Map ECS to Kubernetes

ECS ↔ Kubernetes mapping

  • Treat Task Definition as a Pod spec / Deployment template.
  • Treat Task as a Pod instance.
  • Treat Service (ECS) as a Kubernetes Deployment + Service + (optionally) HPA.
  • Treat Cluster as the logical namespace similar to a Kubernetes Cluster context.

Define this baseline:

  • Create an ECS Cluster first.
  • Create a Task Definition next.
  • Run the Task Definition as either:
  • a one-off Task (testing, batch),
  • or a long-running Service (production, ALB, auto-scaling).

ECS Cluster

Cluster responsibilities

  • Group Tasks and Services.
  • Provide a capacity provider strategy (for example, Fargate vs EC2).
  • Provide a logical namespace for scheduling.

Understand what the Cluster is not:

  • Do not treat the Cluster as a place to define VPC, subnets, or security groups.
  • Do not treat the Cluster as a place to define logging or container image details.
  • Do not assume the Cluster must know about CloudWatch or log groups.

Cluster only becomes relevant when creating:

  • a Task using aws ecs run-task --cluster ...,
  • a Service using aws ecs create-service --cluster ....

Task Definition

Task Definition responsibilities

Treat Task Definition as the canonical manifest describing what to run, not where to run.

Key Task Definition fields:

  • family: Task Definition family name.
  • requiresCompatibilities: declare compatibility, for example ["FARGATE"].
  • Note: This is strictly for validation (e.g., AWS rejects the definition if it lacks networkMode: awsvpc). The actual execution environment is chosen via launchType when calling run-task or create-service.
  • networkMode: for Fargate, set awsvpc.
  • cpu and memory: Task-level CPU and memory allocation.
  • executionRoleArn: IAM role that ECS uses to pull images and send logs.
  • containerDefinitions: array of containers in the Task.
  • name
  • image
  • portMappings
  • environment
  • logConfiguration
  • health checks (optional)

Compare this to Kubernetes:

  • Task Definition = Pod manifest.
  • family = Pod template name.
  • containerDefinitions = spec.containers.
  • Multiple containers in one Task Definition = multiple containers in one Pod.

Notice what the Task Definition does not ask for:

  • No Cluster name.
  • No VPC ID.
  • No subnet IDs.
  • No security group IDs.
  • No assignPublicIp choice.

Those are all runtime concerns handled when running the Task or creating the Service.

Task

Task responsibilities

Task is a single running instance of a Task Definition.

Run a Task via:

  • aws ecs run-task from CLI,
  • “Run Task” button in console.

Runtime parameters:

  • --cluster: choose cluster.
  • --launch-type: choose Fargate or EC2.
  • --network-configuration: choose subnets and security groups for awsvpc.
  • assignPublicIp: choose ENABLED or DISABLED.

Understand behaviour:

  • A Task runs until it exits or fails.
  • ECS does not automatically replace a Task that exits.
  • ECS does not attach a Task directly to a load balancer.

This is kubectl run style behaviour.

Service

Service responsibilities

Service uses a Task Definition and ensures a desired number of Tasks run continuously.

Key fields:

  • --cluster
  • --service-name
  • --task-definition
  • --launch-type or capacity provider
  • --network-configuration (subnets, security groups, assignPublicIp)
  • --desired-count
  • --load-balancers (optional, for ALB/NLB)
  • auto scaling (optional)

Compare behaviour:

  • Service is responsible for creating Tasks.
  • Service replaces failed Tasks automatically.
  • Service supports integration with load balancers.
  • Service supports scaling policies, similar to HPA.

Therefore:

  • Treat Service as the ECS equivalent of Kubernetes Deployment plus Service plus HPA.
  • Treat desired-count as spec.replicas.

Summary mental model

Use this model consistently

  • Create Cluster first.
  • Create Task Definition as the canonical manifest.
  • Use run-task for experiments and quick tests.
  • Use Service for production workloads, ALB integration, and auto scaling.
  • Keep Task Definition focused on container configuration; keep networking and scheduling at runtime.