AI 在云网络（VPC / VNet）部署的编排与安全对齐——从“手工堆资源”到“意图驱动的网络生成”（含 Terraform 工程化）

AI 在云网络（VPC / VNet）部署的编排与安全对齐------从"手工堆资源"到"意图驱动的网络生成"（含 Terraform 工程化）

写在前面：为什么"云网络"反而更容易失控？

很多工程师在第一次接触云网络时，都会产生一种危险的错觉： "云网络比传统网络简单。"

确实，这里没有物理设备，没有线缆，没有机房的噪音。在控制台里点几下，VPC、子网、路由表、安全组仿佛唾手可得。甚至连 NAT、VPN、全球负载均衡，云厂商都贴心地"封装好了"。

但只要你亲历过一个生命周期超过三年的企业级云项目，就会知道真相： 云网络不是简单，而是"复杂度滞后"（隐性债务爆炸）。

第一年，看起来清爽，点击即用；
第二年，开始堆补丁，为了业务上线临时开个"口子"；
第三年，已经没人说得清楚为什么会有这条路由、为什么这个安全组要放行 0.0.0.0/0。

问题的根源并不在云，而在我们的工程方法。在传统网络时代，由于设备昂贵、改动困难，我们被迫先做严谨的设计（Design first）；而在云网络时代，资源廉价、改动极易，于是设计被推迟、被省略、被口头化，最后演变成"堆积木"。

而 AI 真正进入云网络工程，绝不是为了帮你在控制台上"自动点击"，或者帮你写几行 Terraform 代码。它的核心价值在于：第一次让**"架构意图"可以被形式化、被校验、被强制执行**。

这篇文章，讲的就是如何用 AI 找回失控的云网络控制权。

1、云网络的工程复杂度，并没有消失，只是换了形态

如果你只做过 Demo 级别的云实验，那么云网络确实很"简单"。但在真实企业环境中，云网络的复杂度至少来自五个方向。

1.1 多 VPC / 多 VNet 是默认形态，而不是例外

在任何一个稍有规模的组织中：

不同 BU
不同环境（Prod / Test / Dev）
不同账号 / 订阅
不同区域（Region / AZ）

都会自然演化出多个 VPC / VNet。

最初的设计通常是"先分开再说"，但三个月后，你一定会遇到：

共享服务怎么访问？
谁能访问谁？
是走 Peering，还是 Transit？
哪些流量需要过防火墙？

这些问题，本质上已经是CCIE EI / DC 级别的架构问题 ，

只是换了一层 API 外衣。

1.2 路由表与安全策略被"拆散"，反而更难理解

在传统网络中：

路由 → 控制可达性
ACL / FW → 控制访问权限

在云网络中，这两件事被拆到了不同维度：

路由表：决定"能不能到"
安全组 / NSG：决定"能不能进"

而且它们：

分散在每个子网 / 网卡
没有全局视图
没有天然的一致性校验机制

于是你会看到非常典型的场景：

路由是对的，安全组是错的；安全组放通了，但路由绕开了防火墙。

这些问题靠"记忆"和"经验"是解决不了的。

1.3 云网络变更是"渐进污染"的

云网络很少"当场炸"，它更像慢性病：

新业务上线 → 临时放行一条规则
紧急问题 → 开个 0.0.0.0/0
项目结束 → 没人清理

半年后，你再回头看：

没人敢删规则
没人说得清依赖关系
所有变更都靠祈祷

这不是工程，这是堆积。

2、为什么"写 Terraform"并不能解决云网络工程问题

很多团队已经意识到问题，于是选择 Terraform / Bicep / ARM / CloudFormation。

这是正确方向，但远远不够。

2.1 IaC 解决的是"可重复"，不是"可理解"

Terraform 带来的核心价值是：

可复现
可版本控制
可回滚

但它并不自动带来：

架构正确性
安全一致性
跨 VPC 的全局约束

换句话说：

IaC 只是把"手工点控制台"换成了"手工写代码"。

如果架构设计本身是模糊的，那么 Terraform 只是在"稳定地生成错误"。

