AWS Cost Optimization Hub

When AWS announced Cost Optimization Hub at re: Invent 2023, my first reaction was: finally.

For years, AWS savings recommendations had been scattered across at least four different consoles. Compute Optimizer, for instance, right-sizing. Trusted Advisor for general checks. The Reservations and Savings Plans pages are for commitment planning. Cost Anomaly Detection for spikes. Each one with its own UI, its own data freshness, its own export format.

I had clients paying engineers to copy data between dashboards into a single Excel sheet just to see their full optimization opportunity in one place. It was awful.

AWS Cost Optimization Hub fixes that specific problem. It pulls every cost recommendation AWS already generates into a single view, ranks them by estimated savings, and lets you filter across accounts in your organization. And it is free.

In this article, I will walk through how Hub actually works, what each recommendation type means, where the tool falls short, and when you still need to layer a third-party FinOps platform on top. By the end, you will know exactly when Hub is enough and when it is not.

What AWS Cost Optimization Hub Actually Is (and Is Not)

AWS Cost Optimization Hub is a free, centralized service inside the AWS Billing and Cost Management console that aggregates and ranks cost-saving recommendations from multiple AWS sources.

What it is not: a full FinOps platform. It is a recommendation aggregator with a dashboard.

Hub pulls data from five existing AWS sources you may already be using. AWS Compute Optimizer for right-sizing. AWS Trusted Advisor for general checks. Reservations and Savings Plans recommendation engines for commitment planning. AWS Cost Explorer's idle resource detection. Hub does not generate new recommendations. It just centralizes and ranks the ones AWS already produces.

The estimated annual savings number you see on the Hub dashboard is the sum across all accounts in your AWS Organization, deduplicated and adjusted by a default discount rate.

What makes this useful in practice: I can finally hand a CFO one number and one URL. Before Hub, that one number required a manual reconciliation that took hours every quarter.

What makes this not enough: Hub is AWS-only. If your stack includes Azure, GCP, Kubernetes pod-level costs, or Snowflake, Hub sees none of it.

And even within AWS, Hub tells you the savings but not how to ship them through engineering. For that operational reality, practical strategies to reduce AWS costs without slowing innovation are useful background.

Which leads to the obvious next question. What specifically does Hub recommend, and which recommendations actually move the needle?

The Five Recommendation Types Hub Surfaces

AWS Cost Optimization Hub groups recommendations into five categories. Each behaves differently, so it helps to know which to act on first.

1. Idle resource recommendations

Idle EBS volumes, unattached Elastic IPs, idle RDS instances, and idle EC2 instances. Hub flags these as Stop or Delete actions, and they are usually safe wins.

In my experience, idle resources account for around 60% of the absolute dollar savings Hub will surface in the first month. Take them first.

2. Right-sizing recommendations

These come from AWS Compute Optimizer. Hub shows the recommended instance type, projected savings, and a confidence rating. A high confidence rating means Compute Optimizer has at least 14 days of CPU and memory data behind the recommendation.

I would not act on low or medium-confidence right-sizing recommendations without further validation. I have seen production performance regress because someone trusted a low-confidence recommendation built on five days of data. For a deeper look at how Compute Optimizer works under the hood, my breakdown of AWS Compute Optimizer and how to actually act on its recommendations is worth reading first.

3. Reservation and Savings Plans recommendations

Hub surfaces commitment recommendations from AWS's own engine. These can produce big savings, up to 72% according to AWS's own marketing for 3-year all-upfront RIs, but they also lock you in.

My rule of thumb: never commit to more than 70% of your steady-state baseline. AWS's recommendation engine sometimes pushes you toward 100% commitment, which leaves zero flexibility for downsizing or workload changes.

4. Storage class and lifecycle recommendations

S3 lifecycle suggestions, EBS volume type changes, snapshot consolidation. The savings per recommendation are often small, but they compound across large estates and tend to be very low risk.

5. License and architecture recommendations

Hub flags opportunities to use AWS-licensed instances over BYOL where it is cheaper, and to switch to Graviton-based instances where compatible. Graviton recommendations alone can deliver around 20% savings on compatible workloads, according to AWS's own benchmarks.

Once you understand what Hub is recommending, the next thing to understand is where it stops being enough.

Where AWS Cost Optimization Hub Falls Short

I want to be direct about this section, because most articles online about Cost Optimization Hub read like AWS press releases. Here is the honest list of what Hub does not do.

It is AWS-only

If you operate on Azure, GCP, OCI, or any combination, Hub is invisible to those workloads. According to the Flexera 2025 State of the Cloud Report, 89% of enterprises run multi-cloud. For most teams, AWS-only optimization covers a fraction of total cloud spend.

It has no Kubernetes pod-level visibility

Hub sees EKS clusters as EC2 instances. It does not allocate cost to namespaces, pods, or workloads inside those clusters. If you run any meaningful Kubernetes footprint, this is a significant blind spot that Hub alone cannot close.

