AWS Fargate removes the operational burden of managing EC2 instances for containers — no patching, no capacity planning, no idle nodes. It does not remove the cost-management burden; it relocates it. Fargate bills per vCPU-second and per GB-second at the task level, which means every over-provisioned task definition is a permanent tax on every task run for the life of the service, not a one-time misconfiguration.
Teams that migrate from EC2-backed ECS to Fargate and expect the bill to shrink are often surprised when it grows instead — not because Fargate is inherently more expensive, but because nobody carried EC2-era rightsizing discipline into task definition sizing.
The vCPU-Memory Ratio Trap
Fargate only supports specific vCPU-to-memory combinations, not arbitrary values. A task defined with 1 vCPU and 8 GB memory bills for the full 1 vCPU-hour and 8 GB-hour rate regardless of whether the workload uses 200m of CPU and 512 MB of memory — there's no bin-packing benefit like you'd get consolidating light workloads onto a shared EC2 node.
The fix starts with actual utilization data, not the task definition someone wrote during initial setup and never revisited:
# Pull average and p95 CPU/memory utilization for a Fargate service over 14 days
aws cloudwatch get-metric-statistics \
--namespace AWS/ECS \
--metric-name CPUUtilization \
--dimensions Name=ClusterName,Value=production Name=ServiceName,Value=api-service \
--start-time "$(date -u -d '14 days ago' +%Y-%m-%dT%H:%M:%S)" \
--end-time "$(date -u +%Y-%m-%dT%H:%M:%S)" \
--period 3600 \
--statistics Average Maximum
If p95 CPU sits at 25% of the provisioned vCPU and p95 memory sits at 40% of provisioned memory, the task is a candidate for the next size down — Fargate's supported combinations step down in fixed increments (0.25/0.5/1/2/4 vCPU with corresponding memory ranges), so rightsizing is a lookup against the supported table, not a guess.
Fargate Spot for Interruption-Tolerant Workloads
Fargate Spot offers up to 70% savings over standard Fargate pricing for workloads that can tolerate interruption with a 2-minute warning — batch processing, CI/CD runners, async job workers, and non-customer-facing background services are the common fits. Production request-serving tasks generally aren't, unless the service is built with graceful draining and enough replica headroom to absorb an interruption without a customer-visible blip.
{
"capacityProviderStrategy": [
{ "capacityProvider": "FARGATE_SPOT", "weight": 3, "base": 0 },
{ "capacityProvider": "FARGATE", "weight": 1, "base": 2 }
]
}
This capacity provider strategy keeps a guaranteed base of 2 tasks on standard Fargate (for baseline availability during a Spot interruption event) while routing the majority of scaled-out capacity to Spot pricing — a pattern that works well for services with variable load and a tolerance for brief capacity dips during Spot reclaim events.
The Fargate Cost Nobody Budgets For: Data Transfer and ENI Overhead
Every Fargate task gets its own elastic network interface when running in awsvpc network mode, which is the only supported mode for Fargate. This isn't a direct line-item cost, but it caps the number of tasks per subnet based on available IP addresses and interacts with NAT Gateway data processing charges — every outbound call from every task routes through the same NAT path, and Fargate's per-task network isolation means there's no shared connection pooling at the instance level the way there would be on EC2-backed ECS. High task-count services making frequent external calls (third-party APIs, S3, other AWS services outside the VPC) should route through VPC endpoints where available rather than the NAT Gateway — the endpoint eliminates the NAT data processing fee entirely for AWS service traffic.
What a Fargate Cost Review Actually Checks
- Task definition vCPU/memory against 14-day p95 utilization, not launch-day guesses
- Fargate Spot eligibility for interruption-tolerant services, with a standard-Fargate base for availability
- NAT Gateway data processing charges attributable to Fargate task egress, and VPC endpoint coverage gaps
- Idle or zero-desired-count services still holding reserved task slots
- Log driver configuration — CloudWatch Logs ingestion from high-volume Fargate tasks is a frequently overlooked line item on its own
Frequently Asked Questions
Is Fargate more expensive than EC2-backed ECS?
Per-vCPU-hour, Fargate carries a premium over equivalent EC2 On-Demand pricing — you're paying for the removal of instance management. Where Fargate wins on total cost is workloads with variable or bursty load, where EC2 capacity would otherwise sit idle between spikes; where it loses is steady, high-utilization workloads that would bin-pack efficiently onto EC2 nodes with a scheduler like Karpenter.
How much can Fargate Spot actually save?
AWS publishes Fargate Spot pricing at up to 70% below standard Fargate rates, consistent with Spot pricing for other compute types. Realized savings depend on interruption frequency and how much standard-Fargate base capacity a service needs to hold for availability during reclaim events.
Does rightsizing Fargate tasks risk performance problems?
Sizing to p95 rather than peak utilization, with a reasonable margin, is standard practice and shouldn't introduce throttling under normal load. The risk is sizing to average utilization, which under-provisions for real traffic spikes — always size against p95 or higher, never the mean.
What's the fastest first fix for a Fargate bill that's grown unexpectedly?
Pull utilization data for the top 5 highest-task-count services and check them against the Fargate supported vCPU/memory table — oversized task definitions from initial setup are the most common and highest-impact finding, and the fix requires no architecture change, just a task definition revision.
Do Fargate costs show up cleanly in AWS Cost Explorer?
Fargate costs appear under Amazon ECS or Amazon EKS in Cost Explorer depending on the orchestrator, but per-service and per-task-definition breakdowns require either Container Insights or a tagging strategy applied at the service level — Cost Explorer alone won't tell you which specific service is driving the bill without that additional instrumentation.
Rutagon runs AWS cost audits that go past the dashboard-level view — task definition sizing, Spot eligibility, and NAT/endpoint routing analysis included in the same 2-week engagement.
Talk to us about a cost optimization audit → rutagon.com/contact | 907-841-8407 | contact@rutagon.com
Related reading: Aurora Serverless v2 Cost Optimization Guide · AWS NAT Gateway Cost Reduction Guide · AWS Cloud Infrastructure Capability
External reference: AWS Fargate Pricing Documentation