使用拆分式 DNS 配置在 Azure 中托管 Web 应用

Azure Front Door

Azure 应用程序网关

Azure ExpressRoute

Azure DNS

管理工作负荷的团队通常依赖于完全限定的域名（FQDN）进行客户访问。 FQDN 通常与传输层安全性（TLS）服务器名称指示（SNI）结合使用。 使用此方法时，当公共客户从公共 Internet 访问工作负荷或企业客户在内部访问工作负荷时，到应用程序的路由可能会遵循固定路径并具有各种级别的安全或服务质量（QoS）。

以下体系结构演示了一种区分基于域名系统（DNS）的流量处理方式的方法，以及客户是来自 Internet 还是来自企业网络。

建筑

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

以下工作流部分描述了两种配置：公共 Internet 工作流和专用工作流。 合并这两个工作流以实现拆分式托管体系结构。

公共 Internet 工作流

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

1. 客户通过公共 Internet 发送 app.contoso.com 应用程序的请求。

2. 为 contoso.com 域配置 Azure DNS 区域。 为 Azure Front Door 终结点配置适当的 规范名称（CNAME）条目 。

3. 外部客户通过 Azure Front Door 访问 Web 应用程序，后者充当全局负载均衡器和 Web 应用程序防火墙（WAF）。

   • 在 Azure Front Door 中，app.contoso.com 通过配置的终结点上的路由分配为 FQDN。 Azure Front Door 还托管应用程序的 TLS SNI 证书。

     注意

     Azure Front Door 不支持自签名证书。

   • Azure Front Door 根据客户的 Host HTTP 标头将请求路由到配置的源组。

   • 源组配置为通过应用程序网关的公共 IP 地址指向 Azure 应用程序网关实例。

4. AppGW 子网上配置了网络安全组（NSG），以允许从 AzureFrontDoor.Backend 服务标记对端口 80 和端口 443 进行入站访问。 NSG 不允许来自 Internet 服务标记的端口 80 和端口 443 上的入站流量。

   注意

   AzureFrontDoor.Backend 服务标记不会仅限制发到 Azure Front Door 实例的流量。 验证在下一阶段发生。

5. 应用程序网关实例在端口 443 上具有 侦听器 。 流量根据侦听器中指定的主机名路由到后端。

   • 为了确保流量源自 Azure Front Door 配置文件 ，请配置 自定义 WAF 规则 以检查 标头值。

   • Azure 为每个 Azure Front Door 配置文件生成唯一标识符。 唯一标识符是位于 Azure 门户概述页上的 Front Door ID 值。

6. 流量到达在应用程序网关中配置为后端池的计算资源。

专用企业工作流

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

1. 客户从本地环境启动对 app.contoso.com 应用程序的请求。

2. 在本地 DNS 提供程序上配置应用程序 FQDN。 此 DNS 提供程序可以是本地 Windows Server Active Directory DNS 服务器或其他合作伙伴解决方案。 每个应用程序 FQDN 的 DNS 条目配置为指向应用程序网关实例的专用 IP 地址。

3. Azure ExpressRoute 线路或站点到站点 VPN 有助于访问应用程序网关。

4. 在 AppGW 子网上配置 NSG，以允许来自来自流量的本地客户网络的传入专用请求。 此配置可确保其他专用流量源无法直接访问应用程序网关的专用 IP 地址。

5. 应用程序网关具有在端口 80 和端口 443 上配置的 侦听器 。 流量根据侦听器中指定的主机名路由到后端。

6. 只有专用网络流量到达在应用程序网关中配置为后端池的计算。

组件

• DNS：对于公共 Internet 工作流，必须使用 Azure Front Door 终结点 FQDN 的正确 CNAME 配置 公共 Azure DNS 区域 。 在专用（企业）端，将本地 DNS 提供程序（Windows Server Active Directory DNS 或合作伙伴解决方案）配置为将每个应用程序 FQDN 指向应用程序网关的专用 IP 地址。

• Azure DNS 专用解析程序：可以使用 DNS 专用解析程序来解析本地客户。 企业客户可以使用此拆分式 DNS 解决方案来获取对应用程序的访问权限，而无需遍历公共 Internet。

