Azure VM(Linux)でNATインスタンス(IPv4)を構築しスループットを測った

はじめに

まずSNATが必要な場合、まずNAT Gatewayを検討しましょう。2025/11/19にやっとゾーン冗長IPのサポート(Preview)も来ておりコスト面以外で欠点がなくなりつつあります。管理するものを増やして責任を増やす必要はありません。

しかし開発目的であったり、通信量次第では無視できないコスト感になることがあり、検証用途ではオーバースペックになることもあります。その場合はNAT Instanceという手が使えるかもしれません。

また、今回計測した結果から、NAT Gatewayの代わりにNAT Instanceを使うと以下のデメリットがあると考えられます。

• TCPは10Gbps強から5Gbps弱になる
• UDPだと性能を引き出せないかもしれない（チューニング次第？）
• レイテンシがわずかに増加

背景

2026/03以降、既定のSNATがデフォルト無効に

上記の通り、既定のSNATがデフォルトで無効になります。これは今までPublic IPを割り振っていないVMでもなぜかインターネットと通信ができることを実現する仕組みでした。制約もそこそこあったので常用すべきものではありませんでしたが、apt updateなどが何も考えずに通ったので便利ではありました。

Azureではインターネットへ通信を通すには以下のいずれかを取ることになります。

• 明示的にPublic IPを振る
• NAT Gatewayを追加し、経由する
• Azure Load BalancerのSNATの機能を使う
• NAT Instanceを構築し、経由する
• 既定のSNATを有効にする（非推奨）

既定のSNATを頼りに意図的にPublic IPを振らないような設計をすることはあまりないと思われるので困ることはあまりないでしょう。

蛇足ですが、元々は2025/09/30に廃止でしたが、直前で非推奨に切り替わったりしていました。

なぜNAT GatewayではなくNAT Instanceなのか？

コストでしょう。NAT Gatewayは稼働時間課金とデータ処理量の従量課金です。

• 時間: $0.045/時
• データ処理量: $0.045/GB (※egress/ingress両方向を含む)

データ処理量の罠として、転送量(Bandwidth)ではないため、転送量は別でかかります。
そしてingressもデータ処理量としてカウントされるのが厄介です。

1か月(730時間)、1000GBの受信のみで考えても、$77.85($32.85 + $45.00) かかります。ここにさらにデータ転送量がかかるわけです。

Azureの転送量(Bandwidth)の課金はegressのみでingressは無料です。ingressはdocker pullやapt updateなどを行うとデータの取得でダウンロード処理を行うので割と無視できなくなります。

今回の計測ではAzureの同一リージョン内だったのですが、金額は1463円でこのうちNAT Gatewayのデータ処理量は1127円なので約170GB分です。($1=146円)

コストを見ての通り、今回のベンチマークで最もかかったのはNAT Gatewayによるデータ処理量の課金で1000円以上かかってます。

NAT Instanceの提案

毎月$35+通信量に比例した課金、というのはちょっと抵抗がある貧乏性のためのNAT Instanceのご提案となります。Linux VMをちょっと細工すれば作れます。

セットアップのポイントは以下の箇所となります。

• Azure
  • NAT用VMのNetworkInterfaceのIP Forwadingを有効化
  • ルートテーブルで0.0.0.0/0への通信をNAT用VMのプライベートIPになるように定義する
  • 作成したルートテーブルをサブネットに関連付けて、サブネットからインターネットへの通信をNAT用VMへルーティングさせる
  • NAT用VMのNetwork Security GroupでVirtual NetworkからInternet(Service Tag)への通信を許可する
• Linux VM
  • IP Forwardingを有効化
  • IPマスカレードを設定（NAPT処理）

具体的な手順は調べれば出ますが、検証に使ったコードをリポジトリにあげており、そこにterraformやセットアップスクリプトを乗せているので参考になるかもしれません。

運用観点

NAT Gatewayはマネージドなサービスで、帯域の確保と複数IPを使いSNATポートを確保するぐらいで済みます。2025/11にStandard v2(preview)が出たことにより、ゾーン冗長も対応され始めており、欠点がなくなってきました。

NAT InstanceはVMで動作するので、VMのSLAの影響を受けます。SNATポートが枯渇する場合はNICとPublic IPを増やし冗長化をするなりして、適切にルーティングする必要があります。NICもVMのSKUに依存して最大数が決まっており無尽蔵に増やせるわけでもありません。ほとんどの場合、割に合わないでしょう。その代わり通信量の課金が安いです。

NAT検証

NAT無し、NAT Instance、NAT GatewayでClient→NAT→Server というような構成を作り、どれだけ性能に差が出るかを試してみました。レイテンシもとります。なおICMPでは最適化が効かないとかでTCP/UDPベースのPingがよいらしいです。

ただし、同一Azureリージョン内なので、通信経路の最適化は行われてしまっているものと考えられます。ちゃんとサーバを外部に設置するのが良いですが面倒だったので 参考値としてとらえてください。

要約

NAT InstanceではNAT Gatewayと比べてスループットが半分ほどになります。

スループットが重要な場合はやめたほうがよいでしょう。とはいえ、TCPで4Gbpsは出るので、ここを閾値としてみてもよいでしょう。

検証

検証用のコードは以下。

ベンチマーク実施時の通信イメージは以下です。

• ①: 直接接続（Public IP利用, 参考値）
• ②: NAT Gateway利用
• ③: NAT Instance経由

