What Is Amazon ECS? Tasks, Services and Fargate

What Amazon ECS is

Amazon ECS is a fully managed container orchestration service. You build an image, store it in a registry, and describe how to run it. ECS starts the containers, replaces the ones that fail, and scales them on request. It connects to other AWS services by default: images come from Amazon ECR, logs go to CloudWatch Logs, traffic arrives through Elastic Load Balancing, and permissions come from IAM.

Core concepts

• Cluster: a logical grouping of tasks and services. It runs on the capacity registered to it.
• Task definition: a JSON blueprint for one or more containers. It sets the image, CPU and memory, ports, network mode, logging and IAM roles. Each change registers a new numbered revision in the same family.
• Task: a running instance of a task definition inside a cluster. Use a standalone task for a batch job.
• Service: keeps a desired number of tasks running and replaces any that stop. It can also attach a load balancer and auto scaling.
• Container instance: an EC2 instance registered to a cluster. It runs the ECS container agent, which reports task state and starts and stops tasks. Fargate hides this layer.
• Capacity provider: decides which capacity runs the tasks. A service or task selects one through a capacity provider strategy, and a cluster can set a default strategy.

Capacity: Fargate, EC2 and ECS Managed Instances

• AWS Fargate: serverless compute. You set vCPU and memory per task and never manage a server. AWS describes it as ideal for variable workloads and for getting started quickly.
• Amazon EC2 instances: you choose the instance types and their number, and you maintain them. Use this for specialised hardware such as GPUs, capacity reservations, or specific instance types.
• Amazon ECS Managed Instances: EC2 instances that AWS provisions, patches, scales and maintains for you, with access to specific instance types such as GPU or high network performance.

Most of a task definition is the same on every capacity type. Fargate adds two requirements: the awsvpc network mode, and a task-level CPU and memory size from a fixed table.

A minimal task definition

The example runs one web container on Fargate with 0.25 vCPU and 512 MiB of memory, pulls its image from ECR, and sends logs to CloudWatch.

{
  "family": "web-api",
  "requiresCompatibilities": ["FARGATE"],
  "networkMode": "awsvpc",
  "cpu": "256",
  "memory": "512",
  "runtimePlatform": {
    "cpuArchitecture": "X86_64",
    "operatingSystemFamily": "LINUX"
  },
  "executionRoleArn": "arn:aws:iam::123456789012:role/ecsTaskExecutionRole",
  "containerDefinitions": [
    {
      "name": "web",
      "image": "123456789012.dkr.ecr.us-east-1.amazonaws.com/web-api:1.4.2",
      "essential": true,
      "portMappings": [{ "containerPort": 8080, "protocol": "tcp" }],
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/web-api",
          "awslogs-region": "us-east-1",
          "awslogs-stream-prefix": "web"
        }
      }
    }
  ]
}

256 CPU units with 512 MiB is one of the supported Fargate combinations. The execution role lets ECS pull the image and write logs. There is no taskRoleArn because the app makes no AWS calls. Create the log group first, or set awslogs-create-group to true and grant the execution role permission to create it. Then register the definition and start a service:

aws ecs register-task-definition --cli-input-json file://web-api.json

aws ecs create-service --cluster prod --service-name web-api \
  --task-definition web-api --desired-count 2 --launch-type FARGATE \
  --network-configuration "awsvpcConfiguration={subnets=[subnet-aaa111,subnet-bbb222],securityGroups=[sg-0123456789abcdef0],assignPublicIp=DISABLED}"

aws ecs describe-services --cluster prod --services web-api

Networking modes

The network mode decides how a task gets its network identity. AWS recommends awsvpc unless you have a specific reason to use another mode.

• awsvpc: each task gets its own elastic network interface and a private IP address, with the same networking properties as an EC2 instance. Fargate requires this mode. Each task uses a VPC IP address, so size subnets for peak task count.
• bridge: Docker virtual networking inside each EC2 instance. It is the default on Linux EC2 when no mode is set.
• host: containers use the instance network directly. Dynamic host ports are not allowed, so only one task from a definition can run on each instance.
• none: no external network connectivity.
• default: Docker nat networking on Windows EC2.

Load balancing with an Application Load Balancer

