Azure 登陆区域中的 Azure 虚拟机基线体系结构

本文中的体系结构扩展了 虚拟机（VM）基线体系结构，以解决在 Azure 登陆区域中部署虚拟机时的更改和期望。

在本文中的示例中，组织希望基于 VM 的工作负荷使用平台团队集中管理的联合资源。 这些资源包括用于跨界连接的网络资源、标识访问管理和策略。 此示例假定组织采用 Azure 登陆区域，以跨多个工作负荷强制实施一致的治理和成本效益。

作为工作负荷所有者，可以将共享资源的管理卸载到中心团队，以便专注于工作负荷开发工作。 本文介绍工作负荷团队的观点。 指定了平台团队的建议。

文章布局

建筑	设计决策	Azure Well-Architected Framework 方法
▪ 体系结构关系图 ▪ 工作负荷资源 ▪ 联合资源	▪ 订阅设置 ▪ 网络要求 ▪ 基线 的网络设计更改 ▪ 监视 ▪ 修补程序符合性 ▪ 组织治理 ▪ 变更管理	▪ 可靠性 ▪ 安全 ▪ 成本优化

建筑

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

组件

所有 Azure 登陆区域体系结构在平台团队和工作负荷团队之间拥有所有权分离。 应用程序架构师和 DevOps 团队需要充分了解这种责任划分，以便了解其直接影响或控制下的内容，以及哪些内容不是。

工作负荷团队拥有的资源

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

• Azure 虚拟机 是应用程序平台。 计算资源分布在可用性区域。

• Azure 负载均衡器 用于对从前端 VM 到后端 VM 的流量进行专用负载均衡。 负载均衡器跨区域将流量分发到 VM。

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

• Azure Key Vault 用于存储应用程序机密和证书。

• Azure Monitor、Log Analytics 和 Application Insights 用于收集、存储和可视化可观测性数据。

• Azure Policy 用于应用特定于工作负荷的策略。

工作负荷团队维护并履行以下资源和职责。

• 辐射虚拟网络子网和网络安全组（NSG） 放置在这些子网上，以保持分段和控制流量流。

• 专用终结点 来保护与平台即服务（PaaS）解决方案的连接，以及这些终结点所需的 专用 DNS 区域。

• Azure 托管磁盘 将日志文件存储在后端服务器上，即使 VM 重新启动，数据也会保留。 前端服务器附加了可用于部署无状态应用程序的磁盘。

平台团队拥有的资源

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

• 中心网络 中的 Azure 防火墙用于检查和限制出口流量。 此组件取代了基线体系结构中的标准负载均衡器，该体系结构不提供对发到 Internet 的出站流量的限制。

• 中心网络中的 Azure Bastion 提供对工作负荷 VM 的安全作访问。 在基线体系结构中，工作负荷团队拥有此组件。

• 辐射虚拟网络 部署工作负荷的位置。

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

• 基于 Azure Policy 的治理约束 和 DeployIfNotExists（DINE）策略是工作负荷订阅的一部分。

订阅设置

在登陆区域上下文中，工作负荷团队必须通知平台团队其特定要求。

工作负荷团队 必须包含有关工作负荷所需的网络空间的详细信息，以便平台团队可以分配必要的资源。 你的团队确定要求，平台团队确定在虚拟网络中分配的 IP 地址以及要向其分配订阅的管理组。

平台团队 根据工作负荷的业务关键性和技术要求分配适当的管理组，例如，如果工作负荷公开给 Internet。 组织确定这些管理组的配置，平台团队实现这些组。

例如，考虑 基线体系结构 的应用程序方案中的管理组：

• 专用应用程序，例如内部业务线应用程序或现成的商业现成（INTRANET）解决方案，这些解决方案通常位于 Azure 登陆区域的 Corp 管理组下。

• 公共应用程序，就像面向 Internet 的应用程序一样，这些应用程序通常位于 Corp 或 Online 管理组下。

平台团队还负责为工作负荷部署设置订阅或一组订阅。

以下部分提供有关初始订阅设置的指导。 但是，平台团队通常会对集中式服务进行更改，以解决错过或更改的要求。 平台更改对所有工作负荷团队都有更广泛的影响。

