Skipping “what is a container” — this is the model experienced engineers reach for when reasoning about ECS in production.

Task definitions are immutable revisions, not mutable configs

Every time you change a container image, CPU/memory allocation, or environment variable in ECS, you’re not editing an existing task definition — you’re creating a new numbered revision (family:N) alongside every prior one. A running service references a specific revision, and deployments work by shifting the service’s desired tasks from the old revision to the new one, never by mutating tasks in place. This immutability is what makes rollbacks trivial (point the service back at the previous revision number) and is the same architectural pattern Lambda uses for function versions — it’s not a coincidence; it’s how AWS generally solves “how do you deploy new code without breaking what’s currently running.”

The scheduler and the placement engine are two separate decisions

ECS makes two distinct decisions when starting a task: first, the service scheduler decides how many tasks should exist right now to satisfy the desired count, factoring in deployment configuration (minimum/maximum healthy percent) during rolling updates; second, the placement engine decides which specific container instance (EC2 launch type only — Fargate abstracts this away entirely) should host each task, based on placement strategies (binpack, spread, random) and placement constraints (distinctInstance, custom attribute expressions). Engineers debugging “why did my task land on that host” need to separate these two layers — a scheduler decision about desired count won’t explain host selection, and vice versa.

Capacity providers decouple “what to run” from “what to run it on”

A capacity provider is the abstraction that lets a service say “run on Fargate” or “run on this Auto Scaling group of EC2 instances” without the service definition itself managing infrastructure scaling. Capacity provider strategies let a single service split its tasks across multiple providers with weighted ratios — for example, a base of on-demand Fargate tasks plus a weighted overflow onto Fargate Spot for cost optimization, with ECS handling the split automatically as desired count changes.

What actually happens between “update service desired count” and “a healthy container is receiving traffic.”

When a service’s desired count changes — or a task fails a health check and needs replacing — the ECS control plane’s scheduler evaluates the gap between desired and running count and issues a start-task request. For EC2 launch type, this request goes through the placement engine, which queries the cluster’s registered container instances for available CPU, memory, port, and ENI capacity, applies the configured placement strategy to rank candidates, and applies any placement constraints to filter them, before selecting a host and instructing that instance’s ECS agent to pull the image and start the container.

For Fargate, there is no container-instance layer to place onto at all — AWS provisions an isolated micro-VM (built on Firecracker) sized exactly to the task’s declared CPU and memory, pulls the container image into it, and starts the task, all without you ever seeing or managing an underlying host. This is the real distinction between the launch types: EC2 launch type gives you a placement problem to reason about; Fargate removes that problem entirely at the cost of per-task granularity in pricing and less control over the underlying compute.

graph TD
    A[Service Desired Count Changes] --> B[Service Scheduler]
    B --> C{Launch Type}
    C -->|EC2| D[Placement Engine]
    D --> E[Rank Container Instances]
    E --> F[ECS Agent Pulls Image]
    F --> G[Container Started on Host]
    C -->|Fargate| H[Provision Firecracker MicroVM]
    H --> I[Pull Image Into Isolated VM]
    I --> J[Container Started - No Host Visible]
    G --> K[Register with Load Balancer / Service Discovery]
    J --> K
        

Once a container starts, its health is tracked through two independent mechanisms that both feed the scheduler: the container-level health check defined in the task definition (if any), and the target group’s load balancer health check (if the service is attached to one). A task can pass its own health check but still be pulled from rotation if the load balancer’s check fails — these are separate signals evaluated independently.

A task’s lifecycle is a well-defined state machine that every ECS engineer eventually needs to debug by reading directly: PROVISIONING → PENDING → ACTIVATING → RUNNING → DEACTIVATING → STOPPING → DEPROVISIONING → STOPPED. Each transition is visible via the DescribeTasks API and in the console’s task detail view, and a task stuck at PENDING for an extended period is almost always a resource-availability or image-pull problem, while a task that reaches RUNNING and then quickly transitions to STOPPED is almost always an application-level crash or failed health check.

During a rolling deployment, the service scheduler respects minimumHealthyPercent and maximumPercent settings to decide how many old-revision tasks can be stopped and how many new-revision tasks can be started simultaneously — these two numbers are the actual levers controlling deployment speed versus availability risk, far more directly than any “deployment strategy” name in the console.

ECS scales along two independent axes: task count (how many replicas of a service are running) and cluster capacity (how much underlying compute exists to host them). Service Auto Scaling handles the first axis, typically driven by target-tracking policies on CPU or memory utilization, or custom CloudWatch metrics like request count per target. Cluster capacity — relevant only for EC2 launch type — is handled by capacity provider-managed Auto Scaling groups, which scale the underlying EC2 fleet based on aggregate reservation across the cluster, not per-instance utilization.

