ECS vs EKS vs Fargate: $73/Mo Fee vs $0 [2026]

Every AWS team building containerized services eventually hits the same fork in the road: Amazon ECS, Amazon EKS, or AWS Fargate. The question gets confusing fast because Fargate is not actually a competitor to ECS or EKS, it is a compute layer that plugs into either one. The real decision is whether to run AWS’s own orchestrator (ECS) or a managed Kubernetes control plane (EKS), and then whether to run that orchestrator on EC2 instances you manage or on Fargate’s serverless capacity. In October 2026, with EKS charging a flat $0.10 per cluster-hour and Fargate billing $0.04048 per vCPU-hour, the cost and complexity trade-offs between these paths have become sharper, not simpler.

It ends with a migration guide and a verdict backed by the numbers, not vendor marketing. For broader context on how these container services fit into AWS’s wider platform, see our cloud computing coverage.

·

Google · Preferred Sources

Don't miss new tech stories on Google

Add Shattered once in the Google app and our stories show up in your news suggestions.

Add now

What ECS, EKS, and Fargate Actually Are

The confusion around ECS vs EKS vs Fargate usually comes from treating all three as interchangeable “container platforms.” They are not peers. ECS and EKS are orchestrators, they decide what runs where, how services scale, and how deployments roll out. Fargate is a compute mode that either orchestrator can call on instead of EC2 instances. Understanding that split is the first step to picking the right combination.

Amazon ECS: AWS-native orchestration

Amazon Elastic Container Service is AWS’s own orchestrator, built around task definitions, services, and clusters rather than Kubernetes objects. There is no separate orchestration charge for ECS, AWS states plainly that “there is no additional charge for Amazon ECS orchestration. You pay only for the underlying compute and resources,” according to AWS pricing documentation cited in a September 2026 migration analysis from engineering platform Qovery. That makes ECS attractive for teams that want container orchestration without taking on a Kubernetes control-plane bill or a Kubernetes learning curve. ECS tasks can run on self-managed EC2 instances or on Fargate, and AWS has steadily added capabilities like ECS Service Connect and container fleets at general availability to close the gap with Kubernetes-native tooling.

Amazon EKS: managed Kubernetes on AWS

Amazon Elastic Kubernetes Service is a managed Kubernetes control plane. AWS runs and patches the Kubernetes API server, etcd, and scheduler; customers bring worker capacity through EC2 node groups, Karpenter-provisioned nodes, or Fargate. The appeal of EKS is portability and ecosystem depth, Helm charts, custom resource definitions, service meshes, and the enormous catalog of Kubernetes-native tooling all work on EKS roughly the way they would on any other conformant Kubernetes cluster. The cost of that portability is complexity: RBAC, admission controllers, CNI networking, storage classes, and version upgrade cycles all become the operator’s responsibility to some degree, even on a managed control plane.

AWS Fargate: the serverless compute layer

AWS Fargate is not an orchestrator at all. It is a serverless compute engine that removes the need to provision, patch, or scale EC2 instances for container workloads. ECS or Kubernetes still decides scheduling and desired state; Fargate simply supplies isolated compute capacity on demand. Billing is based on the vCPU, memory, and ephemeral storage a task or pod requests, measured from image-pull start to termination and rounded to the nearest second with a one-minute minimum, according to AWS’s Fargate FAQ page. Fargate works underneath both ECS (as the “Fargate launch type”) and EKS (as a supported compute option for eligible pods), which is why framing this as a clean three-way fight is slightly misleading, it is really a two-axis decision: orchestrator (ECS or Kubernetes/EKS) times compute mode (EC2 or Fargate).

ECS vs EKS vs Fargate at a Glance: The Comparison Table

The table below lines up the three options across the dimensions that matter most for an architecture decision in late 2026, cost model, control-plane ownership, ecosystem, and operational overhead.

