Amazon ECS and EKS Architecture Patterns – SAP-C02 Study Guide

Purpose of This Lesson

This lesson focuses on selecting and configuring AWS container services for common architecture requirements. The key decisions include:

• Scaling ECS services using memory utilization.
• Granting containers access to AWS services such as Amazon S3.
• Choosing Amazon ECS versus Amazon EKS.
• Selecting between Fargate, EC2, and Spot Instances for container workloads.
• Routing requests to ECS microservices with an Application Load Balancer (ALB).
• Monitoring EKS clusters, namespaces, services, logs, and metrics with CloudWatch Container Insights.

Key Concepts

ECS service auto scaling based on memory

Amazon ECS Service Auto Scaling adjusts the desired task count for an ECS service. A service can scale using target tracking, step scaling, or scheduled scaling policies.

For an application that must scale based on memory consumption, configure target tracking against the ECS service metric:

• ECSServiceAverageMemoryUtilization

For example, a target tracking policy might attempt to keep average memory utilization near 60%. ECS adds or removes tasks as utilization changes.

Important distinctions:

• Service auto scaling changes the number of running tasks.
• Cluster capacity scaling adds or removes EC2 container instances when using the EC2 launch type.
• With Fargate, AWS supplies the underlying capacity, so you generally configure task scaling without managing container hosts.

IAM roles for ECS tasks

ECS uses two different IAM roles that are frequently tested together:

Role	Used by	Typical permissions
Task role	The application running inside the container	Read objects from S3, publish to Amazon SQS, write to DynamoDB, call other AWS APIs
Task execution role	The ECS agent or Fargate platform on behalf of the task	Pull images from Amazon ECR, send logs to CloudWatch Logs, retrieve supported secrets and configuration

If an application running in a task must read from an S3 bucket, grant the required S3 permissions to the task role, not to the EC2 host instance profile and not solely to the task execution role.

The task role should follow least privilege. For example, grant s3:GetObject only to the required bucket prefix rather than granting broad access to all S3 resources.

ECS versus EKS

Amazon ECS is an AWS-native container orchestration service. It is often simpler to operate when the workload is intended to run primarily on AWS and does not require Kubernetes compatibility.

Amazon EKS is managed Kubernetes. It is a better fit when an organization requires:

• Kubernetes APIs and tooling.
• Portability across AWS, on-premises environments, or multiple clouds.
• Existing Kubernetes operational expertise.
• Kubernetes-native ecosystem integrations and deployment patterns.
• Compatibility with applications already designed for Kubernetes.

EKS still requires Kubernetes administration, including cluster configuration, add-ons, workload deployment, and operational governance. The EKS control plane is managed by AWS, but the overall Kubernetes platform is not fully serverless by default.

The choice should not be based only on the word “Docker.” Both ECS and EKS can run container images. The deciding factors are orchestration requirements, portability, existing skills, operational complexity, and cost.

Cost-oriented container deployment

There is no universal lowest-cost launch type. The answer depends on utilization, task duration, resource requirements, scaling behavior, and operational overhead.

Potential options include:

• ECS on EC2 On-Demand Instances: useful for predictable, steady workloads and workloads requiring host-level control.
• ECS on EC2 Spot Instances: often the lowest compute cost for interruption-tolerant workloads.
• ECS on Fargate: avoids managing container hosts and charges based on requested task resources and runtime, but may cost more for continuously running, highly utilized workloads.
• EKS with managed or Spot worker capacity: appropriate when Kubernetes is required, but the Kubernetes control plane and operational overhead must be included in the design.

For ECS services using Spot Instances, enable ECS managed instance draining or configure instance draining behavior so tasks are stopped and replaced gracefully when an EC2 instance receives an interruption notice. Applications should still be designed for interruption and task replacement.

Fargate for eliminating host management

AWS Fargate is a serverless compute engine for containers used with ECS and EKS. It removes the need to provision, patch, scale, and maintain EC2 container hosts.

Choose Fargate when the requirement emphasizes:

• No operating system management.
• No container cluster host administration.
• Per-task resource allocation.
• Rapid or variable scaling without managing an EC2 fleet.

Fargate does not eliminate all operational responsibilities. You still manage task definitions, networking, IAM, secrets, images, logging, security groups, and application behavior.

ALB routing for ECS microservices

An Application Load Balancer can route requests to different ECS services through listener rules. Common routing conditions include:

