If AWS is giving you a ‘pay for what you consume’ model for every resource, and you aren’t scheduling every resource, you’re pretty much paying for what you don’t consume too. Especially if just basic 9am-6pm scheduling can save you at least 60% of your costs.
Although we have been offering scheduling through our templates since always, we joined the bandwagon to solutionize it - say hello to our Resource Scheduler. And to 2 extremely unique features:
The most commonly scheduled resource is EC2 instances, and why not? The cost saving is huge. Say you schedule your non-prod instances to run between 9am and 6pm, you’re essentially cutting uptime by 15 hours - a whopping 63%. But it doesn’t have to stop there!
Scheduling doesn’t stop at EC2
If just EC2 instances can save you such costs, imagine the impact if you start scheduling other AWS services? Whether it’s RDS, Redshift, Elasticache, ECS, or EKS; every resource can be put on a schedule with TotalCloud.
TotalCloud’s Smart Scheduling
In addition to time-based schedules for your resources, we’ve gone a step ahead to optimize the resource, with a base wider than just time. Usage-based scheduling lets you power on/off depending on whether you’re using the resource or not. We call it the ‘Smart Scheduler’.
Let’s take the example of EC2 instances - In the case of your non-prod instances, you’re most likely not even using it for 9 hours a day. In fact, you’re probably only using it a few days in the week - or you just can’t possibly predict it. Here’s where real time scheduling helps. Your instance shut down automatically when it detects an idle stage based on the thresholds you define. Your savings could actually be 2x, and this applies to all resources.
Shift to real-time usage-based scheduling
Let’s say you have a multi-geo set up, with resources being used at various times by various teams. It becomes difficult to set up automated schedules based on time. Or if you’re dealing with a complex infrastructure that’s set up in a way time-based schedules can’t satisfy your goal. That’s why you need to shift to usage-based schedules. You don’t need to spend hours trying to figure out what time works for all your different teams. If you’re not using it, it shuts down, period.
In a lot of cases, your resources are set up by one team but used by another. Not only does deciding a time become tedious, but if the ops team needs an resource to be started immediately, it requires them to reach out to whoever set it up. It’s all chaos. Instead, the resources can power off when there’s no usage, and can be restarted through a slackbot or by triggering a simple URL based workflow whenever needed, and the cycle continues.
Fully integrated & Customized - We wanted to integrate scheduling into your existing tech stack seamlessly. That’s why we have extremely flexible triggers - this means that your schedule can be triggered from practically anywhere through HTTP calls.
The schedules also have extremely granular settings to define the preferred action before starting and after stopping a resource. For example, say you want an instance attached to an Elastic Load Balancer or an Auto Scaling Group when it restarts.
Flexible filters - You have a 1000 different resources and want bundles of them to be scheduled in different ways? This becomes very easy through flexible filters. You can filter out the resource for every schedule based on name, ID, tags, or any custom parameter that you use. This way you have exactly the right schedule for exactly the right type of resources.
Scheduling recommendations - If you don’t know which resource to schedule, we’ll tell you! Receive utilization-based scheduling recommendations that tell you which resources you can put on schedule, so you’re not missing out on any cost-saving opportunity.
What else is out there?
For as long as AWS has existed, we’ve scheduled our EC2s and nothing else. We wrote up basic scripts that worked, but everytime a new requirement popped up, it was scripting from scratch. Or we used the AWS Instance Scheduler, but it’s the same process. This is time-consuming and tedious (imagine keeping a track of every script you’ve made). It never scaled with our operations either.
On the other hand other tools can be a quick automated fix, but they don’t schedule everything and they don’t give you the flexibility you need. In today’s level of automation, we can not go the siloed way.
We deserve a scheduler that’s smart
Resource scheduling has become a mandatory cost-saving function. We’ve also seen that scheduling shouldn’t stop at EC2. Shift to the smarter way of scheduling, and save at least 60% of your costs, if not more. You can give the platform a try here for free.