Azure 登陆区域中的基线 Azure AI Foundry 聊天参考体系结构

Azure OpenAI 服务

Azure AI 服务

Azure 应用程序服务

Azure Key Vault

Azure Monitor

本文是基于 基线 AI Foundry 聊天参考体系结构构建的系列教程的一部分。 查看基线体系结构，以便在 Azure 应用程序登陆区域订阅中部署之前确定必要的调整。

本文介绍一个生成式 AI 工作负载体系结构，该体系结构部署基线聊天应用程序，但使用工作负荷团队范围之外的资源。 平台团队集中管理资源，多个工作负荷团队使用这些资源。 共享资源包括用于跨界连接的网络资源、标识访问管理系统和策略。 本指南可帮助使用 Azure 登陆区域的组织保持一致的治理和成本效益。

Azure AI Foundry 使用帐户和项目来组织 AI 开发和部署。 例如，登陆区域实现可能使用帐户作为业务组级别的集中式资源，并将项目用作该业务组中每个工作负荷的委托资源。 由于资源组织因素和成本分配限制，我们不建议使用此拓扑，本文不提供相关指导。 相反，此体系结构会将工作负荷视为 Azure AI Foundry 实例的所有者，这是建议的方法。

作为工作负荷所有者，你可以将共享资源管理委托给平台团队，以便专注于工作负荷开发工作。 本文介绍工作负荷团队的观点，并指定平台团队的建议。

重要

什么是 Azure 登陆区域？

Azure 登陆区域将组织的云占用量划分为两个关键领域：

• 应用程序登陆区域是运行工作负荷的 Azure 订阅。 应用程序登陆区域连接到组织的共享平台资源。 该连接为登陆区域提供对支持工作负荷的基础结构的访问权限，例如网络、标识访问管理、策略和监视。

• 平台登陆区域是多个平台团队可以管理的各种订阅的集合。 每个订阅都有特定的功能。 例如，连接订阅为平台团队提供集中式域名系统（DNS）解析、跨界连接和网络虚拟设备（NVA）。

为了帮助你实现此体系结构，请了解 Azure 登陆区域、其 设计原则及其 设计领域。

文章布局

建筑	设计决策	Azure Well-Architected Framework 方法
▪ 体系结构图 ▪ 工作负荷资源 ▪ 联合资源	▪ 订阅设置 ▪ 网络 ▪ 数据科学家访问 ▪ 监视资源 ▪ 组织治理 ▪ 变更管理	▪ 可靠性 ▪ 安全性 ▪ 成本优化 ▪ 卓越运营 ▪ 性能效率

小窍门

Azure AI Foundry 代理服务聊天基线参考实现演示了本文中所述的最佳做法。 在选择和实施设计决策之前，请查看并试用这些部署资源。

建筑

此体系结构关系图包含两个主要部分。 顶部蓝色部分标记为应用程序登陆区域订阅。 底部黄色部分标记为平台登陆区域订阅。 顶部框包含工作负荷创建的资源和订阅售货资源。 工作负荷资源包括 Azure 应用程序网关和 Azure Web 应用程序防火墙、应用服务及其集成子网，以及平台即服务解决方案（PaaS）解决方案（例如 Azure 存储、Azure Key Vault、Azure AI 搜索、Azure AI Foundry、Azure Cosmos DB 和 Azure 存储）的专用终结点。 工作负荷资源还具有具有 Foundry 代理服务和监视资源的 Azure AI Foundry 项目。 应用服务在不同的 Azure 区域中有三个实例。 平台订阅包含中心虚拟网络、Azure 防火墙、Azure Bastion 和灰显的 Azure VPN 网关和 Azure ExpressRoute。 应用程序登陆区域中的辐射虚拟网络和中心虚拟网络通过虚拟网络对等互连进行连接。 受控出口流量从应用程序登陆区域进入平台登陆区域中的 Azure 防火墙。 流从应用服务到应用服务集成子网、专用终结点，再到专用终结点的服务。

下载此体系结构的 Visio 文件。

组件

所有 Azure 登陆区域体系结构在平台团队和工作负荷团队之间分离所有权，称为 订阅民主化。 应用程序架构师、数据科学家和 DevOps 团队必须清楚地了解此部门，以确定其直接影响或控制下哪些内容，以及哪些内容不受影响。

与大多数应用程序登陆区域实现一样，工作负荷团队主要管理工作负荷组件的配置、部署和监督，包括此体系结构中的 AI 服务。

工作负荷团队拥有的资源

以下资源与基线体系结构基本保持不变。

• Azure AI Foundry 帐户和项目 使工作负荷团队能够将生成 AI 模型托管为服务、实现内容安全，并建立与知识源和工具的特定于工作负载的连接。

  如果组织的 AI 卓越中心限制对 AI 模型部署的访问，则工作负荷团队可能不会在项目和帐户中托管模型。 相反，他们可能需要使用 集中式 AI 资源。 在此方案中，所有模型消耗通常都流经 AI 平台团队提供的网关。

  本文假定此方案中的生成 AI 模型是工作负荷拥有的资源。 如果不是模型，则模型主机或模型网关将成为工作负荷依赖项。 平台团队必须保持与 API 的可靠网络连接。

  Foundry 代理服务以特定方式处理模型依赖项，因此在使用集中托管的模型时可能会出现挑战。 可能需要使用备用业务流程协调程序。

• Foundry 代理服务 为聊天交互提供业务流程层。 它托管和管理处理用户请求的聊天代理。

  使用此体系结构中的 标准代理设置 。 将代理连接到辐射虚拟网络中的专用子网，并通过连接订阅路由出口流量。

  工作负荷团队为代理状态、聊天历史记录和文件存储提供专用 Azure 资源。 这些资源是用于 NoSQL、Azure 存储和Azure AI 搜索的 Azure Cosmos DB。 Foundry 代理服务实例以独占方式管理这些资源及其数据。 工作负荷中的其他应用程序组件或组织中的其他工作负荷不应使用它们。

• Azure 应用服务 托管包含聊天用户界面（UI）的 Web 应用程序。 应用服务在不同的 Azure 区域中有三个实例。

  Azure 存储帐户将 Web 应用程序的代码托管为 ZIP 文件，该文件装载在应用服务中。

• AI 搜索 检索应用程序用户查询的相关索引数据。 AI 搜索充当 “检索扩充生成”模式的工作负载知识存储。 此模式从提示中提取适当的查询，查询 AI 搜索，并使用结果作为生成 AI 基础模型的基础数据。

• Azure 应用程序网关 充当反向代理，用于将用户请求路由到应用服务中托管的聊天 UI。 所选 SKU 还托管 Azure Web 应用程序防火墙，以保护前端应用程序免受潜在恶意流量的影响。

  Azure Key Vault 存储应用程序网关的传输层安全性（TLS）证书。

• Azure Monitor、Azure Monitor 日志和 Application Insights 收集、存储和可视化可观测性数据。

• Azure Policy 应用特定于工作负荷的策略，以帮助大规模控制、保护和应用控制。

工作负荷团队还维护以下资源：

• 这些子网上的辐射虚拟网络子网和网络安全组（NSG）会保持分段和控制流量流。

• 专用终结点 可安全连接到平台即服务（PaaS）解决方案。

平台团队拥有的资源

平台团队拥有和维护以下集中资源。 此体系结构假定这些资源是预先预配的，并将它们视为依赖项。

• 中心网络路由中的 Azure 防火墙 、检查和限制源自工作负荷的出口流量，包括代理流量。 工作负荷出口流量将发送到 Internet、跨界目标或其他应用程序登陆区域。

  从基线更改： 在基线体系结构中，工作负荷团队拥有此组件。 在此体系结构中，平台团队在连接订阅下对其进行管理。

• 中心网络中的 Azure Bastion 提供对工作负荷组件的安全作访问，并允许访问 Azure AI Foundry 组件。

  从基线更改： 在基线体系结构中，工作负荷团队拥有此组件。

• 分支虚拟网络是部署工作负荷的位置。

  从基线更改： 在基线体系结构中，工作负荷团队拥有此网络。

• 用户定义的路由（UDR） 强制隧道到中心网络。

  从基线更改： 在基线体系结构中，工作负荷团队拥有此网络。

• 基于 Azure Policy 的治理约束 和 DeployIfNotExists （DINE） 策略适用于工作负荷订阅。 可以在平台团队拥有的管理组级别或工作负荷的订阅中直接应用这些策略。

  从基线更改：这些策略刚纳入此体系结构中。 平台团队应用约束工作负荷的策略。 某些策略可能会复制现有工作负荷约束或引入新约束。

• 专用终结点的 Azure 专用 DNS 区域主机A记录。 有关详细信息，请参阅 Azure 专用链接和 DNS 大规模集成。

  从基线更改： 在基线体系结构中，工作负荷团队拥有此网络。 在此体系结构中，平台团队在连接订阅下管理此组件。

• DNS 解析服务 支持分支虚拟网络和跨界工作站。 此服务通常使用 Azure 防火墙作为 DNS 代理或 Azure DNS 专用解析程序。 在此体系结构中，该服务解析来自辐射的所有 DNS 请求的专用终结点 DNS 记录。 DNS 专用解析程序和链接规则集是平台团队启用此体系结构解析要求的建议方法，因为 Foundry 代理服务的 DNS 解析特征。

• Azure DDoS 防护 可帮助保护公共 IP 地址免受分布式攻击。

  从基线更改： 在基线体系结构中，工作负荷团队购买 DDoS 防护。

重要

Azure 登陆区域作为平台登陆区域订阅的一部分提供上述一些资源。 工作负荷订阅提供其他资源。 其中许多资源驻留在连接订阅中，其中包括 Azure ExpressRoute、Azure VPN 网关和 DNS 专用解析程序。 这些资源提供跨界访问和名称解析。 这些资源的管理不属于本文的范围。

订阅设置

工作负荷团队必须通知平台团队实施此体系结构的特定登陆区域要求。 平台团队必须将其要求传达给工作负荷团队。

例如，工作负荷团队必须提供有关所需网络空间的详细信息。 平台团队使用此信息来分配必要的资源。 工作负荷团队定义要求，平台团队在虚拟网络中分配适当的 IP 地址。

平台团队根据工作负荷的业务关键性和技术需求分配管理组。 例如，如果工作负荷向 Internet 公开（如此体系结构），则平台团队会选择适当的管理组。 为了建立治理，平台团队还配置并实现管理组。 工作负荷团队必须在此治理的约束内设计和作工作负荷。 有关典型管理组区别的详细信息，请参阅 定制 Azure 登陆区域体系结构。

平台团队为此体系结构设置订阅。 以下部分提供有关初始订阅设置的指导。

工作负荷要求和履行

工作负荷团队和平台团队必须协作处理管理组分配、Azure Policy 治理和网络设置等详细信息。 准备检查要求列表，以便与平台团队展开讨论和协商。 以下清单作为示例。

	设计注意事项	此体系结构的工作负荷要求
