Control VM Sprawl with Expiration Dates


Public clouds provide an easy path to deploying virtual machines (VMs), but this ease of deployment, if not properly managed, can lead to a proliferation of uncategorized, mysterious, and often expensive VMs. This reviled situation is known as VM Sprawl.

Networking Appliance Company: Case Study

Case in point, a major networking appliance company had adopted public cloud usage team by team, and wound up with more than a dozen AWS, Azure, and GCP public cloud accounts. The result was multiple interfaces to see and manage all of their VMs, and no unified way to track each VM’s purpose, owner, or lifecycle. The inability to gain visibility into their VMs was costing the enterprise IT team money and time, and exposing them to unnecessary security risks.

Step 1: Automatically Set Expiration Dates

The first step they took to get control over the situation was to install CloudBolt and to connect it to all of their public cloud accounts. When connected to a virtualization system or public cloud account, CloudBolt automatically discovers all of the VMs, networks, images, etc, and begins tracking and reporting them. Standing up CloudBolt and connecting all of their public cloud accounts took less than half a day and gave the IT admins a single web interface where they could see all of their resources across their various public cloud accounts. It’s worth noting that CloudBolt synchronizes with the providers’ inventory every 30 minutes, so if a user powers off a VM, creates a new one, or changes an existing one (ex. adding memory to it), that change will appear in CloudBolt within half an hour.

Step 2: Plug-in

Next, the customer added a post-sync plug-in to CloudBolt that automatically set expiration dates on all of their VMs (here’s a sample CloudBolt plug-in that can be used as a starting point). They then emailed all of their developers and other users of the public clouds to let them know that their VMs would be turned off in 60 days, unless they went into CloudBolt’s web UI, claimed their VMs, and changed or removed the expiration date.

This step was extremely valuable to the organization as it allowed them to know which of their VMs were still needed, and which users and groups they belonged to. By the 60 day mark, they saw that half of their public cloud VMs were powered down, drastically reducing their public cloud costs. CloudBolt’s discovery and expiration date management had enabled the equivalent of sticking a post-it note on the shared refrigerator saying “Unclaimed food will be discarded Friday at 5pm”. The end result: chaos became order, their costs decreased drastically, no important VMs were lost, and the clean up took place without incident.

Step 3: Compare Before & After Costs

After these two steps, the IT department was able to contrast their pre-CloudBolt public cloud bills with their post-CloudBolt bills and present the savings to their peers and management. The strong accolades and recognition received for their work enabled the IT team to continue with additional improvements.

Self-Service IT & Power Schedules

Another improvement made was the roll-out of self-service provisioning of resources in any public cloud or any of their private virtualization systems (VMware and OpenStack). Depending on the group and the environment for the new resources, expiration dates with maximum lengths were set up to be enforced by CloudBolt (here’s a video on how those expiration dates are set up).

In addition, the team set up automated power schedules in CloudBolt so it would turn off VMs when they were not in use (saving even more money), implemented limits & quotas on groups and environments, and added approval processes for any orders in production environments.


For this IT department, striking back against VM sprawl saved money, time and increased visibility, and also greatly enhanced navigation of the infrastructure. Now, anyone with appropriate permissions can see which VMs belonged to who, how they are changing over time, plus notes detailing their purpose.

CloudBolt also allowed the entire IT organization to collaborate and troubleshoot more effectively. It established a common interface for cross-team collaboration, where IT and their internal customers gained a common control plane for infrastructure and applications. Their DevOps practices were advanced and CloudBolt provided them with a place to automate and standardize their practices and processes.

To learn more download our Solution Overview or get a free 25-server lab license today.

Related Blogs

VMWare Competitors: Exploring Migration Options after Broadcom’s Acquisition

As the saga of the recent $69 billion acquisition of VMware by Broadcom continues to play out, it has sent…

VMWare Alternatives – What’s Next For Your Cloud Practice

As a VMware partner, you may have received notice that Broadcom is terminating your contract.  It’s like the tech world’s…

Navigating the VMware Acquisition: A Pragmatic Approach to Migration in the Broadcom Era

Introduction: I received a text from a former colleague and friend out of the blue today that read “I guess…