2.2 人类不擅长维护大规模规则一致性

举一个非常现实的例子。

假设你有：

12 个 VPC
每个 VPC 5--8 个子网
每个子网 3--6 组安全策略

请问：

哪些规则是"模板继承"？
哪些是"例外"？
哪些可以删除？

这个问题对人类是指数级复杂度，但对 AI 是非常适合的约束推理问题。

3、AI 在云网络中的正确位置：不是生成资源，而是展开"意图"

这里是整篇文章最重要的转折点。

AI 在云网络中的角色，不是"帮你写 Terraform"。

而是：把工程师的"架构意图"，展开成可执行、可验证、可持续的网络结构。

3.1 什么是"架构意图"

架构意图不是配置细节，而是稳定、不随实现变化的原则。

例如：

网络隔离粒度是"租户级"还是"应用级"
南北向流量是否必须经过防火墙
东西向（VPC 间）流量是否默认拒绝（Zero Trust）
是否允许 VPC 之间直连
共享服务的访问模型

这些东西，在 CCIE / HCIE 里叫：

分层设计
信任边界
控制面与数据面解耦

在云里，它们需要被结构化表达。

3.2 一个可被 AI 消化的"云网络意图模型"

下面这个例子，并不是配置，而是工程约束描述：

复制代码

network_intent:

  isolation_level: tenant

  topology:

    model: hub-spoke

    transit_required: true

  traffic_control:

    north_south:

      enforcement: firewall

    east_west:

      default_policy: deny

  shared_services:

    allowed: true

    access_via_transit: true

  compliance:

    allow_internet_ingress: false

    outbound_audit: required

注意几点：

没有出现 VPC ID
没有出现 CIDR
没有厂商语法

这是架构层语言。

4、AI 如何从"意图"生成云网络拓扑（工程级过程）

从这里开始，我们进入真正的工程细节。

4.1 AI 不是"直接吐 Terraform"，而是分阶段推理

一个成熟的流程，至少包含四步：

意图解析：理解隔离、路径、控制点
拓扑生成：VPC 数量、角色、连接关系
地址与路由规划：CIDR、路由表
安全策略对齐：路由 + 安全组联合生成

AI 的价值在于：它可以在第 2、3、4 步中持续检查是否违背第 1 步的原则。

4.2 示例：从意图到 VPC 拓扑推导

假设我们输入：

复制代码

tenants:

  - name: finance

  - name: rd

  - name: ops

shared_services: true

AI 的推理结果不应该是"建 3 个 VPC"，

而是：

3 个 Tenant VPC
1 个 Shared Services VPC
1 个 Transit VPC（承载防火墙 / 路由）

这是设计推导，不是模板替换。

5、生成 Terraform：结构先于资源，约束先于语法

到了这里，才轮到 Terraform 出场。

5.1 Terraform 代码应该反映"角色"，而不是"资源堆叠"

一个常见的错误是：

复制代码

resource "aws_vpc" "vpc1" { ... }

resource "aws_vpc" "vpc2" { ... }

而 AI 生成的工程化结构应该更接近：

复制代码

module "tenant_vpc" {

  for_each = var.tenants

  source   = "./modules/tenant_vpc"


  name     = each.key

  cidr     = each.value.cidr

}

这里的关键不是语法，而是：角色抽象。

5.2 AI 自动检查"安全与路由是否解耦失衡"

例如，AI 在生成安全组时，会同时检查：

是否存在允许但不可达的规则
是否存在可达但未授权的路径
是否绕过 transit 的路由

这是人类极其容易忽略，但 AI 非常擅长的事情。

6、一个真实企业级多 VPC 云网络案例：问题不是"怎么建"，而是"怎么不乱"

为了避免空谈，这一节我会用一个高度贴近真实企业的云网络场景，完整走一遍：

从业务需求 → 架构意图 → AI 推导 → Terraform 工程 → 安全对齐校验

6.1 业务背景（这是所有混乱的起点）

某中型企业，组织结构如下：