いずれもVMはUbuntu 24.04 LTSを使っています。

ベンチマーク時のVMインスタンスは以下の通りです。

• Client/Server: D8ls_v5
• NAT Instance: B2ats (コスト重視)

コスト感としては、B2ats_v2は月 $6.8620 + ストレージ $6.08 (32GBのPremium SSD)で比較的低コストです。なお、NAT Gatewayは月 $32.85 です。ここにPublic IPと通信量が入ります。

試験はiperf3で30秒づつ以下の負荷をかけ、その時のスループットを見ます。

• TCPのEgress(送信)
• TCPのIngress(受信)
• UDPのEgress(送信)
• UDPのIngress(受信)
• UDPのEgress(送信) (パケット小さめ)
• UDPのIngress(受信) (パケット小さめ)

Linuxにおけるsysctlの設定は次を参考にし、適当にセットアップしています。

結果

気になるスループットをみてみましょう。

通信	NAT Instance	直接	NAT Gateway
TCPのEgress(送信)	6.86 Gbits/sec	11.50 Gbits/sec	10.70 Gbits/sec
TCPのIngress(受信)	4.20 Gbits/sec	11.50 Gbits/sec	9.61 Gbits/sec
UDPのEgress(送信)	1.60 Gbits/sec	3.65 Gbits/sec	3.55 Gbits/sec
UDPのIngress(受信)	2.67 Gbits/sec	3.93 Gbits/sec	3.90 Gbits/sec
UDPのEgress(送信) len=64	137 Mbits/sec	152 Mbits/sec	160 Mbits/sec
UDPのIngress(受信) len=64	129 Mbits/sec	195 Mbits/sec	196 Mbits/sec

• 概ねNAT InstanceはNat Gatewayの半分ほどになっておりかなり劣っています
• 一方で直接とNAT Gatewayはほとんど変わりません
• UDPの性能が悪い？（iperfのチューニング不足かもしれません）

マシンリソースも取ったので見てみましょう。

NAT Instance	NAT Gateway	直接

NAT Instanceに注目します。ネットワークは縮尺があってない点に注意です。

• CPUをみるとTCPはうまくさばけていますが、UDPだとCPUを多く使ってしまっています（iperf3の特性と思われます）
• メモリは一貫して余裕がありそうです
• 肝心のネットワークトラフィックは…
  • TCPはCPUに余裕があるものの、5Gbpsで頭打ちになっているように見える
    • 直接通信のスペックを見る限り、10Gbpsは出るはずなので、NAT Instanceがボトルネックとなっている
  • UDPはClient->NAT Instance間でトラフィック量が一致していない（Client: 8Gbps, NAT Instance: 2Gbps）
    • 直接通信時はここまで極端ではないので、NAT instanceがドロップしているとみられる

UDPは多分ちゃんとチューニングしてないせいでベンチマークになっていなさそうですが、NAT Instanceではクライアントとサーバでネットワークの通信量が対等ではないことからパケットロスが発生していることがわかります。

参考までにiperf上で計測したTCP再送数、UDPパケットロス数(Lost / Total)もみてみましょう。

通信	NAT Instance	直接	NAT Gateway
TCPのEgress(送信)	548	272156	400139
TCPのIngress(受信)	15932	357926	156470
UDPのEgress(送信)	42384069/48351527 (88%)	26558765/50399886 (53%)	25954360/50160800 (52%)
UDPのIngress(受信)	41145366/45611180 (90%)	22930807/46461568 (49%)	25692156/46576682 (55%)
UDPのEgress(送信) len=64	44435032/51158786 (87%)	26900320/51417579 (52%)	28480862/54490520 (52%)
UDPのIngress(受信) len=64	43420870/48658702 (89%)	24813736/49223475 (50%)	24957133/49476411 (50%)

• NAT InstanceでTCPの再送が少ないのは単純にトラフィックが飽和してなかったからでしょう
• UDPのLostの値が非常に大きい状態です
  • iperf3のLostの算出は順不同も含むので高い数値になりがちではあります
  • しかし、高負荷時は90%弱届かないというのはなかなか厳しいものがありそうです。NAT Instanceのチューニング不足の可能性があります

tcppingによるTCPレイテンシも計測しました。

メトリック	NAT Instance	直接	NAT Gateway
MEAN	1.07 ms	0.57 ms	0.69 ms
P99	2.33 ms	0.62 ms	1.02 ms
STDDEV	0.34	0.05	0.13

• NAT Instanceは直接と比べ２倍弱の増加となっており、明らかにオーバーヘッドになっています
• NAT Gatewayも若干のレイテンシ悪化が見られます。（99 Percentailで0.4ミリ秒の増加）

NAT Gatewayがなぜ早いか？→よくわかりませんでした

NAT Gatewayがなぜ早いかちょっと調べましたが、情報が全くなくわかりませんでした。

ただおそらく、Software Defined Networkingの一環でNAT Instanceのようなリソースではなく、ネットワークのルーティングで制御してNAT Gatewayを実現しているものと考えられます。その雰囲気はAzure Virtual Filtering Platformからうかがえます。

通常のPublic IPとPrivate IPの変換や、Azure Load BalancerのAnantaの仕組み上、SNATの実現にSDNを活用しているのは間違いありませんから、NAT Gatewayも近い仕組みで行っている可能性は高いでしょう。見つけた記事はどれも古いので仕組みは大きく変わっているかもしれませんが。

参考: