Cost Optimization Hub is free, takes one opt-in, and consolidates recommendations that were previously scattered across four consoles. It also has a documented blind spot big enough to distort the score it gives you: Kubernetes and container spend counts toward the denominator of its cost efficiency metric while generating no recommendations for the numerator.
What is Cost Optimization Hub?
A consolidation layer, not a new analysis engine. The AWS documentation describes it as a Billing and Cost Management feature that "helps you consolidate and prioritize cost optimization recommendations across your AWS accounts and AWS Regions", covering "resource rightsizing, idle resource deletion, Savings Plans, and Reserved Instances".
The two things it adds over reading Compute Optimizer directly are worth having. It "accounts for your specific commercial terms with AWS, such as Reserved Instances and Savings Plans", so the estimated saving is not quoted at list price. And it deduplicates overlapping recommendations, which the cost efficiency page illustrates precisely: "stopping an idle EC2 instance reduces the amount you can save through purchasing Savings Plans. Cost Optimization Hub proportionally reduces the estimated savings for Savings Plans recommendations based on the costs of idle EC2 instances that can be stopped."
That is a real problem solved. Two tools each claiming to save you $10,000 on the same instance is the oldest arithmetic failure in this category.
What does it actually cover?
AWS publishes the list, which makes the gaps checkable. Recommendations are generated for EC2 instances and Auto Scaling groups, EBS volumes, Lambda functions, ECS tasks on Fargate, Compute and EC2 Instance Savings Plans, EC2 Reserved Instances, RDS DB instances and storage, RDS Reserved Instances, Aurora cluster storage, ElastiCache clusters and reserved nodes, MemoryDB clusters and reserved instances, DynamoDB tables and reserved capacity, DocumentDB clusters, OpenSearch Reserved Instances, Redshift reserved nodes, SageMaker endpoints and SageMaker Savings Plans.
Read that list for what it does not contain. There are no recommendations for S3, for CloudWatch Logs, for NAT Gateways, for data transfer, for public IPv4 addresses, for Bedrock, or for anything Kubernetes. Which means the entire EC2 - Other bucket, the place where forgotten volumes, idle addresses and cross-zone traffic accumulate, is covered only for EBS volumes.
| Cost centre | Recommendations? | Where the money actually is |
|---|---|---|
| EC2 instances, RDS, ElastiCache, Redshift | Yes | Rightsizing and commitments, well covered |
| EBS volumes | Yes | Unattached and over-provisioned volumes |
| EBS snapshots | No | Orphaned chains and archive-tier minimums |
| NAT Gateway and data transfer | No | Idle gateways and cross-AZ traffic |
| Public IPv4 addresses | No | Idle addresses at the same rate as in-use ones |
| EKS and Kubernetes | No | Over-requested pods, and clusters sitting in extended support |
| S3 | No | Storage class minimums and small-object rounding |
| CloudWatch and CloudTrail | No | Log ingestion and duplicate trails |
Why is the cost efficiency metric misleading for container workloads?
This is the finding worth acting on, and it comes from putting two AWS lists side by side.
The cost efficiency metric is defined as "Cost efficiency = 1 - (Potential Savings / Total Optimizable Spend) × 100%", with AWS's own example: "if your total monthly AWS spend that can be optimized is $100,000 and Cost Optimization Hub identifies $10,000 in potential savings, your cost efficiency is 90%."
Now look at what goes into the denominator. AWS lists the services whose spend counts as "optimizable": EC2 instances, ECS, EKS, EBS volumes, RDS, SageMaker, Redshift, Lambda and OpenSearch. And it notes: "For supported services, the entire service spend is included in Total Optimizable Spend."
EKS is in the denominator. EKS is not in the supported-resources list, so it contributes nothing to the numerator. A cluster with every pod over-requesting memory by 3x adds its full spend to optimizable spend and generates zero potential savings, which raises the reported cost efficiency score. The worse the cluster, the better the number looks.
This is not a bug so much as a consequence of building a score on top of a recommendation set with holes in it. But it does mean the metric should not be used as a KPI by any organisation whose spend is container-heavy, and it is not stated anywhere on the page that defines the metric. Deriving it requires reading the supported resources list and the supported services list together and noticing they disagree.
For the container half, the cost data does exist, just not here. Split cost allocation data puts per-pod cost in the CUR, and ECS is supported too, with different limitations.
How do you turn it on, and what should you check first?
Opting in is one call, and doing it from the management account is what makes it useful across an organisation.
aws cost-optimization-hub update-enrollment-status \
--status Active \
--include-member-accountsThree settings decide whether the numbers mean anything.
- Savings estimation mode. The preferences documentation offers "After discounts", which "estimates savings incorporating all discounts with AWS, such as Reserved Instances and Savings Plans", and "Before discounts", which uses "AWS public (On-Demand) pricing, without incorporating any discounts". Before-discounts numbers are larger and are not what you will realise. Set it to after discounts and say so in any report that quotes the figure.
- Commitment preferences. Term length and payment option change every Savings Plan and RI recommendation. AWS notes the change propagates "within 24 hours", so do not judge the recommendations the same afternoon you set it.
- Organizations trusted access. To cover member accounts, "make sure that the organization has all features enabled". Consolidated billing alone is not enough.
Two facts about the data itself that shape how you use it. Recommendations "are saved in the US East (N. Virginia) Region" regardless of where the resources run, which matters if you have data residency constraints. And the savings figures are normalised, not observed: estimated monthly cost impact "is an estimation of how much your AWS bill will change over a 730-hour period (365 * 24 /12) ... if you had implemented the recommended action 730 hours ago", with AWS adding that it "is a quick approximation of future savings" and "the actual savings that you realize is dependent on your future AWS usage patterns."
In other words a recommendation that says $400 a month means $400 if the resource runs continuously for the next month in the same shape it ran in the lookback window. For steady production that is close. For anything bursty it is an upper bound, and totalling those upper bounds into an annual savings target is how a FinOps programme ends up reporting savings that never appear in the bill.
Is it enough on its own?
For rightsizing and commitments, largely yes, and it is free, which makes arguing against turning it on difficult. For the rest of the bill it is silent, and silence reads as "nothing to fix" rather than "not examined". The gap list above is the working set: storage lifecycle, network topology, logging volume, container requests, and idle addresses. None of it is exotic and none of it is covered.
Pair it with a detection layer for the things it cannot see. A cost anomaly monitor catches a spike in an unsupported service that no recommendation engine was ever going to flag, and the CUR carries the resource-level detail that Cost Optimization Hub does not expose.