• Azure Front Door：Azure Front Door 是一个全局负载均衡器和 WAF，可向世界各地的客户提供快速安全的 Web 应用程序交付。 在此体系结构中，Azure Front Door 将外部客户路由到应用程序网关实例，并提供缓存和优化选项来增强客户体验。

• 应用程序网关：应用程序网关是区域负载均衡器和 WAF，可为 Web 应用程序提供高可用性、可伸缩性和安全性。 在此体系结构中，应用程序网关将外部和内部客户请求路由到后端计算，并保护 Web 应用程序免受常见的 Web 攻击。

  Azure Front Door 和应用程序网关都提供 WAF 功能，但此解决方案中的专用工作流不使用 Azure Front Door。 因此，这两种体系结构都使用应用程序网关的 WAF 功能。

• ExpressRoute：可以使用 ExpressRoute 通过专用连接将本地网络扩展到 Microsoft 云，并借助连接提供商。 在此体系结构中，可以使用 ExpressRoute 为本地客户提供与应用程序网关的专用连接。

选择

作为替代解决方案，可以删除 Azure Front Door，而是将公共 Azure DNS 记录指向应用程序网关的公共 IP 地址。 根据此体系结构的要求，必须在 Azure 的入口点执行 缓存和优化 。 因此，替代解决方案不是此方案的选项。 有关详细信息，请参阅 成本优化。

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

此体系结构中公共入口流量的其他可能替代方法包括：

• Azure 流量管理器：流量管理器是一种基于 DNS 的流量路由服务，可在各个区域和终结点之间分配流量。 可以使用流量管理器而不是 Azure Front Door 将外部客户路由到最近的应用程序网关实例。 但是，Azure Front Door 提供 WAF 功能、缓存和会话相关性等功能。 流量管理器不提供这些功能。

• Azure 负载均衡器：Azure 负载均衡器是一种网络负载均衡器，可为传输控制协议（TCP）和用户数据报协议（UDP）流量提供高可用性和可伸缩性。 可以使用负载均衡器而不是应用程序网关将外部和内部客户请求路由到后端 Web 服务器。 但是，应用程序网关提供诸如 WAF 功能、安全套接字层（SSL）终止和基于 Cookie 的会话相关性等功能。 负载均衡器不提供这些功能。

方案详细信息

此方案解决了托管服务外部客户和内部客户的 Web 应用程序的问题。 此体系结构可确保流量遵循基于客户的源的适当路径。 此体系结构：

• 为世界各地的非企业客户提供通过 Internet 快速可靠的访问 Web 应用程序。

• 使企业客户能够在不遍历公共 Internet 的情况下访问应用程序。

• 保护 Web 应用程序免受常见的 Web 攻击和恶意流量。

潜在的用例

将此体系结构用于需要以下情况的方案：

• 拆分脑 DNS：此解决方案将 Azure Front Door 用于外部客户，并为内部客户使用应用程序网关，每个服务的 DNS 记录不同。 此方法有助于优化各种客户的网络性能、安全性和可用性。

• 应用程序可伸缩性：此解决方案使用应用程序网关，它可以在配置的后端计算资源之间分配流量。 此方法有助于提高应用程序性能和可用性，并支持水平缩放。

考虑

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

可靠性

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

• 确定故障点：在此拆分式 DNS 体系结构中，可靠性取决于关键组件（如 Azure Front Door、应用程序网关和 DNS 配置）的正确功能。 必须识别潜在的故障点，例如配置错误、SSL 证书问题或容量重载。

• 评估影响：必须评估故障的影响。 对于外部客户，充当网关的 Azure Front Door 的任何中断都可能会影响全球访问。 对于内部客户，应用程序网关的任何中断都可能会妨碍企业运营。

• 实施缓解策略：若要降低风险，请跨 多个可用性区域实现冗余，使用 运行状况探测 进行实时监视，并确保正确配置外部和内部流量的 DNS 路由。 确保定期更新 DNS 记录并制定灾难恢复计划。

• 持续监视：若要保持警惕系统运行状况，请使用 Azure Monitor 功能。 为异常设置警报 ，并准备好事件响应计划来及时解决潜在问题。