Dimension	Amazon ECS (EC2)	Amazon EKS (EC2)	Fargate (ECS or EKS)
Orchestration API	AWS-native (task definitions, services)	Kubernetes API	Depends on parent (ECS or EKS)
Control-plane fee	$0 (no ECS orchestration charge)	$0.10/hr standard, $0.60/hr extended support	No separate control-plane fee; inherits parent’s
Compute billing	EC2 instance-hours, shared across tasks	EC2 instance-hours, shared across pods	Per-task/pod vCPU-hour + GB-hour
Node management	Customer-managed (patching, AMIs, scaling)	Customer-managed, or Karpenter-automated	None: AWS manages the host
Bin-packing economics	Yes, multiple tasks per instance	Yes, multiple pods per node	No, each task/pod billed independently
Ecosystem/portability	AWS-only, smaller ecosystem	Full Kubernetes ecosystem, more portable	Constrained by Fargate platform limits
DaemonSets/privileged containers	N/A (not a Kubernetes concept)	Supported on EC2 nodes	Not supported on Fargate (EKS)
GPU support	Yes, via GPU-enabled EC2 instances	Yes, via GPU-enabled EC2 instances	Not supported
Max ephemeral storage	N/A	N/A	200 GiB (ECS Fargate), 175 GiB (EKS Fargate)
Typical cold start	Fast when spare capacity exists	Slower; adds scheduling/admission overhead	20–60 seconds for a moderate image, 10–15s cached
Learning curve	Low to moderate	Moderate to high	Low (abstracts away host management)
Best suited for	AWS-native teams, simpler microservices	Multi-cloud/portability needs, large platform teams	Bursty, isolated, or ops-light workloads

2026 Pricing Breakdown: Control-Plane Fees, vCPU Rates, and Hidden Costs

Pricing is where the ECS vs EKS vs Fargate debate gets concrete. As of October 2026, AWS’s published list prices for US East (N. Virginia) break down as follows.

Cost component	Rate (US East, N. Virginia)	Monthly equivalent (730 hrs)
EKS cluster, standard support	$0.10 per cluster-hour	≈ $73.00 per cluster
EKS cluster, extended support	$0.60 per cluster-hour	≈ $438.00 per cluster
ECS orchestration fee	$0: no separate charge	$0
Fargate (Linux/x86) vCPU-hour	$0.04048	≈ $29.55 per vCPU
Fargate (Linux/x86) GB-hour	$0.004446	≈ $3.25 per GB
Fargate (Arm/Graviton) vCPU-hour	$0.03238	≈ $23.64 per vCPU
Fargate (Arm/Graviton) GB-hour	$0.00356	≈ $2.60 per GB
Example: 1 vCPU + 2GB task, 24/7 (x86)	–	≈ $36.04 per month
Example: 1 vCPU + 2GB task, 24/7 (Arm)	–	≈ $28.84 per month
Free Fargate ephemeral storage	20 GB included per task	$0 up to 20 GB

Those numbers, drawn from AWS’s own Fargate FAQ and ECS pricing pages, tell a consistent story: Fargate’s premium is real, and it compounds. Running the same 1 vCPU / 2GB workload on EC2 instead, where multiple tasks can share a single instance, is routinely cheaper at scale because the customer controls the bin-packing. A September 2026 Qovery analysis of migrating microservices to Fargate or EKS concluded that EKS “gives you full control and cheaper steady-state compute” while Fargate “removes node management but costs more per vCPU and per GB.” That tradeoff, pay more per unit of compute to stop managing hosts, is the central economic question in this whole comparison, and it does not change whether the orchestrator on top is ECS or EKS.

The EC2 launch type avoids both the Fargate premium and the EKS cluster-hour fee, but it reintroduces instance-level cost management: Savings Plans, Spot capacity, EBS volumes, NAT gateway charges, and data transfer all stack on top of raw compute. Our breakdown of AWS EC2 pricing across on-demand, Spot, and reserved models covers how those EC2-side costs shift depending on commitment length, which matters just as much for ECS-on-EC2 and EKS-on-EC2 bills as it does for any other EC2 workload.

One nuance that is easy to miss: the EKS cluster-hour fee is charged even for a cluster running nothing. A nearly-idle EKS cluster used for a side project or a staging environment still accrues $73 a month in pure control-plane cost before a single pod runs, which is one reason some teams keep EKS reserved for clusters with meaningful, sustained workloads and use ECS for smaller or more occasional services.

Performance and Benchmarks: Cold Starts, Task Startup, and Scaling

Startup latency is where theoretical architecture diagrams meet operational reality, and the available 2026 data points in different directions depending on configuration.

An independent 2026 analysis from Vylara’s container cold-start comparison put typical Fargate cold-task startup at 20 to 60 seconds for a moderate-sized image, dropping to 10 to 15 seconds once images are cached locally and health checks are tuned aggressively. That range applies whether the Fargate task is scheduled by ECS or by EKS, since the bottleneck is largely image pull, ENI provisioning, and container entrypoint time rather than which orchestrator issued the scheduling decision.

A separate, more aggressive result comes from a documented engineering optimization case published on Dev.to in April 2026: after a three-week focused effort, the team reduced ECS cold starts from 5.2 seconds to 480 milliseconds, a 91% improvement, while also cutting monthly ECS spending by 42%, according to the published case study. That is a single team’s result rather than a controlled ECS-versus-EKS benchmark, and it should be read as evidence of what careful image optimization and capacity tuning can achieve on ECS specifically, not as a universal platform latency figure.

