1. 企业Azure网络架构总览

Azure网络并不是一张“云端的交换机图”，而是由全球物理骨干、区域边界、可用区容错域、虚拟网络逻辑隔离以及混合云接入路径共同叠加而成的多层体系。企业在上云初期最容易犯的错误，是先把虚拟机部署起来，再回头补网络；而正确的顺序恰恰相反——先确定区域与可用区布局，再确定虚拟网络与子网划分，最后才确定混合云连接与安全边界。本章从全球拓扑讲到企业设计原则，帮助读者建立一张“从物理到逻辑、从云内到云外”的完整心智地图。

一、Azure全球网络拓扑：区域、可用区与边缘

Azure的物理骨架由三个层次构成。最外层是边缘网络，包括全球分布的入网点（PoP）、Azure Front Door 接入点、ExpressRoute 对等位置以及 DDoS 防护清洗点，用户流量首先在这里进入微软骨干。中间层是微软全球骨干网，区域之间通过专用光纤互联，流量在骨干内传输时通常不经过公共互联网，这也是跨区域通信延迟可预测的根本原因。最内层是区域数据中心，每个区域由一组低延迟互联的数据中心组成，区域内数据中心间往返延迟通常在个位数毫秒量级。

需要区分三个容易混淆的概念：区域（Region）是部署资源的地理位置，如 East US、Japan East、China North 3；可用区（Availability Zone）是同一区域内物理隔离的独立供电与冷却单元，通常为 3 个，用于抵御单机房级故障；区域对（Region Pair）是微软为同一地理区域（如美国、欧洲、亚太）内两个区域建立的配对关系，配对区域间的平台更新按批次错开，且异地复制类服务默认优先选择配对区域。三者的容错级别依次为：可用区抵御机房级故障，区域对抵御区域级灾难，全球骨干则决定跨区域访问质量。

二、企业网络设计原则

企业级Azure网络设计可以归纳为五条原则，它们决定了后续所有子网、路由和安全策略的走向。

第一，地址空间先行且不重叠。企业必须为Azure预留一段与本地数据中心、其他云、分支机构都不冲突的私有地址段。常见做法是从 10.0.0.0/8 中划出连续区块，例如本地用 10.0.0.0/12，Azure 生产用 10.16.0.0/12，Azure 非生产用 10.32.0.0/12。若地址重叠，后续只能依赖 NAT，会显著增加排障复杂度。

第二，以订阅和虚拟网络作为隔离单元。生产、非生产、沙箱应使用不同订阅；同一环境内按业务域划分虚拟网络，而不是把所有系统塞进一个巨型 VNet。VNet 之间通过 VNet Peering 或 Azure Virtual WAN 互联，避免形成难以管理的全网状对等。

第三，子网按功能而非按服务器划分。典型分层为：GatewaySubnet（网关专用，建议 /27 或更大）、AzureFirewallSubnet（/26）、应用子网、数据子网、管理子网。子网一旦有资源部署，就不能随意改地址范围，因此规划时要预留增长空间。

第四，安全边界默认拒绝。入站流量经 Front Door 或 Application Gateway 进入，出站流量经 Azure Firewall 或 NVA 统一出口，东西向流量用 NSG 和 Azure Firewall 策略控制。默认拒绝、按需放行，而不是先全通再收紧。

第五，可观测性内建。启用 NSG 流日志、Azure Firewall 日志、Network Watcher 连接监视器，把网络事件汇入 Log Analytics。没有流量可见性的安全边界只是纸面边界。

三、混合云连接场景与安全边界总体框架

混合云连接主要有三类场景。第一类是专线优先：通过 ExpressRoute 建立私网对等，本地与 Azure 之间走专线，适合对延迟、带宽和合规要求高的核心系统。第二类是VPN 备份：在 ExpressRoute 之外部署 Site-to-Site VPN 作为冗余路径，当专线中断时自动切换。第三类是纯 VPN 或点对点：适合中小规模或临时项目，成本低但带宽和稳定性受限。

安全边界的总体框架可以概括为“三层边界、一条主轴”。三层边界分别是：互联网边界（Front Door、WAF、DDoS 防护）、云内东西向边界（NSG、Azure Firewall、Private Endpoint）、混合云边界（ExpressRoute 网关、VPN 网关、边界防火墙）。一条主轴是身份与策略：所有边界最终都由 Microsoft Entra ID、Azure Policy 和 RBAC 统一约束，网络规则只是策略的执行面。

四、一个可参考的起步参数示例

以下参数为教学示例，用于说明规划粒度，并非实测结果。假设企业在 Japan East 部署生产系统，本地数据中心位于东京：

判断规划是否合理，可以看三个信号：本地与 Azure 地址是否完全不重叠；GatewaySubnet 是否预留了足够前缀；关键服务是否跨可用区部署且出站流量是否经过统一防火墙。若这三点都满足，后续扩展和安全加固就有了稳定基础。