Updates to AWS Savings Plan Recommendations

In CloudHealth, you can not only get a recommendation for a Compute Savings Plan, you can explore different Compute Savings Plan commitment level scenarios and see how they might play out in your environment. Now, two new types of insights have been added to that modeling experience. 

In the visual graph, Unused Savings Plan ($) per hour now shows you how much of the hypothetical Savings Plan would not have been used that hour. In the table below the graph, the breakdown showing what usage your hypothetical Savings Plan would have applied to now also includes accounts. In the image below, you can see that across the evaluation period the Savings Plan got the most savings from its application towards r5s which were present in four accounts, and the second most savings were for i3s which were present in two accounts. We hope this helps inform your decision making when making a new Savings Plan commitment.

As a reminder, this feature assumes the most efficient application of the Savings Plan across your billing family, which you can achieve by purchasing your Savings Plan in an account in your billing family that has no usage. 

Update to Permissions Enforcement

On March 18th, we will be tightening the enforcement of our reporting permissions. Over time the number of users needed to manage the cloud at scale for the enterprise has increased, and CloudHealth has attacked these challenges with granular permissions and data segmentation that is reflective of a company’s organizational charts and identity systems. In order to continue our commitment, we are releasing some changes that will impact custom roles created in previous years. This change will affect custom roles created prior to March 18th. 

Support for Additional AWS Services - Coming Soon

Over the next two weeks, we will be adding basic cost allocation support for the following AWS asset types:

• Amazon EKS Fargate Pods

• Amazon SageMaker Batch Transform Jobs

• Amazon SageMaker Processing Jobs

• Amazon SageMaker Studio Notebooks

We will be using the tags and resource ID from your AWS bills to automatically allocate costs and assets to the appropriate Perspective groups. This allocation will be applicable to the past 13 months as well. We recommend that you save your cost and usage reports for reference. If you haven’t already, please enable all the tags in your AWS bills that you use for Perspectives.

Learn more about basic cost allocation support in this Help Center article. You can also learn more about activating user-defined cost allocation tags in this AWS Documentation article.

Deprecation of S3 Bucket List Price Attribute - Coming Soon

With Amazon S3 class-to-bucket mappings and boundaries becoming a blur, the bucket list price concept has turned obsolete. To adapt to changes in S3 pricing, we are going to deprecate list price columns from the S3 bucket report in the next two weeks. If you have any questions about this change, please reach out to us at s3-report-updates@groups.vmware.com.

Learn more about Amazon S3 Storage classes in this Amazon S3 User Guide.

Auto-Grouping High Scale Kubernetes Dimension Values - Coming Soon

As your modern app environment scales to thousands of namespaces, the raw view of the data seen in Kubernetes Allocation and Kubernetes Resources becomes overwhelming. Soon you will see the long tail of dimension members automatically grouped to deal with this, where the members with the fewest occurrences (e.g. the container names with the fewest containers, namespaces with the fewest containers) are grouped. Dimensions with over 3,500 members will see everything after 3,500 grouped into an “Other” category that is displayed as follows, where {N} is replaced with the number of members being grouped in the particular view.

Other [{N} Values]

This does not affect data flowing into Perspectives configuration, which you should continue to use as the primary grouping mechanism, where you have the control to designate what groups matter most and how you want data grouped. Instead, these reports will show you what’s out there (“raw view”), which could help inform things like Perspective building and assist you in finding the signal through the noise.

Deprecation of Mesos Support - Coming Soon

In 2016, CloudHealth began tackling your challenges around containers as new apps shifted towards modern microservices-based architectures. At that time there was a wide variety of modern app platforms in the market, including Mesos (DC/OS). Over the last five years, we have witnessed an industry consolidation around Kubernetes. In August of 2019 Mesosphere, the primary contributor to DC/OS, officially changed its company name to D2iQ and shifted its strategy to incorporate Kubernetes. In parallel, CloudHealth witnessed the drastic decline of our Mesos feature adoption, while Kubernetes continued to grow. As a result, we put significant energy into recent investments for Kubernetes reporting. On October 30, 2020, D2iQ, formerly Mesosphere, declared they had started “the process to wind down the Mesosphere DC/OS Platform.” 

Next Steps: For now, Mesos support will continue to function as-is. Starting in mid-March, warnings will be placed on configuration, clusters, and Mesos report pages reminding you that this functionality will soon sunset. In the second half of May, CloudHealth plans to cease collection and reporting of Mesos data. These steps ensure CloudHealth can remain committed and focused on what is most critical to your success. If you have any questions, please reach out to your CloudHealth Technical Account Manager or cloudhealth-containers-ext@groups.vmware.com.