Lambda NodeJS 14停服后AWS Serverless v1架构运维与升级疑问

背景概述 #

我有多个基于AWS的项目，采用以下架构：Cognito（用户池）、S3（前端存储）、Cloudfront（CDN代理）、API Gateway（REST API）、Lambda NodeJS 14（后端逻辑）、DATA API（通过data-api-client NPM包执行数据库查询）、Aurora MySQL（兼容MySQL 5.7.2.08.3）- Serverless v1（数据库）。这些项目多用于开发或内部用途，使用率极低，借助Serverless v1数据库可在闲置时设置为0 ACU，每月仅需支付约1-2美元。现获悉NodeJS 14将于2023年11月停止服务，针对此情况的疑问及解答如下：

1. 进入第二阶段停服期后，是否仍可继续按现状使用现有系统？ #

• 可以继续运行，但无任何官方支持。AWS停止服务后，Node.js 14的Lambda不会再收到安全补丁、bug修复，一旦出现安全漏洞或运行故障，无法获得AWS技术支持，存在数据泄露或服务中断风险。

2. 若在第二阶段停服期后新建同类系统，是否有办法创建已停服的Lambda NodeJS版本？比如使用CLI v2？ #

• 无法实现。AWS会全面下线已停服的运行时版本的创建通道，无论是控制台还是CLI（包括v2）都无法创建Node.js 14的Lambda函数。即便通过自定义运行时打包Node.js 14部署，也得不到官方支持，风险极高。

3. 若升级至NodeJS 18，是否必须使用Serverless v2？此时DATA API不再受支持，是否需改用RDS Proxy？ #

• 升级Node.js 18不强制要求使用Aurora Serverless v2，但data-api-client可能存在Node.js 18兼容性问题，且Aurora Serverless v1已进入维护模式，官方不再新增功能支持。若继续使用Serverless v1，可能遭遇运行时兼容故障；若切换到Serverless v2，确实无法再使用DATA API，需改用RDS Proxy直接连接数据库，或使用常规MySQL驱动建立连接。

4. 由于Serverless v2最低仅能设置为0.5 ACU，单数据库每月最低成本约40美元，6个数据库则需240美元，相比Serverless v1的2美元成本大幅上升，是否有更优的成本优化方案？ #

• 有几种低成本替代方案：
  • 合并多项目数据库：将多个低使用率项目的数据库合并到同一个Aurora Serverless v2实例，共享0.5 ACU基础资源，大幅降低整体成本。
  • 利用RDS免费套餐：符合条件的话，可使用RDS免费套餐（micro实例），每月成本极低，能满足低使用率场景需求。
  • 定时启停常规RDS实例：通过CloudWatch Events或Lambda定时启停RDS实例，仅在需要使用时启动，闲置时关闭，大幅减少闲置时段的成本。
  • 延续Serverless v1配合Lambda升级：Aurora Serverless v1仍可继续使用，升级Lambda到Node.js 18（需确认data-api-client兼容性，或替换为兼容的数据库客户端），保留0 ACU的低成本优势。

5. 切换至DynamoDB是否为更经济的选择？但此举需要修改数据库、Lambda函数及所有相关查询。 #

• 对于低使用率的内部/开发项目，DynamoDB的按需付费模式确实更经济——闲置时几乎无成本，仅在有请求时按读写容量计费。但需承担以下代价：
  • 重构数据库结构：从关系型MySQL转为NoSQL的DynamoDB，需重新设计数据模型。
  • 修改Lambda查询逻辑：替换data-api-client为DynamoDB SDK（如@aws-sdk/client-dynamodb或@aws-sdk/lib-dynamodb），重写所有数据库操作代码。
  • 学习DynamoDB最佳实践：避免因设计不当导致性能问题或意外成本。
    若项目无大规模扩展需求且重构成本可控，DynamoDB是值得考虑的低成本方案；若重构工作量过大，优先选择合并数据库或定时启停方案更划算。

内容的提问来源于stack exchange，提问作者Taha Erden