☐	辐射虚拟网络的数量及其大小： 平台团队创建并配置虚拟网络，然后将其对等互连到区域中心，将其指定为分支。 它们还需要确保网络能够适应未来的工作负荷增长。 为了有效执行这些任务，他们必须知道所需的辐射数。	在单个专用辐射虚拟网络中部署所有资源。 请求 /22 连续的地址空间以支持全面作和方案，例如并行部署。 以下因素决定了大多数 IP 地址需求： - 应用程序网关子网大小（固定大小）的要求。 - 具有 PaaS 服务的单个 IP 地址的专用终结点（固定大小）。 - 生成代理的子网大小（固定大小）。 - Foundry 代理服务需要前缀中的 /24 子网。
☐	虚拟网络地址前缀： 通常，平台团队根据现有约定、避免与对等网络重叠以及 IP 地址管理 （IPAM） 系统中的可用性分配 IP 地址。	代理集成子网必须使用以或172.此类192.开头192.168.45.1/24的地址前缀。 Foundry 代理服务功能主机中的运行时限制强制实施此要求。 Foundry 代理服务不支持使用 10.子网。 要求平台团队提供具有代理子网有效地址前缀的辐射。
☐	部署区域： 平台团队需要在与工作负荷资源相同的区域中部署中心。	为工作负荷和基础计算资源的区域传达所选区域。 确保区域支持可用性区域。 Foundry 模型中的 Azure OpenAI 具有有限的区域可用性。
☐	流量的类型、卷和模式： 平台团队需要确定工作负荷共享资源的入口和出口要求。	提供有关以下因素的信息： - 用户应如何使用此工作负荷。 - 此工作负荷如何使用其周围的资源。 - 配置的传输协议。 - 流量模式以及预期的高峰和非高峰时段。 当预期与 Internet 建立大量并发连接（聊天）时，以及工作负荷生成最小网络流量（后台干扰）时进行通信。
☐	防火墙配置： 平台团队需要设置规则，以允许合法的出口流量。	共享来自辐射网络的出站流量的详细信息，包括代理流量。 生成代理和跳转盒计算机需要常规的 OS 修补。 代理可能需要与工作负荷外部托管的 Internet 地面源、工具或其他代理进行交互。
☐	来自专用角色的入口流量： 平台团队需要为指定的角色提供对工作负荷的网络访问权限，并实施适当的分段。	请与平台团队协作，确定允许以下角色的授权访问的最佳方法： - 从企业网络连接上的工作站访问 Azure AI Foundry 门户的数据科学家和开发人员 - 通过工作负荷管理的跳转框访问计算层的运算符
☐	对工作负荷的公共 Internet 访问： 平台团队将此信息用于风险评估，从而推动多项决策： - 将工作负荷放置在具有适当防护措施的管理组中 - 工作负荷团队报告的公共 IP 地址的分布式拒绝服务 （DDoS） 保护 - TLS 证书采购和管理	告知平台团队入口流量配置文件： - 面向应用程序网关上的公共 IP 地址的 Internet 源流量 - 与 TLS 证书采购的公共 IP 地址关联的完全限定域名（FQDN）
☐	专用终结点用法： 平台团队需要为专用终结点设置 Azure 专用 DNS 区域，并确保中心网络中的防火墙能够正确执行 DNS 解析。	告知平台团队使用专用终结点的所有资源，包括以下资源： - AI 搜索 - 用于 NoSQL 的 Azure Cosmos DB - 密钥保管库 - Azure AI Foundry - 存储帐户 了解中心如何处理 DNS 解析，并定义工作负荷团队负责管理专用 DNS 区域记录和 DNS 专用解析程序规则集链接。
☐	集中式 AI 资源： 平台团队必须了解模型和托管平台的预期使用情况。 他们使用此信息将网络建立到组织内的集中式 AI 资源。 每个组织定义自己的 AI 采用和治理计划，工作负荷团队必须在这些约束内运行。	告知平台团队你计划使用的 AI 和机器学习资源。 此体系结构使用 Azure AI Foundry、Foundry 代理服务和 Azure AI Foundry 中托管的生成基础模型。 清楚地了解必须使用哪些集中式 AI 服务，以及这些依赖项如何影响工作负荷。

重要

平台团队应遵循订阅售货流程，该流程使用结构化问题集从工作负荷团队收集信息。 这些问题可能因组织而异，但目标是收集必要的输入，以有效实现订阅。 有关详细信息，请参阅订阅自动售货。

计算

业务流程层和聊天 UI 托管与 基线体系结构保持不变。

网络

在基线体系结构中，工作负荷在单个虚拟网络中预配。

从基线更改： 此体系结构将工作负荷划分为两个虚拟网络。 一个网络托管工作负荷组件。 另一个网络管理 Internet 和混合连接。 平台团队确定工作负荷的虚拟网络如何与组织更大的网络体系结构集成，该体系结构通常遵循中心辐射型拓扑。

此体系结构关系图包含一个顶部蓝色部分，标有应用程序登陆区域订阅，其中包含辐射虚拟网络。 虚拟网络包含六个子网。 子网标记为 snet-appGateway、snet-buildAgents、snet-jumpBoxes、snet-appServicePlan、snet-agentsEgress 和 snet-privateEndpoints。 snet-privateEndpoints 子网具有应用服务、Azure 存储、Key Vault、Azure AI Foundry、知识存储、Azure AI 搜索、Azure Cosmos DB 和其他 Azure 存储实例的专用终结点。 最后三个专用终结点标记为 Foundry 代理服务依赖项。 每个子网都有一个 NSG，除了 snet-appGateway 子网，还有一个转到中心的 UDR。 来自本地和本地用户的入口流量指向应用程序网关。 数据科学家用户连接标记为连接订阅的底部部分中的 VPN 网关或 ExpressRoute。 连接订阅包含用于专用链接、DNS 专用解析程序和 DDoS 保护的 DNS 专用区域。 连接订阅中的中心虚拟网络通过虚拟网络对等互连连接到辐射虚拟网络。 中心向辐射虚拟网络提供 DNS。

下载此体系结构的 Visio 文件。

• 中心虚拟网络： 此虚拟网络充当一个区域中心，其中包含与同一区域中的工作负荷资源通信的集中且通常共享的服务。 中心驻留在 连接订阅中。 平台团队拥有此网络中的资源。

• 辐射虚拟网络： 在此体系结构中，基线体系结构中的单个虚拟网络实质上将成为辐射虚拟网络。 平台团队将此辐射网络与中心网络对等互连。 它们拥有和管理辐射网络，包括其对等互连和 DNS 配置。 工作负荷团队拥有此网络中的资源，包括其子网。 此网络包含许多工作负荷资源。

由于这种管理和所有权划分，工作负荷团队必须清楚地 将工作负荷的要求传达 给平台团队。

重要

对于平台团队： 请勿将辐射网络直接对等互连到另一个辐射网络，除非工作负荷特别需要它。 这种做法可以保护工作负荷的分段目标。 你的团队必须促进所有可传递的虚拟网络连接。 但是，如果应用程序登陆区域团队使用自管理专用终结点直接连接其网络，则团队不会管理这些连接。

了解外部团队管理的工作负载资源。 例如，了解聊天代理与另一个团队管理的基础上下文向量数据库之间的网络连接。

虚拟网络子网

在分支虚拟网络中，根据工作负荷要求创建和分配子网。 若要提供分段，请应用限制进出子网的流量的控制。 此体系结构不会在 基线体系结构中的子网之外添加子网。 但是，网络体系结构不再需要 AzureBastionSubnet 或 AzureFirewallSubnet 子网，因为平台团队可能在其订阅中托管此功能。

在 Azure 登陆区域中部署工作负荷时，仍需实现网络控制。 你的组织可能会施加进一步的网络限制，以防止数据外泄，并确保中心安全运营中心和 IT 网络团队的可见性。

入口流量

入口流量流与基线体系结构保持不变。

管理与公共 Internet 流入工作负荷相关的资源。 例如，在此体系结构中，应用程序网关及其公共 IP 地址驻留在辐射网络中，而不是中心网络。 某些组织使用集中式外围网络（也称为外围网络、非军事区域和屏蔽子网）实现将面向入口的资源放置在连接订阅中。 与该特定拓扑的集成不属于本文的范围。

检查传入流量的替代方法

此体系结构不使用 Azure 防火墙来检查传入流量，但有时组织治理需要它。 在这些情况下，平台团队支持实现，为工作负荷团队提供额外的入侵检测和防护层。 此层有助于阻止不需要的入站流量。 若要支持此拓扑，此体系结构需要更多 UDR 配置。 有关详细信息，请参阅 使用 Azure 防火墙和应用程序网关的 Web 应用程序的零信任网络。

DNS 配置

在基线体系结构中，所有组件都直接使用 Azure DNS 进行 DNS 解析。

从基线更改： 在此体系结构中，中心通常有一个或多个 DNS 服务器执行 DNS 解析。 创建虚拟网络时，应已相应地设置虚拟网络上的 DNS 属性。 工作负荷团队不需要了解 DNS 服务的实现详细信息。

此体系结构通过以下方式使用 DNS 配置工作负荷组件。

组件	DNS 配置
应用程序网关	继承自虚拟网络
应用程序服务（聊天 UI）	继承自虚拟网络
AI 搜索	无法重写，使用 Azure DNS
Azure AI Foundry	无法重写，使用 Azure DNS
Foundry 代理服务	无法重写，使用 Azure DNS
Azure Cosmos DB	无法重写，使用 Azure DNS
Jump Box	继承自虚拟网络
生成代理	继承自虚拟网络

此体系结构不会为不启动出站通信的组件配置 DNS 设置。 这些组件不需要 DNS 解析。

此体系结构中的许多组件依赖于中心 DNS 服务器中托管的 DNS 记录来解析此工作负荷的专用终结点。 有关详细信息，请参阅 Azure 专用 DNS 区域。

如果无法进行基于中心的 DNS 解析，这些组件将面临以下限制：

• 平台团队无法记录 DNS 请求，这可能违反组织安全团队要求。

• 在登陆区域或其他应用程序登陆区域中解析专用链接公开的服务可能是不可能的。

建议熟悉平台团队如何管理 DNS。 有关详细信息，请参阅大规模专用链接和 DNS 集成。 添加直接依赖于 Azure DNS 的组件功能时，可能会在平台提供的 DNS 拓扑中引入复杂性。 可以重新设计组件或协商异常，以最大程度地降低复杂性。

出口流量

在基线体系结构中，所有出口流量通过 Azure 防火墙路由到 Internet。

从基线更改： 在此体系结构中，平台提供指向其托管的 Azure 防火墙实例的 UDR。 将此 UDR 应用于基线体系结构中的同一子网。

离开辐射虚拟网络的所有流量（包括来自代理集成子网的流量）通过出口防火墙通过对等中心网络重新路由。

