AWS Fargate Cost Optimization: When Fargate Beats EC2 in 2026

Updated: June 21, 2026

AWS Fargate cost optimization in 2026 comes down to four levers: right-size the vCPU and memory you request, run interruption-tolerant tasks on Fargate Spot for up to 70% off, cover steady baseline usage with a Compute Savings Plan, and move to Graviton (ARM64) where your image supports it. Stacked together, these typically cut Fargate bills 40–65% without touching a line of application code. This guide shows the exact request sizes, CLI commands, and breakeven math that decide whether Fargate or EC2 is the cheaper choice for your workload.

• Fargate charges per-second for the vCPU and memory you request, not what you use. Over-provisioned task definitions are by far the single largest source of waste.
• Fargate Spot offers up to 70% off on-demand pricing in 2026 and works well for stateless workers, batch jobs, and CI runners that tolerate 2-minute interruption notices.
• Compute Savings Plans apply to Fargate at the same discount tier as EC2 (up to 50% for 3-year, all-upfront), and they automatically cover Lambda and EC2 too.
• Graviton-based Fargate tasks cost roughly 20% less than x86 for the same vCPU/memory shape. Switching is a one-line change in your task definition if your container image is multi-arch.
• EC2 with Karpenter usually beats Fargate above ~80% steady-state utilization, or when you need GPUs, large memory ratios (>8 GB/vCPU), or daemonsets like log collectors.
• Container Insights, ephemeral storage above 20 GB, and cross-AZ data transfer are the three hidden line items that quietly inflate Fargate invoices.

How is AWS Fargate billed in 2026?

Fargate bills by the second (with a 1-minute minimum) for the vCPU and memory you declare in the task definition, plus separate charges for ephemeral storage above 20 GB and for any operating system family (Windows tasks are roughly 2x the Linux price). The critical word there is declare. AWS doesn't measure your actual container utilization, so a task that requests 2 vCPU and 4 GB but only uses 0.3 vCPU and 600 MB still bills for the full request. In the us-east-1 region as of 2026, on-demand Linux/x86 Fargate is approximately $0.04048 per vCPU-hour and $0.004445 per GB-hour. A 1 vCPU / 2 GB task running 24x7 therefore costs roughly $36/month before any optimization.

Two pricing modes exist: on-demand and Fargate Spot. Fargate also supports both ECS and EKS as orchestrators. The per-vCPU pricing is identical, but EKS Fargate adds a $0.10/hour control-plane charge per cluster and a per-pod overhead of 256 MB of memory and 0.25 vCPU reserved for the kubelet and kube-proxy. That overhead matters more than people expect: a pod requesting 0.5 vCPU on EKS Fargate actually gets billed at 0.75 vCPU. Always include that surcharge when comparing EKS Fargate to ECS Fargate or to a self-managed node group.

Right-size Fargate tasks: vCPU and memory tuning

So, let's start with the fastest win. Right-sizing usually pays first, because most task definitions inherit defaults from a generator (CDK, Copilot, the Console wizard) that picks 0.5 or 1 vCPU and 1–2 GB regardless of what the workload actually needs. Pull 14 days of CloudWatch CpuUtilization and MemoryUtilization per task family and look at the p95. If p95 CPU is below 30% or memory below 50%, drop one size. Fargate's supported shapes go in 0.25 vCPU and 512 MB increments at the small end, so the granularity is forgiving.

Here's a one-liner that lists every ECS service with its current task size and a 14-day p95 CPU reading, sorted by waste:

aws ecs list-clusters --query 'clusterArns[]' --output text | \
  xargs -n1 -I{} aws ecs list-services --cluster {} --query 'serviceArns[]' --output text | \
  while read svc; do
    cluster=$(echo "$svc" | awk -F/ '{print $2}')
    name=$(echo "$svc" | awk -F/ '{print $3}')
    p95=$(aws cloudwatch get-metric-statistics \
      --namespace AWS/ECS --metric-name CPUUtilization \
      --dimensions Name=ClusterName,Value=$cluster Name=ServiceName,Value=$name \
      --start-time $(date -u -v-14d +%FT%TZ) --end-time $(date -u +%FT%TZ) \
      --period 3600 --extended-statistics p95 \
      --query 'Datapoints[].ExtendedStatistics.p95' --output text \
      | tr '\t' '\n' | sort -n | tail -1)
    echo "$cluster/$name  p95_cpu=$p95"
  done | sort -k2 -t= -n

Anything with p95 below 30 is a right-sizing candidate. For memory, also check the OOMKilled count, because Fargate enforces hard memory limits and trimming too aggressively will crash tasks. A safe rule: target p95 memory between 60% and 75% after the change. I learned this one the hard way on a Node service that looked idle on p95 but spiked hard during JWT key rotation, and clipping it just below the spike caused a string of 2 AM pages. AWS Compute Optimizer added ECS Fargate recommendations in late 2024 and now covers EKS Fargate workloads as well; turn it on at the organization level and treat the "Underprovisioned" and "Overprovisioned" tags as your right-sizing backlog.

