Now you might be wondering why we would ever need to get our hands dirty with something that should be automatic. The whole point of this service is to let things elastically scale based on the needs of the system.

Well, a prime example that comes to mind is if you know you are about to experience a large spike in traffic. This is a perfect time to get ahead of the problem and manually adjust your desired number of instances within your auto scaling group. By having your fleet already scaled up ahead of a large surge of traffic, you can prevent your users from having a bad experience. 

These types of scenarios often come up when a new marketing campaign has been launched. For example, if you were to run an ad during a major sporting event that has millions of viewers, you would probably want to get your fleet pumped up ahead of time. The longer a user has to wait for your webpage or application to load, the more likely they are to leave.  And if you just spent millions of dollars to get them there in the first place, that's not going to look good when your boss comes knocking.

So in this scenario, Not only would you adjust your desired number of instances within your fleet, you would also want to increase the maximum and minimum numbers available as well. And when you know the surge has died down, you can go back and return the numbers back to their normal levels.

The pros of manually scaling your auto scaling groups is that you can get ahead of an event before it takes place. It allows you to reduce downtime for your end users, and gives you the flexibility to manually dial back if you do find yourself over-provisioned.

The cons are this is not a scalable solution. Manually adjusting your scaling groups every day by hand is not what you want to be doing long term. It is for blue moon scenarios and planned large-scale events.