你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn 。 访问此页面需要授权。 可以尝试 登录 或 更改目录 。 访问此页面需要授权。 可以尝试 更改目录 。 本文可帮助决策者定义其跨公共、专用和国家合作伙伴云Azure登陆区域和治理基线。 这是帮助决策者采用主权的第二步。 显示 Microsoft 主权云采用流程各阶段的图示：规划和准备、Azure 着陆区域架构和治理，以及运营标准。 Azure登陆区域是启动的先决条件，每个阶段都基于上一个阶段。 主权体系结构和治理是一段时间内保持合规性的基础。 它们建立了工作负载继承的平台防护措施，以及用于强制执行主权要求的控制措施。 本文基于 Azure登陆区域 ，仅关注不同于标准Azure登陆区域指南的主权要求。 结果 ：在体系结构和治理规划结束时，你对所使用的每个Microsoft主权云部署模型都有一个已批准的目标体系结构、治理基线和实现方法。 概念体系结构图显示了Azure登陆区域如何支持跨多个部署模型的主权工作负荷。 在中央，主权公有云中的主权 Azure 登录区域包含一个提供共享治理和管理服务的平台登录区域，以及面向各个工作负荷的应用程序登录区域。 一个应用程序登陆区域托管主权公有云工作负载，另一个托管主权私有云工作负荷。 Microsoft 365服务、安全、标识和数据治理服务在整个环境中提供功能。 主权私有云工作负载扩展到本地Azure Local环境，其中工作负荷在本地硬件上运行。 单独的国家合作伙伴云部署模型与Azure登陆区域一起显示，并显示在合作伙伴控制的基础结构上运行的工作负荷。 该图说明了如何在统一云采用框架体系结构中跨公有云、私有云和合作伙伴运营的环境应用主权控制。 跨三个Microsoft主权云部署选项的主权工作负荷的概念视图。 下载此架构的 PowerPoint 文件 。 在 Azure 着陆区下方，Microsoft Copilot Studio、Microsoft Fabric 和 Microsoft 365 被展示为集成的业务、数据和 AI 解决方案。 在底部，数据源包括本地系统、Dataverse、Microsoft 365、Azure 工作负载和其他云连接到这些解决方案。 双向箭头表示数据源、Microsoft平台和Azure工作负载之间的集成。 三个Microsoft主权云部署选项中主权工作负载的概念视图，这些选项显示了企业与Microsoft解决方案的集成。 下载此架构的 PowerPoint 文件 。 下面，大型Azure登陆区域框包含平台登陆区域和多个应用程序登陆区域。 由平台团队管理的平台着陆区包含管理组层次结构，将用于安全、管理、网络与连接以及标识的集中式平台资源彼此分隔。 将显示Azure Policy和Azure RBAC，因为它们将应用于管理组。 标注表明平台团队负责向工作负载团队集中分发应用程序登陆区域。 三个Microsoft主权云部署选项中主权工作负荷的详细概念视图。 下载此架构的 PowerPoint 文件 。 在 Azure 着陆区下方，Microsoft Copilot Studio、Microsoft Fabric 和 Microsoft 365 被展示为集成的业务、数据和 AI 解决方案。 在底部，数据源包括本地系统、Dataverse、Microsoft 365、Azure 工作负载和其他云连接到这些解决方案。 双向箭头表示数据源、Microsoft平台和Azure工作负载之间的集成。 三个Microsoft主权云部署选项中主权工作负载的详细概念视图，这些选项显示了企业与Microsoft解决方案的集成。 下载此架构的 PowerPoint 文件 。 如果需要定义主权要求和控制，请从主权规划开始。 如果标准Microsoft云功能和治理控制已足够，请使用公有云Azure。 如果工作负荷需要对治理、数据驻留、机密性、加密、密钥管理或操作员访问监督进行主权控制，请使用主权公有云。 如果工作负荷需要客户控制的基础结构或本地操作，请确定是否需要Azure连接。 如果需要连接能力，请使用“主权私有云 Connected”。 如果不需要连接，请使用主权私有云断开连接。 如果工作负荷需要由本地提供商在国家管辖范围内运行的基础结构，请使用国家合作伙伴云。 在载入工作负载之前，请确定是否需要主权体系结构和治理指南，以及是否需要主权操作标准来保持持续合规性。 此过程以将工作负载载入到所选Microsoft主权云环境结束。 Microsoft主权云的决策树。 下载此架构的 PowerPoint 文件 。 主权公有云Azure。 工作负荷在Azure区域中运行，并使用与任何其他订阅相同的服务目录。 Azure登陆区域最佳做法适用，包括基础管理组层次结构和集中式平台资源。 为每个 主权分类 创建管理组。 将 Azure Policy 定义或策略集以及其他治理控制分配到管理组级别，以强制实施该主权分类所要求的控制措施。 将应用程序登陆区域订阅放置在与工作负荷分配的主权分类匹配的管理组下。 治理基线 ：若要建立主权公有云治理基线，请参阅 主权控制表中 的执行机制。 实施选项 ：Microsoft提供 主权登陆区域加速器 ，它将特定的主权控制添加到标准 平台登陆区域加速器 （ 有关详细信息，请参阅下表 ）。 你还可以开发自己的实现，或与Microsoft或Microsoft合作伙伴合作，为主权要求构建自定义的平台登陆区域。 请参阅下表，了解主权登陆区域加速器向平台登陆区域加速器添加的内容。 同样的原则适用于 Azure 着陆区。 每个工作负载对应一个应用程序着陆区。 对于每个工作负载环境（开发、测试、生产），您都使用一个或多个 Azure 订阅。 数据驻留与工作负载韧性彼此存在张力。 现在确定组织的规则。 设置工作负荷可使用的主权边界内区域，以及是否允许其跨多个区域。 如果边界包含多个已批准的区域，请允许多区域设计，以便工作负荷获得更强的恢复，并将任何灾难恢复区域保留在同一边界内。 如果边界包含单个已批准的区域，则说得如此简单，并且需要可用性区域以实现区域内复原和基于备份的恢复，因为团队无法满足你排除的跨区域目标。有关计划的决定，请参阅 Azure中的可靠性和主权 ， 以及什么是Azure可用性区域？ 公有云中的主权工作负载像其他任何工作负载一样，可与 Microsoft 和 Azure 服务集成。 唯一的主要约束是服务可用性。 确认依赖的每个服务在已批准的区域中运行，并支持分类所需的主权控制。 主权私有云在 Azure Local （你拥有的基础结构）上运行，并在自己的设施中运行。 体系结构必须提供该决策所需的应用程序、数据、标识、管理、安全、网络、通信和操作功能。 根据工作负荷需求、恢复目标、允许的地理边界和故障域调整环境的大小和分发。 避免产生新的集中风险。 您的架构主要取决于连接模式。主权私有云运行在您在自有设施中拥有并运营的基础设施上。 体系结构主要通过连接模式进行更改。 不会添加新的管理组。 Azure 着陆区已包含一个用于 Azure Local 工作负载的 Local 管理组。 将所有 Azure Local 订阅置于其中，并更新其策略分配，以强制执行各个分类的基线。