财务系统（Finance）
研发系统（R&D）
运维 / 管理系统（Ops）
一组共享服务：
- AD / IAM
- 日志
- 跳板机
- 运维平台

约束条件：

三个业务域必须网络隔离
共享服务允许被访问，但不能反向访问业务
所有出互联网流量必须可审计
不允许任何业务 VPC 直接暴露公网
网络规模预期 3 年翻倍

这是一个极其普通的企业需求，但恰恰是这种场景，最容易失控。

6.2 传统做法为什么一定会出问题

如果你让一个经验尚可的工程师来做，流程通常是：

每个部门一个 VPC
再建一个"共享 VPC"
VPC Peering 互连
安全组逐条放行

短期内是能跑的，但半年后一定出现：

Peering 网状爆炸
安全组规则互相引用
无法回答「哪些流量绕过了审计点」
新业务上线只能"复制 + 修改"

这些问题不是工程师能力问题，而是方法问题。

7、把业务需求转成"云网络架构意图"（人类负责的部分）

这里非常关键：
这一部分，必须由人类完成，AI 不能替代。

7.1 用"约束语言"而不是"实现语言"

我们先不谈 VPC、子网、CIDR，而是抽象出约束：

复制代码

network_intent:

  tenants:

    finance:

      internet_access: false

    rd:

      internet_access: false

    ops:

      internet_access: false


  shared_services:

    isolated: true

    allowed_consumers:

      - finance

      - rd

      - ops


  traffic_policy:

    north_south:

      egress_must_go_through: transit

      audit_required: true

    east_west:

      default: deny

      allow_only_via_shared_services: true


  topology:

    model: hub-spoke

    direct_tenant_peering: forbidden

注意：

没有任何云厂商语法
没有资源名
全是**"不变量"**

这一步的价值在于：
三年后，这些原则依然成立。

7.2 这是 CCIE / HCIE 能力的"云化表达"

如果你仔细看，会发现这其实是：

信任边界建模
流量路径控制
单点审计设计
拓扑约束

只是不再依赖设备形态。

8、AI 的第一步：从意图推导"必然拓扑"

AI 在这里做的事情不是生成代码，而是逻辑推导。

8.1 AI 推导出的拓扑角色

基于前面的意图，AI 推导结果应该是：

3 个 Tenant VPC（Finance / R&D / Ops）
1 个 Shared Services VPC
1 个 Transit VPC
- 挂载防火墙 / NAT / 流量审计

并且自动得出几个否定结论：

❌ Tenant ↔ Tenant 不允许直连
❌ Tenant ↔ Internet 不允许直出
❌ Shared Services 不允许主动访问 Tenant

这一步的价值在于：AI 能持续记住这些"禁止项"。

8.2 这是人类极容易犯错的地方

现实中，大量云网络事故，来自：

"临时 Peering 一下，后面再改回来。"

AI 不会"临时"，因为它只遵循意图。

9、地址与路由规划：AI 的优势开始显现

到了 CIDR 与路由阶段，人类的劣势会迅速放大。

9.1 AI 自动做的三件事

AI 在规划地址时，会同时满足：

不重叠
可扩展
拓扑对齐

例如：

复制代码

address_plan:
  transit: 10.0.0.0/16
  shared:  10.10.0.0/16
  tenants:
    finance: 10.20.0.0/16
    rd:      10.30.0.0/16
    ops:     10.40.0.0/16
# AI 注：根据 3 年翻倍增长预期，自动在 Tenant 之间预留了足够的 CIDR 间隔。

这不是"随便分"，而是：

Transit 独立
Shared 独立
Tenant 可按序扩展

9.2 路由推导是"全局约束问题"

AI 在生成路由时，会检查：

是否存在绕过 Transit 的路径
是否出现隐式回程
是否违反"单点审计"

这在 Terraform 之前完成，而不是事后补救。

10、安全策略生成：AI 的真正价值区

这一节，是AI 在云网络中最有价值的地方。

10.1 安全策略不是"规则列表"，而是"路径约束"

