我工作的公司的大部分 AWS 基础设施都是使用 Terraform 描述和管理的。
我们有几种不同的服务，包括容器化后端和 CDN 化前端。
从 Route53 域和命名空间到 ELB、ECS 和 CloudFront，有很多事情要做。
现在发生的问题之一是，主要是因为 Route53 DNS，检查、刷新和验证 terraform 状态需要很长时间。
这就是我们要解决的问题：
如何大幅减少刷新/检查 tf 状态所需的时间？
将其移至单独的存储库显然不是一个好主意，因为这会使所有与 Route53 相关的变量都无法访问，或者可能已经过时。
我来这里是因为我正在研究一个类似的问题。似乎 TF 在图行走方面很糟糕，所以你的东西越相互关联，它的表现就越差。我有一个 2300 资源的毛线球。这需要 49 分钟才能在具有足够内存和处理器的机器上以 10 的并行度运行而不会出现峰值。三分之一用于刷新状态，这可能无法减少，因为它受 AWS CLI 调用的约束。但是在状态刷新之前花费的第三个和之后的第三个似乎主要是图表中的 TF（基于日志）。
我发现一些讨论似乎表明您的代码结构可能会极大地影响计划时间，特别是for_each（链接＃1和＃2）的使用。由于我的代码库大量使用了这个，我发现这很有趣。YMMV ;)
您应该将状态分解为具有合理逻辑区别的组件子状态，例如“前端”、“缓存”或对您的公司如何组织和分类基础架构有意义的任何内容。
在使变量可访问方面，您可以将其他状态声明为数据源并从中提取（假设它们具有您感兴趣的值的有效输出）。