A third data point comes from a re:Invent 2025 session recap covering Qube Research & Technologies, a case discussed in the Qovery migration guide and separately detailed in a conference writeup, which described scaling from a handful of services to tens of thousands using a multi-account, multi-cluster architecture with CloudWatch and OpenTelemetry Collector observability. The presentation focused on operating Fargate and ECS Managed Instances at very large scale rather than publishing a single startup-time figure, but it reinforces the pattern across all three sources: startup and scaling performance on AWS container platforms is overwhelmingly a function of image size, capacity planning, and operational tuning, not an inherent property of “ECS” versus “EKS” as labels.

Put in plain operational terms: ECS task startup skips Kubernetes scheduling and admission-controller layers entirely, which removes one source of latency. EKS startup can add Kubernetes scheduler cycles, CNI IP allocation, admission webhooks, and controller reconciliation on top of the same image-pull and ENI work. Whether that difference is noticeable in practice depends heavily on cluster configuration, a well-tuned EKS cluster with pre-warmed node groups can out-respond a cold ECS-on-EC2 deployment that has to wait for new instances to launch.

Autoscaling Mechanics: HPA, Cluster Autoscaler, Karpenter, and ECS Capacity Providers

Scaling speed depends on which autoscaling layer is doing the work, and ECS and EKS use almost entirely different toolchains to get there. On the ECS side, Service Auto Scaling adjusts the desired task count based on CloudWatch metrics such as CPU or memory utilization, while capacity providers decide whether those new tasks land on existing EC2 capacity, newly launched EC2 instances, or Fargate. The capacity provider layer is what determines whether a scale-out event is near-instant (spare EC2 capacity or Fargate) or slow (new EC2 instances that need to launch and bootstrap first).

EKS stacks more layers on top of the same underlying problem. The Horizontal Pod Autoscaler (HPA) adjusts replica counts based on metrics, much like ECS Service Auto Scaling. But getting those new pods actual compute to run on requires either the older Cluster Autoscaler, which adds EC2 nodes to existing node groups, or Karpenter, which AWS and the broader Kubernetes community have increasingly standardized on since it provisions right-sized nodes directly rather than scaling pre-defined node groups. Danone’s EKS Auto Mode migration, which lifted node utilization into the 80–90% range, is a direct example of Karpenter-style provisioning outperforming static node-group scaling once it is tuned correctly.

The practical difference shows up during traffic spikes. ECS capacity providers and EKS’s HPA-plus-Karpenter combination can both react within seconds if Fargate or available EC2 capacity is already in the pool, but both are equally slow if a scale-out event requires launching brand-new EC2 instances from zero, since instance boot, bootstrap scripts, and registration with the orchestrator all add latency regardless of which orchestrator is waiting on that capacity. Neither ECS nor EKS has a structural advantage here once Fargate is removed from the equation; the determining factor is almost always how much spare capacity a team is willing to pay to keep warm versus how much scale-out latency it is willing to tolerate.

One EKS-specific wrinkle worth flagging: HPA, the Cluster Autoscaler or Karpenter, pod disruption budgets, and topology spread constraints can interact in non-obvious ways, especially under aggressive scale-down. A pod disruption budget set too conservatively can block Karpenter from consolidating underutilized nodes, silently inflating a bill that looks like a Karpenter problem but is actually a disruption-budget misconfiguration. ECS has no equivalent multi-layer interaction to debug, which is part of why teams without dedicated platform engineers tend to find ECS’s autoscaling model easier to reason about under pressure.

Control-Plane and Capacity Limits: What to Check Before You Commit

One honest gap in most ECS-vs-EKS comparisons, this one included, is that neither AWS’s documentation nor independent benchmarks publish a single universal number for maximum nodes per EKS cluster, maximum pods per cluster, or maximum ECS tasks per cluster that holds true across every account. These limits are governed by AWS Service Quotas, and they vary by account history, region, and whether a team has already requested increases for related services like EC2 instance limits or VPC IP address space.

What is consistent is the underlying mechanism: Fargate capacity specifically is gated by a regional, account-level vCPU quota, meaning a sudden burst of Fargate tasks can hit a wall that has nothing to do with ECS or EKS scheduling logic and everything to do with an un-raised quota sitting in the AWS Service Quotas console. Teams planning for a traffic spike, a product launch, or a seasonal peak should check their current Fargate vCPU quota and their EC2 instance limits in the target region well before the event, since quota increase requests are not always approved instantly.

