「既定の送信アクセスが廃止？どんな影響があるの？」「代替リソースの Azure NAT Gateway って？どう構築すればいいかわからない…」

2025年9月30日の Microsoft Azure における「既定の送信アクセス」廃止が近付く中、このような不安やお悩みを持っている方がいらっしゃるのではないでしょうか。

まず Microsoft Azure では、仮想マシンなどのアウトバウンド通信にて「既定の送信アクセス」が実施されていました。これにより、プライベートIPしか持たない仮想マシンでも、自動的にインターネットへのアウトバウンド通信が可能となっていたのです。しかし、この仕様が2025年9月30日で廃止されることが発表され、代替リソースとして「Azure NAT Gateway」への移行が推奨されています。この仕様変化をきちんと理解し、対策をしていないとインターネットへのアウトバウンド通信に問題が発生してしまうかもしれません。

そこで本記事では、この仕様に関わる「NAT」「SNAT」の基本から、「既定の送信アクセス」廃止後の影響、そして Azure NAT Gateway のメリット、設定手順、料金体系、運用までを網羅的に解説しています。クラウドサービスの利用が拡大する中で、インターネット等の外部ネットワークへのアウトバウンドアクセスの安全性・安定性の管理は企業にとって最重要課題の一つです。この機会に、現環境のアウトバウンド通信設定を確認して効率的な管理・運用体制を整えましょう。

まず「NAT（Network Address Translation」とは、文字通り「ネットワークのアドレスを変換する」仕組みです。

特に、送信元のIPを変換して通信する仕組みを「SNAT（送信元NAT：Source NAT）」といいます。Microsoft Azure においては、仮想ルーター (デフォルトゲートウェイ) が、仮想マシンからインターネットへのアウトバウンド通信に対してSNATを実施しています。

ただしインターネットと通信するには、パブリックIP（グローバルIP）が必要です。プライベートIPしか持たないVMであった場合、理論上インターネットとの通信は不可能となります。つまり、いくらデフォルトゲートウェイにてSNATを実施したとしても、変換先のパブリックIPを準備していなければインターネットへの通信はできません。

しかし、Microsoft Azure では「既定の送信アクセス（既定のSNAT）」というデフォルト仕様を用いて、プライベートIPしか持たない仮想マシンであってもインターネットへのアウトバウンド接続を可能としていたのです。

Microsoft Azure における「既定の送信アクセス（既定のSNAT）」とは、明示的なアウトバウンド接続設定なしで仮想ネットワークに仮想マシンをデプロイする際に、自動的にアウトバウンド用のパブリックIPアドレスを割り当てる仕組みです。（これ以降、「既定の送信アクセス（既定のSNAT）」は「既定の送信アクセス」とします）

これにより、仮想マシンからのインターネットや Microsoft 内の他のパブリックエンドポイントへのアウトバウンド通信接続が可能になります。

「既定の送信アクセス」には「ポート枯渇」という大きな課題がありました。

確保されているSNATポート数がNIC1つあたり1024個と固定されているため、短時間に大量の送信接続が発生するとポートを使い果たし、新たな接続が失敗してしまいます。これは特に、多くの外部APIを呼び出すような大規模システムにおいて、安定稼働を脅かす深刻な問題となります。また、どの仮想マシンがどのIPアドレスでインターネットへアクセスしているのかを把握することが難しく、セキュリティ管理にも問題がありました。

このような課題もあり、Microsoft の発表にて、2025年9月30日をもってこの「既定の送信アクセス」が廃止されることが決定しました。

「既定の送信アクセス」が廃止されると、「明示的な送信接続設定をしていない＝インターネットへのアウトバウンド接続用にパブリックIPを用意していない」仮想マシンは、インターネットへ接続できなくなるということです。

例えば、VPNでオンプレミスと接続しているVMであっても、以下の目的等のためインターネットへのアウトバウンドが必要となります。

2025年10月1日より以前に作成された既存の仮想マシンについては、既定の送信アクセス廃止の対象外となっています。そのため、すぐに影響が出る、というわけではありません。しかし、Microsoft は明示的な送信接続設定を追加することを推奨しています。そして2025年10月1日以降に作成される仮想マシンについては、既定の送信アクセスが適用されないため、インターネットへのアウトバウンド通信のためには「明示的な送信接続設定」の実施が必須となります。

その中で、最も推奨される接続設定が「Azure NAT Gateway」です。Azure NAT Gateway は、既定の送信アクセスの課題であったポート枯渇やセキュリティ管理上の問題を解決し、安定したアウトバウンド接続を実現するために設計されたサービスです。別の設定方法としてパブリックロードバランサー（パブリックIPをフロントエンドIPとする Azure Load Balancer）の送信規則設定追加や、仮想マシンにパブリックIPを追加する等が挙げられますが、Azure NAT Gateway の接続設定が他アウトバウンド接続設定よりも優先されます。そのため、一番手っ取り早く廃止対策を実施できるサービスでもあります。既定の送信アクセス廃止後も問題なくビジネスを継続し、ネットワークの安定性・明良性を確保するためにも、Azure NAT Gateway への移行を始めましょう！

