What is the difference between ECS and EKS?

Amazon ECS (Elastic Container Service) is AWS's proprietary container orchestration system. Amazon EKS (Elastic Kubernetes Service) runs managed Kubernetes. The key difference: ECS is simpler and AWS-native; EKS gives you the standard Kubernetes API and is portable across clouds. On the SAA-C03, a scenario mentioning 'Kubernetes' or 'multi-cloud portability' always points to EKS; a scenario asking for 'least operational overhead' with containers and no Kubernetes requirement points to ECS.

AWS Fargate is a serverless compute engine for containers — not a standalone orchestrator, but a launch type you select when creating an ECS service or an EKS Fargate profile. With Fargate, you declare how much CPU and memory your containers need and AWS provisions and manages the underlying compute. You never SSH into a server. Fargate works with both ECS and EKS.

When should I use Fargate instead of Lambda?

Use Fargate (with ECS or EKS) when your workload runs in containers, needs more than 15 minutes of execution time, requires more than 10 GB of memory or roughly 6 vCPUs, or runs at sustained high traffic where per-request Lambda pricing becomes expensive. Use Lambda when the workload is event-driven, short-lived (under 15 minutes), and has variable or unpredictable invocation patterns — Lambda's per-invocation model wins for bursty, low-traffic workloads.

Does Fargate work with EKS?

Yes. AWS Fargate works with both Amazon ECS (as the Fargate launch type) and Amazon EKS (as Fargate profiles). When you add a Fargate profile to an EKS cluster, pods that match the profile's namespace and label selectors run on Fargate compute — no EC2 nodes to manage. The Kubernetes API works identically; only the underlying infrastructure changes.

Which is cheaper: ECS with EC2 or ECS with Fargate?

ECS with an EC2 launch type is generally cheaper for high-throughput, steady-state workloads because you can use Reserved Instances or Spot Instances and bin-pack multiple containers onto each instance. Fargate costs more per vCPU-hour but eliminates all infrastructure management overhead. The exam rule: if a scenario mentions cost optimization for predictable high-volume traffic, EC2 launch type with Spot is usually correct. If it asks for minimum operational overhead, Fargate is correct regardless of cost.

What is an ECS task definition?

An ECS task definition is the blueprint for your containerized application — similar to a Docker Compose file but for AWS. It specifies the container image, CPU and memory allocation, port mappings, environment variables, IAM task role, and logging configuration. A task is a running instance of a task definition; an ECS service maintains a desired count of running tasks and handles replacement if tasks fail or health checks don't pass.

ECS vs. EKS vs. Fargate: The AWS Container Decision the SAA-C03 and DVA-C02 Both Test

Here is a scenario you will see on the SAA-C03:

A startup is containerizing a microservices application for the first time. They have three developers and no Kubernetes experience. They want to run containers on AWS with the least operational overhead, pay only for what they use, and avoid managing EC2 instances. What should a solutions architect recommend?

Four choices: Amazon ECS with EC2 launch type. Amazon ECS with Fargate launch type. Amazon EKS with managed node groups. Amazon EKS with Fargate profiles.

The answer is ECS with Fargate launch type — but if you chose EKS with Fargate profiles because "Fargate = no servers = right answer," or chose EKS because you've heard Kubernetes is the industry standard, you just fell into both traps this question was designed to test.

The ECS vs. EKS vs. Fargate decision matters on the exams because the confusion runs deep. ECS and EKS are both container orchestrators. Fargate works with both. The exams regularly pair "least operational overhead" with "Kubernetes-standard infrastructure." Understanding why these are different answers to different questions — and which signal in a scenario points to which service — is the entire skill this topic tests.

What ECS, EKS, and Fargate Actually Are (and How They Fit Together)

Before the decision framework, the mental model matters: Fargate is not a separate service competing with ECS and EKS. It is a compute option — a launch type — that both ECS and EKS can use.

The correct way to think about the four modes of running containers on AWS:

Mode	Orchestrator	Compute you manage
ECS + EC2 launch type	Amazon ECS	EC2 instances you provision
ECS + Fargate launch type	Amazon ECS	None — AWS manages compute
EKS + managed node groups	Kubernetes (EKS)	Node groups (AMI/scaling)
EKS + Fargate profiles	Kubernetes (EKS)	None — AWS manages compute

The two decisions are independent: first, which orchestrator (ECS or EKS), then which compute substrate (EC2 or Fargate). Most exam scenarios test the orchestrator decision; some test the compute decision; the hardest ones test both simultaneously.

Amazon ECS: The AWS-Native Container Orchestrator

Amazon ECS is AWS's proprietary container orchestration service. It was built AWS-first — deeply integrated with IAM, VPC, ALB/NLB, CloudWatch, and AWS Service Discovery — and optimized for simplicity over flexibility.

The core ECS primitives:

