使用分割腦 DNS 組態在 Azure 中裝載 Web 應用程式

Azure Front Door

Azure 應用程式閘道

Azure ExpressRoute

Azure DNS

管理工作負載的小組通常會依賴完整功能變數名稱 （FQDN） 進行客戶存取。 FQDN 通常會與傳輸層安全性 （TLS） 伺服器名稱指示 （SNI） 結合。 透過這種方法，當公用客戶從公用因特網或企業客戶存取工作負載時，內部存取工作負載時，對應用程式的路由可能會遵循固定路徑，並具有各種層級的安全性或服務品質（QoS）。

下列架構示範一種方法，以根據功能變數名稱系統（DNS）以及客戶來自因特網或公司網路來區分流量的處理方式。

建築

下載此架構的 Visio 檔案 。

下列工作流程區段描述兩個組態：公用因特網工作流程和私人工作流程。 結合這兩個工作流程來實作分割腦裝載架構。

公用因特網工作流程

下載此架構的 Visio 檔案 。

1. 客戶會透過公用因特網傳送 app.contoso.com 應用程式的要求。

2. Azure DNS 區域已針對 contoso.com 網域進行設定。 為 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. 網路安全組 （NSG） 是在 AppGW 子網上設定， 允許從 azureFrontDoor.Backend 服務卷標 埠 80 和埠 443 上的輸入存取。 NSG 不允許來自因特網服務標籤的埠 80 和埠 443 上的輸入流量。

   注意

   AzureFrontDoor.Backend 服務標籤不會只限制 Azure Front Door 實例的流量。 驗證會在下一個階段進行。

5. 應用程式閘道實例具有埠 443 上的 接聽程式 。 流量會根據接聽程式中指定的主機名路由傳送至後端。

   • 若要確保流量源自 您的 Azure Front Door 配置檔，請設定 自定義 WAF 規則 來檢查 X-Azure-FDID 標頭值。

   • Azure 會為每個 Azure Front Door 配置檔產生唯一標識符。 唯一標識碼是位於 Azure 入口網站概觀頁面上的 Front Door 識別碼 值。

6. 流量會到達應用程式閘道中設定為後端集區的計算資源。

私人企業工作流程

下載此架構的 Visio 檔案 。

1. 客戶會從內部部署環境起始 app.contoso.com 應用程式的要求。

2. 應用程式 FQDN 是在內部部署 DNS 提供者上設定。 此 DNS 提供者可以是內部部署 Windows Server Active Directory DNS 伺服器或其他合作夥伴解決方案。 每個應用程式 FQDN 的 DNS 專案都會設定為指向應用程式閘道實例的私人 IP 位址。

3. Azure ExpressRoute 線路或站對站 VPN 有助於存取應用程式閘道。

4. AppGW 子網上已設定 NSG，以允許來自流量來源的內部部署客戶網路連入私人要求。 此設定可確保其他私人流量來源無法直接連線到應用程式閘道的私人IP位址。

5. 應用程式閘道具有在埠 80 和埠 443 上設定的 接聽程式 。 流量會根據接聽程式中指定的主機名路由傳送至後端。

6. 只有專用網流量會到達在應用程式閘道中設定為後端集區的計算。

元件

• DNS：針對公用因特網工作流程，您必須使用 Azure Front Door 端點 FQDN 的適當 CNAME 來設定 公用 Azure DNS 區域 。 在私人（企業）端，設定本機 DNS 提供者（Windows Server Active Directory DNS 或合作夥伴解決方案），將每個應用程式 FQDN 指向應用程式閘道的私人 IP 位址。

• Azure DNS 私人解析程式：您可以使用 DNS 私人解析程序來解析內部部署客戶。 企業客戶可以使用這個分割腦 DNS 解決方案來取得應用程式的存取權，而不需要周遊公用因特網。

• 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 Load Balancer：Azure Load Balancer 是網路負載平衡器，可為傳輸控制通訊協定 （TCP） 和用戶數據報通訊協定 （UDP） 流量提供高可用性和延展性。 您可以使用 Load Balancer，而不是應用程式閘道，將外部和內部客戶要求路由傳送至後端網頁伺服器。 不過，應用程式閘道提供 WAF 功能、安全套接字層 （SSL） 終止和 Cookie 型會話親和性等功能。 Load Balancer 不提供這些功能。

案例詳細數據

此案例可解決裝載服務外部和內部客戶的 Web 應用程式的問題。 此架構可確保流量會根據客戶的來源遵循適當的路徑。 此架構：

