Suspended Processes
ASG上的行为很多，如启动实例、终止实例、将实例注册到ELB，用户可以选择让ASG的某些行为暂时停止，用于调查ASG的配置问题或者其他目的。
在创建完成ASG后，编辑Advance configurations，可以配置ASG的suspended process:
包括以下行为：
Launch— 当ASG扩容时，往里面添加新的EC2Terminate—当 ASG缩容、或者实例健康状态异常时终止机器AddToLoadBalancer—当实例启动后，将实例添加到ELBAlarmNotification—上两节将到Dynamic scaling，它们都是基于CloudWatch Alarm实现的。如果禁用这个过程，所有的Dynamic scaling策略都会失效。AZRebalance—当EC2在AZ间分布不均衡时，ASG主动重新分布EC2到各个AZHealthCheck—检查EC2的状态InstanceRefresh— 进行instance refresh活动，参考上一节ReplaceUnhealthy—终止不健康状态的实例，启动新的实例来替换它ScheduledActions—进行scheduled scaling，前面也讲过
下面我们将一个个介绍，将这些行为暂停后，ASG的表现会如何
Launch
当停掉Launch时，ASG不会再创建新实例。
例如此时将Desired capacity设置为2（当前只有一个实例）：
ASG中实例的数量依然不会增加：
Terminate
当前ASG实例有两台，当停掉Terminate后，再将desired capacity设置为1。ASG并不会采取Scale in操作
HealthCheck
停掉HealthCheck后，ASG会阻止收到EC2或ELB的健康检查。
例如下面有两台实例在健康运行：
将一台EC2的服务停掉：
此时Target group已经检测到服务挂了，将实例状态变为unhealthy：
但ASG的健康状态还是Health：
ReplaceUnhealth
停掉ReplaceUnhealth后，ASG能够接收到EC2或ELB的健康检查通知，但不会主动停掉unhealth的实例。
例如下面有两台实例在健康运行：
将其中一台的服务搞挂：
此时ELB的target group检测出来服务unhealthy，然后将消息通知到ASG：
但ASG不会处理任何Unhealth的实例。
将ReplaceUnhealth这个给去掉后，ASG会马上将unhealth的实例的给下掉，新创建一台健康的机器挂上去
AlarmNotification
如果停掉这个活动，ASG不会收到CloudWatch Alarm的通知。
例如使用target tracking policy配置了CPU大于60%时扩展机器，则这个策略不会生效。
AddToLoadBalancer
停掉ReplaceUnhealth后，ASG不会将新创建的机器加到LoadBalancer里。
将需要实例的数量由2设置为3：
ASG创建完成机器后，在ASG里可以看到三个Healthy的实例：
但在target group里，新建的机器并没有被加上去：
当把这个规则停掉，新创建出来的那台机器会自动挂到target group里吗？答案是不会。
需要手动在target group里面加上去：