治理基线 ：请参阅 主权控制表中 的强制机制，以建立主权私有云治理基线。 实现选项 ：Microsoft提供 主权登陆区域加速器 ，它将特定的主权控制添加到标准 平台登陆区域加速器 。 你还可以开发自己的实现，或与Microsoft或Microsoft合作伙伴合作，为主权要求构建自定义的平台登陆区域。 联机操作和脱机操作有一个会影响你决策的重要区别。 连接操作 ：使用Azure公有云环境中所用的相同应用程序登陆区域原则。 但是，你的工作负载运行在由你拥有的 Azure Local 硬件上。 请参阅 连接操作概述 。 连接操作 ：使用Azure公有云环境中所用的相同应用程序登陆区域原则。 但是，你的工作负载运行在由你拥有的 Azure Local 硬件上。 请参阅 连接操作概述 。 脱机操作 ：计费和许可需要 Azure 订阅。 工作负载完全在本地环境中运行。 将相同的应用程序登陆区域设计原则应用于本地工作负荷环境。 请参阅 Azure Local 的断开连接操作概述 。 脱机操作 ：计费和许可需要 Azure 订阅。 工作负载完全在本地环境中运行。 将相同的应用程序登陆区域设计原则应用于本地工作负荷环境。 请参阅 Azure Local 的断开连接操作概述 。 首要决策是确定主权工作负载可在何处恢复。 定义恢复的地理边界以及组织必须能够承受的中断级别，例如服务器故障、设施中断或区域事件。 联网运营 ：确定工作负载是仅可恢复到 Azure Local 站点，还是也可恢复到主权公有云中经批准的 Azure 区域。 如果允许主权公有云恢复，请定义已批准的位置并验证它们是否符合主权要求。 联网运营 ：确定工作负载是仅可恢复到 Azure Local 站点，还是也可恢复到主权公有云中经批准的 Azure 区域。 如果允许主权公有云恢复，请定义已批准的位置并验证它们是否符合主权要求。 离线操作 ：确定恢复是否必须限制在单个设施内、跨多个设施，或跨更广泛的主权区域。 选择支持恢复目标的恢复方法，并且与Azure连接无关。 确保标识、访问和其他关键平台服务在恢复位置保持可用，以便工作负荷可以在故障转移后继续运行。 离线操作 ：确定恢复是否必须限制在单个设施内、跨多个设施，或跨更广泛的主权区域。 选择支持恢复目标的恢复方法，并且与Azure连接无关。 确保标识、访问和其他关键平台服务在恢复位置保持可用，以便工作负荷可以在故障转移后继续运行。 请参阅 Azure Local的基础结构复原能力 。 可以在已连接或未连接的 Azure Local 上运行 Microsoft 365 、 Foundry AI 模型 和 GitHub Enterprise 。 连接 ：工作负载可以与支持混合或本地连接的Azure服务和Microsoft云服务集成。 连接 ：工作负载可以与支持混合或本地连接的Azure服务和Microsoft云服务集成。 已断开连接 ：断开连接的操作会影响管理Azure Local环境的方式及其与Azure管理服务的连接。 它们本身不会限制工作负荷或应用程序集成。 根据主权要求，工作负载仍可与本地系统、合作伙伴环境和Microsoft 服务集成。 组织通常选择断开连接的操作来减少对外部服务的依赖关系，但部署模型本身不会阻止批准的集成。 计费和许可仍需要Azure订阅。 请参阅 Azure Local的断开连接操作 。 已断开连接 ：断开连接的操作会影响管理Azure Local环境的方式及其与Azure管理服务的连接。 它们本身不会限制工作负荷或应用程序集成。 根据主权要求，工作负载仍可与本地系统、合作伙伴环境和Microsoft 服务集成。 组织通常选择断开连接的操作来减少对外部服务的依赖关系，但部署模型本身不会阻止批准的集成。 计费和许可仍需要Azure订阅。 请参阅 Azure Local的断开连接操作 。 国家合作伙伴云 独立于Microsoft运行，因此它们对体系结构的影响特定于合作伙伴。 在提交设计之前，先使用操作员验证平台功能。 应用 Azure 着陆区实践，并使其适应合作伙伴提供的服务以及工作负载需求。 如果合作伙伴支持所需的 API 和服务版本，则可以使用 主权登陆区域加速器 ，也可以构建自己的平台登陆区域。 与合作伙伴代表一起确定设计方案和集成方案。 法规、安全要求和地缘政治条件可能会随时间而变化。 某些组织希望灵活地在主权公有云、主权私有云和国家合作伙伴云环境之间移动工作负载，而无需进行重大重新设计。 你目前做出的体系结构决策可能会影响未来迁移的成本、复杂性和可行性。 最大程度地减少特定于部署模型的依赖项。 尽可能使用常见的标识、治理和安全功能，例如Microsoft Entra ID、Azure RBAC 和Azure Policy。 选择计算和应用程序平台时，支持跨多个部署模型可用的技术，并且可以在不同的环境中一致地运行，例如虚拟机、容器和 Kubernetes。 虽然特定于部署模型的服务可以提供有价值的功能，但如果将来需求发生变化，它们也可以增加迁移工作量。 最大程度地减少特定于部署模型的依赖项。 尽可能使用常见的标识、治理和安全功能，例如Microsoft Entra ID、Azure RBAC 和Azure Policy。 选择计算和应用程序平台时，支持跨多个部署模型可用的技术，并且可以在不同的环境中一致地运行，例如虚拟机、容器和 Kubernetes。 虽然特定于部署模型的服务可以提供有价值的功能，但如果将来需求发生变化，它们也可以增加迁移工作量。 验证目标平台支持情况。 在采用服务或平台功能之前，请验证工作负荷可能需要运行的每个部署模型中是否存在等效的功能。 服务可用性因主权公有云、主权私有云、Azure Local（已连接和断开连接）和国家合作伙伴云而异。 验证目标平台支持情况。 在采用服务或平台功能之前，请验证工作负荷可能需要运行的每个部署模型中是否存在等效的功能。 服务可用性因主权公有云、主权私有云、Azure Local（已连接和断开连接）和国家合作伙伴云而异。 想要尝试使用 Ask Learn 阐明或指导你完成本主题？ Last updated on 2026-09-04