On the EKS side, cluster-level limits interact with VPC networking more than with Kubernetes itself in practice. The VPC CNI allocates IP addresses per pod from the cluster’s subnets, so a cluster that looks like it should support thousands of pods on paper can run out of usable IP addresses first if the VPC was not sized with pod density in mind. This is a frequent, avoidable cause of EKS scaling problems that has nothing to do with Kubernetes’ own control-plane limits and everything to do with subnet planning done before the cluster was ever created. Anyone sizing a new EKS cluster for meaningful scale should check the current Amazon EKS and VPC CNI documentation for IP allocation modes (including prefix delegation, which increases IPs per node) rather than assuming default networking will scale linearly with node count.

Real-World Case Studies: ECS, EKS, and Fargate in Production

Published AWS case studies give a clearer picture of production outcomes than any synthetic benchmark. The table below summarizes eight named companies running ECS, EKS, or Fargate in production, with the specific results each has reported.

Company	Platform	Reported result
Flywire	ECS + Fargate	Scaled from 3 to 150 services; cut compute costs up to 70%; Fargate Spot cut dev-environment costs 70%; deployment speed up 60%
Nintendo Systems	ECS + Fargate	Scaled ECS to 120 tasks on a major game launch day; digital content sales grew 10x from 2017 to 2023
Vanguard	ECS + Fargate	Runs 850+ production applications; Fargate footprint grew ~275% since May 2020; speed to market improved from 3 months to 24 hours
BILL	ECS + Fargate	Handles 150,000–200,000 requests per minute with automatic scaling; new environments now take weeks instead of months
Hootsuite	EKS	Runs 700+ services; cut EC2 footprint from 2,000+ to under 500 instances; cut EC2 costs ~40%; cut SEV1/SEV2 incidents 57%
ITV	EKS	Moved 75% of its Common Platform to EKS; Spot Instances cut costs up to 60%, saving $150,000 in one year; deploys in as little as 4 minutes
Delhivery	EKS (with G5 nodes)	Serves up to 8,000 requests/minute at 160ms latency; cut monthly model-serving costs ~80%
Danone	EKS Auto Mode	Migrated its EKS fleet to Auto Mode over ~9 months; reclaimed 20%+ of platform-engineering capacity; Karpenter lifted node utilization to 80–90%

Two patterns stand out. First, every ECS/Fargate example here leans on the combination specifically for operational simplification, removing patching, provisioning, and environment-setup toil rather than chasing raw compute efficiency. Flywire’s 60% faster deployment pipeline and BILL’s drop from months to weeks for new environments are both about engineering velocity, not about shaving milliseconds off a cold start. Second, every EKS example leans on scale and portability: Hootsuite’s move off more than 2,000 EC2 instances and ITV’s four-minute deploys both depend on Kubernetes-native tooling (Karpenter, Spot-aware scheduling, CI/CD integrations) that would require more custom engineering to replicate on ECS alone.

It is worth being precise about what these numbers do and do not prove. They are self-reported outcomes published as AWS case studies, not independently audited benchmarks, and none of them isolate the orchestrator choice from everything else that changed during each company’s migration, such as new CI/CD pipelines or new monitoring. Still, the consistency of the savings, generally 30% to 70% in compute or operational cost, across companies of very different sizes and industries is a reasonable signal that both paths can deliver real efficiency gains when the migration is executed deliberately.

What the Adoption Data Shows

Direct, current survey data on ECS-versus-EKS adoption specifically for 2026 is harder to come by than pricing or case-study numbers, but the historical trendline from AWS’s own research and from the Cloud Native Computing Foundation is useful context for how the market arrived at today’s split. AWS reported that “in 2019, 52% of surveyed organizations used Amazon EKS on EC2 for container workloads,” according to Amazon Web Services’ 2019 Container Security Survey, compared with 44% using ECS on EC2 that same year, an early signal that Kubernetes adoption on AWS was already outpacing ECS even before EKS matured into its current feature set.

Fargate’s adoption curve, separately, climbed fast in its early years. Datadog’s 2020 container report found that “in 2020, 32% of organizations running containers in AWS used AWS Fargate, up from 19% in 2019 and 6% in 2018,” a trajectory documented on Datadog’s container report page. That kind of year-over-year doubling is consistent with Fargate’s value proposition landing with teams that wanted container benefits without taking on infrastructure management.