Fargate Spot: when to use it and how to handle interruptions

Fargate Spot reuses AWS's spare capacity at up to 70% off on-demand. The interruption model is gentler than EC2 Spot (you get a 2-minute SIGTERM warning and tasks can drain), but the same workload-suitability rules apply. Use Fargate Spot for stateless web tiers behind a load balancer with multiple replicas, batch jobs that checkpoint, CI runners, asynchronous workers consuming SQS, and anything with retry semantics. Avoid it for stateful singletons, anything with a long startup cost (more than 2 minutes from cold to ready), and workloads with strict SLAs unless you mix in on-demand baseline capacity.

In ECS you express the mix with capacity providers. This service definition fragment runs a baseline of two on-demand tasks and bursts up on Spot:

{
  "capacityProviderStrategy": [
    { "capacityProvider": "FARGATE",      "base": 2, "weight": 1 },
    { "capacityProvider": "FARGATE_SPOT", "base": 0, "weight": 4 }
  ]
}

For EKS, configure a Fargate profile with a label like capacity-type: spot and use a pod-spec node selector. Or, more flexibly, run Karpenter on a small managed node group and let it provision Spot EC2 capacity instead, which we cover in our Karpenter cost optimization guide. Handle the interruption signal by registering a SIGTERM trap that drains connections, finishes in-flight work, and exits within 90 seconds. If your task takes longer it will be force-killed. For broader patterns across services and clouds, see our spot instances playbook.

Apply Compute Savings Plans to Fargate

Compute Savings Plans automatically apply to Fargate at the same discount as EC2: up to 50% for a 3-year all-upfront plan, 27% for 1-year no-upfront. The plan covers Fargate, Lambda, and EC2 simultaneously, so the commit is fungible across compute types. This matters when you're mid-migration. A team moving from EC2 to Fargate can sign one Savings Plan and the discount follows the workload.

The mechanics: AWS calculates your committed dollar-per-hour spend and applies the discount to whichever Fargate vCPU-hours, Lambda GB-seconds, or EC2 instance-hours fit best each hour. You don't need to attach the plan to a specific cluster or service. To size the commit, pull 30 days of Fargate on-demand spend from Cost Explorer, take the minimum hour (the steady baseline), and commit to roughly 80% of that figure. The remaining 20% absorbs traffic dips so you don't waste commitment hours. AWS publishes the full mechanics in the Savings Plans user guide; the strategic playbook for commit ratios and rolling them across instance families lives in our Compute Savings Plans coverage and utilization strategy.

Switch to Graviton (ARM64) for 20% savings

Fargate has supported Graviton2 (ARM64) since 2022, and Graviton3-class capacity rolled out broadly in 2024. The pricing differential as of 2026 is approximately 20% lower vCPU-hour and memory-hour rates than x86. Switching is two changes: build a multi-arch container image (one Buildx command), then add "runtimePlatform": {"cpuArchitecture": "ARM64", "operatingSystemFamily": "LINUX"} to your task definition. That's it.

The catch is image compatibility. Pure Go, Java, .NET 8+, Node.js, Python, and Ruby workloads run on ARM64 with no code changes. Native dependencies (particularly old C extensions, proprietary database drivers, or anything from a vendor still shipping x86-only binaries) may not. The fastest test is to build the ARM64 variant locally with docker buildx build --platform linux/arm64 and run your test suite. If it passes, you're done. We cover the migration playbook end-to-end (including how to A/B test latency between architectures) in our AWS Graviton migration guide, and the same techniques apply to Fargate verbatim.

Is Fargate cheaper than EC2? The breakeven math

Honestly, this is the question everyone asks first. Fargate is cheaper than EC2 below roughly 60–70% steady-state utilization on a per-task basis, and more expensive above it. The reason: EC2 instances bill for the whole VM regardless of how many containers fit on it, so if your bin-packing is excellent, EC2's higher capacity is amortized across many workloads. Fargate eliminates bin-packing waste entirely, but it charges a per-task premium for that convenience (roughly a 15–25% markup vs. equivalent EC2 vCPU/memory at on-demand prices).

Dimension	Fargate	EC2 + Karpenter/ECS
Best for	Spiky, low-utilization, or low-volume services	Steady, high-utilization, dense workloads
Breakeven utilization	Wins below ~60% steady CPU	Wins above ~70% with good bin-packing
Spot discount	Up to 70%	Up to 90%
Savings Plans	Yes, same Compute Savings Plan	Yes, Compute or EC2-Instance plans
Graviton premium	~20% off x86 rates	~20% off x86 rates
GPU support	No	Yes (g4dn, g5, g6, p-series)
Daemonsets / log shippers	Not supported (sidecar only)	Fully supported
Operational overhead	Near zero, no nodes to patch	Patching, AMI lifecycle, autoscaling tuning

