基于即付即得（pay-as-you-go）的云计算模型有助于开发人员和架构师设计出能够一直运行于***资源分配下的应用程序。给服务器过高的配置来满足业务需要意味着花费太多冤枉钱，这个错误的另一个极端则更糟糕，即给服务器过低的配置导致应用程序的性能不足。而应用程序要求的变化使得对服务器配置的选择变得更加困难，因为***的资源组合不是一成不变的。
使用AWS服务来应对这些变化的一种方法是创建一个负载均衡服务器集群，然后根据需要添加或删除服务器。你可以自己管理这样一种集群，除此之外,你还可以尝试AWS Auto Scaling服务。该服务在避免过度配置的条件下保持足够的性能，同时也能够减少一些管理费用。该服务要达到的***应用场景是工作负载变化显著变化时，AWS Auto Scaling能够轻松地跨多个服务器分配负载。
AWS Auto Scaling 使用CloudWatch（亚马逊提供的一种监控工具）来提供所需的性能数据，完成伸缩服务建议。每隔五分钟，CloudWatch都将从服务器和其他AWS资源处，免费地收集性能统计数据，包括CPU使用率、磁盘使用情况和数据传输情况等。（额外付费的话将可获得每分钟一次的性能指标收集服务。）系统管理员可根据这些测量信息规定添加或删除服务器的配置策略。例如，一项配置策略指示当CPU平均利用率超过70%时，将启动一个额外的虚拟实例。
通过实现自动伸缩组协助制定配置策略
使用AWS Auto Scaling服务的***步是实现一个自动伸缩组，即在逻辑上统一管理的一组亚马逊弹性计算云（EC2）实例。每一个组均被指定了最小和***实例数，而实际数值则由基于CloudWatch的测量值做出的配置策略来决定。当需要手动干预时，通过AWS提供的ExecutePolicy命令行，系统管理员便可以无需等待触发条件，直接执行一项策略。
通过自动伸缩组的应用，企业在维护应用程序性能和开销的许多相关工作中得到了帮助。
自动伸缩组能够跨越可用性区域（一种能够支撑应用程序高可用性要求的特性）提供服务。这些可用性区域处于AWS 范围内，例如，美国东部（北维吉尼亚）或欧盟地区（爱尔兰），通过不同的基础架构隔离故障实例与正常实例。如果在某个可用性区域中发生了故障，AWS Auto Scaling将在同一个地理区域内的某个功能区启动一个新的实例。
自动伸缩组能够通过负载均衡器配置集群内服务器间的工作负载。亚马逊的弹性负载均衡服务提供了一个到你的应用程序的所有流量的单点访问。当使用负载均衡器时，可以引用负载均衡测量指标（比如请求等待时间）以及EC2实例测量指标来制定自动伸缩策略。
除了响应变化的负载，Auto Scaling还支持其他伸缩选项，包括持续确保当前实例的性能、手动伸缩以及基于排程的伸缩。
应对AWS Auto Scaling的潜在问题
完成一项自动伸缩策略的指定动作需要花费一定的时间，然而，AWS在一次触发后，实现了一个冷却周期，用于防止当对触发器最初的响应还在继续的时候，执行了对触发器第二次响应所引起的一系列事件。冷却周期始于执行策略动作。
针对Web服务器和一些应用程序服务器而言，当应用程序负载可以分布在多个服务器之上时，自动伸缩不无裨益。某些系统（如关系型数据库系统）可以配置运行于集群中，但其中存在诸多缺点：商业版关系型数据库可能通过收取额外授权费用来提供集群支持，这些授权费甚至会超过因在不同数量的小型服务器运行数据库而拒绝一台大型服务器所节省下来的费用。此外还要考虑管理数据库服务器集群与管理单个服务器的不同开销。
