CloudFormation如何引用控制台手动创建的现有AWS资源
日常运维中碰到控制台手动创建的资源需要在CloudFormation中复用是非常普遍的场景，你初步梳理的三个实现方向都具备落地可行性，但适用场景、成本、风险差异极大，另外还有几个更轻量化的原生实现，没必要一上来就投入开发做自定义资源。
你提到的三类方案的实际可行性评估
将现有资源导入CloudFormation栈统一管理
完全可行，这是AWS原生提供的正式能力。操作逻辑是把手动创建的资源补全匹配栈模板的定义后，直接纳入目标栈的管控范围，导入完成后可以和栈原生创建的资源一样，用!Ref、!GetAtt正常引用全部属性。
实际落地要注意两个核心问题：一是不是所有AWS资源类型都支持导入，导入前需要确认对应资源的支持范围；二是导入后的资源会受栈生命周期管理，如果后续执行栈删除操作，会直接把导入的线上资源一并删除，误操作风险极高。另外如果模板里定义的资源配置和实际控制台的配置不一致，后续栈更新会触发资源替换，带来不必要的业务中断。通过栈参数传入资源标识完成引用
这是目前生产环境最常用的轻量方案，完全可行。
实际操作时不要用普通字符串参数传资源ARN或名称，直接用AWS提供的强类型参数（比如AWS::Lambda::Function::Arn、AWS::IAM::Role::Arn、AWS::S3::Bucket::Name），这类参数在栈部署阶段就会自动校验传入的资源是否在当前账号、当前区域合法存在，提前拦截传错的问题。引用过程完全不改动现有手动资源的任何配置，也不会把资源纳入栈的管控范围，栈删除不会影响外部引用的手动资源，整体风险极低。
唯一的不足是如果手动创建的资源后续出现标识变更（比如S3桶改名、Lambda函数改ARN），需要手动同步更新所有依赖它的栈的参数值。自定义资源拉取现有资源属性完成引用
技术上可行，但绝大多数场景属于过度设计。
自定义资源的核心逻辑是绑定Lambda函数，在栈部署阶段调用AWS API查询现有资源的动态属性，本质是补充CloudFormation本身不支持的属性查询能力。这种方案的问题是需要额外维护自定义资源的Lambda逻辑、权限配置，会给栈增加额外的故障点，除非需要查询的资源属性是CloudFormation本身完全不支持通过参数或动态引用获取的冷门配置，否则完全没必要落地。
其他更适配的原生实现选项
除了你提到的三个方向，还有两个CloudFormation原生支持、零额外开发的方案，适配绝大多数场景：
动态引用统一获取资源标识
不需要每次部署都手动传参数，可以把手动创建的资源的固定标识（比如S3桶名、IAM角色ARN、Lambda函数ARN）提前存在AWS Systems Manager Parameter Store里，在CloudFormation模板里直接用内建动态引用拉取参数值，格式类似{{resolve:ssm:/shared/s3/manual-bucket-arn}}。这种方式不需要自定义资源，所有手动资源的标识可以在参数中心统一维护，后续资源变更只需要改SSM参数值，所有依赖它的栈在下次部署时会自动拉取最新配置，不需要挨个更新栈参数。分层建栈维护共享引用入口
如果手动创建的资源会被多个业务栈依赖，可以单独建一个极简的基础资源栈，这个栈不实际创建任何资源，只负责把所有现有手动资源的标识通过Export导出，所有上层业务栈直接通过Fn::ImportValue引用这些导出值。这种方式可以把所有手动资源的引用关系统一收拢，避免每个栈都硬编码资源ARN，后续资源变更只需要调整基础栈的导出值，所有依赖栈可以统一适配。
实际选型的优先级建议
从风险、维护成本、落地效率三个维度综合排序：
- 日常普通引用、不需要接管现有资源的场景，优先选「强类型参数传入」或「SSM动态引用拉取标识」，零侵入、无额外开发成本，风险最低
- 长期需要消除控制台手动配置漂移、统一管控资源配置的场景，再考虑「原生资源导入流程」，落地前务必做好资源配置和栈模板的匹配校验
- 仅当需要查询CloudFormation原生能力完全不支持的资源动态属性时，才考虑使用Lambda-backed自定义资源，避免无意义的复杂度提升
- 所有跨栈依赖的手动资源，不要在各个业务栈里硬编码标识，统一维护引用入口，避免后续资源变更带来的大面积配置不一致
内容的提问来源于stack exchange，提问作者JASPHI
