Idle resources are a large cause of bill shock and are, along with unallocated resources, a low-hanging fruit in the world of cloud cost optimization. Over the past months, we’ve put out some great blog posts on how to downsize or rightsize resources and how to manage Kubernetes costs - among other cloud cost management strategies - but we’ve never gone into great detail about idle resources. Now’s the time!
Firstly, resources are basically the CPU and memory that you have available in the cloud - your compute resources. And in the world of cloud resources, there are usually three categories of these resources: utilized, idle, and unallocated. Utilized resources are, obviously, resources that are in play today. Unallocated resources are resources that have no usage at all, or are not allocated to an instance - quite uneconomic. Idle resources are resources that were used at some point, but are now not in use; idleness of a resource is also defined as when a resource is not being fully utilized (e.g. you only use 20% of a m4.xlarge EC2 instance resulting in 80% idleness resulting in significant aws ec2 cost implications). Typically, idle and unallocated resources are borne from over-provisioning resources and can be downsized or rightsized. When it comes to developers, it’s hard to restrict the amount of resources they feel they need in order to create performant applications… so we find it appropriate to quote Jabba the Hutt: “There will be no bargain, young Jedi…” but there can be savings.
We go into a ton of detail on idle and unallocated resources in our Cost Management Strategies for Kubernetes eBook which, while specific to Kubernetes tutorials and Kubernetes benefits, does have a lot of information that can be applied to generic resources in the big three cloud providers (Amazon Web Services (AWS), Google Cloud Platform (GCP), and Microsoft Azure).
Like we said: low-hanging fruit. But while it’s easy to correct inappropriate resource allocation, let’s not minimize the impact that idle resources can have on cloud costs. These resources can unfortunately lead to thousands of dollars of absolute waste, so it’s important to keep them in check! 35% of cloud spend is wastage, so keep a close eye on resources. Some long-term planning will be required, but a good place to start is with cloud cost management tools. These tools are a great way to help - especially with features like Cloud AutoStopping, which can stop resources when they are no longer needed and automatically turn them back on when necessary, and Anomaly Detection, which uses machine learning to identify strange spikes in costs and alerts you of the problem. Insights like these are incredibly actionable.
When allocating resources, developers don’t always know how much is going to be used. As they are standing up infrastructure for their build environment, a rough estimate is used in resource limits for the amount of CPU and memory that is going to be consumed and needed. Usually these resources are overallocated and it is a difficult task to gauge the correct amount of resources needed. But this is critical in reducing cloud costs. Having more resources than needed is throwing money away, as it can lead to your cloud bill skyrocketing!
To paint a picture of what is actually happening, let’s say Company A is using AWS and has provisioned EC2 Large Instances, but realized that they only use 40% of the resource. Rather than provisioning thousands of these large instances that cost $10 per unit, the company can instantiate Medium Instances that would save them, let’s say, $5 per unit. Of course, Company A will take the time to understand whether the Medium Instances will meet their base and excess capacity needs, but the point stands that if 60% of the existing Large Instances are going unused, moving down a tier would help to bring that idle utilization down significantly and create more efficiency.
Capitalists around the world have been trying to reduce business costs since the first variations of economies were created. The economics of this really revolve around creating larger cash balances, which mean more potential value for the company.
As it relates to cloud resources, lowering those costs is part of the next frontier. The theory of idle resources is simple: engineers want highly performant applications and thus err on the side of overprovisioning, resulting in idle cloud cost.
But what is the biggest offender? Of course, we’re talking about compute resources.
Some might call this the ultimate idle resource. On-demand resources are easy to spin up and scale, and equally as easy to forget about. This can result in either the resource costing money when it’s not being used at all, or in a resource that isn’t appropriately sized and never gets rightsized.
To solve for these, we can rightsize so that there is minimum idle capacity, or we can turn off these resources when they’re not in use, making it less critical to find the absolute correct instance for the use case.
At Harness, we view idle cloud resources as a byproduct of everyday work that engineering teams do. Because engineers are incentivized to innovate rapidly and prioritize performant applications, they are given free reign to spin up the cloud resources necessary to do so. Many times, this means that they will make a judgment call that will result in over-provisioned resources, ensuring that performance never becomes an issue for the end user.
However, the economic environment within many organizations is not conducive to continually maintaining a high overhead of idle resources. It’s not cost effective, and the fraction of capital required to do it is unsustainable in the long term. With too much idle resource overhead, even with the best discounting from a cloud provider, organizations will end up overpaying for their cloud.
At the same time, it’s difficult to keep this overhead at a minimum, because the decision of the owner of the provisioned cloud resources is rarely looked at after an application change is deployed. What if there was a way to automatically reduce that overhead? Two ways to do this come to mind: automatically rightsize or deprovision resources; or, keep existing resources but turn them off when they’re not in use.
Introducing Harness Cloud Cost Management. You can think of it as intelligent cloud cost management. A key feature of this product module is Cloud AutoStopping, which allows users to solve the problem in two ways:
With the former capability, users can register existing compute resource groups, after which point the tool will minimize the time those resources are spent idle. Users can define a “shutoff period,” and when that threshold is reached without any traffic to the resource, Harness will turn it off. But it’s more than turning things off - it’s also turning them back on again when traffic is detected to the resource.
And for the latter, it’s simple. Users simply ask the system to run the registered compute resource groups as spot instances, and Harness will take care of the rest! Harness will handle the orchestration of spot instances and guarantee no spot interruptions. In this way, users have to worry significantly less about costs because any given instance will cost 70-90% less.
Idle cloud resources are the low-hanging fruit of the cloud cost management world, but they don’t have to be a hassle to take care of. While users can totally do their own analysis of idleness and find ways to rightsize, why not skip the hard work and simply optimize by not paying when it’s not being used?
Leverage intelligence and automation with Harness Cloud Cost Management and immediately do away with the toil related to managing idle cloud costs. Sign up for a demo today!
Enjoyed reading this blog post or have questions or feedback?
Share your thoughts by creating a new topic in the Harness community forum.