遵循这些原则，确保能够承受挑战和维护服务连续性的可靠系统。

安全

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

• 使用零信任方法：在拆分式 DNS 设置中，应用零信任 方法 。 显式验证客户的标识，无论是源自 Internet 还是企业网络。 此方法可确保只有受信任的实体执行授权操作。

• 实现：为可靠的标识管理实现Microsoft Entra ID。 使用Microsoft Entra 条件访问策略根据客户上下文、设备运行状况和位置强制实施严格的访问控制。

• 评估安全有效性：通过实现以下方法评估双重访问工作负荷的安全措施的有效性：

  • 防御性投资：定期评估 Azure Front Door 和应用程序网关的有效性。 确保它们提供有意义的防范威胁。

  • 爆炸半径限制：确保你在有限的范围内包含安全漏洞。 例如，有效地隔离外部和内部流量流。

• 假设有漏洞：确认攻击者可能会违反安全控制措施。 为此类方案做好准备。

• 实施安全措施：实现网络分段、微分段和 NSG。 假设攻击者可能会获得访问权限，并相应地设计补偿控件。

将这些安全原则集成到拆分式 DNS 体系结构中，以创建可靠且可复原的系统，以保护对工作负荷的内部和外部访问。

其他安全增强功能

• 应用程序网关：可以使用应用程序网关上的 WAF 来保护 Web 应用程序免受常见 Web 漏洞和攻击的影响。 还可以使用 Azure 专用链接 从应用程序网关安全地访问后端应用程序服务器，而无需将其公开到公共 Internet。

• Azure 防火墙：可以将 Azure 防火墙添加到中心虚拟网络，并使用 Azure 防火墙威胁情报 阻止来自已知恶意 IP 地址和域的恶意流量。 还可以使用 Azure 防火墙作为 DNS 代理 来截获和检查 DNS 流量并应用 DNS 筛选规则。

• Azure Front Door：可以使用 Azure Web 应用程序防火墙 来保护 Web 应用程序免受边缘的常见 Web 漏洞和攻击。 还可以将 专用链接 与 Azure Front Door 高级层配合使用，以安全地从 Azure Front Door 访问后端应用程序服务器，而无需将其公开到公共 Internet。

成本优化

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

• 后端计算：许多因素（例如 SKU 选择、副本计数和区域）都驱动了运行后端计算服务的成本。 在为工作负荷选择最佳选项之前，请确保考虑 计算资源 的所有元素。

• 应用程序网关：应用程序网关成本取决于实例数、实例大小以及处理的数据量。 可以通过使用 自动缩放 来根据流量需求调整实例数来优化成本。 还可以跨可用性区域部署 区域冗余 SKU ，以减少对高可用性的其他实例的需求。

• Azure Front Door：Azure Front Door 成本取决于路由规则数、HTTP 或 HTTPS 请求数以及传输的数据量。 可以使用 Azure Front Door 标准层或高级层 获得 Azure 内容分发网络、Azure Web 应用程序防火墙和专用链接的统一体验。 还可以使用 Azure Front Door 规则引擎功能 自定义流量管理和优化性能和成本。

  如果方案不需要全局访问或 Azure Front Door 的额外功能，则只能将此解决方案用于应用程序网关。 可以将所有公共 DNS 记录指向应用程序网关侦听器上配置的公共 IP 地址。

请参阅 此解决方案的示例 ，该解决方案近似于此体系结构中组件的典型用法。 调整成本以适应你的方案。

贡献

本文由Microsoft维护。 它最初由以下参与者编写。

主体作者：

• 特洛伊·希特 |高级云解决方案架构师

其他参与者：

• 梅斯·阿尔格巴里 |高级 Azure 网络全球 Blackbelt
• Adam Torkar |高级 Azure 网络全球 Blackbelt
• 迈克尔·麦基尼 |首席 Azure 技术专家

若要查看非公共LinkedIn配置文件，请登录到LinkedIn。

后续步骤

• 应用程序网关基础结构配置
• 使用 Azure Front Door 端到端 TLS
• 将自定义域添加到 Azure Front Door
• 什么是 Azure Front Door 域上的异地筛选

相关资源

