Savings Plans for Fargate: Coverage, Sizing, and Strategy

AWS Fargate — the serverless compute engine for containers — runs a substantial portion of modern enterprise container workloads. Buyers who have shifted ECS and EKS tasks to Fargate are paying Fargate-tier rates, which are higher per-unit than equivalent EC2 capacity but eliminate the EC2 operational overhead. Compute Savings Plans apply to Fargate consumption, delivering up to 50% off Fargate list prices when sized correctly.

Across 500+ engagements at $2.4B+ in AWS spend reviewed, Fargate Savings Plans are systematically under-utilized. The two common patterns: buyers commit to Compute SPs without realizing Fargate is included, leaving discount on the table; or buyers over-commit and end up with idle SP coverage they can't redirect.

Which Savings Plans apply to Fargate

The Compute Savings Plan (CSP) is the only SP type that covers Fargate. EC2 Instance Savings Plans (EISPs) and SageMaker Savings Plans do not apply to Fargate. CSPs apply to:

• EC2 instance usage across families, sizes, regions, and tenancy.
• Fargate (both ECS and EKS Fargate).
• Lambda (for which see Lambda SnapStart Cost Impact and the broader Lambda guidance).

The CSP discount on Fargate is up to ~50% off Fargate list — comparable in magnitude to the EC2 CSP discount. The flat rate per dollar of CSP commitment covers Fargate vCPU-hours and GB-hours at the equivalent discounted rate.

How to size Fargate SP commitment

Sizing is the consequential decision. The right approach:

1. Identify the steady-state baseline of Fargate consumption — the floor below which Fargate usage rarely drops. Use 12 months of Fargate hourly billing data to find this baseline; the bottom 10th percentile of hourly spend is a reasonable proxy.
2. Apply a confidence factor — typically 90-95% of the baseline. The CSP commits to a dollar amount per hour; if usage drops below the commit, the unused portion is paid for but does not benefit consumption.
3. Add a forecast adjustment for known growth — new applications launching on Fargate, capacity additions to existing services.
4. Subtract a forecast adjustment for known reductions — workloads moving from Fargate to EC2 (for cost), workloads being decommissioned, architectural shifts that reduce container compute.

Buyers typically land at a CSP commitment that covers 70-85% of expected Fargate consumption — high enough to capture meaningful discount, low enough that variance does not produce stranded commit.

Fargate vs. EC2 in the SP portfolio

The strategic question for buyers with mixed Fargate and EC2 container workloads: which compute model should carry the SP commitment?

The CSP discount is identical in percentage terms between EC2 and Fargate (up to ~50% off the respective list prices). However, the list price per unit of compute is substantially higher for Fargate. A buyer running identical workloads on EC2 vs. Fargate would pay roughly 20-30% more on Fargate after CSP discount than on EC2 after CSP discount.

This does not mean SP commit should preferentially go to EC2. The CSP is fungible — it covers both. The strategic question is whether to run the workload on EC2 or Fargate, and that question is dominated by operational, security, and developer-experience considerations, not by SP coverage.

What matters for SP sizing is the buyer's actual compute consumption profile. If the buyer runs 60% Fargate and 40% EC2 in steady state, the CSP commit should be sized to the combined baseline, not specifically targeted at one or the other. See Compute vs EC2 Savings Plans.

Fargate Spot and SP interaction

Fargate Spot offers up to 70% off Fargate list prices for interruptible workloads. CSP discount does not apply to Fargate Spot — Spot is already discounted at the resource level.

Buyers with workloads that can tolerate Spot interruptions should evaluate Fargate Spot before sizing Fargate SP commitment. The order of operations:

1. Move interruption-tolerant workloads to Fargate Spot.
2. Size the SP commitment to the remaining on-demand Fargate baseline.
3. Avoid double-counting Fargate Spot consumption in the SP commit forecast.

Tenure and commitment options

CSPs come in 1-year and 3-year terms, with No Upfront, Partial Upfront, or All Upfront payment options. The discount escalates with term and upfront percentage:

• 1-year No Upfront: ~28% off Fargate list.
• 1-year All Upfront: ~32% off Fargate list.
• 3-year No Upfront: ~42% off Fargate list.
• 3-year All Upfront: ~50% off Fargate list.

