将Node.js Lambda函数内联至AWS CloudFormation模板时如何解决本地模块依赖问题

好问题！这种既要把Lambda内联在CloudFormation模板里，又要引入本地依赖、还不能用S3的场景确实挺常见的。我给你几个实用的方案，你可以根据自己的情况选：

方案1：直接把依赖内容硬编码到Lambda代码中 #

这是最简单直接的办法，尤其适合你的依赖是JSON文件的情况。你不需要用require读取文件，而是直接把JSON的内容复制成代码里的变量：

// 原来的代码：
// var dep = require('../config/local_dependencies.json');

// 改成这样：
var dep = {
  "apiKey": "xxx",
  "configValue": "yyy",
  // 把local_dependencies.json里的所有内容都复制过来
};

var other_dep = {
  "setting1": "aaa",
  "setting2": "bbb"
};

exports.handler = async (event) => {
  // 你的业务逻辑
};

优缺点： #

• ✅ 零额外配置，直接在CloudFormation的ZipFile里写就行
• ❌ 如果依赖内容经常变动，维护起来会有点麻烦；如果依赖是复杂的JS模块（不是JSON），这个方法就不适用了

方案2：在Lambda冷启动时动态生成依赖文件 #

Lambda的/tmp目录是可写的，你可以在handler启动的第一步，把依赖内容写入到/tmp对应的目录结构里，然后从/tmp引入依赖。这样能保留原来的依赖引用逻辑（只是路径变了）：

const fs = require('fs');
const path = require('path');

exports.handler = async (event) => {
  // 1. 创建config目录并写入依赖文件
  const configDir = path.join('/tmp', 'config');
  if (!fs.existsSync(configDir)) {
    fs.mkdirSync(configDir, { recursive: true });
  }
  fs.writeFileSync(
    path.join(configDir, 'local_dependencies.json'),
    JSON.stringify({
      "apiKey": "xxx",
      "configValue": "yyy"
    })
  );

  // 2. 创建lib目录并写入另一个依赖文件
  const libDir = path.join('/tmp', 'lib');
  if (!fs.existsSync(libDir)) {
    fs.mkdirSync(libDir, { recursive: true });
  }
  fs.writeFileSync(
    path.join(libDir, 'other_dependencies.json'),
    JSON.stringify({
      "setting1": "aaa",
      "setting2": "bbb"
    })
  );

  // 3. 现在可以正常引入依赖了
  const dep = require('/tmp/config/local_dependencies.json');
  const other_dep = require('/tmp/lib/other_dependencies.json');

  // 你的业务逻辑
  return {
    statusCode: 200,
    body: JSON.stringify({ message: 'Success', dep })
  };
};

优缺点： #

• ✅ 保留了依赖的目录结构，逻辑更清晰；适合依赖内容偶尔变动的场景
• ❌ 每次Lambda冷启动时都会创建文件，会增加一点点冷启动时间（但JSON文件体积小，影响几乎可以忽略）

方案3：用CloudFormation自定义资源自动打包依赖 #

如果你的依赖比较多、或者经常变动，手动复制内容太麻烦，可以用CloudFormation自定义资源来自动化处理：

1. 在模板里内联一个辅助Lambda，它的作用是接收CloudFormation的请求，把主Lambda代码和依赖内容打包成zip，返回Base64编码的zip内容。
2. 主Lambda的Code参数通过Fn::GetAtt获取辅助Lambda返回的打包内容。

示例模板片段：

# 辅助自定义资源Lambda（内联）
DependencyPackager:
  Type: AWS::Lambda::Function
  Properties:
    Runtime: nodejs18.x
    Handler: index.handler
    Role: !GetAtt LambdaExecutionRole.Arn
    Code:
      ZipFile: !Sub |
        const archiver = require('archiver');
        const { promisify } = require('util');
        const stream = require('stream');
        const pipeline = promisify(stream.pipeline);

        exports.handler = async (event) => {
          const response = (status, data) => ({
            Status: status,
            PhysicalResourceId: event.PhysicalResourceId || 'DependencyPackager',
            StackId: event.StackId,
            RequestId: event.RequestId,
            LogicalResourceId: event.LogicalResourceId,
            Data: data
          });

          try {
            // 创建zip归档
            const archive = archiver('zip', { zlib: { level: 9 } });
            const chunks = [];
            archive.on('data', chunk => chunks.push(chunk));
            archive.on('end', () => {});

            // 添加主Lambda代码
            archive.append(event.ResourceProperties.MainCode, { name: 'index.js' });
            // 添加依赖文件
            archive.append(event.ResourceProperties.ConfigDep, { name: 'config/local_dependencies.json' });
            archive.append(event.ResourceProperties.LibDep, { name: 'lib/other_dependencies.json' });
            await archive.finalize();

            // 返回Base64编码的zip内容
            return response('SUCCESS', {
              ZipBase64: Buffer.concat(chunks).toString('base64')
            });
          } catch (err) {
            return response('FAILED', { Error: err.message });
          }
        };

# 主Lambda函数
MyMainLambda:
  Type: AWS::Lambda::Function
  Properties:
    Runtime: nodejs18.x
    Handler: index.handler
    Role: !GetAtt LambdaExecutionRole.Arn
    Code:
      ZipFile: !GetAtt DependencyPackagerOutput.ZipBase64

# 自定义资源，触发辅助Lambda打包
DependencyPackagerOutput:
  Type: Custom::DependencyPackager
  Properties:
    ServiceToken: !GetAtt DependencyPackager.Arn
    MainCode: !Sub |
      var dep = require('../config/local_dependencies.json');
      var other_dep = require('./lib/other_dependencies.json');
      exports.handler = async (event) => {
        // 主Lambda业务逻辑
      };
    ConfigDep: !Sub |
      {
        "apiKey": "xxx",
        "configValue": "yyy"
      }
    LibDep: !Sub |
      {
        "setting1": "aaa",
        "setting2": "bbb"
      }

优缺点： #

• ✅ 自动化处理依赖打包，适合依赖较多或频繁变动的场景
• ❌ 模板结构更复杂，需要额外维护辅助Lambda；第一次部署时需要先创建辅助Lambda的执行角色

总结 #

• 如果依赖是简单JSON且不常变，优先选方案1
• 如果想保留依赖目录结构，选方案2
• 如果依赖多或经常变动，选方案3

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