因此，平台团队必须确保所有 VM 工作负荷都准备好进行任何更改，并且必须了解基于 VM 的解决方案和测试周期的生命周期。 有关详细信息，请参阅 管理一段时间内的更改。

工作负荷要求和履行

工作负荷团队和平台团队分担两个主要职责：管理组分配和网络设置。 对于此体系结构，请考虑应与平台团队通信的以下网络要求。 使用这些要点作为示例，了解在实现类似体系结构时两个团队之间的讨论和协商。

• 分支虚拟网络的数量：在此体系结构中，只需要一个专用辐射。 部署的资源不需要跨多个网络并置在单个虚拟网络中。

• 辐射网络的大小：考虑工作负荷的作要求和预期增长。 例如，如果计划实现蓝/绿或 Canary 更新，则最大大小应考虑到并行部署所需的空间。

  将来的更改可能需要更多 IP 空间，这可能与当前分配不对齐。 这些空间的集成可能会带来额外的复杂性。 主动并提前请求足够的网络资源，以确保分配的空间可以容纳未来的扩展。

• 部署区域：必须指定将部署工作负荷的区域。 平台团队可以使用此信息来确保在同一区域中预配辐射和中心虚拟网络。 由于流量跨越区域边界，跨不同区域的网络可能会导致延迟问题，也会产生额外的带宽成本。

• 工作负荷特征和设计选择：将设计选择、组件和特征传达给平台团队。 例如，如果希望工作负荷生成与 Internet 的大量并发连接（聊天），平台团队应确保有足够的端口可用于防止耗尽。 他们可以将 IP 地址添加到集中式防火墙以支持流量，或设置网络地址转换（NAT）网关，以通过备用路径路由流量。

  相反，如果希望工作负荷生成最小网络流量（后台噪音），平台团队应在整个组织中高效地使用资源。

  平台团队需要清楚地了解任何依赖项。 例如，工作负荷可能需要访问另一个团队拥有的数据库，或者工作负荷可能具有跨界流量。 工作负荷是否在 Azure 外部具有依赖项？ 这些信息对于平台团队来说非常重要。

• 防火墙配置：平台团队必须了解离开辐射网络的流量，并将其隧道发送到中心网络。 中心的防火墙无法阻止该流量。

  例如，如果工作负荷需要访问 Windows 更新以保持修补状态，防火墙不应阻止这些更新。 同样，如果有访问特定终结点的 Monitor 代理，防火墙不应阻止该流量，因为它可能会中断工作负荷的监视数据。 应用程序可能需要访问第三方终结点。 不管怎样，使用集中式防火墙区分预期流量和不必要流量。

• 作员访问：如果存在作员用于通过 Azure Bastion 访问 VM 的 Microsoft Entra ID 安全组，请通知平台团队。 Azure Bastion 通常是中心资源。 确保安全组和 VM 支持安全协议至关重要。

  此外，请告知平台团队包含 VM 的 IP 范围。 在中心网络中配置 Azure Bastion 周围的 NSG 时，必须提供此信息。

• 公共 IP：告知平台团队入口流量配置文件，包括任何预期的公共 IP 地址。 在此体系结构中，只有 Internet 源流量以应用程序网关上的公共 IP 为目标。 如果这些 IP 属于 Azure DDoS 保护计划，或者工作负荷团队负责，平台团队应通知工作负荷团队。

  在此体系结构中，还有另一个公共 IP 用于通过 Azure Bastion 进行作访问。 平台团队拥有此公共 IP，并且它注册了一项服务，如平台团队也管理的 DDoS 防护。

VM 设计选择

VM SKU 和磁盘选择与 基线体系结构相同。

组织可能会对强制使用特定 VM 映像的工作负荷团队施加合规性要求。 鉴于此类要求，平台团队可以管理一组标准化映像，这些映像通常称为 黄金映像，这些映像是在组织内创建的。

平台团队可以使用托管产品/服务（例如 Azure 计算库或专用存储库）来存储批准的 OS 映像或工作负荷项目。 为 VM 选择 OS 映像时，请咨询平台团队，了解映像源、更新频率和使用情况预期。 此外，请确保映像可以满足工作负载满足的必要业务要求。

联网

在 基线体系结构中，工作负荷是在单个虚拟网络中预配的。 工作负荷团队管理虚拟网络。

