AWS 与微软 Azure 于 2026 年 8 月 31 日宣布开启直接、按需的私有网络连接公测。对 AWS 而言，这意味着 AWS Interconnect – multicloud 在已有 Google Cloud 和 Oracle Cloud Infrastructure（OCI）连接的基础上，再加入 Azure，形成面向三家主要非 AWS 云服务商的统一多云连接模式。7

不过，最重要的限定条件是：Azure 集成目前仍处于 Public Preview（公开预览）。因此，当前公布的功能范围、区域覆盖、带宽选项以及生产环境适用性，都不应被视为最终版本。

两项服务如何协同工作

这项能力由两家云厂商各自的一侧服务共同提供：

• AWS Interconnect – multicloud：负责 AWS 侧的托管连接，从 Amazon VPC（虚拟私有云）发起连接。
• Azure Multicloud Interconnect：负责 Azure 侧的对应集成。

两者共同构建的是托管式私有 Layer 3（三层）网络路径，用于连接 AWS 与 Azure 的网络环境。其目标是把许多底层网络工作交给云厂商处理，客户不必自行部署物理路由器，也不必搭建一套经由本地数据中心的路由方案。56

AWS 和微软表示，这项合作采用的是标准化开放 API 规范，而不是为双方专门打造的一次性接口。AWS 在 2025 年 re:Invent 大会上首次介绍这一多云连接思路，并通过公开 GitHub 仓库发布开放规范，供其他云厂商采用。1013

客户可从 AWS Direct Connect 控制台配置

AWS 的文档显示，配置流程被设计为尽量减少跨云服务之间的人工交接。客户可以进入 AWS Direct Connect 控制台，选择 AWS Interconnect，创建多云互联，随后选择目标云服务商、源端和目标区域，并指定所需带宽。处于公测阶段的云服务商会在控制台卡片上显示 “Preview” 标签。12

公测也有明确限制：AWS 文档称，在每个受支持的区域内，每位客户最多创建一个互联连接；公测期间连接可免费使用，但仍受适用的预览服务条款约束。12

这套流程的价值在于，企业不必分别协调云平台、托管机房、网络运营商和内部网络团队，再通过多套工单完成连接。只是“几次点击”并不意味着所有路由、地址规划、访问控制和应用层安全问题都自动消失，实际部署仍需要进行架构验证。

Azure 公测的首批区域与带宽

目前提供的材料确认了以下 AWS 侧区域：

• 美国东部（北弗吉尼亚）
• 美国西部（北加利福尼亚）
• 亚太地区（悉尼）
• 欧洲（法兰克福）

现有证据没有权威列出每个区域对应的 Azure 区域名称，因此暂时不宜制作完整的 AWS–Azure 区域配对表。67

微软表示，该连接在正式普遍可用后，目标是支持最高 100 Gbps 的连接速度。5 但这并不代表初始公测阶段已经能够提供完整的 100 Gbps 容量；企业应以当前控制台和官方区域、带宽文档为准。

安全性、冗余与可用性：哪些是承诺，哪些仍待验证

AWS 和微软将这项服务定位为一种兼顾私有性、弹性和运维简化的连接方式。微软特别强调了以下设计特征：

• 通过 MACsec 对链路进行加密；
• 采用四路冗余的底层架构；
• 目标可用性达到 99.99%（四个九）；
• 可根据需求扩展连接容量。56

但这些内容属于厂商公布的特性和设计目标。由于 Azure 连接仍处于公开预览阶段，且现有材料无法独立验证每一项与公测实现有关的技术细节，企业在将其用于生产系统或受监管工作负载之前，应再次确认当前的区域覆盖、带宽、服务等级协议（SLA）和架构文档。

Azure 在 AWS 多云战略中的位置

Azure 并不是 AWS 多云战略的一次孤立尝试。AWS 表示，AWS Interconnect – multicloud 目前覆盖：

1. Microsoft Azure
2. Google Cloud
3. Oracle Cloud Infrastructure