• 虚拟网络的防火墙和应用程序网关
• 在多租户解决方案中使用 Azure Front Door

管理工作负荷的团队通常依赖于完全限定的域名（FQDN）进行客户访问。 FQDN 通常与传输层安全性（TLS）服务器名称指示（SNI）结合使用。 使用此方法时，当公共客户从公共 Internet 访问工作负荷或企业客户在内部访问工作负荷时，到应用程序的路由可能会遵循固定路径并具有各种级别的安全或服务质量（QoS）。

以下体系结构演示了一种区分基于域名系统（DNS）的流量处理方式的方法，以及客户是来自 Internet 还是来自企业网络。

建筑

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

以下工作流部分描述了两种配置：公共 Internet 工作流和专用工作流。 合并这两个工作流以实现拆分式托管体系结构。

公共 Internet 工作流

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

1. 客户通过公共 Internet 发送 app.contoso.com 应用程序的请求。

2. 为 contoso.com 域配置 Azure DNS 区域。 为 Azure Front Door 终结点配置适当的 规范名称（CNAME）条目 。

3. 外部客户通过 Azure Front Door 访问 Web 应用程序，后者充当全局负载均衡器和 Web 应用程序防火墙（WAF）。

   • 在 Azure Front Door 中，app.contoso.com 通过配置的终结点上的路由分配为 FQDN。 Azure Front Door 还托管应用程序的 TLS SNI 证书。

     注意

     Azure Front Door 不支持自签名证书。

   • Azure Front Door 根据客户的 Host HTTP 标头将请求路由到配置的源组。

   • 源组配置为通过应用程序网关的公共 IP 地址指向 Azure 应用程序网关实例。

4. AppGW 子网上配置了网络安全组（NSG），以允许从 AzureFrontDoor.Backend 服务标记对端口 80 和端口 443 进行入站访问。 NSG 不允许来自 Internet 服务标记的端口 80 和端口 443 上的入站流量。

   注意

   AzureFrontDoor.Backend 服务标记不会仅限制发到 Azure Front Door 实例的流量。 验证在下一阶段发生。

5. 应用程序网关实例在端口 443 上具有 侦听器 。 流量根据侦听器中指定的主机名路由到后端。

   • 为了确保流量源自 Azure Front Door 配置文件 ，请配置 自定义 WAF 规则 以检查 标头值。

   • Azure 为每个 Azure Front Door 配置文件生成唯一标识符。 唯一标识符是位于 Azure 门户概述页上的 Front Door ID 值。

6. 流量到达在应用程序网关中配置为后端池的计算资源。

专用企业工作流

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

1. 客户从本地环境启动对 app.contoso.com 应用程序的请求。

2. 在本地 DNS 提供程序上配置应用程序 FQDN。 此 DNS 提供程序可以是本地 Windows Server Active Directory DNS 服务器或其他合作伙伴解决方案。 每个应用程序 FQDN 的 DNS 条目配置为指向应用程序网关实例的专用 IP 地址。

3. Azure ExpressRoute 线路或站点到站点 VPN 有助于访问应用程序网关。

4. 在 AppGW 子网上配置 NSG，以允许来自来自流量的本地客户网络的传入专用请求。 此配置可确保其他专用流量源无法直接访问应用程序网关的专用 IP 地址。

5. 应用程序网关具有在端口 80 和端口 443 上配置的 侦听器 。 流量根据侦听器中指定的主机名路由到后端。

6. 只有专用网络流量到达在应用程序网关中配置为后端池的计算。

组件

• DNS：对于公共 Internet 工作流，必须使用 Azure Front Door 终结点 FQDN 的正确 CNAME 配置 公共 Azure DNS 区域 。 在专用（企业）端，将本地 DNS 提供程序（Windows Server Active Directory DNS 或合作伙伴解决方案）配置为将每个应用程序 FQDN 指向应用程序网关的专用 IP 地址。

• Azure DNS 专用解析程序：可以使用 DNS 专用解析程序来解析本地客户。 企业客户可以使用此拆分式 DNS 解决方案来获取对应用程序的访问权限，而无需遍历公共 Internet。