By 2021, the Cloud Native Computing Foundation’s annual survey found the ECS-versus-EKS gap had narrowed to roughly a dead heat: “in 2021, 33% of developers using orchestration technologies used Amazon ECS, while 30% used Amazon EKS,” per the Cloud Native Computing Foundation’s 2021 Annual Survey, which cited underlying SlashData research. A separate CNCF figure from the same survey cycle found that Fargate usage among ECS users had risen to nearly 40% in 2021, up from around 35% in 2020, suggesting that even among teams committed to ECS specifically, the serverless Fargate compute mode was becoming the default rather than the exception.

These figures are five to seven years old and should not be mistaken for a current snapshot of 2026 usage, AWS has not published an equivalent survey more recently covering ECS, EKS, and Fargate adoption specifically. But the trend they establish, EKS and ECS converging toward comparable adoption and Fargate becoming the default compute mode for a large share of ECS users, lines up with what the 2025-2026 case studies above show in practice: companies picking whichever orchestrator fits their team’s skills, then defaulting to Fargate unless steady-state cost pressure pushes them back to EC2.

Amazon ECS: Pros and Cons

• Pro: No separate orchestration fee, you pay only for compute and supporting resources.
• Pro: Lower learning curve than Kubernetes; task definitions and services map closely to how most teams already think about deploying containers.
• Pro: Deep native integration with IAM, CloudWatch, ALB/NLB, and other AWS services without extra controllers or operators.
• Pro: Container fleets now at general availability, plus ECS Service Connect, narrow the feature gap with Kubernetes-native service discovery.
• Con: AWS-specific model, task definitions, capacity providers, and IAM task roles do not port to another cloud.
• Con: Smaller third-party ecosystem; fewer operators, controllers, and marketplace integrations than Kubernetes.
• Con: Choosing the EC2 launch type still means patching, AMI management, and capacity planning, ECS does not eliminate node operations by itself.

Amazon EKS: Pros and Cons

• Pro: Full Kubernetes API compatibility, Helm charts, CRDs, service meshes, and the broader Kubernetes ecosystem work largely as-is.
• Pro: Stronger multi-cloud and hybrid portability in principle, since Kubernetes manifests can target other Kubernetes environments.
• Pro: Karpenter and EKS Auto Mode can push node utilization into the 80–90% range, as Danone’s migration demonstrated, reducing wasted compute.
• Con: A flat $0.10/hour (≈$73/month) control-plane fee applies per cluster, even to clusters doing very little, $0.60/hour for extended Kubernetes-version support.
• Con: Meaningfully higher operational complexity: RBAC, admission control, CNI networking, storage classes, and upgrade cadences all need ongoing attention.
• Con: Kubernetes version support windows create upgrade pressure; our coverage of Kubernetes 1.34’s end-of-life timeline shows how quickly unsupported versions accumulate CVE exposure if upgrades slip.
• Con: Practical cloud coupling persists even though Kubernetes is nominally portable, IAM, load balancer controllers, and storage integrations are AWS-specific in practice.

AWS Fargate: Pros and Cons

• Pro: Zero node management, no patching, no AMI pipeline, no capacity planning for hosts.
• Pro: Pay-per-task billing rounds to the second with a one-minute minimum, which suits bursty or short-lived workloads well.
• Pro: Works under both ECS and EKS, so teams are not locked into a single orchestrator by choosing Fargate.
• Pro: Arm/Graviton pricing (about $0.03238/vCPU-hour) runs roughly 20% cheaper than x86 for workloads that can run on Arm.
• Con: Generally more expensive than EC2 for continuously running, steady-state workloads, since each task is billed independently with no customer-controlled bin-packing.
• Con: On EKS specifically, Fargate pods cannot use DaemonSets, privileged containers, GPUs, or EBS volumes, a real constraint for ML inference or node-level agents.
• Con: Cold starts of 20–60 seconds for uncached images can be noticeable for latency-sensitive, rarely-invoked services.
• Con: Capacity is governed by regional/account vCPU quotas, which can require an AWS support request to raise for large bursts.

5 Use Cases: Matching the Right Platform to Your Workload

Rather than a single universal winner, the ECS-vs-EKS-vs-Fargate decision tends to resolve cleanly once you know the shape of the workload.

