AWS Fargate Pricing: Real Costs Include 4 Hidden Fees

Your Fargate calculator shows $45/month. Your AWS bill shows $90. The gap isn't a mistake.

AWS Fargate pricing has five dimensions on the official pricing page — but the real bill includes public IPv4 charges per task, NAT Gateway data processing fees, CloudWatch Logs ingestion, and ALB costs that nobody warns you about upfront. For a typical microservice running 24/7, Fargate compute is only about 68% of the total bill.

Fargate bills for resources you configure, not what your container actually uses. An idle task at 0% CPU costs the same as one running full throttle.

In this guide you'll get the complete Fargate pricing formula, current 2026 rates for Linux, ARM, and Windows, four worked examples with real math, and a line-item breakdown of every charge that shows up on a real Fargate bill — not just the compute part. The CloudBurn Fargate Pricing Calculator uses live AWS pricing data from the Price List API — the same data that powers this guide. Use it to model your specific workload as you read.

All rates in this guide reflect AWS US East (N. Virginia) pricing as of March 2026. Other regions are typically 10–30% higher. Rates are subject to change — verify current rates on the official AWS Fargate pricing page.

How AWS Fargate Pricing Works

Before you can estimate your cost or catch a billing surprise, you need to understand how Fargate measures what it charges you. There are five independently configurable dimensions, and the billing clock starts earlier than most engineers expect.

Fargate has no upfront costs and no minimum fees. You pay for provisioned resources — not utilized resources. That's worth repeating: if you configure 2 vCPU (virtual CPUs) and 4 GB for a task and your application uses 10% of that, you're still billed for the full 2 vCPU and 4 GB.

The five billing dimensions are:

• vCPU count
• Memory (GB)
• Operating system (Linux or Windows)
• CPU architecture (x86 or ARM — ARM is ECS-only)
• Ephemeral storage above the 20 GB free tier

The Billing Formula

The total cost for a Fargate task is additive across all dimensions:

Total = (vCPU count × vCPU rate × seconds)
      + (Memory GB × memory rate × seconds)
      + (Extra storage GB × storage rate × seconds)

Billing is per-second. Linux tasks have a 1-minute minimum. Windows tasks have a 5-minute minimum. Multiple tasks are simply multiples of this formula — there's no consolidation discount. Running one 4 vCPU task costs the same as four 1 vCPU tasks with the same total resources.

When Does Billing Start and Stop?

This is the detail that catches teams most off guard. The billing clock starts when Fargate begins pulling your container image from ECR — not when your container is healthy and handling traffic.

Here's why this matters: in practice, a 2 GB container image on a cold pull can add 90–120 seconds to every task launch that you're paying for before your application does anything. For batch workloads that run hundreds of short tasks per day, that adds up.

The fix is straightforward: keep container images small. Use multi-stage Docker builds to strip dev dependencies, and use ECR image layer caching to speed up pulls. A task that pulls in 5 seconds versus 60 seconds makes a measurable difference at scale.

Billing stops when the ECS task or EKS pod terminates.

Supported Task Sizes (CPU/Memory Combinations)

Fargate doesn't allow arbitrary CPU and memory values. You must choose from seven fixed CPU sizes, each with a defined memory range:

The 8 vCPU and 16 vCPU sizes are designed for ML inference and large batch workloads. Note that Windows containers only support x86; ARM architecture is ECS-only and unavailable for Windows.

New AWS accounts have a default quota of 6 concurrent Fargate vCPUs per region. Fargate auto-increases this over time based on usage, but if you're spinning up more than a handful of tasks on a new account, you may need to request a quota increase through the Service Quotas console.

AWS Fargate Pricing Rates (2026)

Now that you know the formula, here are the actual numbers. All rates below are for US East (N. Virginia), which is the cheapest AWS region. Other regions run 10–30% higher — use the Fargate Pricing Calculator for region-specific estimates.

Linux x86 On-Demand Rates (us-east-1)

Linux ARM (Graviton) On-Demand Rates

Fargate powered by AWS Graviton2 processors is available for ECS — not EKS. The rates are approximately 20% lower across both vCPU and memory dimensions:

The 20% rate reduction matches the AWS claim of "up to 40% better price/performance" — the extra performance gains come from Graviton's higher throughput per core, meaning you often need fewer vCPUs for the same workload.

Windows Container Rates

Windows containers stack three separate charges: base vCPU, a Windows OS license fee (billed per vCPU-second), and memory. The OS license fee is the critical detail:

Key constraints for Windows containers: 5-minute billing minimum (vs 1 minute for Linux), no Fargate Spot, no ARM architecture, and Compute Savings Plans reduce the base vCPU charge but not the OS license fee. Supported versions: Windows Server 2019 Full/Core, Windows Server 2022 Full/Core.