这项服务最初以 Google Cloud 为首个合作伙伴推出，AWS 文档也单独列出了部分 AWS–Google Cloud 区域配对，例如北弗吉尼亚对北弗吉尼亚、北加利福尼亚对洛杉矶。10

Azure 的加入，让客户可以用相近的方式配置另一家主要云平台的私有连接。对 AWS 来说，这也是对“同一套集成模型能否跨越相互竞争的超大规模云厂商”这一思路的进一步验证，而不只是单一双边合作项目。

两家竞争对手为何选择合作

双方给出的直接理由是客户需求。越来越多企业把应用、数据和 AI 工作负载分散到多个云平台，但传统跨云网络往往需要单独设计路由、分别申请服务、协调多方供应商，并维护不同的运维流程。AWS 和微软希望通过合作减少这些定制化工作，让私有跨云连接更一致、更容易管理。56

这次合作之所以受到关注，也在于 AWS 与微软仍是云基础设施市场的直接竞争对手。开放 API 规范为双方提供了一个实际的合作基础：每家厂商仍可保留自己的云网络产品，同时用更标准化的方式完成互联，并为未来可能加入的其他参与者降低接入门槛。513

下一步：更多区域、更高带宽与网络运营商接入

AWS 和微软计划逐步增加区域配对数量，并提高连接容量。微软还将当前服务描述为面向更高带宽需求的基础，未来能力可能超出首批部署范围。56

两家公司设想的参与者也不局限于云厂商之间的直连。网络服务商和电信运营商未来可能加入，从而把较一致的配置和运营模式扩展到云网络、运营商网络与企业网络之间。6

如果更多云厂商和网络参与者采用同一套 API，企业或许可以用更少的定制集成来配置跨云、跨运营商的私有链路。这一方向对分布式 AI 架构尤其重要：训练、推理、数据存储、边缘处理和应用服务可能分布在不同的云区域和网络位置。

但需要注意的是，这目前仍是 AWS 和微软提出的发展方向，并不意味着行业已经形成统一的多云互联标准。Azure 公测阶段更适合用于验证架构和工作负载行为，而不是直接据此假设完整的生产级功能、价格和合同保障。

AWS 与微软 Azure 于 2026 年 8 月 31 日宣布开启直接、按需的私有网络连接公测。对 AWS 而言，这意味着 AWS Interconnect – multicloud 在已有 Google Cloud 和 Oracle Cloud Infrastructure（OCI）连接的基础上，再加入 Azure，形成面向三家主要非 AWS 云服务商的统一多云连接模式。7

不过，最重要的限定条件是：Azure 集成目前仍处于 Public Preview（公开预览）。因此，当前公布的功能范围、区域覆盖、带宽选项以及生产环境适用性，都不应被视为最终版本。

两项服务如何协同工作

这项能力由两家云厂商各自的一侧服务共同提供：

• AWS Interconnect – multicloud：负责 AWS 侧的托管连接，从 Amazon VPC（虚拟私有云）发起连接。
• Azure Multicloud Interconnect：负责 Azure 侧的对应集成。

两者共同构建的是托管式私有 Layer 3（三层）网络路径，用于连接 AWS 与 Azure 的网络环境。其目标是把许多底层网络工作交给云厂商处理，客户不必自行部署物理路由器，也不必搭建一套经由本地数据中心的路由方案。56

AWS 和微软表示，这项合作采用的是标准化开放 API 规范，而不是为双方专门打造的一次性接口。AWS 在 2025 年 re:Invent 大会上首次介绍这一多云连接思路，并通过公开 GitHub 仓库发布开放规范，供其他云厂商采用。1013

客户可从 AWS Direct Connect 控制台配置

AWS 的文档显示，配置流程被设计为尽量减少跨云服务之间的人工交接。客户可以进入 AWS Direct Connect 控制台，选择 AWS Interconnect，创建多云互联，随后选择目标云服务商、源端和目标区域，并指定所需带宽。处于公测阶段的云服务商会在控制台卡片上显示 “Preview” 标签。12

公测也有明确限制：AWS 文档称，在每个受支持的区域内，每位客户最多创建一个互联连接；公测期间连接可免费使用，但仍受适用的预览服务条款约束。12

