Study guide
Technical reference and lesson notes
Purpose of This Lesson
Amazon Elastic Container Service (ECS) and Amazon Elastic Kubernetes Service (EKS) are managed platforms for running containerized applications. The main exam objective is choosing the appropriate orchestration service and launch model, then understanding how tasks, services, clusters, images, and scaling interact.
Key Concepts
Docker Images and Containers
A Docker image is a read-only template containing the instructions and application components required to create a container. Images are commonly built from a Dockerfile and stored in a container registry.
Amazon Elastic Container Registry (ECR) is AWS’s managed, private Docker registry. It provides a secure location for storing and retrieving images used by ECS tasks and other container platforms. Images can also be hosted in registries such as Docker Hub.
A container is a running instance created from an image. ECS currently uses Docker-compatible container images.
ECS Core Components
- Cluster: A logical grouping of ECS resources and workloads. Clusters can contain tasks launched on EC2 or Fargate.
- Container instance: An EC2 instance registered with an ECS cluster and running the ECS container agent.
- ECS container agent: Software that allows an EC2 instance to communicate with the ECS control plane. It is included in the Amazon ECS-optimized AMI and supports Linux and Windows environments.
- Task definition: A JSON blueprint describing one or more containers, including images, resource requirements, networking, and runtime configuration. A task definition can describe up to 10 containers.
- Task: A running instance of a task definition.
- Service: Maintains a specified number of long-running tasks and can integrate with load balancers and Application Auto Scaling.
A task definition describes how containers should run; a service maintains the desired number of task instances. These are different concepts and are frequently tested separately.
ECS Launch Types
ECS supports two primary launch types:
#### EC2 launch type
With the EC2 launch type, you provision and manage the EC2 instances that provide container capacity. This gives you more control over the underlying infrastructure, instance types, operating system configuration, and capacity planning.
You are also responsible for tasks such as:
- EC2 instance provisioning and patching
- AMI and agent lifecycle management
- Capacity planning and cluster optimization
- Scaling the underlying instance fleet
- Managing instance-level security and configuration
#### Fargate launch type
AWS Fargate is a serverless compute engine for containers. You specify the task requirements, and AWS provisions the required compute capacity. You do not manage the underlying EC2 instances or cluster capacity.
Fargate is generally the better choice when reducing operational overhead is more important than controlling the host infrastructure. It offers less infrastructure-level control than the EC2 launch type.
ECS Networking and Load Balancing
ECS services can integrate with Elastic Load Balancing to distribute traffic across running tasks. Exam scenarios may specify either:
- Application Load Balancer (ALB): Typically selected for HTTP/HTTPS applications, path-based routing, host-based routing, and Layer 7 features.
- Network Load Balancer (NLB): Typically selected for high-performance Layer 4 traffic, static IP requirements, or TCP/UDP workloads.
The load balancer provides a stable entry point while the ECS service replaces or scales individual tasks behind it.
ECS Anywhere
ECS Anywhere extends the ECS control plane to supported customer-managed infrastructure outside AWS. It is useful when an organization wants to manage container workloads in AWS and on premises using ECS concepts and tooling.
ECS Auto Scaling
ECS scaling has two distinct levels:
#### Service auto scaling
Service auto scaling changes the desired number of running tasks. It uses Application Auto Scaling and supports:
- Target tracking scaling
- Step scaling
- Scheduled scaling
Service scaling increases or decreases application capacity, but it does not itself provide additional EC2 host capacity for the EC2 launch type.
#### Cluster auto scaling
Cluster auto scaling changes the number of EC2 container instances available to an ECS cluster. It uses an ECS capacity provider associated with an EC2 Auto Scaling group.
Capacity providers can support managed scaling and managed instance termination protection. Cluster scaling is relevant to EC2-backed ECS workloads; Fargate removes the need to manage an EC2 container-instance fleet.
ECS Versus EKS
ECS and EKS are both managed container orchestration services, but they target different operational and compatibility requirements.
ECS is AWS-specific and generally simpler to operate. It uses ECS tasks and services, integrates closely with AWS services, and is a strong fit when the application does not require Kubernetes compatibility.
EKS is managed Kubernetes. It is usually the better choice when an organization:
- Already uses Kubernetes
- Requires Kubernetes APIs and tooling
- Wants portability across AWS, on-premises, or other environments
- Needs Kubernetes Jobs or a Kubernetes-native operating model
- Depends on Kubernetes ecosystem extensions and add-ons
The main terminology distinction is tasks in ECS versus pods in Kubernetes and EKS. A pod is the smallest Kubernetes deployment unit and can contain one or more co-located containers that share networking and storage context.
Exam-Relevant Takeaways
- Choose ECS for an AWS-native container platform with simpler operations and strong AWS integration.
- Choose EKS when Kubernetes compatibility, existing Kubernetes expertise, portability, or Kubernetes APIs are explicit requirements.
- Choose Fargate when you want serverless container execution and do not need control over the underlying instances.
- Choose the ECS EC2 launch type when you need host-level control, specialized instance configurations, or potentially more direct control over capacity economics.
- A task definition is the deployment blueprint; a task is the running workload; a service maintains long-running task count.
- Service auto scaling scales task count. Cluster auto scaling scales EC2 container-instance capacity.
- ECS services can use ALB or NLB integration to distribute traffic across tasks.
- ECR is a private, managed registry for container images.
- ECS Anywhere allows ECS management of supported external or on-premises container infrastructure.
- An EC2 container instance can belong to only one ECS cluster at a time.
Architecture Decision Guide
| Requirement | Recommended choice | Reason |
|---|---|---|
| Run containers without managing EC2 instances | ECS with Fargate | AWS manages the underlying compute capacity |
| Need control over container hosts or instance configuration | ECS with EC2 | You manage the EC2 capacity and gain infrastructure control |
| Existing Kubernetes platform must be retained | EKS | Provides managed Kubernetes compatibility |
| Simple AWS-native container orchestration | ECS | Typically simpler and closely integrated with AWS services |
| Maintain a desired number of long-running containers | ECS service | Services maintain task count and support scaling and load balancing |
| Store private container images | Amazon ECR | Managed private image registry integrated with AWS |
| Scale the number of running application tasks | ECS service auto scaling | Adjusts desired task count |
| Scale EC2 capacity for ECS tasks | ECS cluster auto scaling with capacity providers | Adjusts the container-instance fleet |
| Distribute HTTP application traffic to tasks | ALB integrated with ECS service | Supports Layer 7 routing and HTTP features |
| Distribute TCP/UDP or high-performance Layer 4 traffic | NLB integrated with ECS service | Provides Layer 4 load balancing |
| Manage ECS workloads on supported external infrastructure | ECS Anywhere | Extends ECS management beyond AWS infrastructure |
Common Exam Traps
- Confusing task scaling with cluster scaling: Increasing the desired task count does not automatically mean the EC2 instance fleet has enough capacity unless cluster capacity scaling is also configured.
- Assuming Fargate provides host access: Fargate removes host management and provides less infrastructure-level control than EC2-backed ECS.
- Treating a task definition as a running container: The definition is configuration; the task is the running deployment.
- Choosing EKS merely because the application uses containers: EKS is justified by Kubernetes requirements, not containers alone.
- Assuming ECS and EKS use the same terminology: ECS uses tasks and services; EKS uses pods and Kubernetes objects.
- Forgetting the difference between ALB and NLB: Select the load balancer based on protocol and routing requirements, not simply because the workload uses containers.
- Assuming ECS Anywhere means AWS provides the external servers: ECS Anywhere extends management to customer-managed infrastructure; it does not turn those servers into AWS-managed compute.
- Ignoring host lifecycle responsibility with EC2 launch type: EC2-backed ECS requires patching, capacity planning, and instance management.
Real-World Engineer Notes
- Separate application scaling from infrastructure scaling in both monitoring and architecture reviews. A service may request more tasks while the underlying EC2 capacity remains saturated.
- Fargate simplifies operations, but the decision should still account for task resource sizing, networking, observability, startup behavior, and cost.
- Use immutable image versioning and controlled promotion through ECR rather than relying on ambiguous image tags for production deployments.
- For ECS services behind a load balancer, configure health checks so unhealthy tasks can be replaced automatically.
- The EC2 launch type can be useful when workloads need specific instance families, host-level agents, custom AMIs, or tighter control of the compute fleet.
- EKS introduces the Kubernetes ecosystem and portability benefits, but also brings additional platform complexity and operational concepts.
Quick Reference Summary
- Image: Read-only template used to create containers.
- Container: Running instance of an image.
- ECR: Managed private container image registry.
- Task definition: JSON configuration for one or more containers.
- Task: Running deployment based on a task definition.
- Service: Maintains long-running tasks and desired count.
- Cluster: Logical ECS grouping for tasks and capacity.
- EC2 launch type: More control, more infrastructure management.
- Fargate: Less management, less host-level control.
- Service auto scaling: Changes task count.
- Cluster auto scaling: Changes EC2 container-instance capacity.
- ECS: AWS-native, simpler container orchestration.
- EKS: Managed Kubernetes for Kubernetes-native requirements.
Flashcards
- Q: What is an ECS task definition?
A: A JSON blueprint describing how one or more containers should run.
- Q: What is the difference between an ECS task and a task definition?
A: A task definition is configuration; a task is a running instance based on that configuration.
- Q: What does an ECS service provide?
A: It maintains a desired number of long-running tasks and can integrate with scaling and load balancing.
- Q: What is the main operational advantage of Fargate?
A: It runs containers without requiring customers to provision or manage EC2 container instances.
- Q: What is the main advantage of the ECS EC2 launch type?
A: Greater control over the underlying instances and container capacity.
- Q: What does ECS service auto scaling change?
A: The desired number of running tasks.
- Q: What does ECS cluster auto scaling change?
A: The number of EC2 container instances available to the cluster.
- Q: When is EKS generally preferred over ECS?
A: When Kubernetes compatibility, existing Kubernetes operations, portability, or Kubernetes APIs are required.
- Q: What is Amazon ECR used for?
A: Storing and retrieving container images in a managed private registry.
- Q: What is an ECS container instance?
A: An EC2 instance running the ECS container agent and registered with an ECS cluster.
- Q: Can an EC2 container instance belong to multiple ECS clusters simultaneously?
A: No. An instance can be part of only one ECS cluster at a time.
- Q: What are the Kubernetes equivalents of ECS tasks?
A: Kubernetes pods are the comparable execution unit, although the concepts are not identical.
Practice Questions
Question 1
A company wants to run a stateless web application in containers. The team does not want to patch operating systems, manage EC2 capacity, or optimize a container cluster. The application must scale the number of running containers based on utilization. Which solution best meets these requirements?
A. ECS with the EC2 launch type and a manually managed Auto Scaling group
B. ECS with Fargate and ECS service auto scaling
C. EKS with self-managed worker nodes
D. ECS Anywhere with customer-managed on-premises servers
Correct answer: B
Explanation: Fargate removes EC2 host management, while ECS service auto scaling adjusts the desired number of running tasks. The other options retain infrastructure-management responsibilities or do not match the stated AWS deployment requirement.
Question 2
An organization runs Kubernetes clusters on premises and wants to move workloads to AWS while preserving Kubernetes APIs, deployment tools, and operational processes. Which service is the best fit?
A. Amazon ECS with Fargate
B. Amazon ECS with the EC2 launch type
C. Amazon EKS
D. Amazon ECR
Correct answer: C
Explanation: EKS provides managed Kubernetes and is designed for scenarios where existing Kubernetes skills, APIs, tooling, and deployment models must be retained. ECR is only a container image registry.
Question 3
An ECS service uses the EC2 launch type. Service auto scaling increases the desired task count, but new tasks remain pending because the cluster has no available resources. What additional capability is required?
A. ECR replication
B. ECS cluster auto scaling through a capacity provider and EC2 Auto Scaling group
C. An NLB instead of an ALB
D. ECS Anywhere
Correct answer: B
Explanation: Service auto scaling changes task count, while cluster auto scaling adds EC2 container-instance capacity. A capacity provider associated with an EC2 Auto Scaling group can help scale the underlying fleet.
Question 4
A company needs an AWS-native container platform for a new application. It does not use Kubernetes and wants straightforward integration with AWS services and ECS load balancing. Which option is most appropriate?
A. ECS
B. EKS
C. Amazon ECR only
D. Kubernetes running on unmanaged EC2 instances
Correct answer: A
Explanation: ECS is the AWS-native container orchestration service and is generally simpler when Kubernetes compatibility is not a requirement. ECR stores images but does not orchestrate or run containers.
Question 5
A business needs to expose an ECS service that handles TCP traffic and requires high-performance Layer 4 load balancing. Which load balancer is the best choice?
A. Application Load Balancer
B. Network Load Balancer
C. Amazon ECR
D. ECS service auto scaling
Correct answer: B
Explanation: NLB is designed for Layer 4 TCP/UDP traffic and high-performance load balancing. ALB is generally selected for HTTP/HTTPS and Layer 7 routing requirements.