Ephemeral Storage Pricing

Every Fargate task and pod gets 20 GB of ephemeral storage at no charge. This covers container image layers and bind mounts. Storage above 20 GB costs $0.000111/GB-hr and can be expanded up to 200 GB (Linux platform 1.4.0+ or Windows platform 1.0.0+).

In practice, ephemeral storage overages are negligible for most workloads. Five tasks running 10 minutes/day with 30 GB each (10 GB billable per task) comes to $0.03/month total.

Fargate Pricing Examples: Real-World Calculations

Rate tables are useful, but seeing the formula applied to real workloads makes the numbers concrete. The four examples below come directly from the official AWS Fargate pricing page, with additional context on what the numbers actually mean.

Example 1 — Linux x86 Batch Job (5 tasks, 10 min/day, 30 days)

This is the baseline batch workload: 5 tasks at 1 vCPU / 2 GB memory, running 600 seconds per day for 30 days with 30 GB ephemeral storage per task (10 GB billable above the free 20 GB).

For a lightweight batch workload that doesn't run all day, Fargate is remarkably cheap. The issue emerges when these tasks scale to hundreds of daily runs or when they run continuously.

Example 2 — Same Workload on Graviton ARM

Switch the identical workload from x86 to ARM and the only change is the rate:

ARM saves $0.24/month (19%) on this workload — $2.88/year on just 5 small batch tasks. The savings scale proportionally: at 50 tasks running continuously, that's $28.40/month saved from a single architecture change.

Example 3 — EKS Pods (10 pods, 1 hr/day, 30 days)

Ten pods at 0.25 vCPU / 1 GB, running 1 hour per day:

The EKS cluster fee is separate and not included above. If this is a dedicated cluster: $0.10/hr × 720 hrs = $72/month in control plane fees. The real total for a dedicated EKS cluster running these pods is $76.37/month — the cluster fee dwarfs the pod compute cost entirely. This is a key reason why EKS Fargate makes more sense when you already have a cluster with EC2 nodes and are adding Fargate pods to it.

For more on the EKS cluster fee math, the EKS pricing guide covers the full picture including the $438/month extended support trap.

Example 4 — Windows Containers (10 tasks, 1 hr/day, 30 days)

Ten tasks at 1 vCPU / 2 GB, 1 hour per day, showing the OS license fee stacked separately:

Compare this to the smaller Linux x86 EKS pods from Example 3 (0.25 vCPU / 1 GB, $4.37/month) — even accounting for the 4x CPU and 2x memory difference, the Windows OS license fee and higher per-vCPU rates make Windows Fargate dramatically more expensive. The Windows OS license fee alone adds $13.80/month on top of compute that's already more expensive per vCPU than Linux. If you're running .NET applications that can be moved to modern .NET (which runs on Linux), this is the fastest cost reduction available for Windows Fargate users.

The True Cost of Fargate: Beyond vCPU and Memory

Fargate compute is just one line on your AWS bill. A realistic microservice deployment adds at least four other charges, and for many services those additional costs equal or exceed the Fargate compute cost itself.

This is the most common source of surprise Fargate bills, and it's the gap that no top-10 Fargate pricing resource quantifies. Here's what's actually generating charges in a typical Fargate deployment.

Public IPv4 Charges (Per-Task ENI)

Each Fargate task gets a dedicated Elastic Network Interface (ENI). If that task runs in a public subnet with a public IP assigned, you pay $0.005/hr per public IPv4 address — a charge introduced in February 2024 as part of AWS's global public IPv4 pricing change.

The math scales fast:

• 10 tasks running 24/7 = $36/month in IPv4 charges alone
• 100 tasks running 24/7 = $360/month in IPv4 charges

The fix: deploy tasks in private subnets. Use a NAT Gateway for outbound internet access, or use VPC endpoints for AWS service calls (ECR, S3, CloudWatch) to skip the NAT Gateway entirely for those paths. Yes, a NAT Gateway has its own cost — but for more than a handful of tasks, the VPC architecture math favors private subnets.

NAT Gateway and Data Transfer

Tasks in private subnets route outbound traffic through a NAT Gateway. That adds two charges:

• NAT Gateway uptime: $0.045/hr per gateway (a single-AZ gateway runs $32.40/month continuously)
• Data processing: $0.045/GB for all traffic passing through

A service with 100 GB/month of outbound traffic adds $4.50 in data processing on top of the $32.40 gateway fee. For multi-AZ deployments, three NAT Gateways run $97.20/month in uptime before a byte of data moves. The NAT Gateway pricing guide covers the full picture and six strategies to reduce these costs.