此体系结构关系图的顶部蓝色部分标记为应用程序登陆区域订阅，并包含辐射虚拟网络。 辐射虚拟网络包含六个子网：snet-appGateway、snet-buildAgents、snet-jumpBoxes、snet-appServicePlan、snet-agentsEgress 和 snet-privateEndpoints。 snet-privateEndpoints 子网具有应用服务、Azure 存储、Key Vault、Azure AI Foundry、知识存储、AI 搜索、Azure Cosmos DB 和其他 Azure 存储实例的专用终结点。 最后三个专用终结点标记为 Foundry 代理服务依赖项。 除 snet-appGateway 之外的所有子网都有一条虚线到 Azure 防火墙，该行位于底部部分。 底部部分标记为“连接”订阅。 Azure 防火墙有一条虚线，它指向表示为云的 Internet。 顶部部分读取了可能时，所有工作负荷发起的 Internet 流量都流经中心，因为 UDR 为 0.0.0.0/0。 底部部分中的中心虚拟网络和顶部部分中的辐射虚拟网络通过虚拟网络对等互连进行连接。

下载此体系结构的 Visio 文件。

东西方客户端与 Key Vault、Azure AI Foundry 和其他服务的专用终结点通信与 基线体系结构相同。 上图不包含该路径。

将 Internet 流量路由到防火墙

辐射网络中的所有子网都包含将所有 Internet 绑定流量或 0.0.0.0/0 流量定向到中心的 Azure 防火墙实例的路由。

组件	通过中心强制 Internet 流量的机制
应用程序网关	没有。 源自此服务的 Internet 绑定流量无法通过平台团队的防火墙进行强制。
应用程序服务（聊天 UI）	区域虚拟网络集成 和 vnetRouteAllEnabled 设置已启用。
AI 搜索	没有。 源于该服务的流量无法强制通过防火墙。 此体系结构不使用技能。
Foundry 代理服务	应用于 snet-agentsEgress 子网的 UDR。
跳转框	应用于 snet-jumpbox 子网的 UDR。
生成代理	应用于 snet-agents 子网的 UDR。

此体系结构不会为不启动出站通信的组件配置强制隧道。

对于无法通过中心路由出口流量的组件或功能，工作负荷团队必须符合组织要求。 若要满足这些要求，请使用补偿控件、重新设计工作负载以排除不受支持的功能或请求正式异常。 你负责缓解数据外泄和滥用。

将平台提供的 Internet 路由应用到所有子网，即使你不希望子网有传出流量也是如此。 此方法可确保该子网中的意外部署通过例程出口筛选。 对于包含专用终结点的子网，启用网络策略以支持完整路由和 NSG 控制。

此路由配置可确保检查和控制来自应用服务、Azure AI Foundry 及其项目的所有出站连接，以及源自工作负荷虚拟网络的任何其他服务。

Azure 专用 DNS 区域

使用专用终结点进行东西方流量的工作负荷需要在配置的 DNS 提供程序中记录 DNS 区域。 为了支持专用链接，此体系结构依赖于 Key Vault、Azure AI Foundry 和 Azure 存储等服务的许多 DNS 区域记录。

从基线更改： 在基线体系结构中，工作负荷团队直接管理专用 DNS 区域。 在此体系结构中，平台团队通常维护专用 DNS 区域。 工作负荷团队必须清楚地了解平台团队对专用 DNS 区域记录管理的要求和期望。 平台团队可以使用其他技术，而不是专用 DNS 区域记录。

在此体系结构中，平台团队必须为以下 Azure AI Foundry FQDN API 终结点设置 DNS：

• privatelink.services.ai.azure.com
• privatelink.openai.azure.com
• privatelink.cognitiveservices.azure.com

平台团队还必须为以下 FQDN 设置 DNS，这些 FQDN 是 Foundry 代理服务依赖项：

• privatelink.search.windows.net
• privatelink.blob.core.windows.net
• privatelink.documents.azure.com

重要

在为 Foundry 代理服务部署功能主机并在 Foundry 代理服务作期间，DNS 解析必须从分支虚拟中正常运行。 Foundry 代理服务功能不使用辐射虚拟网络的 DNS 配置。 因此，建议平台团队在 DNS 专用解析程序中为工作负荷的专用 DNS 区域配置规则集，并将这些规则链接到应用程序登陆区域分支。

在部署 Azure AI Foundry 及其代理功能之前，必须等待，直到 Foundry 代理服务依赖项完全可从辐射网络内部解析到其专用终结点。 如果 DINE 策略处理 DNS 专用区域的更新，则此要求尤其重要。 如果在可从子网中解析专用 DNS 记录之前尝试部署 Foundry 代理服务功能，则部署将失败。

平台团队还必须在此体系结构中托管专用 DNS 区域以用于其他工作负荷依赖项：

• privatelink.vaultcore.azure.net
• privatelink.azurewebsites.net

数据科学家和代理开发人员访问权限

与 基线体系结构一样，此体系结构禁用对 Azure AI Foundry 门户和其他基于浏览器的体验的公共入口访问。 基线体系结构部署跳转盒，以便为浏览器提供来自各种工作负荷角色使用的虚拟网络中的源 IP 地址。

当工作负荷连接到 Azure 登陆区域时，团队将获得更多访问选项。 请与平台团队协作，了解是否可以在管理和管理虚拟机（VM）的情况下访问各种基于浏览器的 Azure AI Foundry 门户。 可以通过来自现有 ExpressRoute 或 VPN 网关连接的可传递路由进行此访问。

基于本机工作站的访问需要跨界路由和 DNS 解析，平台团队可以帮助提供这些解决方案。 在订阅自动售货请求中包含此要求。

提供基于工作站的本机门户访问权限可提高工作效率，并简化与管理 VM 跳转框相比的维护。

跳转盒角色

此体系结构中的跳转盒为运营支持提供价值，不适用于运行时目的或 AI 和机器学习开发。 跳转盒可以排查 DNS 和网络路由问题，因为它提供对外部不可访问组件的内部网络访问。

在基线体系结构中，Azure Bastion 访问所管理的跳转框。

在此体系结构中，Azure Bastion 部署在连接订阅中，作为平台团队管理的共享区域资源。 为了演示此体系结构中的用例，Azure Bastion 位于连接订阅中，团队不会部署它。

充当跳转盒的 VM 必须符合 VM 的组织要求。 这些要求可能包括 Microsoft Entra ID 中的公司标识、特定基础映像和修补制度等项。

监视资源

Azure 登陆区域平台在管理订阅中提供共享的可观测性资源。 但是，我们建议预配自己的监视资源，以促进工作负荷的所有权责任。 此方法与 基线体系结构保持一致。

预配以下监视资源：

• Application Insights 充当团队的应用程序性能管理（APM）服务。 可以在聊天 UI、Foundry 代理服务和模型中配置此服务。

• Azure Monitor 日志工作区充当工作负荷拥有的 Azure 资源中的所有日志和指标的统一接收器。

与基线体系结构类似，所有资源都必须将 Azure 诊断日志发送到团队预配的 Azure Monitor 日志工作区。 此配置是基础结构（IaC）部署资源的一部分。 可能还需要将日志发送到中央 Azure Monitor 日志工作区。 在 Azure 登陆区域中，该工作区通常驻留在管理订阅中。

平台团队可能有更多的进程影响应用程序登陆区域中的资源。 例如，他们可能使用 DINE 策略来配置诊断并将日志发送到集中式管理订阅。 他们还可以通过策略应用 Azure Monitor 基线警报 。 确保实现不会阻止这些额外的日志记录和警报流。

Azure Policy

基线体系结构建议 使用常规策略 来帮助控制工作负荷。 将此体系结构部署到应用程序登陆区域时，无需添加或删除额外的策略。 为了帮助强制实施治理并增强此工作负荷的安全性，请继续将策略应用到订阅、资源组或资源。

即使部署工作负荷之前，应用程序登陆区域订阅仍具有现有策略。 某些策略通过审核或阻止部署中的特定配置来帮助组织治理。

以下示例策略可能会导致工作负荷部署复杂性：

• Policy：Secrets [In Key Vault] 应具有指定的最长有效期。

  并发症： Azure AI Foundry 可以在连接的 Key Vault 中存储与知识和工具连接相关的机密。 这些机密没有服务设置的到期日期。 基线体系结构不使用这些类型的连接，但可以扩展体系结构以支持它们。

• Policy：AI 搜索服务应使用客户管理的密钥来加密静态数据。

  并发症： 此体系结构不需要客户管理的密钥。 但你可以扩展体系结构以支持它们。

• Policy：AI Foundry 模型不应为预览版。

  并发症： 在生产工作负荷中启用代理功能时，你可能正在使用预览模型进行开发。

平台团队可能会应用 DINE 策略来处理自动部署到应用程序登陆区域订阅中的问题。 预先将将平台发起的限制和更改纳入 IaC 模板中并进行测试。 如果平台团队使用与应用程序要求相冲突的 Azure 策略，可以协商解决。

管理随时间推移的变化

在此体系结构中，平台提供的服务和作充当外部依赖项。 平台团队继续应用更改、载入登陆区域并应用成本控制。 平台团队可能无法确定单个工作负荷的优先级。 对这些依赖项的更改（如防火墙修改）可能会影响多个工作负荷。

必须以高效且及时的方式与平台团队通信，以便管理所有外部依赖项。 事先测试更改非常重要，这样才不会对工作负荷产生负面影响。

影响工作负荷的平台更改

在此体系结构中，平台团队会管理以下资源。 对这些资源的更改可能会影响工作负荷的可靠性、安全性、操作和性能目标。 在平台团队实施这些更改之前评估这些更改，以确定它们如何影响工作负荷。

• Azure 策略：对 Azure 策略的更改可能会影响工作负荷资源及其依赖项。 这些更改可能包括直接策略更新或将登陆区域移动到新的管理组层次结构中。 在发生新部署之前，这些更改可能会被忽略，因此必须对其进行彻底测试。

  例： 策略不再允许部署需要客户管理的密钥加密的 Azure Cosmos DB 实例，体系结构使用Microsoft管理的密钥加密。

• 防火墙规则：对防火墙规则的修改可能会影响工作负荷的虚拟网络或应用于所有流量的规则。 这些修改可能会导致流量阻塞，甚至导致静默进程失败。 这些潜在问题既适用于出口防火墙，也适用于 Azure 虚拟网络管理器应用的 NSG 规则。

  例： 阻止到必应 API 的流量会导致 Internet 地面数据的代理工具调用失败。

• 中心网络的路由：如果工作负荷依赖于到其他虚拟网络的路由，中心内路由的可传递性变化可能会影响工作负荷的功能。

  例： 路由更改可防止 Azure AI Foundry 代理访问由另一个团队运营的矢量存储，或者阻止数据科学团队从其工作站访问 AI Foundry 门户。

• Azure Bastion 主机：对 Azure Bastion 主机可用性或配置的更改。

  示例：配置更改可防止访问跳转框和生成代理 VM。

影响平台的工作负荷更改

以下示例介绍应与平台团队通信的工作负荷更改。 平台团队必须针对新更改验证平台服务的可靠性、安全性、作和性能目标，然后才能生效。

• 网络出口：监视网络出口量的任何显著增加，以防止工作负荷成为网络设备上的干扰邻居。 此问题可能会影响其他工作负荷的性能或可靠性目标。 此体系结构大多是自包含的，不太可能在出站流量模式上发生重大变化。

