Terraform中共享静态子网数据的推荐实现方式是什么

最优实践：封装为共享Terraform Module #

这是这类场景的首选方案，你可以把所有分类的子网CIDR统一硬编码在一个轻量Module中，按业务场景做结构化输出，示例结构如下：
Module内部的locals.tf配置：

locals {
  # 按业务分类定义所有非AWS托管的内部子网CIDR
  on_prem_cidrs = {
    employee_lan = ["10.0.0.0/24", "10.0.1.0/24"]
    vpn          = ["10.1.0.0/16"]
    office_lan   = ["10.2.0.0/20"]
    guest_lan    = ["192.168.0.0/24"]
    # 新增分类直接在此处扩展
  }

  # 可提前定义常用的组合CIDR，方便直接调用
  trusted_internal_cidrs = flatten([
    local.on_prem_cidrs.employee_lan,
    local.on_prem_cidrs.vpn,
    local.on_prem_cidrs.office_lan
  ])
}

Module内部的outputs.tf配置：

output "on_prem_cidrs" {
  type        = map(list(string))
  description = "按业务分类的非AWS托管内部子网CIDR集合"
  value       = local.on_prem_cidrs
}

output "trusted_internal_cidrs" {
  type        = list(string)
  description = "所有可信内部子网的CIDR合集"
  value       = local.trusted_internal_cidrs
}

使用时只需在需要配置安全组的代码中引用该Module即可，示例：

module "shared_on_prem_cidrs" {
  source = "你的Module仓库地址//on-prem-cidrs"
  version = "~> 1.0"
}

resource "aws_security_group_rule" "allow_employee_access" {
  type        = "ingress"
  from_port   = 443
  to_port     = 443
  protocol    = "tcp"
  cidr_blocks = module.shared_on_prem_cidrs.on_prem_cidrs.employee_lan
  security_group_id = aws_security_group.app_sg.id
}

该方案的优势：

• 所有CIDR统一维护，更新时只需修改一次Module，所有引用的项目同步生效
• 支持版本化管理，变更风险可控
• 结构化的分类定义，避免CIDR用错场景

Remote State方案的适用场景 #

如果你的团队已经有统一的全局静态资源管理规范，也可以将这些CIDR定义在一个无实际资源的Terraform配置中，将state存放在共享远程存储（如S3），通过terraform_remote_state数据源读取。
注意：该方案不如共享Module灵活，需要额外维护无资源的Terraform配置，且依赖远程state的访问权限，仅适合CIDR变更频率极低、团队已有成熟remote state管理流程的场景。

相关Provider说明 #

目前没有专门针对静态CIDR管理的官方Provider，你可以搭配Terraform内置的CIDR校验函数（如cidrvalidate）在Module中添加校验规则，避免错误的CIDR配置提交。
如果你的团队内部使用独立的IPAM系统（如NetBox、phpIPAM），可以直接使用对应系统的Terraform Provider拉取实时CIDR数据，无需硬编码在配置中，彻底避免配置和实际IPAM数据不同步的问题。

额外优化建议 #

• 可以在Module中添加预校验规则，禁止无效CIDR、冲突CIDR的提交
• 变更CIDR时发布新的Module版本，业务方可以按需升级，避免未验证的变更影响线上业务
• 给每个CIDR分类添加清晰的注释，明确使用场景和负责人

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