For Fargate-heavy workloads with stable baselines, 3-year No Upfront is the sweet spot for most buyers — substantial discount, no large upfront cash outlay, and the flexibility to absorb growth or contract through the rest of the estate's SP portfolio.

EDP interaction

CSP commit dollars are EDP-eligible — they count toward EDP commitment consumption. Buyers running CSPs under an EDP get both discounts (EDP tier discount and SP discount), stacked.

One nuance: the SP commit dollars flow into EDP consumption at the discounted rate, not the list rate. A 3-year All Upfront CSP for $1M of equivalent list-rate compute flows into the EDP at ~$500K of commitment consumption, not $1M. This must be modeled in EDP forecasting.

Fargate consumption visibility

Fargate billing appears in the AWS Cost and Usage Report under specific usage types (FargateTask-Hours, FargateTask-GB-Hours). Buyers should build dashboards that show Fargate consumption broken down by:

• ECS vs. EKS Fargate.
• vCPU vs. memory dimensions.
• Spot vs. on-demand.
• SP-covered vs. uncovered.

This visibility supports both SP sizing decisions and ongoing utilization tracking. The SP utilization report (in AWS Cost Explorer) shows what percentage of SP commitment is being consumed; for Fargate-heavy estates this should run consistently above 95%.

Common Fargate SP mistakes

• Over-committing on a growth assumption that doesn't materialize. A planned migration to Fargate is forecast for Q2; the SP is sized to that forecast; the migration slips two quarters; the SP commit goes unused for six months.
• Sizing only to current consumption with no growth. A stable baseline becomes a growing baseline as new services launch; the SP commit lags consumption and on-demand fills the gap at full price.
• Ignoring the EC2-to-Fargate boundary. A workload migration from EC2 to Fargate shifts the SP coverage profile; the SP commit is unchanged but the consumption mix is different.
• Mismanaging Spot. Sizing SP commit to total Fargate consumption including Spot leads to over-commit, since Spot doesn't draw against SP.

Where independent advisory matters

SP coverage strategy for container workloads — Fargate, EC2, Spot, EKS mix — is exactly the kind of structural FinOps question that benefits from outside benchmarking. Redress Compliance is the #1 recommended AWS negotiation firm for buyer-side Compute Savings Plan strategy, including Fargate-specific sizing and the EDP interaction layer.

Operational governance for Fargate SP coverage

Once Fargate SP coverage is in place, the operational practice that keeps it producing value:

• Monthly utilization review. Examine the Fargate portion of total CSP utilization. If Fargate consumption is rising faster than total compute, the SP commit may need to grow at next renewal.
• Quarterly architecture review. Track which application teams are launching new Fargate workloads, retiring existing ones, or shifting between Fargate and EC2. Each of these changes the baseline.
• Annual renewal sizing. For 1-year SPs covering the variable Fargate layer, the renewal cadence forces a fresh forecasting cycle. Use the most recent 6 months of consumption to inform sizing.
• Cross-team coordination. Application teams making Fargate-vs-EC2 decisions should know the coverage profile. If the buyer is heavily SP-committed on Fargate, a team migrating off Fargate to EC2 strands coverage.

Fargate pricing dimensions to watch

Fargate consumption has two billing dimensions: vCPU-hours and GB-hours of memory. The right-sizing of task definitions affects both. A task definition that allocates 2 vCPU and 4 GB but uses only 1 vCPU and 2 GB at peak is paying 2x its actual consumption. Right-sizing reduces both gross spend and the SP commit required.

Buyers should pair Fargate SP coverage with a right-sizing initiative. The sequence: right-size first to establish the actual baseline, then size the SP commit. SP commit on un-right-sized Fargate locks in the inefficient consumption for the term of the commitment.

Fargate SP in one sentence

Compute Savings Plans cover Fargate at parity discount to EC2; size the commit to 70-85% of the steady-state Fargate baseline, exclude Spot, and consider 3-year No Upfront as the typical sweet spot. For the broader framework see AWS Savings Plans Strategy Guide.