AWS Cost Saving Tip 6: Amazon Auto Scaling Termination policy and savings

We all know that Amazon Auto Scaling launches and terminates EC2 instances automatically in response the traffic. Amazon Auto Scaling supports 5 types of termination policies currently to scale down the EC2 instances in event of low traffic. In this tip we are going to explore how choosing the termination policy wisely can save cost.

Imagine you are running online website with spikey traffic pattern in a day as illustrated below. 

If Instances are rapidly launched and terminated it may lead to cost leakage sometimes. Recommended approach is to scale out aggressively and scale down slowly, Example: If new instances are launched by auto scaling in an hour, we are already paying for that hour, so it is ideal that we retain those EC2 instances during that hour as much as possible and terminate them nearing the hour.

Let us see what options we have in Amazon Auto scaling for termination policies. Instead of discussing all the termination policies, we will take 2 policies and see their fitment:

Oldest Instance: You can configure this option if you want the oldest EC2 instance in your Auto Scaling group to be terminated. Auto Scaling uses the instance launch time to identify the EC2 instance that was launched first and terminates them. One catch to this approach is that Oldest EC2 instance need not be closest to that instance hour, so there are chances that they are terminated within 5 minutes of an instance hour start. Example: Imagine 4 X m1.xlarge EC2 instances are started at 9:00 AM EST and X new instances are launched subsequently during the day in batches according to load pattern. At 1:05 PM EST the traffic is slowed down drastically and Auto Scaling uses the OldestInstance Termination policy to bring down the 4 EC2 instances launched at 9:00 AM EST. Looks fine till now. But there is sudden surge of traffic @ 1:40 PM EST which demands 4 new EC2 instances to be launched. Now Auto Scaling launches the needed EC2 instances in the same instance hour (between 1:00 PM to 2:00 PM EST), we have unnecessarily terminated 4 EC2 instances , paid for it and as well launched another 4 and paid for it again as well. This boils down to cost leakage of 4 X 0.480 (current cost of m1.xlarge instance) = 1.92 USD for single Valley->Spike scenario. Imagine this pattern occurs 3- 4 times a day and totaling to ~120 times a month , which contributes to a cost leakage of 1.92 X 120 = 230 USD per month.

This cost leakage can be more than what we have predicted if:

• ·      Valley-Spike scenario occurs more frequently per day
• ·      Number of EC2 instances involved in Auto Scaling are more
• ·      Instance Types used are bigger capacities and costlier

Now let us see how we can use more optimal Auto scaling termination policy to avoid this leakage. Welcome to ClosestToNextInstanceHour Termination policy.

ClosestToNextInstanceHour: You should configure this option if you want the instance that is closest to completing the billing hour to be terminated. In this case the Amazon Auto Scaling will not terminate the oldest instance, but it will terminate the instance that is closest to the next instance hour. Since it maximizes the EC2 instance run to the hour, the Valley-Spike can be accommodated without terminating-launching the EC2 instance rapidly. By selecting the instance that is closest to the next instance hour, it helps maximize the hours your instances run while minimizing the billable instance-hours. It is recommended to use this termination policy based on your scaling fitment and  save cost.


Other Tips

Cost Saving Tip 1: Amazon SQS Long Polling and Batch requests
Cost Saving Tip 2: How right search technology choice saves cost in AWS ?
Cost Saving Tip 3: Using Amazon CloudFront Price Class to minimize costs
Cost Saving Tip 4 : Right Sizing Amazon ElastiCache Cluster
Cost Saving Tip 5: How Amazon Auto Scaling can save costs ?
Cost Saving Tip 6: Amazon Auto Scaling Termination policy and savings
Cost Saving Tip 7: Use Amazon S3 Object Expiration
Cost Saving Tip 8: Use Amazon S3 Reduced Redundancy Storage