CloudFormation 跨栈传值方式对比：Export/Import、Nested Stack、SSM Parameter Store

当基础设施被拆分成多个 CloudFormation stack 之后，一定会遇到同一个问题：“某个 stack 的资源 ID 或 ARN，该怎么被另一个 stack 引用？“本文整理三种常见方式——Export/Fn::ImportValue、Nested Stack、SSM Parameter Store——的原理与适用场景。

1. Export / Fn::ImportValue

输出方 stack 在 Outputs 中定义 Export，引用方 stack 用 Fn::ImportValue 读取。

# 输出方 stack
Outputs:
  VpcId:
    Value: !Ref Vpc
    Export:
      Name: shared-network-vpc-id

# 引用方 stack
Resources:
  WebSg:
    Type: AWS::EC2::SecurityGroup
    Properties:
      VpcId: !ImportValue shared-network-vpc-id

特点

CloudFormation 原生功能，不需要额外资源。
被 Export 的值，只要还有任何一个 stack 在 Import 它，输出方 stack 就无法更新或删除（连修改该值本身的更新也不行）。这种紧耦合是最大的弱点。
Export 名称在同一区域内必须全局唯一，需要注意命名冲突。

适用场景：VPC ID、基础域名等极少变动的基础性数值，需要分发给大量 stack 时。

2. Nested Stack

父 stack 通过 AWS::CloudFormation::Stack 资源调用子模板，并在父模板里用 !GetAtt ChildStack.Outputs.XXX 直接引用子 stack 的 Outputs。

Resources:
  NetworkStack:
    Type: AWS::CloudFormation::Stack
    Properties:
      TemplateURL: https://.../network.yaml

  AppStack:
    Type: AWS::CloudFormation::Stack
    Properties:
      TemplateURL: https://.../app.yaml
      Parameters:
        VpcId: !GetAtt NetworkStack.Outputs.VpcId

特点

父子关系作为一个”部署单元”整体管理，update-stack / delete-stack 都通过父 stack 一次性执行。
不容易出现 Export/Import 那种”因为被引用而无法删除”的问题，因为一切都限定在父 stack 的生命周期内。
代价是子模板需要提前上传到 S3，构建、部署的步骤会增加。
父 stack 的事件、漂移检测、回滚都会连带影响子 stack，部署的影响范围容易扩大；stack 数量一多，嵌套变深，也会让结构变得难以理解。

适用场景：需要始终一起部署、一起销毁的紧密资源组（例如某个微服务自带的 Lambda、DynamoDB、API Gateway 一整套），想把它们打包成一个模板。

3. SSM Parameter Store

把数值保存在 stack 之外的 Systems Manager Parameter Store 里，输出方和引用方都通过它来读写。

# 输出方：把值写成参数
Resources:
  VpcIdParam:
    Type: AWS::SSM::Parameter
    Properties:
      Name: /shared/network/vpc-id
      Type: String
      Value: !Ref Vpc

# 引用方：通过动态引用读取（部署时解析）
Resources:
  WebSg:
    Type: AWS::EC2::SecurityGroup
    Properties:
      VpcId: "{{resolve:ssm:/shared/network/vpc-id}}"

特点

stack 之间在 CloudFormation 层面没有直接依赖，不存在 Export/Import 那种”被引用就不能删除”的限制。
{{resolve:ssm:...}} 是在模板部署执行时解析数值的，所以参数更新后，引用它的其他 stack 不会自动同步（需要显式重新部署）。这一点和 Export/Import 类似。
即便跨 stack、跨仓库、跨团队共享数值，也可以脱离 CloudFormation 的范围，被 CLI、Lambda、其他 IaC 工具等直接读取，通用性更强。
参数本身可以挂 IAM 策略，方便精细控制谁能读写。

适用场景：跨团队的松耦合协作，或者需要被 CloudFormation 以外的工具（CDK、Terraform、应用代码等）读取同一个值的场景。

对比总结

方式	耦合度	删除时的限制	适用范围	额外成本
Export / Fn::ImportValue	stack 之间紧耦合	只要还有 stack 在 Import，输出方就无法更新/删除	仅限同一区域内的 CFn stack	无
Nested Stack	父子紧耦合（同一部署单元）	删除父 stack 会连带删除子 stack；与其他 stack 的隔离度高	局限于父模板之下	需要把模板放到 S3
SSM Parameter Store	松耦合	无限制（参数独立存在）	CFn 以外的工具、团队也可以读取	随参数数量产生管理成本（Standard 层级有免费额度）

该如何选择

同一团队维护、变更频率很低的基础数值（VPC、公共 KMS key 等），只是要分发给多个 stack 的话，用简单的 Export/Import 通常就够了，但要清楚它在更新、删除上的限制。
始终一起部署／销毁的资源组想打包成模板复用，选 Nested Stack，同时注意不要嵌套太深。
跨团队、跨仓库的协作，或者需要被 CloudFormation 以外的工具读取的值，SSM Parameter Store 最灵活，近年来越来越多团队出于松耦合的考虑把它作为默认选择。

三者本质上都是”紧耦合、简单但难以变更”与”松耦合、灵活但管理对象增多”之间的取舍，具体选择应根据 stack 拆分的粒度、团队结构和变更频率来决定。