本文說明 Azure NAT 閘道的最佳做法。 此指引以架構卓越五大要素為基礎：成本優化、營運卓越、效能效率、可靠性和安全性。
作為本指南的必要條件，您應該具備 Azure NAT 閘道的工作知識，並瞭解其各自的功能。 如需詳細資訊，請參閱 Azure NAT 閘道檔。
成本最佳化
透過 Azure Private Link 或服務端點設定平臺即服務 （PaaS） 解決方案的存取權，包括記憶體，因此您不需要使用 NAT 閘道。 Private Link 和服務端點不需要周遊 NAT 閘道才能存取 PaaS 服務。 相較於使用 NAT 閘道的成本，這種方法可降低已處理數據的每 GB 成本。 Private Link 和服務端點也提供安全性優點。
效能效益
每個 NAT 閘道資源每秒最多可提供 50 GB 的輸送量。 您可以將部署分割成多個子網，然後將 NAT 閘道指派給每個子網或子網群組以相應放大。
每個 NAT 閘道公用 IP 位址都提供 64,512 個來源網路位址轉換 （SNAT） 埠。 您可以將最多 16 個 IP 位址指派給 NAT 閘道，包括個別的標準公用 IP 位址、公用 IP 前綴或兩者。 針對每個傳送至相同目的地端點的已指派輸出 IP 位址，NAT 閘道可分別支援傳輸控制通訊協定 （TCP） 和使用者數據報通訊協定 （UDP） 最多 50,000 個並行流量。
SNAT 耗盡
請考慮下列指引來協助防止 SNAT 耗盡：
NAT 閘道資源的預設 TCP 閑置逾時為四分鐘。 您可以設定最多 120 分鐘的逾時。 如果您將此設定變更為高於預設值的值，NAT 閘道會保留較長的流量，這可能會對 SNAT 埠清查造成不必要的壓力。
不可部分完成的要求（每個連線一個要求）會限制規模、降低效能，並減少可靠性。 您可以重複使用 HTTP 或 HTTPS 連線，以減少連線數目和相關聯的 SNAT 連接埠，而不是不可部分完成的要求。 當您重複使用連線時，應用程式可以更妥善地調整規模。 當您使用傳輸層安全性 （TLS） 時，應用程式效能會因為握手、額外負荷和密碼編譯作業成本降低而改善。
如果您未快取 DNS 解析程式的結果，功能變數名稱系統 （DNS） 查閱可以在磁碟區導入許多個別流程。 使用 DNS 快取來減少流量，並減少 SNAT 埠的數目。 DNS 是命名系統，會將域名對應至連線至因特網或專用網之資源的IP位址。
UDP 流程，例如 DNS 查閱，會在閒置逾時期間使用 SNAT 連接埠。 UDP 閑置逾時定時器固定在四分鐘。
使用連接集區來塑造您的連線磁碟區。
若要清除流程，請勿以無訊息方式放棄 TCP 流程或依賴 TCP 定時器。 如果您不讓 TCP 明確關閉連線，TCP 聯機會保持開啟狀態。 中繼系統和端點會讓此連線保持使用，讓 SNAT 埠無法供其他連線使用。 此反模式可以觸發應用程式失敗和 SNAT 耗盡。
除非您知道含意，否則請勿變更OS層級TCP關閉相關定時器值。 如果連線的端點有不相符的預期，TCP 堆疊可以復原，但可能會對您的應用程式效能造成負面影響。 如果您需要變更定時器值，通常會有基礎設計問題。 而且，如果基礎應用程式有其他反模式，而且您改變定時器值，您可能也會加速 SNAT 耗盡。
請檢閱下列指引，以改善服務的規模和可靠性：
請考慮將 TCP 閑置逾時減少為較低值的效果。 默認閑置逾時為四分鐘，可以預先釋放 SNAT 埠清查。
請考慮長時間執行作業的異步輪詢模式，以釋出其他作業的聯機資源。
請考慮針對長時間執行的 TCP 流量使用 TCP keepalives 或應用層 keepalives，例如重複使用的 TCP 連線，以防止中繼系統逾時。您應該只將閑置逾時增加為最後手段，而且可能無法解決根本原因。 當逾時到期時，長時間逾時可能會導致低速率失敗。 它也可能會造成延遲和不必要的失敗。 您可以從連線的一端啟用 TCP Keepalives，讓兩端的連線保持運作。
請考慮針對長時間執行的 UDP 流量使用 UDP Keepalives，以防止中繼系統逾時。當您在連線的一端啟用 UDP Keepalives 時，只有一端的聯機會保持作用中。 您必須在連線的兩端啟用 UDP Keepalives，才能讓連線保持運作。
請考慮正常重試模式，以避免在暫時性失敗或失敗復原期間發生主動式重試和高載。 針對反模式 不可部分完成的連線，您會為每個 HTTP 作業建立新的 TCP 連線。 不可部分完成的聯機會浪費資源，並防止您的應用程式調整良好。
若要提高交易速度並降低應用程式的資源成本，請一律將多個作業管線至相同的連線。 當您的應用程式使用傳輸層加密時，例如TLS，新的連線處理會增加成本。 如需更多最佳做法模式，請參閱 Azure 雲端設計模式。
卓越營運
您可以使用 NAT 閘道搭配 Azure Kubernetes Service （AKS），但 NAT 閘道管理並未包含在 AKS 中。 如果您將 NAT 閘道指派給容器網路介面 （CNI） 子網，您可以啟用 AKS Pod 透過 NAT 閘道輸出。
當您跨區域或區域使用多個 NAT 閘道時，請使用 Azure 公用 IP 前置碼或自備 IP （BYOIP） 前綴，讓輸出 IP 資產保持可管理。 您無法將大於 16 個 IP 位址的 IP 前置詞大小（/28 前置詞大小）指派給 NAT 閘道。
使用 Azure 監視器警示來監視和警示 SNAT 埠使用量、處理或卸載的封包，以及傳輸的數據量。 使用網路安全組 （NSG） 流量記錄來監視 NAT 閘道設定子網中虛擬機器 （VM） 實例的輸出流量。
當您使用 NAT 閘道設定子網時，NAT 閘道會取代該子網上所有 VM 對公用因特網的所有其他輸出連線。 不論輸出規則為何，NAT 閘道都會優先於負載平衡器。 網關也會優先於直接指派給 VM 的公用 IP 位址。 Azure 會追蹤流程的方向，並防止非對稱式路由。 輸入原始流量，例如負載平衡器前端IP，會正確轉譯，而且會透過NAT閘道與輸出原始流量分開轉譯。 此區隔可讓輸入和輸出服務順暢地共存。
建議使用 NAT 閘道作為預設值，以啟用虛擬網路的輸出連線。 相較於 Azure 中的其他輸出連線技術，NAT 閘道可提供效率和操作簡單性。 NAT 閘道會視需要配置 SNAT 埠，並使用更有效率的演算法來防止 SNAT 埠重複使用衝突。 請勿依賴 資產的默認輸出連線 能力反模式。 請改為使用 NAT 閘道資源明確定義您的設定。
可靠性
NAT 閘道資源在一個可用性區域中具有高可用性，而且跨越多個容錯網域。 您可以將 NAT 閘道 部署到沒有區域 ，Azure 會自動選取區域來放置 NAT 閘道，或將 NAT 閘道隔離至特定可用性區域。
若要提供可用性區域隔離，每個子網必須只有特定區域內的資源。 若要實作此方法，您可以：
- 針對部署 VM 的每個可用性區域部署子網。
- 將區域 VM 與相符的區域性 NAT 閘道對齊。
- 建置個別的分區堆疊。
在下圖中，可用性區域 1 中的 VM 位於只有可用性區域 1 的其他資源的子網上。 NAT 閘道在可用性區域 1 中設定為提供該子網。
虛擬網路和子網 橫跨區域中的所有可用性區域。 您不需要依可用性區域分割網路來容納區域性資源。
安全性
使用 NAT 閘道時，個別 VM 或其他計算資源不需要公用 IP 位址，而且可以保持完全私人。 沒有公用IP位址的資源仍然可以連線到虛擬網路外部的外部來源。 您可以建立公用IP前置詞的關聯，以確保您使用一組連續的IP進行輸出連線。 您可以根據這個可預測的IP清單來設定目的地防火牆規則。
常見的方法是使用非 Microsoft 防火牆或 Proxy 伺服器來設計僅限輸出的網路虛擬設備 （NVA） 案例。 當您將 NAT 閘道部署到具有虛擬機擴展集 NVA 的子網時，這些 NVA 會使用一或多個 NAT 閘道地址進行輸出連線，而不是負載平衡器 IP 或個別 IP。 若要使用此案例搭配 Azure 防火牆，請參閱整合 Azure 防火牆 與 Azure 標準負載平衡器。
您可以使用 適用於雲端的 Microsoft Defender 警示功能來監視 NAT 閘道中的任何可疑輸出連線。
參與者
本文由 Microsoft 維護。 原始投稿人如下。
主體作者：
- Ethan Haslett |資深雲端解決方案架構師
若要查看非公開的 LinkedIn 設定檔，請登入 LinkedIn。