Azure 登陸區域中的 Azure 虛擬機器 基準架構

本文中的架構會 擴充虛擬機 （VM） 基準架構 ，以在 Azure 登陸區域中部署虛擬機時解決變更和預期。

在本文中的範例中，組織希望以 VM 為基礎的工作負載使用平臺小組集中管理的同盟資源。 這些資源包括跨單位連線的網路資源、身分識別存取管理和原則。 此範例假設組織採用 Azure 登陸區域，以跨多個工作負載強制執行一致的治理和成本效益。

身為工作負載擁有者，您可以將共用資源的管理卸除給中央小組，以便專注於工作負載開發工作。 本文呈現工作負載小組的觀點。 已指定平臺小組的 建議。

文章版面配置

架構	設計決策	Azure 架構完善的架構方法
▪ 架構圖 ▪ 工作負載資源 ▪ 同盟資源	▪ 訂用帳戶設定 ▪ 網路需求 ▪ 來自基準的網路設計變更 ▪ 監測 ▪ 修補程式合規性 ▪ 組織治理 ▪ 變更管理	▪ 可靠性 ▪ 安全 ▪ 成本優化

架構

下載此架構的 Visio 檔案。

元件

所有 Azure 登陸區域架構都有平臺小組與工作負載小組之間的擁有權區隔。 應用程式架構設計人員和 DevOps 小組必須充分瞭解此責任分割，以瞭解其直接影響或控制下的內容，以及哪些不是。

工作負載小組擁有的資源

下列資源與基準架構大多保持不變。

• Azure 虛擬機器 是應用程式平臺。 計算資源會分散到可用性區域。

• Azure Load Balancer 可用來私下負載平衡從前端 VM 到後端 VM 的流量。 負載平衡器會將流量分散到跨區域 VM。

• Azure 應用程式閘道 會作為反向 Proxy，將使用者要求路由傳送至前端 VM。 選取的 SKU 也可用來裝載 Azure Web 應用程式防火牆，以保護前端 VM 免於潛在的惡意流量。

• Azure 金鑰保存庫 可用來儲存應用程式秘密和憑證。

• Azure 監視器、Log Analytics 和 Application Insights 可用來收集、儲存和可視化可檢視性數據。

• Azure 原則 可用來套用工作負載特有的原則。

工作負載小組會維護並履行下列資源和責任。

• 輪輻虛擬網路子網和放在這些子網上的網路安全組（NSG）， 以維持分割和控制流量。

• 私人端點 可保護平臺即服務 （PaaS） 解決方案的連線，以及 這些端點所需的私人 DNS 區域 。

• Azure 受控磁碟 會將記錄檔儲存在後端伺服器上，即使 VM 重新啟動，也會保留數據。 前端伺服器已連結磁碟，可用來部署無狀態應用程式。

平臺小組擁有的資源

平臺小組擁有和維護這些集中式資源。 此架構假設這些資源已預先布建，並考慮其相依性。

• 中樞網路中 Azure 防火牆 用來檢查和限制輸出流量。 此元件會取代基準架構中的標準負載平衡器，但不會對因特網的輸出流量提供限制。

• 中樞網路中 Azure Bastion 提供對工作負載 VM 的安全作業存取。 在基準架構中，工作負載小組擁有此元件。

• 輪 輻虛擬網路 是部署工作負載的位置。

• 用戶定義的路由 （UDR） 可用來強制通道傳送至中樞網路。

• Azure 原則 型治理條件約束和 DeployIfNotExists （DINE） 原則是工作負載訂用帳戶的一部分。

訂用帳戶設定

在登陸區域內容中，您的工作負載小組必須通知平臺小組其特定需求。

您的 工作負載小組 必須包含工作負載所需的網路空間詳細資訊，讓平臺小組可以配置必要的資源。 您的小組會決定需求，而平臺小組會決定在虛擬網路內指派的IP位址，以及指派訂用帳戶的管理群組。

平臺 小組 會根據工作負載的業務關鍵性和技術需求，指派適當的管理群組，例如，如果工作負載公開至因特網。 組織會決定這些管理群組的組態，而平臺小組會實作這些群組。

例如，系統會考慮基準架構之應用程式案例中的管理群組：

• 私人應用程式，例如內部企業營運應用程式或現成商業解決方案，這些解決方案通常位於 Azure 登陸區域的公司管理群組之下。

• 公用應用程式，如同因特網面向應用程式，這些應用程式通常位於 Corp 或 Online 管理群組之下。