在此体系结构中，平台团队确定网络拓扑。 在此体系结构中假定中心辐射型拓扑。

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

• 中心虚拟网络：区域中心包含与同一区域中的工作负荷资源通信的集中式服务。 有关详细信息，请参阅 平台团队拥有的资源。 建议将中心置于 连接订阅。

• 辐射虚拟网络：在此体系结构中，基线体系结构中的单个虚拟网络是辐射网络。 它与中心网络对等互连，其中包含集中式服务。 平台团队拥有和管理此辐射网络。 此网络包含 工作负荷资源。 工作负荷团队拥有此网络中的资源，包括其子网。

请确保 向平台团队 传达工作负荷要求，并定期查看它们。

虚拟网络子网

在辐射虚拟网络中，工作负荷团队创建并分配子网。 放置控制来限制进出子网的流量有助于提供分段。 此体系结构使用与 基线体系结构相同的子网拓扑，该体系结构具有应用程序网关、前端 VM、负载均衡器、后端 VM 和专用终结点的专用子网。

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

使用此方法，平台团队可以使用集中式服务来优化整体组织支出，而不是在整个组织中为每个工作负荷部署冗余安全控制。 在此体系结构中，Azure 防火墙是中央服务的一个示例。 对于每个工作负荷团队来说，管理自己的防火墙实例并不经济高效或实用。 建议采用集中式防火墙管理方法。

入口流量

入口流量流与 基线体系结构相同。

工作负荷所有者负责与公共 Internet 流入工作负荷相关的任何资源。 例如，在此体系结构中，应用程序网关及其公共 IP 放置在辐射网络中，而不是中心网络。 某些组织可能会使用集中式非军事化 （DMZ） 实现将入口流量的资源置于连接订阅中。 与该特定拓扑的集成不适用于本文。

出口流量

在基线体系结构中，工作负荷虚拟机规模集通过 Azure 负载均衡器访问公共 Internet，但流量不受限制。

这种设计在此体系结构中有所不同。 离开辐射虚拟网络的所有流量都通过出口防火墙通过对等中心网络进行路由。 路由附加到辐射网络中所有可能的子网，该子网将本地虚拟网络中未找到的所有 IP 的所有流量（0.0.0.0/0）定向到中心的 Azure 防火墙。

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

与 Key Vault 访问的专用终结点的工作负荷通信与 基线体系结构相同。 为了简洁起见，从上图中省略该路径。

工作负荷团队必须识别、记录和传达基础结构和工作负荷作所需的所有出站流量流。 平台团队允许所需的流量，并且所有未通信的出口流量都可能会被拒绝。

控制出口流量不仅仅是确保允许预期的流量。 它还要确保只允许 预期流量。 默认情况下，未通信的出口流量可能会被拒绝，但它符合工作负荷的最佳安全利益，以确保流量正确路由。

向平台团队传达任何唯一的出口流量要求。 例如，如果工作负荷建立与外部网络终结点的多个并发连接，请通知平台团队。 然后，平台团队可以在区域防火墙上预配适当的 Azure NAT 网关实现，或添加更多公共 IP 以缓解。

你的组织可能要求阻止使用体系结构模式，这些模式使用工作负荷拥有的公共 IP 进行出口。 在这种情况下，可以使用 Azure Policy 拒绝 VM 网络接口卡（NIC）和其他任何公共 IP（而不是已知入口点）上的公共 IP。

专用 DNS 区域

使用专用终结点的体系结构需要专用 DNS 区域才能与 DNS 提供程序一起使用。 工作负荷团队必须清楚地了解平台团队提供的订阅中专用 DNS 区域的要求和管理。 专用 DNS 区域通常使用 DINE 策略大规模管理，使 Azure 防火墙能够充当可靠的 DNS 代理并支持完全限定的域名（FQDN）网络规则。

在此体系结构中，平台团队确保专用链接终结点的可靠专用 DNS 解析。 与平台团队协作，了解他们的期望。

连接测试

对于基于 VM 的体系结构，有几个测试工具可帮助确定网络视线、路由和 DNS 问题。 可以使用传统的故障排除工具，例如 netstat、nslookup或 tcping。 此外，还可以检查网络适配器的动态主机配置协议（DHCP）和 DNS 设置。 如果有 NIC，则可以使用 Azure 网络观察程序执行连接检查的更多故障排除功能。