There is no governance workflow

Hub shows recommendations. It does not enforce approval workflows, ownership policies, or change management. There is no exclude SLA-bound resources from auto-action toggle. The recommendation lands in the dashboard, and what happens next is on you.

Realized savings tracking is weak

Hub estimates projected savings. It does not robustly close the loop on whether those savings actually materialized on the bill three months later. I have audited deployments where the projected number on the dashboard was 3x what actually showed up.

No chargeback or showback model

Hub does not help you allocate costs to teams or projects in any meaningful way. It groups by account, not by team or product. For real chargeback, you will need a third-party FinOps platform on top. The wider context on what good AWS cost management looks like end-to-end covers the gap between recommendation tooling and full cost discipline.

So Hub solves the visibility problem for AWS-only spend at a single dashboard. It does not solve governance, multi-cloud, Kubernetes, or chargeback. With that lens, here is how I would compare Hub against the alternatives.

AWS Cost Optimization Hub vs Third-Party Tools

I have grouped the most common alternatives I see teams choose between. The table below covers seven criteria across five tool categories.

If you want a more detailed view of where third-party platforms add value beyond what AWS provides natively, my walkthrough of common AWS cost management mistakes and what to do about them covers the operational reality.

With the comparison done, the real question is how to actually use Hub day-to-day in a working FinOps practice.

How I Would Use AWS Cost Optimization Hub in a Real Workflow

Hub is most useful as the first stop in a weekly FinOps review, not as the final word. Here is the cadence I recommend to teams.

Weekly: 30-minute Hub review

Open Hub filtered to your highest-spending accounts. Sort by estimated annual savings descending. Look at the top 10 recommendations. For each one, assign an owner, an action, and a target close date in your tracking system. The review is fast because Hub has done the prioritization for you.

Monthly: validate realized savings

Pull the previous month's actioned recommendations. Compare projected savings to actual line-item changes on the bill. If the gap is greater than 30%, dig in. Common causes are simple. The resource was re-launched. The change was rolled back. A related resource grew to absorb the savings.

Quarterly: review your commitment portfolio

Hub will keep recommending RIs and Savings Plans. Do not just keep adding. Review the existing portfolio. What is expiring? What is underutilized? What workloads have shifted? The way AWS itself frames the new Cost Efficiency metric introduced at re:Invent 2025 is a useful frame here for thinking about commitments alongside utilization.

Continuously: feed the loop into engineering

Hub recommendations should not live in finance dashboards. They should land in Jira tickets assigned to the engineering team that owns the workload. Without that hand-off, recommendations rot. The teams I see succeed are the ones where Hub feeds an existing ticket queue rather than living as a parallel artifact nobody owns.

With a workflow in hand, here are the questions I get asked most often by teams getting started with Hub.

Integrating platform capabilities from Opslyft

To strengthen our optimisation workflow, we also leverage capabilities similar to those in Opslyft’s latest product updates. These updates align closely with the areas we prioritise:

• Advanced anomaly detection
  Customisable rules allow us to define what a spike means for each workload and trigger real-time alerts.
• Contextual Saving Recommendation (CSR)
  AI-powered suggestions highlight which resources can be optimised across AWS, Azure, GCP, Kubernetes and Snowflake, mapped directly to responsible business units.
• Audit logs for accountability
  Every change is recorded, making root-cause analysis and governance smoother.
• Machine-learning-assisted cost allocation
  Helps distribute untagged or shared costs more accurately across teams and services.
• Deep multi-cloud integrations
  Unified visibility across AWS, Azure, GCP, OCI, Snowflake, Kubernetes and OpenAI workloads enables consistent cost governance.

These enhancements align directly with our philosophy of continuous optimisation supported by strong automation and accurate insights.

Best practices we embed into operations

We follow practical habits that make cloud cost optimisation sustainable:

• Assign ownership for each workload and its cost.
• Set meaningful KPIs such as utilisation rates, cost anomalies, or allocation accuracy.
• Enable automation early, shutdowns, rightsizing, and alerting.
• Conduct weekly reviews of spend and optimisation opportunities.
• Connect cost data with business value to guide better decisions.
• Promote a culture where optimisation is part of engineering excellence.

Conclusion

AWS Cost Optimization Hub is the best free upgrade AWS has shipped to its native cost tooling in years. If you operate primarily on AWS and you do not currently have a tool aggregating recommendations across accounts, turn it on this week. The setup is trivial and the time to value is real.

But understand what Hub is and is not. It centralizes and ranks recommendations AWS already generates. It is not a FinOps platform. It does not replace governance, multi-cloud visibility, Kubernetes pod-level allocation, or chargeback workflows.

The teams I see succeed treat Hub as the first input into a weekly FinOps cadence, not as the destination. Start there, build the operational muscle, and layer specialized tools where Hub stops being enough.