Microsoft Azure のアウトバウンド接続設定方法についての詳細は、以下の Microsoft 公式記事をご確認ください。既存環境にてロードバランサーをご利用中の場合、比較検討もお勧めします。

「NATゲートウェイ」について、その基本とメリットを説明します。また、「Azure NAT Gateway」について、AWS の「AWS NAT Gateway」との機能比較もしてみましょう。

NATゲートウェイは、アタッチしたサブネット内リソースからのアウトバウンド通信をすべて集約し、割り当てられたパブリックIPアドレス（またはパブリックIPプレフィックス）に送信元IPアドレスを変換（SNAT）して、インターネットに送信します。

これにより、内部リソースはインターネットから直接アクセスされることなく、安全に外部と通信できます。つまり、既定の送信アクセスによってデフォルトゲートウェイで行われていたSNATを、明示的に実施するリソースとなります。

クラウドプロバイダーによってNATゲートウェイの機能には違いがあります。

Azure NAT Gateway と AWS NAT Gateway を比較すると、基本的なIPアドレス変換の機能は共通していますが、細かな設定や統合されるサービスにおいて少々違いがあります。例えば、Azure NAT Gateway はパブリックIPプレフィックスをサポートし、より柔軟なIPアドレス管理が可能です。

Azure NAT Gateway の導入は、単なる既定の送信アクセス廃止対策に留まりません。以下に示すような、ビジネスに大きなメリットをもたらす機能が多数あります。

前述したように、既定の送信アクセスによるSNATでは、ポート枯渇による接続エラーが発生する可能性がありました。しかし、Azure NAT Gateway は数百万の同時接続をサポートし、大規模なアウトバウンド接続を安定させることが可能です。これにより、多数のVMが同時に外部APIにアクセスするようなシナリオでも、高いパフォーマンスを維持できます。

Azure NAT Gateway はゾーン指定リソースであり、複数のゾーンにVMを配置している場合はそれぞれのゾーンに対して設置することで可用性が担保されます。

単一サブネット内に別ゾーンの仮想マシンを複数設置している場合については、Azure NAT Gateway はサブネットと1対1の関係、かつ Azure NAT Gateway で指定できるゾーンは1つのみであるため、完全な可用性が担保されません。この場合、高可用性のためには、設置ゾーンごとに仮想マシンを別サブネットに配置してから各サブネットに Azure NAT Gateway を設置する必要があります。

Azure NAT Gateway は、内部ネットワークのプライベートIPアドレスを隠蔽し、外部からの直接アクセスを防ぐことでセキュリティを向上させます。また、送信元IPアドレスが固定されるため、外部サービスからのIPアドレス制限設定が容易になります。

Azure NAT Gateway はフルマネージドサービスであり、設定さえしてしまえば、その後の管理ユーザーのネットワーク管理の負担軽減が期待できます。

Azure NAT Gateway の設定は、いくつかのステップを踏むことでスムーズに行えます。ここでは、基本的な設定手順を解説します。

Azure NAT Gateway をデプロイする前に、まず仮想ネットワーク（VNet）と、Azure NAT Gateway をアタッチするサブネットが準備されていることを確認します。Azure NAT Gateway はサブネット単位でアタッチするため、インターネットへのアウトバウンド接続が必要なリソースが配置されているサブネットを特定しておく必要があります。同じ Vnet 内であれば、複数のサブネットにアタッチ可能です。

Azure NAT Gateway をアタッチしたいサブネットにて、ルートテーブルを設定していない場合はルートテーブルの構成は不要です。

他のクラウド環境の場合、NATゲートウェイを介してインターネットに接続するためには、該当するサブネットのルートテーブルにて、インターネット抜けのデフォルトルート（0.0.0.0/0）のネクストホップをNATゲートウェイに指定する等の設定が必要になります。

しかし、Microsoft Azure のルートテーブルでは「システムルート」という自動的に作成され、明示されずに各サブネットに適用されるルートテーブルがあります。Azure NAT Gateway をサブネットにアタッチすると、このシステムルートが更新され、サブネットからのすべてのインターネット向けアウトバウンド通信が Azure NAT Gateway を経由するように自動で変更されます。

既存ルートテーブルにて、インターネット抜けルートをオーバーライドするようなルートを手動で設定していないかをご確認ください。

例）サブネットからの全通信を Azure Firewall 経由にしている場合や、強制トンネリングなどを実施している場合

