The final bit of scaling that we should mention is time based or scheduled scaling. Scheduled scaling is when you add or remove instances from your auto scaling groups based on certain time parameters. For example, you might have a fleet of batch processing instances that you only want to go online during the middle of the night when spot instance prices are generally lower. You can have a scheduled scaling mechanism set in place to load up on these instances and get your work done during those specific hours. Scheduled scaling is a great way to help reduce costs by setting time periods in which your architectures run.

Another example is using scheduled scaling to turn off your dev environments after business hours have concluded. Why would you want to have any extra instances running when they don't need to be. With scheduled scaling you can turn off all of those test and dev workloads when they are not being used, and simply schedule them to turn back on in the morning.

And you can still have combinations of these scaling mechanisms working together. Maybe you have your dev and test environments set to turn on and off at night, but during the day, they can use dynamic scaling to increase the number of instances when needed, and tune back down to a minimum requirement when no tests are being performed.

Using scheduled scaling can save you quite a bit of money if you are able to work it into your architectures. It works especially well when you have harnessed the power of spot instances, which does require some allowances from your solution - like being able to handle stopping and starting.