AWS Compute Optimizer — Stop Guessing, Start Rightsizing

AWS Compute Optimizer has been recommending right-sized EC2, EBS, Lambda, RDS, Aurora, and ECS resources since 2019. Most teams enable it, glance at the dashboard, and leave everything on defaults. That's a missed opportunity — because the defaults are conservative by design, and your workload almost certainly isn't a one-size-fits-all pattern.

In this post I'll walk through every tunable knob in Compute Optimizer's Rightsizing Preferences: what each setting actually means, when to change it, and how to lock recommendations to the exact instance families running in your environment.

What Compute Optimizer does — and what it covers

Compute Optimizer uses machine learning on CloudWatch utilization metrics to detect over-provisioned and under-provisioned resources and recommend optimal replacements. It works across:

Rightsizing preferences — the focus of this post — apply primarily to EC2 and EC2 ASG recommendations, with lookback period options also available for EBS and RDS.

Rightsizing Preferences — the overview

Navigate to Compute Optimizer → Preferences → Rightsizing. Select the resource type (EC2 instances including ASG is the most feature-rich) and preference level (organization, account, or regional).

You'll land on the current defaults summary. For EC2 + ASG, the default state shows:

Hit Edit and you're walked through a four-step wizard: Regional scope → Lookback period & metrics → Preferred EC2 instances → Review & save.

Lookback period: 14, 32, or 93 days

This is the first thing to tune. The lookback period determines how many days of CloudWatch utilization data Compute Optimizer uses to generate recommendations.

The 93-day option requires enabling Enhanced Infrastructure Metrics. When you click it in the console, you'll see the confirmation dialog before it activates:

For EBS volumes, the console shows only 14 or 32 days (no 93-day option). Same for ECS. The 93-day window is EC2/ASG-specific.

Utilization presets: Max savings → Max performance

This is the most impactful setting most teams never touch. Compute Optimizer gives you four named presets that bundle a CPU threshold (P90/P95/P99.5) and CPU headroom (0%/20%/30%) together into a single choice.

Here's exactly what each preset configures under the hood:

Preset	CPU Threshold	CPU Headroom	Best for
Max savings ↓ Cost	P90	0%	Non-production, dev/test environments where peak spikes are acceptable and cost pressure is high
Balanced	P95	30%	General-purpose workloads with moderate sensitivity to peak utilization — a good middle ground
Default Default	P99.5	20%	The out-of-box setting. Conservative — suited for most production workloads without customization
Max performance ↑ Perf	P99.5	30%	Mission-critical production where performance headroom matters more than cost savings

CPU metrics: threshold (P90 / P95 / P99.5) + headroom

Understanding P-values here is important. The threshold determines which data points Compute Optimizer considers when analyzing your CPU history.

Threshold — what P90, P95, P99.5 mean in practice

Over a 14-day period at 5-minute CloudWatch resolution, you have roughly 4,032 data points per instance.

• P99.5 (default) — ignores the top 0.5% of highest CPU data points (~20 data points). Best for sensitive production workloads where occasional spikes genuinely stress the system.
• P95 — ignores the top 5% (~200 data points). More tolerant of brief spikes. A reasonable middle ground for workloads that burst occasionally but not critically.
• P90 (least sensitive) — ignores the top 10% (~400 data points). Aggressive. The recommendation will be tuned to non-peak steady-state load. Use only for workloads where those spikes genuinely don't matter — dev/test, batch jobs with retry logic, etc.

Headroom — buffer capacity on top of observed peak

Headroom adds a percentage buffer above the observed utilization ceiling, so the recommended instance has room to absorb burst above what history recorded.

• 0% headroom — no extra capacity. Recommendation is sized exactly to the threshold utilization level. Maximises savings, minimises buffer.
• 20% headroom (default) — recommended instance has 20% CPU overhead above the observed threshold peak. The AWS-tested sensible default.
• 30% headroom — higher buffer. Used in Balanced and Max performance presets. Good when your workload has unpredictable growth or you want a comfortable safety margin in production.

Memory utilization headroom

Memory preferences are simpler — there's no threshold setting, only headroom (10%, 20%, or 30%). The memory headroom chart shows a much smoother utilization line than CPU, which is typical — memory tends to be allocated rather than bursty.

Preferred EC2 instances — locking to your host family

This is the setting that directly answers the dedicated host question. If your organisation has committed to a specific instance family — say r6i on dedicated hosts — you don't want Compute Optimizer suggesting m7g, c6a, or anything outside your licensed footprint. Preferred instances let you constrain the recommendation output.

Here's how to configure this for a dedicated host running r6i instances:

EBS volume preferences

EBS has its own preferences section, separate from EC2. The options are simpler — only lookback period is configurable (14 or 32 days). No threshold or headroom controls.

Switching EBS to 32 days is free and worth doing — monthly storage patterns (snapshot schedules, nightly ETL writes, month-end archiving) won't show up in a 14-day window and can lead to over-sized volume recommendations if your workload is genuinely spiky on a monthly cadence.

Regional scope + how preferences propagate

Every preference set is scoped. The hierarchy is: Organization → Account → Region. A more specific scope overrides a broader one for that resource.

Which preset should you actually use?

Here's a practical decision matrix based on workload type — not the marketing names:

Workload	Recommended preset	Lookback	Notes
Dev / test environment	Max savings	14 days	Cost matters more than peak headroom. Workload retries are acceptable.
Batch / scheduled jobs	Max savings or Balanced	32 days	32-day lookback essential to capture monthly batch patterns.
General web / API workloads	Default	32 days	P99.5 + 20% headroom + 32-day lookback is a solid general-purpose config.
Stateful production (DB, cache)	Max performance	32 or 93 days	P99.5 + 30% headroom. If quarterly patterns exist, enable enhanced metrics for 93 days.
Dedicated hosts (r6i, etc.)	Default or Max performance	32 days	Pin preferred EC2 instances to the host family. This is the critical step — without it the preset choice is secondary.

None of this is a "set and forget" configuration. As your workloads evolve — new deployments, scaling events, architectural changes — revisit your preferences. The Rightsizing preferences page shows a summary of current settings, and every preference change regenerates recommendations within 24 hours.

Compute Optimizer is one of the few AWS services where the recommendations improve the more you tell it about your constraints. The defaults are intentionally conservative — override them where you know better.