An Application Load Balancer routes HTTP and HTTPS traffic at the application layer and supports path-based routing. For a service in awsvpc mode, create the target group with the ip target type, because each task is attached through its network interface rather than an instance. ECS also needs its service-linked role to register and deregister targets as tasks start and stop.

Service auto scaling

ECS service auto scaling uses Application Auto Scaling to change a service's desired task count. ECS publishes average CPU and memory utilization to CloudWatch, and you can scale on those or on other metrics. The supported types are:

• Target tracking: hold a metric near a target value, such as average CPU at 60 percent.
• Step scaling: adjust the task count by set increments based on how far a CloudWatch alarm is breached.
• Scheduled scaling: change the desired count at set dates and times.
• Predictive scaling: scale ahead of load using patterns in historical data.
• SQS backlog: scale worker tasks on the number of messages waiting per task.

During a deployment, Application Auto Scaling turns off scale-in but leaves scale-out running, unless you suspend it.

Task role and task execution role

Both roles are IAM roles attached to a task, and they do different jobs.

• Task execution role: used by the ECS and Fargate agents, not your code. It pulls the image from a private ECR repository, writes logs with the awslogs driver, and reads any Secrets Manager secret or SSM parameter the task definition references. AWS provides the managed policy AmazonECSTaskExecutionRolePolicy as a starting point.
• Task role: used by your application. Its permissions apply when the container calls S3, DynamoDB, SQS or any other AWS API through the SDK or CLI. ECS delivers these credentials the same way on Fargate and EC2.

Grant the task role only what the app needs. AWS also notes that containers are not a security boundary, and a task role does not change that.

Logging to CloudWatch

The awslogs log driver sends each container's stdout and stderr to CloudWatch Logs. On Fargate you turn it on with a logConfiguration block in the task definition, as in the example above. On EC2, the container agent must be version 1.9.0 or later to support awslogs. Apps that write to files instead of stdout need a log router such as FireLens.

Deployments: rolling update and blue/green

The rolling update (ECS) deployment type replaces tasks in place. Two settings control the pace. minimumHealthyPercent is the floor of healthy tasks during the rollout, and maximumPercent is the ceiling. With two tasks, a minimum of 100 and a maximum of 200 lets ECS start two new tasks before it stops the two old ones.

ECS also has its own blue/green type. The service creates a green revision, optionally sends it test traffic, shifts production traffic, waits for a bake time, and then terminates the blue revision. CloudWatch alarms can roll the deployment back. Managed traffic shifting needs an Application Load Balancer, a Network Load Balancer, Service Connect or VPC Lattice. The older CodeDeploy blue/green type is still documented, but AWS recommends the ECS-native type.

Pricing

There is no additional charge for ECS orchestration. You pay for the compute and resources your containers use, so the bill depends on the capacity option.

• Fargate: billed per vCPU, memory and storage requested, from the moment the image is pulled until the task terminates. Usage is rounded up to the nearest second, with a one-minute minimum.
• Fargate Spot: a discount of up to 70 percent for interruption-tolerant tasks. AWS gives a two-minute warning before it reclaims capacity.
• ECS Managed Instances: a per-instance management fee on top of standard EC2 charges.
• EC2: no ECS fee. You pay for the instances, EBS volumes and public IPv4 addresses you create.

Rates vary by region and change over time, so check the Amazon ECS pricing page before you estimate a bill.

ECS or Kubernetes: a short comparison

ECS does not expose the Kubernetes API. Amazon EKS runs Kubernetes and adds a per-cluster control plane fee. For the pricing lines and a decision rule, read EKS vs ECS. The short version:

Choose ECS when

• The team does not know Kubernetes and does not want to learn it now.
• The workload is a set of services behind load balancers, and AWS-native IAM covers the access model.
• You want fewer components to patch and operate.

Choose Kubernetes on EKS when

• You need the Kubernetes API, Helm charts, or operators.
• You already run Kubernetes elsewhere and want one set of manifests and tools.
• You may move the workload to another cluster later.

Where SeaGit fits

SeaGit does not deploy to Amazon ECS. SeaGit provisions a managed Kubernetes cluster on Amazon EKS in your own AWS account and deploys your app to it. If ECS already fits your team, use ECS directly and skip SeaGit for that path. If you want Kubernetes portability with a simple deploy flow, that is the path SeaGit is built for.

Frequently asked questions