この記事では、Azure NAT ゲートウェイのベスト プラクティスについて説明します。 このガイダンスは、コストの最適化、運用の優秀さ、パフォーマンスの効率性、信頼性、セキュリティという優れたアーキテクチャの 5 つの柱に基づいています。
このガイダンスの前提条件として、Azure NAT Gateway に関する実用的な知識があり、そのそれぞれの機能を理解している必要があります。 詳細については、 Azure NAT Gateway のドキュメントを参照してください。
コストの最適化
NAT ゲートウェイを使用する必要がないように、Azure プライベート リンク またはストレージを含むサービス エンドポイントを介したサービスとしてのプラットフォーム (PaaS) ソリューションへのアクセスを構成します。 プライベート リンクとサービス エンドポイントでは、PaaS サービスにアクセスするために NAT ゲートウェイを通過する必要はありません。 このアプローチにより、NAT ゲートウェイを使用するコストと比較して、処理されるデータのギガバイト (GB) あたりのコストが削減されます。 プライベート リンクとサービス エンドポイントには、セキュリティ上の利点もあります。
パフォーマンス効率
各 NAT ゲートウェイ リソースは、最大 50 ギガビット/秒 (Gbps) のスループットを提供します。 デプロイメントを複数のサブネットに分割し、スケールアウトする各サブネットまたはサブネットのグループに NAT ゲートウェイを割り当てることができます。
各 NAT ゲートウェイのパブリック IP アドレスは、64,512 個の送信元ネットワーク アドレス変換 (SNAT) ポートを提供します。 個々の標準パブリック IP アドレス、パブリック IP プレフィックス、またはその両方を含む、最大 16 個の IP アドレスを NAT ゲートウェイに割り当てることができます。 同じ宛先エンドポイントに送信される、割り当てられたアウトバウンド IP アドレスごとに、NAT ゲートウェイは、伝送制御プロトコル (TCP) とユーザー データグラム プロトコル (UDP) に対してそれぞれ最大 50,000 の同時フローをサポートできます。
SNAT の枯渇
SNAT の枯渇を防ぐために、次のガイダンスを考慮してください。
NAT ゲートウェイ リソースのデフォルトの TCP アイドル タイムアウトは 4 分です。 タイムアウトは最大 120 分まで設定できます。 この設定をデフォルトよりも高い値に変更すると、NAT ゲートウェイがフローを保持する時間が長くなり、SNAT ポート インベントリに不必要な圧力がかかる可能性があります。
アトミック リクエスト (接続ごとに 1 つのリクエスト) により、スケールが制限され、パフォーマンスが低下し、信頼性が低下します。 アトミック リクエストの代わりに、HTTP または HTTPS 接続を再利用して、接続と関連する SNAT ポートの数を減らすことができます。 接続を再利用すると、アプリケーションの拡張性が向上します。 Transport Layer Security (TLS) を使用すると、ハンドシェイク、オーバーヘッド、暗号化操作のコストが削減されるため、アプリケーションのパフォーマンスが向上します。
DNS リゾルバーの結果をキャッシュしない場合、ドメイン ネーム システム (DNS) 検索によって多数の個別のフローが大量に発生する可能性があります。 DNS キャッシュを使用してフローの量を減らし、SNAT ポートの数を減らします。 DNS は、インターネットまたはプライベート ネットワークに接続されているリソースの IP アドレスにドメイン名をマッピングする命名システムです。
DNS 参照などの UDP フローでは、アイドル時間中に SNAT ポートを使用します。 UDP アイドル タイムアウト タイマーは 4 分に固定されています。
接続プールを使用し、接続ボリュームを形成します。
フローをクリーンアップするには、TCP フローを黙って放棄したり、TCP タイマーに頼ったりしないでください。 TCP に接続を明示的に閉じさせない場合、TCP 接続は開いたままになります。 中間システムとエンドポイントはこの接続を使用し続けるため、SNAT ポートは他の接続で使用できなくなります。 このアンチパターンは、アプリケーションの障害や SNAT の枯渇を引き起こす可能性があります。
影響を理解していない限り、OS レベルの TCP クローズ関連のタイマー値を変更しないでください。 接続のエンドポイントの期待値が一致しない場合、TCP スタックは回復できますが、アプリケーションのパフォーマンスに悪影響を及ぼす可能性があります。 タイマー値を変更する必要がある場合は、通常、根本的な設計上の問題があります。 また、基盤となるアプリケーションに他のアンチパターンがあり、タイマー値を変更すると、SNAT の枯渇が加速する可能性があります。
サービスの規模や信頼性を改善するため、次のガイダンスをご確認ください。
TCP アイドル タイムアウトをより低い値に減らすことによる影響を考慮してください。 デフォルトの 4 分のアイドル タイムアウトにより、SNAT ポート インベントリを先制的に解放できます。
接続リソースを他の操作に解放するために、長時間実行操作の非同期ポーリング パターンを検討してください。
中間システムのタイムアウトを防ぐために、再利用された TCP 接続など、存続期間の長い TCP フローには、TCP キープアライブまたはアプリケーション層キープアライブの使用を検討してください。 アイドル タイムアウトを増やすのは最後の手段としてのみにしてください。根本的な原因は解決されない可能性があります。 タイムアウトが長いと、タイムアウトが切れたときに低レートのエラーが発生する可能性があります。 また、遅延や不要な障害が発生する可能性もあります。 接続の片側から TCP キープアライブを有効にして、両側から接続を維持できます。
中間システムのタイムアウトを防ぐために、存続期間の長い UDP フローには UDP キープアライブを使用することを検討してください。 接続の片側で UDP キープアライブを有効にすると、接続の片側のみがアクティブのままになります。 接続を維持するには、接続の両側で UDP キープアライブを有効にする必要があります。
一時的な障害または障害回復時の積極的な再試行やバーストを回避するために、適切な再試行パターンを検討してください。 アンチパターン アトミック接続の場合は、HTTP 操作ごとに新しい TCP 接続を作成します。 アトミック接続はリソースを無駄にし、アプリケーションの適切なスケーリングを妨げます。
アプリケーションのトランザクション速度を向上させ、リソース コストを削減するには、常に複数の操作を同じ接続にパイプライン処理します。 アプリケーションがトランスポート層暗号化 (TLS など) を使用する場合、新しい接続処理によりコストが増加します。 その他のベスト プラクティス パターンについては、「Azure クラウド設計パターン」を参照してください。
オペレーショナルエクセレンス
Azure Kubernetes Service (AKS) で NAT ゲートウェイを使用できますが、NAT ゲートウェイ管理は AKS に含まれていません。 NAT ゲートウェイを Container Networking Interface (CNI) サブネットに割り当てると、AKS ポッドが NAT ゲートウェイを経由して出力できるようになります。
ゾーンまたはリージョン間で複数の NAT ゲートウェイを使用する場合は、Azure パブリック IP プレフィックスまたは BYOIP (Bring Your Own IP) プレフィックスを使用して、送信 IP 資産を管理しやすい状態に保ちます。 16 IP アドレス (/28 プレフィックス サイズ) を超える IP プレフィックス サイズを NAT ゲートウェイに割り当てることはできません。
Azure Monitor アラートを使用して、SNAT ポートの使用状況、処理またはドロップされたパケット、送信されたデータの量を監視し、アラートを出します。 ネットワーク セキュリティ グループ (NSG) フロー ログを使用して、NAT ゲートウェイが構成されたサブネット内の仮想マシン (VM) インスタンスからの送信トラフィック フローを監視します。
NAT ゲートウェイを使用してサブネットを構成すると、そのサブネット上のすべての VM のパブリック インターネットへの他のすべての送信接続が NAT ゲートウェイに置き換えられます。 NAT ゲートウェイは、アウトバウンド規則に関係なく、ロード バランサーよりも優先されます。 また、ゲートウェイは、VM に直接割り当てられるパブリック IP アドレスよりも優先されます。 Azure はフローの方向を追跡し、非対称ルーティングを防ぎます。 ロード バランサーのフロントエンド IP などの受信元のトラフィックは正しく変換され、NAT ゲートウェイを介した送信元のトラフィックとは別に変換されます。 このように分離されていることで、受信および送信サービスをシームレスに共存させることができます。
仮想ネットワークの送信接続を有効にするために、デフォルトとして NAT ゲートウェイを使用することをお勧めします。 NAT ゲートウェイは、Azure の他の送信接続技術と比較して、効率性と運用の簡素化を実現します。 NAT ゲートウェイは、オンデマンドで SNAT ポートを割り当て、より効率的なアルゴリズムを使用して SNAT ポートの再利用の競合を防ぎます。 資産の デフォルトの送信接続 アンチパターンに依存しないでください。 代わりに、NAT ゲートウェイ リソースを使用して構成を明示的に定義します。
信頼性
NAT ゲートウェイのリソースは 1 つの可用性ゾーン内で高可用性であり、複数の障害ドメインにまたがります。 NAT ゲートウェイを ゾーンなし にデプロイできます。この場合、Azure は NAT ゲートウェイを配置するゾーンを自動的に選択するか、NAT ゲートウェイを特定の可用性ゾーンに分離します。
可用性ゾーンの分離を実現するには、各サブネットが特定のゾーン内にのみリソースを持つ必要があります。 このアプローチを実装するには、次のことができます。
- VM がデプロイされている可用性ゾーンごとにサブネットをデプロイします。
- ゾーン VM を、一致するゾーン NAT ゲートウェイと調整します。
- 個別のゾーンスタックを構築します。
次の図では、可用性ゾーン 1 の VM は、同様に可用性ゾーン 1 のみにある他のリソースを持つサブネット上にあります。 NAT ゲートウェイは、そのサブネットを提供するために、可用性ゾーン 1 で構成されます。
仮想ネットワークとサブネットは、リージョン内のすべての可用性ゾーンにまたがっています。 ゾーン リソースに対応するために、可用性ゾーンでそれらを分割する必要はありません。
セキュリティ
NAT ゲートウェイを使用すると、個々の VM やその他のコンピューティング リソースはパブリック IP アドレスを必要とせず、完全にプライベートなままにすることができます。 パブリック IP アドレスを持たないリソースでも、仮想ネットワークの外部にある外部ソースに引き続き到達できます。 パブリック IP プレフィックスを関連付けて、発信接続に連続した IP セットを使用できるようにすることができます。 この予測可能な IP リストに基づいて宛先ファイアウォール ルールを構成できます。
一般的なアプローチは、Microsoft 以外のファイアウォールまたはプロキシ サーバーを使用して、送信専用のネットワーク仮想アプライアンス (NVA) シナリオを設計することです。 NAT ゲートウェイを NVA の仮想マシン スケール セットを含むサブネットにデプロイすると、それらの NVA は、ロード バランサー IP や個々の IP の代わりに、送信接続に 1 つ以上の NAT ゲートウェイ アドレスを使用します。 Azure Firewall でこのシナリオを採用するには、「Azure Firewall と Azure 標準ロード バランサーを統合する」を参照してください。
Microsoft Defender for Cloud アラート機能を使用して、NAT ゲートウェイ内の疑わしい送信接続を監視できます。
共同作成者
この記事は、Microsoft によって保守されています。 当初の寄稿者は以下のとおりです。
プリンシパル作成者:
- Ethan Haslett | シニア クラウド ソリューション アーキテクト
パブリックでない LinkedIn プロファイルを表示するには、LinkedIn にサインインします。
次の手順
- Microsoft Well-Architected Framework
- チュートリアル:Azure portal を使用した NAT ゲートウェイの作成
- アベイラビリティ ゾーンとリージョンを使用するための推奨事項