AWS Compute Optimizer’s New 32-Day Lookback: Better Rightsizing and a Lower AWS Bill for Free
Most businesses are paying for cloud capacity they do not use, and the reason is rarely waste for its own sake. It is uncertainty. Teams size an EBS volume or an ECS service for the worst week they can imagine, then never revisit it because nobody wants to be the person who shrank a resource right before month-end and caused a slowdown. AWS has just removed a chunk of that uncertainty. Learn how the AWS Compute Optimizer 32-day lookback improves EBS and ECS rightsizing recommendations. Discover how AWS Compute Optimizer 32-day lookback helps reduce AWS costs, optimize resource utilization, and maintain application reliability with more accurate insights.
The short version is this. Compute Optimizer looks at how your resources actually behave and then recommends a cheaper or better-fitting configuration. Until recently it only studied the last 14 days of usage for EBS and ECS, which often missed monthly patterns like billing runs, payroll, or end-of-month reporting. You can now tell it to look back 32 days instead, at the organization, account, or individual resource level, through the console, the AWS CLI, or the SDK. New recommendations that reflect a full monthly cycle start appearing within 24 hours. EC2 instances, EC2 Auto Scaling groups, and RDS databases already supported the longer window, so with EBS and ECS added, all five major resource types are now covered.
What Actually Changed in June 2026
The mechanics are simple, and that is the point. Compute Optimizer has always generated rightsizing recommendations by analysing utilisation metrics and comparing your current configuration against cheaper options that would still meet demand. The lookback period controls how much history feeds that analysis. A 14-day window is fine for workloads that look the same every day, but it is a poor fit for anything with a monthly rhythm. If your busiest day of the month falls outside that two-week window, the tool never sees it, and a recommendation made on a quiet fortnight can suggest a size that falls over when the real load arrives.
By moving EBS and ECS to a 32-day option, AWS lets the tool capture at least one full monthly cycle. That matters because so much business activity is monthly. Finance closes the books, e-commerce sees a payday spike, reporting jobs run on the first of the month, and batch processes catch up over a weekend. With 32 days of history, a recommendation accounts for those peaks instead of being blindsided by them. The feature is available in all Regions where Compute Optimizer runs, with the usual exceptions of the AWS GovCloud (US) and China Regions.
Why 14 Days Was Never Enough for Real Workloads
Think about a typical scale-up running a SaaS product on ECS with data on EBS. Traffic is reasonably flat Monday to Friday, then on the last working day of each month every customer logs in to pull reports, and a few large clients trigger exports that hammer disk throughput. On a 14-day lookback, there is a good chance Compute Optimizer never observes that day. It sees a calm fortnight, concludes the ECS service is over-provisioned, and recommends fewer tasks or smaller CPU. Follow that advice and your month-end turns into an incident.
This is exactly why a lot of engineering teams quietly ignored Compute Optimizer for these resource types. The recommendations felt twitchy and untrustworthy, so people left everything oversized to be safe. Oversized and safe is expensive, and it compounds. The 32-day window directly addresses the credibility problem. When the tool has seen your month-end and still says a volume or service can be smaller, that recommendation is far easier to act on, because it was made with the spike in view rather than in spite of it.
What This Means for Your EBS and ECS Spend
EBS and ECS are two of the easiest places for cloud spend to drift. EBS volumes get provisioned generously at launch and then never shrink, even after a workload settles into a predictable pattern. Old gp2 volumes sit at sizes and throughput nobody has questioned in two years. ECS services get task counts and CPU and memory reservations set during a nervous launch week and then stay there long after the traffic profile is understood. Neither tends to show up on a cost review because the individual numbers look small. Across a fleet, they are not small at all.
A 32-day rightsizing pass gives you a credible, data-backed list of which of those volumes and services can safely come down, and by how much. The value is not only the immediate saving. It is having evidence. When an engineer pushes back on shrinking a resource, a recommendation built on a full month of real utilisation is a much stronger basis for the conversation than a gut feeling on either side. It turns rightsizing from an argument into a review of the data.
How to Turn It On
You set the lookback preference at whichever level suits how you run AWS. If you manage a single account, set it there. If you run an AWS Organization, you can set it centrally so every account inherits the 32-day window, which is the sensible default for most companies that want consistent FinOps behaviour. You can also override the preference on individual resources when a specific workload has its own quirks. The setting lives in the Compute Optimizer console under rightsizing recommendation preferences, and the same change can be made through the AWS CLI or SDK if you prefer to manage it as code. Once changed, give it up to 24 hours for the new recommendations to populate.
There is no extra charge for the longer lookback. Compute Optimizer’s standard recommendations remain free, and the enhanced infrastructure metrics that some teams enable are billed separately as before. For most businesses, switching the window to 32 days is a no-cost change that strictly improves the quality of the advice.
The Catch: Recommendations Are Only as Good as Your Workload
A longer lookback makes recommendations better, but it does not make them infallible, and it is worth being honest about that. If your workload has a quarterly or seasonal peak, even 32 days will not capture it, so resources tied to a year-end surge or a seasonal sales event still deserve human judgement before you trim them. The tool also reflects how a resource behaved, not how you intend to use it next quarter, so a service about to absorb a new product launch should not be shrunk on the strength of a quiet month.
The right posture is to treat Compute Optimizer as a well-informed analyst rather than an autopilot. Let it find the candidates, then apply context before you act. The 32-day window simply means the analyst has finally read a full month of the report instead of half of it.
What to Do About It
Switch the lookback period to 32 days at the organization or account level today, then wait a day for recommendations to refresh. Start with EBS volumes and ECS services, since those are the newly covered types and the most likely to be carrying quiet waste. Sort by estimated monthly saving, take the obvious low-risk wins first, and flag anything tied to a launch or a seasonal event for a human decision. Re-run the review monthly so rightsizing becomes a habit rather than a one-off cleanup, and feed the savings back into your FinOps reporting so the work is visible.
If you would rather not pick through recommendations yourself, or you want a second pair of eyes before you resize production, HAZERCLOUD can help. We run cost and rightsizing reviews for growing UK, US, and European businesses on AWS, separating the safe savings from the risky ones and putting guardrails in place so your bill stays under control without putting reliability at risk. Book a free consultation and AWS cost assessment at https://hazercloud.com/contact/ and we will show you where the quiet waste is hiding.
