AWS Compute Optimizer, Cost Explorer & Trusted Advisor

Recap: From Commitment to Measurement

Foundations You'll Need Today

1. Why This Is on the Exam

Cost optimization is Domain 4 of SAP-C02, and it is the domain candidates most often underestimate because the questions do not look like cost questions. A scenario will describe a fleet of instances running at low utilization, a monthly bill that keeps climbing without a corresponding traffic increase, or a migration that has to justify its target instance sizes, and the correct answer is a service that produces a recommendation rather than a service that produces a discount. The exam is testing whether you know which tool answers which question, because the three services in this day overlap enough that a careless reader will pick the wrong one.

The reason this cluster is exam-relevant is that it sits at the intersection of two things the exam loves: a decision that has a defensible right answer, and a set of plausible distractors that are all real AWS services doing something adjacent. Compute Optimizer, Cost Explorer, Trusted Advisor, AWS Config, CloudWatch, and Cost and Usage Report all touch cost or utilization in some way. Only one of them will tell you that a specific m5.2xlarge should be an m5.large. Only one of them will forecast next month's bill. Only one of them will tell you that you have idle load balancers without you having to ask a specific question first. Knowing the boundary between them is the actual skill being tested.

There is also a governance dimension that shows up in multi-account scenarios. In an organization with dozens of accounts, the question of who can see cost data, at what granularity, and whether recommendations are surfaced centrally or per-account is a real architectural decision. Compute Optimizer and Trusted Advisor both have organization-level views that require explicit opt-in, and Cost Explorer's data is scoped to the management account's consolidated billing view. A scenario that asks how a central FinOps team monitors spend across forty accounts is testing whether you know these services can be aggregated, and what has to be enabled for that to work.

Finally, the exam treats these services as the evidence layer for a recommendation you are about to make. When a question asks you to justify moving a workload to Graviton, or to a smaller instance family, or onto a Savings Plan, the answer often hinges on what data supports the change. Compute Optimizer's recommendations are backed by CloudWatch metrics over a lookback window; Cost Explorer's forecasts are backed by historical spend; Trusted Advisor's checks are backed by heuristics against best practice. Understanding what evidence each service actually has access to tells you when its recommendation is trustworthy and when it is not.

2. How Each Service Actually Works

Compute Optimizer is a machine-learning service that consumes CloudWatch metrics and produces instance-type recommendations. It does not read your application, your logs, or your architecture diagrams. It reads CPU utilization, and for some resource types memory utilization if the CloudWatch agent is publishing it, plus a set of derived features like network throughput and disk I/O, and it compares your observed utilization pattern against a model trained on a large corpus of AWS workloads. The output is a recommendation with a finding classification — over-provisioned, under-provisioned, optimized, or none — and a projected monthly savings figure for the over-provisioned case. The critical mechanical detail is that the recommendation is only as good as the metrics it can see, and by default it cannot see memory at all.

Cost Explorer is a reporting and forecasting layer over the billing data AWS already collects. It is not a monitoring service and it does not look at your resources; it looks at your invoice. The data is available at daily and hourly granularity, filterable by service, account, region, tag, instance type, and a long list of other dimensions, and it supports grouping and filtering combinations that let you answer questions like "what did the payments team spend on RDS in eu-west-1 last quarter." Its forecasting feature projects spend forward using historical patterns, and its reservation and Savings Plan recommendations are generated by analyzing your historical usage against the commitment instruments available. The mechanical constraint worth internalizing is latency: Cost Explorer data is not real-time, and the granularity you get depends on how far back you are looking.

Trusted Advisor is a rules engine. It runs a fixed set of checks against your account — some free, some requiring Business or Enterprise Support — and reports pass, warning, or error states with a description of the issue and a link to remediation guidance. The checks span five categories: cost optimization, security, fault tolerance, performance, and service quotas. The cost category is the one relevant here, and it covers things like idle load balancers, unassociated Elastic IP addresses, underutilized EBS volumes, and low-utilization EC2 instances. Trusted Advisor is deliberately shallow and broad: it will tell you that you have idle resources, but it will not tell you what to resize them to. That is Compute Optimizer's job.

