MENU

AKS StandardV2 NAT Gatewayとは？アウトバウンド設計で押さえるゾーン冗長・100Gbps・IPv6対応

Azure

AKS のアウトバウンド設計でいま確認すべきポイントは、managedNATGatewayV2 によって StandardV2 NAT Gateway を AKS の送信経路として選べるようになり、ゾーン冗長、最大 100Gbps クラスの送信性能、IPv6 送信対応を同じ設計軸で扱えるようになったことです。特に Kubernetes networking specialists や platform engineers にとっては、「どの outbound type を選ぶか」が単なる作成時オプションではなく、可用性・SNAT ポート・監査・IPv6 移行計画に直結する判断になります。

2026年4月14日時点で注目すべき Azure Updates の内容は、AKS が managed VNet と BYO VNet の両方で StandardV2 NAT Gateway を outbound type として扱えるようになった、という Public Preview です。これにより、AKS クラスターの送信通信でゾーン冗長な出口、より高いスループット、IPv6 outbound support を計画しやすくなりました。ただし Preview 機能であるため、本番適用は検証環境での確認、リージョン対応、IaC 対応、既存接続への影響を見てから判断するのが安全です。(Microsoft Azure)

ITtripTOOLS
その「面倒」、無料で解決。 ITtripがつくる、6つの道具。 無料ツール一覧へ すべて無料・追加課金なし
先頭0を守るCSV編集こわさないCSV PDFに直接書き込みかけるPDF 写真＋説明をPDFに写レポ スマホ⇄PCで共有コピペ便 · 文章・写真 みんなの日程を調整日程Fit 匿名質問・投票を集めるKOEQ
目次

AKS の outbound type とは何を決める設定か

AKS の outboundType は、クラスターからインターネットや外部サービスへ出ていく通信の経路を決める設定です。Ingress、つまり外部からアプリケーションへ入ってくる通信を直接決めるものではありません。影響するのは、ノードや Pod からのイメージ取得、外部 API へのアクセス、監視エージェントの送信、SaaS 連携、パッケージリポジトリへの接続などです。Microsoft Learn でも、AKS の outbound type はクラスターの egress traffic に影響する設定として説明されています。(Microsoft Learn)

AKS で NAT Gateway を使う場合、大きく分けると次の選択肢があります。

outbound type主な用途重要な判断ポイント
managedNATGatewayV2AKS 管理の VNet で StandardV2 NAT Gateway を使うPreview。AKS が StandardV2 NAT Gateway をプロビジョニングし、ゾーン冗長・高スループット・IPv6 を活用しやすい
managedNATGatewayAKS 管理の VNet で従来の Standard NAT Gateway を使うStandard NAT Gateway ベース。ゾーン冗長が必要なマルチゾーン設計では V2 を優先検討
userAssignedNATGatewayBYO VNet で事前作成した NAT Gateway を使うネットワークチームが NAT Gateway、Public IP、Subnet を管理したい場合に向く
loadBalancerStandard Load Balancer の outbound rule を使う既定構成で使われやすいが、SNAT ポートや大規模送信の設計に注意
userDefinedRoutingAzure Firewall、NVA、集中 egress へ送る検査・監査・許可制御を優先するエンタープライズ向け

今回の更新で特に重要なのは、managedNATGatewayV2 が AKS 管理の構成に入り、BYO VNet では userAssignedNATGateway 経由で StandardV2 NAT Gateway を使える点です。AKS のドキュメントでは、managedNATGatewayV2、managedNATGateway、userAssignedNATGateway が NAT Gateway を使う outbound type として整理されています。(Microsoft Learn)

StandardV2 NAT Gateway で何が変わるのか

StandardV2 NAT Gateway の価値は、「NAT Gateway の新しい SKU」というだけではありません。AKS のように多数の Pod が外部へ出ていく環境では、出口の可用性、性能、IP バージョン、監視性がまとめて変わります。

観点StandardV2 NAT Gateway の意味AKS 設計への影響
ゾーン冗長StandardV2 は複数の Availability Zone にまたがる zone-redundant 構成マルチゾーン node pool の egress が単一ゾーン依存になりにくい
スループットNAT Gateway あたり最大 100Gbps、最大 1,000万 PPS大量の外部 API 呼び出し、ログ送信、データ転送で余裕を持たせやすい
IPv6IPv4 と IPv6 の Public IP / Prefix を扱えるデュアルスタック AKS や IPv6 宛先への送信計画に使いやすい
Public IPStandardV2 NAT Gateway には StandardV2 Public IP が必要既存の Standard SKU Public IP を流用できない
監視Flow logs を利用可能どの送信元がどの宛先へ出ているかを追いやすい

