Bot of the Week: SCHEDULED INSTANCES BOT
What it does: Schedules automatic starts/stops for cloud resources to save money
The Scheduled Instance Bot provides the ability to configure daily stop/start schedules for compute infrastructure. It’s goal is to drive down monthly overspending (by as much as 50%) which results from instances running when they are not needed, often at night or on weekends. Different configurations and policies can be set for specific times, days and/or cloud environments, giving the organization maximum flexibility. Scheduled downtime policies can be configured to allow cloud users to opt-in/opt-out of auto-schedules via tagging. This can be great for developers and stakeholders who are working late/off-hours.
Why do I care?
The worst thing you can do in a public cloud world is run it like a “virtual data center”. You don’t want resources running 24/7/365, and you really want to avoid paying good money for unused capacity. Idle compute capacity typically accounts for 40 to 45 percent of a company’s public cloud bill. Unlike purchasing a physical data center, cloud usage is charged like a utility bill, you pay for exactly what you “turn on”. It can be easy to spin up and forget about instances, resulting in excessively high monthly bills and operational waste.
Scheduled Starts and Stops
Because it is so easy to spin up instances in a cloud ready world, it is not uncommon for forgotten resources to end up running 24/7 for days, weeks or months! That means the organization pays for every unused and over-provisioned resource in your cloud, which can cost a lot of money in the long run. Public Cloud monthly bills often grow 2-3X’s the expected budget in no small part due to excess capacity running when it’s not needed.
This can be addressed by scheduling downtime at the end of the day and spinning instances up again the following morning. Just like your light bill, you don’t want to leave the lights on if you’re not home. When dev environments are not in use at night, shutting them down saves plenty. Here’s some simple math:
500 Development Instances
Shut down from M-F 10pm – 8am = 50 hrs
Shut down Sat & Sun = 48 hrs
500 Instance X $.12 X 98 hrs = $5,880/wk
Here at DivvyCloud, our devs wind down about 10 or 11pm. We simply shut down our development environments at midnight and leave the instances off. Developers can easily turn them back on when they get rolling the next day. Or three days later then they revisit that specific project. Meanwhile, we don’t pay for unused resources. We have a large customer that follows the same strategy. The cost savings are impressive.
Starting and stopping is not always the best solution for every usage concern. Sometimes a test environment is needed for a developer account and will only be used for a few hours in one day. A deletion can be scheduled to terminate those instances. Accounts can even have policies that flag it for deletion after a set number of days, an ideal option for temporary use of instances for simple tasks and reports.
Empowering Users with Tagging
Altering policies for multiple accounts can be a headache if a team wants to work outside of scheduled hours. Using tagging strategies to opt in or out of scheduled stops gives dev teams more flexibility in the cloud. These tags can be used to temporarily alter shut down policies. Since your environment is always being pervasively scanned, the original policy will be reactivated, shutting down the instances at the established time.