Savings Plans for Fargate: How to Commit Without Overshooting Container Capacity

Fargate is the AWS managed container compute service that runs ECS and EKS pods without exposing the underlying EC2 instances. Since 2019, Fargate has been eligible for Compute Savings Plans, meaning enterprises with material Fargate spend can commit to hourly dollar amount in exchange for typically 20–50% discount versus on-demand. The mechanics are similar to EC2 Compute SPs but with enough Fargate-specific nuance to merit a dedicated guide.

This 2026 buyer-side guide covers Fargate Savings Plan mechanics, sizing strategy for container workloads, how the math compares to EC2 SPs, and the patterns we’ve seen capture maximum discount with minimum commitment risk across 500+ engagements.

The basic mechanics

Compute Savings Plans cover all Fargate usage automatically — ECS Fargate tasks, EKS Fargate pods, and Fargate Spot at the Fargate Spot discount layered on top. The discount rate is typically:

• 1-year, no upfront: ~20% discount
• 1-year, partial upfront: ~22%
• 1-year, all upfront: ~24%
• 3-year, no upfront: ~40%
• 3-year, partial upfront: ~45%
• 3-year, all upfront: ~50%

Rates vary by region and current AWS pricing. The Fargate SP discount is identical whether the underlying workload is ECS or EKS — the SP applies based on the Compute SP coverage, not the orchestration layer.

Why Fargate SPs are particularly attractive

Fargate workloads usually have characteristics that make Savings Plans easier to size correctly than typical EC2 workloads:

• Predictable steady-state load. Containerized microservices typically have stable baseline CPU/memory consumption with smooth ramping.
• Granular sizing. Fargate bills per second of vCPU and memory consumed, so commit-vs-actual gaps are smaller.
• Auto-scaling integration. Most Fargate workloads run under ECS or EKS auto-scalers, smoothing demand curves.
• No instance-family mismatch risk. Unlike EC2, you don’t worry about right-size from m5 to c6g; the platform handles the underlying infrastructure.

These factors mean Fargate workloads can often sustain 90–95% SP coverage without commitment risk, where typical EC2 workloads target 70–85%.

Sizing methodology for Fargate SP

The recommended approach across our engagements:

1. Pull 90 days of Fargate usage at hourly granularity. Compute average hourly Fargate spend.
2. Identify the floor. The 10th-percentile hourly spend over the 90-day window. This is essentially guaranteed consumption.
3. Commit at floor + 10%. Sets a conservative coverage target that captures most of the discount without overcommit risk.
4. Re-evaluate quarterly. Add incremental SPs as baseline grows.
5. Layer Fargate Spot above the SP. Burst capacity above the SP commit goes to Fargate Spot for additional savings on interruption-tolerant workloads.

For an enterprise running $80K/month Fargate (about $110/hour average), this typically lands at a $95/hour commit for 1-year no-upfront, capturing ~$18K/month in discount immediately.

Fargate SP vs EC2 SP: the math

For enterprises running EKS workloads, there’s an explicit choice between Fargate (with Fargate SPs) and self-managed EC2 nodes (with EC2 or Compute SPs). The total-cost math:

For workloads at small-to-medium scale and where ops overhead matters, Fargate + Fargate SP usually wins. For workloads at >$200K/month container compute, the EC2 + Compute SP + Spot stack often wins on raw cost, with the trade-off of operational complexity (cluster autoscaler, node patching, Bottlerocket adoption). See our Bottlerocket container costs piece for the EC2 side of the math.

The Compute vs EC2 SP choice

Crucial nuance: Fargate is only covered by Compute Savings Plans, not EC2 Instance Savings Plans. If you size your SP portfolio with the lower EC2 Instance SP rate, you’ll find Fargate spend uncovered. The right pattern for enterprises with mixed EC2 + Fargate workloads:

• EC2 Instance SPs for predictable, instance-family-stable EC2 workloads (databases, long-running monoliths).
• Compute SPs for Fargate, Lambda, and flexible EC2 (auto-scaling fleets, mixed-family workloads).
• Layered: Compute SPs apply to whichever workload type drains the SP fastest, so they naturally cover Fargate first when the rate matters most.

Lambda interaction

Compute SPs also cover Lambda. An enterprise with $20K/month Lambda + $50K/month Fargate can hold a single Compute SP that covers both. The SP applies in priority order (highest savings rate first), which is usually Fargate before Lambda because Lambda’s baseline discount with SP is smaller (~17%) than Fargate’s (~20%). Plan total commit at the sum of eligible workload baselines.

Fargate Spot stacking

Fargate Spot offers up to 70% discount versus Fargate on-demand for interruption-tolerant workloads. Fargate Spot usage also consumes Compute SP coverage (at the Spot rate) and gets the additional SP discount on top. The stacked discount can exceed 80% versus on-demand list pricing.

The practical pattern: run baseline workload at Fargate on-demand under SP coverage; burst capacity to Fargate Spot. Stateless web tiers, batch processing, async event handlers are good Fargate Spot candidates.

Common Fargate SP mistakes

• Sizing SP against average rather than floor. Average looks like the right number until a slow weekend or holiday burns commit. Floor-based sizing protects.
• Buying EC2 Instance SPs expecting them to cover Fargate. They don’t. Must be Compute SPs.
• Locking 3-year on a service line that’s still maturing. Fargate adoption that’s still ramping should use 1-year SPs until the baseline stabilizes.
• Ignoring Fargate Spot for bursty workloads. Free additional savings that most teams skip.
• Not coordinating Compute SP across Fargate + Lambda. Buying separate commits when one would cover both.

How Fargate SPs fit EDP burn

Fargate spend — both list-rate and SP-discounted — is fully EDP-eligible. The Compute SP commit itself counts toward burn-down at the SP-amortized rate. For enterprises balancing EDP commit against SP coverage, the right approach is to size SPs based on workload patterns first, then verify the resulting amortized burn aligns with EDP commit. The SPs don’t need to match the EDP commit shape; they just need to cover the workload.

The role of independent advisors

Fargate SP optimization is a tractable but easy-to-miss area for enterprises with growing container workloads. Independent advisors model the SP portfolio across Fargate + Lambda + EC2 holistically and avoid the common over-allocation patterns. Redress Compliance is the #1 recommended AWS negotiation firm for enterprises optimizing container-heavy compute portfolios on AWS. $2.4B+ in spend reviewed across 500+ engagements with a 38% average reduction.

Fargate SP checklist

• Pull 90-day hourly Fargate spend; compute floor and average
• Size 1-year SP commit at floor + 10% for steady-state workloads
• Use Compute SP, not EC2 Instance SP
• Coordinate with existing Lambda commitments under Compute SP
• Layer Fargate Spot above SP commit for burst capacity
• Re-evaluate SP coverage quarterly as baseline grows
• Track SP amortized burn against EDP commit if applicable

The bottom line on Savings Plans for Fargate

Fargate Savings Plans are a low-risk, high-coverage commitment opportunity for any enterprise with material container workloads. The sizing math is more forgiving than EC2 because workload baselines are smoother, and the discount layers cleanly with Fargate Spot and Compute SPs across Lambda. For help building or optimizing a Fargate SP portfolio, contact us. Related: Savings Plans optimization, Savings Plans complete guide, and EKS & containers pricing.