平臺小組也會負責設定工作負載部署的訂用帳戶或訂用帳戶群組。

下列各節提供初始訂用帳戶設定的指引。 不過，平臺小組通常會變更集中式服務，以解決遺漏或變更的需求。 平台變更對所有工作負載小組都有更廣泛的影響。

因此，平臺小組必須確保所有 VM 工作負載都已針對任何變更做好準備，而且必須注意 VM 型解決方案和測試週期的生命週期。 如需詳細資訊，請參閱 管理一段時間的變更。

工作負載需求和履行

工作負載小組和平臺小組有兩個主要責任：管理群組指派和網路設定。 針對此架構，請考慮您應該與平臺小組通訊的下列網路需求。 當您實作類似的架構時，請使用這些點作為範例，以瞭解兩個小組之間的討論和交涉。

• 輪輻虛擬網路數目：在此架構中，只需要一個專用輪輻。 已部署的資源不需要跨越多個網路，而且會共置在單一虛擬網路內。

• 輪輻網路的大小：將作業需求和工作負載的預期成長納入考慮。 例如，如果您打算實作藍色/綠色或 Canary 更新，大小上限應該會考慮您並存部署所需的空間。

  未來的變更可能需要更多IP空間，這可能會與目前的配置不符。 這些空間的整合可能會帶來額外的複雜性。 主動並事先要求足夠的網路資源，以確保配置的空間可以容納未來的擴充。

• 部署區域：請務必指定將部署工作負載的區域。 平臺小組可以使用這項資訊來確保輪輻和中樞虛擬網路已布建在相同的區域中。 跨不同區域的網路可能會導致延遲問題，因為流量跨越區域界限，也可能會產生額外的頻寬成本。

• 工作負載特性和設計選擇：將設計選擇、元件和特性傳達給平臺小組。 例如，如果您預期工作負載會產生大量並行連線到因特網 （chatty），平臺小組應確保有足夠的埠可供使用，以避免耗盡。 他們可以將IP位址新增至集中式防火牆，以支援流量，或設定網路位址轉換 （NAT） 網關，以透過替代路徑路由傳送流量。

  相反地，如果您預期工作負載會產生最少的網路流量（背景雜訊），平臺小組應該在整個組織中有效率地使用資源。

  平臺小組必須清楚瞭解任何相依性。 例如，您的工作負載可能需要存取另一個小組擁有的資料庫，或您的工作負載可能有跨單位流量。 您的工作負載是否具有 Azure 以外的相依性？ 這類信息對於平臺小組而言很重要。

• 防火牆組態：平臺小組必須注意離開輪輻網路的流量，並透過通道傳送至中樞網路。 中樞中的防火牆無法封鎖該流量。

  例如，如果您的工作負載需要存取 Windows 更新以保持修補，防火牆不應該封鎖這些更新。 同樣地，如果有可存取特定端點的監視器代理程式，防火牆不應該封鎖該流量，因為它可能會中斷工作負載的監視數據。 應用程式可能需要存取第三方端點。 無論如何，請使用集中式防火牆來區分預期和不必要的流量。

• 操作員存取：如果有操作員用來透過 Azure Bastion 存取 VM 的 Microsoft Entra ID 安全組，請通知平臺小組。 Azure Bastion 通常是中央資源。 請務必確保安全組和 VM 支援安全通訊協定。

  此外，請通知平臺小組包含 VM 的 IP 範圍。 在中樞網路中設定 Azure Bastion 周圍的 NSG 時，需要此資訊。

• 公用IP：通知平臺小組輸入流量配置檔，包括任何預期的公用IP位址。 在此架構中，只有因特網來源的流量會以 應用程式閘道 上的公用IP為目標。 如果這些IP屬於 Azure DDoS 保護方案，或工作負載小組的責任，平臺小組應該通知工作負載小組。

  在此架構中，有另一個公用IP可透過Azure Bastion進行作業存取。 平臺小組擁有此公用IP，且已註冊服務，例如平臺小組所管理的 DDoS 保護。

VM 設計選擇

VM SKU 和磁碟選取項目會維持與 基準架構相同。

組織可能會對授權使用特定 VM 映像的工作負載小組施加合規性需求。 鑒於這類需求，平臺小組可能會管理一組標準化映像，這通常稱為 「黃金映射」，這些映像是建立供整個組織使用。