CloudWatch Logs

The default awslogs log driver ships all container stdout/stderr to CloudWatch Logs at standard ingestion rates:

• Ingestion: $0.50/GB
• Storage: $0.03/GB per month (after the first 5 GB free tier)

An application logging 1 GB/day adds $15/month in log ingestion, plus $0.03 × ~30 GB = $0.90/month in storage after the free tier. Verbose logging from 20 Fargate tasks can run $50–$100/month in CloudWatch charges alone.

The fix: set log retention policies (default is never expire), and consider routing long-term logs to S3 via Firehose at $0.023/GB versus $0.50/GB. The CloudWatch Logs pricing guide covers every billing dimension and the retention policy configuration.

Worked Example: Full Bill for a Realistic Microservice

Here's the true cost for a representative production service: 2 tasks, 2 vCPU / 4 GB each, running 24/7 in us-east-1, behind an ALB, in a private subnet with a NAT Gateway, logging to CloudWatch at 500 MB/day per task.

Switch those two tasks to Graviton ARM and the compute drops from $142.19 to $113.76 — saving $28.43/month, or $341/year, with zero changes to the surrounding infrastructure. That's the Graviton opportunity in practice.

Fargate Spot: Up to 70% Cheaper for Interrupt-Tolerant Workloads

Fargate Spot runs on spare AWS compute capacity at up to 70% off On-Demand rates. It's the highest available discount for Fargate — higher than Savings Plans — but it comes with one condition: your tasks must be able to handle interruption.

Spot is available for ECS Linux tasks only — not EKS, not Windows. That's an important constraint, but for teams running batch jobs, CI/CD pipelines, or non-production environments on ECS Linux, Spot is the most impactful cost lever available.

How Fargate Spot Works

When AWS needs capacity back, running Spot tasks receive a SIGTERM signal 2 minutes before termination. At the same time, a task state change event fires to Amazon EventBridge, giving you a hook to automate response (drain connections, complete in-flight work, notify retry systems).

Interrupted tasks are billed only for the time actually used up to the point of interruption. There's no penalty fee for getting interrupted. Fargate manages the Spot pricing — prices are set by AWS and adjust based on long-term supply and demand trends. Current Spot prices are published on the pricing page.

Spot burst and sustained launch rate quotas apply: 100 tasks burst and 20 tasks/second sustained in major regions.

When to Use Spot vs On-Demand

Implementing Mixed Capacity Providers

The real power of Fargate Spot is the mixed capacity provider strategy — running a minimum number of On-Demand tasks for reliability while using Spot for the rest. This gives you cost savings without exposing your service to full interruption risk.

Configure your ECS cluster with both FARGATE and FARGATE_SPOT capacity providers. A practical setup for a web service:

• FARGATE: base=2, weight=1 — always keep at least 2 On-Demand tasks
• FARGATE_SPOT: base=0, weight=4 — run up to 4× more tasks on Spot when available

When Spot capacity is unavailable, ECS falls back to On-Demand for the Spot-intended tasks automatically. You get Spot savings when capacity is plentiful, and reliability when it isn't.

Compute Savings Plans: Commit to Save Up to 50%

If Fargate Spot is too unpredictable for your workload, Compute Savings Plans offer a more controlled discount. You commit to a $/hour spend rate for 1 or 3 years and get up to 50% off Fargate On-Demand rates in return. The commitment is flexible — it covers any Fargate usage across ECS and EKS, in any region, without locking you into specific task sizes.

For more detail on commitment calculation methodology and the broader Compute Savings Plans covering EC2, Lambda, and Fargate together (up to 66% discount), the Compute Savings Plans guide has the full breakdown.

How Compute Savings Plans Apply to Fargate

Savings Plans discount the vCPU and memory dimensions automatically. The discount applies as soon as matching Fargate usage appears in your account — no configuration needed beyond purchasing the plan.

What the discount applies to:

• vCPU per hour
• Memory (GB per hour)
• Applies to both ECS and EKS Fargate workloads

What the discount does NOT apply to:

• Windows OS license fee (this dimension is explicitly excluded)
• Ephemeral storage overages
• Public IPv4 charges, NAT Gateway, CloudWatch Logs, ALB

For Windows Fargate specifically, this means Savings Plans only reduce the base vCPU charge — not the 50% OS license fee stacked on top of it. The effective discount on the total Windows vCPU cost (base + OS fee) is lower than the headline Savings Plans rate.

Savings Plans vs Spot: Which Fits Your Workload?

