AWS Fargate Pricing: Tips to Optimize Costs and Save Money

AWS Fargate is a serverless compute engine for containers that works with Amazon Elastic Kubernetes Service (EKS) and Elastic Container Service (ECS). It removes the need to provision or manage EC2 instances. You define your container’s CPU, memory, and networking requirements, and Fargate handles the underlying infrastructure. For teams that want to run containers without operating a cluster, it is the default starting point on AWS.

The tradeoff is cost. Fargate charges a premium for the infrastructure it abstracts away, and that premium grows as workloads scale. Pricing is based on the vCPUs and RAM your tasks consume, billed per hour. Understanding those costs, and the options available to reduce them, is essential before committing to Fargate at scale.

Fargate on-demand pricing snapshot (US East / N. Virginia):

A typical workload running 4 vCPUs and 16 GB of RAM costs roughly $0.22/hour or $160/month on-demand. Add 10 GB of ephemeral storage for another $0.73/month.

Prices shift over time. Check the AWS Fargate pricing page for current numbers. The relative comparisons in this article hold regardless of small rate changes.

What Fargate is and how it works

Fargate is a fully managed compute layer for containers. You package your application into a container image, specify the CPU and memory it needs, define IAM permissions and networking policies, and launch it. Fargate provisions the infrastructure, runs your container in an isolated environment, and tears it down when the task completes. There are no EC2 instances to select, no cluster capacity to plan, and no operating system patches to apply.

This model works well for teams that want to ship containers without building Kubernetes operational expertise. The isolation model is strong: each Fargate task runs in its own microVM, which provides better tenant separation than shared EC2 nodes. Monitoring integrates with CloudWatch and Container Insights out of the box, though visibility into the underlying infrastructure is limited by design.

Fargate vs. Lambda vs. EC2

All three services can run workloads on AWS, but they target different use cases and carry different cost structures.

The key cost insight is that Fargate bills for configured resources, not utilized resources. If you allocate 4 vCPUs to a task that averages 1.5 vCPUs of actual usage, you pay for all four. EC2 has the same billing model at the instance level, but you can bin-pack multiple workloads onto a single instance to improve utilization. Lambda bills per invocation and execution time, which makes it cheaper for bursty, low-duration workloads but expensive at sustained high throughput.

For most teams, the decision comes down to operational overhead versus cost. Fargate minimizes ops work. EC2 minimizes spend. Lambda is the right choice when workloads are genuinely event-driven and short-lived.

Where Fargate falls short

Fargate’s biggest limitation is its cost at scale. The convenience premium is acceptable for small or experimental workloads, but it compounds quickly. A team running 20 services at 4 vCPUs each will pay roughly $3,200/month on Fargate on-demand. The same workloads on appropriately sized EC2 instances, or on a more cost-effective cloud provider, can cost a third of that. At that scale, the operational savings from serverless no longer justify the price difference.

Resource capping is another constraint. On EKS, each Fargate pod is limited to 4 vCPUs and 30 GB of memory. Workloads that need more than that, whether for data processing, model inference, or memory-intensive applications, simply cannot run on Fargate without being split into smaller, coordinated tasks. That adds application complexity to work around an infrastructure limitation.

There is no GPU support. Teams running machine learning inference, video processing, or any GPU-accelerated workload need to look elsewhere. This is a hard boundary, not a configuration issue.

Observability is limited by the serverless model. Fargate tasks run in isolated microVMs, and you have no access to the underlying host. This is fine when everything works, but it makes debugging harder when something goes wrong at the infrastructure level. You cannot SSH into a node, inspect host-level metrics, or run diagnostic tools outside your container. For teams used to full cluster visibility, this feels like operating with the dashboard lights off.

Fargate on EKS also restricts networking and scheduling options. Only the AWS Application Load Balancer is supported. You cannot run DaemonSets, use HostNetwork or HostPort, or schedule pods on public subnets. These restrictions matter less for simple web services but become blockers for more complex Kubernetes workloads that rely on node-level agents or custom networking.

Regional availability is uneven, particularly for EKS on Fargate. If your infrastructure spans multiple regions, verify that Fargate is available in each one before designing around it.

Reducing your Fargate costs

The most effective lever is the AWS Compute Savings Plan. By committing to a consistent level of compute spend over one or three years, you can reduce Fargate costs by up to 52%. The plan applies across EC2, Lambda, and Fargate in any region, so it does not lock you into a single service. Usage up to your commitment is billed at the discounted rate; anything above it falls back to on-demand pricing. For teams with predictable baselines, this is the first optimization to implement.

The second lever is autoscaling. Idle Fargate tasks cost the same as busy ones. The Kubernetes Horizontal Pod Autoscaler (on EKS) or ECS Service Auto Scaling (on ECS) can scale tasks down during low-demand periods and back up when traffic increases. The goal is to keep configured resources close to actual utilization. Without autoscaling, you are almost certainly paying for capacity you are not using.

Spot instances offer steep discounts (roughly 70% off on-demand) for workloads that can tolerate interruption. Batch jobs, data pipelines, and stateless processing tasks are good candidates. Production services that need high availability are not. Note that Fargate Spot does not carry an SLA, so plan for interruptions in your application design.

Beyond these three, the returns diminish. Resource tagging helps with cost attribution but does not reduce spend directly. Right-sizing task definitions matters, but the real savings come from the structural decisions: Savings Plans, autoscaling, and knowing when Fargate is no longer the right tool.

When to consider moving off Fargate

Fargate makes sense when operational simplicity outweighs cost. For small teams, early-stage products, and workloads with unpredictable traffic, the premium is worth paying. But there is a point where the math stops working, and most growing teams hit it.

The signals are straightforward. Your monthly Fargate bill is large enough that a 2-3x cost reduction would meaningfully change your infrastructure budget. Your workloads are predictable, not bursty, so the serverless scaling model is not buying you much. You need GPUs, or you are hitting the 4 vCPU / 30 GB pod limits. You want deeper observability or more control over networking and scheduling. Any one of these is a reason to evaluate alternatives. Two or more together make a strong case.

The natural next step is managed Kubernetes on infrastructure that costs less. To put the difference in perspective:

The gap is not a rounding error. It is the difference between infrastructure cost being a line item and infrastructure cost being a constraint.

Moving from Fargate to Kubernetes does not have to mean taking on the operational burden that Fargate was designed to avoid. A managed Kubernetes platform handles cluster lifecycle, upgrades, scaling, and monitoring while giving you full access to the Kubernetes API and the flexibility that comes with it. You get GPU support, no pod resource caps, full observability, and your choice of cloud provider or on-premises hardware.

Cloudfleet provides managed Kubernetes with Hetzner integration that combines the operational simplicity of a managed platform with the cost efficiency of European cloud infrastructure. For teams looking to optimize their container infrastructure costs more broadly, our Kubernetes cost optimization approach covers multi-cloud strategies, right-sizing, and FinOps practices that go beyond any single provider’s pricing page.

Running predictable workloads and ready to move past the Fargate premium? See what managed Kubernetes with Cloudfleet costs for your infrastructure.