• 公共访问： 对工作负荷组件的公共访问的更改可能需要额外的测试。 平台团队可能会将工作负荷重新定位到其他管理组。

  示例：在此体系结构中，如果从应用程序网关中删除公共 IP 地址，并且仅使此应用程序在内部，则工作负荷对 Internet 的曝光将发生变化。 另一个示例是向 Internet 公开基于浏览器的 AI 门户，我们不建议。

• 业务关键性评级： 对工作负荷服务级别协议（SLA）的更改可能需要平台和工作负荷团队之间采用新的协作方法。

  例： 工作负荷可能会因采用率增加和成功而严重地从低到高的业务过渡。

企业体系结构团队

某些组织有一个企业体系结构团队，可能会影响工作负荷及其体系结构的设计。 该团队了解企业的 AI 采用 策略以及 Azure 设计 AI 工作负载 中的原则和建议。 请与此团队协作，确保此聊天工作负载满足特定于方案的目标，并符合组织策略和建议。

注意事项

这些注意事项实施 Azure 架构良好的框架的支柱原则，即一套可用于改进工作负荷质量的指导原则。 有关详细信息，请参阅 Well-Architected Framework。

可靠性

可靠性有助于确保应用程序能够履行对客户的承诺。 有关详细信息，请参阅可靠性设计评审核对清单。

此体系结构维护 基线体系结构的可靠性保证。 它不会为核心工作负荷组件引入新的可靠性注意事项。

关键依赖项

将工作负荷在平台和应用程序登陆区域中执行的所有功能视为依赖项。 维护事件响应计划，其中包括每个依赖项的联系人方法和升级路径。 将这些依赖项包含在工作负荷的故障模式分析（FMA）中。

请考虑可能发生的以下工作负荷依赖项和示例方案：

• 出口防火墙： 集中式出口防火墙将发生与工作负荷无关的更改。 多个工作负荷共享防火墙。

• DNS 解析： 此体系结构使用平台团队为大多数资源提供的 DNS，并结合适用于 Foundry 代理服务的 Azure DNS 和链接的 DNS 专用解析程序规则集。 因此，工作负荷取决于对专用终结点的 DNS 记录的及时更新以及 DNS 服务的可用性。

• DINE 策略： Azure 专用 DNS 区域或任何其他平台提供的依赖项的 DINE 策略 以最佳方式 运行，不包括 SLA。 例如，此体系结构专用终结点的 DNS 配置延迟可以防止聊天 UI 成为流量就绪或阻止代理完成 Foundry 代理服务查询。

• 管理组策略： 环境之间的一致策略支持可靠性。 确保预生产环境与生产环境匹配，以提供准确的测试和防止特定于环境的偏差，从而阻止部署或缩放。 有关详细信息，请参阅管理 Azure 登陆区域中的应用程序开发环境。

其中许多注意事项可能不存在于没有 Azure 登陆区域。 你需要与平台团队协作解决这些问题，并确保满足所有要求。 有关详细信息，请参阅 “标识依赖项”。

安全性

安全性提供针对故意攻击和滥用宝贵数据和系统的保证。 有关详细信息，请参阅可靠性设计审查检查表。

入口流量控制

若要将工作负荷与组织中的其他工作负荷辐射区隔离，请在子网上应用 NSG，并在区域中心使用非传输性质或控制。 构建仅允许应用程序及其基础结构的入站网络要求的全面 NSG。 我们建议不要只依赖中心网络的非传输性质来确保安全性。

平台团队实现 Azure 策略的安全性。 例如，策略可以确保应用程序网关具有设置为拒绝模式的 Web 应用程序防火墙，这会限制订阅可用的公共 IP 地址数。 除了这些策略，还应部署更多以工作负荷为中心的策略，以增强入口安全态势。

下表显示了此体系结构中的入口控制示例。

来源	目的	工作负荷控制	平台控制
Internet	应用程序流量流	在允许公共流量转换到聊天 UI 的专用流量之前，通过 NSG、Web 应用程序防火墙和路由规则将所有工作负荷请求漏斗。	没有
Internet	Azure AI Foundry 门户访问和数据平面 REST API 访问	通过服务级别配置拒绝所有访问。	没有
Internet	对除应用程序网关以外的所有服务的数据平面访问	通过 NSG 规则和服务级别配置拒绝所有访问。	没有
Azure Bastion	跳转框和生成代理访问权限	在跳转盒子网上应用 NSG，该子网阻止所有流量到远程访问端口，除非源是平台指定的 Azure Bastion 子网。	没有
跨界	Azure AI Foundry 门户访问和数据平面 REST API 访问	拒绝所有访问。 如果不使用跳转框，则仅允许从授权子网中的工作站访问数据科学家。	在 Azure 虚拟 WAN 安全中心强制实施非传输路由或使用 Azure 防火墙
其他分支	没有	通过 NSG 规则阻止。	在虚拟 WAN 安全中心强制实施非传输路由或使用 Azure 防火墙

出口流量控制

应用 NSG 规则来表达解决方案所需的出站连接要求并拒绝其他所有要求。 不要只依赖于中心网络控制。 作为工作负荷作员，必须尽可能停止靠近源的意外出口流量。

在虚拟网络中拥有工作负荷的子网，但平台团队可能会创建防火墙规则，专门表示在订阅售货过程中捕获的要求。 确保体系结构生存期内子网和资源放置更改与原始请求保持兼容。 与网络团队合作，确保最低访问权限出口控制的连续性。

下表显示了此体系结构中的出口控件示例。

端点	目的	工作负荷控制	平台控制
公共 Internet 源	代理可能需要 Internet 搜索才能在 Foundry Models 请求中建立 Azure OpenAI	在代理集成子网上应用 NSG	为外部知识存储和工具应用防火墙应用程序规则
Azure AI Foundry 数据平面	聊天 UI 与聊天代理交互	允许从应用服务集成子网到 Azure AI Foundry 专用终结点子网的 TCP/443	没有
Azure Cosmos DB	从 Foundry 代理服务访问内存数据库	允许每个端口上的 TCP 连接到 Azure Cosmos DB 专用终结点子网	没有

对于离开工作负荷虚拟网络的流量，此体系结构通过 NSG 在工作负荷级别应用控制，并通过中心网络防火墙在平台级别应用控制。 NSG 提供初始、广泛的网络流量规则。 在平台的中心，防火墙会应用更具体的规则来增强安全性。

此体系结构不需要内部组件（如 Foundry 代理服务及其依赖的 AI 搜索实例）之间的东西向流量通过中心网络进行路由。

DDoS 保护

确定谁应应用涵盖解决方案的公共 IP 地址的 DDoS 防护计划。 平台团队可能会使用 IP 地址保护计划，或者他们可能会使用 Azure Policy 强制实施虚拟网络保护计划。 此体系结构需要 DDoS 防护覆盖范围，因为它具有从 Internet 入口的公共 IP 地址。 有关详细信息，请参阅关于网络和连接的建议。

标识和访问管理

除非平台团队的治理自动化需要额外的控制，否则由于平台团队的参与，此体系结构不会引入新的授权要求。 Azure 基于角色的访问控制（RBAC）应继续履行最低特权原则，仅向需要权限的个人授予有限访问权限，并且仅在需要时授予访问权限。 有关详细信息，请参阅标识和访问管理建议。

证书和加密

你的团队通常会为应用程序网关上的公共 IP 地址采购 TLS 证书。 与平台团队合作，了解证书采购和管理流程应如何与组织期望保持一致。

此体系结构中的所有数据存储服务都支持Microsoft托管或客户管理的加密密钥。 如果工作负荷设计或组织需要更多控制，请使用客户管理的加密密钥。 Azure 登陆区域本身不要求使用特定方法。

成本优化

成本优化侧重于减少不必要的开支和提高运营效率的方法。 有关详细信息，请参阅成本优化设计评审核对清单。

基线体系结构中的所有成本优化策略都适用于此体系结构中的工作负荷资源。

此体系结构极大地受益于 Azure 登陆区域平台资源。 例如，Azure 防火墙和 DDoS 防护等资源从工作负荷过渡到平台资源。 即使通过退款模型使用这些资源，添加的安全性和跨界连接比自行管理这些资源更具成本效益。 利用平台团队提供的其他集中式产品/服务，将这些优势扩展到工作负载，而不会影响其服务级别目标、恢复时间目标或恢复点目标。

重要

不要尝试通过将 Azure AI Foundry 依赖项合并为平台资源来优化成本。 这些服务必须保留工作负荷资源。

卓越运营

卓越运营涵盖了部署应用程序并使其在生产环境中保持运行的运营流程。 有关详细信息，请参阅设计卓越运营的审查清单。

你仍负责 基线体系结构中的所有卓越运营注意事项。 这些职责包括监视、GenAIOps、质量保证和安全部署实践。

关联来自多个接收器的数据

工作负荷的 Azure Monitor 日志工作区存储工作负荷的日志和指标及其基础结构组件。 但是，中心 Azure Monitor 日志工作区通常存储集中服务的日志和指标，例如 Azure 防火墙、DNS 专用解析程序和 Azure Bastion。 关联来自多个接收器的数据可能是一项复杂的任务。

相关数据有助于支持事件响应。 此体系结构的会审 Runbook 应解决这种情况，如果问题超出工作负荷资源，则包括组织联系信息。 工作负荷管理员可能需要平台管理员的帮助来关联来自企业网络、安全或其他平台服务的日志条目。

重要

对于平台团队： 如果可能，请授予 RBAC 权限，以查询和读取相关平台资源的日志接收器。 为网络和应用程序规则评估和 DNS 代理启用防火墙日志。 应用程序团队可以使用此信息对任务进行故障排除。 有关详细信息，请参阅监视和威胁检测建议。

生成代理

此体系结构中的许多服务都使用专用终结点。 与基线体系结构类似，此设计可能需要生成代理。 你的团队可安全可靠地部署生成代理。 平台团队不参与此过程。

确保生成代理管理符合组织标准。 这些标准可能包括使用平台批准的作系统映像、修补计划、合规性报告和用户身份验证方法。

性能效率

性能效率是指工作负荷能够高效地缩放以满足用户需求。 有关详细信息，请参阅性能效率设计评审核对清单。

基线体系结构中的性能效率注意事项也适用于此体系结构。 你的团队将控制应用程序流中的资源，而不是平台团队。 根据工作负荷和成本约束缩放聊天 UI 主机、语言模型和其他组件。 根据体系结构的最终实现，根据性能目标衡量性能时，请考虑以下因素：

• 出口和跨界延迟
• 成本包含治理的 SKU 限制

部署此方案

部署此参考体系结构的登陆区域实现。

Foundry 代理服务聊天基线参考实现

供稿人

Microsoft维护本文。 以下参与者撰写了本文。

主要作者：

• 比拉尔·阿姆贾德 |Microsoft云解决方案架构师
• Freddy Ayala | Microsoft 云解决方案架构师
• 查德·基特尔 |首席软件工程师 - Azure 模式和做法

若要查看非公开的LinkedIn个人资料，请登录LinkedIn。

后续步骤

了解如何与平台团队协作处理技术详细信息。

