AWS added a feature called Target Coverage to the Savings Plans Purchase Analyzer in the Billing and Cost Management console. In one sentence: you enter a coverage percentage of your On-Demand spend, and AWS calculates the exact hourly commitment that achieves it, with charts showing the cost and utilization at that level. It's available at no additional cost in every region that supports the Purchase Analyzer. That's the launch. The reason it matters more for seasonal direct-to-consumer brands than for almost anyone else is a problem the feature quietly fixes — one that has cost D2C brands real money for years.
The Purchase Analyzer's default mode is called Recommended. It looks at your usage over a lookback window and returns the commitment that maximizes your savings against that window. If you run it in early December — right after Black Friday and Cyber Monday, when finance is reviewing the year's spend and someone says "we should lock in a Savings Plan" — the Recommended number is sized to peak. You then commit to that number for one or three years. You spend the next ten months paying for compute capacity you used for two weeks.
TL;DR: The Savings Plans Purchase Analyzer's "Recommended" commitment is sized to your lookback window. For a seasonal D2C brand, running it post-peak produces a commitment sized to peak traffic you carry for the full term. Target Coverage lets you set a deliberate percentage of your baseline instead. If you want us to model your baseline coverage before finance signs a multi-year commitment, book a 30-min call with Dev — no SDR layer.
What Target Coverage Actually Adds
The Purchase Analyzer now offers three modes. Recommended returns the AWS-optimized commitment for maximum savings against your lookback. Custom lets you enter a specific dollar-per-hour commitment and see its effect. Target Coverage sits between them: you enter a whole-number coverage percentage from 10% to 100% of your On-Demand spend, and the analyzer calculates the hourly commitment required to hit it.
Around that core, you set the same parameters as any Savings Plan purchase: term length (1-year or 3-year), payment option (All Upfront, Partial Upfront, or No Upfront), and the lookback period the model draws from. The results render as interactive coverage, cost, and utilization charts built on hourly data, so you can see exactly how much of each hour your commitment would cover.
Two operational details make it genuinely useful for planning. You can exclude expiring plans from the calculation, which means you can model a renewal as if the old commitment were already gone — answering "what should I buy when this 1-year plan lapses next month" without the old plan distorting the math. And you can compare incremental coverage steps directly: model 80% against 90% and see what the last ten points of coverage cost you in commitment versus what they save you. That marginal view is where the over-commitment decision actually lives.
Why "Maximum Savings" Is the Wrong Target for a Seasonal Brand
Savings Plans trade a usage commitment for a discount — up to roughly 28% off On-Demand for Compute Savings Plans across EC2, Fargate, and Lambda. The discount only applies to usage you actually consume up to your committed dollar-per-hour. Commit to more than you use, and the unused portion of the commitment is money spent for nothing. Commit to less than you use, and the excess runs at full On-Demand price.
For a flat workload, the Recommended mode gets this right, because your usage tomorrow looks like your usage yesterday. For a seasonal D2C brand, usage has a shape: a tall, narrow peak in November and December, and a long stable baseline the rest of the year. The Recommended commitment, optimizing for savings against a lookback that includes or is dominated by the peak, lands somewhere above your baseline. Every hour outside peak season, you pay for the gap between that commitment and your actual usage.
The instinct that "more coverage equals more savings" is true only up to your baseline. Past that point, additional coverage is additional risk — you're betting that usage stays high enough to consume the commitment, and for a seasonal business that bet loses for most of the year. Our post on Reserved Instances versus Savings Plans for e-commerce covers which instrument to choose; Target Coverage is about how much of it to buy, which is the question that actually determines whether the commitment helps or hurts.
What Over-Committing Cost a Real D2C Brand
An $8M outdoor apparel brand we work with locked in a 3-year All Upfront Compute Savings Plan in December, the month after their biggest sales weekend of the year. Finance ran the Purchase Analyzer, took the Recommended number — roughly $14 per hour of commitment — got sign-off, and paid upfront for the full term.
Their actual compute told a different story. Peak season (November through early January) ran around $14–16 per hour. The other ten months ran a stable baseline of about $6 per hour. Blended across the year, their real average sat near $8 per hour. They had committed to $14.
The arithmetic of the gap: for roughly 6,500 off-peak hours a year, they were covering about $6 of usage against a $14 commitment — paying for $8 per hour of capacity they weren't running. That's around $52,000 a year of unused commitment, and on a 3-year All Upfront plan, that waste was locked in and prepaid. The "savings" the Recommended mode promised were real on the peak hours and a loss on every other hour.
With Target Coverage, the planning conversation inverts. Instead of "what does AWS recommend," the question becomes "what percentage of our On-Demand do we want covered, given that our baseline is $6 and our peak is $15." Setting Target Coverage to roughly 70% of their off-peak baseline would have produced a commitment near $6–7 per hour: deep, certain savings on the capacity that runs every hour of every day, with peak demand riding On-Demand for two months. The peak On-Demand spend is a known, bounded, seasonal cost — far cheaper than a year-round commitment to a peak that only shows up twice.
A multi-year commitment sized to peak is the most expensive way to "save" on AWS.
We model baseline-versus-peak coverage for D2C brands before any commitment gets signed — usually finding the right percentage sits well below the Recommended number. If you want that model for your account, grab 30 minutes with Dev. Written brief inside a week, no slide deck.
How to Set Coverage for a Seasonal Workload
The method that consistently produces a defensible commitment for a seasonal D2C brand:
1. Find your true baseline, not your average. Pull at least twelve months of hourly usage and identify the lowest stable monthly run-rate — the floor your compute never drops below. That floor is the capacity you are certain to use every hour for the full term. It is the only number safe to put on a 3-year commitment.
2. Set Target Coverage against that baseline, not your total. Covering 100% of a number that includes seasonal spikes re-creates the over-commitment problem. Covering 60–80% of your verified baseline leaves headroom for the baseline itself to dip — from a re-architecture, a workload migration, or a right-sizing pass — without stranding commitment. Use the incremental comparison view to see what moving from 70% to 80% costs versus saves before deciding.
3. Layer the terms. Put the certain baseline on a 3-year plan for the deepest discount. If you have a layer of usage that's stable but less certain — growth you expect but haven't realized — a 1-year plan covers it with less lock-in risk. Leave the seasonal peak on On-Demand. This produces a commitment stack that matches the shape of your usage instead of flattening it into one number.
4. Re-run after peak, with expiring plans excluded. Each year, model the next commitment using the exclude-expiring-plans option so the analyzer shows what to buy as your current plan lapses, rather than stacking a new commitment on top of one that's about to disappear. For the broader cost review this fits into, our post on 15 immediate AWS cost savings for e-commerce covers the right-sizing and storage work that should happen before you commit, since committing to un-optimized usage locks in the waste.
Where the Purchase Analyzer Still Needs a Human
Target Coverage answers "what commitment achieves this coverage percentage." It does not know your business. It cannot tell you whether next year's peak will be larger because of a planned product launch, smaller because you're moving a workload to a more efficient architecture, or whether a baseline that looks stable is about to shift because you're migrating off a service. Those judgments determine which coverage percentage is actually safe, and they require someone who knows both the infrastructure and the roadmap.
This is the same boundary that applies to the new AI tooling in billing — our post on Amazon Q in Cost Explorer covers a feature that explains your spend, but the same rule holds: the tool surfaces the numbers, a human decides what they mean for a multi-year financial commitment. For a seasonal brand, signing a 3-year Savings Plan is one of the larger infrastructure financial decisions of the year. Target Coverage finally gives you the dial to make it deliberately, instead of accepting a number sized to the wrong moment.
Frequently Asked Questions
What lookback period should a seasonal D2C brand use in the Savings Plans Purchase Analyzer?
The lookback period determines which historical usage the analyzer uses to model your commitment, and for seasonal businesses it's the single most dangerous setting. A 7-day or 30-day lookback run in early December reflects only peak traffic, so the Recommended commitment is sized to a level you won't see again for 11 months. If your account has a full trailing year of data, a 12-month lookback gives a blended picture that includes both peak and trough. But even a 12-month lookback in Recommended mode optimizes for total savings against that blended usage — which still over-weights peak hours. The cleaner approach is to ignore lookback-driven recommendations for the commitment decision and use Target Coverage set against your known baseline instead.
Should a seasonal business choose a 1-year or 3-year Savings Plan, and which payment option?
For the stable baseline portion of compute that runs year-round regardless of season, a 3-year No Upfront or Partial Upfront Compute Savings Plan captures the deepest discount on capacity you are certain to use for the full term. The risk with 3-year terms is committing to a level that includes any seasonal variability — so the 3-year commitment should be sized conservatively to the lowest monthly baseline you've seen across a full year, not the average. For the layer above baseline that flexes with season, either a 1-year plan or no commitment at all (running On-Demand for peaks) is the safer choice, because a 3-year commitment on capacity you only need two months a year wastes the discount for the other ten.
When should I still use the Recommended mode instead of Target Coverage?
Recommended mode is appropriate when your workload is genuinely stable — a SaaS backend or an internal platform with flat, predictable usage and no strong seasonality. In those cases the lookback-driven recommendation is sized to a level that reflects your real ongoing need, and accepting it captures maximum savings. Target Coverage is the better tool whenever your usage has a shape: seasonal peaks, growth trajectory, or a planned migration that will change your baseline. The two modes aren't mutually exclusive — you can run Recommended to see the savings ceiling, then use Target Coverage to model what committing to 60%, 70%, or 80% of your baseline actually costs and saves, and choose the percentage that matches how confident you are in that baseline holding.
About the author
AWS Practice Lead, Braincuber Technologies
Owns AWS architecture and cloud cost optimization at Braincuber. Designs production workloads on Bedrock, SageMaker, Lambda, and EC2 for US clients — averaging $4,200/month in cost savings on right-sizing audits.