• Azure Front Door：Azure Front Door 是一个全局负载均衡器和 WAF，可向世界各地的客户提供快速安全的 Web 应用程序交付。 在此体系结构中，Azure Front Door 将外部客户路由到应用程序网关实例，并提供缓存和优化选项来增强客户体验。

• 应用程序网关：应用程序网关是区域负载均衡器和 WAF，可为 Web 应用程序提供高可用性、可伸缩性和安全性。 在此体系结构中，应用程序网关将外部和内部客户请求路由到后端计算，并保护 Web 应用程序免受常见的 Web 攻击。

  Azure Front Door 和应用程序网关都提供 WAF 功能，但此解决方案中的专用工作流不使用 Azure Front Door。 因此，这两种体系结构都使用应用程序网关的 WAF 功能。

• ExpressRoute：可以使用 ExpressRoute 通过专用连接将本地网络扩展到 Microsoft 云，并借助连接提供商。 在此体系结构中，可以使用 ExpressRoute 为本地客户提供与应用程序网关的专用连接。

选择

作为替代解决方案，可以删除 Azure Front Door，而是将公共 Azure DNS 记录指向应用程序网关的公共 IP 地址。 根据此体系结构的要求，必须在 Azure 的入口点执行 缓存和优化 。 因此，替代解决方案不是此方案的选项。 有关详细信息，请参阅 成本优化。

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

此体系结构中公共入口流量的其他可能替代方法包括：

• Azure 流量管理器：流量管理器是一种基于 DNS 的流量路由服务，可在各个区域和终结点之间分配流量。 可以使用流量管理器而不是 Azure Front Door 将外部客户路由到最近的应用程序网关实例。 但是，Azure Front Door 提供 WAF 功能、缓存和会话相关性等功能。 流量管理器不提供这些功能。

• Azure 负载均衡器：Azure 负载均衡器是一种网络负载均衡器，可为传输控制协议（TCP）和用户数据报协议（UDP）流量提供高可用性和可伸缩性。 可以使用负载均衡器而不是应用程序网关将外部和内部客户请求路由到后端 Web 服务器。 但是，应用程序网关提供诸如 WAF 功能、安全套接字层（SSL）终止和基于 Cookie 的会话相关性等功能。 负载均衡器不提供这些功能。

方案详细信息

此方案解决了托管服务外部客户和内部客户的 Web 应用程序的问题。 此体系结构可确保流量遵循基于客户的源的适当路径。 此体系结构：

• 为世界各地的非企业客户提供通过 Internet 快速可靠的访问 Web 应用程序。

• 使企业客户能够在不遍历公共 Internet 的情况下访问应用程序。

• 保护 Web 应用程序免受常见的 Web 攻击和恶意流量。

潜在的用例

将此体系结构用于需要以下情况的方案：

• 拆分脑 DNS：此解决方案将 Azure Front Door 用于外部客户，并为内部客户使用应用程序网关，每个服务的 DNS 记录不同。 此方法有助于优化各种客户的网络性能、安全性和可用性。

• 应用程序可伸缩性：此解决方案使用应用程序网关，它可以在配置的后端计算资源之间分配流量。 此方法有助于提高应用程序性能和可用性，并支持水平缩放。

考虑

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

可靠性

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

• 确定故障点：在此拆分式 DNS 体系结构中，可靠性取决于关键组件（如 Azure Front Door、应用程序网关和 DNS 配置）的正确功能。 必须识别潜在的故障点，例如配置错误、SSL 证书问题或容量重载。

• 评估影响：必须评估故障的影响。 对于外部客户，充当网关的 Azure Front Door 的任何中断都可能会影响全球访问。 对于内部客户，应用程序网关的任何中断都可能会妨碍企业运营。

• 实施缓解策略：若要降低风险，请跨 多个可用性区域实现冗余，使用 运行状况探测 进行实时监视，并确保正确配置外部和内部流量的 DNS 路由。 确保定期更新 DNS 记录并制定灾难恢复计划。

• 持续监视：若要保持警惕系统运行状况，请使用 Azure Monitor 功能。 为异常设置警报 ，并准备好事件响应计划来及时解决潜在问题。

遵循这些原则，确保能够承受挑战和维护服务连续性的可靠系统。

