The terms “Highly Available” and “Scalable” are not new anymore. But, there are many scenarios which demand smarter approaches to achieve them. For On-premise applications, it is little difficult and costly to achieve HA and scalability, compared to On-cloud applications.
However, in Amazon Web Services (AWS) cloud, we have something called Auto Scaling Groups (ASG). An ASG contains a collection of Elastic Compute Cloud (EC2) instances that share similar characteristics and are treated as a logical grouping for the purposes of instance scaling and management. As an ASG ensures scalability, we must understand that it does come with a price!
Cost savings is a crucial factor for any organisation, big or small. Hence, we need to be careful while implementing the HA + scalability architecture in cloud, keeping the monetary aspects in perspective.
A Familiar Scenario
For instance, let’s say, Sameer has created an ASG for a proof-of-concept (POC) that he’s working on. If the POC is going on for a longer time, then Sameer might receive a significant EC2 bill. And, if he is using the “Free-tier”, there’s a likelihood that he might exceed the free-tier limit. This is quite possible, as the instances in ASG would be running 24×7, even if Sameer is not using them.
A question thus arises: How can he avoid getting charged for the time he did not use the ASG instances?
The first thought that comes to mind when thinking about cost optimisation for EC2 is shutting down the instances when not in use. Yes, Sameer too can shut downs the instances after his work is done for the day. However, because an ASG is in place, any instance going down would result in a new EC2 instance being automatically spawned (to maintain the desired count).
So what best can be done in these scenarios?
Here are a couple of choices that Sameer has,
- Manually update the minimum and desired values for ASG to 0-0
- Write a Lambda function to update the minimum and desired values for ASG
Though the latter is a good option, we must not forget that the final goal is to save the cost. If Sameer creates a Lambda function to update the ASG during non-working hours, he will incur the lambda cost (no matter how small). Additionally, he will have to invest some time and effort in creating the lambda function
A Smarter Approach
Is there any simpler method which will help save cost and would involve comparatively less efforts?
Yes, there is!
ASG has a feature called Scheduled Actions (don’t worry if you haven’t heard of it yet). Conventionally, Scheduled Actions are used for scaling out for certain amount of time or at specific time of the day (e.g. being ready for high traffic in advance) and later scale back in.
So, coming back to our scenario: one might wonder if these Scheduled Actions can be used to update the ASG’s min-desired values to 0-0 and then again, reset the min-desired values to desirable values like, say, 1-2.
The answer is Yes!
While implementing the Scheduled Actions, we have to specify the value for Recurrence field i.e., when or how often the action should be executed. It supports multiple values like, once, everyday, every week, etc. We can also specify a cron expression.
So, if Sameer wants to bring up the instances in ASG during office hours he can use a Scheduled Action with Cron expression and similarly, he can configure a second Scheduled Action to stop the EC2 instances during non-office hours and weekends.
An example for Scheduled Action for Starting and Stopping EC2 instances in ASG is shown in below snapshot,
This way, Sameer could keep the costs in check, while ensuring that the HA + scalability aspects are not compromised.
The DevOps team at BlazeClan employs as well as advises several such optimization techniques to ensure that our clients get the most out of their cloud-based applications. Do get in touch with us if you would like us to advise on your solutions!