这套流程的价值在于，企业不必分别协调云平台、托管机房、网络运营商和内部网络团队，再通过多套工单完成连接。只是“几次点击”并不意味着所有路由、地址规划、访问控制和应用层安全问题都自动消失，实际部署仍需要进行架构验证。

Azure 公测的首批区域与带宽

目前提供的材料确认了以下 AWS 侧区域：

• 美国东部（北弗吉尼亚）
• 美国西部（北加利福尼亚）
• 亚太地区（悉尼）
• 欧洲（法兰克福）

现有证据没有权威列出每个区域对应的 Azure 区域名称，因此暂时不宜制作完整的 AWS–Azure 区域配对表。67

微软表示，该连接在正式普遍可用后，目标是支持最高 100 Gbps 的连接速度。5 但这并不代表初始公测阶段已经能够提供完整的 100 Gbps 容量；企业应以当前控制台和官方区域、带宽文档为准。

安全性、冗余与可用性：哪些是承诺，哪些仍待验证

AWS 和微软将这项服务定位为一种兼顾私有性、弹性和运维简化的连接方式。微软特别强调了以下设计特征：

• 通过 MACsec 对链路进行加密；
• 采用四路冗余的底层架构；
• 目标可用性达到 99.99%（四个九）；
• 可根据需求扩展连接容量。56

但这些内容属于厂商公布的特性和设计目标。由于 Azure 连接仍处于公开预览阶段，且现有材料无法独立验证每一项与公测实现有关的技术细节，企业在将其用于生产系统或受监管工作负载之前，应再次确认当前的区域覆盖、带宽、服务等级协议（SLA）和架构文档。

Azure 在 AWS 多云战略中的位置

Azure 并不是 AWS 多云战略的一次孤立尝试。AWS 表示，AWS Interconnect – multicloud 目前覆盖：

1. Microsoft Azure
2. Google Cloud
3. Oracle Cloud Infrastructure

这项服务最初以 Google Cloud 为首个合作伙伴推出，AWS 文档也单独列出了部分 AWS–Google Cloud 区域配对，例如北弗吉尼亚对北弗吉尼亚、北加利福尼亚对洛杉矶。10

Azure 的加入，让客户可以用相近的方式配置另一家主要云平台的私有连接。对 AWS 来说，这也是对“同一套集成模型能否跨越相互竞争的超大规模云厂商”这一思路的进一步验证，而不只是单一双边合作项目。

两家竞争对手为何选择合作

双方给出的直接理由是客户需求。越来越多企业把应用、数据和 AI 工作负载分散到多个云平台，但传统跨云网络往往需要单独设计路由、分别申请服务、协调多方供应商，并维护不同的运维流程。AWS 和微软希望通过合作减少这些定制化工作，让私有跨云连接更一致、更容易管理。56

这次合作之所以受到关注，也在于 AWS 与微软仍是云基础设施市场的直接竞争对手。开放 API 规范为双方提供了一个实际的合作基础：每家厂商仍可保留自己的云网络产品，同时用更标准化的方式完成互联，并为未来可能加入的其他参与者降低接入门槛。513

下一步：更多区域、更高带宽与网络运营商接入

AWS 和微软计划逐步增加区域配对数量，并提高连接容量。微软还将当前服务描述为面向更高带宽需求的基础，未来能力可能超出首批部署范围。56

两家公司设想的参与者也不局限于云厂商之间的直连。网络服务商和电信运营商未来可能加入，从而把较一致的配置和运营模式扩展到云网络、运营商网络与企业网络之间。6

如果更多云厂商和网络参与者采用同一套 API，企业或许可以用更少的定制集成来配置跨云、跨运营商的私有链路。这一方向对分布式 AI 架构尤其重要：训练、推理、数据存储、边缘处理和应用服务可能分布在不同的云区域和网络位置。

但需要注意的是，这目前仍是 AWS 和微软提出的发展方向，并不意味着行业已经形成统一的多云互联标准。Azure 公测阶段更适合用于验证架构和工作负载行为，而不是直接据此假设完整的生产级功能、价格和合同保障。