What Is Amazon ECS?

Amazon Elastic Container Service (Amazon ECS) is a managed container orchestration service that deploys, runs, and scales containerized applications on AWS. Instead of manually starting Docker containers on individual servers, developers define the application containers, resource requirements, networking, permissions, and desired number of running instances. ECS schedules workloads, monitors their state, and replaces tasks when necessary.

ECS is commonly used for REST APIs, microservices, background workers, scheduled jobs, and internal applications. It integrates with Amazon ECR, Application Load Balancers, CloudWatch, IAM, AWS Secrets Manager, and Service Auto Scaling. However, ECS does not automatically make an application reliable or scalable: container health, network connectivity, deployment configuration, database capacity, and failure handling still need deliberate engineering.

Table of Contents

• What Amazon ECS Provides
  • Why Container Orchestration Is Needed
  • ECS vs. Kubernetes and AWS Lambda
• How Amazon ECS Works
  • Clusters, Task Definitions, Tasks, and Services
  • Task Lifecycle and Desired State
  • ECS on Fargate vs. EC2
• Networking, Service Discovery, and Security
  • VPC Networking and Load Balancing
  • Task Roles, Execution Roles, and Secrets
  • Communication Between Services
• ECS Deployments and Auto Scaling
  • Rolling Deployments and Rollbacks
  • Service Auto Scaling
  • Health Checks and Graceful Shutdown
• Production Design Example: API and Background Workers
  • Production Architecture
  • Failure Scenario: Unhealthy Tasks During a Release
• Ready-to-Use Example: Deploy FastAPI to ECS Fargate
  • 1. Create and Containerize the Application
  • 2. Provision ECS Infrastructure with Terraform
  • 3. Build, Push, and Deploy the Container
  • 4. Verify, Troubleshoot, and Clean Up
• Performance, Pricing, and Operations
  • Capacity Planning and Cost
  • Observability and Operational Metrics
• Common Mistakes and Production Checklist
  • Common ECS Mistakes
  • Production Checklist
• Frequently Asked Questions
  • What Is Amazon ECS Used For?
  • What Is the Difference Between ECS and Docker?
  • What Is the Difference Between ECS and Fargate?
  • Is Amazon ECS Kubernetes?
  • Is Amazon ECS Serverless?
  • Is Amazon ECS Free?
• Conclusion
  • More Articles to Read

What Amazon ECS Provides

Containers package an application and its dependencies into a deployable image. ECS provides the orchestration layer that decides where those containers run, maintains the requested number of tasks, connects applications to AWS networking, and coordinates deployments.

The main difference between running a container manually and using ECS is that ECS continuously manages the workload's desired state rather than depending on engineers to start, monitor, and restart each container individually.

Why Container Orchestration Is Needed

Imagine an API packaged into a Docker image. Running the image on one EC2 instance might be sufficient during development, but production introduces additional requirements:

• Run multiple copies of the API for availability.
• Distribute instances across failure domains.
• Replace containers when processes crash.
• Route traffic only to healthy application instances.
• Release new application versions without stopping every container.
• Scale capacity when CPU utilization or request volume increases.
• Inject secrets and AWS permissions securely.
• Collect logs and operational metrics centrally.

ECS addresses these orchestration concerns through task definitions, a service scheduler, capacity integrations, load balancing, and deployment controls.

Docker remains useful for image creation and local development. ECS consumes container images and handles how they are executed across AWS infrastructure. For the container fundamentals, see What Is Docker?.

ECS vs. Kubernetes and AWS Lambda

ECS is an AWS-native orchestration platform. Kubernetes is an open-source orchestration system with a broader platform ecosystem, while AWS Lambda uses a function invocation model instead of long-running container services.

For an AWS-focused application consisting of a few APIs and workers, ECS can be operationally simpler than maintaining an extensible Kubernetes platform. Kubernetes becomes more attractive when teams require its ecosystem, standardized resource APIs, custom controllers, or portability across supported environments.

See What Is Kubernetes? for a deeper comparison of container orchestration models.

How Amazon ECS Works