安全

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

• 使用零信任方法：在拆分式 DNS 设置中，应用零信任 方法 。 显式验证客户的标识，无论是源自 Internet 还是企业网络。 此方法可确保只有受信任的实体执行授权操作。

• 实现：为可靠的标识管理实现Microsoft Entra ID。 使用Microsoft Entra 条件访问策略根据客户上下文、设备运行状况和位置强制实施严格的访问控制。

• 评估安全有效性：通过实现以下方法评估双重访问工作负荷的安全措施的有效性：

  • 防御性投资：定期评估 Azure Front Door 和应用程序网关的有效性。 确保它们提供有意义的防范威胁。

  • 爆炸半径限制：确保你在有限的范围内包含安全漏洞。 例如，有效地隔离外部和内部流量流。

• 假设有漏洞：确认攻击者可能会违反安全控制措施。 为此类方案做好准备。

• 实施安全措施：实现网络分段、微分段和 NSG。 假设攻击者可能会获得访问权限，并相应地设计补偿控件。

将这些安全原则集成到拆分式 DNS 体系结构中，以创建可靠且可复原的系统，以保护对工作负荷的内部和外部访问。

其他安全增强功能

• 应用程序网关：可以使用应用程序网关上的 WAF 来保护 Web 应用程序免受常见 Web 漏洞和攻击的影响。 还可以使用 Azure 专用链接 从应用程序网关安全地访问后端应用程序服务器，而无需将其公开到公共 Internet。

• Azure 防火墙：可以将 Azure 防火墙添加到中心虚拟网络，并使用 Azure 防火墙威胁情报 阻止来自已知恶意 IP 地址和域的恶意流量。 还可以使用 Azure 防火墙作为 DNS 代理 来截获和检查 DNS 流量并应用 DNS 筛选规则。

• Azure Front Door：可以使用 Azure Web 应用程序防火墙 来保护 Web 应用程序免受边缘的常见 Web 漏洞和攻击。 还可以将 专用链接 与 Azure Front Door 高级层配合使用，以安全地从 Azure Front Door 访问后端应用程序服务器，而无需将其公开到公共 Internet。

成本优化

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

• 后端计算：许多因素（例如 SKU 选择、副本计数和区域）都驱动了运行后端计算服务的成本。 在为工作负荷选择最佳选项之前，请确保考虑 计算资源 的所有元素。

• 应用程序网关：应用程序网关成本取决于实例数、实例大小以及处理的数据量。 可以通过使用 自动缩放 来根据流量需求调整实例数来优化成本。 还可以跨可用性区域部署 区域冗余 SKU ，以减少对高可用性的其他实例的需求。

• Azure Front Door：Azure Front Door 成本取决于路由规则数、HTTP 或 HTTPS 请求数以及传输的数据量。 可以使用 Azure Front Door 标准层或高级层 获得 Azure 内容分发网络、Azure Web 应用程序防火墙和专用链接的统一体验。 还可以使用 Azure Front Door 规则引擎功能 自定义流量管理和优化性能和成本。

  如果方案不需要全局访问或 Azure Front Door 的额外功能，则只能将此解决方案用于应用程序网关。 可以将所有公共 DNS 记录指向应用程序网关侦听器上配置的公共 IP 地址。

请参阅 此解决方案的示例 ，该解决方案近似于此体系结构中组件的典型用法。 调整成本以适应你的方案。

贡献

本文由Microsoft维护。 它最初由以下参与者编写。

主体作者：

• 特洛伊·希特 |高级云解决方案架构师

其他参与者：

• 梅斯·阿尔格巴里 |高级 Azure 网络全球 Blackbelt
• Adam Torkar |高级 Azure 网络全球 Blackbelt
• 迈克尔·麦基尼 |首席 Azure 技术专家

若要查看非公共LinkedIn配置文件，请登录到LinkedIn。

后续步骤

• 应用程序网关基础结构配置
• 使用 Azure Front Door 端到端 TLS
• 将自定义域添加到 Azure Front Door
• 什么是 Azure Front Door 域上的异地筛选

相关资源

• 虚拟网络的防火墙和应用程序网关
• 在多租户解决方案中使用 Azure Front Door