The three services compose into a rough funnel. Trusted Advisor is the wide end — it surfaces categories of waste across the account without you having to ask a specific question. Compute Optimizer is the narrow end — it takes a specific resource and tells you what to change it to. Cost Explorer is the accounting layer that tells you whether the change mattered, and it is also the source of the commitment recommendations that turn a right-sizing decision into a purchasing decision. A mature cost practice uses all three in that order, and the exam scenarios that describe a cost problem usually map cleanly onto one stage of the funnel.

3. The Core Decision Boundary

The fork every scenario question hinges on is whether the question is asking you to find waste, to quantify waste, or to act on waste. Finding waste is a discovery problem and the answer is almost always Trusted Advisor, because it is the only one of the three that proactively surfaces issues you did not ask about. Quantifying waste is a measurement problem and the answer is Compute Optimizer when the resource is compute and Cost Explorer when the question is about spend over time or across accounts. Acting on waste is a decision problem, and the answer depends on whether the action is a resize, a commitment purchase, or a decommission.

The subtlety is that the same scenario can be read at more than one stage, and the exam exploits this. A question describing an account with a rising bill and no traffic growth could be answered by Trusted Advisor if the expected answer is "find the idle resources," by Cost Explorer if the expected answer is "break the spend down by service to find the driver," or by Compute Optimizer if the expected answer is "right-size the over-provisioned instances." The discriminator is usually a phrase in the question that names the desired output: "identify," "forecast," "recommend a new instance type," "attribute to a team." Read for the output, not the problem.

The last two rows are the distractors that appear most often. AWS Config evaluates resources against rules you write, and while you can write a cost-flavored rule, Config does not generate recommendations — it reports compliance. CloudWatch is the raw data source that Compute Optimizer consumes, but CloudWatch itself will not tell you an instance is oversized; it will show you a CPU graph and leave the inference to you. If a scenario's correct answer is Config or CloudWatch, the question will describe a custom rule or a raw metric threshold, not a recommendation.

4. Configuration Modes and Their Tradeoffs

Compute Optimizer's most consequential configuration is whether it is opted in at the organization level and whether enhanced infrastructure metrics are enabled. By default, Compute Optimizer is opt-in per account, and in an organization you can enable it centrally so that the management account sees recommendations across all member accounts. Enhanced infrastructure metrics extend the lookback window from the default 14 days to three months, which matters enormously for workloads with monthly or quarterly cycles — a batch job that runs on the first of the month looks idle in a 14-day window and correctly utilized in a 90-day window. The tradeoff is that the longer window is a paid feature and the recommendations take longer to stabilize after a workload change.

The second knob is whether the CloudWatch agent is publishing memory utilization. Compute Optimizer's EC2 recommendations are materially better with memory data, because a workload that is CPU-light but memory-bound will be recommended for a smaller instance on CPU evidence alone and then fall over. This is not a Compute Optimizer setting so much as a prerequisite: if you have not installed the agent and configured it to publish the memory metric, you are getting a recommendation based on half the picture. The exam does not usually test the agent configuration directly, but it does test the consequence — a recommendation that ignores memory is a recommendation you should validate before acting on.

Cost Explorer's configuration is mostly about scope and granularity. The management account of an organization sees consolidated cost across all member accounts, and member accounts see only their own. Granularity is daily by default and hourly for recent data, with the hourly view retained for a shorter window. The tradeoff here is between precision and latency: the most recent day or two of data may be incomplete or estimated, so a forecast built on the trailing edge of the data is less reliable than one built on a settled month. Cost Explorer also has a per-account setting for whether it can be enabled at all, and in some organizations it is deliberately restricted to a central FinOps account.

Trusted Advisor's configuration is essentially a support-plan question. The full set of checks, including the cost optimization category, requires Business or Enterprise Support; the free tier exposes a small subset of security and service quota checks. In an organization, Trusted Advisor has an organizational view that aggregates check results across accounts, but it requires the management account to enable it and it requires each member account to be on a qualifying support plan. The practical tradeoff is that Trusted Advisor's breadth is purchased with support cost, which is why it is often the last of the three services an organization adopts.

5. Sizing, Limits and Quotas

The numbers that matter here are mostly about lookback windows and data retention, because those determine how much history a recommendation is built on. Compute Optimizer's default metrics lookback is 14 days, and enhanced infrastructure metrics extend that to three months. Recommendations are refreshed periodically rather than continuously, so a change you make today will not be reflected in the recommendation for some hours. Cost Explorer retains daily data for 13 months and hourly data for 14 days, which is why a year-over-year comparison is possible but a month-over-month comparison at hourly granularity is not. Trusted Advisor's checks refresh on their own cadence, with some checks updating several times a day and others less frequently.