ECS organizes container workloads using several resources. Their names are similar enough to confuse new users, but each resource answers a different operational question.

Understanding the distinction between a task definition, an individual task, and a service is essential when deploying applications and troubleshooting scaling or deployment failures.

Clusters, Task Definitions, Tasks, and Services

An ECS application is commonly composed of the following resources:

A task definition specifies container images, CPU and memory configuration, ports, environment variables, secrets, logging, IAM roles, and other runtime settings. Every registered change creates a new revision.

A task is an execution of a particular task-definition revision. A service maintains a specified number of tasks, replaces failed tasks, and coordinates changes when a new task definition is deployed.

ECS can also run standalone tasks using RunTask. This is useful for migrations, one-off jobs, and short-lived workloads that do not need a continuously running service.

Task Lifecycle and Desired State

Suppose an ECS service has a desired count of three tasks. The service scheduler attempts to maintain three running tasks, subject to available capacity and configuration.

If one task stops unexpectedly, ECS can launch a replacement. If a new deployment changes the task definition, the scheduler replaces old tasks according to the deployment strategy.

Common task states include PROVISIONING, PENDING, ACTIVATING, RUNNING, DEACTIVATING, STOPPING, and STOPPED. The exact transitions depend on the capacity type and task configuration.

A task reaching RUNNING does not necessarily mean the application is ready to serve traffic. Container and load balancer health checks can still fail during initialization.

ECS on Fargate vs. EC2

ECS orchestrates containers, but those containers still need compute resources. Two common capacity choices are AWS Fargate and the ECS EC2 launch type.

• Fargate: AWS manages the underlying compute infrastructure. You choose supported task CPU and memory combinations without managing EC2 instances.
• EC2 launch type: Your ECS tasks run on managed or self-managed EC2-backed capacity, depending on the configuration. This offers greater host control but adds infrastructure responsibilities.

Fargate is often a practical default for independent APIs, workers, and small-to-medium services. EC2-backed capacity may be attractive for consistently utilized workloads, specialized host requirements, GPU use cases, or cluster-level cost optimization.

Choosing Fargate does not mean that all scaling becomes unlimited. Task quotas, deployment behavior, networking capacity, downstream services, and supported resource configurations still constrain throughput.

Networking, Service Discovery, and Security

ECS networking determines how containers receive incoming requests, reach databases and queues, and access AWS services. Incorrect networking is a frequent reason tasks fail to start or remain unhealthy.

The core production principle is to expose only the components that need public access while keeping application tasks and data services in controlled network segments.

VPC Networking and Load Balancing

With the awsvpc network mode, an ECS task receives its own elastic network interface and can have associated security groups. Fargate tasks use this networking model.

A common production architecture uses an internet-facing Application Load Balancer in public subnets and API tasks in private subnets:

1. The client connects to the Application Load Balancer.
2. The load balancer selects a healthy target.
3. The request is forwarded to an ECS task's private IP address.
4. The container processes the request and returns its response.

When using awsvpc task networking, an ALB target group must use the ip target type rather than instance.

Private tasks still need outbound connectivity when pulling images, sending logs, or calling AWS APIs. This may be provided through NAT, suitable VPC endpoints, or other explicitly configured network paths.

For load distribution and target health, read What Is a Load Balancer?.

Task Roles, Execution Roles, and Secrets

ECS distinguishes between two important IAM roles:

• Task execution role: Used by the ECS/Fargate infrastructure to perform operations such as pulling private images from Amazon ECR and sending logs to CloudWatch.
• Task role: Provides permissions to the application running inside the container, such as reading S3 objects or sending SQS messages.

Do not use the task execution role as a substitute for application permissions. Assign least-privilege permissions through the appropriate role.

For sensitive configuration, ECS can reference values stored in AWS Secrets Manager or Systems Manager Parameter Store. Access to those secrets requires the correct execution-role permissions for injection or application task-role permissions when fetched directly by the application.

Secrets injected as environment variables are generally resolved when a task starts. Rotating a secret does not automatically replace its value inside already-running containers; the application needs an appropriate refresh or redeployment strategy.

Communication Between Services