Microsoft の NAT Gateway SKU 比較では、StandardV2 は Availability Zones、IPv4/IPv6、最大 100Gbps、最大 1,000万 PPS、Flow logs に対応すると説明されています。(Microsoft Learn)

ゾーン冗長への影響：マルチゾーン AKS の出口を単一障害点にしない

AKS で node pool を複数 Availability Zone に分散しても、送信経路が単一ゾーンに強く依存していると、実運用では egress が弱点になります。たとえば、アプリケーション Pod は別ゾーンで動いていても、外部 API、コンテナレジストリ、監視基盤への送信が失敗すれば、ワークロード全体の信頼性は下がります。

StandardV2 NAT Gateway は zone-redundant by default とされ、リージョン内の複数 Availability Zone にまたがって動作します。Standard NAT Gateway はゾーンリソースとして扱われるため、ゾーン障害への備えという観点では StandardV2 のほうが AKS のマルチゾーン設計と整合しやすくなります。(Microsoft Learn)

ただし、StandardV2 NAT Gateway を選べば AKS 全体が自動的に高可用になるわけではありません。次の要素もあわせて設計する必要があります。

確認項目見落としやすいポイント
node pool のゾーン分散NAT Gateway だけ冗長でも、ノードが単一ゾーンなら意味が薄い
PodDisruptionBudgetゾーン障害時に必要数の Pod が残るか確認する
外部依存先SaaS、外部 API、Private Link、DNS、監視基盤が同じレベルで冗長か確認する
リージョン対応StandardV2 NAT Gateway や StandardV2 Public IP の対応リージョンを事前に確認する
非 Private Cluster の API server 通信非 Private Cluster では API server 関連通信も outbound type の影響を受けるため、Private Cluster や API Server VNet Integration も検討する

特に platform engineering チームでは、「node pool はマルチゾーンだが egress は従来構成のまま」という状態が起こりがちです。可用性レビューでは、Ingress、Pod 配置、ストレージだけでなく、egress のゾーン依存もチェックリストに入れるべきです。

スループットへの影響：100Gbpsだけでなく SNAT と接続数を見る

StandardV2 NAT Gateway は、NAT Gateway あたり最大 100Gbps、最大 1,000万 packets per second、1 connection あたり最大 1Gbps と説明されています。Standard SKU は最大 50Gbps、最大 500万 PPS であるため、送信量が多い AKS では StandardV2 が性能面で有利です。(Microsoft Learn)

ただし、AKS の egress 設計では「100Gbps だから十分」と判断するのは危険です。実際には、次の3つを分けて見る必要があります。

見るべき指標なぜ重要か実務での確認例
帯域幅大容量データ転送の上限に影響する外部ストレージ、ログ転送、ML 推論 API、データ同期
PPS小さなリクエストを大量に送る処理で効くメトリクス送信、DNS、短時間の API 呼び出し
SNAT ポート同じ宛先への同時接続数に影響するSaaS API、DB proxy、外部決済 API、Webhook 送信

NAT Gateway は Public IP アドレスごとに 64,512 SNAT ports を提供し、Public IP を追加することで SNAT port inventory を拡張できます。StandardV2 NAT Gateway は最大 16 個の IPv4 Public IP と 16 個の IPv6 Public IP を扱えるため、IPv4 と IPv6 の両方で送信容量を計画できます。(Microsoft Learn)

AKS で SNAT が問題になりやすいパターン

AKS では、1つの node ではなく、多数の Pod が同じ外部エンドポイントへ一斉に接続します。そのため、見かけ上のトラフィック量が小さくても SNAT ポートが先に詰まることがあります。

よくある例は次のとおりです。

