Container Deployments with ECS and Fargate. It solves the problem of packaging and running an application reliably across different environments without worrying about the underlying server hardware. For a DVA-C02 candidate, this is critical because the exam tests how to define, deploy, and manage containers using AWS's native orchestration service without having to manually manage servers.
Jump to a section
A catering manager is hired to organise a large outdoor festival dinner. The manager does not own a kitchen, a food truck, or even a single pot. Instead, they hire a fully equipped professional kitchen from a local restaurant that is closed for the day. That hired kitchen comes with ovens, fridges, chefs' knives, and a cleaning crew already included. The manager simply brings the pre-prepared ingredients, tells the hired kitchen's head chef the recipe, and the dinner is cooked and served on time. The manager never once worries about fixing a broken oven or scrubbing a floor. They pay only for the hours the kitchen is used.
Now imagine a second scenario. The same manager decides to buy their own food truck. They purchase the truck, install the stove, hire a mechanic to keep it running, and store it in a rented lot each night. They pay for the truck whether it is cooking or parked. The manager has full control over every detail of the truck, but they also carry all the responsibility and cost of maintaining it.
This is exactly the difference between using Fargate (hiring the professional kitchen) and using EC2 instances (buying the food truck) inside Amazon ECS. The catering manager is the developer who deploys containerised applications. ECS is the catering company that provides the scheduling and coordination. Fargate is the hired kitchen: AWS manages the servers, so the developer only provides the container image and the recipe (task definition). The developer never logs into a server or applies a security patch. The food truck is the EC2 launch type: the developer provisions, patches, and scales the underlying servers themselves.
Let us start with what a container actually is. A container is a lightweight, standalone package of software that includes everything needed to run a piece of code: the application itself, its libraries, configuration files, and dependencies. Unlike a virtual machine (VM), which includes a full operating system (OS) kernel, a container shares the host machine's OS kernel. This makes containers faster to start and much smaller in size than VMs. Think of a shipping container: it holds goods securely and can be moved from a ship to a train to a truck without anything spilling. Software containers do the same for code, allowing developers to build an application once and run it anywhere — on a laptop, in a data centre, or in the cloud.
Now, if a developer has one container, running it is simple. But in a real business, there might be dozens or hundreds of containers providing different parts of a website or a mobile app backend. Manually starting, stopping, and networking these containers is error-prone and does not scale. This is where an orchestrator comes in. An orchestrator is a tool that automates the deployment, scaling, and management of containers. AWS offers two main container orchestrators: Amazon Elastic Container Service (ECS) and Amazon Elastic Kubernetes Service (EKS). For the DVA-C02 exam, ECS is the primary focus.
Amazon ECS is a fully managed container orchestration service. It means you tell ECS which container images to run, how many copies of each container to run, and how much CPU and memory each container needs. ECS handles placing those containers onto a cluster of servers, restarting them if they crash, and distributing network traffic to them. ECS itself does not run the containers; it needs compute resources. Those resources can be provided in two ways: an EC2 launch type or a Fargate launch type.
Amazon EC2 (Elastic Compute Cloud) is a service that gives you virtual servers in the cloud. With the EC2 launch type in ECS, you first create and manage a fleet of EC2 instances that serve as the worker machines for your containers. You are responsible for patching the operating system, managing instance sizes, and handling the scaling of the server fleet. This gives you fine-grained control but requires significant operational overhead. It is like building and maintaining your own fleet of food trucks.
AWS Fargate is a serverless compute engine for containers. With Fargate, you do not manage any servers at all. You simply define your container requirements (CPU, memory, networking) in a task definition, and AWS runs the container on optimally sized servers that they manage entirely. You cannot log into those servers, you do not patch them, and you do not decide which specific server your container lands on. Fargate automatically scales the underlying infrastructure up and down based on your needs. You only pay for the vCPU and memory resources your containers consume while they are running. This is the hired professional kitchen from the analogy.
Both launch types use the same core ECS concepts. The first concept is a cluster. A cluster is a logical grouping of resources. In the EC2 launch type, a cluster is a group of EC2 instances. In the Fargate launch type, a cluster is a logical namespace where your tasks run. There are no visible servers in a Fargate cluster.
The second concept is a task definition. This is a blueprint — a JSON file that defines your containerised application. It specifies the container image to use (for example, 'my-app:v1' stored in Amazon ECR or Docker Hub), the amount of CPU and memory, the port mappings (e.g., container port 80 to host port 80), environment variables, logging configuration, and IAM roles. A task definition is like the recipe the catering manager gives to the kitchen.
The third concept is a task. A task is a running instance of a task definition. If you launch one copy of your application, that is one task. If you need three copies to handle more traffic, ECS creates three tasks. Each task is a running container with the settings from the task definition.
The fourth concept is a service. A service is an ECS resource that manages running a specified number of tasks simultaneously. It ensures that if a task crashes, a new one is launched to replace it. It can also be linked to an Application Load Balancer (ALB) to distribute incoming traffic across all healthy tasks. With a service, you can configure auto scaling to automatically increase or decrease the number of tasks based on CPU usage or other metrics. A service is like the catering company's coordinator who makes sure enough cooks are working at all times.
The fifth concept is the container agent. On EC2 launch type, each EC2 instance runs a small piece of software called the ECS container agent. This agent communicates with the ECS control plane and tells the instance which tasks to run. For Fargate, AWS manages this agent entirely on your behalf.
Why does all of this matter for DVA-C02? The exam tests your ability to create a task definition with the correct parameters, choose the right launch type based on a scenario, configure a service with load balancing and auto scaling, and understand how IAM roles govern what tasks can do. You will be asked to identify when to use Fargate (for simplicity and reduced operational overhead) versus EC2 (for strict compliance, custom networking, or cost optimisation at large scale).
A concrete example: imagine a start-up building a photo-sharing social media app. The app has three components: a front-end web server, a back-end API, and a background worker that resizes images. Using ECS with Fargate, the developer creates three separate task definitions, one for each component. They then create three ECS services, each running multiple copies of its respective task for resilience. An ALB sits in front of the web service. The background worker service pulls image-processing jobs from an Amazon SQS queue. The developer never provisions an EC2 instance. They update their application by simply pushing a new container image to ECR and updating the task definition. ECS with Fargate rolls out the update with zero downtime.
Push a Container Image to Amazon ECR
You build a Docker image of your application locally and then push it to a repository in Amazon ECR. This makes the image available for ECS to pull. ECR is a fully managed container registry that integrates with ECS and IAM for fine-grained access control. Without this step, ECS has no image to deploy.
Create a Task Definition
You create a task definition in JSON or via the AWS console. You specify the ECR image URI, the required CPU and memory (using valid Fargate combinations), the container port, environment variables (preferably from Secrets Manager), and the task IAM role. This task definition is the recipe ECS uses to launch containers.
Create an ECS Cluster
You create an ECS cluster, which is a logical grouping of resources. For Fargate, the cluster is empty of visible servers; it simply provides a namespace for your tasks and services. The cluster must be in the same VPC as your load balancer and databases.
Create an ECS Service with a Load Balancer
You create a service inside the cluster, referencing the task definition. You specify how many copies of the task you want running (desired count). You attach an Application Load Balancer target group so that traffic is evenly distributed across healthy tasks. The service monitors task health using the ALB health checks and replaces unhealthy tasks automatically.
Configure Auto Scaling
You set up an auto scaling policy for the service using Application Auto Scaling. You define a target tracking policy, such as maintaining average CPU utilisation at 70%. ECS automatically adds or removes tasks to meet the target, ensuring the application handles traffic spikes without manual intervention.
Deploy an Update
When the development team releases a new container image, you push it to ECR and update the task definition with the new image tag. You then trigger a new deployment in the ECS service. With a rolling update strategy, ECS starts new tasks with the new image, waits for them to pass health checks, and then terminates the old tasks. This provides zero-downtime updates.
Imagine you work as a platform engineer for a mid-sized online retail company. The company is migrating its entire e-commerce platform from a monolithic application running on a few large servers to a microservices architecture using containers. Your job is to deploy these containers using ECS with Fargate. Here is exactly what you do.
First, you meet with the development team to understand the application breakdown. They have identified six microservices: product catalogue, shopping cart, user authentication, order processing, payment gateway, and a recommendation engine. Each team owns its own code repository and produces a Docker image. The images are pushed to Amazon ECR (Elastic Container Registry), which is AWS's private container image repository. You do not need to manage a separate registry; ECR is fully managed.
Next, you write the task definitions. For the product catalogue service, you specify the following in the task definition JSON:
The image URI from ECR.
0.5 vCPU and 1024 MB of memory (this is a light service).
Port mapping: container port 8080 mapped to no host port (Fargate uses the task ENI IP).
Environment variables like DATABASE_URL pointing to an RDS endpoint (stored in AWS Secrets Manager, not plain text).
A task IAM role that grants permissions to read from the product catalogue DynamoDB table.
A task execution role that allows ECS to pull the image from ECR and write logs to CloudWatch Logs.
You create a Fargate cluster named 'production-cluster'. You then create an ECS service for each microservice. For example, the 'product-catalogue-service' is configured to run 3 tasks (copies) at all times. You attach an Application Load Balancer target group to this service so that incoming HTTP traffic is distributed across the 3 tasks. The ALB health check pings the /health endpoint on each task every 30 seconds. If a task fails three health checks in a row, ECS replaces it with a new one.
Traffic spikes during Black Friday are a major concern. To handle this, you configure auto scaling for the product catalogue service. You set a target tracking scaling policy that keeps average CPU utilisation at 60%. When traffic rises and CPU exceeds 60%, ECS automatically adds tasks up to a maximum of 20. When traffic drops, it scales down to a minimum of 2.
For the payment gateway service, security is paramount. You lock down its security group to only accept traffic from the order processing service's security group. You also configure the task definition to use a Fargate platform version 1.4.0 or later, which supports the awsvpc network mode with enhanced security features.
Now, a critical part of your real job is observability. You configure each service to send logs to Amazon CloudWatch Logs with a specific log group per microservice. You set up CloudWatch alarms: if order processing tasks consistently return 5xx errors, an alarm triggers a notification to the on-call engineer via Amazon SNS.
Deployments happen weekly. Your company uses blue/green deployment, which is supported natively by ECS through CodeDeploy. You define an AppSpec file that tells CodeDeploy which task definition to use and which traffic routing strategy to apply. A new version of the product catalogue is deployed: ECS starts new tasks with the new image, the ALB directs a small percentage of traffic to them, and if everything looks good after ten minutes, 100% of traffic is shifted to the new tasks. The old tasks are terminated.
Finally, you implement cost governance. You use AWS Compute Optimizer to review right-sizing recommendations for your Fargate task sizes. You find that the recommendation engine tasks are over-provisioned at 2 vCPU and 4096 MB when they consistently use only 0.5 vCPU. You update the task definition to the recommended size, reducing the monthly bill significantly.
The DVA-C02 exam tests 'Container Deployments with ECS and Fargate' in Domain 2, which covers deployment, monitoring, and optimisation. Expect 5-10 questions on this topic across the exam. These are not trick questions, but they are precise. The exam loves small details in the wording of task definition parameters and the differences between the two launch types.
Here are the exact concepts they test, grouped by category:
- Task Definitions - You MUST know the difference between 'task role' and 'task execution role'. The task role is the IAM role the containerised application assumes to call AWS services (e.g., read from S3). The task execution role is the role that ECS itself assumes to pull the container image and send logs. This is a classic trap: they will offer a scenario and ask which role to modify. - Network mode: Fargate tasks always use the 'awsvpc' network mode, which gives each task its own elastic network interface (ENI) and a private IP address. EC2 tasks can use 'bridge', 'host', or 'awsvpc'. The exam will ask when you cannot use certain modes. - CPU and memory combinations for Fargate are fixed. For example, 0.25 vCPU requires 512 MB, 1 GB, or 2 GB of memory. The exam will give you a task definition with an invalid combination and expect you to spot it. - Read-only root filesystem: a task definition can set 'readonlyRootFilesystem' to true for security. The exam tests when you need a scratch volume (ephemeral storage) for temporary writes. - Launch Types: Fargate vs EC2 - Fargate is the correct answer when a scenario mentions 'serverless', 'no server management', 'reduced operational overhead', or 'pay-per-use'. EC2 is correct when the scenario demands 'custom networking', 'GPU support', 'Windows containers', or 'strict compliance requiring dedicated instances'. - A common trap asks you to recommend a launch type for a batch job that runs for five minutes once a day. Fargate is better here because you pay only for the runtime. EC2 would be wasted cost because the instance must run continuously. - Services and Auto Scaling - Know the difference between 'desired count', 'minimum healthy percent', and 'maximum percent' in a service's deployment configuration. The exam will ask what parameters ensure zero downtime during a rolling update. - Service auto scaling uses the Application Auto Scaling service, not ECS directly. Target tracking scaling policies, step scaling, and scheduled scaling are all fair game. You need to know which metric to track — typically CPUUtilization, MemoryUtilization, or ALBRequestCountPerTarget. - Security - IAM roles for tasks: the task role inherits permissions. The exam will ask what happens if a container tries to access an S3 bucket without the correct task role policy. - Secrets: environment variables should come from AWS Secrets Manager or Systems Manager Parameter Store, not hardcoded in the task definition. The exam tests how to reference a secret ARN in the task definition. - Networking - Security groups are applied at the task level (ENI). The exam tests how to allow traffic between two services in different ECS services but within the same VPC. - Logging - The awslogs log driver must be configured in the task definition to send logs to CloudWatch. The exam tests why logs are missing: often because the task execution role lacks the 'logs:CreateLogStream' and 'logs:PutLogEvents' permissions.
Trap patterns include:
Choosing EC2 launch type when the question emphasises 'no server management' (Fargate is correct).
Confusing task role with execution role.
Selecting an invalid CPU/memory pair for Fargate.
Forgetting that ECS with EC2 requires you to manage the ECS container agent and the scaling of the underlying instances.
To prepare, memorise the Fargate CPU/memory tables, the difference between task and execution roles, and the two primary use cases for each launch type. Practise writing task definition JSON snippets by hand until the structure becomes automatic.
ECS is a container orchestration service; Fargate is a serverless compute engine that runs the containers for ECS without you managing servers.
A task definition is a JSON blueprint that specifies the container image, CPU, memory, IAM roles, and port mappings for your application.
Use the Fargate launch type when you want to avoid managing servers; use the EC2 launch type when you need control over the underlying instance or require GPUs or Windows containers.
The task IAM role grants permissions to the application inside the container; the task execution role grants ECS permission to pull images and send logs.
An ECS service maintains a desired number of task copies and can integrate with an Application Load Balancer for traffic distribution and health checks.
Fargate tasks support only the awsvpc network mode, which gives each task its own elastic network interface and private IP address within a VPC.
For zero-downtime deployments, configure the ECS service with a rolling update strategy and set minimum healthy percent accordingly.
CPU and memory pairs in Fargate are fixed; for example, 0.25 vCPU only allows three specific memory values: 512 MB, 1 GB, or 2 GB.
These come up on the exam all the time. Here's how to tell them apart.
Fargate Launch Type
No server management; AWS handles underlying hosts
Pay per second for vCPU and memory used by tasks
Only supports Linux containers with awsvpc network mode
EC2 Launch Type
You manage EC2 instances, including patching and scaling
Pay for EC2 instances whether they run tasks or not
Supports Linux and Windows containers; multiple network modes
Task Role
Used by the application inside the container to call AWS APIs
Defined in the taskDefinition's 'taskRoleArn' field
Example: container reads from DynamoDB uses this role
Task Execution Role
Used by the ECS agent to pull the container image and send logs
Defined in the taskDefinition's 'executionRoleArn' field
Example: ECS pulls image from ECR uses this role
ECS Service
Ensures a desired number of tasks run continuously
Supports auto scaling and rolling updates
Works with load balancers for traffic distribution
ECS Task (standalone)
Runs once and stops; no automatic restart
No auto scaling or deployment strategies
No load balancer integration; manual traffic management
Task Definition (full JSON)
All parameters are configurable, including log drivers and secrets
Can be version-controlled in a code repository
Used for infrastructure-as-code deployments (e.g., CloudFormation)
Task Definition (via AWS Console)
Limited to fields presented in the console UI
Harder to version and automate
Suitable for testing and one-off configurations
Mistake
Fargate is a separate container orchestration tool that replaces ECS.
Correct
Fargate is not a separate orchestrator. It is a compute engine that runs inside ECS. You still use ECS to define tasks, services, and clusters. Fargate replaces the EC2 instances that provide the compute capacity for those tasks.
The term 'Fargate' sounds like a product name on its own, and beginners often assume it competes with ECS rather than being a part of it.
Mistake
A task definition is the same as a running container.
Correct
A task definition is a blueprint or template. A task is a running instance of that blueprint. You can have multiple tasks running from the same task definition. Changing the task definition does not affect running tasks until you trigger a new deployment.
People conflate configuration with execution. It is like thinking a cake recipe (task definition) is the same as the baked cake (task).
Mistake
ECS with Fargate automatically scales the number of tasks based on traffic without any configuration.
Correct
Fargate does not auto scale tasks by itself. You must explicitly create an ECS service with an auto scaling policy (using Application Auto Scaling). The policy can target CPU, memory, or request count. Without this, the service runs a fixed number of tasks.
The word 'serverless' leads people to believe all scaling is automatic and requires no thought. In reality, auto scaling must be deliberately configured.
Mistake
You can SSH into a Fargate container to debug issues.
Correct
You cannot SSH into a Fargate container. AWS manages the underlying host, and you have no shell access. For debugging, you rely on CloudWatch Logs, AWS X-Ray for tracing, and the ECS Exec feature (which allows secure shell access through a session manager but not SSH).
With virtual machines and EC2, developers are used to SSHing in. Fargate removes that capability entirely, which is a major mindset shift.
Mistake
The ECS container agent runs inside a Fargate container.
Correct
The Fargate launch type does not run the ECS container agent inside the container. AWS manages the agent on the underlying infrastructure that you cannot see. The container itself only contains your application and its dependencies.
People familiar with the EC2 launch type know the agent runs on the EC2 instance. They mistakenly think a similar agent runs inside the container in Fargate.
Reveal each answer, then mark whether you got it right. Score 60%+ to unlock the next chapter.
ECS is the container orchestration service that manages scheduling, running, and scaling containers. Fargate is a launch type within ECS that runs containers on infrastructure managed by AWS, so you do not have to manage servers. The two work together: ECS orchestrates, Fargate provides the compute.
No. Fargate is not a standalone product. It is a compute engine that is always used with a container orchestrator like ECS or EKS (Amazon Elastic Kubernetes Service). For DVA-C02, focus on ECS with Fargate.
You push a new image to ECR, update the task definition to point to that new image, and then update the ECS service. ECS performs a rolling update, gradually replacing old tasks with new ones, assuming you configure the service to allow such updates.
Common causes include insufficient permissions in the task execution role, an invalid CPU/memory combination, a missing VPC or subnet configuration, or a public IP not assigned when needed. Check the service events in the ECS console for specific error messages.
Not always, but it is common. A load balancer is needed for services that receive HTTP traffic from users or external systems. For internal batch processing or worker services, you might use an Amazon SQS queue instead. The load balancer also provides health checks, which are essential for the service to manage task health.
No. Fargate is a cloud-native AWS service that runs only in AWS data centres. For on-premises container orchestration, you would use ECS Anywhere or Amazon EKS on your own servers, but neither uses Fargate.
You've just covered Container Deployments with ECS and Fargate — now see how well it sticks with free DVA-C02 practice questions. Full explanations included, no account needed.
Done with this chapter?