AWS Lambda事件驱动架构最佳实践：多告警处理架构选型咨询

你现在碰到的是Lambda落地非常典型的「单胖函数vs函数爆炸」二选一误区，两个纯极端方案都不符合最佳实践，完全可以取两边的优点规避缺点。

现有通用处理Lambda架构的问题 #

你当初为了避免重复建函数选的单通用函数方案，思路方向没错，但属于典型的Lambda反模式，除了你已经发现的日志混杂排查难的问题，还有几个硬伤：

• 故障爆炸半径过大：单个告警的逻辑bug、依赖冲突、超时/内存配置不合理，会直接影响所有告警的处理，极端情况下某段逻辑的死循环甚至会打满账号的Lambda并发配额，导致全量告警失效
• 权限违反最小原则：通用Lambda必须持有所有20个告警对接第三方服务的全部IAM权限，一旦某段逻辑出现注入类漏洞，攻击者可以通过这个函数触达所有关联服务，安全风险极高
• 可观测性缺失：CloudWatch的调用次数、错误率、延迟等默认指标都是按函数维度统计的，你要单独看某一个告警的运行数据，必须自己埋点加自定义指标，额外增加工作量；排查问题时要在混杂的日志里靠关键词过滤，很容易漏掉关键报错
• 资源配置无法差异化：不同告警的API调用链路长度、内存需求、超时阈值、触发频率都不一样，通用函数只能取一个兼容所有场景的配置，要么给低需求告警配太高的内存浪费钱，要么给高需求告警配的资源不够跑失败
• 冷启动性能差：通用函数打包了所有告警的处理逻辑，部署包体积远大于单逻辑函数，冷启动延迟会明显升高，对告警这类对时效敏感的场景影响很大

纯一告警一Lambda方案的问题 #

你担心的CDK结构冗余是真实存在的痛点：如果硬写20遍重复的Lambda定义代码，后续改个通用runtime版本、加个公共环境变量都要改20次，维护成本极高，完全是用人力成本换架构收益，得不偿失。

推荐的折中落地方案 #

核心原则是代码集中复用，资源独立部署，不要把「独立部署Lambda」和「代码冗余」划等号，具体落地只需要做3件事：

• 抽离公共依赖：把你已经封装好的通用API调用逻辑、工具方法统一打包成Lambda Layer，所有告警处理函数共用这个层，不用每个函数重复打包公共代码
• CDK侧批量生成资源：不要手写20个函数定义，维护一份集中的告警配置清单，通过循环批量生成所有告警对应的Lambda、IAM权限、SNS订阅，示例代码如下：

// 集中维护所有告警的配置，新增/修改告警只需要改这一个清单
const ALARM_CONFIGS = [
  {
    name: 'payment-failed-alarm',
    memory: 128,
    timeoutSec: 3,
    handlerPath: 'handlers/paymentFailed.main',
    iamActions: ['thirdparty:SendAlert']
  },
  {
    name: 'disk-usage-alarm',
    memory: 256,
    timeoutSec: 5,
    handlerPath: 'handlers/diskUsage.main',
    iamActions: ['thirdparty:SendMetricAlert', 'ops:CreateTicket']
  }
  // 其余告警按相同格式补充即可
]

// 循环批量生成所有资源，无重复代码
ALARM_CONFIGS.forEach(conf => {
  const processor = new Function(this, `alarm-${conf.name}`, {
    runtime: Runtime.NODEJS_18_X,
    code: Code.fromAsset('src/alarm-processors'), // 所有告警处理逻辑存放在同一个代码目录
    handler: conf.handlerPath,
    memorySize: conf.memory,
    timeout: Duration.seconds(conf.timeoutSec),
    layers: [commonApiLayer] // 引用封装了公共API调用的公共层
  })
  // 单独给每个函数绑定最小必要权限
  processor.addToRolePolicy(new PolicyStatement({
    actions: conf.iamActions,
    resources: ['*']
  }))
  // 给SNS加对应订阅，配合消息过滤自动路由对应告警到专属函数
  alarmSns.addSubscription(new LambdaSubscription(processor, {
    filterPolicy: {
      alarmName: SubscriptionFilter.stringFilter({ allowlist: [conf.name] })
    }
  }))
})

• 调整SNS路由逻辑：原来调度器发SNS消息时，给消息加一个alarmName的消息属性，SNS会通过配置好的过滤策略，自动把不同告警的消息投递给对应的专属处理Lambda，完全不需要你在代码里写告警名称到处理类的映射逻辑。

这套方案可以同时解决两个极端方案的所有痛点：

• 无代码/配置冗余：所有告警配置集中维护，新增告警只需要在配置清单里加一行，自动生成所有对应资源
• 可观测性完全隔离：每个告警对应独立的Lambda日志组、CloudWatch指标，排查问题直接进对应函数查看即可，不需要过滤混杂日志
• 故障半径收敛：单个告警的逻辑错误、配置问题只会影响自身，不会波及其他告警
• 资源配置灵活：可以给每个告警单独适配内存、超时、并发配置，高优先级告警可以单独开预置并发降低冷启动，低频告警用默认配置即可，成本最优
• 权限合规：每个函数只持有自己需要的最小权限，没有过度授权的安全风险

如果后续单个告警的API调用链路变长、需要复杂的失败重试、分支判断逻辑，可以再把对应告警的处理逻辑换成Step Functions编排，现阶段逻辑不复杂的话用Lambda就足够。

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