パターン失敗しやすい理由対策
多数の Pod が同じ SaaS API を呼ぶ宛先が同じため SNAT ポートを消費しやすい接続プール、Keep-Alive、リトライ制御、Public IP 追加
短命接続を大量に作るポート再利用待ちが増えやすいHTTP keep-alive、gRPC、バッチ間隔の調整
監視エージェントが大量送信するノード数増加に比例して外部送信が増える送信先集約、サンプリング、ログレベル調整
CI/CD や Job が同時起動する短時間に image pull や外部通信が集中する起動タイミング分散、キャッシュ、ACR の近接配置

StandardV2 NAT Gateway は大規模 egress に向きますが、アプリケーション側が短命接続を大量に作る設計のままだと、性能上限の前に接続効率が問題になります。ネットワークだけでなく、アプリケーションのコネクション管理も同時に見るのが現実的です。

IPv6 計画への影響：IPv6 outbound support は「出口」だけの話ではない

今回の更新で重要なのは、AKS の outbound type として StandardV2 NAT Gateway を使うことで、IPv6 outbound support を計画しやすくなる点です。StandardV2 NAT Gateway は IPv4 と IPv6 の Public IP / Prefix をサポートし、最大 16 個の IPv4 Public IP と 16 個の IPv6 Public IP を同時に扱えます。(Microsoft Learn)

ただし、IPv6 対応は NAT Gateway の設定だけで完結しません。AKS で IPv6 を使う場合は、クラスター、VNet、Pod CIDR、Service CIDR、CNI、LoadBalancer Service、監視、セキュリティ製品まで含めて確認する必要があります。AKS の dual-stack ドキュメントでは、dual-stack networking では Azure VNet と Pod CIDR の両方が dual-stack である必要があり、node や Pod の IPv6-only はサポートされないと説明されています。(Microsoft Learn)

IPv6 計画で先に決めるべきこと

IPv6 outbound を有効にする前に、少なくとも次の問いに答えられる状態にしておきましょう。

判断ポイント確認内容
IPv6 が必要な通信外部 API、規制要件、グローバルユーザー向け通信、IPv6-only 宛先の有無
AKS の IP familyIPv4-only のままか、ipv4,ipv6 の dual-stack にするか
CNIAzure CNI Overlay や Cilium など、対象構成での IPv6 制約を確認する
DNSAAAA レコード解決時にアプリが IPv6 を優先しても問題ないか
セキュリティ制御NSG、Firewall、Network Policy、WAF、SIEM が IPv6 を同じ粒度で扱えるか
許可リスト外部サービス側で IPv6 の送信元 IP を登録できるか
監視Flow logs、メトリクス、アプリログで IPv4/IPv6 を区別して追えるか

IPv6 は「アドレス枯渇対策」として語られがちですが、AKS ではむしろ「通信経路の二重化」「グローバルサービスとの接続性」「将来のネットワーク標準への備え」として考えるほうが実務的です。IPv6 を有効化すると、DNS 解決や接続先の選択が変わり、今まで IPv4 だけで動いていた外部依存が別の経路を使い始めることがあります。まずは検証クラスターで、Pod から IPv4 宛先、IPv6 宛先、dual-stack 宛先へ curl やアプリ実通信を流して、経路とログを確認するのが安全です。

managedNATGatewayV2 と userAssignedNATGateway の選び方

AKS の StandardV2 NAT Gateway 対応では、マネージド構成と BYO 構成のどちらを選ぶかが設計上の分岐点になります。

シナリオ推奨しやすい選択理由
AKS 管理の VNet を使い、運用を簡素化したいmanagedNATGatewayV2AKS が StandardV2 NAT Gateway を管理し、ゾーン冗長や IPv6 の恩恵を受けやすい
ネットワークチームが VNet / Subnet / Public IP を管理しているuserAssignedNATGateway + StandardV2 NAT GatewayBYO VNet で既存のネットワーク標準に合わせやすい
送信元 IP を厳密に固定したいcustomer-defined IP を使う構成外部 SaaS の allowlist 登録や監査に向く
Azure Firewall で集中検査したいuserDefinedRoutingL7/L4 検査、FQDN ルール、組織標準の egress control を優先できる
検証用・小規模で複雑な要件がないloadBalancer または従来構成ただし SNAT や将来の拡張性は早めに確認する

managedNATGatewayV2 で outbound IP を構成する場合、Azure-managed IP と customer-defined IP を同時に混在させることはできません。また、作成後に customer-defined と managed の方式を切り替えることもできないため、最初の設計判断が重要です。AKS のドキュメントでは、IPv4/IPv6 の managed outbound IP count、customer-defined Public IP、Public IP Prefix の各パラメーターが整理されています。(Microsoft Learn)