Spot and Savings Plans can also be combined. Spot tasks run at the Spot rate; if a Spot task falls back to On-Demand, the Savings Plans discount applies to that On-Demand usage. This stacking gives you the best of both discount mechanisms.

ECS vs EKS Fargate: Pricing Differences That Catch Teams Off Guard

Most Fargate pricing content treats ECS and EKS as equivalent. They're not. EKS Fargate has a fixed cluster fee, a pod size cap, and lacks two of the most valuable cost features available on ECS: Spot and Graviton ARM.

If you're evaluating Fargate for a new project, this distinction matters more than the vCPU rate. For the full ECS cost picture, see the ECS pricing guide. For EKS-specific costs including extended support risk, see the EKS pricing guide.

The EKS Cluster Fee

Every EKS cluster charges $0.10/hr for the managed control plane — that's $72/month whether you run 1 pod or 1,000. This is the fixed cost floor for any EKS Fargate deployment.

If you're considering EKS Fargate for a small workload, the math often doesn't work: the cluster fee alone can exceed the pod compute cost. Going back to Example 3, the 10 pods at 0.25 vCPU cost $4.37/month in compute — but the cluster costs $72/month. The total is $76.37, and the compute is only 6% of the bill.

The cluster fee is shared across all pods in a cluster, so if you already have an EKS cluster with EC2 nodes, adding Fargate pods doesn't increase the cluster fee. That's when EKS Fargate actually makes cost sense.

EKS Fargate Pod Size Limits

EKS Fargate pods have a hard cap of 4 vCPU / 30 GB per pod. On ECS, the maximum is 16 vCPU / 120 GB per task. This cap matters for:

• ML inference workloads (8 or 16 vCPU tasks must use EC2 nodes on EKS, not Fargate)
• Large batch processing tasks that need more than 30 GB of memory
• Any workload requiring the 8 vCPU or 16 vCPU sizes from the task configuration grid

ECS vs EKS Fargate Constraints

The Amazon EKS cost optimization best practices documentation is direct about this: "Fargate compute is a fully managed compute option for EKS clusters but may require more compute capacity and be more expensive than other capacity types." Each EKS Fargate pod runs on single-tenant compute isolation, versus EC2 nodes that can pack multiple pods — which is why Fargate on EKS often needs more total resources for the same workload.

Fargate vs EC2: Which Is Actually Cheaper?

This depends almost entirely on your utilization pattern. Fargate charges for reserved resources per second; EC2 charges for the instance regardless of how many tasks run on it. EC2 allows bin-packing (running multiple containers on one instance), which can make it significantly cheaper per workload at high utilization.

For the EC2 pricing mechanics you'll need to make this comparison concrete, the EC2 pricing breakdown covers all purchase options including Reserved Instances and Savings Plans.

When Fargate Costs More Than EC2

Fargate tends to cost more in these scenarios:

• Steady-state, high-utilization services — tasks running 24/7 at consistent load, where EC2 bin-packing and Reserved Instances undercut Fargate's per-second rate
• Large workloads that pack efficiently — a c6g.xlarge (4 vCPU, 8 GB, ~$0.136/hr On-Demand Graviton) running two 2 vCPU / 4 GB tasks costs $0.068/hr per workload vs $0.099/hr on Fargate
• Teams with mature EC2 auto-scaling already in place — if you've already solved the operational complexity, the overhead argument for Fargate weakens
• Windows workloads — the OS license fee makes Fargate particularly expensive; EC2 Windows instances can be Right Reserved for lower total cost

When Fargate Costs Less (or the Same, Net of Ops)

The calculation shifts in the other direction with these workload patterns:

• Variable or spiky load — Fargate scales to zero between bursts; EC2 idles and still charges
• Development and staging environments — sporadic usage means you're paying for idle EC2 capacity most of the day with EC2, while Fargate charges nothing when tasks aren't running
• Teams without bandwidth for EC2 fleet management — OS patching, AMI updates, cluster autoscaling configuration, capacity provisioning — these have real engineering time costs. For many teams that engineering time is worth more than the compute premium Fargate charges
• Early-stage products — getting to production quickly has dollar value that often outweighs infrastructure optimization at small scale

Fargate vs Lambda

For completeness, since "fargate vs lambda" is a common follow-on question:

Lambda is better for event-driven functions with unpredictable, spiky traffic and sub-minute execution times. Fargate wins for anything needing persistent connections, more than 10 GB of memory, or execution times beyond 15 minutes.

How to Reduce Your Fargate Bill: 4 Strategies That Work

These four strategies are ordered by ROI-to-effort ratio. The first one (Graviton) is where I'd start for almost any ECS workload — it's a configuration change in a task definition, not a refactor.