作员访问权限

与 基线体系结构一样，此体系结构支持通过 Azure Bastion 进行作访问。

但是，基线体系结构将 Azure Bastion 部署为工作负荷的一部分。 对于采用 Azure 登陆区域的典型组织，他们将 Azure Bastion 部署为每个区域的中央资源。 平台团队拥有和维护 Azure Bastion，组织中的所有工作负载共享它。 为了演示此体系结构中的用例，Azure Bastion 位于连接订阅的中心网络中。

作员标识

此体系结构使用与 基线体系结构相同的身份验证扩展。

始终从最低特权和精细访问任务而不是长期访问的原则开始。 在登陆区域上下文中，利用平台团队管理的实时（JIT）支持。

修补程序符合性和 OS 升级

基线体系结构 介绍了修补和升级的自治方法。 当工作负荷与登陆区域集成时，此方法可能会更改。 平台团队可能会决定修补作，以便所有工作负载都符合组织要求。

确保修补过程包括添加到体系结构的所有组件。 例如，如果选择添加生成代理 VM 来自动部署、缩放和管理应用程序，则这些 VM 必须符合平台要求。

监测

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

工作负荷团队预配监视资源，其中包括：

• Application Insights 作为工作负荷团队的应用程序性能监视（APM）服务。

• Log Analytics 工作区作为从工作负荷拥有的 Azure 资源和应用程序代码收集的所有日志和指标的统一接收器。

显示工作负荷监视资源的 下载此体系结构的 Visio 文件。

与基线类似，所有资源都配置为将 Azure 诊断日志发送到工作负荷团队作为基础结构即代码（IaC）部署资源的一部分预配的 Log Analytics 工作区。 可能还需要将日志发送到中央 Log Analytics 工作区。 在 Azure 登陆区域中，该工作区位于管理订阅中。

平台团队可能还具有可用于配置诊断以将日志发送到其集中式管理订阅的 DINE 策略。 请务必确保实现不会限制其他日志流。

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

工作负荷的日志和指标及其基础结构组件存储在工作负荷的 Log Analytics 工作区中。 但是，集中式服务的日志和指标（例如 Azure 防火墙、Microsoft Entra ID 和 Azure Bastion）生成的日志和指标存储在中央 Log Analytics 工作区中。 关联来自多个接收器的数据可能是一项复杂的任务。

相关数据通常在事件响应期间使用。 如果有多个接收器中的数据关联存在问题，请确保此体系结构的会审 Runbook 可以解决该问题，并在问题超出工作负荷资源时包括组织联系点。 工作负荷管理员可能需要平台管理员的帮助，以关联企业网络、安全性或其他平台服务中的日志条目。

Azure Policy

平台团队可能会应用影响工作负荷部署的策略。 他们通常会应用 DINE 策略来处理自动部署到应用程序登陆区域订阅中。 DINE 策略可以修改工作负荷资源或将资源添加到部署，这可能会导致通过工作负荷模板以声明方式部署的资源与处理请求实际使用的资源之间存在差异。 典型的解决方案是使用命令性方法修复这些更改，这并不理想。

为了避免这种差异，请先发制人地将平台发起的更改合并并测试到 IaC 模板中。 如果平台团队使用与应用程序要求冲突的 Azure 策略，则可以与平台团队协商解决方案。

管理一段时间内的更改

平台提供的服务和作被视为此体系结构中的外部依赖项。 平台团队继续应用更改、载入用户并应用成本控制。 为组织提供服务的平台团队可能无法确定单个工作负荷的优先级。 这些依赖项的更改（无论是金映像更改、防火墙修改、自动修补或规则更改）都可能会影响多个工作负荷。

因此，工作负荷和平台团队必须高效及时地进行通信，以管理所有外部依赖项。 测试更改非常重要，因此它们不会对工作负荷产生负面影响。

影响工作负荷的平台更改

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

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

• 防火墙规则：对防火墙规则的修改可能会影响工作负荷的虚拟网络或在所有流量中广泛应用的规则。 这些修改可能会导致流量被阻止，甚至出现无提示进程故障，例如 OS 修补程序的失败应用。 这些潜在问题适用于出口 Azure 防火墙和 Azure 虚拟网络管理器应用的 NSG 规则。