平臺小組可能會使用受控供應專案，例如 Azure 計算資源庫或私人存放庫來儲存已核准的 OS 映射或工作負載成品。 當您選擇 VM 的 OS 映射時，請洽詢平臺小組以取得映射來源、更新頻率和使用量預期。 也請確定映像可以符合工作負載滿足的必要商務需求。

網路

在基準架構中，工作負載會布建在單一虛擬網路中。 工作負載小組會管理虛擬網路。

在此架構中，平臺小組會決定網路拓撲。 此架構中假設中樞輪輻拓撲。

下載此架構的 Visio 檔案。

• 中樞虛擬網路：區域中樞包含與相同區域中工作負載資源通訊的集中式服務。 如需詳細資訊，請參閱 平臺小組擁有的資源。 建議將中樞放在連線訂用帳戶中。

• 輪輻虛擬網路：在此架構中，來自基準架構的單一虛擬網路是輪輻網路。 其會與中樞網路對等互連，其中包含集中式服務。 平臺小組擁有和管理此輪輻網路。 此網路包含 工作負載資源。 工作負載小組擁有此網路中的資源，包括其子網。

請確定您將 工作負載需求 傳達給平臺小組，並定期檢閱。

虛擬網路子網路

在輪輻虛擬網路中，工作負載小組會建立並配置子網。 放置控件來限制子網進出的流量有助於提供分割。 此架構會使用與基準架構相同的子網拓撲，其具有專用子網，適用於 應用程式閘道、前端 VM、負載平衡器、後端 VM 和私人端點。

當您在 Azure 登陸區域中部署工作負載時，您仍然需要實作網路控制。 組織可能會施加限制，以防止數據外泄，並確保中央安全性作業中心 （SOC） 和 IT 網路小組的可見度。

使用這種方法，平臺小組可以使用集中式服務來優化整體組織支出，而不是針對整個組織的每個工作負載部署備援安全性控制。 在此架構中，Azure 防火牆 是中央服務的範例。 對於每個工作負載小組來說，管理自己的防火牆實例並不符合成本效益或實用。 我們建議使用集中式的防火牆管理方法。

輸入流量

輸入流量流程會維持與 基準架構相同。

工作負載擁有者負責與公用因特網輸入至工作負載相關的任何資源。 例如，在此架構中，應用程式閘道 及其公用IP會放在輪輻網路中，而不是中樞網路。 某些組織可能會使用集中式非軍事化 （DMZ） 實作，將具有輸入流量的資源放在聯機訂用帳戶中。 與該特定拓撲的整合已脫離本文的範圍。

輸出流量

在基準架構中，工作負載虛擬機擴展集會透過 Azure Load Balancer 存取公用因特網，但流量不受限制。

這種設計在此架構中不同。 離開輪輻虛擬網路的所有流量都會透過對等互連中樞網路透過輸出防火牆路由傳送。 路由會連結至輪輻網路中所有可能的子網，以將本機虛擬網路 （0.0.0.0.0/0） 中找不到的所有IP流量導向至中樞的 Azure 防火牆。

下載此架構的 Visio 檔案。

金鑰保存庫 存取的私人端點的工作負載通訊仍與基準架構相同。 為了簡潔起見，此路徑會從上圖中省略。

工作負載小組必須識別、記錄及傳達基礎結構和工作負載作業所需的所有輸出流量流程。 平臺小組允許必要的流量，而且所有未認可的輸出流量都可能會遭到拒絕。

控制輸出流量不僅僅是確保允許預期的流量。 這也是為了確保 只 允許預期的流量。 預設可能會拒絕未通訊的輸出流量，但它在工作負載的最佳安全性利益中，以確保流量已正確路由。

將任何獨特的輸出流量需求傳達給平臺小組。 例如，如果您的工作負載會建立與外部網路端點的許多並行連線，請通知平臺小組。 然後，平臺小組可以在區域防火牆上布建適當的 Azure NAT 閘道實作，或新增更多公用 IP 以降低風險。

您的組織可能會有需求，而不要使用架構模式，而此模式會使用工作負載擁有的公用IP進行輸出。 在此情況下，您可以使用 Azure 原則 來拒絕 VM 網路介面卡 （NIC） 和任何其他公用 IP，但您已知的輸入點以外的任何其他公用 IP。

私人 DNS 區域

使用私人端點的架構需要私人 DNS 區域才能與 DNS 提供者搭配使用。 工作負載小組必須清楚瞭解平臺小組所提供的訂用帳戶中私人 DNS 區域的需求和管理。 私用 DNS 區域通常會使用 DINE 原則大規模管理，這可讓 Azure 防火牆 作為可靠的 DNS Proxy 運作，並支援完整功能變數名稱 （FQDN） 網路規則。

