#aws #ec2 #ecs
Welcome to day 10 of the unofficial AWS Cost Optimisation Advent Calendar 2024, where every day we will be sharing new tips or tricks to help you optimise your cloud costs before Christmas 2024.
Today we will be looking at Auto Scaling, a service that automatically adjusts how many EC2 instances, containers, or other resources you are using based on a set of rules.
Whilst Auto Scaling is a cost optimisation in itself, we are are going to try and delve a bit deeper into how you can optimise your Auto Scaling setup to squeeze out some extra savings.
You can skip this section if you are familiar with Auto Scaling, but for those who are new to the service, here is a quick overview of how Auto Scaling is a common cost optimisation tool.
Auto Scaling works by creating a group of resources, such as EC2 instances, and then setting up rules that determine when to add or remove resources from the group.
For example, you could set up a rule that adds a new EC2 instance to the group when the CPU utilisation of the existing instances goes above 80%.
At the same time you can set a target number of instances to maintain, so that in this example once CPU utilisation returns to normal, the Auto Scaling group will remove the extra instance.
In its simplest form and the most common setup will be to set up a minimum number of servers you would like to run at all times, and then based on CPU, memory or time of day (using scheduled scaling) you can scale up or down.
Typically these will be set up for EC2 instances, Lambda functions and ECS tasks. For these services the set up is fairly straightforward and there are numerous resources online for this so we won't cover it here.
Let's take a look at some of the lesser known features of Auto Scaling that can help you optimise your costs.
One of the lesser known features of Auto Scaling is the ability to use Spot Instances as part of your Auto Scaling group.
Spot instances allow you to save up to 90% on the cost of your EC2 instances.
As the very nature of auto-scaling means your instances should be ephemeral and be able to be terminated at any time, Spot Instances are a perfect fit for Auto Scaling as you can take advantage of the cost saving when it is available.
To use Spot Instances in your Auto Scaling group, you simply need to specify the ratio of Spot Instances to On-Demand Instances in your Auto Scaling group.
AWS will then automatically manage the Spot Instances for you, ensuring that you have the desired number of instances running at all times and take advantage of Spot when it is available.
The main consideration you need to take into account to leverage this cost saving is that AWS can terminate a Spot instance with just 2 minutes notice meaning you don't want to be using this in auto-scaling groups that have long running tasks where interruption would be a problem.
A common use case which can give you an idea of how to account for this is to use it for web servers. Although you don't want to terminate a web request whilst still talking to a client it is very rare for a web request to take longer than 2 minutes. Therefore you will need to look out for notifications that the instance will be terminated and shutdown the web server gracefully prior to this.
To monitor for termination you would typically have a cron job or logic in your application that checks the instance metadata for the termination notice which can be found at:
curl http://169.254.169.254/latest/meta-data/spot/instance-action
Most common web servers will have a graceful shutdown option which completes running http requests first before shutting down.
Whilst it is fairly well known that you can use Predictive Scaling for EC2 instances, it is less well known that you can also use it for RDS instances as by default RDS only supports autoscaling of storage unless you are using Aurora Serverless (see our post on Rightsizing RDS).
A fairly common occurrence in many companies is that they have periods of high load or large batch jobs that run and because they have had problems in the past they have deployed large database servers to prevent these issues.
One way to solve this is to switch to Aurora which can scale up and down based on load and let Amazon manage the scaling for you.
This is not an option for everyone so another tactic is to use Event Bridge and a timed Lambda function to scale up and down your RDS instance.
If you are just scaling read replicas then this is fairly straightforward and low risk. If you need to scale the primary instance this should take a lot of care as you don't want to introduce downtime or slowness.
To scale the primary instance you would typically set your Lambda function to introduce a new larger read replica with the desired instance size and then promote it to the primary.
It might sound a bit scary due to being your primary but the promotion process is well tested in AWS and in general can be done with a lot of confidence.
Another optimisation method is splitting your auto-scaling groups into specialised groups. Some examples are:
Auto Scaling is a powerful tool for cost optimisation and there are many ways to optimise your Auto Scaling setup to squeeze out some extra savings.
Hopefully some of the ideas here have given you some inspiration to look at your own workloads and see where you can make some changes to reduce idle resources.
To be one of the first to know when the next edition is published please follow us on LinkedIn, X or subscribe to the RSS feed.
Join our newsletter for Cost Optimization tips and tricks
By subscribing you agree to our Privacy Policy and provide consent to receive updates from our company.