The resource coverage of Compute Optimizer is worth knowing because it is broader than EC2. It also produces recommendations for Auto Scaling groups, EBS volumes, Lambda functions, ECS services on Fargate, and commercial software licenses. The Auto Scaling group case is the one that trips people up: the recommendation is for the group's instance type and desired capacity, not for individual instances, and acting on it means changing the launch template rather than resizing a running instance. Lambda recommendations are about memory configuration, which is the Lambda equivalent of instance sizing and directly affects both cost and execution duration.

Trusted Advisor's cost checks have their own implicit thresholds. The low-utilization EC2 check, for example, flags instances whose CPU utilization stays below a threshold over a multi-day window, and the idle load balancer check flags load balancers with no healthy targets or negligible traffic. These thresholds are not configurable, which is the point — Trusted Advisor is a best-practice baseline, not a tunable policy engine. If you need a threshold you control, that is AWS Config or a custom CloudWatch alarm, not Trusted Advisor.

6. Failure Modes and What They Look Like in Production

The most common failure mode is acting on a Compute Optimizer recommendation that was built on insufficient evidence. The symptom is a resize that improves the bill and degrades the workload: latency climbs, the instance starts swapping, or a batch job that used to finish in an hour now takes three. The cause is almost always a metric the recommendation could not see — memory, GPU, or a burst pattern outside the lookback window. The first diagnostic move is to pull the CloudWatch metrics for the recommended resource over a window longer than the recommendation's lookback and check whether the utilization pattern is actually flat or whether it has peaks the model did not observe.

The second failure mode is a Cost Explorer forecast that is confidently wrong because the historical data contains a discontinuity. A one-time migration, a reserved instance purchase, a support plan change, or a large data transfer will all bend the trend line, and the forecast will extrapolate the bend. The symptom is a forecast that looks implausible relative to what you know is happening, and the diagnostic move is to filter the cost data down to the service or account driving the change and look at the daily series rather than the monthly aggregate. Forecasts are only as good as the assumption that the future resembles the past.

The third failure mode is Trusted Advisor noise. In a large account, the cost checks will flag resources that are intentionally idle — a standby environment, a DR region, a load balancer waiting for a failover. The symptom is a check that has been in warning state for months and that everyone has learned to ignore, which is worse than not having the check at all because it trains the team to dismiss the category. The diagnostic move is to establish which flagged resources are intentional and either tag them so they can be excluded from review or accept the warning as a known exception with a documented reason.

There is a fourth, quieter failure mode: recommendations that are correct but never acted on. Compute Optimizer will happily tell you that forty instances are over-provisioned every day for a year, and nothing changes because no one owns the recommendation. This is not a technical failure, but it is the one that shows up most often in real accounts, and it is why the operational angle below matters more than the tooling.

7. The Operational and SRE Angle

From an SRE perspective, these services are inputs to a recurring review process, not dashboards you look at once. The shape that works is a monthly cost review where Compute Optimizer recommendations are triaged into three buckets: act now, validate first, and ignore with a reason. The "validate first" bucket is the important one, because it is where the memory-blind recommendations and the cyclical-workload recommendations land, and it is where a careless team causes an incident. The runbook for a resize should include a check of the resource's actual peak utilization over a window longer than the recommendation's lookback, and for anything user-facing, a rollback plan.

The SLO implication is that cost optimization is a change to production, and changes to production carry availability risk. A resize that reduces memory headroom can turn a latency SLO breach into a recurring event, and the cost saving will not look like a saving once you account for the incident. The right framing is that right-sizing is a capacity change and should go through the same change management as any other capacity change, with the same monitoring and the same rollback path. The exam does not usually phrase it this way, but the scenarios that describe a cost problem in a latency-sensitive system are often testing whether you recognize that the cheapest instance is not always the correct one.

On the monitoring side, the useful alarms are not on the cost services themselves but on the resources they recommend changing. If you resize an instance, you want a CPU credit balance alarm for burstable families, a memory utilization alarm if the agent is publishing it, and a latency alarm on the service in front of it. For Cost Explorer, the useful operational artifact is a budget with a forecasted-spend alert, which turns a trend into a notification before the month closes rather than after. For Trusted Advisor, the useful artifact is a periodic export of check results into whatever system your team already reviews, so the checks are not a separate destination nobody visits.