導入前に確認すべき制約と注意点

StandardV2 NAT Gateway は魅力的ですが、既存 AKS へそのまま入れ替える前に確認すべき制約があります。

注意点実務上の影響
Preview 機能であるSLA やサポート条件を確認し、本番は慎重に判断する
StandardV2 Public IP が必要既存の Standard SKU Public IP は StandardV2 NAT Gateway に使えない
Standard NAT Gateway からのインプレースアップグレードはできない新しい StandardV2 NAT Gateway を作成し、Subnet 付け替えが必要
移行時に既存接続へ影響するメンテナンス枠、段階移行、ロールバック手順が必要
リージョン対応を確認する必要があるグローバル展開ではリージョンごとの差分が運用リスクになる
IaC / Terraform / CLI 対応を確認するPreview ではツール側の対応差分が起こりやすい
IPv6 は周辺機能の対応も必要NAT Gateway だけで AKS 全体の IPv6 対応が完了するわけではない

StandardV2 NAT Gateway への移行では、既存の Standard NAT Gateway や Standard SKU Public IP をそのまま流用できず、移行中のダウンタイムや既存接続への影響を計画する必要があります。Microsoft の移行ガイダンスでも、Standard から StandardV2 へのインプレース移行はできず、既存接続に影響すると説明されています。(Microsoft Learn)

検証環境での作成イメージ

Preview の managedNATGatewayV2 を使うには、aks-preview 拡張機能と feature flag の登録が必要です。AKS ドキュメントでは、ManagedNATGatewayV2Preview feature flag の登録と、最小 aks-preview 拡張バージョン 20.0.0b1 が案内されています。(Microsoft Learn)

az extension add --name aks-preview
az extension update --name aks-preview

az feature register \
  --namespace "Microsoft.ContainerService" \
  --name "ManagedNATGatewayV2Preview"

az feature show \
  --namespace "Microsoft.ContainerService" \
  --name "ManagedNATGatewayV2Preview"

az provider register --namespace Microsoft.ContainerService

AKS 管理の StandardV2 NAT Gateway を使う場合の考え方は、次のようになります。実行前に、対象リージョン、AKS バージョン、CLI の最新仕様、IPv6 を使う場合の dual-stack 要件を必ず確認してください。

az aks create \
  --resource-group rg-aks-egress \
  --name aks-egress-v2 \
  --location eastus2 \
  --node-count 3 \
  --network-plugin azure \
  --outbound-type managedNATGatewayV2 \
  --nat-gateway-managed-outbound-ip-count 2 \
  --nat-gateway-idle-timeout 4 \
  --generate-ssh-keys

IPv6 outbound を検証する場合は、AKS の dual-stack 設計もあわせて確認します。たとえば、検証クラスターでは --ip-families ipv4,ipv6、Pod CIDR、Service CIDR、CNI、LoadBalancer Service の挙動を確認し、Pod から IPv6 宛先へ実通信を流します。AKS の dual-stack では、node と Pod は IPv4/IPv6 の両方を持ち、Service は IPv4 または IPv6、あるいは dual-stack として扱えます。(Microsoft Learn)

az aks create \
  --resource-group rg-aks-egress \
  --name aks-egress-v2-ipv6 \
  --location eastus2 \
  --node-count 3 \
  --network-plugin azure \
  --network-plugin-mode overlay \
  --ip-families ipv4,ipv6 \
  --outbound-type managedNATGatewayV2 \
  --nat-gateway-managed-outbound-ip-count 2 \
  --nat-gateway-managed-outbound-ipv6-count 1 \
  --nat-gateway-idle-timeout 4 \
  --generate-ssh-keys

BYO VNet の場合は、StandardV2 Public IP、StandardV2 NAT Gateway、Subnet 関連付けを先にネットワーク側で作成し、AKS 作成時に userAssignedNATGateway を指定する流れになります。AKS ドキュメントでも、BYO networking では事前構成済みの NAT Gateway を Subnet に関連付け、userAssignedNATGateway を使う構成が説明されています。(Microsoft Learn)

設計レビューで使えるチェックリスト