Task definition — the blueprint: container image, CPU/memory, port mappings, IAM task role, log driver. Think of it as a Docker Compose file for a single deployable unit.
Task — a running instance of a task definition. One task can run multiple containers that share a network namespace (useful for sidecar patterns).
Service — keeps a desired count of tasks running. Replaces failed tasks automatically, integrates with an ALB target group for load balancing, and drives rolling deployments.
Cluster — the logical grouping of tasks and services (and EC2 instances, for the EC2 launch type).

The EC2 launch type: You provision the EC2 instances, manage AMI updates, and control cluster scaling — but you can use Spot Instances, Reserved Instances, and bin-pack multiple containers per instance. This is the cost-optimized path for teams with predictable, steady-state workloads.

The Fargate launch type: No EC2 instances to manage. You declare the CPU and memory per task; AWS provisions the compute. You pay per vCPU-second and GB-second consumed. The exam calls this "no servers to manage" or "serverless containers."

When the SAA-C03 or DVA-C02 points to ECS:

"No Kubernetes experience" or "not currently using Kubernetes"
"Fully managed" containers with "deep AWS service integration"
"Least operational overhead" when no Kubernetes requirement is stated
Microservices that don't need cross-cloud portability

Amazon EKS: The Kubernetes Path

Amazon EKS runs Kubernetes — the open-source container orchestration standard. AWS manages the Kubernetes control plane (the etcd data store, the kube-apiserver, the controller manager, and the scheduler). You interact with the cluster using standard kubectl commands and the Kubernetes API.

The critical difference from ECS: EKS uses Kubernetes primitives — Pods, Deployments, Services, Ingresses, ConfigMaps, Secrets, Custom Resource Definitions (CRDs). These are identical across AWS, GCP, Azure, and on-premises. If your team already uses Kubernetes or needs to run the same workloads on multiple clouds, EKS lets you reuse existing tooling and manifests.

With managed node groups: AWS provisions and updates EC2 instances for the worker nodes. You manage scaling configuration and node group settings, but AWS handles the Kubernetes control plane agents. Less work than fully self-managed nodes, but more operational surface than Fargate.

With Fargate profiles: You define which pods (by namespace and label selectors) run on Fargate compute. Those pods get serverless infrastructure per the EKS Fargate documentation. Useful when you want the Kubernetes API without any node management — though with constraints: no DaemonSets, no privileged containers, and each pod runs in a dedicated micro-VM (stronger isolation, but no bin-packing multiple pods per instance).

When the SAA-C03 points to EKS:

The scenario explicitly mentions Kubernetes or "container orchestration using Kubernetes"
"Portability between cloud providers" or "multi-cloud" with existing Kubernetes workloads
"Custom resource definitions," "CRDs," or "Kubernetes-native tooling"
The company already has Kubernetes expertise and wants a managed control plane

Fargate vs. Lambda: The Exam's Hardest Container Trap

The SAA-C03 and DVA-C02 regularly offer Lambda as an alternative to Fargate. This is a common misdirection. Here is the decision table:

Signal in the scenario	Answer
"Event-driven," "triggered by," "per-request invocations"	Lambda
Execution time under 15 minutes	Lambda (simpler and cheaper for short tasks)
Execution time over 15 minutes	ECS or EKS with Fargate (Lambda hard limit)
"Container image," "Docker," "existing containerized app"	ECS or EKS (Fargate or EC2)
Memory over 10 GB or CPU over 6 vCPU	ECS or EKS (Lambda ceiling: ~10 GB RAM, ~6 vCPU at max memory)
"Sustained high traffic," "always-on," "predictable load"	ECS or EKS (Lambda per-invocation pricing is expensive at scale)
"Variable," "bursty," "unpredictable, low-frequency traffic"	Lambda (scales to zero; no idle cost)
"No server management" + containers running 24/7	Fargate (ECS or EKS)

A common exam trap: a containerized batch job that runs for 20 minutes, triggered by an S3 event upload. The container dimension points to ECS/Fargate; the 20-minute runtime eliminates Lambda. The S3 trigger is a distractor — EventBridge Pipes or S3 event notifications can trigger ECS tasks too.

AWS container service decision tree — ECS vs EKS vs Fargate vs Lambda choosing the right compute layer

The Full Decision Framework

Use this order of operations on any exam scenario involving containers:

Step 1 — Is Kubernetes required?

Yes (explicit mention, portability requirement, CRDs, existing Kubernetes team) → EKS
No (unspecified, or "simplest approach," no Kubernetes skills) → ECS

Step 2 — What compute substrate?

"No servers," "serverless," "no EC2 to manage," "least operational overhead" → Fargate
"Cost optimization," "Spot Instances," "steady-state high throughput," "bin-packing" → EC2 launch type

Step 3 — Is Lambda on the table?

Execution time over 15 min → eliminate Lambda immediately
Sustained or predictable high traffic → prefer ECS or EKS
Event-driven, bursty, short-duration → Lambda wins on simplicity and cost

If the scenario says nothing about Kubernetes and asks for "least operational overhead with no servers," the answer is almost always ECS + Fargate. EKS with Fargate adds Kubernetes complexity for no benefit when the team doesn't need the Kubernetes API.

Architecture: Control Plane, Compute, Workload

