Amazon ECS Architecture: Tasks, Services, Capacity, and Operational Boundaries

Amazon Elastic Container Service is AWS’s native container orchestrator. ECS schedules tasks from versioned task definitions; long-running services maintain desired count and coordinate deployments, while standalone tasks cover batch or one-off work. The control plane is managed, but the data plane can be EC2 instances you operate, AWS Fargate capacity, or a mixture selected through capacity providers.

The objects that matter

A task definition describes container images, CPU and memory, ports, volumes, health checks, logging, and IAM roles. A service binds a task definition revision to a cluster, desired count, networking, load balancing, and rollout policy. Capacity providers decide where tasks can run and can express strategies such as a baseline on one provider with additional capacity elsewhere.

Networking and identity

With awsvpc networking, each task receives an elastic network interface and security-group policy. That is easy to reason about but consumes subnet addresses and ENI capacity. Separate the task execution role—which lets the ECS agent pull images or publish logs—from the task role used by application code. Avoid static AWS credentials inside images.

Deployments and observability

ECS services can replace tasks gradually and integrate with Application or Network Load Balancers. Health checks must represent readiness rather than merely prove that a process exists. CloudWatch Container Insights, application metrics, structured logs, deployment events, and tracing together explain failures that a single CPU graph will miss. Pin images by digest or immutable release tag so a rollback references the artifact that was actually tested.

Limits and costs

ECS itself reduces control-plane work, but EC2 capacity still requires AMI patching, scaling, and bin-packing decisions. Fargate removes those hosts but constrains some privileged and host-level workloads. Costs come from the selected compute, storage, load balancers, logging, data transfer, and optional observability—not simply from “running ECS.” Choose ECS when AWS integration and explicit infrastructure control matter more than Kubernetes portability.

Task definition revisions are release contracts

Registering a task definition creates an immutable revision in a family. The service points to a revision and launches tasks from it, so a release review should compare the complete rendered definition: image digest, command, environment and secret references, CPU and memory, port mappings, health checks, volumes, logging driver, runtime platform, execution role, and task role. Updating only the image tag is not enough when an old revision can resolve that tag to different bytes later.

The execution role is used by ECS and the container agent for platform work such as pulling from ECR or sending logs. The task role supplies credentials to application containers. Combining them makes it harder to reason about which code can call an AWS API. Credentials should arrive through the task metadata endpoint and SDK provider chain; static keys in environment variables or images bypass normal rotation and make incident containment slower.

Deployment controllers and failure containment

For the rolling ECS deployment controller, minimumHealthyPercent and maximumPercent define how much old and new capacity may coexist. They interact with cluster headroom, load-balancer health checks, container health checks, image pull time, and application startup. A setting that is safe with spare Fargate capacity can deadlock on a fully packed EC2 cluster. The deployment circuit breaker can mark a deployment failed and optionally roll it back when tasks cannot reach steady state; CloudWatch alarms can also participate in deployment failure detection.

Readiness must fail before the load balancer sends traffic, while liveness-style container checks should not restart a process merely because a downstream dependency is briefly unavailable. During termination, stop accepting work, drain connections, and finish within the configured stop timeout. Exercise rollback using a known task definition revision and immutable image, not by editing the failed revision in place.

Capacity and networking audit

Capacity-provider base and weight values distribute tasks after the base requirement is satisfied; they are not percentage guarantees for a tiny service. For EC2 providers, managed scaling still depends on correct Auto Scaling group configuration and instances successfully joining the cluster. For Fargate, subnet address exhaustion and unavailable task-size combinations can block placement even when the service control plane is healthy.

With awsvpc, include task ENIs in address planning and security review. Check routes to ECR, CloudWatch Logs, Secrets Manager, and application dependencies from private subnets. NAT gateways are one option, but VPC endpoints can avoid a public egress dependency for supported services. Security groups should describe application flows, and service discovery or load balancing should not be treated as an authorization boundary.

Incident questions that shorten diagnosis

Start with the stopped-task reason and service events, then correlate deployment ID, task definition revision, container exit code, health-check results, agent or Fargate platform version, and relevant CloudWatch logs. Determine whether the failure is placement, image pull, startup, health, runtime, or draining; each has a different owner and remediation. Preserve the failing definition and digest so the event remains reproducible after the service rolls back.

Operationally, alarm on repeated task starts, deployment duration, insufficient healthy tasks, load-balancer target health, CPU and memory saturation, and dependency-specific service-level indicators. Container Insights can add infrastructure visibility, but application telemetry must still explain whether requests are correct and timely.

Also rehearse loss of an Availability Zone and a capacity provider. Placement strategies and service spread preferences influence distribution, but they do not guarantee that every dependency, subnet, target group, or data store survives the same failure. Verify the running task count and request success during the exercise, then retain the task and deployment events as evidence.

Related:

Sources: