Azure landing zone 是为多订阅 Azure 环境提供治理、安全与扩展基础的参考架构，由 Cloud Adoption Framework（CAF）的 Ready 阶段提供设计指引。本页说明平台 landing zone 与工作负载 landing zone 的划分，以及它们与 AI 工作负载的关系。

为什么需要

AI 工作负载通常分散在多个订阅、多个环境中。若缺少统一的管理组结构、策略与网络，合规、出口控制与成本归属会各自为政。

landing zone 把“平台”（集中治理与共享能力）与“工作负载”（团队在护栏内部署）分开，使新增 AI 应用可以按同一套标准创建。

页面指出，新增 AI 能力通常通过更新平台策略来统一约束，而不必改变整体架构。

核心概念

概念	含义
平台 landing zone	集中的治理、安全与共享资源基础，通常每个 Microsoft Entra 租户一个
工作负载 landing zone	一个工作负载一个，包含其全部环境（如开发、测试、生产），每个环境由一个或多个订阅组成
管理组层级	组织全部订阅的治理结构，区分平台资源与工作负载资源
集中资源	连接与网络、安全监控、身份服务、管理服务等；只集中能带来明确治理、运维或经济收益的能力
订阅分发（subscription vending）	可重复地请求、创建并交付工作负载订阅；数量增长后宜自动化
工作负载放置	按需求放入 Online、Corp（内部）或 Local 管理组，并继承其策略
实施方式	加速器（基于基础设施即代码）或自行构建

拓扑与实施方式对比

选项	说明	注意
Hub-spoke 网络	连接订阅集中在 hub，安全、管理、身份与连接各自独立订阅	参考架构中的示例包含防火墙、DDoS 防护与 VPN/ExpressRoute 网关
Azure Virtual WAN	以 Virtual WAN hub 承载多区域连接	适合多区域场景，具体配置以官方页面为准
仅管理组层级	只关注治理结构，不限定网络拓扑	适合先统一治理再决定网络
加速器	Microsoft 提供的基础设施即代码加速器，按推荐实践部署	对大多数组织是最快路径；加速器名称与版本待核实
自行构建	内部团队或与 Microsoft 或合作伙伴共同设计	投入较大，需要自行维护

参考架构中的管理组示例包括 Security、Management、Identity、Connectivity、Corp、Online、Local、Sandbox 与 Decommissioned，用于说明层级划分，不代表必须采用的数量。

与 AI 工作负载的关系

页面明确：Microsoft Foundry 资源可以加入工作负载 landing zone 的环境中，AI 能力按工作负载逐个部署。

数据与 AI 工作负载可以作为独立的工作负载 landing zone，与平台 landing zone 由平台团队与工作团队分别管理。

具体的 AI 安全与网络控制（例如私有端点、出口防火墙、托管标识）见企业 AI 参考架构与安全基线的相关内容。

限制与待核实

加速器的名称、版本与支持范围本页未逐一核对，待核实。

页面中的 Azure Policy 策略定义未展开，具体策略以官方策略参考为准。

页面示意图中的订阅与区域数量为示例，不代表推荐数量。

来源与核对

来源：见 frontmatter 的 sources 列表。

read_scope：正文已读。CAF landing zone 页面为完整正文读取。Foundry 参考架构页面仅用于说明 AI 工作负载的位置关系，在末尾约 7000 字符处截断，相关结论仅限已读部分。

企业知识助手

中国与全球区域差异

Last update: 2026-11-6

🎉Explore AI & LLM & Cloud

👏记录实践，分享思考👏

awesome_ai_copilot