• Small-to-midsize teams standardizing on AWS: ECS on Fargate removes both the Kubernetes learning curve and the EC2 management burden, at the cost of a higher per-task compute price. This is the path Flywire and BILL both took to simplify operations rather than to chase the lowest possible compute bill.
• Platform teams with multi-cloud or hybrid ambitions: EKS is the only one of the three built on a portable API. Even if a workload runs only on AWS today, EKS keeps the door open to GKE, AKS, or on-prem Kubernetes later without a rewrite of deployment manifests.
• Bursty, event-driven, or batch workloads: Fargate’s per-second billing and zero node management fit spiky traffic well, paying for 10 minutes of compute 50 times a day beats keeping an EC2 instance warm around the clock, especially for workloads that don’t run continuously.
• Large-scale, cost-sensitive, steady-state services: ECS or EKS on EC2, ideally with Karpenter or Spot capacity, wins on raw unit economics because tasks or pods can be packed densely onto fewer, better-utilized instances, the pattern behind Hootsuite’s EC2 footprint reduction and ITV’s Spot savings.
• GPU-backed ML inference or model serving: EKS on EC2 (not Fargate, which excludes GPUs entirely) is close to mandatory. Delhivery’s G5-backed EKS deployment, serving thousands of requests per minute at 160ms latency, is a representative pattern for teams in this category.

Migration Guide: Moving Between ECS, EKS, and Fargate

Most migrations in this space move in one of two directions: ECS-on-EC2 to ECS-on-Fargate, to shed node management, or ECS to EKS, to gain Kubernetes portability. Both follow a broadly similar sequence.

Moving from ECS on EC2 to ECS on Fargate

1. Audit existing task definitions for host-level dependencies, such as privileged mode, host networking, or custom kernel modules, that Fargate does not support.
2. Right-size CPU and memory requests against Fargate’s fixed task-size matrix (0.25 vCPU supports 0.5–2GB; 1 vCPU supports 2–8GB, and so on upward).
3. Update the task definition’s requiresCompatibilities field to FARGATE and set networkMode to awsvpc, which Fargate requires.
4. Move any host-mounted volumes to Fargate’s ephemeral storage (20GB free, expandable to 200GB) or to EFS for persistence.
5. Shift a small percentage of traffic to Fargate tasks first, watching cold-start and cost metrics, before cutting over fully.
6. Decommission the EC2 capacity provider once Fargate tasks are stable and fully absorbing traffic.

{
  "family": "checkout-service",
  "networkMode": "awsvpc",
  "requiresCompatibilities": ["FARGATE"],
  "cpu": "1024",
  "memory": "4096",
  "containerDefinitions": [
    {
      "name": "checkout",
      "image": "123456789012.dkr.ecr.us-east-1.amazonaws.com/checkout:latest",
      "portMappings": [{ "containerPort": 8080, "protocol": "tcp" }],
      "logConfiguration": {
        "logDriver": "awslogs",
        "options": {
          "awslogs-group": "/ecs/checkout-service",
          "awslogs-region": "us-east-1",
          "awslogs-stream-prefix": "checkout"
        }
      }
    }
  ]
}

Moving from ECS to EKS

This migration is heavier because it changes the orchestration API, not just the compute mode. The Qovery migration guide cited earlier frames the core work as translating ECS task definitions and services into Kubernetes Deployments and Services, replacing ECS capacity providers with node groups or Karpenter, and replacing ECS’s native load balancer integration with the AWS Load Balancer Controller or an Ingress controller.

1. Stand up an EKS cluster alongside the existing ECS cluster rather than replacing it in place, so traffic can be shifted gradually.
2. Translate each ECS task definition into a Kubernetes Deployment manifest, mapping container definitions, environment variables, and secrets references one-to-one where possible.
3. Replace ECS IAM task roles with IAM Roles for Service Accounts (IRSA) so pods retain least-privilege AWS permissions.
4. Install the AWS Load Balancer Controller to replicate ECS’s integration with Application Load Balancers and Network Load Balancers.
5. Choose a worker-capacity model: EC2 managed node groups for steady-state density, Karpenter for automated right-sizing, or EKS Fargate for pods with no DaemonSet or GPU requirements.
6. Provision the new infrastructure as code rather than by hand; teams already comparing Terraform against CloudFormation for provisioning tend to extend whichever tool they already use to cover the new EKS resources instead of introducing a third one.
7. Run ECS and EKS side by side behind the same DNS/load balancer for a defined cutover window, then decommission the ECS cluster once EKS carries production traffic cleanly.

# Create a managed EKS cluster with a Fargate profile for lightweight services
eksctl create cluster \
  --name production-cluster \
  --region us-east-1 \
  --version 1.31 \
  --fargate

# Add a Karpenter-managed node pool for steady-state, GPU, or DaemonSet workloads
eksctl create nodegroup \
  --cluster production-cluster \
  --name karpenter-nodes \
  --node-type m6i.large \
  --nodes-min 2 --nodes-max 20

Security and Compliance Considerations

