Cloud View - Data#3
Overview
Getting Setup
Using
Recommendations
Overview
Getting Setup
Using
Recommendations
  • Quick Start
  • Getting Started
  • Concepts and Terminology
    • Overview
    • Tag Hierarchy
    • Shared Data
    • Custom Data
    • Actions
    • System Tags
  • Getting data into Cloud View - Data#3

    • Overview
    • Microsoft Azure
      • Azure App Registration
      • Cost Management Exports
      • Enhanced Azure Access
      • Troubleshooting
    • Amazon Web Services
    • Google Cloud
    • Oracle Cloud
    • Alibaba Cloud
    • Tag Mapping
    • Custom Usage
    • Settings
  • Using Cloud View - Data#3
    • Costs and Usage
    • Emissions and Energy
    • Tracking
    • Budgets
    • Reporting
    • Governance & Compliance
      • Overview
      • Watchdog
    • Customer Management
  • Recommendations
    • Azure
    • Amazon
  • Kubernetes Cost Insights
  • Platform Integration and Security

    • API Overview
    • Platform Security & Data Protection
    • Access Management

Savings Confidence & Conflicting Recommendations

How confident is the savings estimate?

CloudCtrl shows a confidence indicator alongside each recommendation's estimated saving. This reflects how reliable the figure is — a high-confidence estimate is based on solid, consistent usage data over a long period, while a low-confidence estimate may be based on limited data or a short observation window.

The confidence level is sourced directly from the cloud provider where available (for example, AWS Compute Optimizer reports how many days of data it used). Where the provider doesn't supply a confidence signal, CloudCtrl derives one based on the available data.

What this means for you: treat high-confidence savings figures as reliable planning inputs. Low-confidence figures are still worth reviewing, but verify the usage data before committing to a change.

Conflicting recommendations

Sometimes CloudCtrl will show a conflict warning on a recommendation. This happens when the same resource has both a rightsizing recommendation (e.g. "downsize this VM") and a commitment recommendation (e.g. "buy a Reserved Instance for this VM") at the same time.

Acting on both simultaneously could waste money:

  • If you downsize the resource first, a Reserved Instance you bought for its original size won't fully apply to the new, smaller size.
  • If you buy the commitment first, rightsizing later may reduce the benefit of the commitment.

What to do when you see a conflict

You have three options:

  1. Rightsize first — implement the rightsizing recommendation, then revisit commitment options for the new resource size.
  2. Commit first — purchase the commitment now for the current size, and plan to revisit rightsizing in a future cycle.
  3. Dismiss one recommendation — if one of the two isn't relevant (for example, you've already purchased a commitment), dismiss it with the appropriate reason.