It’s common practice to stop your EC2 machines outside of business hours. It’s a basic cost optimization strategy and is something Totalcloud simplifies for its AWS users. There are, however, situations where you might not be able to shut down your machines at night as you still need them running. Machines that have to remain up for a much longer period can’t be benefited from intermittent scheduling strategies.
This does not mean that you should ignore cost optimization for these instances. We came to realize a strategy that can still offer a reduction in cost even for these long-running instances. This strategy is executed in the form of our new use case, ‘EC2 Downgrade’. The goal here is to downgrade the machine to a lower spec and cheaper alternative for a temporary window where the workload is not as demanding. This way, even if you have to keep it running past your business hours, you can save costs by opting for cheaper machines to do the job.
EC2 Upgrade and Downgrade
So let’s say, you usually schedule your instances for a classic 9-5 workday, where your instances start at 9 am and stop at 5 pm. But since you need instances to remain running throughout, a classic start/stop won’t help. You can instead choose to downgrade your instance to a smaller machine type at 5pm everyday and upgrade it to another instance type at 9 am everyday. It’s the same concept of scheduling, but that action performed on the beginning and end of the schedule are different. (since YOU define the action, you can in fact instruct us to perform ANY action according to schedule, more about that here.
Similar to any scheduling action, you can set the desired time for when the changes should be made to the machine - or even have multiple intermittent schedules in a single day, depending on specific points during the day where traffic or workload changes. The temporary change in machines can match the new demands - while saving you that unnecessary cost incurred.
You can specify the machine type that you want your existing machines to upgrade or downgrade to. When the scheduled period arrives, your current machine will be turned off to accommodate your replacement. This specific use case provides for 2 actions - Upgrading or Downgrading.
Along with the option to switch out your instances, this ready-made template comes with the usual customization options like others. You can choose to perform other actions along with the downgrade/upgrade such as taking snapshots of a machine before it downgrades. The parking/un-parking actions both have the option to perform other tasks along with its intended one.
Why this use case can come in handy?
When you’re aware of regular workload fluctuations, it becomes extremely beneficial to automate the optimization part. The use case can be expressed as a TotalCloud workflow - and we’ve even templatized - so it essentially takes you a couple of minutes to set up. The workflow continues to perform the defined action according to the schedule you’ve mentioned, without any need for manual intervention. (Want to approve the action every time it is scheduled to happen? You can add a ‘user approval’ condition that send you a Slack or Email approval just before the action)
With the option of a recurring schedule, you can plan out exactly when you need downgrades and it will perform it every day/week at the specified time. The factors that go into deciding when you need to perform the action can go beyond just time. By viewing & measuring your CPU Utilization, you can identify over/under-utilized instances that can be included in your schedule. .
The best aspect of the feature is it reduces any need for you to directly configure these changes or have to write a lambda function that gets this done periodically. All you have to do is set the time and specify the instance you need.
Benefits of the Upgrade/Downgrade feature during operation
How it differs from AWS auto-scaling
On the surface, there are a few similarities between our new feature and AWS Auto-Scaling. Auto-scaling works by temporarily rightsizing the group of instances selected to meet the desired capacity. Scaling only affects the number of instances rather than the instances themselves.
The Upgrade/Downgrade feature works by switching out the instances matching your desired instance at your desired time.
ASG is a reactive scaling feature. Depending on the changes in your environment, your group of instances is scaled automatically. Whereas, our feature is similar to proactive scaling, the changes to your environment are made entirely by your preemptive setting.
Our template has far more possibilities in saving costs than ASG such as tag filtering, cross-region downgrading and scheduling based on utilization. The automatic scaling reduces your workload which is a great advantage and our feature requires your manual input in setting it up. Hence, when used together, this could be the best rightsizing solution for your environment.
I’ll give a quick rundown on how you can set up the downgrade feature. The template will be already available to you so most of your work is already cut down by a lot. All you really have to do is specify what you need and when you need it. This specific example seeks to downgrade our existing t2.micro machine to t2.nano during a specific period.
Choose ‘EC2 Instance Downgrade’ from the list of templates available
Set your timezone and scheduling period. This will be where you determine when you want to downgrade/upgrade your instances.
Select the AWS service. In this case, we’re strictly focusing on EC2 modification so the template would have already assigned EC2 instance for you.
Filter the instance you wish to modify.
You can filter by various metrics like a key-value parameter or tags. Below example will focus on tags.
You will be assigned with three parking actions. The first one is to stop the existing instance. The second is to load up the downgraded/upgrade instance you need by modifying your existing one. The third one is to start said instance.
You have to specify which instance you need to modify to. This is done in the second parking action, ‘EC2 Modify Instance Attribute’. Click on edit and then on ‘instance type’.
We’ll be downgrading t2.nano to t2.micro.
Choose the unparking action. The unparking action determines what to occur after the scheduled period is over. The pre-determined actions are similar to the parking action. Since you will be reverting back to your previous instance, modify the instance type from t2.micro to your earlier t2.nano.
This new template will add to your existing cost optimization strategies perfectly. we hope to put out more such use cases for AWS users. Sign up on Totalcloud to get access to this and many other templates.