Microservices running on ECS often need to communicate without relying on individual task IP addresses. Task IPs may change during deployments, scaling, and failure recovery.

ECS supports integrations for service discovery and service-to-service communication, including AWS Cloud Map and ECS Service Connect.

Use service discovery when one internal service must call another by a stable logical name. For asynchronous communication, a queue such as Amazon SQS may be preferable because the producer does not need the consumer to be immediately available.

ECS Deployments and Auto Scaling

Container deployment is not simply replacing one image with another. New tasks need capacity, network connectivity, image access, startup time, and passing health checks before they can reliably handle traffic.

ECS provides deployment controls that help coordinate this process, while Service Auto Scaling adjusts task counts according to workload demand.

Rolling Deployments and Rollbacks

During a rolling deployment, ECS replaces tasks using the new task-definition revision while maintaining availability according to the service's deployment settings.

Two important parameters are minimumHealthyPercent and maximumPercent. They influence how many tasks may remain available and how much extra capacity may run during a deployment.

For example, a service with four desired tasks and a maximum of 200% may temporarily run up to eight tasks while replacing the old version, subject to capacity and other deployment controls.

The ECS deployment circuit breaker can detect certain failures that prevent a rolling deployment from reaching a healthy state. When rollback is enabled and a suitable previously completed deployment exists, ECS can return to that revision.

However, circuit breakers cannot detect every application regression. A container might pass health checks while returning incorrect data or introducing a memory leak that becomes visible only after sustained traffic.

See What Is Rolling Deployment? for deployment mechanics and failure trade-offs.

Service Auto Scaling

ECS Service Auto Scaling integrates with Application Auto Scaling to modify a service's desired task count.

Common scaling signals include:

• CPU utilization: Useful for CPU-intensive APIs or workers.
• Memory utilization: Useful when memory usage correlates with request or task pressure.
• ALB requests per target: Useful for request-driven HTTP APIs.
• Queue backlog: Useful for workers processing messages from SQS.
• Custom metrics: Application-specific measures such as jobs waiting or processing latency.

Scaling API tasks by CPU alone can be misleading. An API blocked on a slow database may consume little CPU while clients experience high latency.

For EC2-backed ECS clusters, increasing desired task count may also require scaling the underlying EC2 capacity. Fargate abstracts the host provisioning step, although task launch and service quotas still apply.

Health Checks and Graceful Shutdown

ECS deployments rely on health checks to decide whether tasks are suitable for continued operation. Depending on configuration, these checks can include container-level health checks and load balancer target checks.

A lightweight endpoint such as GET /health is useful for an API. It should establish that the application can serve basic requests without performing expensive database queries on every check.

Graceful shutdown matters just as much as startup. When ECS stops a task, the containerized application should handle termination signals, stop accepting new work, and complete or safely release in-flight operations within its configured shutdown window.

For a detailed distinction between process liveness and traffic readiness, see Health Checks, Readiness, and Liveness Probes.

Production Design Example: API and Background Workers

Consider a SaaS application that accepts document uploads, stores metadata, and generates reports. Its REST API must remain responsive while longer-running work executes asynchronously.

ECS can host both the API and worker containers, but these components should run as separate services because they have different scaling signals and failure characteristics.

Production Architecture

A production deployment can use:

• Application Load Balancer: Receives HTTPS requests and routes them to healthy API tasks.
• ECS API service: Runs at least two FastAPI tasks across suitable Availability Zones.
• Amazon RDS PostgreSQL: Stores transactional application data.
• Amazon S3: Stores documents and generated files.
• Amazon SQS: Buffers report-generation jobs.
• ECS worker service: Processes jobs without public HTTP ingress.
• Amazon ECR: Stores deployable container images.
• CloudWatch: Collects application logs and operational metrics.

When a user requests a report, the API creates a database record, schedules processing through a reliable queue handoff, and returns a job identifier. A worker retrieves the message, generates the report, uploads it to S3, updates job status, and acknowledges the message.

API capacity can scale according to HTTP load, while worker capacity scales according to queue backlog or message age. The two services can share common libraries and base images without sharing a deployment schedule.

