Terraform中SQS两种重驱动策略配置方式的差异与选型疑问

示例A和示例B的核心差异 #

这两种方式的本质区别是策略配置的载体不同：

• 示例A：将死信队列的redrive_allow_policy（控制允许哪些源队列发送死信消息）直接内嵌在死信队列的aws_sqs_queue资源中，而用独立的aws_sqs_queue_redrive_policy资源为源队列配置重驱动规则（指定死信队列地址和消息最大接收次数）。
• 示例B：将redrive_policy（重驱动规则）直接内嵌在死信队列的aws_sqs_queue资源中，而用独立的aws_sqs_queue_redrive_allow_policy资源为死信队列配置允许接收的源队列范围。

从SQS原生逻辑来看，redrive_policy是源队列的专属配置（决定无法处理的消息转发目标），redrive_allow_policy是死信队列的专属配置（控制死信消息的来源权限）。示例A的配置逻辑更贴合SQS原生设计，示例B仅死信队列的允许策略拆分为独立资源管理。

替代方案与前两种方式的对比 #

替代方案将两个策略直接内嵌在同一aws_sqs_queue资源中，和前两种方式的最终效果完全一致，但具备明显优势：

• 资源更精简：无需额外创建独立的策略资源，Terraform状态文件的资源条目更少，管理成本更低。
• 配置更集中：队列的所有关联策略都在同一资源块中定义，可读性和维护性更强，避免跨资源的配置分散。
• 变更更可控：修改策略时只需更新单个资源，无需处理多资源间的依赖关系，降低变更出错概率。

推荐方案 #

优先选择替代方案，即将redrive_policy和redrive_allow_policy直接内嵌在aws_sqs_queue资源中。这种方式既符合Terraform「资源集中管理」的最佳实践，也贴合SQS的配置逻辑，同时减少不必要的资源拆分，让配置更简洁高效。

仅在特殊场景（如需要单独为策略添加生命周期规则、或策略需被其他资源引用）下，再考虑使用独立的aws_sqs_queue_redrive_policy/aws_sqs_queue_redrive_allow_policy资源。

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