ASG与ALB的集成
在创建ASG时有几个选项，可以选择是否将ASG绑定到Load Balancer上：
在创建完ASG后，也可以随时编辑是否将其绑定到Load Balancer上：
本节我们直接在ASG上创建一个新的ELB并与之绑定(也可选择先提前创建好再绑定)。
创建ALB并绑定到ASG
上面点击Edit后，选择创建一个新的Internet-facing类型的ALB：
在这个ALB上创建一个新的target group：
最后点击Update。此时查看ALB页面，发现会有一个新的ALB正在创建中：
创建完成后，能够访问到后端服务(在创建Launch template一节，EC2上设置了userdata)
health check
ASG的属性上，有两个health check的选项，一个是基于EC2，另一个是基于ELB：
-
基于EC2的检查——检查实例状态，包括
System status check和Instance status check，但如果实例的应用端口挂了，这种场景是检查不到的。
-
基于ELB的检查——使用ELB的
health check可以检测到端口unhealth。
如果ASG挂到ELB下面，AWS强烈建议选ELB类型的检查
先开启ELB类型的检查：
为了模拟ELB健康检查失败的场景，我们先在ASG后面运行两台机器，然后登录到其中一台把端口人为搞挂掉，测试ASG会不会检查到这种情况，然后拉起新的机器替换掉原来不健康的实例。
将ASG的最小容量调整为两台：
等有两台机器稳定运行后，登录到其中一台上面，将httpd服务杀掉：
刷新ALB页面，会有一半的机率访问到挂掉的服务：
等待一段时间后，ASG会检测到挂掉的EC2(其实是ELB的健康检查做到的):
然后ASG拉起一台新的实例，来保持健康状态的实例数量：
从Activity history中也能看到对应的事件：
由于默认Deregistration delay时间设置为300s，所以要等一段时间才能将这台故障的EC2从ASG中移除：
