はじめに
こんにちは、NTTテクノクロス株式会社の渡邉です。
2025年11月19日、NAT Gatewayに「リージョン別の可用性（regional availability mode）」が追加されました。
リリース文を読んだ瞬間は「単なるマルチAZ対応か」と流しそうになったのですが、改めて確認すると、VPC設計のベストプラクティスに影響のある大きなアップデートであることがわかりました。
本記事は、re:Invent 2025のキャッチアップとして社内勉強会で発表した内容を元に、リージョナルNAT Gatewayの何が凄いのか、そして従来のNAT Gatewayと「完全上位互換ではない」点を紹介します。
従来のNAT Gateway
AWSの定番構成といえば、各AZにPublic SubnetとPrivate Subnetを切り、Public Subnet側にNAT Gatewayを置くよく見る構成です。AWS公式ドキュメントでもお馴染みですね。
出典：Example: VPC with servers in private subnets and NAT
NAT GatewayはVPCからインターネットへのアウトバウンド通信を担うマネージドNATサーバーで、Private Subnet内のインスタンスは、NAT GatewayのIPアドレスを使って外部サービスへ接続します。運用が楽でスケールも勝手にやってくれる、良いサービスです。
ただし、従来のNAT Gateway（リージョナルNAT Gatewayとの対比でZonal NAT Gatewayとも表記します）には、AZに紐づくサービスであるがゆえの課題がありました。
課題1：AZを増減させるたびに発生するネットワーク作業
ワークロードを新しいAZに展開するたび、NAT Gatewayについては以下の作業が必要でした。
- 新AZにPublic Subnetを作成し、IGWへのルートを設定
- そのAZ用のNAT Gatewayを作成
- EIPを払い出して関連付け
- Private Subnet用ルートテーブルにNAT Gateway向けルートを追加
1VPCの2AZ → 3AZ変更だけなら大したことはないのですが、環境種別(dev/stg/prod)や複数VPC、パブリックIPアドレスの管理まで掛け合わさると地味にしんどい作業になります。ほとんどAWS側の管理なので、いっそAuto Scalingもしてくれればいいのに......と感じたこともありました。
課題2：NATがあるAZの障害対応
従来のNAT GatewayはAZ内で冗長化こそされていますが、特定のAZに配置されるため、そのAZの障害の影響を免れません。一方でルートテーブルは静的なままなので、AZ障害時に「正常なAZのNAT Gatewayへトラフィックを向け直す」仕組みは自前で用意する必要がありました。
ではフェイルオーバーを自作するとどうなるか。NLB＋Proxyを挟んでヘルスチェックを通し、HealthyなProxyにのみルーティングする……といった構成が知られていますが、正直かなり大掛かりです。NAT越えのアウトバウンドを担保するためだけにプロキシ層を運用するのは、本末転倒感すらあります。
2025/11/19：リージョナルNAT Gatewayの登場
そこで登場したのがリージョナルNAT Gatewayです。
ワークロードの存在状況に基づいてVPC内の複数のAZにまたがって自動的に拡張および縮小する単一のNAT Gatewayを作成できるようになります。
リージョナルNAT Gateway、すなわちNATのマルチAZサポートがされるようになりました。これにより、AZ障害対応のためのプロキシ層も、AZ拡張のたびのネットワーク作業も不要になります。
……で、終わらない。のがこのアップデートです。単なる「マルチAZ対応」に留まらない、ベストプラクティスが変わる3つのポイントを見ていきましょう。
凄さ1：Public Subnet無しで動作する
個人的に一番のインパクトはここです。リージョナルNAT Gatewayは図のようにPublic Subnetを必要としません。
出典：Introducing Amazon VPC Regional NAT Gateway
従来のNAT Gatewayはユーザー管理のSubnetに明示的に配置するリソースでした。そのため、アウトバウンド通信のみが必要なワークロードであっても、NAT Gatewayを置くためだけにPublic Subnetを各AZに用意する必要がありました。リージョナルNAT GatewayはVPCに対して作成されるリソースで、専用のリージョナルNAT用のルートテーブルが自動で用意されます。このルートテーブルにはIGW向けのデフォルトルートが事前構成済みなので、ワークロード側のルートテーブルのターゲットとして指定するだけで扱えます。
このアップデートにより、アウトバウンド通信しか必要のないワークロードはPublic Subnetを削除できます。また、CloudFront VPC オリジン機能でインバウンド通信が賄える場合は、VPC内のサブネットを全てPrivate Subnetで構成する運用も現実的になります。
「Public Subnetが存在しない＝インターネットから直接到達可能なリソースを置く場所がそもそも無い」ので、セキュリティレビューや監査の説明もシンプルになり、理想的なVPC運用に大きく近づくのが魅力です。
注意： Internet Gatewayは必要
ここで注意したいのは、Public Subnetが不要になっても、VPCとInternet Gatewayの関連付け自体は必要という点です。NAT後の通信は、自動作成されたルートテーブルのIGW向けルートを通ってインターネットへ出ていきます。不要になるのは「IGWに直接面するサブネットのユーザー管理」であって、VPCからIGWを完全に消せるわけではありません。
Network Firewall、IPAMとの連携
「NAT Gatewayの手前でNetwork Firewallを通したい」という要件も引き続き対応できます。従来よりルートテーブルの本数が減った分、設計の見通しは良くなりました。
出典：Introducing Amazon VPC Regional NAT Gateway
また、NAT Gatewayに付与するパブリックIPアドレス(EIP)の管理についてはIPAM（Amazon VPC IP Address Manager）との連携がサポートされています。IPAMのパブリックプールからCIDR単位でアドレスを払い出す運用にしておけば、リージョナルNAT GatewayがAZ拡張してアドレスが増えても、IPAMポリシーとマネージドプレフィックスリストの自動更新で追従できます。
ちなみに、リージョナルNAT GatewayはAZあたり最大32個のIPアドレスをサポートしており（Zonalは8個）、同一宛先への同時接続数の上限も引き上げやすくなっています。
凄さ2：自動モード
リージョナルNAT Gatewayには自動モードと手動モードがあります。自動モードでは、課題1で挙げたAZごとのネットワーク作業（NAT Gatewayの作成、ルートテーブルとルートの管理、EIPの関連付け）がまるごと不要になります。
自動拡張のタイムラグ
自動モードでは、ワークロードを新しいAZに展開すると、リージョナルNAT GatewayがそのAZのENIを検知して該当AZへ自動的に拡張します。ただし、この拡張は即時ではありません。AWS公式ブログでは、新しいAZへの拡張に平均15〜20分、最大で60分かかる可能性があると説明されています。
RNAT takes an average of 15-20 minutes and can take up to a maximum of 60 minutes, to expand to a new AZ upon ENI detection in that AZ.
出典：Introducing Amazon VPC Regional NAT Gateway
拡張が完了するまでの間、そのAZのワークロードからの通信は、既存AZ側のリージョナルNAT Gatewayでクロスゾーン処理されます。つまり、AZ展開直後からAZローカルなNAT処理を確実にしたい場合や、AZ間のデータ転送を厳密に抑えたい場合は、手動モードで事前にAZとEIPを構成しておく必要があります。
モードの選び分け
判断基準も整理しておきます。
| 観点 | 自動モード | 手動モード |
|---|---|---|
| EIP管理 | 自動（Amazon提供IP、またはIPAMポリシーに基づく割り当て） | 手動で特定のEIPを指定 |
| 接続先への許可リスト | CIDR単位で伝えられる場合 | IPアドレス単位で固定が必要な場合 |
| AZの拡張・縮退 | AZ内のENI有無で自動追従（最大60分） | 自己管理（AZ・EIPの構成） |
| 向いているケース | ネットワーク設定を最小限にしたい | 1AZ運用などのコスト重視、IP固定要件 |
基本的に「接続先がIPをどう許可しているか」で、モード選定が決まるでしょう。外部SaaSや取引先システムに対して送信元IPアドレスを許可リスト登録してもらっている環境では、自動モードでアドレスが増減すると困ります。また、可用性よりランニングコスト重視の場合にも手動モードが適します。そうした制約がなければ、拡張作業をAWSに任せられる自動モードが基本です。
凄さ3：お値段据え置き
新機能で一番気になるのはお金ですが、AZあたりのNAT Gateway単価は従来と同じです。東京リージョンの場合、時間課金は$0.062/時間、データ処理料金は$0.062/GBのままです。
ただし、リージョナルNAT Gatewayの時間課金は構成されているAZごとに発生します。単一のNAT Gateway IDになっても課金が1つ分になるわけではないため、NAT Gatewayの数を減らすコスト最適化とは相性が良くない場合もあります。
リリース後に改善された点
2025/11直後に不足していたが、解決した問題にも触れておきます。
Transit Gatewayとの連携
実務ではTransit Gatewayを使って複数VPCのアウトバウンドをEgress VPCのNAT Gatewayに集約し、コスト最適化する構成を取っている組織は多いと思います。
リージョナルNAT GatewayのGA当初は、戻り通信のためにTransit Gatewayをターゲットにしたルートを作成しようとするとエラーになるため、NAT集約構成はZonal一択、という検証報告もありました。しかし2026/5にいつの間にか解決していたようです。現在の公式ドキュメントでは、リージョナルNAT GatewayのルートテーブルでTransit Gatewayが有効なターゲットとしてサポートされていることが明記されています。
完全上位互換ではない
Zonal NAT Gatewayを残すべきケースが明確に一つあります。リージョナルNAT GatewayはプライベートNATには対応していない旨が、公式ドキュメント・公式ブログに明記されています。
Private connectivity type is not supported by RNAT at launch. For workloads requiring private connectivity, we recommend continuing with the zonal NAT Gateway implementation.
出典：Introducing Amazon VPC Regional NAT Gateway
プライベートNATとは、VPC内・VPC間での通信経路を集約するためのNAT Gatewayです。オンプレとのCIDR重複回避など、プライベート接続のためにNAT Gatewayを使っているケースでは、引き続きZonal NAT Gatewayを使う必要があります。
それ以外にも、AZ展開直後からAZローカルなNAT処理を保証したい場合（前述の自動拡張タイムラグ）や、ログ分析がNAT GatewayのENIを前提にしている場合（後述）は、Zonal NAT Gatewayの維持や手動モードでの事前構成が候補になります。
既存Zonal NAT Gatewayから移行する場合の注意点
既存のZonal NAT Gateway構成からリージョナルNAT Gatewayへ移行する場合、ルートテーブルの向き先を変更するタイミングで既存の接続はリセットされます。公式ドキュメントでも、メンテナンスウィンドウ内での作業が推奨されています。
This will reset your existing connections. We recommend that you complete these steps in your maintenance window.
出典：Regional NAT gateways - Convert from zonal to regional NAT gateways
移行方法は大きく2つあります。
1つ目は、新しいリージョナルNAT Gatewayを作成してから切り替える方法です。リージョナルNAT Gatewayを作成し、Private Subnetのルートテーブルをリージョナル側へ向け替え、その後に既存のZonal NAT Gatewayを削除します。作業順序が単純で切り戻しもしやすい一方、送信元IPアドレスが変わります。外部サービス側でNAT GatewayのEIPを許可リスト登録している場合は、事前に登録変更が必要です。
2つ目は、既存のEIPを引き継ぐ方法です。既存のZonal NAT Gatewayを削除してEIPを解放し、そのEIPを使ってリージョナルNAT Gatewayを作成し、ルートテーブルを更新します。送信元IPアドレスを維持できますが、Zonal NAT Gatewayの削除からリージョナルNAT Gatewayの作成・ルート変更までの間、通信断が発生します。
したがって、送信元IPアドレスを変更できる環境では新しいEIPを使った段階的移行、送信元IPアドレスを維持する必要がある環境ではメンテナンスウィンドウ内での一括移行、と使い分けることになります。
監視・ログで変わるポイント
リージョナルNAT GatewayでもCloudWatchメトリクスとVPC Flow Logsを使った監視は可能です。ただし、Zonal NAT Gatewayと同じ前提でログを処理できるとは限りません。
Zonal NAT Gatewayの場合、Flow Logsではrequester-managed ENIの interface-idでNAT Gatewayのトラフィックを識別できました。一方リージョナルNAT Gatewayでは、代わりにresource-idフィールドにNAT Gateway ID（nat-xxxxxxxx）が記録されます。既存のログ分析でENI IDを前提にしている場合は、AthenaやCloudWatch Logs Insightsのクエリ修正が必要になる可能性があります。
CloudWatchメトリクスについては、AWS公式ブログで、AZごとにZonal NAT Gatewayと同様のメトリクスを出力すると説明されています。
you can use Amazon CloudWatch metrics since RNAT emits the same metrics as zonal NAT for each AZ.
出典：Introducing Amazon VPC Regional NAT Gateway
結局、どう選ぶか
判断フローは次のように整理できます。
既存環境については、現行運用で困っていないなら無理に移行する必要はありません。一方で新規構築では、リージョナルNAT Gatewayをデフォルトの選択肢にして良さそうです。
まとめ
リージョナルNAT Gatewayにより、VPCのインターネットegress設計は大きく簡素化できます。特に、NAT Gateway配置用のPublic Subnetを各AZに用意しなくてよくなり、単一のNAT Gateway IDで複数AZのワークロードを扱える点は、運用負荷を下げる効果が大きいです。
一方で、完全な上位互換ではありません。プライベートNATは未サポートであり、新しいAZへの自動拡張には最大60分かかる可能性があります。また、Flow Logsの識別子もZonal NAT Gatewayと同じ前提では扱えません。
新規構築ではリージョナルNAT Gatewayを第一候補にしつつ、プライベート接続・固定EIP要件・AZ展開タイミング・ログ分析要件を確認したうえで選び分けましょう。