The organizational angle is that someone has to own the recommendations. In a small team that is obvious; in an organization with a central platform team and dozens of product teams, it is not. The pattern that scales is a central FinOps function that owns the aggregate view and the commitment purchases, with per-team recommendations routed to the teams that own the workloads. Compute Optimizer's organization-level view and Trusted Advisor's organizational view exist precisely to make that split possible, and a scenario that describes a central team needing visibility across accounts is usually pointing at one of them.

8. Edge Cases and Exam Gotchas

The single most-tested gotcha is that Compute Optimizer needs memory metrics to make good EC2 recommendations, and those metrics come from the CloudWatch agent, not from the hypervisor. A question that describes a memory-bound workload being recommended for a smaller instance is testing whether you know the recommendation is CPU-biased without the agent. The second most-tested is that Trusted Advisor's cost checks require Business or Enterprise Support, so a scenario describing a Basic Support account that needs proactive cost findings has no correct answer involving Trusted Advisor.

Another recurring trap is confusing Cost Explorer's reservation recommendations with the act of purchasing. Cost Explorer recommends; you purchase in the RI or Savings Plans console, or via the API. A scenario that asks how to reduce cost by committing will have a correct answer that involves analyzing usage in Cost Explorer and then purchasing, and a distractor that implies Cost Explorer itself applies the discount. Similarly, Compute Optimizer recommends but does not resize — there is no auto-remediation, and a scenario implying automatic right-sizing is describing something you would have to build with EventBridge and Lambda on top of the recommendation.

The organization-level opt-in is a frequent source of wrong answers. Compute Optimizer and Trusted Advisor both have organization-wide views, but both require the management account to enable them, and Trusted Advisor additionally requires qualifying support in the member accounts. A scenario that says the management account cannot see member-account recommendations is usually describing a missing opt-in rather than a missing permission. Cost Explorer is different: consolidated billing means the management account sees member-account cost by default, with no opt-in required.

Finally, be careful with the word "idle." Trusted Advisor's idle checks and Compute Optimizer's over-provisioned finding are not the same thing. An idle resource is one that is doing nothing and could be deleted; an over-provisioned resource is one that is doing work but has more capacity than it needs and could be resized. A scenario that asks how to reduce cost from a resource that is genuinely unused is a Trusted Advisor or decommission question; one that asks about a resource that is busy but oversized is a Compute Optimizer question.

9. This vs. the Services It Gets Confused With

The comparison that matters most is against AWS Config and CloudWatch, because those are the two services that appear as distractors most often and the boundary is genuinely subtle. Config evaluates resources against rules and reports compliance; it can be used for cost governance if you write rules like "flag EBS volumes unattached for more than 30 days," but it does not generate recommendations and it does not know what an instance should be resized to. CloudWatch is the raw telemetry layer that Compute Optimizer consumes; it will show you the utilization but not the conclusion. If a scenario's correct answer is Config, the question will describe a custom rule or a compliance requirement. If it is CloudWatch, the question will describe a metric threshold or an alarm.

The Cost and Usage Report is the other service worth separating out, because it is the one that appears in scenarios about custom FinOps tooling. CUR is not a UI; it is a scheduled delivery of line-item billing data to S3, and it is the source of truth that Cost Explorer's aggregates are built from. If a scenario asks for the most granular billing data available, or for data to feed a custom analytics pipeline, the answer is CUR. If it asks for a quick visual breakdown or a forecast, the answer is Cost Explorer. The two are complementary, not competing, and the exam expects you to know which one is the raw feed.

The practical rule for the exam is to read the scenario for the verb. "Recommend" points at Compute Optimizer. "Forecast," "attribute," or "break down" points at Cost Explorer. "Identify" or "check" points at Trusted Advisor. "Enforce" or "evaluate against a rule" points at Config. "Alert on a threshold" points at CloudWatch. "Export line items" points at CUR. The verbs are chosen deliberately, and matching the verb to the service is faster and more reliable than reasoning about the architecture.

Hands-on Lab: Right-Sizing a Fleet from Evidence (45 min)

Scenario Question Drills (20 min)

Peek into Tomorrow

Sources