我的情况并不那么复杂，但在AWS云计算上却很复杂：
我想根据SQS上的消息数量来上下自动调节。
但我不确定我需要在AWS cloudformation上指定什么，我想我会需要：
某种对AutoScalingGroup上当前实例数进行查询的lambda / cloudformation
某种lambda / cloudformation，用于对SQS上当前的消息数进行查询。
比较＃1和＃2的一些比较操作。
在＃1＆lt;时创建扩展策略＃2
在＃1＆gt;时创建缩小规模政策＃2
不确定我应该从哪里开始......有人可以展示一些例子吗？
答案 0 :(得分：0)
您将几个不同的概念混合在一起（CloudFormation，Auto Scaling，Lambda）。最好保持简单，至少在初始部署时如此。然后，您可以稍后使用CloudFormation自动执行此操作。
Auto Scaling最困难的部分实际上是确定要使用的最佳扩展策略。一般规则是在需要时快速添加容量，然后在不再需要时缓慢移除容量。这样，您就可以避免 churn ，在短时间内添加和删除实例。
最简单的设置是：
对缩放政策使用ApproximateNumberOfMessagesVisible指标。 （见Amazon SQS Metrics and Dimensions）。它提供了等待处理的消息计数。但是，我已经看到零计数实际上并未作为指标发送的情况，因此还会在 INSUFFICIENT_DATA 的警报状态下触发您的扩展策略，这也意味着队列是空的。
无需使用AWS Lambda函数，除非您对何时扩展有非常复杂的要求。
如果您的请求全天定期，请将最小值设置为一个实例以始终具有可用容量。
如果您的请求不常见（并且可能有几个小时没有请求进入），请将最小设置为零实例，以便节省资金。
您需要尝试确定应触发横向扩展事件的最佳队列大小。这取决于消息到达的频率以及消息处理的时间。您还可以尝试实例类型 - 确定是否更好地拥有许多较小（例如T2）的实例，或更少的较大实例（例如M4或C4，视需要而定）。
如果您不需要在短时间内处理请求（也就是说，有时可能会有点迟到），您可以考虑使用现货定价来大幅降低成本，由于现货价格高，偶尔可能无法运行。 （或者，只是高价并接受偶尔你支付的价格超过按需价格，但一般来说你会节省可观的费用。）
在控制台中手动创建以上所有内容，然后尝试和测量结果。完成后，您可以根据需要将其实施为 CloudFormation堆栈。
<强>更新
Auto Scaling屏幕仅根据EC2创建警报。要在其他指标上创建警报，请先创建警报，然后将其放入策略中。
根据Amazon SQS队列添加规则：
ApproximateNumberOfMessagesVisible指标（将在几分钟后显示）在CloudWatch中创建警报