The content in this blog is outdated and we cannot reliably say it is still accurate with the speed in which the cloud industry moves. But don’t worry—below are more recent, up-to-date blogs.
For consumption based services like AWS, it’s in Amazon’s best interests for their customers to fully utilize the infrastructure they deploy. No one wants to find out they’ve been wasting money on unused services. Finding those immediate and long term cost savings that bring an AWS customer to full utilization of their cloud infrastructure is one of CloudHealth’s many strengths. Our customers initially see the potential savings through the Health Check report. The report covers three major themes: cost, performance and security.
Right off the bat in the Immediate Savings section, we uncover unused EBS volumes and RI modification recommendations that can be realized relatively quickly. It’s enlightening to take a look at the Health Check report for our new trials. They’ve often gone months, or even years, without any deep insight into their usage. This trial, for instance, could save $23K a month, and it only took a few minutes for us to determine that after getting read-only credentials to perform a scan of their AWS Account.
Each section of the report has a quick one-click drilldown that will help the appropriate decision maker determine the best course of action. (Personally, I’d clean up those unused volumes and throw an office party with the savings.)
When you have hundreds or thousands of servers, there’s bound to be a few that you can part with, generally due to over-provisioning. Maybe you spun up a few extra in a cluster just to be safe, but forgot about them, or you took a guestimate on the number of IOPS needed for a volume and it was way too much. The Operational Savings section will give you a high level starting point for tackling waste across your instances and volumes. We limit the instances to General Purpose and Compute Optimized to make it even easier to identify instances that really are under-utilized.
For security, we display what is essentially the “front door has been left wide open” report. AWS makes it so easy to spin up hundreds of instances, create dozens of security groups with varying rules, often custom, and then forgot all about that because things are just working. (An all too common scenario is an engineer temporarily opening up a rule to 0.0.0.0 for some testing and forgetting to revert the change). We’ll show you a high level review of open ports covering many common applications.
After drilling down to see the 55 instances with MySQL exposed, I could tell that they were all under a development account, and it was a rule in the default security group.
Whereas other sections will make you a hero for saving the company money, this section just might save the company. And just because you may not have any instances left wide open doesn’t mean you don’t have other port exposures, so be sure to look at our Open Ports report as well; it covers many other scenarios.
The majority of our customers are well beyond the Chaos stage of cloud deployment. No one knows all instances that are deployed, so to help manage them, AWS Tags are used to designate assets. Generally, scripts or procedures are followed to deploy a new asset so tags get setup properly. If someone draws outside the lines, we’ll catch them quickly within the Cloud Governance section of the report. Instances without tags will show up, and can be quickly viewed to determine if they should be terminated or fixed. If CloudTrail integration is enabled, you’ll even be able to see who deployed the instance.
This report is meant as a high level overview of “quick hit” actions to take, and can be consumed by many members of a company either daily, weekly or monthly from the site or by email. Each user can subscribe and set their own schedule.