7.1 云分支与云网关
7.1 云分支与云网关
云网对照的第一课：当站点本身是云里的一段虚拟网络，SD-WAN 的边缘与网关以什么形态存在。承上：6.2 节的容器化边缘与 ZTP 在这里直接复用——云分支的开通就是 ZTP 的云端重演。启下：7.2 节的骨干加速建立在云网关这个汇聚点上。读完本节，你应当能给"业务上云"的网络接入画出部署图，并说清 SD-WAN 叠加与云厂商原生组网的分工。
分支概念的云化
物理分支的三要素——位置、人员、设备——在云内站点里只剩下设备形态的影子：一个 VPC 或虚拟网络里跑着业务系统，没有店员也没有机房。云分支（Cloud Branch）就是部署在云内的软件边缘：一个虚机或容器实例，运行与物理边缘相同的软件栈，通过 ZTP 注册到同一控制器、执行同一套策略。对控制器而言，云分支与门店分支没有区别——这让全网策略的一致性延伸到了云内。
云分支部署的层级有三种选择，各有适用：业务 VPC 内直署（每个业务 VPC 放一个边缘实例，隔离最好，实例数多）；枢纽 VPC 汇聚（一朵云里只在一两个枢纽 VPC 部署云网关，业务 VPC 经云内路由连到网关，实例省、管理集中）；云厂商组网服务旁挂（边缘不进业务路径，只与云厂商的 transit 网关或虚拟 hubs 对接，把 SD-WAN 当成"另一个接入方"）。中小规模常用枢纽汇聚，多业务线强隔离场景用直署。
云网关：云内的汇聚点
云网关（Cloud Gateway）是枢纽 VPC 里的高可用边缘集群，承担三个角色：隧道汇聚——该云内所有业务 VPC 的南北向流量经它进出 Overlay；协议翻译——把云内路由（VPC 路由表、对等连接）与 Overlay 路由对接，双向注入；安全卡点——云内到本地的流量在这里过分段与 IPSec，云内到云内的流量按策略决定是否检查。云网关必须是多可用区部署——它是单朵云里的咽喉，挂了等于这朵云从专网掉线。
图：多云互联拓扑：云分支、云网关与既有广域的衔接
云分支的成本细目
云分支"免机房"的另一面是"全上账单"，预算时要列全四个科目。实例费：云网关是常驻的虚机或容器实例，多可用区至少两份，规格按加密吞吐选——这个科目 24 小时计费，与流量无关。流量费：云厂商对出云流量计费，跨可用区、跨区域的内部流量也有费率，隧道流量在云内绕行时按云的口径计——SD-WAN 封装不改变计费口径，只改变流量路径。专线分摊：若该云通过专线接入区域 Hub，专线的端口费与流量费要分摊到受益的业务线。许可费：云分支的 SD-WAN 软件许可通常按实例或按吞吐计价，与物理边缘的许可口径可能不同，签约前核对。四个科目合起来，再与"在云厂商买原生互联"的报价对比，才是云分支的真实性价比——只比设备省了多少机房钱，会得出过于乐观的结论。
与云厂商原生服务的分工
云厂商提供了一整套组网能力：专线接入（Direct Connect、ExpressRoute 类）、云内枢纽路由（transit gateway、virtual hub 类）、全球骨干互联。这些与 SD-WAN 的分工要按流量类型划：云内互访与云间大带宽，原生服务是正解——它们走云厂商骨干，带宽与稳定性最优，SD-WAN 硬叠一层只会增加封装开销；云与既有站点的互联，SD-WAN 是正解——它带来加密（公网段）、选路（多链路）、策略一致性（云分支与门店同一套规则）。最常见的组合架构：每朵云拉一条专线接到就近区域 Hub 或云网关，云内大流量走原生对等，云到分支的关键业务流量走 SD-WAN 隧道并受策略调度。
路由冲突：云分支最高频故障的处置
7.1 的工程红线里点名了路由冲突，值得展开成处置手册，因为它的高频程度配得上这个篇幅。故障画像：某业务 VPC 里的服务器突然访问不通本地数据中心，平台显示隧道正常、链路体检单全绿——流量根本没进隧道。根因：云内路由表里，目标网段的路由被 VPC 的默认本地路由（或另一条更精确的路由）抢先，流量被云原生路由直接丢弃或发错方向，SD-WAN 隧道成了摆设。云的路由匹配规则（最长前缀优先加本地路由特殊地位）与广域网的路由习惯不同，两边都要懂才能定位。预防三招：其一，云网关联动的路由注入用云厂商的 API 自动维护，禁止手工在控制台加"临时路由"；其二，规划期就做网段总表（本地与所有云的网段统一分配，从源头消灭重叠——重叠网段在多云环境是结构性炸弹）；其三，变更管理里把"云路由变更"与"广域策略变更"列为同等级别，都要走评审。定位口诀：隧道绿而业务不通，先查云路由表，再查安全组，最后才怀疑 SD-WAN——多数人反过来，在正确的地方白费一小时。
问题：云分支和物理边缘可以混用同一套策略模板吗？
可以且应当，这正是云分支的价值所在——但要做一处适配。策略模板里的链路引用要抽象：物理站点引用"宽带接口、4G 接口"，云分支引用的是"弹性网卡、云内子网"，硬绑接口名的模板无法通用。正确做法是模板用"角色"引用链路（主链路角色、备份角色），站点档案里再把角色映射到实际接口。这个抽象做好了，一个"标准业务站点"模板同时服务门店与云上环境，策略一致性从口号变成默认事实；做不好，云分支就会悄悄长成第二套策略体系，几年后没人说得清哪套是权威。
云分支上线与退役的操作要点
云分支的生命周期比物理站点更"轻进轻出"，两个方向各有要点。上线：部署模板化——云网关用基础设施即代码的声明模板（实例规格、可用区分布、网络接口、路由表项全部代码化），新云环境接入是"跑一遍模板加 ZTP 注册"，人工只做参数确认；上线验收沿用第 6 章口径（隧道全通、体检单产出、故障演练通过），不因环境在云上而放宽。退役：云环境的到期、迁移、缩容是常态，退役流程要提前写好——先把该云的路由从全网策略里摘除（其他站点的流量不再指向它），再停实例、释放隧道授权、归档该站点的遥测数据；顺序反了（先停实例）会让全网产生一阵黑洞路由告警。轻进轻出的另一面是"进出频繁"，把这两套流程写进运维手册，云分支才真正成为可弹性调用的资源而不是一次性工程。
本节要点
- 云分支是软件边缘的云内部署，对控制器而言与门店分支无异；开通即 ZTP 重演，分钟级。
- 部署层级三选：VPC 直署（强隔离）、枢纽汇聚（省实例）、旁挂对接（不进业务路径）。
- 云网关是单云咽喉，必须多可用区；路由表冲突是云分支最高频故障，变更要纳管。
- 与原生组网的分工：云内云间走原生（带宽最优），云与站点走 SD-WAN（加密、选路、策略一致）。
云内的接入问题解决了，下一节处理云与云之间——借公有云骨干当中继，把跨云绕路与质量一起解决。