Blog Categories

EKS vs ECS vs EKS/ECS Fargate

Yonathan Koren

Yonathan Koren

If you are researching the various container orchestration service offerings on AWS, you may have realized that EKS and ECS are your two options. You may have also seen Fargate as an option tied to each of these service offerings, i.e. “EKS Fargate” and “ECS Fargate”, which may have further complicated your understanding of the available container orchestration service offerings on AWS. In short, EKS is the managed Kubernetes service offering provided by AWS, and ECS is an AWS-specific orchestrator managed by AWS which predates EKS and is unrelated to Kubernetes, but nevertheless allows you to schedule containers and build out user-facing services out of them. Fargate is a serverless execution type for each of these services which allows you to use each service without managing the underlying EC2 instances which will perform the EKS or ECS workloads.

This essentially leads to four distinct service offerings, each with its own set of constraints and nuances. The following is a simple breakdown of these nuances which may clarify your understanding of these service offerings:

Fundamental Considerations

ConsiderationEKSEKS FargateECSECS Fargate
Container RuntimeDockerContainerd (as of Fargate 1.4)DockerContainerd (as of Fargate 1.4)
Atomic Container UnitPodPodTaskTask
Windows Container Support?Yes, with Windows EKS ClustersNoYes, with Windows ECS ClustersNo

Tool Ecosystem

ToolEKSEKS FargateECSECS Fargate
Configuration Management
  • Helm
  • Kustomize
  • Raw k8s manifests
  • CloudFormation
  • Terraform
Centralized Logging SolutionAny centralized logging solution that can be achieved on Kubernetes (for example Fluentd running as a k8s DaemonSet as part of an EFK Stack)
  • Amazon CloudWatch
  • Amazon Elasticsearch Service
  • Amazon Kinesis Data Firehose
  • AWS for Fluent Bit Outputs
Time Series Metrics
  • Any monitoring solution that can be achieved on Kubernetes (for example Grafana and Prometheus)
  • CloudWatch Prometheus Metrics via CloudWatch Container Insights
  • Any monitoring solution that can be achieved on Kubernetes without the use of DaemonSets (for example Grafana and Prometheus, but not CloudWatch Container Insights)
CloudWatch Prometheus Metrics via CloudWatch Container Insights
Integration with ECRNative integration with AWS ECR via IAM Policies
Integration with other Container Image RegistriesAuthentication with external Container Image Registries via k8s Secret objects, which are encrypted via AWS KMS

IAM and Networking

Out of Box FunctionalityEKSEKS FargateECSECS Fargate
AWS IAM
  • Cluster IAM role
  • Node IAM role
  • IAM-Role-backed Kubernetes Service Account
  • Pod execution role
  • Amazon ECS task execution IAM role
  • Amazon ECS Container Instance IAM Role
  • Amazon ECS task execution IAM role
NetworkingAmazon VPC Container Network Interface (CNI)
  • awsvpc — ENI allocated to each k8s Pod
  • awsvpc — ENI allocated to each ECS Task
  • bridge — Uses EC2 instances’ Docker host networking
  • host — Uses EC2 instance’s ENI
  • none — The task has no external network connectivity.
  • awsvpc — ENI allocated to each ECS Task

    Pricing (us-east-1 as of January 2021)

    BillableEKSEKS FargateECSECS Fargate
    Control Plane$0.10 / hour$0.10 / hourNoneNone
    CPU TimeEC2 instance pricing$0.04048 / vCPU / hourEC2 instance pricing$0.04048 / vCPU / hour
    MemoryEC2 instance pricing$0.004445 / GB / hourEC2 instance pricing$0.004445 / GB / hour

    Other Considerations

    ConsiderationEKSEKS FargateECSECS Fargate
    Control Plane SLA99.95%99.95%99.99%99.99%
    SLA Financially-backed?YesYesYesYes
    On-prem Support (AWS Outposts)?YesNoYesNo

    About The Author

    Hi, I’m Yonathan Koren. As a DevOps Specialist at Indellient, I help organizations along their DevOps journeys. In the past, I used to be an operator, and one of the themes that deeply resonates with me is the struggle developers and operators experience when they feel that they are working against each other. My goal is to help organizations achieve their business goals by adopting workflows that promote productivity, autonomy, and collaboration. I am a certified HashiCorp practitioner, working closely with the HashiCorp suite. I have also given talks alongside Chef and HashiCorp regarding the importance of consistent, composable packaging of organizations’ applications using Chef Habitat, which allows them to deploy to VMs, bare metal, Nomad, or Kubernetes using a single artifact.