The Fargate Tax: Why Serverless Kubernetes Costs 38% More Past 200 vCPU-Hours

Fargate is appealing because the pitch is clean: no AMI patching, no node group sizing, no cluster autoscaler tuning. You describe what your pod needs and AWS handles the rest. For a team of two or three engineers, that operational simplicity is worth real money.

At low workload volumes, Fargate delivers on that pitch. Past 200 vCPU-hours per day, it consistently costs 35-40% more than an equivalent EC2 node group running the same workloads. The operational savings exist, but the compute premium exceeds them.

Most teams make the Fargate versus EC2 decision at cluster creation time based on operational preference, not cost analysis. They stay on whichever choice they made until the monthly bill crosses a threshold that forces a conversation. This post builds the model so that conversation happens before the bill does.

What Fargate Actually Costs Per vCPU-Hour

Fargate charges separately for vCPU and memory, billed per second at these us-east-1 on-demand rates: $0.04048 per vCPU-hour and $0.004445 per GB-hour. A pod requesting 1 vCPU and 2 GB of RAM costs $0.04937 per hour.

EC2 pricing covers the entire instance. A t3.medium (2 vCPU, 4 GB) runs at $0.0416 per hour, which works out to $0.0208 per vCPU-hour at full utilization. A m5.large (2 vCPU, 8 GB) runs at $0.096 per hour, or $0.048 per vCPU-hour.

The t3.medium comparison looks extreme because EC2 instances pack workloads onto shared nodes. If you fill a t3.medium with two 1 vCPU / 2 GB pods, each pod costs $0.0208 per vCPU-hour on EC2 versus $0.04937 on Fargate. The fair comparison accounts for how densely pods pack onto nodes.

For compute-class instances (m5, c5, r5), the Fargate premium settles around 37-42% at full EC2 utilization. That number is the ceiling of EC2 advantage, achievable only when nodes run at 100% of schedulable capacity.

The Node Overhead Adjustment EC2 Always Carries

EC2 instances never run at 100% effective workload utilization. The OS, kubelet, kube-proxy, and eviction thresholds consume roughly 15-20% of provisioned capacity on a typical EKS node. AWS reserves a fixed amount per node type: for m5.xlarge, the kubelet reserves 80m CPU and 1740Mi memory by default.

At 87.5% effective utilization on an m5.xlarge, the real cost per workload vCPU-hour rises from $0.048 to $0.055. That is a meaningful adjustment that closes part of the gap with Fargate. But it does not close it entirely. Fargate at $0.04937 per vCPU-hour is still cheaper per raw compute hour on the m5.xlarge comparison, even after overhead adjustment.

Where EC2 wins is bin-packing: one node running eight 1-vCPU pods at 87.5% utilization still costs less per pod-hour than running eight separate Fargate tasks, because the fixed overhead is shared across all pods. Fargate charges each pod separately for its full requested resources.

The Crossover Point: 200 vCPU-Hours Per Day

The break-even model combines three inputs: daily vCPU-hours of workload, average EC2 node utilization, and the node management labor cost for the team.

At low daily vCPU-hours, EC2 node management costs (AMI updates, node group sizing, autoscaler tuning) represent a large fraction of total infrastructure cost. Fargate’s premium is offset by avoided labor. As daily vCPU-hours grow, compute cost dominates and labor cost becomes a smaller fraction. Past 200 vCPU-hours per day, the compute premium exceeds the labor savings for most teams.

The “ops labor” estimate for a 2-3 engineer team is $8,000-$15,000 per year in avoided node management work, or roughly $650-$1,250 per month. At 400 vCPU-hours per day, EC2 saves approximately $80 per month on compute but the ops savings still favor Fargate. At 800 vCPU-hours per day, the compute delta alone exceeds the ops savings and EC2 wins on total cost.

The crossover at 200 vCPU-hours is not a hard line. Teams with dedicated SRE capacity who can automate node management shift the crossover lower. Teams where every hour of platform engineering time is expensive shift the crossover higher. The model gives you the variables; you supply the team-specific numbers.

Tracking workload vCPU-hours over time is easiest through Kubernetes resource visibility tooling that surfaces per-node and per-workload utilization in one view. Without that visibility, teams are making the Fargate versus EC2 decision on intuition rather than data.

Workloads That Should Stay on Fargate

Not every workload should migrate to EC2 past the crossover. Four workload types favor Fargate regardless of volume.

Fargate Spot further changes the math for batch workloads: 50-70% discount off standard Fargate rates with interruption risk. For batch jobs that can tolerate a restart, Fargate Spot is often the cheapest option of all, cheaper than EC2 spot for the same workload because there is no node provisioning delay on interruption recovery.

The Karpenter Factor: EC2 Without Most of the Node Management Tax

The argument for Fargate is operational simplicity. Karpenter closes 80% of that gap for EC2. Karpenter handles node provisioning, instance type selection, bin-packing, and node consolidation automatically. An EKS cluster running Karpenter behaves much closer to Fargate operationally: you describe pod requirements, Karpenter provisions the right node, and unused nodes are consolidated or terminated.

What Karpenter does not eliminate: AMI management, node security patching, and cluster autoscaler configuration for non-Karpenter node groups. These are a smaller fraction of node management work, but they are not zero. For teams that want truly zero node operations, Fargate remains the right answer even past the cost crossover, if the compute premium is within budget.

When provisioning new clusters from scratch, ZopDay’s cluster wizard makes opinionated decisions about node group configuration, Karpenter setup, and default instance families based on expected workload patterns. That removes most of the initial setup labor without requiring Fargate.

Mixed Mode: Fargate for Burst, EC2 for Baseline

The practical recommendation for most teams past 200 vCPU-hours per day is mixed mode: EC2 node groups for steady-state serving workloads, Fargate for burst and batch.

Baseline serving traffic on EC2 captures the cost advantage past the crossover. Burst overflow on Fargate captures the operational advantage: burst capacity is available in seconds, not minutes, and Fargate tasks terminate cleanly when traffic recedes. This is the same pre-scaling pattern used by event readiness planning for planned traffic spikes: EC2 handles the baseline, Fargate absorbs the spike without requiring node group resizing.

The migration from pure Fargate to mixed mode is measured in weeks for most clusters. The simplest path is to identify the top three steady-state deployments by vCPU-hours, move them to EC2 node groups with Karpenter, and leave everything else on Fargate. Measure the cost delta after 30 days and continue migrating if the numbers hold.

Fargate is not the wrong choice. It is the wrong choice for workloads that run long and steadily. The 38% premium is the price of operational simplicity. Past 200 vCPU-hours per day, that price is worth examining.