订阅销售

相关资源

• 有关 Azure 上的 AI 工作负荷的 Well-Architected 框架视角

本文是基于 基线 AI Foundry 聊天参考体系结构构建的系列教程的一部分。 查看基线体系结构，以便在 Azure 应用程序登陆区域订阅中部署之前确定必要的调整。

本文介绍一个生成式 AI 工作负载体系结构，该体系结构部署基线聊天应用程序，但使用工作负荷团队范围之外的资源。 平台团队集中管理资源，多个工作负荷团队使用这些资源。 共享资源包括用于跨界连接的网络资源、标识访问管理系统和策略。 本指南可帮助使用 Azure 登陆区域的组织保持一致的治理和成本效益。

Azure AI Foundry 使用帐户和项目来组织 AI 开发和部署。 例如，登陆区域实现可能使用帐户作为业务组级别的集中式资源，并将项目用作该业务组中每个工作负荷的委托资源。 由于资源组织因素和成本分配限制，我们不建议使用此拓扑，本文不提供相关指导。 相反，此体系结构会将工作负荷视为 Azure AI Foundry 实例的所有者，这是建议的方法。

作为工作负荷所有者，你可以将共享资源管理委托给平台团队，以便专注于工作负荷开发工作。 本文介绍工作负荷团队的观点，并指定平台团队的建议。

重要

什么是 Azure 登陆区域？

Azure 登陆区域将组织的云占用量划分为两个关键领域：

• 应用程序登陆区域是运行工作负荷的 Azure 订阅。 应用程序登陆区域连接到组织的共享平台资源。 该连接为登陆区域提供对支持工作负荷的基础结构的访问权限，例如网络、标识访问管理、策略和监视。

• 平台登陆区域是多个平台团队可以管理的各种订阅的集合。 每个订阅都有特定的功能。 例如，连接订阅为平台团队提供集中式域名系统（DNS）解析、跨界连接和网络虚拟设备（NVA）。

为了帮助你实现此体系结构，请了解 Azure 登陆区域、其 设计原则及其 设计领域。

文章布局

建筑	设计决策	Azure Well-Architected Framework 方法
▪ 体系结构图 ▪ 工作负荷资源 ▪ 联合资源	▪ 订阅设置 ▪ 网络 ▪ 数据科学家访问 ▪ 监视资源 ▪ 组织治理 ▪ 变更管理	▪ 可靠性 ▪ 安全性 ▪ 成本优化 ▪ 卓越运营 ▪ 性能效率

小窍门

Azure AI Foundry 代理服务聊天基线参考实现演示了本文中所述的最佳做法。 在选择和实施设计决策之前，请查看并试用这些部署资源。

建筑

此体系结构关系图包含两个主要部分。 顶部蓝色部分标记为应用程序登陆区域订阅。 底部黄色部分标记为平台登陆区域订阅。 顶部框包含工作负荷创建的资源和订阅售货资源。 工作负荷资源包括 Azure 应用程序网关和 Azure Web 应用程序防火墙、应用服务及其集成子网，以及平台即服务解决方案（PaaS）解决方案（例如 Azure 存储、Azure Key Vault、Azure AI 搜索、Azure AI Foundry、Azure Cosmos DB 和 Azure 存储）的专用终结点。 工作负荷资源还具有具有 Foundry 代理服务和监视资源的 Azure AI Foundry 项目。 应用服务在不同的 Azure 区域中有三个实例。 平台订阅包含中心虚拟网络、Azure 防火墙、Azure Bastion 和灰显的 Azure VPN 网关和 Azure ExpressRoute。 应用程序登陆区域中的辐射虚拟网络和中心虚拟网络通过虚拟网络对等互连进行连接。 受控出口流量从应用程序登陆区域进入平台登陆区域中的 Azure 防火墙。 流从应用服务到应用服务集成子网、专用终结点，再到专用终结点的服务。

下载此体系结构的 Visio 文件。

组件

所有 Azure 登陆区域体系结构在平台团队和工作负荷团队之间分离所有权，称为 订阅民主化。 应用程序架构师、数据科学家和 DevOps 团队必须清楚地了解此部门，以确定其直接影响或控制下哪些内容，以及哪些内容不受影响。

与大多数应用程序登陆区域实现一样，工作负荷团队主要管理工作负荷组件的配置、部署和监督，包括此体系结构中的 AI 服务。

工作负荷团队拥有的资源

以下资源与基线体系结构基本保持不变。

• Azure AI Foundry 帐户和项目 使工作负荷团队能够将生成 AI 模型托管为服务、实现内容安全，并建立与知识源和工具的特定于工作负载的连接。

  如果组织的 AI 卓越中心限制对 AI 模型部署的访问，则工作负荷团队可能不会在项目和帐户中托管模型。 相反，他们可能需要使用 集中式 AI 资源。 在此方案中，所有模型消耗通常都流经 AI 平台团队提供的网关。

  本文假定此方案中的生成 AI 模型是工作负荷拥有的资源。 如果不是模型，则模型主机或模型网关将成为工作负荷依赖项。 平台团队必须保持与 API 的可靠网络连接。

  Foundry 代理服务以特定方式处理模型依赖项，因此在使用集中托管的模型时可能会出现挑战。 可能需要使用备用业务流程协调程序。

• Foundry 代理服务 为聊天交互提供业务流程层。 它托管和管理处理用户请求的聊天代理。

  使用此体系结构中的 标准代理设置 。 将代理连接到辐射虚拟网络中的专用子网，并通过连接订阅路由出口流量。

  工作负荷团队为代理状态、聊天历史记录和文件存储提供专用 Azure 资源。 这些资源是用于 NoSQL、Azure 存储和Azure AI 搜索的 Azure Cosmos DB。 Foundry 代理服务实例以独占方式管理这些资源及其数据。 工作负荷中的其他应用程序组件或组织中的其他工作负荷不应使用它们。

• Azure 应用服务 托管包含聊天用户界面（UI）的 Web 应用程序。 应用服务在不同的 Azure 区域中有三个实例。

  Azure 存储帐户将 Web 应用程序的代码托管为 ZIP 文件，该文件装载在应用服务中。

• AI 搜索 检索应用程序用户查询的相关索引数据。 AI 搜索充当 “检索扩充生成”模式的工作负载知识存储。 此模式从提示中提取适当的查询，查询 AI 搜索，并使用结果作为生成 AI 基础模型的基础数据。

• Azure 应用程序网关 充当反向代理，用于将用户请求路由到应用服务中托管的聊天 UI。 所选 SKU 还托管 Azure Web 应用程序防火墙，以保护前端应用程序免受潜在恶意流量的影响。

  Azure Key Vault 存储应用程序网关的传输层安全性（TLS）证书。

• Azure Monitor、Azure Monitor 日志和 Application Insights 收集、存储和可视化可观测性数据。

• Azure Policy 应用特定于工作负荷的策略，以帮助大规模控制、保护和应用控制。

工作负荷团队还维护以下资源：

• 这些子网上的辐射虚拟网络子网和网络安全组（NSG）会保持分段和控制流量流。

• 专用终结点 可安全连接到平台即服务（PaaS）解决方案。

平台团队拥有的资源

平台团队拥有和维护以下集中资源。 此体系结构假定这些资源是预先预配的，并将它们视为依赖项。

• 中心网络路由中的 Azure 防火墙 、检查和限制源自工作负荷的出口流量，包括代理流量。 工作负荷出口流量将发送到 Internet、跨界目标或其他应用程序登陆区域。

  从基线更改： 在基线体系结构中，工作负荷团队拥有此组件。 在此体系结构中，平台团队在连接订阅下对其进行管理。

• 中心网络中的 Azure Bastion 提供对工作负荷组件的安全作访问，并允许访问 Azure AI Foundry 组件。

  从基线更改： 在基线体系结构中，工作负荷团队拥有此组件。

• 分支虚拟网络是部署工作负荷的位置。

  从基线更改： 在基线体系结构中，工作负荷团队拥有此网络。

• 用户定义的路由（UDR） 强制隧道到中心网络。

  从基线更改： 在基线体系结构中，工作负荷团队拥有此网络。

• 基于 Azure Policy 的治理约束 和 DeployIfNotExists （DINE） 策略适用于工作负荷订阅。 可以在平台团队拥有的管理组级别或工作负荷的订阅中直接应用这些策略。

  从基线更改：这些策略刚纳入此体系结构中。 平台团队应用约束工作负荷的策略。 某些策略可能会复制现有工作负荷约束或引入新约束。

• 专用终结点的 Azure 专用 DNS 区域主机A记录。 有关详细信息，请参阅 Azure 专用链接和 DNS 大规模集成。

  从基线更改： 在基线体系结构中，工作负荷团队拥有此网络。 在此体系结构中，平台团队在连接订阅下管理此组件。

• DNS 解析服务 支持分支虚拟网络和跨界工作站。 此服务通常使用 Azure 防火墙作为 DNS 代理或 Azure DNS 专用解析程序。 在此体系结构中，该服务解析来自辐射的所有 DNS 请求的专用终结点 DNS 记录。 DNS 专用解析程序和链接规则集是平台团队启用此体系结构解析要求的建议方法，因为 Foundry 代理服务的 DNS 解析特征。

• Azure DDoS 防护 可帮助保护公共 IP 地址免受分布式攻击。

  从基线更改： 在基线体系结构中，工作负荷团队购买 DDoS 防护。

重要

Azure 登陆区域作为平台登陆区域订阅的一部分提供上述一些资源。 工作负荷订阅提供其他资源。 其中许多资源驻留在连接订阅中，其中包括 Azure ExpressRoute、Azure VPN 网关和 DNS 专用解析程序。 这些资源提供跨界访问和名称解析。 这些资源的管理不属于本文的范围。

订阅设置

工作负荷团队必须通知平台团队实施此体系结构的特定登陆区域要求。 平台团队必须将其要求传达给工作负荷团队。

例如，工作负荷团队必须提供有关所需网络空间的详细信息。 平台团队使用此信息来分配必要的资源。 工作负荷团队定义要求，平台团队在虚拟网络中分配适当的 IP 地址。

平台团队根据工作负荷的业务关键性和技术需求分配管理组。 例如，如果工作负荷向 Internet 公开（如此体系结构），则平台团队会选择适当的管理组。 为了建立治理，平台团队还配置并实现管理组。 工作负荷团队必须在此治理的约束内设计和作工作负荷。 有关典型管理组区别的详细信息，请参阅 定制 Azure 登陆区域体系结构。

平台团队为此体系结构设置订阅。 以下部分提供有关初始订阅设置的指导。

工作负荷要求和履行

工作负荷团队和平台团队必须协作处理管理组分配、Azure Policy 治理和网络设置等详细信息。 准备检查要求列表，以便与平台团队展开讨论和协商。 以下清单作为示例。

	设计注意事项	此体系结构的工作负荷要求
