我正在尝试设置一个EC2 Scaling组，该组可根据SQS队列中的项目数进行扩展。
当SQS队列中有项可见时，我需要Scaling组有1个实例可用，当SQS队列为空时（例如没有可见或不可见的消息）我希望有0个实例。
所需实例设置为0，min设置为0，max设置为1。
我在SQS队列上设置了cloudwatch警报，以便在可见消息大于零时触发，并在不可见消息小于1时触发警报（即不再需要做的工作）。
目前，Cloudwatch警报触发器用于创建实例，但随后缩放组会自动杀死实例以满足所需的设置。我预计警报会在最小和最大设置内调整所需的实例数，但事实并非如此。
答案 0 :(得分：8)
是的，你当然可以拥有一个Auto Scaling组：
ApproximateNumberOfMessagesVisible＆gt; 0表示1分钟，添加1个实例当队列中有消息等待时，这将导致Auto Scaling启动实例。它将继续尝试启动更多实例，但最大设置会将其限制为1个实例。
没有消息时的缩放是有点小问题。
首先，当缩小时，实际上很难知道。如果有消息等待处理，则ApproximateNumberOfMessagesVisible将大于零。但是，没有消息等待，这并不一定意味着您希望扩展，因为消息可能正在处理（“在飞行中”），如ApproximateNumberOfMessagesNotVisible所示。所以，如果这两个都为零，你只想要缩小。遗憾的是，CloudWatch警报只能引用一个指标，而不是两个指标。
其次，当Amazon SQS队列为空时，它不会向Amazon CloudWatch发送指标。这种情况很有意义，因为队列大多是空的，所以它会不断发送零度量。但是，它会导致CloudWatch在队列为空时未收到指标的问题。相反，警报将进入INSUFFICIENT_DATA状态。
因此，您可以将警报创建为：
ApproximateNumberOfMessagesVisible = 0持续15分钟时，删除1个实例，但将操作设置为在INSUFFICIENT_DATA上触发，而不是ALARM 请注意建议的“15分钟”延迟，以避免颠簸实例。这是快速连续添加和删除实例的地方，因为消息是定期进入的，但不经常发生。因此，最好在决定放大之前等待一段时间。 （毕竟，Amazon EC2实例每小时收费，因此通常不会产生额外费用。）
这会留下在处理消息时终止实例的问题。这可以通过利用Auto Scaling Lifecycle Hooks来避免，{{3}}在实例即将终止时发送信号，使应用程序有机会延迟终止直到工作完成。然后，只有在消息处理完成后，您的应用程序才会发出信号表明它已准备好终止。
底线
以上大部分内容取决于：
如果您的消息不经常且易于处理，则可能值得继续运行t2.micro实例。以2c /小时，扩展的好处很小。此外，在添加和删除实际支付的实例时总是存在风险*更多**，因为实例按小时收费 - 运行实例30分钟，终止实例，然后启动另一个实例30分钟实际上收费两个小时。
最后，您可以考虑使用 AWS Lambda 而不是Amazon EC2实例。 Lambda非常适合短期代码执行而无需服务器。虽然它不能由SQS队列中的消息触发，但它可以通过您将消息发送到队列的任何进程触发 - 通过直接调用Lambda，或者将消息发送到Amazon SNS主题，该主题位于转身可以打电话给Lambda。
答案 1 :(得分：0)
对于简单的 conf，每秒 aws ami/ubuntu 计费不用担心浪费启动/关闭时间，只需自己终止 ec2，没有任何 asg 关闭策略在客户端启动代码中添加一点 bash 或预安装它处理完成后，cron 和轮询进程存在或 cpu 负载和术语 ec2 或关闭（如果您附加卷并需要它们自动销毁，则终止会更好）。关于 asg 定义为 0/0/1 (min/desired/max) 的一个恼人的事情是在 sqs 上定义为 0/0/1 (min/desired/max) 和 ApproximateNumberOfMessagesNotVisible - 在 ec2 以某种方式被触发后它切换到 1/0/1 并且它开始循环触发 ec2 即使有没有什么是 sqs（我正在做视频转码，排队工作要对 sns/sqs 做，并用在非空 sqs 上定义的 asg 触发 ffmpeg 节点）