在AWS API Gateway中跨多个Lambda函数共享配置的最佳实践

我正在AWS部署一个按组划分、包含多个端点的API Gateway。为提升速度、可读性与复用性，按组部署了多个Lambda函数；为保证可移植性，所有资源都通过一个CloudFormation模板定义。当前文件结构如下：

package_name
|
| - group1/
|    |- handler1.py
|        | def function11(event, context):
|               ...
|        | def function12(event, context):
|               ...
| - group2/
|    |- handler2.py
|        | def function21(event, context):
|               ...
|        | def function22(event, context):
|               ...
| - config.py
|      S3_BUCKET_NAME = "my_bucket"
| - template.yaml
       Resources:
         Group1Function:
           Properties:
             CodeUri: group1/
             Handler: handler1.function11
               ...etc...

对应端点：

<url>/group1/function11 
<url>/group1/function12
<url>/group2/function21 
<url>/group2/function22

设计目标是请求不同端点时，仅加载对应组的handler文件。原本计划将公共配置放在config.py中，通过from package_name.config import S3_BUCKET_NAME导入，但CloudFormation仅打包group1/、group2/内的代码，不包含config.py。请问在大量端点与配置的大规模部署场景下，实现跨函数共享配置的最佳方案是什么？

1. Lambda层（大规模场景首选） #

Lambda层可以将共享代码（比如config.py）打包成独立层，多个Lambda函数共享使用，既避免重复打包，又能统一管理配置。

操作步骤： #

• 新建layers/config/目录，将config.py移入该目录，结构如下：

package_name
|
| - group1/
| - group2/
| - layers/
|    |- config/
|       |- python/
|          |- config.py  # 公共配置文件
| - template.yaml

注意：Lambda层的Python代码必须放在python/目录下，这样Lambda运行时才能正确识别导入路径。

• 在CloudFormation模板中定义Lambda层资源，然后让所有需要共享配置的Lambda函数关联该层：

Resources:
  ConfigLayer:
    Type: AWS::Lambda::LayerVersion
    Properties:
      ContentUri: layers/config/
      CompatibleRuntimes:
        - python3.9  # 替换为你的Lambda运行时版本

  Group1Function11:
    Type: AWS::Lambda::Function
    Properties:
      CodeUri: group1/
      Handler: handler1.function11
      Runtime: python3.9
      Layers:
        - !Ref ConfigLayer
      # 其他属性...

  Group1Function12:
    Type: AWS::Lambda::Function
    Properties:
      CodeUri: group1/
      Handler: handler1.function12
      Runtime: python3.9
      Layers:
        - !Ref ConfigLayer
      # 其他属性...

  # group2的函数同理关联ConfigLayer

• 在Lambda函数的handler中直接导入配置：

from config import S3_BUCKET_NAME

优势：

• 统一管理共享配置/代码，更新层即可同步所有关联函数
• 减少每个Lambda包的体积，提升部署速度
• 符合大规模场景下的复用与可维护性需求

2. AWS Systems Manager Parameter Store（适合动态/敏感配置） #

如果配置需要动态调整、包含敏感信息（比如密钥），推荐用SSM Parameter Store存储配置，Lambda函数运行时按需拉取。

操作步骤： #

• 在AWS控制台或通过CLI将配置存入SSM Parameter Store：

aws ssm put-parameter --name "/myapp/config/S3_BUCKET_NAME" --type "String" --value "my_bucket"

• 给Lambda函数添加ssm:GetParameter权限（在CloudFormation的IAM角色中配置）：

LambdaExecutionRole:
  Type: AWS::IAM::Role
  Properties:
    AssumeRolePolicyDocument:
      Version: '2012-10-17'
      Statement:
        - Effect: Allow
          Principal:
            Service: lambda.amazonaws.com
          Action: sts:AssumeRole
    Policies:
      - PolicyName: SSMParameterAccess
        PolicyDocument:
          Version: '2012-10-17'
          Statement:
            - Effect: Allow
              Action: ssm:GetParameter
              Resource: arn:aws:ssm:${AWS::Region}:${AWS::AccountId}:parameter/myapp/config/*

• 在Lambda handler中获取配置：

import boto3

ssm = boto3.client('ssm')

def function11(event, context):
    response = ssm.get_parameter(Name='/myapp/config/S3_BUCKET_NAME', WithDecryption=False)
    s3_bucket = response['Parameter']['Value']
    # 业务逻辑...

优势：

• 配置可动态修改，无需重新部署Lambda函数
• 支持加密存储敏感配置，符合安全合规要求
• 适合大规模场景下多环境（开发/测试/生产）的配置管理

3. 环境变量（适合少量静态配置） #

如果配置项很少且不需要动态调整，可以直接在CloudFormation模板中给Lambda函数设置环境变量。

操作步骤： #

• 在CloudFormation的Lambda资源中定义环境变量：

Group1Function11:
  Type: AWS::Lambda::Function
  Properties:
    CodeUri: group1/
    Handler: handler1.function11
    Runtime: python3.9
    Environment:
      Variables:
        S3_BUCKET_NAME: "my_bucket"
    # 其他属性...

• 在Lambda handler中读取环境变量：

import os

def function11(event, context):
    s3_bucket = os.environ.get('S3_BUCKET_NAME')
    # 业务逻辑...

优势：

• 实现简单，无需额外资源
• 配置与函数绑定，直观易查

劣势：

• 大量配置时会导致模板冗余，维护成本高
• 无法动态修改，修改配置需要重新部署Lambda

4. 调整CloudFormation打包逻辑（不推荐大规模场景） #

如果一定要用本地config.py的方式，可以修改打包逻辑，让CloudFormation将config.py复制到每个函数的目录中，但这种方式会导致代码冗余，不适合大规模场景。

操作步骤： #

• 在部署前通过脚本将config.py复制到group1/、group2/等目录：

cp config.py group1/
cp config.py group2/

• 然后再执行CloudFormation部署命令。

劣势：

• 配置更新时需要重新复制到所有目录，容易出错
• 每个Lambda包都包含重复的配置文件，增加包体积和部署时间

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