☐	辐射虚拟网络的数量及其大小： 平台团队创建并配置虚拟网络，然后将其对等互连到区域中心，将其指定为分支。 它们还需要确保网络能够适应未来的工作负荷增长。 为了有效执行这些任务，他们必须知道所需的辐射数。	在单个专用辐射虚拟网络中部署所有资源。 请求 /22 连续的地址空间以支持全面作和方案，例如并行部署。 以下因素决定了大多数 IP 地址需求： - 应用程序网关子网大小（固定大小）的要求。 - 具有 PaaS 服务的单个 IP 地址的专用终结点（固定大小）。 - 生成代理的子网大小（固定大小）。 - Foundry 代理服务需要前缀中的 /24 子网。
☐	虚拟网络地址前缀： 通常，平台团队根据现有约定、避免与对等网络重叠以及 IP 地址管理 （IPAM） 系统中的可用性分配 IP 地址。	代理集成子网必须使用以或172.此类192.开头192.168.45.1/24的地址前缀。 Foundry 代理服务功能主机中的运行时限制强制实施此要求。 Foundry 代理服务不支持使用 10.子网。 要求平台团队提供具有代理子网有效地址前缀的辐射。
☐	部署区域： 平台团队需要在与工作负荷资源相同的区域中部署中心。	为工作负荷和基础计算资源的区域传达所选区域。 确保区域支持可用性区域。 Foundry 模型中的 Azure OpenAI 具有有限的区域可用性。
☐	流量的类型、卷和模式： 平台团队需要确定工作负荷共享资源的入口和出口要求。	提供有关以下因素的信息： - 用户应如何使用此工作负荷。 - 此工作负荷如何使用其周围的资源。 - 配置的传输协议。 - 流量模式以及预期的高峰和非高峰时段。 当预期与 Internet 建立大量并发连接（聊天）时，以及工作负荷生成最小网络流量（后台干扰）时进行通信。
☐	防火墙配置： 平台团队需要设置规则，以允许合法的出口流量。	共享来自辐射网络的出站流量的详细信息，包括代理流量。 生成代理和跳转盒计算机需要常规的 OS 修补。 代理可能需要与工作负荷外部托管的 Internet 地面源、工具或其他代理进行交互。
☐	来自专用角色的入口流量： 平台团队需要为指定的角色提供对工作负荷的网络访问权限，并实施适当的分段。	请与平台团队协作，确定允许以下角色的授权访问的最佳方法： - 从企业网络连接上的工作站访问 Azure AI Foundry 门户的数据科学家和开发人员 - 通过工作负荷管理的跳转框访问计算层的运算符
☐	对工作负荷的公共 Internet 访问： 平台团队将此信息用于风险评估，从而推动多项决策： - 将工作负荷放置在具有适当防护措施的管理组中 - 工作负荷团队报告的公共 IP 地址的分布式拒绝服务 （DDoS） 保护 - TLS 证书采购和管理	告知平台团队入口流量配置文件： - 面向应用程序网关上的公共 IP 地址的 Internet 源流量 - 与 TLS 证书采购的公共 IP 地址关联的完全限定域名（FQDN）
☐	专用终结点用法： 平台团队需要为专用终结点设置 Azure 专用 DNS 区域，并确保中心网络中的防火墙能够正确执行 DNS 解析。	告知平台团队使用专用终结点的所有资源，包括以下资源： - AI 搜索 - 用于 NoSQL 的 Azure Cosmos DB - 密钥保管库 - Azure AI Foundry - 存储帐户 了解中心如何处理 DNS 解析，并定义工作负荷团队负责管理专用 DNS 区域记录和 DNS 专用解析程序规则集链接。
☐	集中式 AI 资源： 平台团队必须了解模型和托管平台的预期使用情况。 他们使用此信息将网络建立到组织内的集中式 AI 资源。 每个组织定义自己的 AI 采用和治理计划，工作负荷团队必须在这些约束内运行。	告知平台团队你计划使用的 AI 和机器学习资源。 此体系结构使用 Azure AI Foundry、Foundry 代理服务和 Azure AI Foundry 中托管的生成基础模型。 清楚地了解必须使用哪些集中式 AI 服务，以及这些依赖项如何影响工作负荷。

重要

平台团队应遵循订阅售货流程，该流程使用结构化问题集从工作负荷团队收集信息。 这些问题可能因组织而异，但目标是收集必要的输入，以有效实现订阅。 有关详细信息，请参阅订阅自动售货。

计算

业务流程层和聊天 UI 托管与 基线体系结构保持不变。

网络

在基线体系结构中，工作负荷在单个虚拟网络中预配。

从基线更改： 此体系结构将工作负荷划分为两个虚拟网络。 一个网络托管工作负荷组件。 另一个网络管理 Internet 和混合连接。 平台团队确定工作负荷的虚拟网络如何与组织更大的网络体系结构集成，该体系结构通常遵循中心辐射型拓扑。

此体系结构关系图包含一个顶部蓝色部分，标有应用程序登陆区域订阅，其中包含辐射虚拟网络。 虚拟网络包含六个子网。 子网标记为 snet-appGateway、snet-buildAgents、snet-jumpBoxes、snet-appServicePlan、snet-agentsEgress 和 snet-privateEndpoints。 snet-privateEndpoints 子网具有应用服务、Azure 存储、Key Vault、Azure AI Foundry、知识存储、Azure AI 搜索、Azure Cosmos DB 和其他 Azure 存储实例的专用终结点。 最后三个专用终结点标记为 Foundry 代理服务依赖项。 每个子网都有一个 NSG，除了 snet-appGateway 子网，还有一个转到中心的 UDR。 来自本地和本地用户的入口流量指向应用程序网关。 数据科学家用户连接标记为连接订阅的底部部分中的 VPN 网关或 ExpressRoute。 连接订阅包含用于专用链接、DNS 专用解析程序和 DDoS 保护的 DNS 专用区域。 连接订阅中的中心虚拟网络通过虚拟网络对等互连连接到辐射虚拟网络。 中心向辐射虚拟网络提供 DNS。

下载此体系结构的 Visio 文件。

• 中心虚拟网络： 此虚拟网络充当一个区域中心，其中包含与同一区域中的工作负荷资源通信的集中且通常共享的服务。 中心驻留在 连接订阅中。 平台团队拥有此网络中的资源。

• 辐射虚拟网络： 在此体系结构中，基线体系结构中的单个虚拟网络实质上将成为辐射虚拟网络。 平台团队将此辐射网络与中心网络对等互连。 它们拥有和管理辐射网络，包括其对等互连和 DNS 配置。 工作负荷团队拥有此网络中的资源，包括其子网。 此网络包含许多工作负荷资源。

由于这种管理和所有权划分，工作负荷团队必须清楚地 将工作负荷的要求传达 给平台团队。

重要

对于平台团队： 请勿将辐射网络直接对等互连到另一个辐射网络，除非工作负荷特别需要它。 这种做法可以保护工作负荷的分段目标。 你的团队必须促进所有可传递的虚拟网络连接。 但是，如果应用程序登陆区域团队使用自管理专用终结点直接连接其网络，则团队不会管理这些连接。

了解外部团队管理的工作负载资源。 例如，了解聊天代理与另一个团队管理的基础上下文向量数据库之间的网络连接。

虚拟网络子网

在分支虚拟网络中，根据工作负荷要求创建和分配子网。 若要提供分段，请应用限制进出子网的流量的控制。 此体系结构不会在 基线体系结构中的子网之外添加子网。 但是，网络体系结构不再需要 AzureBastionSubnet 或 AzureFirewallSubnet 子网，因为平台团队可能在其订阅中托管此功能。

在 Azure 登陆区域中部署工作负荷时，仍需实现网络控制。 你的组织可能会施加进一步的网络限制，以防止数据外泄，并确保中心安全运营中心和 IT 网络团队的可见性。

入口流量

入口流量流与基线体系结构保持不变。

管理与公共 Internet 流入工作负荷相关的资源。 例如，在此体系结构中，应用程序网关及其公共 IP 地址驻留在辐射网络中，而不是中心网络。 某些组织使用集中式外围网络（也称为外围网络、非军事区域和屏蔽子网）实现将面向入口的资源放置在连接订阅中。 与该特定拓扑的集成不属于本文的范围。

检查传入流量的替代方法

此体系结构不使用 Azure 防火墙来检查传入流量，但有时组织治理需要它。 在这些情况下，平台团队支持实现，为工作负荷团队提供额外的入侵检测和防护层。 此层有助于阻止不需要的入站流量。 若要支持此拓扑，此体系结构需要更多 UDR 配置。 有关详细信息，请参阅 使用 Azure 防火墙和应用程序网关的 Web 应用程序的零信任网络。

DNS 配置

在基线体系结构中，所有组件都直接使用 Azure DNS 进行 DNS 解析。

从基线更改： 在此体系结构中，中心通常有一个或多个 DNS 服务器执行 DNS 解析。 创建虚拟网络时，应已相应地设置虚拟网络上的 DNS 属性。 工作负荷团队不需要了解 DNS 服务的实现详细信息。

此体系结构通过以下方式使用 DNS 配置工作负荷组件。

组件	DNS 配置
应用程序网关	继承自虚拟网络
应用程序服务（聊天 UI）	继承自虚拟网络
AI 搜索	无法重写，使用 Azure DNS
Azure AI Foundry	无法重写，使用 Azure DNS
Foundry 代理服务	无法重写，使用 Azure DNS
Azure Cosmos DB	无法重写，使用 Azure DNS
Jump Box	继承自虚拟网络
生成代理	继承自虚拟网络

此体系结构不会为不启动出站通信的组件配置 DNS 设置。 这些组件不需要 DNS 解析。

此体系结构中的许多组件依赖于中心 DNS 服务器中托管的 DNS 记录来解析此工作负荷的专用终结点。 有关详细信息，请参阅 Azure 专用 DNS 区域。

如果无法进行基于中心的 DNS 解析，这些组件将面临以下限制：

• 平台团队无法记录 DNS 请求，这可能违反组织安全团队要求。

• 在登陆区域或其他应用程序登陆区域中解析专用链接公开的服务可能是不可能的。

建议熟悉平台团队如何管理 DNS。 有关详细信息，请参阅大规模专用链接和 DNS 集成。 添加直接依赖于 Azure DNS 的组件功能时，可能会在平台提供的 DNS 拓扑中引入复杂性。 可以重新设计组件或协商异常，以最大程度地降低复杂性。

出口流量

在基线体系结构中，所有出口流量通过 Azure 防火墙路由到 Internet。

从基线更改： 在此体系结构中，平台提供指向其托管的 Azure 防火墙实例的 UDR。 将此 UDR 应用于基线体系结构中的同一子网。

离开辐射虚拟网络的所有流量（包括来自代理集成子网的流量）通过出口防火墙通过对等中心网络重新路由。

