はじめに
AWS re:Invent 2025で開催されたLevel 300セッション「Automate high availability and enhance security with Regional NAT」に参加してきました。スピーカーはVinod Katariaさん（AWSネットワーキング スペシャリストソリューションアーキテクト）とBhargav Talluriさん（AWSネットワークサービス プロダクトリード、ルーティング担当）のお二人でした。
AWS re:Inventのカレンダー上は"Level: 300 – Advanced"と記載されていましたが、VinodさんはLevel 200と言われていました。
単に間違えたのか、セッションのスポンサーの想いと異なるのか...どうなんでしょうね。
本チョークトークは通常のセッションと異なり、スライドだけでなくホワイトボードも使いながらインタラクティブに進行するスタイルでした。セッションの途中でも適宜参加者からの質問が差し込まれ、積極的な数名の方が次々と質問を投げかけていました。また、最初にNAT Gatewayを使っているか？という質問対して、ほぼ全員の手が挙がっていました。
セッションを文字起こしした内容を中心に記載しております。
ある程度裏どりはしていますが、誤った文字起こしを元に記載している可能性がある点ご注意ください。
Regional NAT Gatewayとは
Regional NAT Gatewayは、通称Pre-re:Inventと呼ばれる期間に相当する2025年11月19日にリリースされた新機能です。
従来のZonal NAT Gatewayは高可用性のためにゾーン単位で設計されており、各アベイラビリティゾーン（AZ）のPublic SubnetにNAT Gatewayを配置する必要がありました。
一方でRegional NAT Gatewayは高可用性をマネージドに、リージョン単位で設計してくれます。詳細は後続のセッション内容をご覧ください。
セッション内容
お客様から寄せられていた課題
まず、現在のNAT Gatewayについて整理されました。
現在のNAT Gatewayは以下の図のような構成を取ります。
VPC内の2個のAZにそれぞれPublic SubnetとPrivate Subnetが存在しています。この例では、us-east-1リージョンにVPCを用意しています。それぞれのPublic SubnetにNAT Gatewayが配置されています。これにより、各Private Subnetからインターネットへのアウトバウンド通信が可能になります。
重要なのが、各AZのPrivate SubnetにはZonal NAT Gatewayを指すルートテーブルが存在するということです。
従来はこのスタイルが標準でしたが、この場合の課題は、利用する各AZごとに1個のPublic SubnetとNAT Gatewayが必要であったことでした。新しいAZで新しいワークロードを立ち上げるたびに、手動で上記セットを追加する必要があったことは、運用上の手間を増やしました。また、それだけでなくルートテーブルにエントリを追加する必要があることも同様に面倒な設定でした。
この状況に対し、お客様からの以下のようなフィードバックが寄せられていました。
- どこにNAT Gatewayをインスタンス化すればよいか追跡するのが難しい
- 新しいAZにワークロードを展開するたびに手動で拡張が必要
- セキュリティポリシーやルーティングに詳しくない担当者がPublic SubnetでNAT Gatewayを設定する際に、間違いを起こす可能性がある
これらの声を受けて、Regional NAT Gatewayが開発されたとのことです。
Regional NAT Gatewayとは
Bhargavさんから説明されたRegional NAT Gatewayの特徴は以下の通りです。
- 複数AZにまたがる単一のNAT Gateway
- AZレベルではなくVPCレベルで機能し、1個のNAT Gatewayで複数のAZに対応します。
- 自動的な拡張・縮小
- ENIを検出し、AZ内のワークロードを検出して自動的に拡張します。ワークロードがなくなれば自動的に縮小します。
- 詳細は後述
- 専用ルートテーブル
- Regional NAT Gateway作成時に専用のルートテーブルが自動生成されます。
- このルートテーブルには0.0.0.0/0がインターネットゲートウェイを指すルートが含まれており、Private Subnetをこのルートテーブルに関連付けることで、Regional NAT Gateway経由でのインターネット通信が可能になります。
- Public Subnet不要
- VPCのCIDRからプライベートIPは使用されず、Public Subnetを使用しなくなるためセキュリティが向上します。
- IPAMポリシーとの統合
- IPAMポリシーを使用することで、NAT Gatewayに割り当てられるIPアドレスを指定したIPプールから予測可能な形で割り当てることができます。
- ユースケース:「これらのNAT Gatewayには連続したIPアドレスを割り当てたいが、その割り当て元はこのIPプールだけに限定したい」といった制御が可能になります。
デプロイメントモード
Regional NAT Gatewayには2個のデプロイメントモードが存在します。
自動モード
これがRegional NAT Gatewayの真骨頂と言えるモードで、より多くの場面で役立ちます。
自動モードの特徴は以下です。
- VPC内のENI（Elastic Network Interface）の存在を検出し、アクティブなENIがあるAZに、自動的にNAT Gatewayインスタンスが起動
- 最後のENIがなくなったAZからは自動的に削除
- Elastic IP （EIP）割り当ても自動
手動モード
手動モードの特徴は以下です。
- 展開するAZを明示的に選択（例：AZ-AとAZ-Bでアクティブにしたい）
- どのEIPを割り当てるかを選択
- 追加が必要な場合は設定画面で別のAZやIPを有効化
コンソール画面
NAT Gatewayの詳細ページには以下の新しいフィールドが表示されます。
- アベイラビリティモード：「ゾーナル」ではなく新しい「リージョナル」モード
- EIP割り当て方法：「自動」または「手動」
なお、Regional NAT Gatewayに割り当てられるパブリックIPアドレスは、AWS独自のCIDRから提供されます。VPCのSubnet内のIPアドレスは消費されません。
また、現在Regional NAT Gatewayはパブリック向けで、プライベートNATはサポートされていません。パブリックIPアドレスが必要です。そこでそのIPアドレスが割り当てられ、リモートの宛先ではトラフィックが届いたときにそのIPアドレスが確認されます。
ルートテーブル
Regional NAT Gateway作成時に専用のルートテーブルが自動生成されます。このルートテーブルはRegional NAT Gatewayを削除しない限り削除できません。
デフォルトのエントリに加えて、カスタムルートを追加することができます。カスタムルーティングをしたい場合は、ここで指定します。
超余談ですが...
「Regional NAT Gateway作成時に自動生成された専用のルートテーブル」に対し、以下の操作ができる/できないことを確認しました。
既存のエントリ(InternetGatewayへ0.0.0.0/0の経路)の削除：可能
エントリの追加：可能
エントリの削除：可能
subnetへのアタッチ：可能
subnetからデタッチ：可能
ルートテーブルの削除：不可
ファイアウォールとの統合シナリオ
Regional NAT Gatewayとファイアウォールを組み合わせたアーキテクチャが紹介されました。
構成としては、アプリケーションサブネットからファイアウォールサブネットへトラフィックを送信し、ファイアウォールサブネットのルートテーブルがRegional NAT Gatewayを指すようにします。
Regional NAT Gatewayのルートテーブルにカスタムルートを追加することで、アプリケーションサブネットからのトラフィックをファイアウォールエンドポイント経由で処理させることができます。
移行方法
Zonal NAT Gateway(従来のNAT Gateway)からRegional NAT Gatewayへの移行手順が説明されました。
- Regional NAT Gatewayをプロビジョニング（この時点ではトラフィックに影響なし）
- プライベートルートテーブルを変更し、0.0.0.0/0をZonal NAT GatewayからRegional NAT Gatewayに向ける
- トラフィックをテストして動作確認
- 各AZのルートテーブルについて手順2-3を繰り返す
- 検証完了後、Zonal NAT Gatewayを削除
移行時の注意点として、ルートテーブルを切り替える際に接続の中断が発生するため、メンテナンスウィンドウでの実施が推奨されます。
スケーリングの仕組み
スケーリングについて以下の説明がありました。
-
スケールアップ(Regional NAT Gatewayの数を増やす)
- ユニークな宛先への接続数が40,000に達すると、追加のEIPを割り当て
- 55,000接続まで対応可能だが、40,000時点でプロアクティブにスケール
- スループットは5 Gbpsから最大100 Gbpsまで拡張可能
-
スケールダウン(Regional NAT Gatewayの数を減らす)
- 接続数が20,000以下の状態が1時間継続すると、EIPを解放
- ENIがなくなったAZからは自動的に撤退
- スケールダウンはより保守的に行われる
-
制限値
- VPCあたりのRegional NAT Gateway数：5（ソフトリミット）
- AZあたりの最大EIP数：32
- ユニークな宛先あたりの最大接続数：55,000
32 EIP × 55,000接続で、ユニークな宛先に対して約160万〜180万の同時接続が可能という計算になります。途方もないですね。
料金について
Vinodさんから、料金について説明がありました。
料金体系は従来のZonal NAT Gatewayと同じで、以下の2個の要素で構成されます。
- ゲートウェイ稼働時間（アクティブなAZごとの時間課金）
- 処理されたデータ量（GB単位）
例えば、3個のAZでZonal NAT Gatewayを運用していた環境を、Regional NAT Gatewayで同じ3個のAZをカバーする構成に変更した場合、コストに違いはありません。アクティブなAZの数に基づいて課金されます。
質疑応答セッション
本セッションでは、セッションの途中でも参加者から適宜質問が差し込まれました。以下にその内容をまとめます。
質疑応答セッションは、できる限り発言をそのまま記載しています。
Q1: ルートテーブルの設定について
質問者: Regional NAT Gatewayを使う場合、ルートテーブルはどのように設定するのですか？
Vinodさん: NAT Gateway処理が必要な、またはインターネットに到達可能なすべてのSubnetのルートテーブルに、Regional NAT Gatewayを設定する必要があります。ただし、覚えるべきNAT Gateway IDは1個だけになります。以前は各AZごとにNAT Gatewayを立ち上げて、「これはAZ-1のものだったか、AZ-2だったか」とIDをマッピングする必要がありましたが、その必要がなくなります。
Q2: Internet Gatewayとの共存について
質問者: Internet Gatewayは引き続き使用できますか？
Vinodさん: はい、両方とも共存します。Zonal NAT Gatewayはなくなりません。RegionalとZonalの両方のオプションがあります。使いやすさや、複数のゲートウェイを管理する場合と1個のNAT Gatewayを管理する場合の運用負担の違いがポイントです。
Q3: コストの違いについて
質問者: RegionalとZonalでコストの違いはありますか？
Vinodさん: 同じワークロードの場合、違いはありません。アクティブなAZの数が同じであれば、コストは同じです。
Q4: 移行時の接続中断について
質問者: 移行時、ルートテーブル切り替えで接続は中断されますか？
Vinodさん: はい、接続に影響が出ます。メンテナンスウィンドウ中に実施し、接続が確立されていることを確認することを推奨します。
Q5: 既存EIPの引き継ぎについて
質問者: 既存のEIPを引き継ぐにはどうすればよいですか？3rd partyの許可リストに登録されているEIPがあるのですが。
Vinodさん: 以下の手順で対応できます。
- Regional NAT Gatewayを作成（新しいEIPが割り当てられる）
- Zonal NAT Gatewayを削除（EIPが解放される）
- 解放されたEIPをRegional NAT Gatewayに割り当て
- ルートテーブルを切り替え
Q6: BYOIPについて
質問者: BYOIP（Bring Your Own IP）は使えますか？
Vinodさん: はい、使えます。
Q7: 一部のAZのみにNAT Gatewayを配置する場合
質問者: 6個のAZがある場合、2個だけにNAT Gatewayを配置することは可能ですか？
Vinodさん: 手動モードでのみ可能です。その場合、残りのAZからのトラフィックはクロスAZトラフィックになります。自動モードでは、ENIが検出されたAZに自動的にNAT Gatewayが展開されます。
クロスAZトラフィックが大量にある場合はローカルのNAT Gatewayを使う方が理にかなっていますが、小規模なワークロードの場合は余分なゲートウェイの稼働時間を回避できます。これはトレードオフです。
クロスAZトラフィックには追加のデータ転送料金（GB単位）が発生するため、トラフィック量とNAT Gateway稼働コストを比較して判断する必要があります。
Q8: フェイルオーバーについて
質問者: Zonal NAT Gatewayでは手動フェイルオーバーができましたが、Regional NAT Gatewayではどうですか？
Vinodさん: Regional NAT Gatewayでは、その手動フェイルオーバーの仕組みはありません。
ただし、NAT Gateway自体が高可用性を持つように設計されています。裏側でフリートとして運用されており、NAT Gatewayがダウンする可能性は非常に低いです。AZ全体の障害が発生した場合は、そのAZ内のワークロード自体も影響を受けます。
スケーリングについても、入ってくるトラフィックに応じて自動的にスケールするため、大量のトラフィックが流入してもNAT Gatewayがダウンすることは想定されていません。
ここで表現している「Zonal NAT Gatewayでは手動フェイルオーバー」とは、AZ障害時に、管理者が手動でルートテーブルを変更して別のAZのNAT Gatewayに切り替える運用上の対応を指していると想像しています。
Q9: 100 Gbpsを超えるスループットが必要な場合
質問者: 100 Gbpsを超えるスループットが必要な場合は？
Bhargavさん: 別のRegional NAT Gatewayを立ち上げて、トラフィックを分散する必要があります。
Q10: ダウンスケール時のEIP解放について
質問者: Regional NAT Gatewayをダウンスケールするとき、EIPは解放されますか？
Vinodさん: はい、解放されます。AZが空になり、ENIが存在しなければ自動的に縮小します。接続数が20,000以下の状態が1時間続き、既存のIPで十分であれば自動的に縮小します。
Q11: 特定の宛先に特定のEIPを使う制御について
質問者: AZあたり32個のEIPがあるとのことですが、特定の宛先に特定のEIPを使うように制御できますか？
Vinodさん: 自動的にEIPが割り当てられ、接続数が増えると追加されます。「この宛先にはこの特定のEIPを使う」という制御はできません。
ただし、IPAMポリシーを使用することで、どの範囲からIPアドレスを割り当てるかを事前に定義できます。これにより、どのIPが使われるかを予測可能にできます。
Q12: 自動でEIPが追加される条件について
質問者: 自動でEIPが追加される条件は？また、そのイベントを知る方法は？
Vinodさん: ユニークな宛先への接続数が40,000を超えると、追加のEIPが割り当てられます。合計の接続数ではなく、特定の宛先への接続数です。
手動モードの場合は、CloudWatchメトリクスを監視して、接続数が40,000に達した場合や、ポート割り当てエラーが発生した場合に手動でEIPを追加する必要があります。
Q13: IaCツールのサポート状況について
質問者: CDK、CloudFormation、Terraformでデプロイできますか？
Vinodさん: CloudFormationとAWS CLIは対応済みです。
Bhargavさん: Terraformについては、リリースから1〜2週間後ということもあり、AWS Providerでの対応は準備中です。
（理解整理）Zonal NAT Gatewayが適するケース
今回の話を聞くに、基本的に今後はRegional NAT Gatewayを使うべし！という文脈に思えます。
ただし、以下のようなケースではZonal NAT Gatewayが適している、または必要となりそうです。
- Private NAT Gatewayが必要な場合
- Regional NAT GatewayはPublic NAT Gatewayのみ対応しています。
- VPC間やオンプレミスとの通信でPrivate NAT Gatewayが必要な場合は、Zonal NAT Gatewayを使用する必要があります。
- 手動フェイルオーバーの制御が必要な場合
- Q8で言及されたように、Zonal NAT Gatewayでは、AZ障害時に手動でルートテーブルを別のAZのNAT Gatewayに切り替えることができました。
- Regional NAT Gatewayではこの手動フェイルオーバーの仕組みがありません。
- ただし、Vinodさんの回答では「NAT Gateway自体が高可用性を持つように設計されており、ダウンする可能性は非常に低い」とのことで、実際にこれが必要になるケースは限定的かもしれません。
- 特定のEIPを特定の用途に厳密に紐づけたい場合
- Q11で言及されたように、Regional NAT Gatewayでは「この宛先にはこのEIP」という細かい制御はできません。
- IPAMポリシーで「どの範囲から割り当てるか」は制御できますが、コンプライアンス要件などで厳密なIP制御が求められる場合は、Zonal NAT Gatewayの方が適している可能性があります
- 既存環境で問題なく動作しており、移行リスクを取りたくない場合
- 移行時に接続の中断が発生するため、ミッションクリティカルな環境で「動いているものを変えたくない」という判断もあり得ます。
- Vinodさんも「Zonal NAT Gatewayはなくなりません」と明言しており、無理に移行する必要はありません。
おわりに
Regional NAT Gatewayは、従来のZonal NAT Gatewayの運用上の課題を解決する新機能であり、基本的にはこれから新規で構築する環境に導入することはほぼほぼ損はないように感じました。
改めて、メリデメを整理しておきます。
メリット
- 管理対象のNAT Gatewayが1個に集約され、運用が簡素化
- Public Subnetが不要になり、セキュリティが向上
- ワークロードの拡張・縮小に自動で追従
- 料金は従来と同等
デメリット
- 移行時は接続の中断が発生する
- 手動フェイルオーバーの仕組みはない（ただし高可用性は組み込み済み）
既存環境からの移行は必須ではなく、Zonal NAT Gatewayは引き続き利用可能です。ただし、新規構築や運用簡素化を検討している場合は、Regional NAT Gatewayの採用を検討する価値があると感じました。
チョークトークならではのインタラクティブな進行で、積極的な参加者から次々と質問が飛び交い、実務で気になるポイントについて詳しく聞くことができました。NAT Gatewayを使っている方は、メリデメを踏まえたうえでぜひ検討してみてはいかがでしょうか。