Failure Scenario: Unhealthy Tasks During a Release

Suppose a new FastAPI release introduces a database query that takes several seconds under load. Newly deployed tasks start and return healthy responses from /health, but request latency increases and the database connection pool begins to saturate.

ECS may consider the rollout successful because the tasks are running and pass configured health checks. The deployment circuit breaker cannot guarantee detection of business-level performance regressions.

A safer release process combines health checks with alarms on latency, error rate, database connection pressure, and other important service-level indicators.

If the deployment causes sustained failures, the release pipeline should be able to restore a previously validated task-definition revision. Database schema changes must remain compatible with both application versions during the rollback window.

Ready-to-Use Example: Deploy FastAPI to ECS Fargate

This example builds a small FastAPI container, pushes it to Amazon ECR, and deploys it to ECS Fargate using Terraform. An Application Load Balancer distributes requests across two running tasks.

To keep the demo independently deployable, it provisions a new VPC, two public subnets, an internet gateway, an ALB, and Fargate tasks with public IP addresses. The task security group permits application traffic only from the ALB. Production workloads should generally place tasks in private subnets and provide controlled egress.

1. Create and Containerize the Application

Create the project structure:

ecs-demo/
  app/
    main.py
    requirements.txt
    Dockerfile
  terraform/
    main.tf
    outputs.tf

Create app/main.py:

import os
import socket

from fastapi import FastAPI


app = FastAPI()


@app.get("/health")
def health():
    # Lightweight health check for the ALB.
    return {"status": "ok"}


@app.get("/")
def index():
    return {
        "message": "Hello from Amazon ECS!",
        "hostname": socket.gethostname(),
        "environment": os.getenv("APP_ENV", "development"),
    }

Create app/requirements.txt:

fastapi>=0.115,<1
uvicorn>=0.30,<1

For a reproducible production build, lock exact dependency versions and rebuild images when security updates are approved.

Create app/Dockerfile:

FROM python:3.12-slim

WORKDIR /app

# Install runtime dependencies.
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

# Add application code.
COPY main.py .

# Run as a non-root user.
RUN useradd --create-home appuser
USER appuser

EXPOSE 8000

# Exec form keeps signal handling predictable.
CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

This container has one Uvicorn process. For Fargate workloads, adding multiple workers per task is a capacity decision rather than an automatic improvement. Test CPU use, memory, and request concurrency before increasing workers.

2. Provision ECS Infrastructure with Terraform

Create terraform/main.tf:

terraform {
  required_version = ">= 1.5.0"

  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = "~> 6.0"
    }
  }
}

provider "aws" {
  region = "us-west-2"
}

variable "image_uri" {
  description = "Fully qualified ECR container image URI."
  type        = string
}

# -----------------------------------
# Networking
# -----------------------------------

data "aws_availability_zones" "available" {
  state = "available"
}

resource "aws_vpc" "demo" {
  cidr_block           = "10.42.0.0/16"
  enable_dns_support   = true
  enable_dns_hostnames = true

  tags = {
    Name = "ecs-demo"
  }
}

resource "aws_internet_gateway" "demo" {
  vpc_id = aws_vpc.demo.id
}

resource "aws_subnet" "public" {
  count = 2

  vpc_id = aws_vpc.demo.id

  cidr_block = cidrsubnet(
    aws_vpc.demo.cidr_block,
    8,
    count.index,
  )

  availability_zone = (
    data.aws_availability_zones.available.names[count.index]
  )

  map_public_ip_on_launch = true

  tags = {
    Name = "ecs-demo-public-${count.index + 1}"
  }
}

resource "aws_route_table" "public" {
  vpc_id = aws_vpc.demo.id

  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.demo.id
  }
}

resource "aws_route_table_association" "public" {
  count = 2

  subnet_id      = aws_subnet.public[count.index].id
  route_table_id = aws_route_table.public.id
}

# -----------------------------------
# Security groups
# -----------------------------------

resource "aws_security_group" "alb" {
  name_prefix = "ecs-demo-alb-"
  vpc_id      = aws_vpc.demo.id
}

