多GitLab仓库的AWS SAM模板如何正确引用跨仓共享资源

首先明确架构合理性：单仓库仅部署一个Lambda从来不是SAM或AWS的最佳实践要求你当前单仓库管理多Lambda（按独立文件夹存放代码）、单仓库配独立CI流水线跑sam build/sam package/sam deploy的模式是完全成熟的生产级用法，不需要为了共享资源调整现有仓库拆分逻辑。

你之前考虑的嵌套栈、跨仓库共享CDK文件两类方案都不匹配当前独立仓库独立部署的场景，落地成本和后续维护成本极高，最适配你场景的方案是用SSM Parameter Store做资源发现，完全不需要硬编码ARN，也不需要打通跨仓库的代码或流水线依赖。

推荐方案：SSM参数存储共享资源ARN #

落地步骤不需要改动现有CI核心逻辑，只需要调整两边的SAM模板：

• 第一步：在创建共享数据库的仓库模板中，创建完数据库资源后，把资源ARN写入SSM参数，同时给其他仓库的部署角色配置对应参数路径的ssm:GetParameter读权限即可，模板片段示例：

# 共享数据库所在仓库 template.yml 片段
Resources:
  SharedBusinessDB:
    Type: AWS::DynamoDB::Table # 换成你实际的数据库类型，Aurora/RDS/Redshift逻辑一致
    Properties:
      TableName: shared-order-table
      AttributeDefinitions:
        - AttributeName: order_id
          AttributeType: S
      KeySchema:
        - AttributeName: order_id
          KeyType: HASH
      BillingMode: PAY_PER_REQUEST

  SharedDbArnParam:
    Type: AWS::SSM::Parameter
    Properties:
      Name: /shared/prod/database/order-db-arn
      Type: String
      Value: !GetAtt SharedBusinessDB.Arn

• 第二步：在需要引用共享数据库的其他仓库模板中，直接用SAM原生的SSM参数类型动态拉取ARN，不需要写死任何固定值，模板片段示例：

# 引用共享资源的仓库 template.yml 片段
Parameters:
  SharedOrderDbArn:
    Type: AWS::SSM::Parameter::Value<String>
    Default: /shared/prod/database/order-db-arn

Resources:
  OrderProcessLambda:
    Type: AWS::Serverless::Function
    Properties:
      CodeUri: lambda/order-process/ # 你现有的Lambda独立文件夹路径
      Handler: app.handler
      Runtime: nodejs20.x
      Policies:
        # 直接引用动态拉取的ARN给Lambda加访问权限
        - DynamoDBCrudPolicy:
            TableArn: !Ref SharedOrderDbArn
      Environment:
        Variables:
          ORDER_DB_ARN: !Ref SharedOrderDbArn

• 第三步：流水线顺序适配：第一次上线时先跑持有共享数据库的仓库流水线，完成数据库和SSM参数创建，之后两个仓库的流水线就可以完全独立运行，不需要做跨仓库依赖编排。后续如果数据库因为重建等原因ARN发生变化，SSM参数会被SAM自动更新，引用方下次执行部署时会自动拉取最新的ARN，完全不需要人工修改配置。

备选方案：CloudFormation导出值 #

如果你的共享数据库资源创建后基本不会删除、替换，可以用CloudFormation原生的导出导入能力，步骤更简单：

• 在共享数据库仓库模板的Outputs块导出ARN：

Outputs:
  SharedOrderDbArn:
    Value: !GetAtt SharedBusinessDB.Arn
    Export:
      Name: prod-shared-order-db-arn

• 在引用方模板中直接用!ImportValue prod-shared-order-db-arn引用即可。
  注意这个方案有硬限制：导出值一旦被其他栈引用，就无法修改或删除，必须先删除所有引用该值的栈才能操作共享数据库，灵活性远差于SSM方案，只适合完全稳定的基础资源。

不推荐之前考虑的两类方案的原因 #

• 嵌套栈方案：嵌套栈要求所有子栈模板归属于同一个父栈的部署生命周期，必须把所有模板统一打包到同一个部署物中，和你当前两个仓库独立流水线、独立部署的模式完全冲突，落地需要重构整套CI/CD做跨仓库依赖编排，改造成本极高。
• 跨仓库共享CDK文件方案：会引入强跨仓库代码依赖，后续共享CDK文件更新时需要同步所有引用仓库的版本，很容易出现版本不一致导致的部署故障，本质是把基础设施层的耦合转成了代码仓库层的耦合，长期维护成本很高。

避坑提醒：如果两个仓库的CI部署用的是不同的IAM角色，一定要给引用方的部署角色加上对应SSM参数路径的读取权限，否则部署时会报权限错误；如果是跨账号部署共享资源，只需要给对应账号的角色加SSM读取权限、数据库资源的访问策略放开对应账号Lambda执行角色的访问权限即可，逻辑和同账号场景一致。

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