Based on the SAP-C02 exam guideReport an error
If you've ever clicked "Create ECS" somewhere in the console, two questions immediately come to mind: "Why not use EKS?", "What's the difference from Fargate?" On the surface, all three look like "tools for running containers," but when you receive your billing statement, the difference can be hundreds of dollars per month. The SAP exam presents scenarios with all three services, averaging 3-4 questions per domain, but surface-level keyword matching won't get you even halfway there.
This article examines why ECS, EKS, and Fargate evolved into their current forms, how the control plane and data plane diverge, and where the branching occurs depending on scenarios. Including App Runner, ECS/EKS Anywhere, we aim to draw a single map of the "AWS container family." If you recall this map before the exam, any scenario narrows down to one of four answers.
Before Docker arrived in 2013, server deployment meant "work dependent on a specific server." If you installed ruby 2.6, python 3.7, and node 12 on one server simultaneously, dependency hell began, and "it works on my laptop but not on the server" was the daily norm. Docker solved this problem by layering image and layer concepts on top of LXC (Linux Containers) and Union FS, but the moment you spin up 30 containers on one server, a new problem emerges. It becomes difficult to track which containers are dead and which are alive, and if one server dies, all 30 containers on it disappear at once.
In 2014, Google open-sourced its Borg system experience as Kubernetes (K8s). AWS released ECS the same year, creating its own orchestrator because K8s hadn't yet reached version 1.0 officially. Later, as K8s became the de facto standard, AWS announced EKS in 2017 at re:Invent, declaring "we now offer K8s as a managed service." Fargate, announced at the same event, answered the market demand: "I don't want to worry about nodes at all," providing a serverless data plane.
💡 Related Theory: Container orchestration is fundamentally a scheduling problem for distributed systems. How do you place m jobs on n nodes? This reduces to an NP-hard multi-dimensional bin packing problem. K8s' basic scheduler solves it with heuristics combining priorityFunction and predicate filters, while Karpenter goes further by dynamically selecting node types. Theoretical background is available in Tannenbaum's Distributed Systems chapter 6.3 and Google's Borg paper (2015 EuroSys, "Large-scale cluster management at Google with Borg").
🔍 Deeper Dive: The biggest design philosophy difference between ECS and K8s is API richness. K8s has 30+ resource types — Pod, Deployment, Service, ConfigMap, Secret, Ingress, CRD, etc. — all declarative YAML. ECS ends at four concepts: Cluster, Task Definition, Service, Task. The learning curve difference translates directly to operational burden. In SAP exams, when "minimize operational burden" and "AWS-focused" keywords appear together, the answer is almost always ECS; when "portability" and "K8s standard" keywords appear, it's almost always EKS.
The initial confusion about these three services stems from Fargate not being a separate orchestrator. Fargate is a "data plane option" you can use instead of nodes, available for both ECS and EKS.
┌─────────────────────────────────────────┐
│ Control Plane │
│ ├─ ECS: AWS managed, free │
│ └─ EKS: AWS managed, $0.10/h │
└─────────────────────────────────────────┘
│
│ Task placement decision
▼
┌─────────────────────────────────────────┐
│ Data Plane — 3 options │
│ ├─ EC2 Launch Type (user manages nodes)│
│ ├─ Fargate Launch Type (serverless) │
│ └─ ECS Anywhere / EKS Anywhere (on-prem)
└─────────────────────────────────────────┘
| Dimension | ECS | EKS | Fargate |
|---|---|---|---|
| Control plane cost | Free | $0.10/h (~$73/month) | N/A (option) |
| API standard | AWS proprietary | Kubernetes (CNCF) | Depends on ECS/EKS API |
| Learning curve | Low | High (kubectl, YAML, CRD) | Same as ECS/EKS |
| Portability | AWS-dependent | Multi-cloud possible | AWS-dependent |
| Data plane options | EC2, Fargate, Anywhere | EC2 (Managed/Self), Fargate, Anywhere | (itself) |
| Spot integration | EC2 Spot, Fargate Spot | EC2 Spot, Fargate Spot, Karpenter | Fargate Spot |
| Startup time | Tens of seconds to 1 minute | Tens of seconds to 1 minute | 30-60s (including image pull) |
🎯 Scenario: "A global fintech runs AWS, on-premises, and GCP simultaneously. Container workload portability is critical—they need identical manifests deployable in any environment. The ops team wants to avoid K8s operational burdens like control plane patching and etcd backups. Which combination fits?" — EKS + Karpenter + IRSA. ECS is AWS-proprietary so portability breaks; App Runner doesn't support multi-cloud manifest compatibility. EKS is the exact intersection: K8s standard while AWS manages the control plane.
ECS requires knowing just four concepts: Cluster → Service → Task → Task Definition.
taskRoleArn), volume mounts, and logging. Similar to Docker Compose but maps to both Fargate and EC2.The key distinction is Task IAM Role (= taskRoleArn) vs. Task Execution Role (= executionRoleArn). Confusing them costs one or two exam questions.
| Role | Purpose | Used by |
|---|---|---|
| Task Execution Role | ECR image pull, CloudWatch Logs write, fetch environment variables from Secrets Manager | ECS agent (infrastructure work) |
| Task Role | Application code making AWS API calls (DynamoDB Put, S3 Get, etc.) | Application code inside Task |
⚠️ Trap: "ECS Task has S3 access permission error" usually means Task Role is missing S3 permissions. Adding S3 to Execution Role won't work (the app calls it, not the ECS agent). Conversely, "ECR image pull fails" is an Execution Role issue.
EKS is essentially managed K8s, so it uses K8s concepts directly (Pod, Deployment, Service, Ingress, ConfigMap, Secret, ServiceAccount, CRD). AWS adds four integration layers on top.
EKS' $0.10/hour is roughly $73/month per cluster, regardless of node count. "An ops team wants to spin up 100 clusters" becomes $7,300/month — not ignorable. SAP frequently features the tradeoff: "dozens of small workloads → multiple ECS clusters" vs. "unified EKS + namespace isolation."
📚 Case Study: On March 2, 2019, part of the EKS us-east-1 cluster's API Server became unresponsive. Root cause: etcd quorum loss during control plane upgrade. AWS auto-recovered, but for ~2 hours, some clusters experienced
kubectlcommand failures. The lesson: data plane (Pods on nodes) keeps running even if the control plane dies. Already-scheduled Pods continue; only new scheduling and rolling updates are blocked. Production operations can survive control plane outages in "new deployments paused, existing traffic maintained" mode. See AWS Status History.
Same ECS Service, but EC2 and Fargate Launch Types differ completely in cost, operations, and capabilities.
| Aspect | EC2 Launch Type | Fargate Launch Type |
|---|---|---|
| Node management | User (AMI patching, capacity provider, ASG) | AWS |
| Cost model | EC2 hours + EBS | vCPU-seconds + memory-seconds |
| Startup time | Fast (pre-warmed nodes) | 30-60s (micro-VM boot + image pull) |
| GPU/high-density | Possible (P, G, Inf instances) | GPU in select regions only |
| Daemon Set | Possible | Not possible (no node concept in Fargate) |
| ENI | Shared or awsvpc mode | One ENI per Task (forced) |
| Operational burden | High (patching, AMI, ASG) | Low |
| Cost efficiency | Favors steady, high-density use | Favors spiky workloads |
| Sidecar flexibility | Unlimited | Within memory/CPU limits |
🔍 Deeper Dive: Fargate boots a micro-VM each time because hardware-level isolation is required. AWS built Firecracker, its own micro-VMM (Virtual Machine Monitor). Running on KVM but providing only a minimal device model instead of full QEMU, boot time is ~125ms. The Firecracker paper (NSDI 2020 — "Firecracker: Lightweight Virtualization for Serverless Applications") is public, and the same technology powers Lambda. This isolation ensures Fargate safely runs next to other customers' containers in multi-tenant environments.
💡 Related Theory: EC2 Launch Type's cost efficiency comes from bin packing. Running 16 × 0.25 vCPU Tasks on one m5.xlarge (4 vCPU, 16GB) spreads the node cost. Fargate's Task-per-micro-VM model prevents bin packing; each Task's vCPU and memory are billed separately. "Running 1,000 × 0.25 vCPU Tasks" is vastly cheaper on EC2, but "variable + spiky" favors Fargate. The practical breakpoint: average node utilization over 40%. Consistently above 40%, EC2 + SP typically wins; below, Fargate generally wins.
AWS ECS, EKS, and Fargate in context with GCP and Azure clarifies positioning.
| Dimension | AWS | GCP | Azure |
|---|---|---|---|
| Managed K8s | EKS | GKE (Autopilot/Standard) | AKS |
| K8s control plane cost | $0.10/h | Standard free, Autopilot free | Free (Free tier) |
| Serverless containers | Fargate, App Runner | Cloud Run, GKE Autopilot | Container Apps, Container Instances |
| Proprietary orchestrator | ECS | (none) | (none) |
| On-premises extension | ECS Anywhere, EKS Anywhere | Anthos | Azure Arc, AKS HCI |
| Auto node provisioning | Karpenter (open source) | GKE Autopilot built-in | AKS Node Auto-provisioning (Preview) |
GCP's GKE Autopilot is closest to "zero operational burden," and AWS caught up with EKS Auto Mode (late 2024). Azure focused on K8s without building a proprietary orchestrator. AWS maintains ECS because part of the market finds K8s "too heavy."
📚 Case Study: In 2022, Snap (Snapchat's parent) migrated some workloads from GCP to AWS. GCP's GKE-to-EKS migration was the largest cost and time item. Manifests transferred intact, but IAM integration (Workload Identity → IRSA), Ingress (GCP Load Balancer → AWS ALB Controller), and Persistent Volume mapping (GCP PD → EBS) all had to be rewritten. K8s is a standard, but cloud integration layers aren't.
Even ECS Fargate requires "building VPC, ALB, Service, Task Definition." App Runner (GA 2021) abstracts one level higher — a PaaS. Point to a GitHub repo or ECR image, and auto build/deploy/URL provisioning completes. Think of it as Heroku for AWS.
By scenario keywords:
⚠️ Trap: "App Runner is always cheaper than ECS Fargate" is wrong. App Runner's operational cost is higher; only the operational burden is lower. High-traffic production may favor ECS Fargate + Capacity Provider.
Two frequently confused services in hybrid environments. Similar names, opposite structures.
| Aspect | ECS Anywhere | EKS Anywhere |
|---|---|---|
| Control plane location | AWS cloud | On-premises (customer infrastructure) |
| Data plane location | On-premises | On-premises |
| Internet connectivity | Required for control plane calls | Supports air-gapped (fully isolated) |
| Licensing | Billed per external instance hour | EKS Distro free + support separate |
| Use case | "Manage alongside AWS ECS" | "Operate K8s on-prem, EKS-D for consistency" |
| Comparison: ECS on Outposts | Control plane AWS, nodes Outposts (AWS hardware) | (N/A) |
🎯 Scenario: "A manufacturer operates 100 factory gateways. Some factories have internet outages spanning days; workloads must operate autonomously. Which option fits?" — EKS Anywhere. Control plane on-premises works in air-gapped environments. ECS Anywhere needs control plane calls, so internet loss halts new deployments and scaling.
🔍 Deeper Dive: EKS Anywhere internally uses EKS Distro (EKS-D), an open-source K8s distribution. AWS packages the K8s version and components (coredns, etcd, kube-proxy, CNI) validated for EKS, ensuring identical versions and behavior cloud and on-prem. This pattern mirrors GCP's Anthos (GKE on-prem). Anthos bundles the GKE-operated control plane into on-prem; EKS Anywhere keeps the control plane on-premises.
Capacity Provider abstracts "where to place this task" for an ECS Service. Three types exist:
Mix these with weight and base. Example: base=2, FARGATE weight=1, FARGATE_SPOT weight=4:
This guarantees minimal availability with 2 stable Tasks while reducing 60-70% costs via Spot for the rest. SAP's "cost efficiency + availability both" scenarios frequently feature this answer.
📚 Case Study: In 2023, Pinterest shifted some backend workloads to ECS Fargate + 80% Fargate Spot mix, reducing container infrastructure costs ~40%. They increased
STOPTIMEOUTto 60 seconds and implemented SIGTERM handlers for graceful in-flight request draining. AWS re:Invent 2023 presentation.
Operations inevitably demand "get into this container for debugging." Historically, SSH keys were embedded in nodes for docker exec, a security nightmare. ECS Exec (2021) provides SSH-free direct container shell access using SSM Session Manager as the backbone.
aws ecs execute-command \
--cluster prod \
--task <task-id> \
--container app \
--interactive \
--command "/bin/sh"Internally, the ECS Agent embeds SSM Agent, letting SSM act as an SSH replacement channel. All sessions log to CloudTrail, with optional full session storage in S3/CloudWatch Logs. Essential for audit and regulated environments.
Today's map is a single chart: Control Plane: choose ECS (AWS proprietary, free) or EKS (K8s standard, $0.10/h). Data Plane: pick EC2 (direct node management, cost advantage) / Fargate (serverless, zero ops burden) / Anywhere (on-prem). For simpler PaaS needs, App Runner sits one level higher.
Tomorrow we drill into EKS node groups, IRSA, and Karpenter. EKS spreads across domains 1–3 in SAP, with IRSA and Karpenter as frequent exam topics. How this map fills in is next.
Click a choice to reveal the answer and explanation.
Question 1
A global fintech deploys the same K8s workloads to AWS, GCP, and on-premises data centers. The operations team wants to reduce the burden of operating the cluster control plane (etcd backups, version upgrades), at least on AWS. Which combination best satisfies this requirement?
Question 2
When an ECS Task starts, pulling the image from ECR works fine, but when the application code calls S3 GetObject, AccessDenied occurs. What is the cause?
Question 3
A media startup is looking for the option with the least operational burden, where pushing a single line of code automatically builds, deploys, and assigns an HTTPS endpoint. It does not need sidecars, a service mesh, or advanced VPC integration. Which service is appropriate?
Question 4
An ECS back-office API with highly variable traffic that is nearly 0 at dawn. The company wants both partial availability guarantees and cost savings. Which Capacity Provider configuration should it use?
Question 5
A manufacturer runs container workloads on industrial gateways at 100 factories. Some factories lose internet for days at a time. The control plane must operate inside the factory. Which service is appropriate?
Question 6
A company needs EKS Pods to access S3. The operations team wants to achieve "least privilege per Pod." What is the most secure method?
Question 7
You need to connect to a shell inside an ECS container for debugging. The company security policy prohibits the use of SSH keys and requires audit logging of all sessions. What is the most appropriate method?