多云互联踩坑清单
各家云的接入模型不一样

接入模型的差异

各家云的专线接入在概念上类似 —— 都是「物理连接 + 逻辑通道 + 路由通告」的三层结构 —— 但具体实现差别不小，规划时需要逐项确认：

• 物理连接的最小单位 —— 有的按端口速率固定档位提供，有的支持在同一物理端口上划分多个逻辑通道。这决定了多个 VPC 或多个账号能否共用一条物理线。
• 逻辑通道与 VPC 的对应关系 —— 一条逻辑通道能连几个 VPC、跨账号怎么授权、跨区域能不能复用，各家规则不同。
• 路由通告方式 —— 静态路由还是 BGP，能通告多少条路由前缀，是否支持路由过滤与优先级控制。前缀数量上限在网段规划复杂时会成为硬约束。
• 冗余模型 —— 单线、双线接入同一接入点、还是双线接入不同接入点。各家对「高可用」的定义和 SLA 承诺不一样。

建议做法：把要接入的每朵云、每个区域、每个账号列成一张表，逐项填上述四项的具体规则，再设计整体拓扑。这张表通常能提前暴露一两个必须调整的假设。

地址规划：最贵的返工

地址段冲突是多云项目里代价最高的问题，因为发现得晚、改起来动的是已上线资源。

典型场景：本地数据中心用 10.0.0.0/8 里的某个段，云 A 的 VPC 默认创建时也落在这个范围，云 B 又和云 A 撞了。等到三方要互通时才发现，此时迁移 VPC 网段意味着重建大量资源。

如果已经发生冲突且无法迁移，技术上还有 NAT 转换这条路，但它会带来额外的运维复杂度和排障难度 —— 属于补救措施而非设计选择。

计费口径：出向流量是主要变量

云专线的费用通常由三部分构成，各家的口径差异集中在第三项：

1. 物理端口费 —— 按端口速率档位的月租，各家结构类似。
2. 逻辑通道费 —— 按通道数量或带宽收取，部分云在小带宽档位免收。
3. 出向流量费 —— 从云上流出的数据量，这是账单波动的主要来源。

需要特别注意的是，通过专线出云的流量单价通常低于走公网出云，但依然是要计费的。有些团队误以为「上了专线就不用付流量费了」，结果在做数据回迁或全量备份时收到意外账单。

规划时的实用建议：先估算稳态的出向流量，再单独估算异常场景的流量 —— 全量备份、灾难恢复演练、数据迁移、日志批量回传。异常场景的峰值往往是稳态的几十倍，值得提前算一遍并设置账单告警。

拓扑：别让云与云之间绕回本地

多云互联最常见的架构错误，是把每朵云各自接一条专线回本地，然后指望它们之间自然互通。

这个结构的问题有三个：时延翻倍（云 A → 本地 → 云 B）、本地出口成瓶颈（所有跨云流量都过本地）、本地故障影响跨云（本地出问题，云与云之间也断）。

更合理的做法是把各云区域接入同一张网，由网络侧做路由收敛 —— 云与云之间在这张网内部直接互通，不必回本地，也不走公网。本地作为其中一个接入点，与各云地位平等。

弗雷德云的云专线与多云互联支持直连 AWS、Azure、GCP、阿里云等主流公有云，标准交付 3 个工作日。配合云枢 YUNSHU 自助平台，VPC、路由、NAT、出口与跨云互联可以自助点选、分钟级生效，跨云拓扑的调整不必每次都走工单。

上线后容易出问题的地方