ECS Fargate VS EKS Fargate

Fargate is one compute engine, but the experience of using it differs depending on which orchestrator schedules onto it. This page compares Fargate under Amazon ECS with Fargate under Amazon EKS on architecture, configuration, features, limitations and cost. The engine’s own behaviour — task sizing, storage, pricing shape — is covered in Fargate.

Architecture and management

ECS with Fargate uses AWS’s own scheduler and its task and service definitions. It is the shorter path for an AWS-native application, with less to configure and tighter integration with the surrounding AWS services.

EKS with Fargate uses Kubernetes concepts and standard manifests. It is more to learn and operate, and it buys flexibility and portability: the same manifests run on any conformant Kubernetes. Pods land on Fargate by matching a Fargate profile’s namespace and label selectors.

Configuration

An ECS task definition:

{
  "family": "sample-app",
  "cpu": "256",
  "memory": "512",
  "containerDefinitions": [{
    "name": "web-app",
    "image": "nginx:latest",
    "portMappings": [{
      "containerPort": 80,
      "protocol": "tcp"
    }]
  }],
  "requiresCompatibilities": ["FARGATE"],
  "networkMode": "awsvpc"
}

The equivalent Kubernetes Deployment:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: sample-app
spec:
  replicas: 3
  template:
    spec:
      containers:
      - name: web-app
        image: nginx:latest
        resources:
          requests:
            memory: "512Mi"
            cpu: "250m"
        ports:
        - containerPort: 80

Note that Fargate sizes an EKS pod by rounding the sum of its containers’ requests up to the nearest supported CPU/memory combination, plus a small reservation for the Kubernetes components. Requests that are slightly over a boundary cost a whole tier.

Features

ECS with Fargate: faster task start-up; service discovery through AWS Cloud Map or ECS Service Connect; direct ALB and NLB target group registration; IAM roles per task; native CloudWatch and Container Insights; Fargate Spot for interruptible work; less container-level customisation, and AWS-specific tooling.

EKS with Fargate: the full Kubernetes API and object model; multi-container pods with shared volumes and lifecycle; Kubernetes RBAC alongside EKS Pod Identity or IRSA; the standard Kubernetes tooling and monitoring ecosystem; service mesh options; portability to other Kubernetes environments.

Limitations

ECS with Fargate

• AWS-specific — no portability
• No host access, no privileged containers
• Fixed CPU and memory combinations, from 0.25 vCPU / 512 MiB up to 16 vCPU / 120 GiB, plus 32 vCPU at 60, 120 or 244 GiB
• No GPUs or other accelerators

EKS with Fargate

• No DaemonSets — a daemon has to become a sidecar in every pod
• No privileged containers, and no HostPort or HostNetwork
• No GPUs, no Inferentia, no Arm/Graviton, no Windows containers, no Bottlerocket
• Persistent volumes through Amazon EFS only, and static provisioning only — no dynamic provisioning. The EFS CSI driver is pre-installed, so pods mount EFS without a driver install. Amazon EBS and FSx for Lustre cannot be mounted.
• 20 GiB of ephemeral storage per pod by default, raisable to 175 GiB with an ephemeral-storage request; the pulled container image shares it
• Private subnets only; the cluster VPC must have them with NAT access
• The EC2 Instance Metadata Service is not available to pods — use IRSA or Pod Identity for credentials, and put Region and Availability Zone in the pod spec if the workload needs them
• No Fargate Spot
• Not available in every EKS Region; not available on AWS Outposts, Local Zones or Wavelength
• Version rollback is not supported for Fargate nodes

The claim that EKS Fargate has no persistent volume support is long out of date — EFS has been mountable since 2020. The real constraint is the absence of dynamic provisioning, which means the file system has to exist before the PersistentVolume references it.

Cost

ECS with Fargate has no control-plane charge. You pay only for the vCPU and memory allocated to tasks, plus data transfer and any load balancer.

EKS with Fargate adds the EKS cluster charge on top — $0.10 per cluster-hour on a supported Kubernetes version, $0.60 once the version enters extended support. Check current figures on the EKS pricing page. On a handful of pods the cluster fee can exceed the compute; across a large multi-tenant cluster it disappears into the noise. It is the main argument against running a cluster per team or per environment.

ECS Fargate also has Fargate Spot, at a substantial discount for interruptible tasks. EKS does not.

Integration

Both support VPC networking, IAM, CloudWatch, Elastic Load Balancing and auto scaling.

ECS integrates more directly with AWS CloudFormation, AWS Cloud Map and ECS Service Connect. EKS brings Kubernetes-native service mesh options, the standard Kubernetes tooling chain, and broader third-party support.

Choosing

Choose ECS with Fargate for AWS-native applications, straightforward microservices, teams new to containers, and small to medium estates where the EKS cluster fee and operational surface are not worth paying.

Choose EKS with Fargate where Kubernetes is already the standard, where the workload needs specific ecosystem components, where multi-cloud portability is a genuine requirement, or where an existing Kubernetes deployment is being migrated. Check the limitations list first — no DaemonSets and no dynamic volume provisioning rule out more workloads than teams expect, and a mixed cluster with some managed nodes alongside Fargate profiles is often the practical answer.