This chapter covers Amazon ECS (Elastic Container Service) and AWS Fargate, the core container orchestration services for the DVA-C02 exam. Understanding ECS task definitions, services, clusters, and the differences between EC2 and Fargate launch types is critical, as container-based questions appear in roughly 10-15% of the exam. You will learn how to define, deploy, and manage containers at scale, integrate with other AWS services, and troubleshoot common issues — all from a developer's perspective.
Jump to a section
Think of Amazon ECS and Fargate like a modern shipping port. The port itself is your ECS cluster — the infrastructure that manages containers. Ships (EC2 instances) arrive at the port; each ship has a crane (ECS agent) that can load/unload containers. But with Fargate, it's like the port provides floating cranes that operate directly on the water, without needing ships. You just specify the container size (CPU and memory) and the crane handles the rest. The port authority (ECS control plane) decides which crane handles which container, based on resource availability. Each container runs in its own isolated environment (a Fargate task) with its own network interface and security group, just like each shipping container has its own lock and seal. You never manage the ships; you just tell the port: 'Run this container image with 2 vCPUs and 4 GB RAM.' The port allocates a crane, loads the container, and monitors it. If the container fails, the port can automatically restart it (service auto-recovery). This is serverless container management — you focus on the cargo, not the fleet.
What is Amazon ECS?
Amazon ECS is a fully managed container orchestration service that allows you to run, stop, and manage Docker containers on a cluster. You define your application as a task definition, which is a JSON template describing up to 10 containers, their images, resource requirements, networking, and volumes. ECS then schedules those tasks onto a cluster of EC2 instances (EC2 launch type) or runs them on serverless infrastructure (Fargate launch type).
Why ECS and Not Just Docker?
Running Docker directly on EC2 requires you to manage the container runtime, networking, load balancing, scaling, and failure recovery. ECS abstracts these concerns. It integrates with Elastic Load Balancing (ALB/NLB), Auto Scaling, CloudWatch, IAM, and VPC networking. For the DVA-C02, you must know that ECS is the native AWS container orchestrator — not Kubernetes (EKS). The exam focuses on ECS concepts, not EKS.
Launch Types: EC2 vs. Fargate
EC2 Launch Type: You provision and manage EC2 instances that form the cluster. You pay for the EC2 instances even if they are idle. You have full control over the instance configuration, including GPU support, placement groups, and custom AMIs. The ECS agent runs on each instance and registers it with the cluster.
Fargate Launch Type: You do not manage any servers. You define CPU and memory per task (e.g., 0.25 vCPU, 512 MB RAM) and AWS runs the container on shared, isolated infrastructure. You pay only for the resources consumed by running tasks. Fargate is serverless and the recommended default for most workloads.
Task Definitions
A task definition is a blueprint for your application. It specifies:
- Family: Name for the task definition (e.g., "my-app").
- Container definitions: Image (from ECR or Docker Hub), port mappings, environment variables, secrets (from Secrets Manager or SSM), log configuration (CloudWatch Logs), health check command.
- Task role: IAM role that the task's containers assume to call AWS APIs (e.g., S3, DynamoDB).
- Execution role: IAM role that ECS uses to pull images and send logs.
- Network mode: For Fargate, only awsvpc is supported — each task gets its own elastic network interface (ENI) with a private IP.
- CPU and memory: For Fargate, you specify task-level CPU (0.25 to 16 vCPUs) and memory (512 MB to 120 GB). For EC2, you specify container-level limits.
- Volumes: Bind mounts, EFS filesystems, or Docker volumes.
Clusters
A cluster is a logical grouping of tasks or services. For EC2 launch type, the cluster contains EC2 instances. For Fargate, the cluster is just a namespace — no infrastructure to manage. Clusters are region-specific. You can have multiple clusters for different environments (dev, test, prod).
Services
An ECS service allows you to run and maintain a specified number of task instances simultaneously. If a task fails or stops, the service scheduler launches another instance to replace it. Key service configurations:
- Desired count: Number of concurrent tasks.
- Deployment type: Rolling update (default) or blue/green (using CodeDeploy).
- Load balancer: Attach an ALB or NLB to distribute traffic across tasks. For Fargate, you must use the awsvpc network mode, which allows each task to be registered directly with the target group.
- Auto Scaling: Use ECS Service Auto Scaling to adjust desired count based on CloudWatch metrics (CPU, memory, ALB request count).
- Task placement strategies: For EC2 launch type, you can use binpack, spread, or distinctInstance to control where tasks are placed.
How ECS Works Internally
Task Definition Registration: You register a task definition via AWS CLI, SDK, or CloudFormation. ECS stores it in its backend.
Service Creation: You create a service that references the task definition. The service scheduler calculates how many tasks to run.
Task Launch: For EC2, the ECS scheduler picks an instance with sufficient resources and communicates with the ECS agent on that instance to pull the image and start the container. For Fargate, the ECS control plane allocates infrastructure (a lightweight VM) and launches the container. The Fargate agent runs on the allocated infrastructure.
Networking: With awsvpc mode, each task gets an ENI attached to a VPC subnet. The ENI gets a primary private IP from the subnet. Security groups apply to the ENI. For EC2 launch type, you can also use bridge or host networking.
Health Checks: ECS monitors the health of tasks using the ALB health checks (if attached) or the container's health check command. Unhealthy tasks are replaced.
Logging: Containers send logs to CloudWatch Logs if configured. The log driver is specified in the container definition.
Key Values and Defaults
Task definition revision: Each time you register a new task definition, it gets a revision number (e.g., my-app:3). Services can be updated to use a new revision.
Fargate CPU/memory combinations: You must use valid combinations. For example, 0.25 vCPU requires 0.5 GB, 1 GB, or 2 GB memory. See the official table.
Service desired count: Default 1.
Deployment minimum healthy percent: Default 100% (during rolling update, 100% of desired count must be healthy).
Deployment maximum percent: Default 200% (can temporarily run up to double the desired count).
Task stop timeout: Default 30 seconds (ECS sends SIGTERM, then SIGKILL after timeout).
Service discovery: Uses AWS Cloud Map for service-to-service communication.
Integration with Other Services
ECR: Amazon Elastic Container Registry stores Docker images. ECS pulls images from ECR using the execution role.
CloudWatch Logs: Container logs are streamed to log groups. You can create metric filters to alert on errors.
IAM: Task roles allow containers to access AWS resources. Execution roles allow ECS to pull images and send logs.
ELB: Application Load Balancer (ALB) supports path-based routing and is recommended for HTTP/HTTPS. Network Load Balancer (NLB) for high performance or TCP.
Auto Scaling: ECS Service Auto Scaling uses target tracking, step scaling, or scheduled scaling.
CloudFormation: You can define ECS resources in CloudFormation templates.
EventBridge: ECS emits events (task state changes, service actions) that can trigger Lambda functions.
CLI and SDK Commands
aws ecs register-task-definition --family my-app --container-definitions file://taskdef.json
aws ecs create-service --cluster default --service-name my-service --task-definition my-app:1 --desired-count 2 --launch-type FARGATE --network-configuration "awsvpcConfiguration={subnets=subnet-xxx,securityGroups=sg-xxx}"
aws ecs list-tasks --cluster default
aws ecs describe-tasks --cluster default --tasks arn:aws:ecs:...
aws ecs update-service --cluster default --service my-service --task-definition my-app:2
aws ecs run-task --cluster default --task-definition my-app:1 --launch-type FARGATE (for one-off tasks)
Task Lifecycle
PENDING: Task is accepted, waiting for resources.
ACTIVATING: Task is being launched (pulling image, starting container).
RUNNING: Task is healthy and running.
DEACTIVATING: Task is being stopped (SIGTERM sent).
STOPPED: Task has exited. Stopped tasks have a stoppedReason (e.g., "Essential container in task exited").
Common Troubleshooting
Task fails to start: Check execution role permissions (ECR pull, CloudWatch logs). Check awsvpc configuration: subnet must have route to internet or VPC endpoints for ECR and CloudWatch.
Task stuck in PENDING: Insufficient resources (for EC2) or Fargate capacity limits. Check service quotas.
Service not scaling: Verify CloudWatch metrics exist, scaling policy is correct, and cooldown periods.
Container exits immediately: Check container entrypoint and logs. The essential container must keep running.
Fargate Spot
Fargate Spot allows you to run tasks on spare capacity at up to 70% discount. Tasks can be interrupted (2-minute warning). Use for fault-tolerant, stateless workloads. Specify capacityProviderStrategy with FARGATE_SPOT.
Data Volumes
Bind mounts: Mount a host directory into the container (EC2 only).
EFS: Use Amazon EFS file system for persistent storage. Fargate supports EFS via the efsVolumeConfiguration in the task definition. The EFS file system must be in the same VPC.
Docker volumes: Use Docker-managed volumes (EC2 only).
Secrets and Environment Variables
Environment variables: Can be specified in the task definition as plain text or referenced from SSM Parameter Store or Secrets Manager using valueFrom.
Secrets: Use secrets array in container definition to reference sensitive data. The execution role must have ssm:GetParameters or secretsmanager:GetSecretValue.
Logging and Monitoring
CloudWatch Logs: Configure awslogs log driver with awslogs-group and awslogs-region.
CloudWatch Container Insights: Collects metrics (CPU, memory, network) and logs for ECS tasks.
AWS X-Ray: Can be enabled for tracing via the X-Ray daemon sidecar container.
Security Best Practices
Use least privilege for task roles.
Store secrets in Secrets Manager, not environment variables.
Use private ECR repositories with IAM authentication.
Enable encryption at rest for EFS volumes.
Use security groups to restrict traffic between tasks.
Pricing
EC2 launch type: Pay for EC2 instances (running or stopped), EBS volumes, data transfer.
Fargate launch type: Pay per second for CPU and memory used by running tasks, plus any associated EFS or data transfer.
Limits
Task definitions: 1 MB max per definition.
Containers per task: Up to 10.
Fargate tasks per region: Soft limit of 100 (can be increased).
Services per cluster: 500.
Tasks per service: 1,000.
Summary of Exam-Relevant Points
ECS is container orchestration; Fargate is serverless compute for containers.
Task definitions are JSON blueprints.
Services maintain desired count and integrate with ALB.
awsvpc network mode gives each task its own ENI and security group.
Execution role is for ECS to pull images and logs; task role is for the application to call AWS APIs.
Fargate supports EFS but not bind mounts.
Fargate Spot for cost savings.
Rolling updates are default; blue/green with CodeDeploy.
Service Auto Scaling uses target tracking with CloudWatch metrics.
Task placement strategies only apply to EC2 launch type.
Use run-task for one-off or batch tasks; create-service for long-running services.
Define and Register Task Definition
You start by creating a task definition JSON file. This defines your application's containers: the image (from ECR or Docker Hub), port mappings (e.g., container port 80 mapped to host port 0 for dynamic port), environment variables, resource limits (CPU and memory), IAM roles (task role and execution role), and log configuration. For Fargate, you must specify `networkMode: awsvpc`. Register the task definition using the AWS CLI command `aws ecs register-task-definition --cli-input-json file://taskdef.json`. ECS stores it and returns a revision number (e.g., my-app:1). Each revision is immutable; you can create new revisions for updates.
Create an ECS Cluster
Create a cluster to group your tasks/services. For Fargate, the cluster is just a logical container and requires no infrastructure. Use `aws ecs create-cluster --cluster-name my-cluster`. You can also create a cluster with EC2 instances using a CloudFormation template or the console. The cluster is region-specific. You can attach capacity providers (FARGATE, FARGATE_SPOT) to the cluster to define launch type strategies. For example, `capacityProviders=[FARGATE,FARGATE_SPOT]` and `defaultCapacityProviderStrategy=[{base=1,weight=1,capacityProvider=FARGATE},{base=0,weight=4,capacityProvider=FARGATE_SPOT}]`.
Create a Service or Run a Task
For long-running applications, create a service: `aws ecs create-service --cluster my-cluster --service-name my-service --task-definition my-app:1 --desired-count 2 --launch-type FARGATE --network-configuration "awsvpcConfiguration={subnets=subnet-xxx,securityGroups=sg-xxx}"`. The service ensures the desired number of tasks are always running. For one-off tasks (e.g., batch job), use `run-task`: `aws ecs run-task --cluster my-cluster --task-definition my-app:1 --launch-type FARGATE --network-configuration "..."`. The task runs and then stops. You can also attach a load balancer to the service for traffic distribution.
Monitor and Scale the Service
Once the service is running, ECS monitors task health. If a task fails, the service replaces it automatically. You can attach CloudWatch alarms and create Service Auto Scaling policies. For example, target tracking scaling on average CPU utilization: `aws application-autoscaling put-scaling-policy --service-namespace ecs --scalable-dimension ecs:service:DesiredCount --resource-id service/my-cluster/my-service --policy-name cpu-target --policy-type TargetTrackingScaling --target-tracking-scaling-policy-configuration TargetValue=70.0,PredefinedMetricSpecification={PredefinedMetricType=ECSServiceAverageCPUUtilization}`. The service scales up/down based on the metric.
Update the Service with a New Task Revision
To deploy a new version of your application, register a new task definition revision (my-app:2) and update the service: `aws ecs update-service --cluster my-cluster --service my-service --task-definition my-app:2`. ECS performs a rolling update: it starts new tasks with the new definition, waits for them to become healthy, then stops old tasks. The deployment configuration (minimum healthy percent, maximum percent) controls the speed and availability. You can also use blue/green deployment with CodeDeploy for canary testing.
Scenario 1: Microservices on Fargate
A fintech startup runs 15 microservices (Node.js, Python, Go) on ECS Fargate. Each service has its own task definition, ECR repository, and CI/CD pipeline (CodePipeline + CodeBuild). They use an Application Load Balancer with path-based routing to direct traffic to the correct service. For example, /api/users routes to the user service. They use service discovery (Cloud Map) for inter-service communication. The task role for each service is scoped to only the DynamoDB tables it needs. They use Fargate Spot for non-critical services (e.g., reporting) to reduce costs by 60%. Auto Scaling is configured based on request count per target. The challenge is managing secrets: they use Secrets Manager and the secrets array in the container definition. Common issue: tasks fail to start because the execution role lacks ecr:GetDownloadUrlForLayer permission. They monitor with Container Insights and set up CloudWatch dashboards.
Scenario 2: Batch Processing with ECS RunTask
A media company processes video files using FFmpeg containers on ECS Fargate. They use S3 as the source and destination. An S3 PutObject event triggers a Lambda function that calls run-task with the video file path as an environment variable. The task pulls the FFmpeg image, processes the video, and uploads the result to another S3 bucket. The task stops after processing. They use Fargate Spot for cost savings, but handle interruptions by storing the job state in DynamoDB and retrying interrupted tasks (the 2-minute warning triggers a Lambda via EventBridge). The task role has S3 read/write permissions. The execution role pulls the image from ECR. They set the task CPU and memory based on video resolution: 1080p uses 1 vCPU and 2 GB RAM; 4K uses 4 vCPU and 8 GB RAM. The main issue is that tasks can stay in PENDING if Fargate capacity is exhausted; they set a CloudWatch alarm and use a fallback to on-demand Fargate.
Scenario 3: Legacy Lift-and-Shift with EC2 Launch Type
An enterprise moves a legacy Java application to ECS. The application requires persistent scratch space on the host (bind mount) and a specific AMI with custom kernel modules. They use EC2 launch type with a custom AMI that has the ECS agent pre-installed. They create an Auto Scaling group for the EC2 instances and use binpack placement strategy to maximize instance utilization. The service uses an NLB for TCP traffic. They have a stateful session requirement, so they use sticky sessions (target group stickiness). The challenge is managing instance patching: they use a rolling update strategy that launches new instances with the latest AMI, then drains old ones. The main pitfall is that the ECS agent must be updated on the instances; they use a startup script to install the latest agent version. They monitor instance health with EC2 status checks and ECS agent connectivity.
What DVA-C02 Tests on ECS and Fargate
The exam objectives for Domain 1 (Development) include: "Design and develop container-based applications using Amazon ECS." Specific tested concepts:
Task definitions (required fields, network modes, IAM roles)
Launch types (EC2 vs Fargate) and when to use each
Service vs RunTask
Load balancer integration (ALB vs NLB)
Auto Scaling (Service Auto Scaling, not EC2 Auto Scaling)
Environment variables and secrets (using valueFrom and secrets)
Data volumes (EFS for Fargate, bind mounts for EC2)
Troubleshooting (task stuck in PENDING, execution role issues)
Common Wrong Answers and Why
"Use ECS with EC2 launch type for all workloads because it's cheaper." Wrong — Fargate can be cheaper for spiky workloads because you pay only per task, not for idle instances. EC2 is cheaper for steady-state, high-utilization workloads. The exam expects you to choose based on requirements: if you need GPU, custom AMI, or want to manage instances, choose EC2; otherwise, Fargate.
"Attach a security group to the task definition." Wrong — security groups are attached to the ENI, not the task definition. You specify security groups in the awsvpcConfiguration when creating the service or run-task.
"Use a task role to allow ECS to pull images from ECR." Wrong — that's the execution role. The task role is for the application to call AWS services.
"For persistent storage in Fargate, use bind mounts." Wrong — Fargate does not support bind mounts. Use EFS for persistent storage.
Specific Numbers and Terms
Fargate valid CPU/memory combinations: 0.25 vCPU -> 0.5, 1, 2 GB; 0.5 vCPU -> 1, 2, 3, 4 GB; 1 vCPU -> 2, 3, 4, 5, 6, 7, 8 GB; etc. (memorize the pattern: memory in GB must be between 0.5 and 8 per 0.5 vCPU).
Task definition max: 1 MB.
Containers per task: max 10.
Service minimum healthy percent: default 100%.
Service maximum percent: default 200%.
Task stop timeout: 30 seconds (SIGTERM then SIGKILL).
Fargate Spot interruption: 2-minute warning.
Network mode for Fargate: only awsvpc.
EFS can be mounted in Fargate tasks using efsVolumeConfiguration.
Edge Cases and Exceptions
If a task definition is updated, the service must be explicitly updated to use the new revision. The service does not automatically pick up new revisions.
For Fargate, you cannot specify hostPort — it must be 0 (dynamic) or match containerPort. The ENI gets the container port directly.
When using EFS, the task and EFS must be in the same VPC. Security groups must allow NFS traffic (port 2049).
If you use FARGATE_SPOT capacity provider, tasks can be interrupted; you must handle that in your application.
The execution role needs ecr:GetDownloadUrlForLayer, ecr:BatchGetImage, ecr:BatchCheckLayerAvailability, and logs:CreateLogStream, logs:PutLogEvents.
How to Eliminate Wrong Answers
If the question mentions "no servers to manage" or "serverless" → Fargate.
If the question mentions "custom AMI" or "GPU" → EC2 launch type.
If the question mentions "persistent storage" → EFS (not bind mounts for Fargate).
If the question mentions "secrets" → use secrets array with valueFrom pointing to Secrets Manager or SSM.
If the question mentions "one-time batch job" → run-task (not service).
If the question mentions "load balancing" → use ALB (or NLB for TCP).
If the question mentions "blue/green deployment" → use CodeDeploy.
ECS is a container orchestration service; Fargate is a serverless compute engine for containers.
Task definitions are JSON blueprints that define up to 10 containers, resources, IAM roles, and networking.
Fargate only supports `awsvpc` network mode; each task gets its own ENI and security group.
The execution role is for ECS to pull images and send logs; the task role is for the application to call AWS APIs.
Use `create-service` for long-running tasks; use `run-task` for one-off or batch jobs.
Service Auto Scaling uses CloudWatch metrics (CPU, memory, ALB request count) with target tracking.
Fargate Spot can reduce costs up to 70% but tasks can be interrupted with a 2-minute warning.
For persistent storage in Fargate, use Amazon EFS (not bind mounts).
Blue/green deployments require CodeDeploy; rolling updates are default.
Task placement strategies (binpack, spread) only apply to EC2 launch type.
Secrets should be stored in Secrets Manager or SSM and referenced via `valueFrom` or `secrets`.
Common task failure reasons: execution role missing permissions, insufficient VPC endpoints, or invalid CPU/memory combination.
These come up on the exam all the time. Here's how to tell them apart.
ECS EC2 Launch Type
You manage EC2 instances in the cluster.
Pay for EC2 instances (running or stopped).
Supports custom AMI, GPU, and placement groups.
Allows bind mounts and Docker volumes.
More control over infrastructure.
ECS Fargate Launch Type
No servers to manage; AWS runs containers on shared infrastructure.
Pay per second for CPU and memory used by tasks.
No access to underlying OS or custom AMI.
Only EFS for persistent storage (no bind mounts).
Simpler; ideal for most applications.
Mistake
ECS is the same as Docker Compose.
Correct
ECS is a fully managed orchestration service for running containers at scale across a cluster, with features like auto-scaling, load balancing, and service discovery. Docker Compose is a local tool for defining and running multi-container Docker applications on a single host. ECS can use Compose files via the ECS CLI, but they are fundamentally different in scope.
Mistake
Fargate tasks run on shared EC2 instances that you can access.
Correct
Fargate tasks run on isolated infrastructure managed by AWS. You cannot SSH into the underlying host or see it. Each task gets its own isolated runtime environment. You only manage the task definition and the application.
Mistake
You can use any network mode with Fargate.
Correct
Fargate only supports the `awsvpc` network mode. This gives each task its own ENI and security group. `bridge`, `host`, and `none` modes are not supported.
Mistake
The task role and execution role are the same.
Correct
They are different. The execution role is used by ECS to pull container images and send logs to CloudWatch. The task role is used by the application running inside the container to call AWS APIs (e.g., S3, DynamoDB). Each task definition can specify both.
Mistake
ECS services automatically update when you register a new task definition revision.
Correct
No, you must explicitly update the service to use the new revision using `update-service` or the console. The service continues using the old revision until you update it.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
An ECS service ensures a specified number of task instances are always running, automatically replacing failed tasks. It integrates with load balancers and auto scaling. Use services for long-running applications like web servers. `RunTask` launches a single task and stops it after completion. Use it for batch jobs, migrations, or one-off tasks. The exam often tests this distinction: if the question mentions 'run once' or 'batch', choose RunTask; if 'high availability' or 'load balancing', choose service.
Use the `secrets` array in the container definition to reference secrets from AWS Secrets Manager or SSM Parameter Store. For example: `"secrets": [{"name": "DB_PASSWORD", "valueFrom": "arn:aws:secretsmanager:us-east-1:123456789012:secret:my-db-password"}]`. The execution role must have `secretsmanager:GetSecretValue` permission. Do not use plaintext environment variables for sensitive data. The exam expects you to know this over alternative methods.
Yes, Fargate supports Amazon EFS for persistent storage. You define an `efsVolumeConfiguration` in the task definition, specifying the file system ID and root directory. The task must be in the same VPC as the EFS file system, and security groups must allow inbound NFS traffic (port 2049) from the task's security group. EFS is the only persistent storage option for Fargate; bind mounts and Docker volumes are not supported.
Two roles: (1) Execution role — assumed by ECS to pull container images from ECR and send logs to CloudWatch. It needs permissions like `ecr:GetDownloadUrlForLayer`, `ecr:BatchGetImage`, `logs:CreateLogStream`, `logs:PutLogEvents`. (2) Task role — assumed by the application inside the container to call AWS APIs (e.g., S3, DynamoDB). You specify both in the task definition. The exam tests that you know which role does what.
Use ECS Service Auto Scaling, which adjusts the desired count of tasks based on CloudWatch metrics. You can use target tracking scaling (e.g., keep average CPU at 70%), step scaling, or scheduled scaling. The scaling policy is created via Application Auto Scaling. Note that this is different from EC2 Auto Scaling for the cluster instances. For Fargate, you only need Service Auto Scaling; for EC2, you may also need to scale the EC2 instances themselves.
The default is rolling update. During a deployment, ECS starts new tasks with the updated task definition, waits for them to pass health checks, and then stops old tasks. You can control the speed with `minimumHealthyPercent` and `maximumPercent` (defaults 100% and 200%). For more advanced deployments (blue/green, canary), you can use AWS CodeDeploy with the ECS compute platform.
Common causes: (1) Insufficient resources — for EC2, no instance has enough CPU/memory; for Fargate, capacity limits reached. (2) Execution role missing permissions — ECS cannot pull the image. (3) Network configuration — subnet has no route to ECR (need NAT gateway or VPC endpoints). (4) Service limits exceeded. Check the task's `stoppedReason` or `lastStatus` in the console or CLI. For Fargate, also check if the CPU/memory combination is valid.
You've just covered Amazon ECS and Fargate for Developers — now see how well it sticks with free DVA-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?