此体系结构关系图的顶部蓝色部分标记为应用程序登陆区域订阅，并包含辐射虚拟网络。 辐射虚拟网络包含六个子网：snet-appGateway、snet-buildAgents、snet-jumpBoxes、snet-appServicePlan、snet-agentsEgress 和 snet-privateEndpoints。 snet-privateEndpoints 子网具有应用服务、Azure 存储、Key Vault、Azure AI Foundry、知识存储、AI 搜索、Azure Cosmos DB 和其他 Azure 存储实例的专用终结点。 最后三个专用终结点标记为 Foundry 代理服务依赖项。 除 snet-appGateway 之外的所有子网都有一条虚线到 Azure 防火墙，该行位于底部部分。 底部部分标记为“连接”订阅。 Azure 防火墙有一条虚线，它指向表示为云的 Internet。 顶部部分读取了可能时，所有工作负荷发起的 Internet 流量都流经中心，因为 UDR 为 0.0.0.0/0。 底部部分中的中心虚拟网络和顶部部分中的辐射虚拟网络通过虚拟网络对等互连进行连接。

下载此体系结构的 Visio 文件。

东西方客户端与 Key Vault、Azure AI Foundry 和其他服务的专用终结点通信与 基线体系结构相同。 上图不包含该路径。

将 Internet 流量路由到防火墙

辐射网络中的所有子网都包含将所有 Internet 绑定流量或 0.0.0.0/0 流量定向到中心的 Azure 防火墙实例的路由。

组件	通过中心强制 Internet 流量的机制
应用程序网关	没有。 源自此服务的 Internet 绑定流量无法通过平台团队的防火墙进行强制。
应用程序服务（聊天 UI）	区域虚拟网络集成 和 vnetRouteAllEnabled 设置已启用。
AI 搜索	没有。 源于该服务的流量无法强制通过防火墙。 此体系结构不使用技能。
Foundry 代理服务	应用于 snet-agentsEgress 子网的 UDR。
跳转框	应用于 snet-jumpbox 子网的 UDR。
生成代理	应用于 snet-agents 子网的 UDR。

此体系结构不会为不启动出站通信的组件配置强制隧道。

对于无法通过中心路由出口流量的组件或功能，工作负荷团队必须符合组织要求。 若要满足这些要求，请使用补偿控件、重新设计工作负载以排除不受支持的功能或请求正式异常。 你负责缓解数据外泄和滥用。

将平台提供的 Internet 路由应用到所有子网，即使你不希望子网有传出流量也是如此。 此方法可确保该子网中的意外部署通过例程出口筛选。 对于包含专用终结点的子网，启用网络策略以支持完整路由和 NSG 控制。

此路由配置可确保检查和控制来自应用服务、Azure AI Foundry 及其项目的所有出站连接，以及源自工作负荷虚拟网络的任何其他服务。

Azure 专用 DNS 区域

使用专用终结点进行东西方流量的工作负荷需要在配置的 DNS 提供程序中记录 DNS 区域。 为了支持专用链接，此体系结构依赖于 Key Vault、Azure AI Foundry 和 Azure 存储等服务的许多 DNS 区域记录。

从基线更改： 在基线体系结构中，工作负荷团队直接管理专用 DNS 区域。 在此体系结构中，平台团队通常维护专用 DNS 区域。 工作负荷团队必须清楚地了解平台团队对专用 DNS 区域记录管理的要求和期望。 平台团队可以使用其他技术，而不是专用 DNS 区域记录。

在此体系结构中，平台团队必须为以下 Azure AI Foundry FQDN API 终结点设置 DNS：

• privatelink.services.ai.azure.com
• privatelink.openai.azure.com
• privatelink.cognitiveservices.azure.com

平台团队还必须为以下 FQDN 设置 DNS，这些 FQDN 是 Foundry 代理服务依赖项：

• privatelink.search.windows.net
• privatelink.blob.core.windows.net
• privatelink.documents.azure.com

重要

在为 Foundry 代理服务部署功能主机并在 Foundry 代理服务作期间，DNS 解析必须从分支虚拟中正常运行。 Foundry 代理服务功能不使用辐射虚拟网络的 DNS 配置。 因此，建议平台团队在 DNS 专用解析程序中为工作负荷的专用 DNS 区域配置规则集，并将这些规则链接到应用程序登陆区域分支。

在部署 Azure AI Foundry 及其代理功能之前，必须等待，直到 Foundry 代理服务依赖项完全可从辐射网络内部解析到其专用终结点。 如果 DINE 策略处理 DNS 专用区域的更新，则此要求尤其重要。 如果在可从子网中解析专用 DNS 记录之前尝试部署 Foundry 代理服务功能，则部署将失败。

平台团队还必须在此体系结构中托管专用 DNS 区域以用于其他工作负荷依赖项：

• privatelink.vaultcore.azure.net
• privatelink.azurewebsites.net

数据科学家和代理开发人员访问权限

与 基线体系结构一样，此体系结构禁用对 Azure AI Foundry 门户和其他基于浏览器的体验的公共入口访问。 基线体系结构部署跳转盒，以便为浏览器提供来自各种工作负荷角色使用的虚拟网络中的源 IP 地址。

当工作负荷连接到 Azure 登陆区域时，团队将获得更多访问选项。 请与平台团队协作，了解是否可以在管理和管理虚拟机（VM）的情况下访问各种基于浏览器的 Azure AI Foundry 门户。 可以通过来自现有 ExpressRoute 或 VPN 网关连接的可传递路由进行此访问。

基于本机工作站的访问需要跨界路由和 DNS 解析，平台团队可以帮助提供这些解决方案。 在订阅自动售货请求中包含此要求。

提供基于工作站的本机门户访问权限可提高工作效率，并简化与管理 VM 跳转框相比的维护。

跳转盒角色

此体系结构中的跳转盒为运营支持提供价值，不适用于运行时目的或 AI 和机器学习开发。 跳转盒可以排查 DNS 和网络路由问题，因为它提供对外部不可访问组件的内部网络访问。

在基线体系结构中，Azure Bastion 访问所管理的跳转框。

在此体系结构中，Azure Bastion 部署在连接订阅中，作为平台团队管理的共享区域资源。 为了演示此体系结构中的用例，Azure Bastion 位于连接订阅中，团队不会部署它。

充当跳转盒的 VM 必须符合 VM 的组织要求。 这些要求可能包括 Microsoft Entra ID 中的公司标识、特定基础映像和修补制度等项。

监视资源

Azure 登陆区域平台在管理订阅中提供共享的可观测性资源。 但是，我们建议预配自己的监视资源，以促进工作负荷的所有权责任。 此方法与 基线体系结构保持一致。

预配以下监视资源：

• Application Insights 充当团队的应用程序性能管理（APM）服务。 可以在聊天 UI、Foundry 代理服务和模型中配置此服务。

• Azure Monitor 日志工作区充当工作负荷拥有的 Azure 资源中的所有日志和指标的统一接收器。

与基线体系结构类似，所有资源都必须将 Azure 诊断日志发送到团队预配的 Azure Monitor 日志工作区。 此配置是基础结构（IaC）部署资源的一部分。 可能还需要将日志发送到中央 Azure Monitor 日志工作区。 在 Azure 登陆区域中，该工作区通常驻留在管理订阅中。

平台团队可能有更多的进程影响应用程序登陆区域中的资源。 例如，他们可能使用 DINE 策略来配置诊断并将日志发送到集中式管理订阅。 他们还可以通过策略应用 Azure Monitor 基线警报 。 确保实现不会阻止这些额外的日志记录和警报流。

Azure Policy

基线体系结构建议 使用常规策略 来帮助控制工作负荷。 将此体系结构部署到应用程序登陆区域时，无需添加或删除额外的策略。 为了帮助强制实施治理并增强此工作负荷的安全性，请继续将策略应用到订阅、资源组或资源。

即使部署工作负荷之前，应用程序登陆区域订阅仍具有现有策略。 某些策略通过审核或阻止部署中的特定配置来帮助组织治理。

以下示例策略可能会导致工作负荷部署复杂性：

• Policy：Secrets [In Key Vault] 应具有指定的最长有效期。

  并发症： Azure AI Foundry 可以在连接的 Key Vault 中存储与知识和工具连接相关的机密。 这些机密没有服务设置的到期日期。 基线体系结构不使用这些类型的连接，但可以扩展体系结构以支持它们。

• Policy：AI 搜索服务应使用客户管理的密钥来加密静态数据。

  并发症： 此体系结构不需要客户管理的密钥。 但你可以扩展体系结构以支持它们。

• Policy：AI Foundry 模型不应为预览版。

  并发症： 在生产工作负荷中启用代理功能时，你可能正在使用预览模型进行开发。

平台团队可能会应用 DINE 策略来处理自动部署到应用程序登陆区域订阅中的问题。 预先将将平台发起的限制和更改纳入 IaC 模板中并进行测试。 如果平台团队使用与应用程序要求相冲突的 Azure 策略，可以协商解决。

管理随时间推移的变化

在此体系结构中，平台提供的服务和作充当外部依赖项。 平台团队继续应用更改、载入登陆区域并应用成本控制。 平台团队可能无法确定单个工作负荷的优先级。 对这些依赖项的更改（如防火墙修改）可能会影响多个工作负荷。

必须以高效且及时的方式与平台团队通信，以便管理所有外部依赖项。 事先测试更改非常重要，这样才不会对工作负荷产生负面影响。

影响工作负荷的平台更改

在此体系结构中，平台团队会管理以下资源。 对这些资源的更改可能会影响工作负荷的可靠性、安全性、操作和性能目标。 在平台团队实施这些更改之前评估这些更改，以确定它们如何影响工作负荷。

• Azure 策略：对 Azure 策略的更改可能会影响工作负荷资源及其依赖项。 这些更改可能包括直接策略更新或将登陆区域移动到新的管理组层次结构中。 在发生新部署之前，这些更改可能会被忽略，因此必须对其进行彻底测试。

  例： 策略不再允许部署需要客户管理的密钥加密的 Azure Cosmos DB 实例，体系结构使用Microsoft管理的密钥加密。

• 防火墙规则：对防火墙规则的修改可能会影响工作负荷的虚拟网络或应用于所有流量的规则。 这些修改可能会导致流量阻塞，甚至导致静默进程失败。 这些潜在问题既适用于出口防火墙，也适用于 Azure 虚拟网络管理器应用的 NSG 规则。

  例： 阻止到必应 API 的流量会导致 Internet 地面数据的代理工具调用失败。

• 中心网络的路由：如果工作负荷依赖于到其他虚拟网络的路由，中心内路由的可传递性变化可能会影响工作负荷的功能。

  例： 路由更改可防止 Azure AI Foundry 代理访问由另一个团队运营的矢量存储，或者阻止数据科学团队从其工作站访问 AI Foundry 门户。

• Azure Bastion 主机：对 Azure Bastion 主机可用性或配置的更改。

  示例：配置更改可防止访问跳转框和生成代理 VM。

影响平台的工作负荷更改

以下示例介绍应与平台团队通信的工作负荷更改。 平台团队必须针对新更改验证平台服务的可靠性、安全性、作和性能目标，然后才能生效。

• 网络出口：监视网络出口量的任何显著增加，以防止工作负荷成为网络设备上的干扰邻居。 此问题可能会影响其他工作负荷的性能或可靠性目标。 此体系结构大多是自包含的，不太可能在出站流量模式上发生重大变化。

