经过一番搜索，我发现有两种公认的方式来管理 AS API 或 AS 的一般工作：
一种方法是直接从 worker 内部操纵服务器的健康状况。这是相当多的站点所做的并且它是有效的，当您的工作人员检测到系统中没有更多的工作或冗余时，它会将其所在的服务器标记为不健康。这样，AS API 就会出现并在一段时间后自动将其删除。
因此，使用这种方法，您将在一段时间内根据您的 SQS 队列大小制定扩展策略（例如，每 5 分钟 SQS 消息超过 100 个添加 2 个服务器；每 10 分钟 SQS 消息超过 500 个双倍网络容量50%）。缩减将由代码而不是活动策略来处理。
此方法也适用于零集群，因此您可以在不使用集群时将集群一直关闭到没有服务器，使其非常具有成本效益。
好处：
- 易于设置
- 使用 AWS API 函数
- 可能是最快的设置
- 使用 AWS 托管 API 为您管理集群大小
缺点：
- 不使用完整的 AWS API 很难管理，即在创建新服务器时，如果不执行所有 instanceid 的完整 API 命令返回，您将无法取回它的 instanceid。在其他情况下，如果您想要对集群进行自我控制，AWS AS API 会妨碍您并让生活变得更加艰难
- 依靠亚马逊知道什么最适合您的钱包。您依靠 Amazon API 来正确扩展，这对许多人来说是一个优势，但对某些人来说是个劣势。
- worker 必须容纳一些服务器池代码，这意味着 worker 不是通用的，不能在不更改配置的情况下立即移动到另一个集群。
考虑到这一点，还有第二种选择，DIY。您使用 EC2 Spot Instance 和 on Demand Instance API 根据您的自定义规则创建自己的 AS API。这很容易解释：
- 你有一个 cli 脚本，当运行开始时，比如 10 个服务器
- 您有一个 cronjob，当检测到满足某些条件时，服务器会停机或更多
好处：
- 轻松干净地管理您的终端
- 可以做普通工人
- 服务器池可以开始管理多个集群
- 您可以制定规则以及从 AWS 上的指标获取数据并使用它们进行比较和时间范围来了解事情是否应该改变的事情并不十分复杂。
缺点：
- 很难获得多区域（对 SQS 来说还不错，因为 SQS 是单区域）
- 难以处理区域容量和工作量的错误
- 您必须依靠自己的服务器正常运行时间和自己的代码来确保 cronjob 正常运行，并按应有的方式配置服务器，并在应该的时候将它们分解。
因此，对于最终用户来说，这似乎是一场更舒适的战斗。我个人仍在考虑这两者，并创建了一个小型自托管服务器池，它可以为我工作，但同时我很想尝试让它在 AWS 自己的 API 上工作。
希望这对人们有所帮助，
编辑：请注意，使用这两种方法中的任何一种，您仍然需要一个函数来预测您应该如何出价，因此您需要在您的现货类型（EC2 类型）上调用出价历史 API 并计算出价方式。
另一个编辑：在系统中自动检测冗余的另一种方法是检查 SQS 队列的空响应指标。这是您的工作人员 ping 队列但未收到响应的次数。如果您在工作期间在应用程序中使用排他锁，这将非常有效。