Amazon CloudWatch is a web service that enables you to monitor and manage various metrics, and configure alarm actions based on the metrics. A metric is a variable that you want to monitor, for example, CPU usage or incoming network traffic. A CloudWatch alarm is an object that monitors a single metric over a specific period. The alarm changes its state when the value of the metric breaches a defined range and maintains the change for a specified number of periods.

Amazon CloudWatch can aggregate metrics across pre-defined dimensions, for example, aggregating the CPU utilization of all EC2 instances in an Auto Scaling group. The alarm connected to an Auto Scaling policy triggers a scaling event, and the number of instances are increased or decreased as per the defined policy. For these simple scaling policies, the reaction is always the same independent of the size of the breach. Such policies lock the Auto Scaling group while a scaling action is running, and no further alarms can be raised during this time. Additionally, it evaluates the metric only when no scaling action is ongoing. However, such policies do not let you control how aggressively you want to react to the breaches of your metrics. 

We can also define Step Scaling policies in which we can define multiple steps in the same policy. The appropriate scaling step is selected based on the value of the metric that triggered the alarm, based on the magnitude of the breach. In these policies, the metrics are continuously evaluated and it does not lock the Auto Scaling group while the action is evaluated. You can also use additional metrics and define multiple thresholds to specify the best strategy for your use cases. Overall, Step Scaling policies are the better and more flexible choice.

Aside from the scaling policies, you can also leverage the Instance Lifecycle hooks for finer grained control for launching and terminating instances. These hooks are useful in supporting common use cases including assigning EIP address on launch, registering new instances with DNS, gathering log files before instances are terminated, investigating issues with an instance before terminating it, and so on.

In situations of rolling deployments across Auto Scaling groups, you can terminate the instances one by one, followed by relaunching the instances (the new instances will launch with the new configurations enabled).