• 共享资源：对共享资源的 SKU 或功能的更改可能会影响工作负荷。

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

• Azure Bastion 主机：更改 Azure Bastion 主机可用性或配置可能会影响工作负荷作。 确保跳转盒访问模式更改具有有效的例程、即席和紧急访问。

• 所有权更改：将所有权和联系点的任何更改传达给工作负荷团队，因为它们可能会影响工作负荷的管理和支持请求。

影响平台的工作负荷更改

以下示例是此体系结构中应与平台团队通信的工作负荷更改。 平台团队在生效之前，必须针对新的工作负荷团队更改验证平台服务的可靠性、安全性、作和性能目标。

• 网络出口：监视网络出口量的任何显著增加，以防止工作负荷成为网络设备上的干扰邻居。 此问题可能会影响其他工作负荷的性能或可靠性目标。

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

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

• 所有权更改：向平台团队传达所有权更改和联系点。

工作负荷业务需求更改

为了维护工作负荷的服务级别目标（SLO），平台团队可能需要参与工作负荷体系结构更改。 这些更改可能需要平台团队的更改管理，或者验证现有治理是否支持更改的要求。

例如，将更改传达给以前不允许的任何出口流，以便平台团队可以在防火墙、虚拟网络管理器或其他组件中添加该流以支持所需流量。 相反，如果不再需要以前允许的出口流，平台团队应阻止该流，以便维护工作负荷的安全性。 还可以传达路由到其他虚拟网络或跨界终结点的更改，或对体系结构组件的更改。 每个资源都受策略和潜在出口防火墙控制的约束。

考虑

这些注意事项实现 Azure Well-Architected 框架的支柱，这是一组指导原则，可用于提高工作负荷的质量。 有关详细信息，请参阅 azure Well-Architected Framework Microsoft。

可靠性

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

此体系结构符合 基线体系结构的可靠性保证。

可靠性目标

由于出口网络控制等组件，可能的最大复合 SLO 低于基线复合 SLO。 这些组件在登陆区域环境中很常见，对此体系结构并不是唯一的。 如果工作负荷团队直接控制这些 Azure 服务，则 SLO 同样会减少。

尽管 SLO 最大可能降低，但关键可靠性方面是跨功能团队划分工作负荷组件。 借助此方法，工作负荷团队受益于专门团队，该团队专注于运行此工作负荷和其他工作负荷所使用的关键基础结构。

有关详细信息，请参阅 有关定义可靠性目标的建议。

关键依赖项

查看工作负荷在平台和应用程序登陆区域中执行的所有功能作为依赖项。 事件响应计划要求工作负荷团队了解这些依赖项的联系人信息点和方法。 此外，在工作负荷的故障模式分析（FMA）中包含这些依赖项。

对于此体系结构，请考虑以下依赖项：

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

• 网络端口耗尽：共享网络设备的所有工作负荷的使用量峰值可能导致网络饱和或出口防火墙上的端口耗尽。

• DINE 策略：Azure DNS 专用 DNS 区域（或任何其他平台提供的依赖项）的 DINE 策略 尽最大努力，执行时没有 SLA。 DNS 配置的延迟可能会导致应用程序处理流量的准备延迟。

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

其中许多注意事项可能不存在于 Azure 登陆区域，但工作负载和平台团队需要协作解决这些问题，以确保满足需求。

有关详细信息，请参阅 有关执行故障模式分析的建议。

安全

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

此体系结构的安全注意事项从 基线体系结构进行。 以下部分中的建议基于 Well-Architected Framework 中的安全设计评审清单。

网络控制

正确配置网络控制以确保工作负荷安全。

入口流量

可以通过子网上的 NSG 或区域中心内的非传输性质或控件，将工作负荷与组织内的其他工作负荷辐射隔离开来。 构建仅允许应用程序及其基础结构的入站网络要求的综合 NSG。 我们建议不要只依赖中心网络的非传输性质来保证安全性。

平台团队可能实施 Azure 策略，以确保应用程序网关将 Web 应用程序防火墙设置为 拒绝模式，以限制订阅可用的公共 IP 数和其他检查。 除了这些策略，工作负荷团队还应该负责部署以工作负荷为中心的策略，以增强入口安全态势。

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

