Amazon EKS — Fargate Limitations

1 minute read

Fargate Limitations

Fargate is powerful but has significant limitations you must understand before choosing it. These aren’t bugs — they’re inherent to the serverless model.


What You Can’t Do on Fargate

Limitation Why Workaround
No DaemonSets No persistent nodes to run them on Use sidecar containers
No privileged containers Security isolation model prevents it Use EC2 nodes
No GPUs Fargate doesn’t support GPU instances Use EC2 GPU node groups
Max 4 vCPU, 30 GB memory per pod Fargate resource limits Split into multiple pods
No EBS volumes No persistent block storage Use EFS (shared storage)
No hostNetwork No host networking Use VPC CNI
No hostPort No port mapping to host Use Services
Slower pod startup microVM boot time ~30-60 seconds Pre-warm with dummy pods
No SSH to “node” No underlying EC2 to access Use kubectl exec

Storage on Fargate

Fargate pods get 20 GB ephemeral storage by default (configurable up to 200 GB). For persistent storage:

# Use EFS (the only persistent storage option on Fargate)
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: efs-claim
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: efs-sc
  resources:
    requests:
      storage: 5Gi

Key limitation: No EBS volumes on Fargate. If you need block storage (databases, etc.), use EC2 nodes.


DaemonSet Alternatives

Since DaemonSets don’t work on Fargate, use sidecars:

# Instead of a Fluent Bit DaemonSet, add it as a sidecar
containers:
  - name: app
    image: my-app:latest
  - name: fluent-bit
    image: fluent/fluent-bit:latest
    volumeMounts:
      - name: logs
        mountPath: /var/log

Decision Matrix

Requirement Fargate OK?
Stateless web app ✅ Yes
Batch processing ✅ Yes
DaemonSets needed ❌ No
GPU workloads ❌ No
EBS storage ❌ No
Privileged containers ❌ No
Fast pod startup (<5s) ❌ No (30-60s)

What’s Next?

Understand the costs: Fargate Pricing.