• 為世界各地的非企業客戶提供透過因特網快速且可靠的 Web 應用程式存取。

• 提供企業客戶在不周遊公用因特網的情況下存取應用程式的能力。

• 保護 Web 應用程式免於常見的 Web 攻擊和惡意流量。

潛在的使用案例

針對需要下列情況的案例，請使用此架構：

• 分割腦 DNS：此解決方案會針對外部客戶使用 Azure Front Door，並為內部客戶使用應用程式閘道，並針對每個服務使用不同的 DNS 記錄。 此方法可協助優化各種客戶的網路效能、安全性和可用性。

• 應用程式延展性：此解決方案會使用應用程式閘道，以在已設定的後端計算資源之間散發流量。 這種方法有助於改善應用程式效能和可用性，並支援水平調整。

考慮

這些考量能實作 Azure Well-Architected Framework 的支柱，這是一組指導原則，可以用來改善工作負載的品質。 如需詳細資訊，請參閱 Well-Architected Framework。

可靠性

可靠性有助於確保您的應用程式可以符合您對客戶的承諾。 如需詳細資訊，請參閱 可靠性的設計檢閱檢查清單。

• 識別失敗點：在此分割腦 DNS 架構中，可靠性取決於重要元件的正確運作，例如 Azure Front Door、應用程式閘道和 DNS 設定。 您必須識別潛在的失敗點，例如設定錯誤、SSL 憑證問題或容量多載。

• 評估影響：您必須評估失敗的影響。 對於外部客戶，任何作為閘道的 Azure Front Door 中斷都可能會影響全球存取。 對於內部客戶而言，應用程式閘道的任何中斷都可能會妨礙企業作業。

• 實作風險降低策略：若要降低風險，請在 多個可用性區域實作備援、使用 健康情況探查 進行實時監視，並確保外部和內部流量的 DNS 路由設定正確。 請確定您定期更新 DNS 記錄，並有災害復原計劃。

• 持續監視：若要保持警惕您的系統健康情況，請使用 Azure 監視器功能。 設定 異常的警示，並備妥事件回應計劃，以及時解決潛在問題。

遵循這些原則，以確保能夠承受挑戰並維護服務持續性的健全且可靠的系統。

安全

安全性可提供針對蓄意攻擊和濫用寶貴數據和系統的保證。 如需詳細資訊，請參閱 安全性的設計檢閱檢查清單。

• 使用零信任方法：在分割腦 DNS 設定中，套用 零信任 方法。 明確驗證客戶的身分識別，無論是來自因特網還是公司網路。 此方法可確保只有受信任的實體會執行授權的動作。

• 實作：針對強固的身分識別管理實作Microsoft Entra ID。 使用Microsoft Entra 條件式存取原則，根據客戶內容、裝置健康情況和位置強制執行嚴格的訪問控制。

• 評估安全性效力：實作下列方法，評估雙重存取工作負載的安全性措施有效性：

  • 防禦性投資：定期評估 Azure Front Door 和應用程式閘道的有效性。 請確定它們能針對威脅提供有意義的保護。

  • 爆炸半徑限制：請確定您在有限範圍內包含安全性缺口。 例如，有效地隔離外部和內部流量。

• 假設有缺口：確認攻擊者可能會違反安全性控制措施。 準備這類案例。

• 實作安全性措施：實作網路分割、微分割和 NSG。 假設攻擊者可能會取得存取權，並據此設計補償控件。

將這些安全性原則整合到您的分割腦 DNS 架構中，以建立健全且具彈性的系統，以保護您的工作負載內部和外部存取。

其他安全性增強功能

• 應用程式閘道：您可以使用應用程式閘道上的 WAF 來保護 Web 應用程式免於常見的 Web 弱點和惡意探索。 您也可以使用 Azure Private Link 從應用程式閘道安全地存取後端應用程式伺服器，而不需將其公開至公用因特網。

• Azure 防火牆：您可以將 Azure 防火牆新增至中樞虛擬網路，並使用 Azure 防火牆威脅情報 來封鎖來自已知惡意 IP 位址和網域的惡意流量。 您也可以使用 Azure 防火牆作為 DNS Proxy 來攔截和檢查 DNS 流量，並套用 DNS 篩選規則。

• Azure Front Door：您可以使用 Azure Web 應用程式防火牆 來保護 Web 應用程式，避免邊緣常見的 Web 弱點和惡意探索。 您也可以使用 Private Link 搭配 Azure Front Door 進階層，安全地從 Azure Front Door 存取後端應用程式伺服器，而不需將其公開至公用因特網。