• 公共访问： 对工作负荷组件的公共访问的更改可能需要额外的测试。 平台团队可能会将工作负荷重新定位到其他管理组。

  示例：在此体系结构中，如果从应用程序网关中删除公共 IP 地址，并且仅使此应用程序在内部，则工作负荷对 Internet 的曝光将发生变化。 另一个示例是向 Internet 公开基于浏览器的 AI 门户，我们不建议。

• 业务关键性评级： 对工作负荷服务级别协议（SLA）的更改可能需要平台和工作负荷团队之间采用新的协作方法。

  例： 工作负荷可能会因采用率增加和成功而严重地从低到高的业务过渡。

企业体系结构团队

某些组织有一个企业体系结构团队，可能会影响工作负荷及其体系结构的设计。 该团队了解企业的 AI 采用 策略以及 Azure 设计 AI 工作负载 中的原则和建议。 请与此团队协作，确保此聊天工作负载满足特定于方案的目标，并符合组织策略和建议。

注意事项

这些注意事项实施 Azure 架构良好的框架的支柱原则，即一套可用于改进工作负荷质量的指导原则。 有关详细信息，请参阅 Well-Architected Framework。

可靠性

可靠性有助于确保应用程序能够履行对客户的承诺。 有关详细信息，请参阅可靠性设计评审核对清单。

此体系结构维护 基线体系结构的可靠性保证。 它不会为核心工作负荷组件引入新的可靠性注意事项。

关键依赖项

将工作负荷在平台和应用程序登陆区域中执行的所有功能视为依赖项。 维护事件响应计划，其中包括每个依赖项的联系人方法和升级路径。 将这些依赖项包含在工作负荷的故障模式分析（FMA）中。

请考虑可能发生的以下工作负荷依赖项和示例方案：

• 出口防火墙： 集中式出口防火墙将发生与工作负荷无关的更改。 多个工作负荷共享防火墙。

• DNS 解析： 此体系结构使用平台团队为大多数资源提供的 DNS，并结合适用于 Foundry 代理服务的 Azure DNS 和链接的 DNS 专用解析程序规则集。 因此，工作负荷取决于对专用终结点的 DNS 记录的及时更新以及 DNS 服务的可用性。

• DINE 策略： Azure 专用 DNS 区域或任何其他平台提供的依赖项的 DINE 策略 以最佳方式 运行，不包括 SLA。 例如，此体系结构专用终结点的 DNS 配置延迟可以防止聊天 UI 成为流量就绪或阻止代理完成 Foundry 代理服务查询。

• 管理组策略： 环境之间的一致策略支持可靠性。 确保预生产环境与生产环境匹配，以提供准确的测试和防止特定于环境的偏差，从而阻止部署或缩放。 有关详细信息，请参阅管理 Azure 登陆区域中的应用程序开发环境。

其中许多注意事项可能不存在于没有 Azure 登陆区域。 你需要与平台团队协作解决这些问题，并确保满足所有要求。 有关详细信息，请参阅 “标识依赖项”。

安全性

安全性提供针对故意攻击和滥用宝贵数据和系统的保证。 有关详细信息，请参阅可靠性设计审查检查表。

入口流量控制

若要将工作负荷与组织中的其他工作负荷辐射区隔离，请在子网上应用 NSG，并在区域中心使用非传输性质或控制。 构建仅允许应用程序及其基础结构的入站网络要求的全面 NSG。 我们建议不要只依赖中心网络的非传输性质来确保安全性。

平台团队实现 Azure 策略的安全性。 例如，策略可以确保应用程序网关具有设置为拒绝模式的 Web 应用程序防火墙，这会限制订阅可用的公共 IP 地址数。 除了这些策略，还应部署更多以工作负荷为中心的策略，以增强入口安全态势。

下表显示了此体系结构中的入口控制示例。

来源	目的	工作负荷控制	平台控制
Internet	应用程序流量流	在允许公共流量转换到聊天 UI 的专用流量之前，通过 NSG、Web 应用程序防火墙和路由规则将所有工作负荷请求漏斗。	没有
Internet	Azure AI Foundry 门户访问和数据平面 REST API 访问	通过服务级别配置拒绝所有访问。	没有
Internet	对除应用程序网关以外的所有服务的数据平面访问	通过 NSG 规则和服务级别配置拒绝所有访问。	没有
Azure Bastion	跳转框和生成代理访问权限	在跳转盒子网上应用 NSG，该子网阻止所有流量到远程访问端口，除非源是平台指定的 Azure Bastion 子网。	没有
跨界	Azure AI Foundry 门户访问和数据平面 REST API 访问	拒绝所有访问。 如果不使用跳转框，则仅允许从授权子网中的工作站访问数据科学家。	在 Azure 虚拟 WAN 安全中心强制实施非传输路由或使用 Azure 防火墙
其他分支	没有	通过 NSG 规则阻止。	在虚拟 WAN 安全中心强制实施非传输路由或使用 Azure 防火墙

出口流量控制

应用 NSG 规则来表达解决方案所需的出站连接要求并拒绝其他所有要求。 不要只依赖于中心网络控制。 作为工作负荷作员，必须尽可能停止靠近源的意外出口流量。

在虚拟网络中拥有工作负荷的子网，但平台团队可能会创建防火墙规则，专门表示在订阅售货过程中捕获的要求。 确保体系结构生存期内子网和资源放置更改与原始请求保持兼容。 与网络团队合作，确保最低访问权限出口控制的连续性。

下表显示了此体系结构中的出口控件示例。

端点	目的	工作负荷控制	平台控制
公共 Internet 源	代理可能需要 Internet 搜索才能在 Foundry Models 请求中建立 Azure OpenAI	在代理集成子网上应用 NSG	为外部知识存储和工具应用防火墙应用程序规则
Azure AI Foundry 数据平面	聊天 UI 与聊天代理交互	允许从应用服务集成子网到 Azure AI Foundry 专用终结点子网的 TCP/443	没有
Azure Cosmos DB	从 Foundry 代理服务访问内存数据库	允许每个端口上的 TCP 连接到 Azure Cosmos DB 专用终结点子网	没有

对于离开工作负荷虚拟网络的流量，此体系结构通过 NSG 在工作负荷级别应用控制，并通过中心网络防火墙在平台级别应用控制。 NSG 提供初始、广泛的网络流量规则。 在平台的中心，防火墙会应用更具体的规则来增强安全性。

此体系结构不需要内部组件（如 Foundry 代理服务及其依赖的 AI 搜索实例）之间的东西向流量通过中心网络进行路由。

DDoS 保护

确定谁应应用涵盖解决方案的公共 IP 地址的 DDoS 防护计划。 平台团队可能会使用 IP 地址保护计划，或者他们可能会使用 Azure Policy 强制实施虚拟网络保护计划。 此体系结构需要 DDoS 防护覆盖范围，因为它具有从 Internet 入口的公共 IP 地址。 有关详细信息，请参阅关于网络和连接的建议。

标识和访问管理

除非平台团队的治理自动化需要额外的控制，否则由于平台团队的参与，此体系结构不会引入新的授权要求。 Azure 基于角色的访问控制（RBAC）应继续履行最低特权原则，仅向需要权限的个人授予有限访问权限，并且仅在需要时授予访问权限。 有关详细信息，请参阅标识和访问管理建议。

证书和加密

你的团队通常会为应用程序网关上的公共 IP 地址采购 TLS 证书。 与平台团队合作，了解证书采购和管理流程应如何与组织期望保持一致。

此体系结构中的所有数据存储服务都支持Microsoft托管或客户管理的加密密钥。 如果工作负荷设计或组织需要更多控制，请使用客户管理的加密密钥。 Azure 登陆区域本身不要求使用特定方法。

成本优化

成本优化侧重于减少不必要的开支和提高运营效率的方法。 有关详细信息，请参阅成本优化设计评审核对清单。

基线体系结构中的所有成本优化策略都适用于此体系结构中的工作负荷资源。

此体系结构极大地受益于 Azure 登陆区域平台资源。 例如，Azure 防火墙和 DDoS 防护等资源从工作负荷过渡到平台资源。 即使通过退款模型使用这些资源，添加的安全性和跨界连接比自行管理这些资源更具成本效益。 利用平台团队提供的其他集中式产品/服务，将这些优势扩展到工作负载，而不会影响其服务级别目标、恢复时间目标或恢复点目标。

重要

不要尝试通过将 Azure AI Foundry 依赖项合并为平台资源来优化成本。 这些服务必须保留工作负荷资源。

卓越运营

卓越运营涵盖了部署应用程序并使其在生产环境中保持运行的运营流程。 有关详细信息，请参阅设计卓越运营的审查清单。

你仍负责 基线体系结构中的所有卓越运营注意事项。 这些职责包括监视、GenAIOps、质量保证和安全部署实践。

关联来自多个接收器的数据

工作负荷的 Azure Monitor 日志工作区存储工作负荷的日志和指标及其基础结构组件。 但是，中心 Azure Monitor 日志工作区通常存储集中服务的日志和指标，例如 Azure 防火墙、DNS 专用解析程序和 Azure Bastion。 关联来自多个接收器的数据可能是一项复杂的任务。

相关数据有助于支持事件响应。 此体系结构的会审 Runbook 应解决这种情况，如果问题超出工作负荷资源，则包括组织联系信息。 工作负荷管理员可能需要平台管理员的帮助来关联来自企业网络、安全或其他平台服务的日志条目。

重要

对于平台团队： 如果可能，请授予 RBAC 权限，以查询和读取相关平台资源的日志接收器。 为网络和应用程序规则评估和 DNS 代理启用防火墙日志。 应用程序团队可以使用此信息对任务进行故障排除。 有关详细信息，请参阅监视和威胁检测建议。

生成代理

此体系结构中的许多服务都使用专用终结点。 与基线体系结构类似，此设计可能需要生成代理。 你的团队可安全可靠地部署生成代理。 平台团队不参与此过程。

确保生成代理管理符合组织标准。 这些标准可能包括使用平台批准的作系统映像、修补计划、合规性报告和用户身份验证方法。

性能效率

性能效率是指工作负荷能够高效地缩放以满足用户需求。 有关详细信息，请参阅性能效率设计评审核对清单。

基线体系结构中的性能效率注意事项也适用于此体系结构。 你的团队将控制应用程序流中的资源，而不是平台团队。 根据工作负荷和成本约束缩放聊天 UI 主机、语言模型和其他组件。 根据体系结构的最终实现，根据性能目标衡量性能时，请考虑以下因素：

• 出口和跨界延迟
• 成本包含治理的 SKU 限制

部署此方案

部署此参考体系结构的登陆区域实现。

Foundry 代理服务聊天基线参考实现

供稿人

Microsoft维护本文。 以下参与者撰写了本文。

主要作者：

• 比拉尔·阿姆贾德 |Microsoft云解决方案架构师
• Freddy Ayala | Microsoft 云解决方案架构师
• 查德·基特尔 |首席软件工程师 - Azure 模式和做法

若要查看非公开的LinkedIn个人资料，请登录LinkedIn。

后续步骤

了解如何与平台团队协作处理技术详细信息。

订阅销售

相关资源

• 有关 Azure 上的 AI 工作负荷的 Well-Architected 框架视角