Click to learn more about author Jay Chapel.

We have been talking about idle cloud resources for several years now. Typically, we’re talking about instances purchased on-demand that you’re using for non-production purposes like development, testing, QA, staging, etc. These resources can be “parked” when they’re not being used, such as on nights and weekends, saving 65% or more per resource each month. What we haven’t talked much about is how the problem of idle cloud resources extends beyond just your typical virtual machine.

Why Idle Cloud Resources are a Problem

If you think about it, the problem is pretty straightforward: If a resource is idle, you’re paying your cloud provider for something you’re not actually using. This adds up.

Most non-production resources can be parked about 65% of the time – that is, parked 12 hours per day and all day on weekends. We see that our customers are paying their cloud providers an average list price of $220 per month for their instances. If you’re currently paying $220 per month for an instance and leaving it running all the time, that means you’re wasting $143 per instance per month.

Maybe that doesn’t sound like much. But if that’s the case for 10 instances, you’re wasting $1,430 per month. One hundred instances? You’re up to a bill of $14,300 for time you’re not using. And that’s just a simple micro example. At a macro level that’s literally billions of dollars in wasted cloud spend.

Four Types of Idle Cloud Resources

So, what kinds of resources are typically left idle, consuming your budget? Let’s dig into that, looking at the big three cloud providers –Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP).

• On-Demand Instances/VMs: This is the core of the conversation, and what we’ve addressed above. On-demand resources – and their associated scale groups – are frequently left running when they’re not being used, especially those used for non-production purposes.

• Relational Databases: There’s no doubt that databases are frequently left running when not needed, similar to on-demand resources. The problem is whether you can park them to cut back on wasted spend. AWS allows you to park certain types of its RDS service; however, you cannot park like idle database services in Azure (SQL Database) or GCP (SQL). In this case, you should review your database infrastructure regularly and terminate anything unnecessary – or change to a smaller size if possible.

• Load Balancers: AWS Elastic Load Balancers (ELB) cannot be stopped (or parked), so to avoid getting billed for the time you need to remove the resource. The same can be said for Azure Load Balancer and GCP Load Balancers. Alerts can be set up in AWS CloudWatch/Azure Metrics/Google Stackdriver when you have a load balancer with no instances, so be sure to make use of those alerts.

• Containers: Optimizing container use is a project of its own, but there’s no doubt that container services can be a source of waste. In fact, we are evaluating the ability to park container services including ECS and EKS from AWS; ACS and AKS from Azure; and GKE from GCP, and to prune and park the underlying hosts. In the meantime, you’ll want to regularly review the usage of your containers and the utilization of the infrastructure, especially in non-production environments.

Cloud waste is a billion-dollar problem facing businesses today. Make sure you’re turning off idle cloud resources in your environment, by parking those that can be stopped and eliminating those that can’t, to do your part in optimizing cloud spend.