A common scaling failure mode on EC2 launch type is a mismatch between these two scaling loops: service-level auto scaling requests more tasks faster than the capacity provider’s Auto Scaling group can launch new instances, leaving tasks stuck in PENDING during a traffic spike. Fargate sidesteps this entirely since there’s no instance-launch lead time to account for, which is why many teams default latency-sensitive, spiky workloads to Fargate even when steady-state workloads run more cost-effectively on EC2.

Airbnb has publicly described operating ECS at very large scale, emphasizing that most of their operational tuning effort went into right-sizing capacity provider scaling lead time and target-tracking cooldowns rather than task-level configuration — a pattern that generalizes directly: at scale, the interaction between the two scaling loops matters more than any single service’s settings.

ECS’s control plane itself is a managed, Regional, multi-AZ service — you don’t design for its availability directly. The reliability engineering that matters is in how you configure task placement and deployment settings to survive an AZ failure or a bad deployment.

Spreading tasks across Availability Zones is not automatic by default on EC2 launch type — it requires an explicit spread placement strategy on the attribute:ecs.availability-zone attribute, or the underlying Auto Scaling group must already be balanced across AZs for Fargate-equivalent distribution to occur naturally. Teams that only bin-pack for density without a spread constraint can end up with a service’s entire capacity concentrated in a single AZ, which defeats Multi-AZ resilience even though every individual task appears healthy.

ECS security design centers on a distinction that trips up teams new to the service: the task role (IAM permissions the application code inside the container assumes at runtime) and the task execution role (permissions ECS itself needs to pull images and write logs on the task’s behalf) are separate roles with separate purposes, and conflating them — granting application-level permissions to the execution role, or vice versa — is a common over-permissioning mistake that widens blast radius unnecessarily.

With awsvpc networking mode, each task gets its own ENI and can therefore have its own security group, independent of the underlying host — this is what makes true task-level network segmentation possible on ECS, rather than relying on host-level security groups shared across every task on that instance. Secrets should be injected via Secrets Manager or Parameter Store references in the task definition rather than plaintext environment variables, since task definitions themselves (including their environment variable values) are visible to anyone with ecs:DescribeTaskDefinition permission.

CloudWatch Container Insights provides per-task and per-service CPU, memory, and network metrics without requiring a sidecar or custom instrumentation, and is the standard starting point for ECS observability — but it’s opt-in per cluster and carries its own cost, which is why some cost-sensitive teams disable it and rely on the base ECS service and task metrics instead for less granular but free monitoring.

Application logs are typically routed via the awslogs log driver directly to CloudWatch Logs, configured per container in the task definition, though teams standardizing on a broader observability stack (Datadog, Splunk) often use the firelens log driver instead, which routes logs through a Fluent Bit or Fluentd sidecar container for more flexible destination routing. ECS also emits service-level events (deployment started, tasks failed to start, steady state reached) queryable via DescribeServices and forwardable to EventBridge — this event stream is the primary mechanism for building deployment-status alerting without polling.

A production ECS deployment pattern typically pairs the service with an Application Load Balancer for HTTP/HTTPS workloads (using target group health checks as the source of truth for task health) or Network Load Balancer for TCP-level or extreme-throughput needs, and layers in AWS Cloud Map-based Service Discovery for internal service-to-service communication that doesn’t need a load balancer at all.

graph LR
    CI[CI/CD Pipeline] -->|register new revision| TD[Task Definition Revision N+1]
    TD --> SVC[ECS Service Update]
    SVC --> SCHED[Service Scheduler]
    SCHED -->|rolling deployment| OLD[Old Revision Tasks]
    SCHED -->|rolling deployment| NEW[New Revision Tasks]
    NEW --> ALB[Application Load Balancer Target Group]
    OLD -.->|drained and stopped| STOP[Stopped]
    ALB --> USERS[End Users / Internal Callers]
    SVC --> CM[Cloud Map Service Discovery]
        

Multi-account, multi-environment deployments commonly separate task definitions per environment (dev/staging/prod) while sharing a common base image built once in CI, promoted through environments by updating environment-specific task definition revisions — keeping the image itself immutable across the promotion pipeline while only environment-specific configuration (secrets ARNs, resource sizing) changes between revisions.

Samsung’s cloud engineering team has publicly described migrating large-scale backend services onto ECS specifically for its tight native integration with IAM and Application Load Balancer, avoiding the operational overhead of running a separate Kubernetes control plane for services that didn’t need Kubernetes-specific extensibility.

Duolingo has discussed operating a large ECS fleet blending Fargate for latency-sensitive request-serving services with EC2 capacity providers for steady-state batch and data-processing workloads, explicitly citing the cost difference between per-task Fargate pricing and densely bin-packed EC2 capacity for predictable, always-on workloads as the deciding factor per service.

Vanguard has cited ECS’s task-level IAM roles and awsvpc per-task networking as central to meeting financial-services compliance requirements for network segmentation between services running on shared infrastructure, illustrating how the security primitives covered earlier translate directly into regulatory posture in production.