我有一个包含 3 个模块和 25 个端点（模块之间）的应用程序。模块：用户、CRM、PQR。
我想优化 AWS 成本并普遍尊重架构最佳实践。
【问题讨论】：
标签： amazon-web-services aws-lambda
这取决于您的架构以及您希望它的解耦程度。以下是您了解最佳实践的良好起点：
https://aws.amazon.com/blogs/compute/best-practices-for-organizing-larger-serverless-applications/
【讨论】：
Gustavos' answer 中的链接提供了一个不错的起点。我将根据您在 cmets 中提到的标准详细说明。
您提到要针对成本和架构最佳实践进行优化，让我们从成本部分开始。 Lambda 定价相当简单，您可以在pricing page 上查看。基本上，您需要为代码以 1MS 的增量运行多长时间付费。每毫秒的成本取决于您为 Lambda 函数预置的资源数量。 Lambda 通常不是您帐单上最昂贵的项目，因此一旦出现问题，我就会开始对其进行优化。
从定价的角度来看，Lambda 函数是多还是少并不重要。
在架构最佳实践方面，没有单一的万能参考架构，但 Gustavo 提到的帖子是一个很好的起点：Best practices for organizing larger serverless applications。您如何构建应用程序可能取决于许多因素：
您提到了三个主要组件/模块，总共有 25 个端点：
由于您没有告诉我们太多有关技术堆栈的信息，因此我假设您正在尝试构建一个 REST API，作为某些前端应用程序的后端。
在这种情况下，您可以将这三个模块视为三个微服务，它们为应用程序实现特定功能。它们中的每一个都实现了一些端点（HTTP 方法和路径的组合）。如果您从 API 网关开始作为架构的入口点，则可以将其用作客户端内部架构的抽象。
API Gateway 可以根据 HTTP 方法和路径将请求路由到不同的 Lambda 函数。您现在可以选择如何实现后端。我可能会从构建多个 Lambda 的通用代码库开始，并使用 API 网关将每个端点映射到 Lambda 函数。您还可以从更大的多用途 Lambda 开始，及时重构它们以提取特定端点，然后使用 API 网关路由到更专业的 Lambda。
您可能已经注意到，这有点含糊，这是故意的。我认为您最终会得到与端点数量大致相同的 Lambda，但这并不意味着您必须以这种方式开始。如果您刚刚开始使用 AWS，管理一堆 Lambda 并在那里进行交互可能会让人望而生畏。从更熟悉的架构开始，然后随着时间的推移将它们重构为更加云原生。
【讨论】：