The honest rule of thumb: small platform teams with fewer than ~20 long-running services almost always come out ahead on Fargate once you factor in the engineering hours saved on node management. Large platforms with hundreds of services, GPU workloads, or strict per-second latency budgets typically save money on EC2, especially with Karpenter consolidating workloads onto Spot capacity. A hybrid model is the most common outcome I've seen in practice: Fargate for the long tail of low-traffic services, EC2 for the top 5–10 workloads by spend.

Hidden Fargate costs: ephemeral storage, logs, and data transfer

Three line items show up on the bill that nobody sized for in the task definition. First, ephemeral storage. Every Fargate task gets 20 GB free, but any extra is billed at $0.000111 per GB-hour. A task requesting 200 GB of ephemeral storage running 24x7 adds about $16/month. Most of the time the team requested 200 GB once for a one-off build, then forgot to lower it. Audit with aws ecs describe-task-definition and grep for ephemeralStorage.

Second, Container Insights. ECS Container Insights is convenient but bills as CloudWatch custom metrics (~$0.30 per metric per month), and the metric count scales linearly with task count. A cluster running 200 tasks can easily generate $400/month of Insights metrics. Switch to Container Insights with enhanced observability only on production clusters, or move to a self-hosted Prometheus + Grafana stack and disable the AWS one. Our CloudWatch cost optimization guide covers the exact CLI to find which clusters are paying for Insights you no longer use.

Third, cross-AZ data transfer. Fargate tasks distribute across availability zones for high availability, and any traffic between AZs costs $0.01/GB each way. A chatty microservice making 100 GB/day of cross-AZ calls costs roughly $60/month in data transfer alone. Use topology-aware routing (ECS service connect or EKS topology-aware hints) to keep traffic within a single AZ when possible.

Monitor Fargate cost with Cost Explorer and CUR

Treat Fargate spend as a first-class metric. Build a Cost Explorer view filtered to Service = Amazon Elastic Container Service and Usage Type Group = ECS: Fargate, grouped by tag. Tag every task definition with cost-center, team, and environment. Fargate inherits resource tags onto the line item, so without them you can't allocate. For deeper analysis, point Athena at the Cost and Usage Report (CUR) and run queries like:

SELECT
  resource_tags_user_team    AS team,
  line_item_resource_id       AS task,
  SUM(line_item_unblended_cost) AS cost,
  SUM(line_item_usage_amount)   AS vcpu_hours
FROM cur_table
WHERE line_item_product_code = 'AmazonECS'
  AND product_servicecode    = 'AmazonECS'
  AND line_item_usage_type LIKE '%Fargate%'
  AND bill_billing_period_start_date = DATE '2026-06-01'
GROUP BY 1, 2
ORDER BY cost DESC
LIMIT 50;

That query exposes the top 50 tasks by Fargate spend in a single month. Pair it with anomaly detection (covered in our cloud cost anomaly detection setup guide) so an unintentional --replicas 100 deploy pages someone within 24 hours instead of showing up on next month's invoice.

Frequently Asked Questions

Does Fargate qualify for Savings Plans?

Yes. Fargate is covered by Compute Savings Plans (not EC2 Instance Savings Plans) at the same discount tier as EC2, up to 50% for a 3-year all-upfront commitment. The plan is fungible across Fargate, Lambda, and EC2, so a single commitment can cover multiple compute services.

What is Fargate Spot and how much does it save?

Fargate Spot runs tasks on AWS's spare capacity at up to 70% off on-demand pricing. AWS gives a 2-minute SIGTERM warning before reclaiming capacity. It works best for stateless services with multiple replicas, batch jobs, and CI runners that can tolerate occasional interruptions.

Is Fargate cheaper than running EC2 with Karpenter?

It depends on utilization. Fargate is typically cheaper below ~60% steady CPU utilization, because EC2 bills for the whole instance regardless of bin-packing. Above ~70% utilization with good bin-packing, EC2 + Karpenter usually wins, especially when you can use EC2 Spot at up to 90% off.

How do I right-size Fargate tasks?

Pull 14 days of CloudWatch CPUUtilization and MemoryUtilization metrics per task family. If p95 CPU is below 30% or memory below 50%, drop one size. Target 60–75% memory utilization after the change to avoid OOM kills. AWS Compute Optimizer now provides ECS and EKS Fargate right-sizing recommendations directly.

Can I run Graviton (ARM64) workloads on Fargate?

Yes. Fargate supports ARM64 via the runtimePlatform field on the task definition. Graviton-based Fargate tasks cost roughly 20% less than x86. You need a multi-arch container image (build with docker buildx --platform linux/arm64), and pure Go, Java, .NET, Node, Python, and Ruby workloads typically run unchanged.