如何在CDK中处理SSM Parameter Store可选参数

你遇到的部署失败是因为ssm.StringParameter.fromStringParameterAttributes方法会在CloudFormation模板中生成硬引用，CloudFormation在构建变更集阶段就会校验这些SSM参数是否存在，不存在直接抛出校验错误，且因为CDK的stringValue返回的是Token，合成阶段无法拿到实际值做存在性判断。以下是三种可落地的处理方案：

方案1：Lambda运行时主动拉取SSM参数（推荐） #

这是最适配需求的方案，无需在CDK层面处理复杂的条件逻辑，还天然适配内置默认值的设计：

• 移除CDK中SSM参数的硬引用，不需要在栈定义时提前拉取参数
• 在Lambda代码中调用SSM的GetParameter接口，捕获参数不存在的异常，直接使用应用内置默认值即可

示例Node.js Lambda代码片段：

const { SSMClient, GetParameterCommand } = require("@aws-sdk/client-ssm");
const ssmClient = new SSMClient();

async function getSsmParamOrDefault(paramName, defaultValue) {
  try {
    const res = await ssmClient.send(new GetParameterCommand({
      Name: paramName,
      WithDecryption: true // 非加密参数可移除该配置
    }));
    return res.Parameter.Value;
  } catch (e) {
    if (e.name === "ParameterNotFound") return defaultValue;
    throw e;
  }
}

// 调用示例
const PARAM_ONE = await getSsmParamOrDefault("/myapp/param1", "内置默认值1");

优势：

• 不需要修改CDK部署逻辑，实现简单
• 支持参数热更新，修改SSM参数不需要重新部署Lambda
• 完全规避部署阶段的参数存在性校验问题

方案2：使用自定义资源在部署阶段查询参数 #

如果确实需要将参数作为环境变量在部署时注入Lambda，可以通过自定义资源实现：

1. 编写一个简单的Lambda作为自定义资源的处理函数，功能是接收SSM参数名，返回参数值或者空值（如果不存在）
2. 在栈定义中为每个可选SSM参数创建自定义资源实例
3. 将自定义资源的输出作为环境变量传入业务Lambda

优势：可以在部署阶段完成参数注入，不需要修改业务Lambda的参数读取逻辑
劣势：需要额外维护自定义资源的逻辑，部署链路变长

方案3：CDK合成阶段预查SSM参数 #

如果你的部署流程允许在CDK合成时调用AWS API，可以在合成阶段直接调用SSM SDK查询参数是否存在，存在就添加对应环境变量，不存在就跳过：

// CDK代码示例，需要先安装aws-sdk
import { SSM } from 'aws-sdk';
const ssm = new SSM({ region: process.env.CDK_DEFAULT_REGION });

async function createStack() {
  const app = new cdk.App();
  const stack = new cdk.Stack(app, 'MyAppStack');

  const environment: Record<string, string> = {};
  try {
    const p1 = await ssm.getParameter({ Name: '/myapp/param1' }).promise();
    environment.PARAM_ONE = p1.Parameter!.Value!;
  } catch (e) {
    // 参数不存在就跳过，不添加该环境变量
  }

  new lambda.Function(stack, 'MyLambda', {
    // 其余Lambda配置
    environment
  });
}

优势：实现简单，不需要额外运行时逻辑
劣势：CDK合成时需要有AWS账号访问权限，且参数存在性是合成时的静态状态，部署时参数被删除仍会导致部署失败

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