resource "aws_vpc_security_group_ingress_rule" "alb_http" {
  security_group_id = aws_security_group.alb.id
  cidr_ipv4         = "0.0.0.0/0"

  ip_protocol = "tcp"
  from_port   = 80
  to_port     = 80
}

resource "aws_vpc_security_group_egress_rule" "alb_outbound" {
  security_group_id = aws_security_group.alb.id
  cidr_ipv4         = "0.0.0.0/0"
  ip_protocol       = "-1"
}

resource "aws_security_group" "tasks" {
  name_prefix = "ecs-demo-tasks-"
  vpc_id      = aws_vpc.demo.id
}

resource "aws_vpc_security_group_ingress_rule" "tasks_http" {
  security_group_id = aws_security_group.tasks.id

  referenced_security_group_id = aws_security_group.alb.id

  ip_protocol = "tcp"
  from_port   = 8000
  to_port     = 8000
}

resource "aws_vpc_security_group_egress_rule" "tasks_outbound" {
  security_group_id = aws_security_group.tasks.id
  cidr_ipv4         = "0.0.0.0/0"
  ip_protocol       = "-1"
}

# -----------------------------------
# ECR, IAM, and logs
# -----------------------------------

resource "aws_ecr_repository" "api" {
  name = "ecs-demo-api"

  image_scanning_configuration {
    scan_on_push = true
  }

  tags = {
    Environment = "development"
  }
}

data "aws_iam_policy_document" "ecs_trust" {
  statement {
    actions = ["sts:AssumeRole"]

    principals {
      type = "Service"
      identifiers = [
        "ecs-tasks.amazonaws.com"
      ]
    }
  }
}

resource "aws_iam_role" "execution" {
  name_prefix        = "ecs-demo-exec-"
  assume_role_policy = data.aws_iam_policy_document.ecs_trust.json
}

resource "aws_iam_role_policy_attachment" "execution" {
  role = aws_iam_role.execution.name

  policy_arn = (
    "arn:aws:iam::aws:policy/service-role/AmazonECSTaskExecutionRolePolicy"
  )
}

resource "aws_cloudwatch_log_group" "api" {
  name              = "/ecs/demo-api"
  retention_in_days = 7
}

# -----------------------------------
# ECS cluster and task definition
# -----------------------------------

resource "aws_ecs_cluster" "demo" {
  name = "ecs-demo"
}

resource "aws_ecs_task_definition" "api" {
  family                   = "ecs-demo-api"
  network_mode             = "awsvpc"
  requires_compatibilities = ["FARGATE"]

  cpu    = "256"
  memory = "512"

  execution_role_arn = aws_iam_role.execution.arn

  container_definitions = jsonencode([
    {
      name      = "api"
      image     = var.image_uri
      essential = true

      portMappings = [
        {
          containerPort = 8000
          protocol      = "tcp"
        }
      ]

      environment = [
        {
          name  = "APP_ENV"
          value = "development"
        }
      ]

      logConfiguration = {
        logDriver = "awslogs"

        options = {
          awslogs-group         = aws_cloudwatch_log_group.api.name
          awslogs-region        = "us-west-2"
          awslogs-stream-prefix = "api"
        }
      }
    }
  ])
}

# -----------------------------------
# Application Load Balancer
# -----------------------------------

resource "aws_lb" "api" {
  name               = "ecs-demo-alb"
  internal           = false
  load_balancer_type = "application"

  security_groups = [
    aws_security_group.alb.id
  ]

  subnets = aws_subnet.public[*].id
}

resource "aws_lb_target_group" "api" {
  name        = "ecs-demo-api"
  port        = 8000
  protocol    = "HTTP"
  target_type = "ip"
  vpc_id      = aws_vpc.demo.id

  health_check {
    enabled             = true
    path                = "/health"
    healthy_threshold   = 2
    unhealthy_threshold = 3
    interval            = 15
    timeout             = 5
    matcher             = "200"
  }
}

resource "aws_lb_listener" "http" {
  load_balancer_arn = aws_lb.api.arn
  port              = 80
  protocol          = "HTTP"

  default_action {
    type             = "forward"
    target_group_arn = aws_lb_target_group.api.arn
  }
}

