多客户端API Gateway场景下如何复用AWS Lambda对接不同Aurora RDS

这套改造不需要重写你已有的业务SQL，核心就是把原来硬编码在Lambda里的单数据库连接串完全剥离，通过API Gateway的配置给每个客户的调用打上专属标识，Lambda根据标识动态匹配对应客户的数据库连接——因为所有客户的库表结构完全一致，原有业务逻辑不需要做任何改动。

第一步：打通API Gateway到Lambda的无侵入标识透传 #

不要靠前端请求传客户身份，避免被篡改带来串库风险，所有标识直接在每个客户专属的API Gateway的Lambda集成层配置：

• 针对每个客户的API Gateway，在和目标Lambda的集成请求映射中，新增一个固定参数x_customer_db_config，值为该客户对应的数据库配置唯一标识（比如prod_aurora_cust_001、prod_aurora_cust_002）
• 这个参数完全由后端控制台配置，客户的前端应用无法修改、伪造，从根源上避免越权访问其他客户数据库的问题
• 映射配置示例（API Gateway集成请求映射规则）：

  {
    "x_customer_db_config": "$util.escapeJavaScript('prod_aurora_cust_001')"
  }
  

• 配置完成后，Lambda收到的event对象里会自动带上这个参数，不需要前端做任何改动。

第二步：用托管配置存储替代代码硬编码连接串 #

不要把所有客户的数据库连接串写死在Lambda代码里，推荐把所有客户的数据库连接串加密存在AWS Secrets Manager里：

• 每个客户的数据库连接串对应一个独立的Secret条目，Secret名称和第一步配置的x_customer_db_config值完全对齐（比如名称就是prod_aurora_cust_001）
• 给Lambda的执行服务角色配置最小权限：只允许读取这几个关联客户的Secret内容，不开放全账户的Secret访问权限，避免安全风险
• Lambda内部加一层全局缓存，第一次收到对应客户的请求时，拉取一次Secret的连接串值存在内存里，后续同客户的热调用直接用缓存，不需要每次都请求Secrets Manager，避免增加额外延迟。

第三步：改造原有代码的连接逻辑，适配多客户场景 #

把原来每次调用新建单连接、用完直接销毁的逻辑，替换成按客户标识缓存连接池的模式，既保证复用性，又避免频繁建连带来的性能损耗，核心改造点：

1. 删除代码里硬编码的单条连接串
2. 从event中读取传入的客户配置标识
3. 按标识查连接池缓存，不存在就拉取对应连接串新建连接池
4. 复用原有SQL查询逻辑，从连接池拿连接执行查询，用完把连接放回池内，不要直接断开

改造后的核心代码参考：

const { SecretsManagerClient, GetSecretValueCommand } = require("@aws-sdk/client-secrets-manager");
const pg = require("pg");

// 全局缓存：按客户key存连接池，避免重复建连
const connPoolCache = {};
const secretsClient = new SecretsManagerClient({ region: "你的AWS服务区域" });

exports.handler = async function(event, context) {
    // 从API Gateway传入的参数获取当前客户的配置标识
    const customerConfigKey = event.x_customer_db_config;
    if (!customerConfigKey) {
        throw new Error("缺少客户数据库配置标识，请求中断");
    }

    // 检查缓存中是否已有当前客户的连接池
    let currentPool = connPoolCache[customerConfigKey];
    if (!currentPool) {
        // 无缓存则从Secrets Manager拉取对应客户的连接串
        const secretContent = await secretsClient.send(
            new GetSecretValueCommand({ SecretId: customerConfigKey })
        );
        const dbConnString = JSON.parse(secretContent.SecretString).connection_string;
        // 初始化当前客户的连接池，根据Aurora的最大连接数调整单池上限
        currentPool = new pg.Pool({
            connectionString: dbConnString,
            max: 5,
            idleTimeoutMillis: 30000 // 空闲30秒自动回收闲置连接，避免占满Aurora连接配额
        });
        connPoolCache[customerConfigKey] = currentPool;
    }

    // 从连接池获取连接执行原有业务SQL，和你之前的输出格式完全一致
    // 原来用query.on("row")监听结果的高并发风险问题，这里换成async/await的方式直接拿结果，不需要改前端的接收逻辑
    const client = await currentPool.connect();
    try {
        const queryResult = await client.query(`-- 替换为你原有业务SQL即可`);
        return queryResult.rows;
    } finally {
        // 将连接放回连接池，不要直接关闭
        client.release();
    }
};

生产环境适配的避坑要点 #

• 连接数控制：给这个公共Lambda设置合理的预留并发数，结合每个客户连接池的最大连接数，整体匹配Aurora的最大连接配额，避免突发流量打满数据库连接
• 配置刷新：给内存缓存加一个10分钟左右的过期时间，客户数据库密码轮转、连接地址变更时，不需要重新部署Lambda，只要更新Secrets Manager的内容，缓存过期后自动拉取新配置
• 版本统一：后续业务逻辑更新时，只需要部署一次这个公共Lambda，所有关联客户的API Gateway会自动加载新版本，不需要给每个客户重复部署单独的Lambda
• 日志隔离：在日志里加上customerConfigKey字段，排查问题时可以快速定位是哪个客户的请求出了问题，不会混在同一份日志里找不到边界。

内容的提问来源于stack exchange，提问作者Nooh Ahamad