How Does AWS Cost Explorer Recommend Savings Plans?
AWS Cost Explorer recommends the optimal hourly dollar commitment for Amazon EC2 Savings Plans by analyzing historical On-Demand usage over a specified lookback period and simulating every possible commitment level to maximize total net savings. The engine evaluates hourly usage patterns across eligible compute services, translates On-Demand expenditures into discounted Savings Plans equivalents, and identifies the specific hourly commitment where the marginal savings from discounted usage outweigh the cost of any unused commitment during off-peak hours. This article explains the data inputs, mathematical optimization model, configuration parameters, and verification steps behind AWS Cost Explorer Savings Plans recommendations.
How the Recommendation Engine Analyzes Historical Usage
AWS Cost Explorer begins its analysis by inspecting your historical On-Demand compute usage at an hourly granularity. Depending on the Savings Plan type you select, the engine filters for eligible usage:
- Compute Savings Plans: Includes On-Demand usage across Amazon EC2 (regardless of instance family, size, OS, tenancy, or AWS Region), AWS Fargate, and AWS Lambda.
- EC2 Instance Savings Plans: Includes On-Demand usage for a specific EC2 instance family within a chosen AWS Region (regardless of instance size, OS, or tenancy).
For every hour \(t\) in the selected lookback period (\(T\) total hours, such as \(168\), \(720\), or \(1440\) hours for 7, 30, or 60 days), Cost Explorer examines the On-Demand instances and services that ran during that hour and retrieves their corresponding Savings Plans rates based on your selected term (1-year or 3-year) and payment option (No Upfront, Partial Upfront, or All Upfront).
Crucially, AWS applies Savings Plans to the usage that offers the highest discount percentage first during any given hour. Cost Explorer replicates this exact billing behavior during its simulation.
The Mathematical Optimization Model
To find the optimal hourly commitment \(C\) (measured in dollars per hour), Cost Explorer evaluates candidate commitment values and calculates the resulting total cost over the lookback period.
Suppose that in hour \(t\), you have \(N\) distinct buckets of eligible On-Demand usage. When ordered from the highest discount percentage to the lowest, bucket \(i\) has an On-Demand cost of \(O_{t,i}\) and a discount ratio of \(d_i\) (where \(0 < d_i < 1\)). The equivalent full-value Savings Plans rate for that usage is:
\[S_{t,i} = O_{t,i} (1 - d_i)\]
If you commit to \(C\) dollars per hour, your total expenditure in hour \(t\), denoted as \(\text{Cost}_t(C)\), consists of the fixed hourly commitment \(C\) plus any residual On-Demand cost that exceeds the commitment capacity:
\[\text{Cost}_t(C) = C + \sum_{i=1}^{N} \text{ResidualOnDemand}_{t,i}(C)\]
Specifically, as the commitment \(C\) is consumed across the ordered usage buckets \(i = 1, 2, \dots, N\):
- If the remaining commitment in hour \(t\) completely covers \(S_{t,i}\), the residual On-Demand cost for bucket \(i\) is \(0\).
- If the remaining commitment \(c_{\text{rem}}\) only partially covers \(S_{t,i}\), the covered fraction is \(\frac{c_{\text{rem}}}{S_{t,i}}\), leaving an uncovered On-Demand cost of:
\[\text{ResidualOnDemand}_{t,i}(C) = O_{t,i} \left(1 - \frac{c_{\text{rem}}}{S_{t,i}}\right) = O_{t,i} - \frac{c_{\text{rem}}}{1 - d_i}\]
- If total discounted usage in hour \(t\) is less than \(C\) (meaning \(\sum_{i=1}^{N} S_{t,i} < C\)), the residual On-Demand cost for that hour is \(0\), and the unused portion \(C - \sum_{i=1}^{N} S_{t,i}\) is simply wasted commitment for that hour.
Across all \(T\) hours in the lookback period, total Baseline On-Demand Spend is:
\[\text{Baseline} = \sum_{t=1}^{T} \sum_{i=1}^{N} O_{t,i}\]
Total Net Savings for a given hourly commitment \(C\) is:
\[\text{NetSavings}(C) = \text{Baseline} - \sum_{t=1}^{T} \text{Cost}_t(C)\]
AWS Cost Explorer searches for the commitment \(C^*\) that maximizes \(\text{NetSavings}(C)\):
\[C^* = \arg\max_{C \ge 0} \text{NetSavings}(C)\]
The Marginal Condition for Optimal Commitment
Because \(\text{NetSavings}(C)\) is a concave, piecewise-linear function of \(C\), the optimal commitment \(C^*\) occurs at the exact threshold where increasing the commitment by an additional \(\Delta C\) (for example, \(\$0.01\text{/hour}\)) stops yielding positive net savings across the \(T\) hours.
If every usage bucket in your environment had a uniform discount rate \(d\), increasing \(C\) by \(\$1.00\) saves \(\frac{1}{1 - d}\) dollars of On-Demand spend in every hour where your usage exceeds \(C\), and costs \(\$1.00\) in every hour. Thus, if \(p(C)\) represents the fraction of hours in the lookback period where your discounted usage is at least \(C\), the marginal change in total cost per hour is:
\[\frac{d}{dC} \left( \frac{1}{T} \sum_{t=1}^{T} \text{Cost}_t(C) \right) = 1 - \frac{p(C)}{1 - d}\]
Setting this derivative to zero reveals a clean rule of thumb:
\[p(C^*) = 1 - d\]
For example, if your average Savings Plans discount \(d\) is \(30\%\) (\(0.30\)), the optimal hourly commitment \(C^*\) corresponds to the usage level that is met or exceeded in at least \(70\%\) (\(1 - 0.30 = 0.70\)) of the hours in the lookback period. Even though \(C^*\) results in some unused commitment during the remaining \(30\%\) of low-traffic hours, the \(30\%\) discount captured during the \(70\%\) of active hours more than compensates for those idle hours.
Customizable Recommendation Parameters
In the AWS Cost Explorer console or via the AWS SDK/CLI
(GetSavingsPlansPurchaseRecommendation), you can adjust
four primary parameters that directly alter the calculation of \(C^*\):
- Savings Plans Type: Choosing Compute Savings Plans aggregates usage across EC2, Fargate, and Lambda globally, smoothing out regional or instance-family spikes and typically allowing a higher baseline commitment. Choosing EC2 Instance Savings Plans scopes the optimization to individual instance families per region, offering higher discount rates (\(d_i\)) at the cost of reduced flexibility.
- Term Length (1-year vs. 3-year): A 3-year term significantly increases the discount rate \(d_i\). Because \(1 - d_i\) becomes smaller, the break-even utilization threshold \(p(C^*)\) is lower, meaning Cost Explorer may recommend committing to usage that isn't even running \(100\%\) of the time if the 3-year discount is deep enough.
- Payment Option (No Upfront, Partial Upfront, All Upfront): Upfront payment options provide slightly higher discount rates \(d_i\). Cost Explorer normalizes All Upfront and Partial Upfront costs into an effective hourly rate so all commitments are expressed on an equivalent \(\$/\text{hour}\) basis.
- Lookback Period (7, 30, or 60 days): This sets \(T\). Select 7 days if you recently completed a major architecture migration or right-sizing initiative and want the recommendation to reflect your new steady state. Select 30 or 60 days to capture monthly or bi-monthly cyclical patterns.
- Account Scope (Payer vs. Linked Account): In an AWS Organizations setup, generating recommendations at the management (payer) account level pools hourly usage across all member accounts. Pooling reduces overall variance—when one account scales down, another might scale up—leading to higher utilization and larger combined net savings.
Accounting for Existing Commitments and Exclusions
AWS Cost Explorer does not analyze historical usage in a vacuum; it automatically factors in existing active commitments:
- Existing Reserved Instances (RIs) and Savings Plans: Cost Explorer only runs its optimization algorithm on the uncovered On-Demand usage remaining after existing RIs and active Savings Plans have been applied to each hour in the lookback window.
- Expiring Commitments: Any Savings Plans or Reserved Instances that expire before the lookback period ends (or are already expired at the time of calculation) are accounted for according to their active timestamps during the lookback window. If you have large commitments expiring next week, wait until after they expire and use a 7-day lookback window, or manually add their hourly value to the recommendation.
- Spot and Dedicated Host Usage: Spot Instances are excluded because they do not use On-Demand rates, though Dedicated Host On-Demand usage is eligible for Compute and EC2 Instance Savings Plans.
How to Verify and Adjust the Recommendation
While Cost Explorer optimizes mathematically for historical data, it cannot predict future business changes. Before purchasing the recommended hourly commitment \(C^*\), perform the following checks:
- Simulate Custom Commitments in Cost Explorer: Use the Savings Plans Recommendations simulator in the AWS Billing and Cost Management console to enter custom hourly dollar amounts above and below \(C^*\). Observe how the Estimated SavingsPlans utilization and Estimated On-Demand coverage curves shift.
- Check for Minimum Utilization Policies: Many FinOps teams enforce a strict policy requiring \(>95\%\) or \(100\%\) commitment utilization to avoid explaining "unused commitment waste" on financial reports, even when a lower utilization technically yields higher net savings. If your organization requires near-\(100\%\) utilization, choose an hourly commitment equal to your minimum hourly discounted usage (\(\min_t \sum_i S_{t,i}\)) rather than \(C^*\).
- Layer Commitments Incrementally: Instead of purchasing \(100\%\) of the recommended commitment \(C^*\) at once, purchase \(50\%\) to \(70\%\) first, monitor your Savings Plans Utilization and Coverage reports for a week, and then purchase additional smaller commitments to approach the optimal level safely.