在此架構中，平臺小組可確保私人連結端點的可靠私人 DNS 解析。 與您的平臺小組共同作業，以瞭解其期望。

連線 能力測試

針對以 VM 為基礎的架構，有數個測試工具可協助判斷網路視線、路由和 DNS 問題。 您可以使用傳統疑難解答工具，例如 netstat、 nslookup或 tcping。 此外，您可以檢查網路適配器的動態主機設定通訊協定 （DHCP） 和 DNS 設定。 如果有 NIC，您有更多疑難解答功能可讓您使用 Azure 網路監看員 來執行連線檢查。

操作員存取

如同基準架構，此架構支援透過 Azure Bastion 的作業存取。

不過，基準架構會將 Azure Bastion 部署為工作負載的一部分。 對於採用 Azure 登陸區域的一般組織，他們會將 Azure Bastion 部署為每個區域的中央資源。 平臺小組擁有和維護 Azure Bastion，且組織中的所有工作負載都會共用。 為了示範此架構中的使用案例，Azure Bastion 位於聯機訂用帳戶中的中樞網路。

操作員身分識別

此架構會使用與 基準架構相同的驗證延伸模組。

一律從最低許可權和細微存取工作的原則開始，而不是長期存取。 在登陸區域內容中，利用平臺小組所管理的 Just-In-Time （JIT） 支援。

修補合規性和OS升級

基準 架構 描述修補和升級的自主方法。 當工作負載與登陸區域整合時，該方法可能會變更。 平臺小組可能會指定修補作業，讓所有工作負載都符合組織需求。

請確定修補程式包含您新增至架構的所有元件。 例如，如果您選擇新增組建代理程式 VM 來自動化應用程式的部署、調整和管理，這些 VM 必須符合平臺需求。

監視

Azure 登陸區域平臺會在管理訂用帳戶中提供共用的可觀察性資源。 不過，我們建議您布建自己的監視資源，以協助工作負載的擁有權責任。 此方法與 基準架構一致。

工作負載小組會佈建監視資源，包括：

• Application Insights 作為工作負載小組的應用程式效能監視 （APM） 服務。

• Log Analytics 工作區是從工作負載擁有的 Azure 資源和應用程式程式代碼收集的所有記錄和計量的統一接收。

下載此架構的 Visio 檔案。

與基準類似，所有資源都會設定為將 Azure 診斷 記錄傳送至Log Analytics工作區，工作負載小組會在基礎結構即程序代碼 （IaC） 部署資源時布建。 您可能也需要將記錄傳送至中央 Log Analytics 工作區。 在 Azure 登陸區域中，該工作區位於管理訂用帳戶中。

平臺小組可能也有可用來設定診斷以將記錄傳送至其集中式管理訂用帳戶的 DINE 原則。 請務必確定您的實作不會限制額外的記錄流程。

將多個接收的數據相互關聯

工作負載的記錄和計量及其基礎結構元件會儲存在工作負載的Log Analytics工作區中。 不過，集中式服務的記錄和計量，例如 Azure 防火牆、Microsoft Entra ID 和 Azure Bastion，都會儲存在中央 Log Analytics 工作區中。 將來自多個接收的數據相互關聯可能是一項複雜的工作。

事件回應期間通常會使用相互關聯的數據。 如果有多個接收的數據相互關聯時發生問題，請確定此架構的分級 Runbook 可加以解決，並在問題超出工作負載資源時包含組織連絡點。 工作負載系統管理員可能需要平台系統管理員的協助，以將企業網路、安全性或其他平臺服務的記錄專案相互關聯。

Azure 原則

平臺小組可能會套用會影響工作負載部署的原則。 他們通常會套用 DINE 原則，以將自動化部署處理到應用程式登陸區域訂用帳戶。 DINE 原則可以修改工作負載資源，或將資源新增至您的部署，這可能會導致透過工作負載範本以宣告方式部署的資源與處理要求實際使用的資源不一致。 典型的解決方案是使用不理想的命令式方法來修正這些變更。

為了避免這種差異，請先先將平臺起始的變更並測試到您的 IaC 範本中。 如果平臺小組使用與應用程式需求衝突的 Azure 原則，您可以與平臺小組交涉解決方案。

管理一段時間的變更

