Anomaly Detection — Public Beta

CloudHealth Anomaly Detection is now available in public beta for AWS, Azure, and GCP environments. This feature identifies an unusual increase or decrease in spend and provides you with ownership to analyze and act on unwanted changes – helping cloud adoption become more cost-effective. 

Anomaly Detection is supported by FlexOrgs to ensure the right access for the right users and enabled by FlexReports to perform root cause analysis and understand usage and resources contributing to the anomaly. CloudHealth Policies can be utilized to create condition-based alerts and notifications that make timely information available for the right stakeholders.

Using Anomaly Detection, you can:

• Filter the anomalies based on various parameters, including time period, account name, service, region, marketplace, cost impact, and more

• Sort or search the data to investigate the anomaly that is important to you

• Understand details of the anomaly and the historical trend

• Create alerts & notifications through policies for desired conditions

For more information, view this Help Center article.

Update to Cost Reallocation Rules — Toggle Switch

We are happy to announce that the single toggle switch for “Across Accounts and Regions” in Cost Reallocation has been split into exclusive toggles for “Across Accounts” and “Across Regions.” This update was deployed to Production last week.

The “Across Regions” toggle has now been moved to Advanced Settings on the same page. This change is to steer users away from using the “Across Regions” option because of the delays it can cause in the Cost History Report. As a best practice, users should use this option only if they have a strong business use case for reallocation of costs across regions. “Across Regions” does not change any reallocated costs at the account level, and just further splits the account costs at the region level (within each account).

Enhanced Notifications for Start/Stop Policy Actions

You can now take advantage of better visibility of when start/stop policies (also known as “lights on/lights off”) have successfully started or stopped instances. To utilize this, simply add an e-mail address when configuring the action. Then, use the radio toggle to indicate whether you want the e-mail to include just the IDs of workloads that failed to start or stop, or to also include the IDs of the workloads that successfully started or stopped. This notification will purposefully be delayed for a brief period (approximately 40 minutes) to allow for any variance in provisioning time by the cloud provider. It will then check to see if the workload has the intended status before bringing all the results into the notification. This visibility helps to operationalize this type of policy.