如何用AWS CDK部署CDK目录外的Lambda函数及架构疑问

1. 在现有项目内创建CDK目录是否可行？ #

完全可行，这是渐进式迁移现有Node.js项目到AWS云的常用实践。这种方式无需拆分原有代码仓库，能保持业务代码与基础设施即代码（IaC）的统一管理，尤其适合从传统Express架构逐步过渡到Serverless或混合云架构的场景，团队无需切换多个代码库，降低了迁移和维护成本。

2. 修改projectRoot指向父目录来部署CDK外的Lambda是否可取？ #

这种方式能临时解决路径问题，但长期来看并不推荐，存在以下潜在问题：

• 部署包体积冗余：CDK会将父目录下的所有文件纳入打包范围，可能包含测试文件、前端静态资源、日志等无关内容，增大Lambda部署包体积，影响冷启动性能。
• 依赖冲突风险：根目录的package.json依赖版本可能与CDK目录的依赖不一致，打包或部署时容易出现依赖版本冲突，导致运行时错误。
• 安全隐患：可能意外将根目录下的敏感配置文件（如.env、密钥文件）打包进Lambda部署包，引发数据泄露风险。

3. 有没有更优方法部署CDK目录外的Lambda，保持CDK目录仅用于资源编排？ #

推荐以下几种更规范的方案：

• 精准指定Lambda代码路径：在CDK代码中使用lambda.AssetCode.fromAsset()方法，通过相对路径（相对于CDK目录）指向src下的Lambda代码目录。例如：

  import * as lambda from 'aws-cdk-lib/aws-lambda';
  import * as path from 'path';
  
  const myLambda = new lambda.Function(this, 'MyLambda', {
    runtime: lambda.Runtime.NODEJS_20_X,
    handler: 'index.handler',
    code: lambda.AssetCode.fromAsset(path.join(__dirname, '../src/lambda')),
  });
  

  这种方式仅打包指定目录的内容，避免冗余，同时保持CDK目录的独立性。
• 独立管理Lambda依赖：在src下的Lambda子目录中单独创建package.json，只声明该Lambda运行所需的依赖。CDK打包时会自动处理该子目录的依赖安装，不会受根目录依赖的影响，确保Lambda运行环境的纯净。
• 使用Lambda层共享业务代码：如果多个Lambda需要复用业务控制器代码，可将这些公共逻辑打包成Lambda层。在CDK中定义层资源，然后让各个Lambda引用该层，这样每个Lambda仅需包含入口代码，业务逻辑统一放在层中，既简化了CDK的资源定义，也提升了代码复用率。
• 预打包Lambda代码：在执行cdk deploy前，通过脚本（如npm脚本）将src中的Lambda代码预打包成zip文件，排除冗余文件并完成编译（如TypeScript转JS）。然后在CDK中通过lambda.AssetCode.fromAsset()指向该zip文件，精准控制打包内容，提升部署效率。

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