• Host header, such as orders.example.com.
• Path pattern, such as /orders/*.
• HTTP header values.
• Query-string parameters.
• Source IP address.
• HTTP method and other supported rule conditions.

Each rule forwards traffic to a target group, which can represent a separate ECS service. For example, an ALB could route requests with an HTTP header such as X-Service: billing to a billing target group.

ALB routing is distinct from service discovery. Use ALB listener rules when routing is based on incoming HTTP request attributes. Use AWS Cloud Map or another service discovery approach when services need to locate one another dynamically without going through an ALB.

CloudWatch Container Insights for EKS

Amazon CloudWatch Container Insights collects and aggregates container metrics and logs. For EKS, it can provide observability across Kubernetes resources such as:

• Clusters.
• Nodes.
• Pods.
• Namespaces.
• Workloads and services.
• Container CPU and memory usage.
• Container logs and performance data.

The information is viewed in the CloudWatch console and can be queried or integrated with CloudWatch alarms and dashboards. Enabling Container Insights may incur CloudWatch ingestion and storage charges, so retention and collection scope should be planned.

Exam-Relevant Takeaways

• Use ECS Service Auto Scaling to change the desired number of tasks based on ECSServiceAverageMemoryUtilization.
• Use an ECS task role for permissions required by application code inside a container.
• Use the task execution role for ECS/Fargate operations such as pulling ECR images and sending logs to CloudWatch Logs.
• Choose EKS when Kubernetes compatibility, portability, or Kubernetes-native tooling is a primary requirement.
• Choose Fargate when the requirement is to avoid managing container hosts or operating systems.
• EC2 Spot capacity can reduce costs for interruption-tolerant ECS workloads, but use draining and design for task replacement.
• Fargate is not automatically cheaper than EC2. Compare workload utilization and include operational costs.
• ALB listener rules can route based on host headers, paths, HTTP headers, and query-string parameters.
• CloudWatch Container Insights provides centralized container-level observability for EKS and other supported container environments.

Architecture Decision Guide

Requirement	Strong candidate	Reasoning	Main caveat
Scale ECS tasks based on memory	ECS Service Auto Scaling with target tracking	Adjusts desired task count using average service memory utilization	Ensure task memory limits and capacity are sufficient
Application code needs S3 access	ECS task role	Credentials are made available to the application container	Scope permissions to required buckets and prefixes
Pull ECR images or send task logs	ECS task execution role	Used by the ECS agent or Fargate platform	This does not replace the application task role
Kubernetes portability or existing Kubernetes platform	Amazon EKS	Provides managed Kubernetes control plane and Kubernetes APIs	More platform complexity than ECS
No container host management	AWS Fargate	AWS manages the underlying compute hosts	Resource pricing may exceed well-utilized EC2 capacity
Lowest compute cost for interruptible workloads	ECS on EC2 Spot	Uses discounted interruptible capacity	Tasks can be interrupted; use draining and resilient applications
HTTP header or query-string routing	ALB listener rules	Routes requests to service-specific target groups	Validate rule priority and condition support
Centralized EKS metrics and logs	CloudWatch Container Insights	Provides cluster and workload-level visibility	Monitor CloudWatch ingestion and retention costs

Common Exam Traps

• Confusing task role and task execution role: S3 access used by application code belongs on the task role.
• Assuming Fargate is always cheapest: Fargate reduces management effort, but EC2 or Spot may be less expensive for stable, highly utilized workloads.
• Treating EKS as completely serverless: EKS manages the control plane, but worker capacity and Kubernetes operations still require design and management unless Fargate or another managed compute option is used.
• Using an EC2 instance profile for application permissions: Host-level credentials are broader than necessary and do not represent the correct ECS security model.
• Ignoring Spot interruption behavior: Spot capacity requires graceful draining, replacement capacity, and stateless or checkpointed application design.
• Using the wrong ALB routing condition: Header-based routing, path-based routing, host-based routing, and query-string routing are different listener rule conditions. Select the one matching the request requirement.
• Scaling tasks without scaling EC2 capacity: ECS task scaling on the EC2 launch type can fail if the cluster lacks available CPU or memory. Configure capacity scaling as needed.
• Assuming monitoring is free: CloudWatch Container Insights can generate metric, log ingestion, and storage charges.

Real-World Engineer Notes

• Set realistic ECS task memory reservations and limits. Scaling on average memory utilization is only useful when the task definition reflects the application’s actual resource behavior.
• For Fargate tasks, place tasks in appropriate subnets and provide network access to dependencies such as ECR, CloudWatch Logs, S3, and secrets. VPC endpoints can reduce NAT Gateway dependency and cost for supported services.
• For ECS on EC2, use capacity providers to associate services with On-Demand and Spot capacity and to control the desired capacity mix.
• Use multiple target group health checks and graceful shutdown behavior so ALB deregistration and ECS task replacement do not interrupt in-flight requests.
• Protect S3 access with both IAM policies and, where appropriate, S3 bucket policies, VPC endpoint policies, encryption requirements, and organization-level controls.
• For EKS, define a deliberate observability strategy. Container Insights is useful for managed collection, but high-volume application logs may require filtering, retention policies, or an alternate log pipeline.
• Prefer stateless containers when possible. Persistent state should generally be placed in managed services such as Amazon RDS, DynamoDB, ElastiCache, or Amazon EFS according to the access pattern.

Quick Reference Summary

• Memory-based ECS scaling: ECS Service Auto Scaling using ECSServiceAverageMemoryUtilization.
• Application-to-S3 permissions: ECS task role.
• ECR pull and CloudWatch Logs permissions: ECS task execution role.
• AWS-native orchestration: ECS.
• Kubernetes and portability: EKS.
• No host operating system management: Fargate.
• Discounted interruptible compute: EC2 Spot with draining and resilient tasks.
• HTTP request routing: ALB listener rules and target groups.
• EKS centralized metrics and logs: CloudWatch Container Insights.

Flashcards

1. Q: Which ECS metric can be used to scale a service based on memory?

A: ECSServiceAverageMemoryUtilization, typically with ECS Service Auto Scaling target tracking.

1. Q: Which IAM role should an ECS application use to read from Amazon S3?

A: The ECS task role.

1. Q: What is the ECS task execution role used for?

A: ECS/Fargate platform actions such as pulling images from ECR, sending logs to CloudWatch Logs, and retrieving supported configuration or secrets.

1. Q: When is Amazon EKS preferable to ECS?

A: When Kubernetes APIs, existing Kubernetes expertise, Kubernetes-native tooling, or portability across environments is required.

1. Q: What is the main operational benefit of Fargate?

A: It removes the need to manage EC2 container hosts and their operating systems.

1. Q: Why might ECS on Spot Instances reduce cost?

A: Spot Instances offer discounted compute capacity for workloads that can tolerate interruption.

1. Q: What should be configured to handle ECS tasks running on Spot capacity?

A: Instance draining or ECS managed draining, replacement capacity, and application-level resilience to task interruption.

1. Q: Which AWS load balancer can route HTTP requests based on headers or query strings?

A: An Application Load Balancer using listener rule conditions.

1. Q: What does an ALB target group commonly represent in an ECS microservices design?

A: A group of tasks belonging to a particular ECS service.

1. Q: What CloudWatch feature provides EKS container metrics and logs by Kubernetes resource?

A: CloudWatch Container Insights.

1. Q: Is Fargate always less expensive than ECS on EC2?

A: No. Fargate may be more expensive for steady, highly utilized workloads, while EC2 or Spot can have lower compute cost.

1. Q: What can happen if ECS tasks scale out but EC2 cluster capacity does not?

A: Tasks may remain pending because the cluster lacks sufficient CPU or memory; capacity scaling must be addressed separately.

Practice Questions

Question 1

An ECS task runs an application that must read objects from a specific S3 bucket prefix. The ECS cluster uses EC2 instances. Which configuration provides the correct least-privilege access?

A. Add s3:GetObject to the EC2 instance profile.

B. Add s3:GetObject to the ECS task execution role.

C. Add s3:GetObject to the ECS task role and scope the resource to the required prefix.

D. Store long-term access keys in the container image.

Correct answer: C

The application runs inside the task, so its AWS permissions belong in the task role. The policy should be restricted to the required S3 objects. The execution role is used by the ECS platform, not normally by application code.

Question 2

A company must run containers using Kubernetes APIs and the same deployment tooling across AWS and its on-premises environment. Which service best meets the requirement?

A. Amazon ECS with the EC2 launch type.

B. AWS Fargate with ECS.

C. Amazon EKS.

D. AWS Lambda container images.

Correct answer: C

Amazon EKS provides managed Kubernetes control planes and compatibility with Kubernetes APIs and tooling. ECS is an AWS-native orchestrator and does not provide Kubernetes compatibility.

Question 3

A stateless ECS service has unpredictable traffic and must not require administrators to patch or scale container hosts. Which option best satisfies the operational requirement?

A. ECS on a manually managed EC2 cluster.

B. ECS on Fargate with ECS Service Auto Scaling.

C. ECS on Spot Instances with manually maintained AMIs.

D. Containers installed directly on an EC2 instance.

Correct answer: B

Fargate removes container host management. ECS Service Auto Scaling can adjust the number of running tasks as demand changes.

Question 4

An ECS service uses EC2 Spot Instances. During a Spot interruption, tasks must be replaced with minimal disruption. Which design is most appropriate?

A. Disable health checks so interrupted tasks remain registered.

B. Use ECS instance draining, provide replacement capacity, and make the service resilient to task termination.

C. Store AWS access keys on each Spot instance.

D. Prevent ECS from launching replacement tasks.

Correct answer: B

Spot Instances can be interrupted. Draining prevents new work from being placed on an affected instance and allows tasks to stop gracefully, while replacement capacity and application resilience maintain availability.

Question 5

An EKS platform team needs centralized visibility into CPU, memory, logs, namespaces, and services from the CloudWatch console. Which feature should they enable?

A. AWS CloudTrail data events.

B. VPC Flow Logs.

C. CloudWatch Container Insights.

D. Amazon Inspector only.

Correct answer: C

CloudWatch Container Insights collects and presents container performance data and logs at cluster and Kubernetes workload levels, including namespaces and services. CloudTrail and VPC Flow Logs serve different auditing and network-observability purposes.