CloudFormation输出是否支持Retain类更新策略？如何不删依赖栈更新源栈？

Great question—this is such a common gotcha when working with cross-stack references in CloudFormation! Let’s break this down clearly for you:

Do CloudFormation Outputs have an equivalent of UpdateReplacePolicy: Retain? #

Nope, Outputs (and their exported values) don’t have a direct equivalent to UpdateReplacePolicy. The core issue here is that when an exported value is referenced by another stack, CloudFormation blocks any changes to or deletion of that export until the dependent stack stops using it. This is a safety measure to avoid broken dependencies between stacks.

Solutions to Update the First Stack Without Deleting the Second #

Here are practical, actionable workarounds you can use:

1. Use a Temporary Export to Break the Dependency Temporarily #

This is the best approach if you want to keep the cross-stack reference long-term:

• Step 1: Update your first stack’s template to add a new Output (e.g., FeedStageDynamoTableStreamArnTemp) that exports the same DynamoDB stream ARN as your original output.
• Step 2: Update your second stack to modify its Lambda EventSourceMapping to use this temporary exported value instead of the original one. Now the original export is no longer referenced.
• Step 3: You can now freely update your first stack—whether you need to tweak the original Output, adjust DynamoDB table properties, or even replace the table (your UpdateReplacePolicy: Retain will keep the old table intact, so you won’t lose data).
• Step 4: Once the first stack is updated, switch the second stack back to using the original (now updated) exported value, then you can remove the temporary Output from the first stack if you don’t need it anymore.

2. Replace the Cross-Stack Import with a Parameter in the Second Stack #

If you don’t need a strict cross-stack dependency, this is a quick fix:

• Step 1: Modify your second stack’s template to replace the Fn::ImportValue call with a new Parameter (e.g., DynamoDBStreamArn).
• Step 2: Update the second stack, passing in the current DynamoDB stream ARN as the parameter value. This cuts the dependency on the first stack’s export entirely.
• Step 3: Now you can update the first stack however you need. If you want to restore the cross-stack reference later, just switch the second stack back to using Fn::ImportValue with the updated export.

3. Check if Your Table Update is Non-Breaking #

Wait a minute—if you’re only making changes to the DynamoDB table that don’t require replacing the resource (like adjusting read/write capacity, adding a Global Secondary Index, or updating tags), the stream ARN won’t change. In this case, you should be able to update the first stack without any issues! The block only happens when the exported value itself would change or be deleted.

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