平臺提供的服務和作業會被視為此架構中的外部相依性。 平臺小組會繼續套用變更、上線使用者，以及套用成本控制。 為組織服務的平臺小組可能不會排定個別工作負載的優先順序。 這些相依性的變更，無論是金映像變更、防火牆修改、自動化修補或規則變更，都可能會影響多個工作負載。

因此，工作負載和平臺小組必須有效率且及時地通訊，才能管理所有外部相依性。 測試變更很重要，因此它們不會對工作負載造成負面影響。

影響工作負載的平台變更

在此架構中，平臺小組會管理下列資源。 這些資源的變更可能會影響工作負載的可靠性、安全性、作業和效能目標。 在平臺小組生效之前，請務必先評估這些變更，以判斷它們如何影響工作負載。

• Azure 原則：變更 Azure 原則可能會影響工作負載資源及其相依性。 例如，可能會有直接的原則變更或將登陸區域移至新的管理群組階層。 在有新的部署之前，這些變更可能會被忽視，因此請務必徹底測試這些變更。

• 防火牆規則：修改防火牆規則可能會影響工作負載的虛擬網路或廣泛套用至所有流量的規則。 這些修改可能會導致流量遭到封鎖，甚至是無訊息進程失敗，例如OS修補程式的失敗應用程式。 這些潛在問題同時適用於輸出 Azure 防火牆和 Azure 虛擬網絡 管理員套用的 NSG 規則。

• 共用資源：共用資源上 SKU 或功能的變更可能會影響工作負載。

• 中樞網路的路由：如果工作負載相依於路由至其他虛擬網路，中樞路由的可轉移本質變更可能會影響工作負載功能。

• Azure Bastion 主機：Azure Bastion 主機可用性或設定的變更可能會影響工作負載作業。 確定跳板箱存取模式變更具有有效的例程、臨機操作和緊急存取。

• 擁有權變更：將擁有權和連絡點的任何變更傳達給工作負載小組，因為它們可能會影響工作負載的管理和支援要求。

影響平臺的工作負載變更

下列範例是此架構中的工作負載變更，您應該與平臺小組通訊。 平臺小組務必先驗證平臺服務的可靠性、安全性、作業和效能目標，再對新的工作負載小組變更生效。

• 網路輸出：監視網路輸出的任何顯著增加，以防止工作負載成為網路裝置上的嘈雜鄰居。 此問題可能會影響其他工作負載的效能或可靠性目標。

• 公用存取：對工作負載元件的公用存取變更可能需要進一步測試。 平臺小組可能會將工作負載重新放置到不同的管理群組。

• 業務關鍵性評等：如果工作負載的服務等級協定（SLA）有變更，您可能需要平臺和工作負載小組之間的新共同作業方法。

• 擁有權變更：將擁有權變更和連絡點的變更傳達給平臺小組。

工作負載商務需求變更

若要維護工作負載的服務等級目標（SLO），平臺小組可能需要參與工作負載架構變更。 這些變更可能需要來自平臺小組的變更管理，或現有治理支持變更需求的驗證。

例如，將變更傳達給任何先前不允許的輸出流程，讓平臺小組可以在防火牆、虛擬網絡 管理員或其他元件中新增該流程，以支援所需的流量。 相反地，如果不再需要先前允許的輸出流程，平臺小組應該封鎖該流程，以維護工作負載的安全性。 同時將路由傳送至其他虛擬網路或跨單位端點的變更，或對架構元件的變更進行通訊。 每個資源都受限於原則和潛在的輸出防火牆控制。

可靠性

此架構符合基準架構中的可靠性保證。

可靠性目標

由於輸出網路控制等元件，可能的最大複合 SLO 低於基準複合 SLO 。 這些元件在登陸區域環境中很常見，並不在此架構中是唯一的。 如果工作負載小組直接控制這些 Azure 服務，SLO 也會同樣減少。

儘管 SLO 可能較低，但關鍵可靠性層面是跨功能小組的工作負載元件劃分。 使用此方法時，工作負載小組受益於專門小組，其著重於此工作負載和其他工作負載所使用的重要基礎結構。

如需詳細資訊，請參閱定義可靠性目標的 建議。

重要相依性

檢視工作負載在平臺和應用程式登陸區域中執行的所有功能作為相依性。 事件回應計劃要求工作負載小組知道這些相依性的連絡資訊點和方法。 在工作負載的失敗模式分析中也包含這些相依性（FMA）。

針對此架構，請考慮下列相依性：

