构建弹性且可扩展的 AWS Lambda + S3 架构

Source: Dev.to

我曾构建并审查过多个无服务器系统，其中 AWS Lambda 和 Amazon S3 构成了核心——文件摄取管道、媒体处理平台以及事件驱动的 API。随着时间的推移，我注意到一个反复出现的挑战：人们要么把 Lambda + S3 看得过于简单（“只在上传时触发函数”），要么在图示过于复杂时感到抽象。

在本文中，我将带你了解我在设计既复杂又易于理解的 Lambda + S3 架构时的思路，结合真实案例和最新的 AWS 能力。我还会展示我如何在 Lucidchart 中绘制该架构，以便能够清晰、广泛地进行解释。

我想要解决的问题

在设计无服务器系统时，我通常希望实现三件事：

• 为用户和客户端提供简洁的入口点
• 在后台实现异步、弹性的处理
• 随着系统规模扩大，保持对成本和运营的强控制

我不把注意力放在单个 AWS 服务上，而是将架构划分为层级。这种思维模型也非常适合在 Lucidchart 中绘图。

Edge / 客户端层

请求的来源所在：

• Web 或移动客户端
• CLI 工具或第三方 webhook

大多数情况下，客户端并不会直接与 Lambda 通信。我倾向于保持一个干净的边界。

API 与入口层

这里我通常使用：

• API Gateway 用于 REST 或 HTTP API
• Lambda Function URLs 用于非常聚焦的内部端点
• CloudFront + WAF 当 API 面向公众且需要防护时

该层仅负责身份验证、校验和路由——不承担繁重的业务逻辑。

计算层（Lambda）

Lambda 在此发挥光彩。我通常将职责拆分到多个函数中：

• Request Lambdas – 快速、同步（身份验证、预签名 URL）
• Processor Lambdas – 异步工作者（图片压缩、元数据提取）
• Indexer Lambdas – 背景任务（搜索索引、向量嵌入）

存储与数据平面（以 S3 为中心）

这是一套系统的核心。我通常使用多个 bucket，每个 bucket 都有明确的用途：

• ingest-bucket – 原始上传
• processed-bucket – 派生产物
• archive-bucket – 长期保存

我常用的关键 S3 功能：

• 使用预签名 URL 直接上传（客户端绕过 Lambda）
• S3 Intelligent‑Tiering 自动控制成本
• S3 Object Lambda 实时转换
• S3 Batch Operations + Lambda 用于大规模重新处理作业

下面是上述结构的基础设施图：

最后思考

Lambda 和 S3 往往被介绍为简单的服务，但二者结合可以驱动极其复杂的系统。关键在于：

• 保持同步路径简短
• 将其他所有工作推向事件驱动
• 让 S3 发挥其最擅长的：弹性扩展与低成本存储