AWS Compute Optimizer generates recommendations for EC2, EBS, Lambda, ECS, and RDS resources based on actual utilization patterns, not theoretical sizing guides. It's free, it's built into every AWS account, and most teams either ignore it entirely or apply its recommendations blindly without understanding the tradeoffs. Both approaches leave savings on the table or introduce risk.
Here's what Compute Optimizer actually finds in real accounts, and how to apply its findings without breaking anything.
What Compute Optimizer Actually Analyzes
Compute Optimizer uses CloudWatch metrics (CPU, memory where available via the CloudWatch agent, network, disk I/O) over a 14-day lookback period by default, comparing your actual resource usage against your provisioned capacity. It generates a finding classification — Optimized, Over-provisioned, Under-provisioned, or Not Optimized — for each resource, along with specific instance type or size recommendations.
The tool's biggest limitation: it only sees what CloudWatch sees. Without the CloudWatch agent installed, memory utilization isn't visible, which means EC2 recommendations for memory-bound workloads are working with an incomplete picture. Install the agent before trusting Compute Optimizer's EC2 recommendations for memory-intensive applications.
Common Findings We See in Real Accounts
EC2 over-provisioning is the most common and highest-value finding. In audits across multiple client accounts, a consistent pattern emerges: 30-45% of general-purpose EC2 instances are running at under 20% average CPU utilization, frequently the result of "size for peak, forget to resize" behavior after an initial capacity planning exercise that never gets revisited.
EBS volume type mismatches are common and easy to fix. Compute Optimizer regularly flags gp2 volumes that would perform equivalently (or better) on gp3 at lower cost — this is one of the safest, lowest-risk changes available since gp3 migration from gp2 requires no downtime.
Lambda memory over-allocation shows up frequently in functions where developers set memory conservatively high "to be safe" without profiling actual usage, not realizing Lambda cost scales directly with allocated memory regardless of whether it's used.
RDS instance class recommendations require the most caution. Compute Optimizer's RDS recommendations are directionally useful but don't account for connection pooling headroom, replication lag sensitivity, or planned growth — treat these as a starting point for investigation, not an instruction to resize immediately.
The Real Savings We've Measured
Across recent client engagements, applying Compute Optimizer's EC2 and EBS recommendations after manual validation has produced consistent savings in the 15-30% range on the audited compute and storage line items — not the full cloud bill, but a meaningful chunk of it. The variance depends heavily on how disciplined the team's original sizing process was; teams with mature capacity planning see smaller gains, teams that provisioned once and never revisited see the largest gains.
How to Apply Recommendations Without Breaking Production
Never bulk-apply recommendations without validation. Compute Optimizer flags a resource as over-provisioned based on historical utilization — it doesn't know about a planned traffic spike, a seasonal pattern outside its lookback window, or an upcoming feature launch that will change usage patterns.
Start with the highest-confidence, lowest-risk changes. EBS gp2-to-gp3 migrations and clearly over-provisioned non-production instances are safe starting points. Save production database resizing and anything touching customer-facing latency for a more careful, staged rollout.
Validate memory visibility before trusting EC2 memory-bound recommendations. If the CloudWatch agent isn't installed, install it and gather at least 14 days of real memory data before acting on any memory-sensitive resizing recommendation.
Resize in stages with monitoring, not all at once. Move one tier down, monitor for a full business cycle (including any weekly or monthly peak), then continue if metrics hold steady.
Re-run Compute Optimizer quarterly, not once. Usage patterns drift as your application and traffic evolve. A one-time audit misses the ongoing over-provisioning that naturally creeps back in as new services get deployed with conservative default sizing.
Where Compute Optimizer Falls Short
It doesn't recommend Savings Plans or Reserved Instance purchases (that's AWS Cost Explorer's Savings Plans recommendations, a separate tool), doesn't account for Spot Instance opportunities, and doesn't understand your application's actual availability requirements — it's a utilization tool, not a full FinOps strategy. Pair it with a broader cost optimization approach rather than treating it as a complete solution on its own.
Rutagon runs FinOps audits that combine Compute Optimizer findings with broader cost strategy and careful validation before any production change. Contact us to discuss a cost optimization audit for your AWS account.
Frequently Asked Questions
Is AWS Compute Optimizer free to use?
Yes, Compute Optimizer is included at no additional cost as part of your AWS account and analyzes EC2, EBS, Lambda, ECS, and RDS resources using existing CloudWatch metrics.
Why doesn't Compute Optimizer see my EC2 memory utilization correctly?
Memory utilization isn't visible to Compute Optimizer unless the CloudWatch agent is installed and configured on the instance. Without it, EC2 recommendations rely on CPU and network metrics alone, which can miss memory-bound over-provisioning.
How much can I realistically save by following Compute Optimizer recommendations?
Real-world results vary by how disciplined your original sizing process was, but many teams see 15-30% savings on the specific compute and storage resources analyzed, after manual validation of each recommendation before applying it.
Should I apply Compute Optimizer recommendations automatically?
No, we recommend against bulk automatic application. The tool doesn't know about planned traffic changes, seasonal patterns outside its lookback window, or upcoming feature launches. Validate each recommendation, especially for production and database resources, before applying.
How often should I check Compute Optimizer recommendations?
Quarterly is a reasonable cadence for most teams, since usage patterns drift as applications evolve and new services get deployed with conservative default sizing that gradually reintroduces over-provisioning.