• 輸出防火牆：由多個工作負載共用的集中式輸出防火牆會進行與工作負載無關的變更。

• 網路埠耗盡：共用網路裝置之所有工作負載的使用量尖峰可能會導致網路飽和或輸出防火牆上的埠耗盡。

• DINE 原則：Azure DNS 私人 DNS 區域的 DINE 原則（或任何其他平臺提供的相依性）是 最佳作法，執行時沒有 SLA。 DNS 設定的延遲可能會導致應用程式整備處理流量的延遲。

• 管理組策略：環境之間的一致原則是可靠性的關鍵。 請確定生產階段前環境類似於生產環境，以提供精確的測試，並防止可能會封鎖部署或調整的環境特定偏差。 如需詳細資訊，請參閱 管理 Azure 登陸區域中的應用程式開發環境。

其中許多考慮可能不存在於 Azure 登陸區域，但工作負載和平臺小組需要共同解決這些問題，以確保符合需求。

如需詳細資訊，請參閱執行失敗模式分析 建議。

安全性

此架構的安全性考慮會從 基準架構繼續執行。 下列各節中的建議是以良好架構架構架構中的安全性設計檢閱檢查清單為基礎。

網路控制

正確設定網路控制，以確保您的工作負載安全。

輸入流量

您可以透過子網上的 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）	前端 VM 子網上的 UDP/123 對因特網 （輸出防火牆會縮小此廣泛開放範圍）	與工作負載控制相同的防火牆網路規則額度
Windows Update 端點	Microsoft 伺服器的 Windows Update 功能	後端 VM 子網上的 TCP/443 和 TCP/80 對因特網（輸出防火牆會縮小此廣泛開放範圍）	具有 FQDN 標籤的防火牆津貼規則 WindowsUpdate
監視代理程式端點	VM 上監視擴充功能的必要流量	這兩個 VM 子網上的 TCP/443 對因特網 （輸出防火牆會縮小這個廣泛的開放範圍）	TCP/443 上 所有特定 FQDN 的必要防火牆應用程式規則額度
nginx.org	直接從廠商安裝 Nginx （範例應用程式元件）	前端 VM 子網上的 TCP/443 到因特網（輸出防火牆會縮小此廣泛開放範圍）	TCP/443 上 nginx.org 的必要防火牆應用程式規則額度
金鑰保存庫	若要在 應用程式閘道 和 VM 中匯入 （傳輸層安全性） TLS 憑證	- 從這兩個 VM 子網到私人端點子網的私人端點子網 TCP/443 - 從 應用程式閘道 子網到私人端點子網的 TCP/443 - 以必要的應用程式安全組 （ASG） 指定和 應用程式閘道 子網標記的 VM TCP/443	無

DDoS 保護

判斷誰負責套用 DDoS 保護計劃，其中包含您解決方案的所有公用 IP。 平臺小組可能會使用IP保護方案，甚至可能使用 Azure 原則來強制執行虛擬網路保護計劃。 此架構應該具有涵蓋範圍，因為它牽涉到從因特網輸入的公用IP。

如需詳細資訊，請參閱網路和連線能力 建議。

秘密管理

針對秘密管理，此架構會 遵循基準架構。

身為工作負載小組，請繼續將秘密保留在 金鑰保存庫 實例中。 視需要部署更多實例以支援您的應用程式和基礎結構作業。

如需詳細資訊，請參閱保護應用程式秘密 建議。

成本最佳化

針對工作負載資源，基準架構中的成本優化策略也適用於此架構。

此架構可大幅受益於 Azure 登陸區域平台資源。 即使您透過退款模型使用這些資源，新增的安全性和跨單位連線比自我管理這些資源更有成本效益。

平臺小組會管理此架構中的下列資源。 這些資源通常是以耗用量為基礎的（退款）或可能免費給工作負載小組。

• Azure 防火牆
• 安全性資訊及事件管理 (SIEM)
• Azure Bastion 主機
• 跨單位連線能力，例如 ExpressRoute

利用平臺小組的其他集中式供應專案，將這些優點延伸到您的工作負載，而不會影響其 SLO、復原時間目標（RTO）或恢復點目標（RPO）。

如需詳細資訊，請參閱 建議 來收集和檢閱成本數據。

部署此案例

此參考架構的部署可在 GitHub 上取得。

後續步驟

檢閱工作負載小組與平臺小組之間共用的共同作業和技術詳細數據。

訂閱自動售貨