成本優化

成本優化著重於減少不必要的費用，並提升營運效率的方式。 如需詳細資訊，請參閱 成本優化的設計檢閱檢查清單。

• 後端計算：許多因素，例如 SKU 選取、複本計數和區域，都會驅動執行後端計算服務的成本。 請先確定您已考慮 計算資源 的所有元素，再選取工作負載的最佳選項。

• 應用程式閘道：應用程式閘道成本取決於實例數目、實例大小，以及已處理的數據量。 您可以使用 自動調整 來根據流量需求調整實例數目，以優化成本。 您也可以跨可用性區域部署 區域備援 SKU ，以減少額外實例的高可用性需求。

• Azure Front Door：Azure Front Door 成本取決於路由規則數目、HTTP 或 HTTPS 要求數目，以及傳輸的數據量。 您可以使用 Azure Front Door 標準層或進階層 來取得 Azure 內容傳遞網路、Azure Web 應用程式防火牆和 Private Link 的統一體驗。 您也可以使用 Azure Front Door 規則引擎功能 來自定義流量管理和優化效能和成本。

  如果您的案例不需要全域存取或 Azure Front Door 的額外功能，您可以只搭配應用程式閘道使用此解決方案。 您可以將所有公用 DNS 記錄指向應用程式閘道接聽程式上設定的公用 IP 位址。

請參閱 此解決方案的範例 ，此解決方案會大致瞭解此架構中元件的一般使用方式。 調整成本以符合您的案例。

貢獻

本文由 Microsoft 維護。 它最初是由下列參與者所撰寫。

主體作者：

• 特洛伊·希特 |資深雲端解決方案架構師

其他參與者：

• 梅斯·阿爾格巴里 |資深 Azure 網路全域黑帶
• Adam Torkar |資深 Azure 網路全域黑帶
• Michael McKechney |主要 Azure 技術專家

若要查看非公用LinkedIn配置檔，請登入LinkedIn。

後續步驟

• 應用程式閘道基礎結構組態
• 使用 Azure Front Door 端對端 TLS
• 將自定義網域新增至 Azure Front Door
• 什麼是 Azure Front Door 網域的異地篩選

相關資源

• 虛擬網路的防火牆和應用程式閘道
• 在多租用戶解決方案中使用 Azure Front Door

管理工作負載的小組通常會依賴完整功能變數名稱 （FQDN） 進行客戶存取。 FQDN 通常會與傳輸層安全性 （TLS） 伺服器名稱指示 （SNI） 結合。 透過這種方法，當公用客戶從公用因特網或企業客戶存取工作負載時，內部存取工作負載時，對應用程式的路由可能會遵循固定路徑，並具有各種層級的安全性或服務品質（QoS）。

下列架構示範一種方法，以根據功能變數名稱系統（DNS）以及客戶來自因特網或公司網路來區分流量的處理方式。

建築

下載此架構的 Visio 檔案 。

下列工作流程區段描述兩個組態：公用因特網工作流程和私人工作流程。 結合這兩個工作流程來實作分割腦裝載架構。

公用因特網工作流程

下載此架構的 Visio 檔案 。

1. 客戶會透過公用因特網傳送 app.contoso.com 應用程式的要求。

2. Azure DNS 區域已針對 contoso.com 網域進行設定。 為 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. 網路安全組 （NSG） 是在 AppGW 子網上設定， 允許從 azureFrontDoor.Backend 服務卷標 埠 80 和埠 443 上的輸入存取。 NSG 不允許來自因特網服務標籤的埠 80 和埠 443 上的輸入流量。

   注意

   AzureFrontDoor.Backend 服務標籤不會只限制 Azure Front Door 實例的流量。 驗證會在下一個階段進行。

5. 應用程式閘道實例具有埠 443 上的 接聽程式 。 流量會根據接聽程式中指定的主機名路由傳送至後端。

   • 若要確保流量源自 您的 Azure Front Door 配置檔，請設定 自定義 WAF 規則 來檢查 X-Azure-FDID 標頭值。

   • Azure 會為每個 Azure Front Door 配置檔產生唯一標識符。 唯一標識碼是位於 Azure 入口網站概觀頁面上的 Front Door 識別碼 值。

6. 流量會到達應用程式閘道中設定為後端集區的計算資源。

私人企業工作流程

下載此架構的 Visio 檔案 。

1. 客戶會從內部部署環境起始 app.contoso.com 應用程式的要求。

