AWS Services
AWS Compute Optimizer
Understand AWS Compute Optimizer for rightsizing recommendations, including supported resources, CloudWatch metrics, enhanced infrastructure metrics, findings, recommendation preferences, cost and performance tradeoffs, and SAA-C03 traps.
After this, you will understand
Compute Optimizer helps learners see rightsizing as data-driven architecture hygiene, not guesswork.
Compute Optimizer analyzes utilization metrics and recommends better resource configurations for supported AWS compute resources.
Learners treat every recommendation as automatically safe or confuse rightsizing recommendations with real-time scaling.
Use Compute Optimizer to identify overprovisioned, underprovisioned, and optimized resources before making resizing or commitment decisions.
Think before readingWhat is the clean distinction between Compute Optimizer and Auto Scaling?
Reading in progress
This page is saved in your local study history so you can continue later.
Study path
Read these in order
Start with the mechanics, then move into the patterns that explain why the system is shaped this way.
Concepts Covered
- AWS Compute Optimizer
- Rightsizing recommendations
- Supported resources
- CloudWatch metric analysis
- Findings: overprovisioned, underprovisioned, optimized
- Recommendation options
- Enhanced infrastructure metrics
- Cost and performance tradeoffs
- Compute Optimizer versus Trusted Advisor and Auto Scaling
- SAA-C03 traps
1. Plain-English Mental Model
AWS Compute Optimizer is a rightsizing recommendation service.
The simple model is:
historical utilization metrics -> Compute Optimizer analysis -> sizing recommendations
It looks at resource usage patterns and recommends better configurations for supported AWS resources. The goal is to reduce waste, improve performance, or both.
If an EC2 instance is mostly idle, Compute Optimizer may recommend a smaller type. If an instance is consistently stressed, it may recommend a larger or different type. If a resource looks well matched, it may mark it optimized.
It is an advisory service. It does not automatically rewrite your architecture.
2. Why This Service Exists
Right-sizing is harder than it sounds.
Teams often choose large instances "just to be safe." Databases get oversized before launch. Auto Scaling groups keep old instance families. Lambda memory settings are guessed. EBS volumes are provisioned with more IOPS than needed.
Those choices become invisible once the system is running, especially if nothing is failing.
Compute Optimizer exists to turn utilization history into practical recommendations.
For SAA-C03, it appears when the question asks for identifying overprovisioned or underprovisioned compute resources, improving performance and cost using recommendations, or right-sizing workloads based on metrics.
3. The Naive Approach And Where It Breaks
The naive pattern is:
pick instance size during launch -> never revisit it
This breaks because workload behavior changes. Traffic grows, code gets slower, traffic falls, caches improve, batch windows change, and newer instance families become available.
Another naive pattern is choosing the cheapest smaller instance without checking performance. That can save money while increasing latency or error rates.
A third mistake is buying Savings Plans before right-sizing. If you commit to waste, you make the waste cheaper but more durable.
Compute Optimizer helps start the conversation with data, but engineers still need to validate recommendations against workload behavior.
4. Core Primitives
A finding describes whether a resource appears optimized, overprovisioned, or underprovisioned.
A recommendation suggests one or more alternative configurations.
Supported resource types include EC2 instances, Auto Scaling groups, EBS volumes, Lambda functions, ECS services on Fargate, commercial software licenses, and other supported resources according to current AWS documentation.
CloudWatch metrics provide the utilization data Compute Optimizer analyzes.
Enhanced infrastructure metrics can extend the lookback period for supported resources.
Recommendation preferences let organizations tune recommendations, such as preferred instance families or risk settings.
Estimated savings and performance risk help teams weigh cost versus behavior.
Organizations integration can allow management accounts or delegated administrators to view recommendations across accounts.
5. Architecture Use Cases
Use Compute Optimizer before purchasing Savings Plans:
current resource metrics -> rightsizing recommendations -> stable baseline -> commitment decision
Use it to find idle or oversized EC2 instances in development accounts.
Use it to identify underpowered production instances before performance incidents worsen.
Use it to review Lambda memory settings where duration, memory, and cost interact.
Use it to review EBS volume performance settings.
Use it with Auto Scaling groups to modernize instance families or adjust group-level capacity decisions.
Use it during Well-Architected cost optimization reviews as supporting evidence.
7. Security Model
Compute Optimizer needs permission to access utilization and resource metadata. Access to recommendations is controlled by IAM.
Recommendations can reveal workload behavior, resource names, utilization patterns, and cost opportunities. Treat organization-wide reports as internal operational data.
In Organizations, delegated administrator access should be restricted to trusted platform or FinOps roles.
Compute Optimizer does not grant permission to modify resources. Separate IAM permissions control whether a user can resize EC2 instances, modify EBS volumes, change Lambda memory, or update Auto Scaling groups.
CloudTrail records Compute Optimizer API activity.
8. Reliability And Resilience
Rightsizing affects reliability.
Downsizing an overprovisioned resource may be safe, but only if the historical window includes real peaks. A quiet week is not enough evidence for a seasonal workload.
Upsizing or changing instance families may improve reliability when resources are under pressure.
Recommendations should be tested. Use staging, canary deployment, rolling updates, instance refresh, or maintenance windows depending on the workload.
Do not optimize away resilience capacity. A resource may look underused because it is standby, redundant, or reserved for failover.
Context matters: a database replica, spare capacity, or disaster recovery component can look wasteful if you ignore its resilience role.
9. Performance And Scaling
Compute Optimizer helps performance by identifying underprovisioned resources and better-fit configurations.
It uses historical metrics, so it is strongest when metrics reflect normal and peak behavior.
It is not real-time scaling. Auto Scaling reacts dynamically to demand. Compute Optimizer gives recommendations after analyzing history.
Use CloudWatch, load testing, application metrics, and deployment monitoring to validate changes.
Some performance issues are architectural, not sizing issues. Increasing an instance size will not fix a missing index, inefficient query, noisy network path, or overloaded downstream dependency.
10. Cost Model
Compute Optimizer's value is cost avoidance and performance improvement through better resource choice.
It can identify overprovisioned resources, underutilized capacity, and opportunities to use newer instance families or different configurations.
Enhanced infrastructure metrics and related features may have pricing considerations, so verify current AWS pricing before broad enablement.
Do not treat estimated savings as guaranteed. Workload behavior, reserved commitments, Savings Plans, Spot usage, licensing, and data transfer can affect actual cost.
The best savings often come from a loop: observe, recommend, test, resize, monitor, and repeat.
12. SAA-C03 Exam Signals
"Right-size EC2 instances based on utilization" points to Compute Optimizer.
"Find overprovisioned or underprovisioned resources" points to Compute Optimizer.
"Recommend better Lambda memory or EBS volume configuration" can point to Compute Optimizer when supported resource wording appears.
"Automatically add EC2 instances during traffic spikes" points to EC2 Auto Scaling, not Compute Optimizer.
"Find AWS best-practice account recommendations across cost, security, performance, and quotas" points to Trusted Advisor.
"Analyze historical cost by service" points to Cost Explorer.
13. Common Exam Traps
Do not confuse Compute Optimizer with Auto Scaling.
Do not apply recommendations blindly to production.
Do not downsize failover or standby capacity without understanding resilience intent.
Do not buy commitments before rightsizing.
Do not assume every AWS resource type is covered. Check supported resources.
Do not treat cost savings estimates as final billing guarantees.
15. Related Topics
Review Amazon CloudWatch because Compute Optimizer depends on utilization metrics.
Next, study AWS Savings Plans and AWS Trusted Advisor to connect rightsizing with commitment purchases and broader best-practice recommendations.
Official AWS references:
What to study next
These links keep the session moving: read prerequisites first, then open the systems, concepts, and patterns that deepen this page.
Prerequisites
Read these first if the mechanics feel unfamiliar.
More Links
Additional references connected to this page.