# -----------------------------------
# ECS service
# -----------------------------------

resource "aws_ecs_service" "api" {
  name            = "ecs-demo-api"
  cluster         = aws_ecs_cluster.demo.id
  task_definition = aws_ecs_task_definition.api.arn

  desired_count = 2
  launch_type   = "FARGATE"

  deployment_minimum_healthy_percent = 100
  deployment_maximum_percent         = 200

  deployment_circuit_breaker {
    enable   = true
    rollback = true
  }

  network_configuration {
    subnets = aws_subnet.public[*].id

    security_groups = [
      aws_security_group.tasks.id
    ]

    # Demo only: use private subnets in production.
    assign_public_ip = true
  }

  load_balancer {
    target_group_arn = aws_lb_target_group.api.arn
    container_name   = "api"
    container_port   = 8000
  }

  health_check_grace_period_seconds = 30

  depends_on = [
    aws_lb_listener.http,
    aws_iam_role_policy_attachment.execution
  ]
}

This configuration creates two Fargate tasks, each with 0.25 vCPU and 512 MiB of memory, behind a public HTTP Application Load Balancer. The task security group permits incoming port 8000 traffic only from the load balancer.

The configuration uses HTTP to make local testing straightforward. Production traffic should use HTTPS with an ACM certificate, an HTTPS listener, and appropriate redirect policies. Public IP assignment on the tasks is also a demonstration choice, not the preferred production model.

The ECS task execution role allows ECS to pull the image from ECR and publish CloudWatch logs. Because this sample application does not call AWS services, it does not require a separate application task role.

Create terraform/outputs.tf:

output "ecr_repository_url" {
  value = aws_ecr_repository.api.repository_url
}

output "alb_dns_name" {
  value = aws_lb.api.dns_name
}

output "cluster_name" {
  value = aws_ecs_cluster.demo.name
}

output "service_name" {
  value = aws_ecs_service.api.name
}

3. Build, Push, and Deploy the Container

The ECR repository must exist before Docker can push the image, but the ECS service needs an image URI. Create the repository first, push the image, then apply the complete Terraform configuration.

Run these commands from the ecs-demo directory:

# Configure the AWS Region.
export AWS_REGION="us-west-2"

# Initialize Terraform.
cd terraform
terraform init

# Create the ECR repository first.
# This is a demo bootstrap step, not a routine
# production deployment workflow.
terraform apply \
  -target=aws_ecr_repository.api

# Read the repository URL.
ECR_URL="$(terraform output -raw ecr_repository_url)"

# Authenticate Docker to Amazon ECR.
aws ecr get-login-password \
  --region "$AWS_REGION" \
  | docker login \
      --username AWS \
      --password-stdin \
      "$(echo "$ECR_URL" | cut -d/ -f1)"

# Build and push the API image.
cd ../app

docker build -t ecs-demo-api:1 .

docker tag ecs-demo-api:1 "$ECR_URL:1"
docker push "$ECR_URL:1"

# Pass the image URI into Terraform.
cd ../terraform

export TF_VAR_image_uri="$ECR_URL:1"

# Provision the remaining infrastructure.
terraform plan
terraform apply

# Get the public ALB endpoint.
ALB_DNS="$(terraform output -raw alb_dns_name)"

# Test the application.
curl "http://$ALB_DNS/health"
curl "http://$ALB_DNS/"

The resulting response identifies the running application and container hostname. Repeating the request may return responses from different tasks, depending on the load balancer's routing decisions and connection reuse.

In CI/CD, use immutable image digests or unique release identifiers rather than repeatedly overwriting the same tag. Image provenance and deployment rollback become much easier when each release references an unambiguous artifact.

4. Verify, Troubleshoot, and Clean Up

ECS may need time to provision networking, pull the image, start tasks, and pass the target group's health checks. Inspect the service events and stopped-task reasons if the deployment does not stabilize.

# Inspect ECS service health and deployment status.
aws ecs describe-services \
  --cluster ecs-demo \
  --services ecs-demo-api \
  --query "services[0].{Running:runningCount,Desired:desiredCount,Events:events[0:5]}"

