AWS–Azure 多云专线进入预览：代理出口团队需要重新验证什么
Amazon Web Services 于 2026 年 8 月 31 日宣布，AWS Interconnect – multicloud 与 Microsoft Azure 的连接进入公开预览。这项托管服务旨在按需提供两个云环境之间的专用私有带宽，使客户无需自行安排物理线路。
对于使用代理执行合规数据采集、市场研究、广告验证或区域测试的团队，这项变化主要发生在网络路径中段，并不会减少出口端所需的证据。私有云间连接可以简化传输并提高韧性，但它不会自动证明公共出口由哪一朵云承载、业务是否经过指定代理、TLS 在哪里终止，或故障时是否发生直接互联网回退。
AWS 公布了什么
AWS 将此次预览描述为 AWS 与 Azure 之间的按需私有连接模式。Azure 预览首批覆盖美国东部（北弗吉尼亚）、美国西部（北加利福尼亚）、亚太（悉尼）和欧洲（法兰克福）。
服务会在物理分离的设施和路由器上配置四条独立逻辑路径。AWS 表示，这种四重冗余设计旨在路由器维护和多个独立中断时继续承载流量，包括整站点故障的场景。
AWS 还说明，两家云服务商边缘路由器之间使用 MACsec 保护传输，并包含 Network Synthetic Monitor，帮助发现丢包并判断问题是否来自 AWS 一侧。
这些是有价值的基础设施能力，但不能替代应用层控制和面向具体代理业务的验证。
重画完整出口路径
多云代理路由可能包含：
- 源云中的工作负载进程；
- 源子网、虚拟网络和内部安全控制；
- 私有多云互联；
- 目标云虚拟网络或检查层；
- NAT、防火墙或显式代理配置；
- 商业代理网关；
- 实际代理出口；
- 已授权公共目标。
为每一跳记录路由所有者、加密机制、DNS 解析器、源地址转换、监控信号和故障行为。明确标出私有互联保护结束、公共代理段开始的位置。
不能因为存在私有云间链路，就声称完整代理交易都是私有的。
明确公共出口属于哪朵云
架构必须为每个工作负载回答：
- AWS 工作负载是否先到 Azure，再连接代理网关？
- Azure 工作负载是否先到 AWS，接受集中检查和出口控制？
- 两朵云是否都允许独立出口？
- 正常状态下哪条路径优先？
- 私有链路受损时会发生什么？
- 默认路由能否绕过检查层或代理？
路由表、动态路由、防火墙规则、私有 DNS 和代理环境变量可能相互冲突。必须从应用进程验证实际路径，而不只是检查架构图。
MACsec 有明确边界
AWS 描述的是两家服务商边缘路由器之间的 MACsec。它保护互联段，但不等同于应用到代理、或应用到目标的 TLS。
使用 HTTPS 代理网关时，仍需验证：
- 应用连接到预期代理主机名；
- 证书链和主机名验证已启用；
- 协商的是批准的 TLS 策略；
- 代理认证失败时关闭连接；
- CONNECT 行为符合产品设计；
- 离开互联段后的流量仍按要求受到保护；
- 凭据不会进入流日志、终端输出或支持材料。
对于 SOCKS5，要把路由和加密分开。SOCKS5 本身并不加密应用负载。
重新验证 DNS
工作负载经过私有多云互联后，代理网关名称使用的解析器及返回地址都可能变化。需要测试：
- 两朵云分别使用哪个解析器；
- 分视图或私有区域行为；
- A 与 AAAA 结果；
- 路由变化期间的缓存生命周期；
- 受支持 SOCKS 配置的远程 DNS 行为；
- 旧缓存是否指向不可达或错误网关。
记录解析器和结果类别时，不要保存无关客户数据或完整敏感目标信息。
测试四类故障
四条逻辑互联路径提高基础设施韧性，但代理业务还有其他故障层。
互联受损
观察单路径、路由器或站点不可用时的路由收敛、业务中断、丢包、连接重置和恢复时间。
检查或出口故障
关闭受控的防火墙、NAT 或代理金丝雀，证明流量不会悄悄改走直连。
商业代理故障
模拟网关超时、认证拒绝和 TLS 验证失败。重试必须有上限，也不能切换到未经批准的直接连接。
目标响应变化
把网络故障与目标限流、访问规则和内容变化分开。快速返回的拦截页并不是成功路由。
关联基础设施和应用证据
Network Synthetic Monitor 可以帮助定位 AWS 一侧的丢包，但代理事故记录还应包含：
operation_id
source_cloud
source_region
intended_egress_cloud
interconnect_path_state
proxy_gateway_alias
proxy_route_verified
direct_fallback_blocked
tls_validation_result
observed_exit_market
first_attempt_result
retry_count
total_latency_ms使用别名和脱敏标识。日常遥测中不得包含密码、令牌、Cookie、个人数据或完整敏感 URL。
建立预览验收门槛
将预览用于生产代理路径前，应完成受控评估：
- 所需源地区和目标地区均受支持；
- 每个工作负载都有一条明确的正常出口路径；
- 从应用实际验证路由优先级；
- 已记录互联加密边界；
- 代理 TLS 与目标 TLS 分别测试；
- 两朵云的 DNS 结果都已验证；
- 如果同时使用 IPv4 与 IPv6，应分别测试；
- 已观察单路径、路由器和站点受损场景；
- 代理、NAT 和检查层故障不会产生直连回退；
- 监控能够关联基础设施丢包与应用结果；
- 延迟、首试成功率和成本达到门槛；
- 团队拥有已批准的回滚路径。
由于 Azure 连接仍处于公开预览，关键流量使用前必须核实最新地区、容量、支持和可用性条件。
运营检查清单
- [ ] 已绘制从源到目标的完整代理路径。
- [ ] 每个工作负载的公共出口归属明确。
- [ ] 私有互联段与公共互联网段没有混为一谈。
- [ ] MACsec 与 TLS 边界分别记录。
- [ ] 从应用进程验证实际路由。
- [ ] 在两朵云中检查 DNS 行为。
- [ ] 代理凭据不会进入诊断材料。
- [ ] 已阻止并测试直接回退。
- [ ] 故障切换期间重试上限保持有效。
- [ ] 路由变化后重新验证出口地区和内容。
- [ ] 基础设施与应用遥测共享关联标识。
- [ ] 已记录预览限制与回滚方案。
可继续阅读 98IP 的代理故障切换恢复演练、代理服务 SLA 验证手册和代理位置准确性检查指南。
常见问题
AWS–Azure 多云互联会替代代理服务吗？
不会。它提供云环境之间的私有连接。互联网出口、过滤、商业代理选择和目标访问仍是独立的架构决策。
MACsec 是否让公共代理连接端到端加密？
不会。AWS 描述的是服务商边缘路由器之间的 MACsec。应用 TLS 和代理到目标段仍需独立验证。
四条互联路径能避免所有代理故障吗？
不能。它们主要提高互联韧性。DNS、路由、防火墙、NAT、代理网关、认证、TLS 和目标故障仍可能发生。
故障时应该直接切换到公共互联网吗？
除非这种行为经过明确授权和设计，否则不应该。对强制代理业务，通常应阻止并测试直连回退。
合规说明
仅将多云和代理基础设施用于合法、已授权的业务。遵守目标条款、robots 指令、隐私义务、同意要求和限流。私有连接和加密不会赋予访问受限系统的权限。不得利用故障切换、替代云或代理轮换规避访问决定。
来源说明：Amazon Web Services，《AWS and Microsoft Azure collaborate to expand multicloud networking》，发布于 2026 年 8 月 31 日。