AWS container services architecture comparison — ECS EC2 vs ECS Fargate vs EKS EC2 vs EKS Fargate control plane and data plane layers

The architecture diagram above shows the structural split. Both ECS and EKS have a managed control plane (AWS-operated), but the data plane — where your containers actually run — depends on whether you choose EC2 or Fargate. The control planes are different systems with different APIs; the Fargate compute layer is shared infrastructure that looks identical from the outside regardless of whether the orchestrator above it is ECS or Kubernetes.

What This Looks Like on the DVA-C02

The Developer Associate exam focuses on ECS and Fargate through a developer lens, not an architecture-selection lens.

Task IAM roles: Each ECS task should have its own IAM role, configured via taskRoleArn in the task definition. The DVA-C02 tests this: a question about a Lambda-like pattern where a container needs S3 access expects the taskRoleArn field, not an EC2 instance profile. Instance profiles apply to the EC2 host, not to individual tasks.

Secrets Manager integration: Injecting secrets into containers via the secrets block in the task definition (pulling from AWS Secrets Manager or Parameter Store at task launch) versus baking them in as plaintext environment variables. The exam expects Secrets Manager integration for any credential or API key scenario.

Rolling deployments: ECS services use a rolling update deployment strategy by default. The DVA-C02 tests the minimumHealthyPercent and maximumPercent parameters — the knobs that control how many old tasks remain running while new tasks start. A minimumHealthyPercent of 50 and maximumPercent of 100 means half the old tasks must stay healthy while the other half are replaced; the replacement can't overprovision above the desired count.

Container health checks: ECS can use ALB target group health checks or container-level health checks defined in the task definition (healthCheck block). Understanding which layer detects and replaces an unhealthy container is a recurring DVA-C02 question pattern.

Take the free DVA-C02 diagnostic to see how these container-specific topics show up in the current exam blueprint, then practice full scenarios in the DVA-C02 question bank.

What This Looks Like on the SAA-C03

The Solutions Architect exam tests the architecture decision — which service, and why, given competing constraints.

Design pattern to recognize: Any scenario that says "containerized application," "Docker images," or "microservices" and then lists requirements (operational overhead, cost, portability, execution time) is testing the three-way framework above. Map each constraint to the decision tree and eliminate one option at a time.

Multi-AZ container resilience: ECS services and EKS node groups both span Availability Zones when configured correctly. Placing tasks across AZs requires explicit configuration — ECS Service placement strategies or EKS node group multi-AZ settings — not a default assumption. An exam scenario asking for "high availability for containers" expects you to know this is a configuration choice, not automatic.

Auto Scaling: ECS services scale via Application Auto Scaling targeting CPU/memory utilization or ALB request count per target. EKS uses the Kubernetes Cluster Autoscaler (for EC2 nodes) or Karpenter (AWS's faster, more efficient node provisioner) to scale nodes, and the Kubernetes Horizontal Pod Autoscaler to scale pods. Fargate handles compute scaling automatically at the task or pod level — no node scaling required, because there are no nodes.

Connecting containers to queues: A frequent SAA-C03 pattern pairs ECS with an SQS queue — a queue receives work items, and an ECS service polls and processes them, scaling tasks up when the queue depth grows. Compare this with the event-driven decoupling patterns in SQS vs. SNS vs. EventBridge to see how queue-triggered container tasks fit into broader architectures.

Start testing yourself on these architecture scenarios with the free SAA-C03 diagnostic, then work through container-focused questions in the SAA-C03 practice bank.

Quick-Reference Summary

	ECS + EC2	ECS + Fargate	EKS + EC2	EKS + Fargate
Orchestrator	Amazon ECS	Amazon ECS	Kubernetes	Kubernetes
Server management	You manage EC2	None	You manage nodes	None
Kubernetes API	No	No	Yes	Yes
Multi-cloud portability	No	No	Yes	Yes
Cost model	EC2 pricing	Per vCPU·s / GB·s	EC2 + K8s control plane fee	Fargate + K8s control plane fee
DaemonSets	Yes (ECS equivalents)	No	Yes	No
Best for	Cost-optimized, steady traffic	Simplest containers, minimal ops	Existing K8s teams, portability	K8s + serverless compute

Three Rules to Commit to Memory

"Kubernetes" → EKS. No exceptions. No matter how simple the rest of the scenario sounds, explicit mention of Kubernetes always means EKS.
"No servers / least operational overhead" + containers, no Kubernetes → ECS + Fargate. EKS + Fargate has more operational complexity (Kubernetes API, Fargate profile selectors, pod scheduling constraints) for the same compute benefit.
"Over 15 minutes" eliminates Lambda. Pair this with "containers" or "existing Docker image" and the answer is always ECS or EKS — usually Fargate unless the scenario explicitly calls for cost optimization via Spot Instances.

For more on the serverless side of these decisions — specifically Lambda's concurrency model and what Reserved vs. Provisioned concurrency do — see Lambda Concurrency: Reserved vs. Provisioned. The two topics come together in any scenario that asks when to lift a workload from Lambda into a container.