# List running tasks.
aws ecs list-tasks \
  --cluster ecs-demo \
  --service-name ecs-demo-api

# View container application logs.
aws logs tail "/ecs/demo-api" --since 15m

# Inspect current target health.
TARGET_GROUP_ARN="$(
  aws elbv2 describe-target-groups \
    --names ecs-demo-api \
    --query 'TargetGroups[0].TargetGroupArn' \
    --output text
)"

aws elbv2 describe-target-health \
  --target-group-arn "$TARGET_GROUP_ARN"

# Remove the infrastructure when finished.
terraform destroy

Terraform destroy may fail to delete the ECR repository while it still contains the pushed image. Remove the disposable image through the ECR API, confirm the repository is empty, and run terraform destroy again.

This is a development example with billable Fargate tasks, an Application Load Balancer, public IPv4 addresses, ECR storage, and logging. Do not leave it running after testing.

Performance, Pricing, and Operations

ECS itself is an orchestration service, but the underlying compute, networking, storage, and monitoring resources have costs. Fargate and EC2-backed deployments have substantially different cost profiles.

A reliable cost comparison must include not only container compute but also load balancers, network egress, NAT gateways or VPC endpoints, public IPv4 addresses, log ingestion, and idle capacity.

Capacity Planning and Cost

For an HTTP API, estimate the safe throughput of one task under representative traffic and latency targets. Use this measurement to determine the initial desired count and scaling thresholds.

For example, if one task handles 150 requests per second at an acceptable latency and the application expects 600 requests per second, four tasks provide the theoretical minimum under those assumptions.

Production capacity usually needs additional headroom for failures, deployments, uneven traffic, and downstream variability. A fleet of four tasks operating continuously at its tested limit has little room to absorb disruptions.

For Fargate, compute charges are generally based on configured task resources and running duration, with additional applicable features or resources. For EC2-backed ECS, the compute cost comes from the EC2 instances and their associated infrastructure.

Task-level cost does not tell the whole story. A small low-traffic service may spend more on load balancing or networking than on the containers themselves.

Observability and Operational Metrics

Useful ECS and application metrics include:

• Running vs. desired task count: Whether the service has reached its requested capacity.
• CPU and memory utilization: Resource pressure and scaling demand.
• Task startup failures: Problems with image pulls, permissions, or networking.
• Deployment status: Whether the new service revision reaches a healthy state.
• ALB 5xx errors: Problems affecting HTTP request handling.
• Target response time: API latency observed through the load balancer.
• Unhealthy targets: Application readiness or runtime failures.
• SQS backlog and oldest message age: Worker processing pressure.

CloudWatch Logs, CloudWatch Container Insights, ECS service events, and application tracing provide complementary visibility. Logs show execution details, metrics expose trends, and traces help explain slow requests across dependencies.

Keep correlation identifiers consistent between the API, background jobs, and downstream services so incidents can be investigated across components.

Common Mistakes and Production Checklist

ECS is operationally simpler than manually managing a fleet of container hosts, but it still requires careful application and infrastructure design. Many production failures are caused by assumptions about container lifecycle, networking, or dependency capacity.

The most reliable ECS workloads treat containers as replaceable and maintain application state outside their local filesystems.

Common ECS Mistakes

Frequent mistakes include:

• Confusing ECS and Fargate: ECS orchestrates workloads; Fargate supplies managed compute.
• Running stateful applications without persistent storage design: Local data disappears when tasks are replaced.
• Giving tasks unnecessary public exposure: Direct access bypasses intended ingress controls.
• Using the wrong ALB target type: awsvpc tasks require ip targets.
• Ignoring image-pull connectivity: Tasks cannot reach ECR or other required endpoints.
• Using the execution role for application permissions: IAM responsibilities become confused.
• Deploying without meaningful health checks: ECS routes traffic to applications that are not ready.
• Failing to handle SIGTERM: Requests or jobs are interrupted during deployment.
• Scaling only by CPU: Queue backlog or response latency grows without corresponding scaling.
• Reusing mutable image tags: Rollbacks and deployments may reference ambiguous image contents.
• Ignoring dependency limits: Scaling containers overwhelms the database or another shared service.