Security posture differs meaningfully across the three options, mostly because of how much attack surface each one exposes directly to the operator. ECS and EKS on Fargate both benefit from AWS managing the underlying host, which removes an entire category of concern: unpatched kernels, exposed container runtimes, and host-level privilege escalation. That is one reason PayByPhone’s case study specifically cited compliance requirements as a driver for its move to Fargate with Windows containers.

EKS on EC2 carries more responsibility: node AMIs need regular patching, the CNI and any service mesh need careful network-policy configuration, and RBAC misconfiguration is a common source of over-privileged pods. Teams running EKS at scale generally pair it with policy-as-code tooling; our walkthrough of Kyverno for Kubernetes pod security covers how admission policies catch privileged containers and missing resource limits before they reach production, which matters more on EKS than on ECS simply because Kubernetes exposes more configurable surface area per pod.

Container image scanning matters identically across all three platforms, since a vulnerable base image is a vulnerable base image regardless of which orchestrator schedules it. Our comparison of free versus paid container vulnerability scanners is a reasonable next step for any team running production workloads on ECS, EKS, or Fargate that has not yet wired scanning into its CI/CD pipeline. IAM scope is the other recurring theme: ECS task roles and EKS IRSA both support least-privilege design, but EKS’s RBAC layer adds a second permission system on top of IAM that has to be kept in sync, which is a common source of drift in audits.

Vendor Lock-In and Exit Costs

Lock-in is often framed as a binary, Kubernetes is portable and ECS is not, but the reality sits on a spectrum for all three options. ECS is the most obviously locked-in: task definitions, capacity providers, and the ECS API itself have no equivalent outside AWS, so a move to another cloud means rewriting the deployment layer from scratch, even if the containers themselves do not change.

EKS looks more portable on paper, since Kubernetes manifests are nominally cloud-agnostic, but the practical coupling is still significant. IAM Roles for Service Accounts, the AWS Load Balancer Controller, EBS-backed storage classes, and VPC CNI networking are all AWS-specific implementations of Kubernetes concepts that have different equivalents, not drop-in replacements, on GKE or AKS. A team that built its EKS deployment around these AWS-native integrations should expect a nontrivial rework, not a simple kubeconfig swap, if it ever needs to move to another cloud’s Kubernetes offering. The portability benefit is real, but it shows up more in the Kubernetes skills and manifest structure transferring to a new team or new cloud than in an actual zero-effort migration.

Fargate sits in between. Choosing Fargate as a compute mode does not add any lock-in beyond whatever the parent orchestrator (ECS or EKS) already carries, since Fargate’s billing model and task-size matrix are conceptually similar to what any serverless container platform offers. The decision to use Fargate is reversible by switching back to EC2 within the same orchestrator without touching the orchestration layer at all, which makes it one of the lower-regret choices in this whole comparison, precisely because it is a compute decision rather than an architectural one.

Common Mistakes When Choosing Between ECS, EKS, and Fargate

The most frequent mistake is picking EKS by default because “Kubernetes is the industry standard,” without a concrete requirement that ECS cannot satisfy. Every EKS case study in this comparison, Hootsuite, ITV, Delhivery, and Danone, involved a specific driver: multi-cloud ambition, GPU workloads, or an existing platform-engineering team already fluent in Kubernetes. Teams that adopt EKS without one of those drivers tend to pay the $73-a-month control-plane fee and the RBAC/CNI complexity tax without capturing a matching benefit.

A second common mistake is defaulting every workload to Fargate without checking steady-state cost. Fargate’s per-task billing is easy to reason about for a handful of services, but a fleet of a dozen always-on tasks running 24/7 can cost noticeably more than the same workload consolidated onto two or three well-utilized EC2 instances. Flywire’s own case study is instructive here: the company used Fargate Spot specifically for development environments, where interruption tolerance is high and the discount matters, rather than applying Fargate uniformly across every environment.

A third mistake is underestimating the EKS upgrade cadence. Kubernetes versions move on a support schedule, and letting a cluster drift onto an unsupported version either forces a rushed upgrade or triggers AWS’s considerably more expensive extended-support pricing of $0.60 per cluster-hour, six times the standard rate. Teams running EKS in production should treat version upgrades as a recurring calendar item, not a reactive scramble once AWS sends an end-of-support notice.

A fourth mistake, specific to teams migrating from ECS to EKS, is underestimating how much of the existing deployment pipeline assumes ECS’s API. CI/CD scripts that call the ECS API directly to register task definitions or update services need to be rewritten to apply Kubernetes manifests instead, and secrets management, logging configuration, and health-check definitions all need to be re-expressed in Kubernetes terms rather than copied over unchanged. Budgeting for that pipeline rework, not just the runtime migration, is what separates the smoother migrations in this comparison from the ones that drag on for months longer than planned.

