CloudFormation创建初始SSM参数支持后续AWS控制台更新的管理方案

针对你描述的场景，优先选择手动创建SSM参数+CloudFormation动态引用的方案，完全匹配你的需求：

• 和你的核心设计目标一致：你最初的诉求就是仅对参数名称做版本控制，不需要管控参数值。使用resolve:ssm系列动态引用时，CloudFormation模板仅需要固定写死参数名，部署运行时会自动拉取SSM中最新的参数值，你在AWS控制台修改SSM参数值的操作不会和CloudFormation栈产生任何冲突，也不需要每次修改后同步更新CloudFormation模板，完全适配你的使用流程。
• 避免资源漂移带来的副作用：如果将SSM参数导入CloudFormation栈管理，后续你在控制台修改参数值后，CloudFormation会检测到资源配置漂移，后续每次执行栈更新操作时，只要模板内的Value字段没有同步更新，就会强制覆盖你在控制台修改的参数值，不符合你的使用习惯。
• 落地成本极低：动态引用不需要调整现有SSM参数的任何配置，也不需要执行资源导入这类有操作风险的步骤，直接修改模板内的参数引用方式即可生效。

如果后续你的需求发生以下变化，可以再考虑将SSM参数导入CloudFormation栈统一管理：

• 需要对SSM参数的所有属性（包括值、类型、标签、访问权限等）做全生命周期的版本管控，不允许绕过CloudFormation在控制台直接修改参数
• 需要通过CloudFormation栈的生命周期统一管理SSM参数的创建、删除，避免项目下线后出现无用参数残留

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