2. 應用程式 FQDN 是在內部部署 DNS 提供者上設定。 此 DNS 提供者可以是內部部署 Windows Server Active Directory DNS 伺服器或其他合作夥伴解決方案。 每個應用程式 FQDN 的 DNS 專案都會設定為指向應用程式閘道實例的私人 IP 位址。

3. Azure ExpressRoute 線路或站對站 VPN 有助於存取應用程式閘道。

4. AppGW 子網上已設定 NSG，以允許來自流量來源的內部部署客戶網路連入私人要求。 此設定可確保其他私人流量來源無法直接連線到應用程式閘道的私人IP位址。

5. 應用程式閘道具有在埠 80 和埠 443 上設定的 接聽程式 。 流量會根據接聽程式中指定的主機名路由傳送至後端。

6. 只有專用網流量會到達在應用程式閘道中設定為後端集區的計算。

元件

• DNS：針對公用因特網工作流程，您必須使用 Azure Front Door 端點 FQDN 的適當 CNAME 來設定 公用 Azure DNS 區域 。 在私人（企業）端，設定本機 DNS 提供者（Windows Server Active Directory DNS 或合作夥伴解決方案），將每個應用程式 FQDN 指向應用程式閘道的私人 IP 位址。

• Azure DNS 私人解析程式：您可以使用 DNS 私人解析程序來解析內部部署客戶。 企業客戶可以使用這個分割腦 DNS 解決方案來取得應用程式的存取權，而不需要周遊公用因特網。

• 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 Load Balancer：Azure Load Balancer 是網路負載平衡器，可為傳輸控制通訊協定 （TCP） 和用戶數據報通訊協定 （UDP） 流量提供高可用性和延展性。 您可以使用 Load Balancer，而不是應用程式閘道，將外部和內部客戶要求路由傳送至後端網頁伺服器。 不過，應用程式閘道提供 WAF 功能、安全套接字層 （SSL） 終止和 Cookie 型會話親和性等功能。 Load Balancer 不提供這些功能。

案例詳細數據

此案例可解決裝載服務外部和內部客戶的 Web 應用程式的問題。 此架構可確保流量會根據客戶的來源遵循適當的路徑。 此架構：

• 為世界各地的非企業客戶提供透過因特網快速且可靠的 Web 應用程式存取。

• 提供企業客戶在不周遊公用因特網的情況下存取應用程式的能力。

• 保護 Web 應用程式免於常見的 Web 攻擊和惡意流量。

潛在的使用案例

針對需要下列情況的案例，請使用此架構：

• 分割腦 DNS：此解決方案會針對外部客戶使用 Azure Front Door，並為內部客戶使用應用程式閘道，並針對每個服務使用不同的 DNS 記錄。 此方法可協助優化各種客戶的網路效能、安全性和可用性。

• 應用程式延展性：此解決方案會使用應用程式閘道，以在已設定的後端計算資源之間散發流量。 這種方法有助於改善應用程式效能和可用性，並支援水平調整。

考慮

這些考量能實作 Azure Well-Architected Framework 的支柱，這是一組指導原則，可以用來改善工作負載的品質。 如需詳細資訊，請參閱 Well-Architected Framework。

可靠性

可靠性有助於確保您的應用程式可以符合您對客戶的承諾。 如需詳細資訊，請參閱 可靠性的設計檢閱檢查清單。

• 識別失敗點：在此分割腦 DNS 架構中，可靠性取決於重要元件的正確運作，例如 Azure Front Door、應用程式閘道和 DNS 設定。 您必須識別潛在的失敗點，例如設定錯誤、SSL 憑證問題或容量多載。

• 評估影響：您必須評估失敗的影響。 對於外部客戶，任何作為閘道的 Azure Front Door 中斷都可能會影響全球存取。 對於內部客戶而言，應用程式閘道的任何中斷都可能會妨礙企業作業。

• 實作風險降低策略：若要降低風險，請在 多個可用性區域實作備援、使用 健康情況探查 進行實時監視，並確保外部和內部流量的 DNS 路由設定正確。 請確定您定期更新 DNS 記錄，並有災害復原計劃。

• 持續監視：若要保持警惕您的系統健康情況，請使用 Azure 監視器功能。 設定 異常的警示，並備妥事件回應計劃，以及時解決潛在問題。

遵循這些原則，以確保能夠承受挑戰並維護服務持續性的健全且可靠的系統。

安全

安全性可提供針對蓄意攻擊和濫用寶貴數據和系統的保證。 如需詳細資訊，請參閱 安全性的設計檢閱檢查清單。

