Welcome to the world of money saving where everything you do should save you some cash to spend it on whatever you like !!!
What is Amazon EC2 Auto Scaling?
- Simple and automatic capacity provision
- Replacement of unhealthy instances
- Balanced capacity across availability zones
- Support for multiple purchase options
- Scaling of your infrastructure (up and down)
Why Spot Instances?
Amazon EC2 Spot Instances let you take advantage of unused EC2 capacity in the AWS cloud for up to a 90% discount compared to On-Demand prices. When making requests for Spot Instances, you can take advantage of “allocation strategies” within services such as EC2 Auto Scaling and EC2 Fleet.
Auto Scaling Group (ASG) Intro:
So now that we are ready to start using the Auto Scaling groups and feel the AWS vibes all over the place, let’s go over some of the basics:
I might use the term “ASG” for autoscaling groups because it’s Friday and I am lazy….Don’t judge me!
- ASG is a logical group of instances for your service
- The keys to activate this magnificent resource are:
- Desired Capacity: the number of instances you want you autoscaling group to spin at any given time
- Min: the minimum number of instances you want your autoscaling group to maintain at any given time
- Max: the maximum number of instances you want your autoscaling group to maintain at any given time
“Wait a minute…. There is the “auto” in “autoscaling”! So how…..what…..huh?
Calm down, calm down, although those are not a part of this article’s focus, here are the autoscaling methods !!!:
- Manual Scaling: you guessed it from the name, you just go and scale your ASG manually via the AWS CLI, API or directly from the console. Manual labor is still a part of our world in 2020 and it’s not going away any time soon
- Scheduled Scaling: you can and may go ahead and schedule the scaling of your ASG based on your needs and predictions. For example, if you know that your website gets a high amount of traffic on Mondays, every other month, between 9 and 10 AM, while it’s raining (just kidding), you can go ahead and set this schedule to launch more instances for that time frame to handle the load and then simply scale it down for you at the end of the given schedule.
- Dynamic Scaling: sounds cool right?! Well…it is!
You can and may use Scaling Policies. This a super powerful tool that can be configured any way you like to meet your most specific and custom needs. - Predictive Scaling: Just like one of Harry Potter’s classes, AWS can too look into the past and future. This is possible with this super cool scaling method that uses machine learning to look into your past scaling patters and try to predict what, why, when and how your ASGs should scale
If you want to know more about ASG in general, go ahead and visit the AWS Documentation Section and dive in!
We are getting closer to the real bread and butter of this story but first, a quick look at the past and the present of the ASG structure:
- Multiple ASGs
- Each type was in a different ASG
- Many resources to manage
- Many actions to take in case of scaling
- Single ASG to rule them all !
- Easy control over each type
- One source to scale from
The above images are showing that you can now configure and customise one ASG to use all three of the purchase types:
- On demand: instances that you launch and never go away while you keep paying the same stable price for them (just like my needy dog)
- Spot: A Spot Instance is an unused EC2 instance that is available for less than the On-Demand price.
- RI: basically, you “rent” and instance while paying a fixed price with option for an upfront payment as well to lower that fixed payment
Now we are getting to the good stuff!
Allocation Strategies:
- Lowest-price (diversified over N pools) allocation strategy: this strategy will deploy instances from each pool of instance types and the price limits you give it.
Since the price is constantly changes, those instances will be terminated and replaced by new, cheaper once thus potentially disrupting your service at a higher rate. - Capacity-optimised allocation strategy: the Star of our show today!
This strategy does not look at the prices of the instance types in each pool configure but instead looks for the optimal capacity volume and chooses those instances to run your service on.
Since it does not care about the price, even if it changes, the instances will remain online and will not terminate as frequently as the Lowest-price strategy. The only time it may and will replace the instance is if a better pool with the highest capacity needed for your service is available.
Lets review this use case and assume you are using the below:
A “c5.large”, “c4.large” , “c3.large” instance types for your ASG,
three availability zones : us-east-1a, us-east-1b and us-east-1c,
the “c3.large” costs less than “c4.large” and “c5.large”
but has less free capacity left in each availability zone:
- Lowest-price: will look inside the available instance pool in each availability zone and launch the least priced one which will select the:
– “c3.large” and “c5.large” in us-east-1a
– “c3.large” and “c4.large” in us-east-1b
– A mix of the three in us-east-1c
This happens because the price is in fact lower for “c3.large” but it does not have a lot of capacity left to play with.
For the Lowest-price allocation strategy A mix of types were chosen and spread across the availability zones. Since the price of all three types may and will change frequently, the instances in those families will terminate and be replaced by a new cheapest type. - Capacity-optimised allocation strategy: will look at the free capacity in. each availability zone and launch the types with the most capacity left:
– “c5.large” in us-east-1a
– “c3.large” in us-east-1b
– “c5.large” in us-east-1c
For the Capacity-optimised allocation strategy the types with the most capacity were chosen regardless of the price thus they will not be impacted by the price fluctuation and remain up and running until the free capacity amount changes. Since that happens less frequently then the price change, the volume of interruptions to the instance and your service will be minimised.
This allocation strategy may be especially useful for workloads with a high cost of interruption, including:
- Big data and analytics
- Image and media rendering
- Machine learning
- High performance computing
Well well well, now you know how to take care of your precious application/server/whatever magic you want to run and make sure that the interruptions to your money maker are minimised and you can finally afford that coffee machine you always wanted for your office !!!