Switch to Graviton (20% Off, Minimal Effort)

For containerized workloads on ECS, this is the easiest meaningful cost reduction available. The migration is: build multi-architecture images (Docker buildx or a CI build matrix), then update the runtimePlatform field in your ECS task definition to cpuArchitecture: ARM64. That's typically the entire change for most containerized applications.

Here's what that 20% rate difference translates to in dollars for tasks running 24/7 for 30 days:

These are compute-only savings. The surrounding infrastructure costs (NAT, ALB, CloudWatch) don't change. For a production service running 10 tasks at 2 vCPU / 4 GB, Graviton saves $142/month — $1,705/year — from a single task definition change.

In practice, Graviton migration for containerized workloads is usually a day's work, not a sprint. The tricky cases are services with native binaries or dependencies compiled for x86 only. For the vast majority of web applications and APIs running in containers, ARM64 works without code changes.

Use Fargate Spot for Batch, CI/CD, and Dev Environments

Apply Spot to any workload that can tolerate a 2-minute shutdown warning:

• Batch and ETL jobs with retry logic
• CI/CD pipeline build runners (most CI frameworks handle this natively)
• Scheduled tasks and cron jobs
• Non-production environments where occasional interruption is fine

Implement graceful SIGTERM handling in your application — catch the signal, finish in-flight requests, and shut down cleanly within 2 minutes. Configure the ECS service with FARGATE_SPOT as the capacity provider and set stopTimeout: 120 on the container definition.

Commit with Compute Savings Plans

Savings Plans make sense when your Fargate usage is consistent and predictable. A rough threshold: if you're spending more than $200/month On-Demand on Fargate and expect that to continue for at least a year, a 1-year Compute Savings Plan will pay back quickly.

Use AWS Cost Explorer's Savings Plans recommendations to calculate the right commitment level — it analyzes your last 30 days of usage and suggests an hourly commitment that covers your baseline without over-committing. Avoid purchasing based on peak usage; buy to cover the floor and let On-Demand absorb spikes.

Three-year terms offer the highest discount but require confidence in long-term usage patterns. Start with 1-year unless you have strong evidence for 3-year stability.

Rightsize with AWS Compute Optimizer

Over-provisioned tasks are a common source of quiet waste. A task configured for 4 vCPU that consistently runs at 15% CPU is using 85% of its cost for nothing.

AWS Compute Optimizer analyzes CloudWatch metrics (CPUUtilization, MemoryUtilization) over a minimum 24-hour window and generates rightsizing recommendations for Fargate services. In the console, filter by "Findings = Over-provisioned" to find the worst offenders.

One important limitation: Compute Optimizer only generates recommendations for ECS services that are in a steady state and don't have step scaling or target tracking policies active. If your service auto-scales aggressively, Compute Optimizer can't distinguish between over-provisioning and scaling headroom.

The AWS Well-Architected guidance (MSFTCOST07-BP01) on using Compute Optimizer for Fargate rightsizing is worth reading if you're managing a fleet of Fargate services.

Rightsizing requires updating the task definition and redeploying the service, so plan for a deployment cycle. The payoff for a consistently over-provisioned task can be 30-50% savings on that task's compute cost.

Frequently Asked Questions

Wrapping Up

Here are the five things I'd want anyone running Fargate to internalize:

1. Fargate bills configured resources, not utilization. Rightsizing isn't optional — it's the baseline. Compute Optimizer is the right tool for finding waste.

2. The billing clock starts at Docker image pull, not container health. Keep images small. The difference between a 5-second and 60-second pull matters at scale.

3. For real cost estimation, add IPv4, NAT, CloudWatch, and ALB to your compute estimate. Compute is often 60–70% of the total bill for a production service. The rest doesn't show up in any Fargate-specific calculator.

4. Graviton ARM is the easiest saving available on ECS — roughly 20% lower rates, typically a single-day migration for containerized apps, and it stacks with Spot and Savings Plans.

5. EKS Fargate and ECS Fargate have meaningfully different cost profiles. EKS lacks Spot, lacks ARM, adds a $72/month cluster fee, and caps pods at 4 vCPU / 30 GB. If you're starting fresh, ECS is the cheaper platform for Fargate-first architectures.

Next step: run your specific configuration through the Fargate Pricing Calculator with your actual task sizes, region, and architecture choice. If you're weighing Fargate against running your own EC2 nodes, the ECS pricing guide breaks down the full comparison including EC2 managed instance cluster overhead.

What's your biggest Fargate cost surprise been? The IPv4 charge, CloudWatch logs, or something else entirely? Drop a comment below.