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