Busca en todas las páginas de la documentación
Kubernetes is powerful and complicated. For a large share of container workloads, most of that complexity is overhead you never wanted. AWS offers a different answer: ECS for orchestration and Fargate for serverless compute.
This page builds the mental model. It separates the two ideas people constantly conflate - the orchestrator and the launch type - and shows where ECS and Fargate sit relative to EKS, so you can decide with confidence rather than by default.
Two questions decide how your containers run on AWS, and they are independent.
The first is which orchestrator schedules and supervises your containers. ECS is one option; EKS (managed Kubernetes) is the other.
The second is what compute the containers actually run on. This is the launch type: EC2 (virtual machines in your account that you own and operate) or Fargate (serverless compute AWS provisions per task).
People say "Fargate" as if it were an alternative to ECS. It is not. Fargate is a launch type; ECS is the orchestrator that uses it. You run ECS on Fargate.
The ECS object model is small and worth memorizing.
| Object | What it is |
|---|---|
| Cluster | A logical grouping that holds your services and tasks. |
| Task Definition | A versioned blueprint: which containers, images, CPU, memory, roles, ports, env, secrets. |
| Task | A running instantiation of a task definition - one or more containers scheduled together. |
| Container | A single container inside a task, defined by a container definition. |
| Service | A controller that keeps N copies of a task running and wires them to load balancers. |
A one-off job is a task you run and let finish. A long-running server is a service that maintains a desired count and replaces anything that dies.
Listing your clusters is a good first SDK call to confirm the model is wired up.
# --- Python (boto3) ---
import boto3
ecs = boto3.client("ecs", region_name="us-east-1")
resp = ecs.list_clusters()
for arn in resp["clusterArns"]:
print(arn)// --- TypeScript (AWS SDK v3) ---
import { ECSClient, ListClustersCommand } from "@aws-sdk/client-ecs";
const ecs = new ECSClient({ region: "us-east-1" });
const resp = await ecs.send(new ListClustersCommand({}));
for (const arn of resp.clusterArns ?? []) {
console.log(arn);
}Once you separate orchestrator from launch type, the trade-offs line up cleanly.
ECS on Fargate removes servers entirely. There are no EC2 instances in your account, nothing to patch, no cluster autoscaler to tune. You declare a task's vCPU and memory, and AWS finds capacity, runs the task in its own kernel-isolated micro-VM, and bills per vCPU-second and GB-second. This is the default recommendation for most teams starting out.
ECS on EC2 keeps a fleet of instances you own in the cluster. The ECS agent on each instance reports capacity, and ECS bin-packs tasks onto them. You get access to the host, GPUs, specific instance types, and lower per-unit cost at steady high utilization - in exchange for operating the fleet.
EKS is a different orchestrator: managed Kubernetes. AWS runs the Kubernetes control plane (at an hourly cost per cluster), and you deploy with Kubernetes objects - Deployments, Pods, Services - using kubectl and the vast Kubernetes ecosystem. EKS itself can also use Fargate for its pods, which is exactly why launch type and orchestrator must be kept separate in your head.
The practical contrast between ECS and EKS:
| Dimension | ECS | EKS |
|---|---|---|
| Control plane cost | None | Hourly per cluster |
| API | AWS-specific (ECS API) | Kubernetes API |
| Learning curve | Low | High |
| Portability | AWS-only | Portable across Kubernetes |
| Ecosystem | AWS-native services | Helm, operators, CNCF tooling |
| Best for | AWS-committed teams wanting simplicity | Kubernetes expertise or multi-cloud |
The reason ECS feels lighter is that it leans on services you already use rather than reinventing them. Task IAM roles come straight from IAM. Networking in awsvpc mode gives each task its own elastic network interface and security groups, so a task is a first-class VPC citizen. Load balancing is an ALB target group. Logs go to CloudWatch via the awslogs driver. There is no separate networking layer, ingress controller, or secrets operator to install - the equivalents are AWS primitives ECS calls directly.
Cost shape differs by launch type. Fargate has no idle cost between tasks but a higher per-unit price while running, which suits spiky or low-volume workloads. EC2 launch type can be cheaper at sustained high utilization but you pay for instances whether or not tasks fill them. Fargate Spot cuts the Fargate price substantially for interruptible work, at the cost of two-minute reclaim notices.
When EKS wins is specific: you already have Kubernetes expertise, you need Helm charts or operators, you want workloads portable across clouds, or you depend on Kubernetes-native tooling like custom controllers. If none of those apply, the Kubernetes control plane is complexity you are paying for without using.
The pragmatic default for a team on AWS that just wants to ship containers: ECS on Fargate. Start there, and reach for EC2 launch type when utilization economics or host access demand it, or for EKS when you genuinely need Kubernetes.
ECS is the orchestrator that schedules and supervises containers. Fargate is a serverless launch type that provides the compute. You run ECS on Fargate; they are not competitors.
Choose ECS when you want to run containers on AWS with minimal operational overhead and no need for the Kubernetes API. Choose EKS when you need Kubernetes tooling, portability, or existing Kubernetes expertise.
No. Unlike EKS, ECS has no control-plane charge. You pay only for the underlying compute: Fargate vCPU/GB-seconds, or the EC2 instances in your cluster.
EC2 (you run the instances in the cluster) and Fargate (AWS runs the compute serverlessly). The launch type is chosen per task or service and is independent of the ECS orchestrator itself.
A task is a running instance of a task definition - one or more containers scheduled together. A service is a controller that keeps a desired number of tasks running and connects them to load balancers.
Yes. Fargate is a compute layer that both ECS and EKS can use. This is exactly why the launch type (Fargate vs EC2) and the orchestrator (ECS vs EKS) are separate decisions.
Yes. ECS is AWS-specific and does not run elsewhere. If portability across clouds matters, Kubernetes on EKS is the portable choice.
Because it removes servers entirely: no instances to patch, scale, or right-size. You declare CPU and memory per task and pay only while tasks run, which fits most workloads and teams.
Stack versions: This page was written for boto3 1.43.x (Python 3.10+) and the AWS SDK for JavaScript v3 (Node.js 18+).
Revisado por Chris St. John·Última actualización: 23 jul 2026