器大活好，能大能小能伸能缩：AutoScaling
我们可以先假设一个应用场景，比如说我启动了一个实例，实例上搭建了一个网站，半夜十二点的时候，假设只有几十人访问，那这时候只用这一个实例就可以承担这几十人访问的负载，而在白天，或是晚上七八点的时候访问的人会特别多，这一个实例可能就承担不了这么多的负载，我需要多启动几个实例，利用cloudwatch监控实例的运行状况，当实例的cpu利用率过高的时候就开始启动实例，可是又不能人为地启动实例，因为你不知道什么时候流量会增多，这时候就需要利用Autoscaling让系统自动地为我们启动实例，而当cpu利用率变低的时候，可以让Autoscaling为我们终止实例，利用Autoscaling可以打造自动扩展收缩弹性系统。
Auto Scaling能够根据需求自动增加或减少启动实例的数量，来确保系统运行所需要的实例数量，在需求高峰时Auto Scaling自动增加EC2实例，确保性能稳定，在需求降低时自动减少EC2实例来降低成本。
Autoscaling中还有两个概念需要理解：
启动配置和Autoscaling组。
启动配置是用于AutoScaling启动EC2实例的模板。在这里可以指定实例的信息，例如Amazon系统映像(AMI)的ID、实例类型、安全组和绑定的角色等。同时在这里可以配置监视EC2时使用CloudWatch详细监控，还是基础监控。默认情况下，当手动生成启动配置的时候，是使用的基础监控，当利用CLI或者API生成启动配置的时候，默认使用详细监控。不同的AutoScaling组可以使用相同的启动配置，但只能使用一个启动配置。在启动配置被生成后，是不能被修改的，如果业务需要使用新的启动配置，只能重新生成新的启动配置。当使用新的启动配置时，新生成的实例会使用新的启动配置中配置的参数，但是已有的，使用旧的启动配置生成的实例不会受到影响。
Autoscaling组中包含的概念比较多。它是ec2实例的集合，Autoscaling组可以根据指定的条件自动扩展实例数量，或减少实例数量，这种维护实例数量的功能是Autoscaling服务的核心功能。
•定义了启动EC2实例时，使用哪个启动配置。
•定义了启动AutoScaling组后初始实例数，最小及最大实例数。初始实例数是指系统在任何时候都至少拥有的实例数。这里定义的最小及最大是极限值，即自动启动EC2实例的时候，不能超过这里定义的范围。
•定义了在哪个VPC的哪个子网中启动实例（AutoScaling组不可以跨VPC，即不可以跨区域，但是可以跨某个VPC下的多个子网）。
•是否配合ELB使用。
但配合ELB使用时，通过健康检查※，判断组中的实例是否是健康的，如果不是的话，AutoScaling会将不健康的实例终结掉，然后重新启动新的实例。（自动愈合，实例的个数）。
•Scaling策略，定义了在哪种情况下需要增加实例，在哪种情况下需要减少实例。
•SNS通知，当AutoScaling组内的实例出现某些情景(启动，终结，启动失败，终结失败)时可以通过SNS邮件通知用户。
※健康状况检查类型：
Auto Scaling中实例的运行状况有正常和不佳两种。一个实例在通过初始运行状况检查后，将被Auto Scaling视为正常。Auto Scaling定期对Auto Scaling组中的实例执行运行状况检查并标识所有运行状况不佳的实例。Auto Scaling在将一个实例标记为运行状况不佳后，会计划替换该实例。而确定实例的运行状况可以使用两种检查：一个是ec2实例提供的状态检查，一个是负载均衡器提供的运行状况检查。
Ec2实例的状态检查分为两种：一个是系统状态检查，一个是实例状态检查。
①系统状态检查，检查的是实例所在的aws系统，由于是系统问题，所以一般情况下，如果系统出了问题，我们只能等待aws来修复，可能导致系统检查失败的原因有：
网络连接丢失
系统电源损耗物理主机上的软件问题物理主机上影响到网络连接状态的硬件问题
不过如果我们的实例利用的是ebs卷的话，我们可以通过停止并再次启动实例来解决系统问题，因为再次启动之后，ec2实例会在新的物理主机上启动，所以系统问题应该会被解决掉，不过如果实例利用的是实例存储卷的话，只能把实例终止掉，再启动新的实例，因为把利用实例存储卷的实例停止后，实例中的数据都会丢失，所以只能启动新的实例替换原来的。
②实例状态检查，监控的是各个实例的软件和网络配置。如果实例状态检查失败，一般需要自行解决问题(例如，重启实例或更改实例配置)。
可能导致实例状态检查失败的原因有：
系统状态检查故障网络或启动配置不正确内存耗尽文件系统损坏内核不兼容。
再看负载均衡器提供的运行状况检查：为了查明EC2实例的可用性，负载均衡器会定期发送ping、尝试进行连接或者发送请求来测试EC2实例。这些测试称为elb的运行状况检查。两者检查的对象是不一样的，ec2检查的是这个是实例是否在正常运行，而elb检查的是实例上的应用是否在正常运行，所以当AutoScaling和ELB配合使用时，比较推荐使用elb的状态检查来确定这个实例该不该被替换。
运行状况检查宽限期，是为了给实例提供足够的预热时间，默认系统会等300秒后才对EC2和elb进行状态检查以及运行状况检查。
实例保护，如果启用了实例保护，则这个autoscaling组中启动的实例在scale in的时候，也就是当系统想要终止我们的实例的时候，是终止不了的，启用了实例保护之后，组中所有的实例都启用这个属性，从而保护不被终止，当然这个属性也可以单独对某个实例进行设置，比如autoscaling组中不设置，在其中启动的某个实例上启用这个设置，来保护该实例。
配置扩展策略：这里有两个选项：
①保持初始大小，利用这个可以保持Auto Scaling组中的实例数量，Auto Scaling组首先启动我们刚才配置的最小数量的EC2实例。为了保持这个数量的实例，Auto Scaling对Auto Scaling组内运行的实例执行定期运行状况检查。如果发现实例运行状况不佳，它将终止该实例，并启动新实例，从而保证autoscaling组中的总数量不变。
②使用扩展策略调整此组的容量，这里就是配置当系统的某个数据满足某个条件时，让系统自动地增加或减少ec2实例数量来满足需求。这里还可以设置最大和最小值，系统会在这两个数值之间启动或终止实例。
•使用扩展策略扩展autoscaling组的话，核心就是当系统满足一定的条件的时候，系统会自动地添加或者删除实例。这里的条件需要在警报中生成。比如，当系统平均的cpu利用率连续5分钟低于30%的时候，自动的删除1个实例，同时生成一个警报，向sns的主题发送该信息；或者当系统平均的CPU利用率连续5分钟高于80%的时候，要自动添加一个实例，同时生成一个警报，向SNS的主题发送该信息。
配置通知，我们还可以当这个组中的实例：启动，终止，无法启动，无法终止，发生这些动作变化的时候，发送信息到sns的主题，比如当系统中新启动了一个新的实例的时候，有了这个配置通知，系统管理员就会收到SNS的通知。
Autoscaling组是可以进行编辑的，但是启动配置是无法进行编辑的，如果想要对启动的ec2实例进行更改，只能再生成一个新的启动配置，然后在autoscaling组这里对启动配置进行更改。
这里还有一个比较重要的概念：AutoScaling CoolDown冷却时间。当系统的CPU急速的被消耗的时候，CloudWatch会检测到CPU的变化，从而促使AutoScaling来根据设置的扩展策略自动的添加实例个数。但是从实例的启动到正常运行是需要一定的时间的，比如该实例上需要配置很多软件，那么可能就会花很多时间，如果在这个实例还没有正常运行的时候，那么CPU的利用率还是比较高的状态，这时CloudWatch就会认为现在的系统仍然需要更多的实例，CloudWatch的警报就会被触发后，继而又会添加新的实例。问题就出现了，CloudWatch没有等到被添加的实例正常运行，就又添加新的实例了，这时候可能就会出现浪费实例的情况。有了冷却时间之后，AutoScaling在启动实例后，就会等待一段时间，这段时间内，CloudWatch不会被触发，扩展策略引起的扩展活动就会被暂停，当冷却时间过后，新添加的实例也正常工作了，然后扩展活动会被恢复，CloudWatch再被触发的话，新的实例就会被添加，同时冷却时间会再次生效。创建AutoScaling组的时候，默认会应用冷却时间（默认300秒）。
总结：当使用AutoScaling的时候，它会使用我们配置好了的启动配置和AutoScaling组，在某个VPC（自定义）下的某些子网（自定义）中启动在AutoScaling组中定义的初始实例数。A：如果不让系统调整实例个数，那么无论发生什么情况，系统都会尽可能的运行固定个数的实例，比如说我们的Autoscaling组中设置了初始所需要的实例个数是2，那么这时候我们会有两个实例被自动地启动，最初启动的实例的个数就是这个所需的个数，如果我们把一个实例删除了，或者是运行状况检查失败了它还会启动新的实例，来保证系统中有我们所需个数的实例，这个就是自我恢复功能，像金刚狼一样。B：如果使用扩展策略来调整系统中的实例个数，那么系统会根据我们设置的条件，自动地增加或者减少系统中的实例个数。比如当系统中的CPU利用率超过80%，要自动的增加2个实例，当系统中的CPU利用率低于30%，要自动地减少2个实例，同时冷却时间会生效，但是无论系统怎样自动添加或减少实例的个数，都不会超过设置的最小和最大实例个数。同时还可以当实例的个数或者状态发生改变的时候，用设置的SNS通知系统管理员。