The Verdict: Which Should You Choose in 2026

There is no single winner across ECS, EKS, and Fargate, because they are not actually competing for the same job. The data points to three fairly clean decision rules.

If the team is AWS-only, wants to move fast, and does not need Kubernetes-specific tooling, ECS on Fargate is the lowest-friction choice: $0 orchestration fee, no node management, and a learning curve measured in days rather than months. Flywire, Nintendo Systems, Vanguard, and BILL all validate this path at meaningfully different scales, from a handful of services to 850-plus production applications.

If the team needs Kubernetes portability, a deep third-party ecosystem, or already has Kubernetes expertise in-house, EKS justifies its $73-a-month-per-cluster floor and higher operational complexity. Hootsuite’s 57% drop in SEV1/SEV2 incidents and 40% EC2 cost cut, and ITV’s $150,000 in one year from Spot Instances, both came after the team absorbed that complexity and then optimized aggressively on top of it with Karpenter and automation. EKS is not the simpler option, but it is the more flexible one, and that flexibility paid off for both companies within roughly a year of migrating.

For compute mode specifically, the EC2-versus-Fargate question is a function of workload shape more than philosophy: Fargate wins on operational simplicity for bursty or ops-light workloads, and loses on steady-state unit economics once a workload runs continuously enough that dense bin-packing on EC2 pays for itself. Teams running GPU workloads do not get a choice at all; Fargate’s lack of GPU support rules it out, pushing those workloads to EKS or ECS on EC2 by default, as Delhivery’s G5-backed EKS deployment illustrates. The practical starting point for most new AWS container projects in 2026 is still ECS on Fargate for anything without a specific reason to need Kubernetes, with a deliberate migration to EKS only once the team hits a concrete wall, portability requirement, or ecosystem need that ECS cannot clear.

Frequently Asked Questions

Is Fargate cheaper than EC2 for ECS or EKS?
Not for steady-state workloads. Fargate bills each task or pod independently for its requested vCPU and memory, while EC2 lets multiple tasks or pods share an instance through bin-packing. AWS’s own pricing and independent analysis both show EC2 is generally cheaper for continuously running capacity, while Fargate’s advantage is removing node management rather than cutting the compute bill.

Can I run ECS and EKS on the same AWS account?
Yes. There is no technical restriction preventing both from running in the same account, VPC, or even alongside each other for different services. Many of the companies covered in this comparison, including those running primarily on ECS, also operate smaller EKS footprints for specific workloads that need Kubernetes-native tooling.

Does Fargate support GPUs?
No. Fargate does not support GPU-backed tasks or pods on either ECS or EKS as of October 2026. Workloads that need GPU acceleration, such as ML inference, must run on EC2 instances with GPU support, typically behind EKS or ECS depending on the orchestrator preference.

How much does an EKS cluster cost before any workloads run?
Approximately $73 per month at the standard support rate of $0.10 per cluster-hour, or roughly $438 per month under extended Kubernetes-version support at $0.60 per cluster-hour. This fee applies regardless of how many pods the cluster is running, including zero.

Is migrating from ECS to EKS worth the effort?
It depends on whether the team actually needs what Kubernetes offers. Companies like Hootsuite and ITV that migrated to EKS reported real gains, including a 57% drop in major incidents and $150,000 in annual Spot savings, but both absorbed meaningful operational complexity to get there. Teams without a specific portability, ecosystem, or scaling requirement that ECS cannot meet generally do not see a comparable return.

What is the difference between ECS Fargate and EKS Fargate?
Both bill the same way, by vCPU-hour and GB-hour, but they have different platform limits. ECS Fargate supports up to 200 GiB of ephemeral storage per task, while EKS Fargate supports up to 175 GiB per pod. EKS Fargate also cannot run DaemonSets, privileged containers, GPU workloads, or attach EBS volumes, constraints that do not apply in the same way to ECS Fargate tasks.

Which is better for a startup with a small engineering team?
ECS on Fargate is usually the better starting point for small teams. It avoids both the Kubernetes learning curve and the $73-a-month EKS control-plane floor, letting a small team focus engineering time on the product rather than on cluster operations. Several of the case studies in this comparison, including Flywire and BILL, scaled from a handful of services into the hundreds without ever needing to adopt Kubernetes.

Does AWS charge extra for ECS orchestration?
No. Amazon ECS has no separate orchestration fee. Customers pay only for the underlying compute, whether that is EC2 instance-hours or Fargate vCPU-hours and GB-hours, plus any other AWS services the workload uses, such as load balancers or CloudWatch logging.