• 使用零信任方法：在分割腦 DNS 設定中，套用 零信任 方法。 明確驗證客戶的身分識別，無論是來自因特網還是公司網路。 此方法可確保只有受信任的實體會執行授權的動作。

• 實作：針對強固的身分識別管理實作Microsoft Entra ID。 使用Microsoft Entra 條件式存取原則，根據客戶內容、裝置健康情況和位置強制執行嚴格的訪問控制。

• 評估安全性效力：實作下列方法，評估雙重存取工作負載的安全性措施有效性：

  • 防禦性投資：定期評估 Azure Front Door 和應用程式閘道的有效性。 請確定它們能針對威脅提供有意義的保護。

  • 爆炸半徑限制：請確定您在有限範圍內包含安全性缺口。 例如，有效地隔離外部和內部流量。

• 假設有缺口：確認攻擊者可能會違反安全性控制措施。 準備這類案例。

• 實作安全性措施：實作網路分割、微分割和 NSG。 假設攻擊者可能會取得存取權，並據此設計補償控件。

將這些安全性原則整合到您的分割腦 DNS 架構中，以建立健全且具彈性的系統，以保護您的工作負載內部和外部存取。

其他安全性增強功能

• 應用程式閘道：您可以使用應用程式閘道上的 WAF 來保護 Web 應用程式免於常見的 Web 弱點和惡意探索。 您也可以使用 Azure Private Link 從應用程式閘道安全地存取後端應用程式伺服器，而不需將其公開至公用因特網。

• Azure 防火牆：您可以將 Azure 防火牆新增至中樞虛擬網路，並使用 Azure 防火牆威脅情報 來封鎖來自已知惡意 IP 位址和網域的惡意流量。 您也可以使用 Azure 防火牆作為 DNS Proxy 來攔截和檢查 DNS 流量，並套用 DNS 篩選規則。

• Azure Front Door：您可以使用 Azure Web 應用程式防火牆 來保護 Web 應用程式，避免邊緣常見的 Web 弱點和惡意探索。 您也可以使用 Private Link 搭配 Azure Front Door 進階層，安全地從 Azure Front Door 存取後端應用程式伺服器，而不需將其公開至公用因特網。

成本優化

成本優化著重於減少不必要的費用，並提升營運效率的方式。 如需詳細資訊，請參閱 成本優化的設計檢閱檢查清單。

• 後端計算：許多因素，例如 SKU 選取、複本計數和區域，都會驅動執行後端計算服務的成本。 請先確定您已考慮 計算資源 的所有元素，再選取工作負載的最佳選項。

• 應用程式閘道：應用程式閘道成本取決於實例數目、實例大小，以及已處理的數據量。 您可以使用 自動調整 來根據流量需求調整實例數目，以優化成本。 您也可以跨可用性區域部署 區域備援 SKU ，以減少額外實例的高可用性需求。

• Azure Front Door：Azure Front Door 成本取決於路由規則數目、HTTP 或 HTTPS 要求數目，以及傳輸的數據量。 您可以使用 Azure Front Door 標準層或進階層 來取得 Azure 內容傳遞網路、Azure Web 應用程式防火牆和 Private Link 的統一體驗。 您也可以使用 Azure Front Door 規則引擎功能 來自定義流量管理和優化效能和成本。

  如果您的案例不需要全域存取或 Azure Front Door 的額外功能，您可以只搭配應用程式閘道使用此解決方案。 您可以將所有公用 DNS 記錄指向應用程式閘道接聽程式上設定的公用 IP 位址。

請參閱 此解決方案的範例 ，此解決方案會大致瞭解此架構中元件的一般使用方式。 調整成本以符合您的案例。

貢獻

本文由 Microsoft 維護。 它最初是由下列參與者所撰寫。

主體作者：

• 特洛伊·希特 |資深雲端解決方案架構師

其他參與者：

• 梅斯·阿爾格巴里 |資深 Azure 網路全域黑帶
• Adam Torkar |資深 Azure 網路全域黑帶
• Michael McKechney |主要 Azure 技術專家

若要查看非公用LinkedIn配置檔，請登入LinkedIn。

後續步驟

• 應用程式閘道基礎結構組態
• 使用 Azure Front Door 端對端 TLS
• 將自定義網域新增至 Azure Front Door
• 什麼是 Azure Front Door 網域的異地篩選

相關資源

• 虛擬網路的防火牆和應用程式閘道
• 在多租用戶解決方案中使用 Azure Front Door