将大量容器部署到 AWS 的最佳、简单方法是什么？如果容器用处不大或根本没有用处，那么就必须具有可扩展性，但成本要低廉。
我有一种方法可以生成提供数据的 docker 容器（使用 fastAPI）。每个容器都运行一些基本的 numpy/ML，但不会太复杂。更重要的是，它们可能连续几天都不会收到任何请求，我们需要能够以最低的成本部署大量此类容器，而不必担心为它们维护整个 EC2 实例。
感谢任何对 docker 和 AWS 有意见的人。以下是我对解决方案的理解（以及为什么我对它们不满意）：
- Elastic Beanstalk
这意味着将您的容器上传到 ECR，然后在 EB 上设置带有端点的负载均衡器环境。这是我目前使用的解决方案，它的端点是一个公共 URL，这很不方便，但我已经经历了将其放到我的虚拟云上的挑战。不过，我怀疑虽然它可以根据需要进行扩展，但它始终会保持每个容器至少运行一个 EC2 实例，这意味着您要支付实际需要的 1000 倍的成本，来维护一个闲置的 EC2 实例。
- EC2 实例
我可以部署一个 EC2 实例并在其中运行我的容器。但是从负载（一个实例可以容纳多少个容器？）和端点（我必须跟踪名称并为每个容器分配自己的端口）来看，这似乎非常手动，这看起来很混乱且容易出错。
- Lambda 函数已上传为 Docker 容器
这意味着要修改 docker 容器以实现 lambda_function 方法作为其 api，然后将其部署为 lambda 函数。这似乎是以零使用意味着零成本（或最低成本）的方式维护容器的唯一方法，只需在请求进入时付费。但是，这意味着要修改此用例的容器并设置一堆额外的管道；我必须以某种方式将典型的 lambda 函数 dockerfile 与我当前基于 web-api 的 dockerfile 融合，并研究如何将 API 网关请求转换为 docker-lambda 调用。
- Lambda 函数，不再使用 docker
现在我已经完全解构了 docker 容器，但如果您需要全天候访问但又不想让它们保持运行，那么使用 docker 可能就不合适了？
结论
所以基本上我怀疑我需要将我的容器转变为 lambda 函数，这是可行的，但却违背了让我们的承包商使用 docker 的目的（我现在正在以适合我的目标环境的方式修改构建过程，这正是 docker 应该防止的事情！）