ECS and EKS orchestrate containers, Fargate runs them. Choose the orchestrator and the compute separately to avoid paying for capability you never use.

Running Containers on AWS: Choosing Between ECS, EKS, and Fargate

A team debates ECS or EKS or Fargate for weeks, then puts every service on EKS. Months later, cluster upgrades and control-plane charges consume effort for services that never used a Kubernetes feature.

WHAT

Amazon ECS and Amazon EKS orchestrate containers, while AWS Fargate provides serverless compute for ECS tasks and compatible EKS Pods without requiring direct management of EC2 worker instances.

• ECS: AWS-native orchestration where the unit of deployment is a task, maintained at a desired count by a service. There is no separate ECS control-plane charge, so costs depend on task compute and the surrounding infrastructure.
• EKS: Managed Kubernetes where workloads run as Pods inside a cluster. Each cluster has a control-plane charge, making cluster count a cost driver alongside compute and supporting services.
• Fargate: Provides compute for ECS tasks and compatible EKS Pods. ECS or Kubernetes scheduling determines the desired workload count and replaces failed workloads, while Fargate provisions the compute capacity.

WHERE

Each option fits different workloads, depending on the orchestration features required and who manages the compute.

• ECS: Runs stateless HTTP APIs behind an Application Load Balancer, queue-driven workers that scale on queue depth, and scheduled or batch jobs launched as one-off tasks.
• EKS: Hosts platforms that depend on Kubernetes APIs, custom controllers, operators, Helm charts, or existing Kubernetes manifests.
• Fargate: Provides compute for tasks or Pods that do not require host-level control, making it useful for smaller services, variable workloads, and short-lived batch jobs.

WHY

Each option removes a different operational burden. ECS avoids a separate Kubernetes control plane and Kubernetes-specific upgrade cycles. EKS preserves access to Kubernetes tooling. Fargate removes the need to manage EC2 worker hosts and node capacity.

Each also adds a trade-off. ECS task definitions and service features are AWS-specific, so workloads built on Kubernetes tooling need rework before they can run on it. EKS adds a per-cluster charge and an upgrade cycle the team still owns, which only a real Kubernetes requirement justifies.

Fargate bills for the vCPU and memory allocated while workloads run, so quiet periods keep a baseline cost and fixed size combinations can leave unused capacity. It also rules out privileged containers, GPUs, and DaemonSets, and steady high-utilization workloads deserve a comparison against EC2-backed capacity.

Reducing operational work does not guarantee a smaller bill, since orchestrator choice, cluster count, and compute pricing all shape the total.

WHEN

Deploy ECS, EKS, or Fargate when:

• ECS: Services are stateless or queue-driven, no requirement depends on Kubernetes APIs, and the team wants AWS-native orchestration with a simpler operating model.
• EKS: A concrete requirement exists for Kubernetes APIs, operators, custom controllers, or existing manifests, and the team can manage the cluster upgrade cycle.
• Fargate: The team wants to avoid managing EC2 hosts and node capacity, and workloads fit the supported CPU, memory, networking, and storage configurations.

HOW

Scenario: An application has a catalog API, a cart API, an order worker that processes SQS messages, and a recommendation service that depends on a Kubernetes operator.

The obvious design puts all four services on EKS. That is a valid choice when the team already runs Kubernetes and expects more services to need it, but here the catalog API, cart API, and order worker inherit the cluster operating model, upgrade cycle, and control-plane charge without using any Kubernetes feature. If the cluster uses EC2-backed nodes, the team also owns worker-node capacity.

The improved design splits by requirement. ECS runs the three conventional services on Fargate, and EKS hosts only the recommendation service, on Fargate Pods if the operator is compatible and on EC2-backed nodes if it is not. The cost is two orchestration platforms to operate, with Kubernetes limited to the one workload that needs it.

NAIVE
EKS cluster
  |- catalog API
  |- cart API
  |- order worker
  |- recommendation service (operator)
  Compute: Fargate Pods or EC2-backed nodes

IMPROVED
ECS: catalog API ----> Fargate tasks
ECS: cart API -------> Fargate tasks
ECS: order worker ---> Fargate tasks <- SQS messages
EKS: recommendation -> Fargate Pods (or EC2-backed nodes if the operator needs them)

FAILURE PATH: bad ECS release -> deployment circuit breaker -> rollback
FAILURE PATH: task or Pod exits -> ECS or Kubernetes scheduler launches a replacement
MONITORING: running vs desired tasks and Pods, deployment failures, queue depth

1. ECS runs the catalog API and cart API, and each service keeps its desired task count.
2. ECS runs the order worker, and a configured maximum caps how far it scales with queue depth.
3. EKS runs the recommendation service because the operator depends on the Kubernetes API.
4. Fargate provides compute for every ECS task and for each compatible EKS Pod.
5. The ECS scheduler and the Kubernetes scheduler each replace failed workloads and maintain the desired count.
6. ECS deployments use the circuit breaker, which stops a release that never stabilizes and rolls back to the previous version when one exists.

Running two orchestrators adds a second operating model and keeps the EKS control-plane charge for one cluster. That cost buys ECS simplicity for the conventional services and Kubernetes capability only where it is needed.

TAKEAWAY

Choose the orchestrator and the compute separately: ECS for AWS-native simplicity, EKS only for a real Kubernetes requirement, and Fargate when skipping node management is worth the compute pricing.