AI 不会直接生成安全组，而是先生成允许的通信关系图：

Finance → Shared（限定端口）
R&D → Shared（限定端口）
Ops → Shared（管理端口）
Transit → Internet（受控）

然后才展开为：

安全组规则
NSG
Firewall policy

10.2 示例：AI 生成的安全组逻辑（伪代码）

复制代码

allow:

  - src: tenant.finance

    dst: shared.ad

    ports: [389, 636]


deny:

  - src: any

    dst: any

    default: true

注意："拒绝"是默认态，而不是规则之一。

11、Terraform 工程生成：AI 负责一致性，人类负责审查

现在，才进入 Terraform。

11.1 AI 生成的不是单文件，而是工程结构

典型结构如下：

复制代码

├── modules/
│   ├── vpc/
│   ├── transit/
│   └── security_policies/
├── live/
│   ├── prod/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   └── network_intent.yaml  <-- 核心：人类只维护这个

intent.yaml 是核心输入，Terraform 只是展开器。

11.2 示例：由 AI 生成的 Terraform 片段（节选）

复制代码

module "transit_vpc" {

  source = "../modules/vpc"

  name   = "transit"

  cidr   = var.cidr.transit

}


module "tenant_vpcs" {

  for_each = var.tenants

  source   = "../modules/vpc"


  name = each.key

  cidr = each.value.cidr

}

这里体现的是：

角色化
批量化
可扩展

12、持续校验：AI 不是"生成一次就走人"

这是很多人忽略的一点。

12.1 每一次变更，AI 都在问同一个问题

有没有违背最初的意图？

新增安全组规则？
新增路由？
新增 VPC？

AI 可以自动给出：

风险提示
意图冲突点
建议替代方案

这是人类很难长期保持的纪律性。

13、一次真实的云网络"安全对齐失败"事故：配置都对，但架构是错的

这一节，我不再讲"应该怎么做"，而是讲：

一个在真实企业里发生过、而且非常典型的云网络事故。

事故的危险性不在于"配置错误"，而在于------所有配置看起来都是对的。

13.1 事故背景：一次"合规"的云迁移

该企业已经完成了从 IDC 到云的第一阶段迁移，整体状态如下：

每个业务一个 VPC
有 Transit VPC
有防火墙
有 Terraform
有变更流程
常规 CSPM（云安全态势管理）扫描无高危项

从审计角度看，这是一个合规项目。

13.2 问题是怎么暴露的？

问题不是通过安全扫描发现的，而是：

一次非常偶然的流量分析。

运维团队在排查性能问题时，发现：

某业务系统访问公网 API
没有经过 Transit 防火墙
日志中也没有对应记录

这意味着：存在"不可见的出网路径"。

14、为什么人类会"理直气壮地犯错"

这是一个非常值得拆解的地方。

14.1 人类的推理路径（当时的设计者）

设计者的逻辑是：

所有业务 VPC 的默认路由指向 Transit
防火墙做了出网控制
所以一定是"所有出网都可控"

这个推理在传统网络中几乎不会出错。

14.2 云网络打破了这个隐含前提

但在云网络中，真实情况是：

某些子网：
- 绑定了 NAT Gateway
NAT Gateway：
- 直接绑定公网 IP
路由优先级与下一跳陷阱 ：
- 子网路由表被修改，0.0.0.0/0 的下一跳直接指向了本地 NAT Gateway，而非 Transit Gateway。在云网络中，子网路由优先于全局意图。

结果是：路由逻辑是对的，安全组逻辑是对的，但整体路径绕过了"设计中的控制点"。

15、这是"路径级错误"，不是"规则级错误"

这是很多工程师第一次真正意识到的问题。

15.1 为什么扫描工具发现不了

因为：

没有"违规规则"
没有"过宽放行"
没有暴露端口

它违反的不是规则，而是：

最初的架构意图。

15.2 这正是 AI 能做、人类难以长期坚持的事情

AI 可以持续维护一个抽象模型：

"哪些路径是被允许存在的？"

