Amazon ECS on Fargate
Lowest-friction production container path on AWS. Deploy services without owning nodes, AMIs, or kubelets.
- Compare: Lambda vs ECS Fargate
- Compare: ECS vs EKS
Container orchestration decision tree
Which AWS Container Orchestration Should I Use?
Pick ECS Fargate, ECS on EC2, EKS, EKS Auto Mode, or App Runner by ops appetite, Kubernetes needs, and instance control — in 4 questions.
Last updated: August 5, 2026Author: FactualMinds AWS ArchitectsReviewed by: AWS Solutions Architect — Professional certified
Step 1/Choose to begin
Do you need the Kubernetes ecosystem (Helm, operators, CRDs, multi-tenancy patterns)?
If you do not need Kubernetes APIs, ECS is almost always the lower-ops path on AWS.
Recommendation
How to use this tree
Ask the Kubernetes question first. Most teams that “default to EKS” do not need Kubernetes APIs — they need containers. If you already chose EKS, prefer Auto Mode unless you have a concrete packing or operator reason to self-manage nodes.
For the broader compute catalog (Lambda, Batch, Lightsail), use the Which AWS Compute Service tree. This tree goes deeper on container orchestration only.
All possible recommendations in this tree
Reference list of every endpoint in this decision tree — useful when you want to skim before answering questions, or when JavaScript is disabled.
Amazon ECS on EC2
Container orchestration with EC2-level control. Pick when Fargate cannot meet GPU, AMI, or reserved-capacity economics.
- Compare: ECS vs EKS
ECS capacity providers (Fargate + EC2)
Run most services on Fargate and pin specialty workloads to EC2 capacity providers. Common healthy production shape.
- Compare: ECS vs EKS
Amazon EKS Auto Mode
Managed Kubernetes with AWS-operated nodes, networking, and Karpenter-style autoscaling. Default EKS path when you need K8s without a large platform team.
- Compare: ECS vs EKS
Amazon EKS + Karpenter (self-managed nodes)
EKS with Karpenter for flexible instance selection and consolidation. Choose when Auto Mode constraints conflict with your packing strategy.
- Compare: ECS vs EKS
Amazon EKS as an internal platform
Multi-tenant Kubernetes with operators, CRDs, and team namespaces. Justified when multiple product teams share one control plane.
- Compare: ECS vs EKS
AWS App Runner
Push a container or source repo; App Runner builds, deploys, scales, and serves it. Best for internal tools and early product, not complex multi-service platforms.
- Compare: Lambda vs ECS Fargate
Frequently Asked Questions
Why is ECS Fargate the default when we do not need Kubernetes?
ECS Fargate gives you container deployment, autoscaling, IAM-integrated networking, and CloudWatch logging without nodes or kubelets. EKS is more powerful but pays back its complexity only when you actually need the Kubernetes ecosystem.
Does EKS Auto Mode replace the ECS vs EKS decision?
No. Auto Mode lowers the operational tax of being on EKS — it does not make Kubernetes free. If you do not need Helm, operators, CRDs, or multi-tenancy patterns, ECS Fargate remains the simpler default.
When do GPUs force ECS on EC2 or EKS?
When inference or training needs GPU instances that Fargate does not cover for your shape, pin those services to ECS on EC2 or EKS with GPU node pools. Keep non-GPU services on Fargate where possible.
Want a deeper review than the tree?
Send us your workload requirements and we'll write back with a one-page architecture recommendation — usually within two business days.