CloudFormation/SAM：如何安全修改Lambda日志组的逻辑资源名称？

不能直接修改逻辑资源名称——CloudFormation会把逻辑名称的变更判定为「删除旧资源+创建新资源」，直接操作会导致现有日志组被删除（丢数据）；就算给旧资源加DeletionPolicy: Retain避免删除，创建新资源时也会因为物理日志组名称重复而报错，还会留下无引用的旧逻辑资源。

安全修正的分步操作 #

1. 先给旧日志组加保护，防止被删除
   在模板里给拼写错误的FopFuncLogGroup添加DeletionPolicy: Retain，确保后续删除该逻辑资源时，物理日志组不会被CloudFormation删掉。修改后的代码片段：

   FopFuncLogGroup:
     Type: AWS::Logs::LogGroup
     DeletionPolicy: Retain
     Properties:
       LogGroupName: !Sub /aws/lambda/${fooFunc}
       RetentionInDays: 365
   

   执行sam deploy完成这步更新，这只会修改资源属性，不会碰日志里的数据。

2. 把现有日志组导入到新的逻辑名称下

   • 删掉模板里的FopFuncLogGroup定义，添加正确的FooFuncLogGroup，保持物理名称和属性完全一致：

     FooFuncLogGroup:
       Type: AWS::Logs::LogGroup
       Properties:
         LogGroupName: !Sub /aws/lambda/${fooFunc}
         RetentionInDays: 365
     

   • 用CloudFormation的资源导入功能，把已存在的物理日志组关联到新的逻辑资源上。用SAM的话可以执行：

     sam deploy --no-fail-on-empty-changeset --capabilities CAPABILITY_IAM --import-existing-resources
     

     也可以直接在CloudFormation控制台里选「导入资源到栈」，跟着向导选目标日志组，关联到FooFuncLogGroup即可。

3. 清理冗余记录（可选）
   导入完成后，旧的FopFuncLogGroup会从栈里移除，物理日志组现在由新的逻辑资源管理。如果不需要旧资源的历史记录，可以在控制台里清理栈的相关记录。

关键原因说明 #

• CloudFormation靠逻辑资源名称识别唯一资源，改名就等同于删旧建新，这是核心机制决定的。
• 直接加DeletionPolicy: Retain只能保住物理日志组，但新资源创建时会因为同名冲突失败，还会留下无引用的旧逻辑资源，反而增加混乱。

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