AWS 容器 (ECS) 与 AMI 和 Spot 实例

Question

我的问题的核心是使用 Amazon Machine Image + Micro Spot 实例来运行任务与使用 Elastic Container Service (ECS) 相比是否存在缺点。

这是我的情况：我需要按需运行由远程 Web 挂钩触发的任务。

这个任务有可能被连续触发 10 次，或者连续几周不执行，所以我绝对想要一个只按需运行（和计费）的服务。

我的计划是将 webhook 指向 Lambda 函数，但问题是让 Lambda 函数做什么。

虽然不需要很长时间，但这项任务需要几个不同的运行时（Powershell Core、Python、PHP、Git）来完成它的工作，所以 Lambda 并不是真正的可能性，因为我已经达到了部署包大小限制。 但是我可以使用 Lambda 来开始这项工作。

我开始做的是创建一个具有所有必要运行时和代码的 AMI，然后使用 Spot 请求启动一个实例，让它通过通过 userdata 传入的启动脚本执行操作，然后在完成后自行关闭。 我必须加入一些速率控制逻辑来防止两个同时运行，但这是一个可以解决的问题。

当我意识到我可能可以使用 Fargate 在 ECS 上使用 docker 容器来实现这一点时，我在开发这个解决方案的过程中犹豫了。

我只是不知道当我不是 docker pro 并且已经配置了 AMI 时，将额外的开发时间切换到 docker 容器是否有任何好处。 加上 ECS/Fargate 实际上比仅仅运行一个微实例更昂贵。

是否有任何关于在一天之内发出一打的短时（<5 分钟）现场请求（t3a-micro）的担忧？ 这有速率限制吗？ 我会收到来自 AWS 的一封愤怒的电子邮件，让我取消它吗？ 是否还有其他原因 ECS 是唯一正确的答案？ 完全是别的什么？

Answer 1

您使用 Spot 实例和 AMI 的解决方案是一个有效的解决方案，尽管我过去曾经历过获取 Spot 实例的缓慢时间。 您还会产生 AMI 启动时间。

如评论中所述，您将为此实例至少支付 1 小时的费用，因此您应在终止前将您的实例保持一小时运行，以防在同一小时内出现更多请求。

恕我直言，你应该用 lambda 来构建它。 通过将每个运行时的工作负载拆分为它自己的 lambda，您可以使其工作。

AWS 支持 python、powershell 运行时，您可以创建一个自定义的 PHP运行时。 将它们与您选择的粘合剂、SNS、SQS、直接调用或 Step Functions 链接在一起，您将拥有最具成本效益的解决方案。 您还可以获得对每个功能/运行时更好和独立维护的好处。

将初始 lambda 置于 API 网关之后，您也将获得速率限制功能。