For the past several years, I have been warning companies to watch out for idle cloud resources. This often means instances purchased “on demand” that companies use 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). Of course, this results in great savings. But this doesn’t address the issue of how idle cloud resources extend beyond your typical virtual machine.
Why idle cloud resources are a problem
If you think about it, the problem is not very complicated. When a resource is idle, you’re paying your cloud provider for something you’re not actually using. And there’s no reason to pay for something you are not actually using.
Most non-production resources can be parked about 65% of the time, that is, parked 12 hours per day and all day on weekends. Many of the companies I talk to 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.
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).
Four types of idle cloud resources
- On-demand Instances/VMs: This is the core of the conversation, and what I have 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 as well, in similar circumstances to the 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 resources, 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 it. The same can be said for Azure Load Balancer and GCP Load Balancers. Alerts can be set up in 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 for my company, ParkMyCloud, to park container services including ECS and EKS from AWS, ACS and AKS from Azure, and GKE from GCP, and the ability 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 most businesses today. But the solution is quite simple. Make sure you’re turning off idle cloud resources in your environment. Do this by parking those resources that can be stopped and eliminating those that can’t.
Interested in hearing industry leaders discuss subjects like this and sharing their experiences and use-cases? Attend the Cyber Security & Cloud Expo World Series with upcoming events in Silicon Valley, London and Amsterdam to learn more.