源	目的	工作负荷控制	平台控件
互联网	用户流量流	在允许公共流量转换到进入前端 VM 的专用流量之前，通过 NSG、Web 应用程序防火墙和路由规则传递所有请求	没有
Azure Bastion	作员对 VM 的访问	VM 子网上的 NSG 会阻止所有流量进入远程访问端口，除非它源自平台的指定 Azure Bastion 子网	没有
其他辐射	没有	通过 NSG 规则阻止	Azure 虚拟 WAN 安全中心时的非传输路由或 Azure 防火墙规则

出口流量

应用 NSG 规则，以表达解决方案所需的出站连接要求并拒绝其他所有内容。 不要只依赖于中心网络控件。 作为工作负荷作员，你有责任将不需要的出口流量停止为尽可能接近源。

请注意，在虚拟网络中拥有子网时，平台团队可能会创建防火墙规则来专门表示捕获的要求，作为订阅售货过程的一部分。 确保体系结构生存期内子网和资源放置更改仍与原始请求兼容。 或者，你可以与网络团队合作，确保最小访问出口控制的连续性。

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

端点	目的	工作负荷 （NSG） 控件	平台（中心）控件
ntp.ubuntu.com	Linux VM 的网络时间协议 （NTP）	UDP/123 到前端 VM 子网上的 Internet（出口防火墙缩小了这个广泛的开放范围）	与工作负荷控制相同的防火墙网络规则限额
Windows 更新终结点	Microsoft 服务器的 Windows 更新功能	TCP/443 和 TCP/80 后端 VM 子网上的 Internet（出口防火墙缩小了这个广泛的开放范围）	具有 FQDN 标记的防火墙限制规则 WindowsUpdate
监视代理终结点	VM 上的 Monitor 扩展所需的流量	TCP/443 到两个 VM 子网上的 Internet（出口防火墙缩小了这个宽阔的开放范围）	TCP/443 上所有特定 FQDN 的必要防火墙应用程序规则限额
nginx.org	直接从供应商安装 Nginx（示例应用程序组件）	TCP/443 到前端 VM 子网上的 Internet（出口防火墙缩小了这个广泛的开放范围）	TCP/443 上 nginx.org 所需的防火墙应用程序规则限额
Key Vault	在应用程序网关和 VM 中导入 （传输层安全性） TLS 证书	- TCP/443 从两个 VM 子网到专用终结点子网的专用终结点子网 从应用程序网关子网将 TCP/443- 到专用终结点子网 从具有所需应用程序安全组（ASG）指定和应用程序网关子网的 VM - TCP/443	没有

DDoS 防护

确定负责应用涵盖所有解决方案公共 IP 的 DDoS 防护计划的人员。 平台团队可能使用 IP 保护计划，甚至可能使用 Azure Policy 强制实施虚拟网络保护计划。 此体系结构应具有覆盖范围，因为它涉及来自 Internet 的入口的公共 IP。

有关详细信息，请参阅 有关网络和连接的建议。

机密管理

对于机密管理，此体系结构遵循 基线体系结构。

作为工作负荷团队，请继续将机密保留在 Key Vault 实例中。 根据需要部署更多实例以支持应用程序和基础结构作。

有关详细信息，请参阅 保护应用程序机密的建议。

成本优化

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

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

此体系结构极大地受益于 Azure 登陆区域平台资源。 即使通过退款模型使用这些资源，添加的安全性和跨界连接比自行管理这些资源更具成本效益。

平台团队在此体系结构中管理以下资源。 这些资源通常是基于消耗的（退款）或可能免费给工作负荷团队。

• Azure 防火墙
• 安全信息和事件管理（SIEM）
• Azure Bastion 主机
• 跨界连接，例如 ExpressRoute

利用平台团队提供的其他集中式产品/服务，将这些优势扩展到工作负载，而不会影响其 SLO、恢复时间目标（RTO）或恢复点目标（RPO）。

有关详细信息，请参阅 有关收集和查看成本数据的建议。

部署此方案

GitHub 上提供了此参考体系结构的部署。

下一步

查看工作负荷团队与平台团队之间共享的协作和技术详细信息。

订阅自动售货