StandardV2 NAT Gateway を AKS の outbound type として検討するなら、次の順序で確認すると抜け漏れを減らせます。

順番確認すること判断基準
1送信通信の要件を棚卸しする外部 API、SaaS、監視、レジストリ、OS 更新、Webhook を洗い出す
2可用性要件を決めるマルチゾーン AKS なら egress も zone-redundant にするか判断する
3スループットと接続数を見積もるGbps、PPS、同時接続、同一宛先への接続数を分けて見る
4Public IP 管理方式を決めるAzure-managed か customer-defined かを作成前に決める
5IPv6 方針を決めるIPv4-only 継続、dual-stack、IPv6 outbound 検証の段階を分ける
6監視とログを設計するFlow logs、Azure Monitor、アプリログで送信元・宛先を追えるようにする
7移行手順を作るStandard から StandardV2 への置き換えは接続影響を前提にする
8ロールバックを準備する旧 NAT Gateway、Public IP、Subnet 設定を戻せる手順を残す

特にグローバルに AKS を展開している組織では、リージョンごとに「StandardV2 NAT Gateway が使えるか」「StandardV2 Public IP が作れるか」「外部サービスの allowlist に IPv6 を登録できるか」が変わる可能性があります。プラットフォーム標準として採用する前に、代表リージョンだけでなく、実際に使う全リージョンで確認しましょう。

よくある失敗パターン

outbound type を変えれば Ingress も改善すると誤解する

outboundType は送信通信の設定です。Service type LoadBalancer、Ingress Controller、Application Gateway、Front Door などの受信設計とは別に考える必要があります。送信元 IP 固定、外部 API 接続、SNAT、IPv6 outbound には効きますが、ユーザーからアプリケーションへ入ってくる通信の可用性を直接改善するものではありません。

既存の Standard Public IP を流用しようとする

StandardV2 NAT Gateway には StandardV2 Public IP または Prefix が必要です。既存の Standard SKU Public IP をそのまま使える前提で移行計画を立てると、作業直前に設計変更が必要になります。外部サービスの allowlist に送信元 IP を登録している場合は、re-IP の調整も必要です。(Microsoft Learn)

100Gbps だけを見て SNAT を見ない

帯域に余裕があっても、同じ宛先への短命接続が多ければ SNAT ポートがボトルネックになります。マイクロサービス、Job、イベント駆動ワークロードでは、通信量より接続数のほうが問題になることがあります。HTTP keep-alive、接続プール、リトライ間隔、外部 API のレート制限をあわせて見直しましょう。

IPv6 を有効にしてから周辺製品の非対応に気づく

IPv6 outbound を検証するときは、AKS だけでなく、DNS、Firewall、NSG、Network Policy、監視、SIEM、外部 SaaS の allowlist まで確認します。IPv6 宛先へ到達できても、ログで追えない、ポリシーで制御できない、障害時に運用チームが切り分けられない状態では本番投入しづらくなります。

Preview を本番標準にしてしまう

managedNATGatewayV2 は Preview として案内されています。Preview は検証や早期評価には有用ですが、SLA、サポート、仕様変更の可能性を踏まえた判断が必要です。まずは開発・検証クラスター、次に低リスクな本番系、最後に全社標準という段階を踏むのが安全です。

まとめ：AKS の outbound type はプラットフォーム設計の標準部品として扱う

StandardV2 NAT Gateway の AKS outbound type 対応は、AKS の egress 設計を一段引き上げる更新です。ゾーン冗長によりマルチゾーン AKS の出口を強くし、最大 100Gbps クラスの性能で大規模送信に備え、IPv6 outbound support によって将来の dual-stack 設計を進めやすくなります。

次に取るべき行動は、既存 AKS クラスターの outboundType、送信元 Public IP、SNAT 使用状況、IPv6 要件を棚卸しすることです。そのうえで、マネージド VNet なら managedNATGatewayV2、BYO VNet なら userAssignedNATGateway + StandardV2 NAT Gateway を検証候補にします。Preview 機能である点を踏まえ、まずは非本番クラスターでゾーン障害時の egress、同時接続、IPv6 宛先、Flow logs の見え方を確認しましょう。

Azure
ネットワーク IPv6 Kubernetes AKS Azure NAT Gateway

この記事を書いた人

佐藤健司のアバター 佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

関連記事

コメント

コメントする

目次