而不是：

规则有没有写错
CIDR 有没有算错

16、AI 是如何发现这个问题的（工程过程）

下面是这个项目后来补充的能力。

16.1 AI 维护的不是配置，而是"路径图"

AI 在后台维护的是一个逻辑结构：

复制代码

[Business VPC]
      |
      v
[Transit VPC] ---> [Firewall] ---> [Internet]

然后把所有真实配置映射到这张图上。

16.2 发现异常的关键逻辑（基于下一跳校验）

当 AI 扫描配置时，它并不是在看"图"，而是在校验路由表的下一跳（Next Hop）。

AI 捕捉到了如下异常逻辑：

意图模型定义：所有业务子网 0.0.0.0/0 的下一跳必须是 Transit VPC ENI。
实际配置检测：检测到 Tenant-Subnet-RT 的默认路由 0.0.0.0/0，其 Target 被指向了 nat-gw-id（本地 NAT 网关）。
拓扑判定：该 NAT Gateway 位于 Tenant VPC 内部，绕过了 Transit 审计点。

此时，AI 不会关心这个 NAT 配置得是否完美，它只关心一件事： 底层路由指向违背了顶层架构约束。

17、AI 给出的不是"报错"，而是"工程级解释"

这是 AI 真正让工程师愿意用的地方。

17.1 AI 的提示不是告警，而是推理结论

例如：

检测到一条从 tenant-rd 子网到公网的有效路径，

该路径未经过 Transit VPC 中定义的审计节点。

此路径与以下架构意图冲突：

north_south.egress_must_go_through = transit

17.2 同时给出三种处理建议

而不是一句"违规"。

例如：

将该子网的 NAT Gateway 移入 Transit
移除该子网的公网出网能力
在意图模型中显式声明"允许例外"

最终决定，交给人类。

18、哪些地方，必须由人类兜底，而不能交给 AI

这一节非常重要，也是你这个专栏的"边界声明"。

18.1 AI 不应该决定的三件事

业务优先级
风险与收益的权衡
什么时候破例是合理的

这些是责任问题，不是计算问题。

18.2 AI 的角色是"持续反问"

AI 应该做的事情是：

"你现在的选择，是否仍然符合你当初说过的话？"

这不是控制，而是提醒。

19、把这一套能力放回 CCIE / HCIE 体系里看

如果你从认证体系回看，会发现：

CCIE EI：路径控制、策略一致性
CCIE DC：Fabric 意图、流量工程
CCIE Sec：信任边界、审计点
HCIE Cloud：多 VPC 互联、安全域

AI 不是新知识，而是新执行者。

20、这一篇真正想确立的工程结论

到这里，本文其实已经完成它的使命了。我们讨论了意图、拓扑、Terraform 工程化以及最关键的安全对齐。

20.1 云网络进入"后配置时代"

未来的核心竞争力，不再是你是否背得下 AWS 或 Azure 的几百个 API 参数，也不是你能写多复杂的 Terraform 模块。而是：你是否能清晰地表达"这个网络不应该变成什么样"。

这正是业界正在推崇的 Policy as Code (PaC) 的核心价值：用代码定义网络，用策略守卫边界。AI 则是这个过程中的最佳翻译官和审计员。

20.2 AI 不是替代工程师，而是替代"遗忘"

它无法替代你做风险决策，但它能替代那些人类最不擅长的事：

它不会忘记三年前你定下的"隔离原则"；
它不会因为业务紧急就"临时"放行一条高危路由后忘了删除；
它不会因为疲劳而忽略那条绕过防火墙的隐蔽路径。

结语：为什么这一篇是"Now"，而不是"Future"

因为云已经是现实，VPC 已经是主战场，而混乱正在发生。如果你现在打开公司的云控制台，检查一下路由表和安全组，大概率已经能看到"熵增"的痕迹。

AI 不是用来"规划未来的科幻网络"，它是用来把我们现在的网络，从"手工堆砌"的泥潭里，拉回严谨的工程轨道。

（文：陈涉川）

2025年12月28日