このようなユーザー定義ルートがある場合、該当ルートがシステムルートより優先されてしまうため、Azure NAT Gateway を通過しません。

NATゲートウェイは、Azure Portal、Azure CLI、または Azure PowerShell を使用して作成します。今回は、Azure Portal 上での作成方法を紹介します。

まず、Azure Portal にログインし、「NATゲートウェイ」へ移動します。左上の「＋作成」を選択します。

Azure NAT Gateway の名称や、配置先など基本情報を設定します。

可用性ゾーン設定では、アタッチ先サブネット内のVMが配置されている可用性ゾーンを指定してください。「ゾーンなし」を設定可能ですが、アタッチ先のサブネット内リソースが配置されているゾーンに自動的に設置されます。

TCPアイドルタイムアウト（分）とは、TCP接続が非アクティブな状態が続いた場合に接続を閉じるまでの時間を設定します。デフォルトは4分ですが、アプリケーションの要件に合わせて最大120分まで延長できます。これにより、長時間のアイドル状態が続く接続でも、意図せず切断されることを防ぎます。

Azure NAT Gateway には、1つ以上のパブリックIPアドレスまたはパブリックIPプレフィックスを割り当てます。パブリックIPプレフィックスを使用すると、複数のパブリックIPアドレスをまとめて管理でき、将来的なIPアドレスの追加も容易になります。

今回はパブリックIPアドレスを１つ新規作成し、アタッチします。

Azure NAT Gateway をアタッチするサブネットを指定します。アタッチしたいサブネットが所属する仮想ネットワークを指定し、サブネットを選択します。サブネットは複数選択することが可能です。

適宜タグを設定し、最後に設定したパラメータを確認して「作成」を選択して作成完了です！

Azure NAT Gateway の設定が完了したら、実際にテストを行い、アウトバウンド通信制御が有効になっているかを確認します。

まず、作成した Azure NAT Gateway に移動し、サイドバーから「送信IP」を選択します。開かれた画面から、新規作成してアタッチしたパブリックIPを確認しましょう。

次に、Azure NAT Gateway をアタッチしたサブネット内のVMから外部インターネットにアクセスし、送信元IPアドレスが Azure NAT Gateway に割り当てたパブリックIPアドレスになっていることを確認します。

サーバに接続し、Powershell にて以下コマンドを実行します。先ほど確認した Azure NAT Gateway のパブリックIPが表示されれば完了です！

＜コマンド＞curl ifconfig.me

Azure NAT Gateway の設定中に発生する一般的な問題として、ルートテーブルの設定ミス、パブリックIPアドレスの割り当てミス、またはネットワークセキュリティグループ（NSG）による通信ブロックなどが挙げられます。

これらの問題が発生した場合は、各リソース設定画面から設定を確認する他、Azure Monitor のネットワーク診断ツールなどを活用して原因を特定してみましょう。

Azure NAT Gateway のよくある質問については、こちらの Microsoft 公式記事をご確認ください！

Azure NAT Gateway の導入にはコストが発生します。既定の送信アクセス廃止対策の全体的なコストを正確に把握するため、まずはその料金体系を確認しましょう。

Azure NAT Gateway の料金は、主に以下の2つの要素で構成されます。

これらの料金はリージョンによって異なる場合があるため、最新の料金情報は以下の Microsoft Azure 公式の料金確認サイトでご確認ください。

Azure NAT Gatewayのコストを最適化するためのヒントは、いくつかあります。

例えば、以下のようなものが挙げられます。

これらのヒントを参考に、現環境の設定を再度確認してみてください。

Azure NAT Gateway を導入した後も、そのパフォーマンスと安定性を維持するためには適切な運用が不可欠です。監視やログ分析方法についての手法例を紹介します。この段落の最後に参考用の Microsoft 公式記事も掲載していますので、ご興味がある方はそちらもご確認ください。

Azure NAT Gateway の健全性とパフォーマンスを継続的に監視するためには、Azure Monitor を活用した監視体制をお勧めします。

例えば、Azure Monitor にて、Azure NAT Gateway の接続数、データ転送量、ポート使用状況などのメトリックを、Azure Monitor に送信するように設定します。これらのメトリックを監視することで、潜在的な問題を早期に発見することができ、アラートを設定することができるので、エラー発生時の迅速な対応につながります。

Azure NAT Gateway の診断ログを有効にし、Azure Log Analytics などのツールを使用してログを分析することで、ネットワーク通信のパターンを把握し、パフォーマンスのボトルネックを特定しやすくなります。

例えば、特定のアプリケーションからの接続が集中している場合や、不必要なアウトバウンド接続が発生している場合などを特定し、改善策を講じることが可能です。

Azure Monitor、Azure Log Analytics との連携についての詳細情報は以下の Microsoft の公式記事をご確認ください。