Production Checklist

Before launching an ECS workload into production, verify these controls:

• Container images are versioned, scanned, and reproducible.
• API services run across appropriate Availability Zones.
• Application tasks use private networking unless public exposure is justified.
• Ingress is restricted through security groups and an appropriate load balancer.
• Task execution roles and application task roles follow least privilege.
• Secrets are managed securely and rotation behavior is understood.
• CPU and memory allocations are tested under representative load.
• Health checks reflect application readiness without excessive dependency work.
• Deployments have rollback procedures and adequate spare capacity.
• Applications handle graceful shutdown and idempotent background processing.
• Auto Scaling policies use meaningful workload metrics.
• Service-level monitoring covers errors, latency, task health, and dependencies.
• Cloud networking and container compute costs are monitored.

Frequently Asked Questions

Amazon ECS combines container orchestration with AWS compute and networking services, so its capabilities are often confused with those of Docker, Kubernetes, Fargate, and other AWS compute products.

What Is Amazon ECS Used For?

Amazon ECS is used to deploy and manage containerized applications on AWS. Common workloads include REST APIs, microservices, background workers, scheduled jobs, and internal services.

What Is the Difference Between ECS and Docker?

Docker is commonly used to build and run application containers. ECS is an orchestration service that schedules containerized workloads, maintains services, coordinates deployments, and integrates with AWS infrastructure.

Developers can build Docker images locally and deploy them through ECS without manually running containers on production servers.

What Is the Difference Between ECS and Fargate?

ECS is the container orchestration service. Fargate is a managed compute option for running containers without provisioning EC2 hosts.

You can run ECS workloads on Fargate or supported EC2-backed capacity. The choice affects operational responsibilities, cost, and infrastructure control.

Is Amazon ECS Kubernetes?

No. ECS is AWS's native container orchestration service and uses its own resource model and APIs. Amazon EKS is AWS's managed Kubernetes service.

Both can orchestrate containers, but their control-plane architecture, ecosystem, configuration resources, and operational workflows differ.

Is Amazon ECS Serverless?

ECS with Fargate provides a serverless infrastructure experience because AWS manages the compute hosts. ECS running on EC2-backed capacity does not remove host-management responsibilities in the same way.

Neither model removes application responsibilities such as monitoring, deployment safety, database scaling, and security.

Is Amazon ECS Free?

The ECS orchestration control plane generally does not have a separate charge for standard ECS usage, but the resources used to run applications are billable. Charges can include Fargate compute, EC2 instances, load balancers, network traffic, storage, and CloudWatch.

Always review the current AWS pricing for the selected deployment model and Region.

Conclusion

Amazon ECS is a managed container orchestration platform for running containerized applications on AWS. It manages task scheduling, service desired state, deployments, health checks, and scaling while integrating closely with AWS networking, IAM, logging, and compute services.

Its main advantage is that developers can deploy production containers without building their own orchestration platform. Fargate further reduces infrastructure work by managing compute capacity, while EC2-backed ECS provides additional host-level flexibility.

Successful production deployments still require stateless application design, secure networking, appropriate scaling policies, reliable health checks, graceful shutdown, and recovery procedures. ECS operates the container platform; the application architecture determines how well the system behaves when dependencies slow down or infrastructure fails.

Key Takeaway: Amazon ECS turns container images into managed application services. Use Fargate when simplicity is the priority, EC2-backed capacity when greater control is needed, and design every ECS workload around replaceable tasks, measurable health, safe deployments, and controlled access to dependencies.

More Articles to Read

Continue exploring these related topics for more detailed guidance on ECS configuration, production architectures, deployment strategies, infrastructure automation, and container operations.

• Amazon ECS Explained: A Beginner-Friendly Introduction
• Amazon ECS Task Definitions, Services, and Deployments Explained
• Running Production APIs and Background Workers on Amazon ECS
• What Is Terraform?
• What Is Auto Scaling?
• What Is CI/CD?
• What Is Blue-Green Deployment?