2026.09.23 aws

NAT Gatewayの構築手順とリージョナル移行：AZ設計とポート枯渇の実装対処

AWSのNAT Gatewayには、単一のAZで動く従来型（ゾーナル）に加えて、VPC単位で複数AZへ自動的に広がるリージョナルモードがあります。2026年9月時点の公式ユーザーガイドには「Regional NAT gateways for automatic multi-AZ expansion」という章が追加され、プライベート接続が必要なケースを除く全てのユースケースでリージョナルを検討するよう案内する内容です。この記事では、AWS CLIとTerraformでの作成方法、ゾーナル構成からの移行順序、ポート枯渇や350秒タイムアウトの検知までを、公式ドキュメントの数値を根拠に実装手順としてまとめます。NAT Gatewayの役割そのものや料金の比較は既存記事に譲り、ここでは「どう作って、どう運用を回すか」だけを扱います。

まとめ：リージョナルを既定にしてゾーナルを残す境界線

新規にVPCを設計するなら、可用性モードはリージョナルを既定に置いてかまいません。パブリックサブネットが不要になり、AZを増やすたびにNAT Gatewayを作ってルートテーブルを分ける作業が消えます。IPアドレスの上限もAZあたり32個へ広がり、ゾーナルの8個より同時接続の余裕が大きくなります。

ゾーナルを残す判断になるのは3つの場合だけです。プライベートNATが要件に入るとき、対象AZが拡張制約のあるゾーンのとき、そして既存接続を切るメンテナンス枠がどうしても取れないとき。リージョナルはプライベートNATに対応せず、移行では既存接続がリセットされるため、この3つは技術ではなく段取りの問題として先に片付ける必要があります。

運用で最初に仕込むのは、ErrorPortAllocationとIdleTimeoutCountの2つのCloudWatchアラームです。NAT Gatewayの障害は帯域ではなくポートの枯渇として現れ、IPアドレスを足すだけで解消することが多いためです。なお、リージョナルは新しいAZへ広がるまで最大60分かかります。AZをまたぐスケールアウトを自動化しているなら、この待ち時間を前提に切り戻し経路を設計してください。

NAT Gatewayの通信経路とゾーナル・リージョナル2方式の構造差

最初に、2つの可用性モードが通信経路のどこを変えるのかを押さえます。NATの変換そのものは同じで、違うのは配置単位とルートテーブルの持ち方です。

パブリックとプライベートで変わる戻り経路とElastic IPの有無

NAT Gatewayには接続タイプが2つあります。パブリックはパブリックサブネットに置き、作成時にElastic IPの関連付けが必須です。プライベートサブネットからの通信はNAT Gatewayでプライベート IPv4 アドレスへ変換され、その後インターネットゲートウェイがElastic IPへ変換して外へ出ます。

プライベートNAT Gatewayは別物です。Elastic IPを関連付けられず、Transit Gatewayや仮想プライベートゲートウェイ経由でオンプレミスや他VPCへ抜けるときに使います。インターネットゲートウェイへルーティングしてもトラフィックは破棄される、とAWSのNAT gatewayユーザーガイドに明記されています。ここを取り違えると疎通しません。

接続タイプと役割の整理はAWS NATゲートウェイとインターネットゲートウェイの違いで図解しています。本記事は作成後の運用に絞ります。

帯域5Gbps・100万ppsから始まる3種類の上限値と超過時の挙動

NAT Gatewayの性能上限は3つあり、どれに当たっているかで打ち手が変わります。公式のNAT gateway basicsによれば、帯域は5Gbpsから始まり100Gbpsまで自動でスケールします。パケットは毎秒100万パケットから始まり、1,000万パケットまで自動で伸びる仕様です。この上限を超えるとパケットは破棄されます。

3つめが同時接続数です。1つのIPv4アドレスあたり、宛先IP・宛先ポート・プロトコルの組み合わせごとに55,000接続まで。数万クライアントが同じAPIエンドポイントを叩く構成では、帯域に余裕があってもここから先に詰まります。

帯域とパケットの上限に当たった場合、公式の対処はサブネットを分割してNAT Gatewayを増やすことです。同時接続の場合はIPアドレスを足すほうが先で、作り直しは不要。どの壁に当たったかはCloudWatchのメトリクスで切り分けます。

ゾーナル8IPに対しリージョナル32IPというポート上限の設計差

ゾーナルNAT GatewayにひもづけられるIPv4アドレスは、プライマリ1つとセカンダリ7つの計8つまでです。これに対しリージョナルはAZあたり32個まで持てます。IPが1つ増えるごとに、同じ宛先への同時接続が55,000本ずつ増える計算です。

観点	ゾーナル	リージョナル
配置単位	AZごとに1台	VPCに1台
パブリックサブネット	必要	不要
IPアドレス上限	8個（1＋7）	AZごとに32個
プライベートNAT	対応	非対応
AZ拡張	手動で作成	自動（最大60分）
ルートテーブル	AZごとに分割	同一エントリを共有
メトリクスの軸	NatGatewayId	NatGatewayIdとAZ

表の最終行は監視設計に効きます。ゾーナルはNatGatewayIdだけで一意に決まりますが、リージョナルで見るのはNatGatewayIdとAvailabilityZoneの組です。既存のダッシュボードをそのまま持ち込むと、AZごとの値が合算されずに欠けて見えることがあります。

リージョナルNAT Gatewayの作成手順とAWS CLI・Terraformの記述差

作成そのものは短く終わります。サブネットを指定しない点と、ルートテーブルが自動で用意される点が従来と異なります。

availability-mode regionalを指定するCLIの実行例と確認

マネジメントコンソールでは、NAT Gatewayの作成画面で「Availability mode」にRegionalを選び、VPCを指定します。サブネットの指定欄は現れません。CLIなら次の1行です。

aws ec2 create-nat-gateway \
  --vpc-id vpc-0a1b2c3d4e5f67890 \
  --availability-mode regional \
  --tag-specifications 'ResourceType=natgateway,Tags=[{Key=Name,Value=egress-rnat}]'

# 作成後の状態とAZごとのアドレス割り当てを確認する
aws ec2 describe-nat-gateways \
  --nat-gateway-ids nat-0123456789abcdef0 \
  --output json

IPアドレスを自分で管理する手動モードを選んだ場合は、AZを指定してElastic IPを関連付けます。公式のリージョナルNAT gatewayの章には、associate-nat-gateway-addressで割り当て、disassociate-nat-gateway-addressで外す手順が載っています。自動モードなら、IPアドレスとAZ拡張の両方を管理するのはAWS側です。特別な事情がなければ自動モードで始めてください。

Terraformのavailability_mode引数とゾーナル記述との差分

Terraform AWSプロバイダのaws_nat_gatewayには、availability_modeという引数があります。Terraform Registryのaws_nat_gatewayによれば値はzonalとregionalの2つで、既定はzonalです。つまり既存のコードを書き換えない限り、挙動は従来のままになります。

# リージョナル: subnet_id も allocation_id も書かない
resource "aws_nat_gateway" "egress" {
  vpc_id            = aws_vpc.main.id
  availability_mode = "regional"

  tags = {
    Name = "egress-rnat"
  }
}

# ゾーナル（従来）: AZごとにEIPとパブリックサブネットが要る
resource "aws_nat_gateway" "zonal_1a" {
  allocation_id = aws_eip.nat_1a.id
  subnet_id     = aws_subnet.public_1a.id

  tags = {
    Name = "egress-nat-1a"
  }
}

差分は3行です。vpc_idを指定し、availability_modeを足し、subnet_idとallocation_idを消す。AZが3つある構成なら、aws_nat_gatewayとaws_eipとパブリックサブネットがそれぞれ3リソースずつ消えます。for_eachでAZを回していたモジュールは、ループごと不要になります。

自動作成されるNAT専用ルートテーブルとミドルボックスの戻り経路

リージョナルNAT Gatewayを作ると、AWSがそのNAT専用のルートテーブルを自動で作り、インターネットゲートウェイへのルートを設定済みの状態で渡します。パブリックサブネットを自分で用意してIGWルートを書く作業は不要です。この自動生成されたルートテーブルは、ファイアウォールなどミドルボックスへの戻りルートを足す場所としても使えます。

# プライベートサブネット側は全AZで同じ1エントリを向ける
resource "aws_route" "private_default" {
  for_each = aws_route_table.private

  route_table_id         = each.value.id
  destination_cidr_block = "0.0.0.0/0"
  nat_gateway_id         = aws_nat_gateway.egress.id
}

従来はAZごとに異なるNAT Gateway IDを向ける必要があり、ルートテーブルをAZ数だけ分ける設計が定石でした。リージョナルでは同じIDを全AZで共有することが可能です。なお公式には、リージョナルNAT Gatewayのルートテーブルで有効なルートとしてTransit Gatewayがサポートされる旨が書かれています。Egress VPCを1本に寄せる構成はTransit Gatewayのクロスアカウント構築手順と組み合わせると全体像がつかみやすくなります。

ゾーナル構成からの移行手順とIPアドレスを保持する場合の停止時間

稼働中のVPCを移行する場合、既存接続がリセットされる点だけは避けられません。公式も「メンテナンスウィンドウ内で実施すること」を推奨しています。IPアドレスを引き継ぐかどうかで、手順の順序と停止時間が変わります。

新しいIPで切り替える3ステップと既存接続がリセットされる範囲

送信元IPを外部に登録していないなら、新しいIPアドレスで作り直すほうが安全です。先にリージョナルNAT Gatewayを作り、ルートテーブルを差し替え、古いゾーナルを消す。この順序なら、切り替え前にNAT Gatewayがavailableになっていることを確認できます。

# 1. 先に作る（この時点では誰も使っていない）
aws ec2 create-nat-gateway --vpc-id vpc-0a1b2c3d4e5f67890 \
  --availability-mode regional

# 2. プライベートサブネットのデフォルトルートを差し替える
aws ec2 replace-route \
  --route-table-id rtb-0123456789abcdef0 \
  --destination-cidr-block 0.0.0.0/0 \
  --nat-gateway-id nat-0fedcba9876543210

# 3. 旧ゾーナルを削除する（Elastic IPは別途解放する）
aws ec2 delete-nat-gateway --nat-gateway-id nat-0123456789abcdef0

ルートを差し替えた瞬間、古いNAT Gateway経由で張られていたTCP接続は切れます。切れるのは外向きの通信だけで、VPC内部の通信や受信側には影響しません。長時間のバッチやDBレプリケーションが外部へ出ているなら、そのジョブを止めてから実行してください。

Elastic IPを引き継ぐ場合に先の削除が必要となる逆順の手順

取引先のファイアウォールに送信元IPを登録している場合、IPアドレスを変えられません。このときは順序が逆になります。既存のゾーナルNAT Gatewayを先に削除してElastic IPを解放し、そのIPを使ってリージョナルNAT Gatewayを作り、最後にルートテーブルを向け直します。

削除から作成完了までの間、プライベートサブネットからの外向き通信は止まります。ここが実質の停止時間で、作成そのものは数分で終わるとはいえ、ルート差し替えまで含めると10分前後は見ておく設計が必要です。IPアドレスの付け替えを伴う作業は、Elastic IPの解放待ちで詰まることもあります。

停止時間を1秒も許容できないなら、移行そのものを見送る判断も成り立ちます。ゾーナルのまま運用を続けても、ポート上限と可用性の要件を満たせているなら実害はありません。

新AZへの拡張に最大60分かかる前提で組むデプロイ計画と暫定経路

リージョナルNAT Gatewayは、新しいAZにENIが現れたことを検知して自動で広がります。ただし即時ではありません。公式には、リソースが起動してからそのAZへ拡張が完了するまで最大60分かかる場合があるとあります。拡張が終わるまでの間、そのリソースの通信は既存AZのNAT Gatewayがクロスゾーンで処理します。

通信は止まらないので機能面の問題は起きません。効いてくるのは料金で、AZをまたぐデータ転送の分が上乗せされます。新AZでの大規模なバッチ実行や、災害対策のAZ切り替え訓練を計画しているなら、対象リソースを1時間前に起動しておくと転送料金の上振れを抑えられます。

逆に、ENIが1つも無くなったAZからは自動で縮小します。夜間にAZ単位でリソースを落とす運用をしていると、拡張と縮小を毎日繰り返す形になるということです。この挙動が読みにくいと感じるなら、手動モードでAZごとのIPアドレスを自分で固定する選択肢もあります。

ポート枯渇と350秒タイムアウトの検知に使うCloudWatchメトリクス

NAT Gatewayで起きるトラブルの大半は、3つのメトリクスを見れば切り分けられます。CloudWatchは1分間隔でデータを配信し、15か月保持します。名前空間はAWS/NATGatewayです。

ErrorPortAllocationが1以上のときに増やすIPアドレスの本数

ErrorPortAllocationは、NAT Gatewayが送信元ポートを割り当てられなかった回数です。公式のメトリクス一覧には「ゼロより大きい値は、同時接続が開きすぎていることを示す」とあります。統計はSum、しきい値は1でかまいません。0か0以外かの二値で扱うメトリクスです。

aws cloudwatch put-metric-alarm \
  --alarm-name rnat-port-allocation-error \
  --namespace "AWS/NATGateway" \
  --metric-name ErrorPortAllocation \
  --dimensions Name=NatGatewayId,Value=nat-0123456789abcdef0 \
  --statistic Sum --period 300 --evaluation-periods 1 \
  --threshold 1 --comparison-operator GreaterThanOrEqualToThreshold \
  --alarm-actions arn:aws:sns:ap-northeast-1:123456789012:ops-alerts

発報したらIPアドレスを足します。1つ足すごとに同一宛先への同時接続が55,000本増えるので、ピーク時の接続数を55,000で割った数が必要なIP数の目安です。リージョナルならAZあたり32個まで、ゾーナルなら8個が天井で、そこを超えるならサブネットとNAT Gatewayの分割に進みます。

IdleTimeoutCountの増加とTCPキープアライブの設定値の決め方

NAT Gatewayは、350秒以上アイドルだった接続をタイムアウトさせます。このときFINではなくRSTパケットを返すため、接続を使い回していたクライアント側は突然のリセットとして受け取ります。公式のトラブルシューティングに「350秒後に接続が切れる」という項目があるのは、この挙動が原因です。

IdleTimeoutCountが増えているなら、アイドル接続を掴んだままのクライアントがいます。対処は2つ。通信を流し続けるか、350秒より短い間隔でTCPキープアライブを送るかです。Amazon Linuxなら次の設定で足ります。

# 300秒無通信でプローブ開始、30秒間隔で5回まで
sudo sysctl -w net.ipv4.tcp_keepalive_time=300
sudo sysctl -w net.ipv4.tcp_keepalive_intvl=30
sudo sysctl -w net.ipv4.tcp_keepalive_probes=5

# 再起動後も効かせる
echo "net.ipv4.tcp_keepalive_time = 300" | \
  sudo tee /etc/sysctl.d/99-nat-keepalive.conf

アプリケーション側のコネクションプールにアイドルタイムアウト設定があるなら、そちらを350秒未満にするほうが確実です。JDBCやHTTPクライアントの既定値が600秒などになっていないか、先に確認してください。

PacketsDropCountが0.01%を超えた場合の切り分けの順序

PacketsDropCountは破棄されたパケット数です。公式は「PacketsDropCount÷（PacketsInFromSource＋PacketsInFromDestination）×100」で割合を出し、全体の0.01%を超えるならVPCサービス側の問題を疑うよう案内しています。この数字が出たときは、まずAWSのサービス状況を確認する順序になります。

0.01%以下なら、自分の構成を疑います。TCP接続の一部だけが失敗する場合、公式が挙げる原因は2つです。宛先がフラグメント化されたTCPパケットを返しているか、リモートサーバでtcp_tw_recycleが有効になっているか。NAT GatewayはTCPとICMPのIPフラグメントをサポートしないため、前者ならNATインスタンスへの切り替えが回避策になります。

切り分けには、パブリックサブネットに置いた別インスタンスからtcpdumpで確認する手順が案内されています。NAT Gateway配下のインスタンスからは確認できない点に注意してください。NATゲートウェイとNATインスタンスの違い・料金で両者の機能差を整理しています。

リージョナルNAT Gatewayを見送る要件とゾーナル残置の代替構成

ここまで作る側の話をしてきましたが、採用しないほうがよい構成もあります。玉虫色にせず、条件で切ります。

プライベートNATと制約AZという2つの非対応条件とその回避策

リージョナルNAT Gatewayはプライベート接続に対応しません。公式も、プライベートNATの用途ではゾーナルの可用性モードを使うよう明記しています。オンプレミスとのIPアドレス重複を避けるためにプライベートNATを噛ませている構成なら、ここは選べません。ゾーナルのまま据え置きます。

もう1つが制約AZです。AWSが拡張余力を確保できないAZではリージョナルNAT Gatewayがサポートされず、ゾーナルの作成時もNotAvailableInZoneエラーになります。この場合の回避策は、別AZにNAT Gatewayを作って制約AZのプライベートサブネットから参照するか、リソース自体を別AZへ移すかの2択です。前者はAZ間のデータ転送料金が常時かかります。

インターネットへの通信そのものを減らせるなら、そちらが本筋です。S3やDynamoDBへの通信が大半を占める構成では、NAT Gatewayを経由させずゲートウェイ型エンドポイントへ流すだけでデータ処理料金が消えます。判断の分かれ目はVPCエンドポイントとNATゲートウェイの料金比較にまとめています。

メンテナンス枠を取れない本番環境での段階移行とロールバック経路

止められない本番環境では、VPC全体を一度に切り替えず、プライベートサブネット単位で移す方法があります。リージョナルNAT Gatewayを追加で作り、影響の小さいサブネットのルートテーブルから順に差し替える。ゾーナルは消さずに残しておけば、ルートを戻すだけで切り戻せます。

この期間は両方のNAT Gatewayが動くため、時間課金が二重にかかります。公式の料金ページのとおり、NAT Gatewayは稼働時間とデータ処理量の2本立てで課金され、部分利用の1時間も1時間として計上されます。実額はリージョンで異なるのでAmazon VPCの料金で確認してください。3AZのゾーナル3台を残したまま並走させると、単純に4台分の時間課金になります。並走期間は週単位で区切るのが現実的です。

移行の順序決めや、Egress設計をTransit Gatewayへ寄せるかどうかの判断で迷う場合は、AWSのインフラ構築支援から構成の相談を受け付けています。既存VPCの構成図と通信量の実測値があれば、並走期間と停止時間の見積もりまで出せます。

よくある質問

NAT Gatewayの構築と移行で実際に問い合わせが多い点をまとめます。

リージョナルNAT Gatewayはゾーナルより料金が安くなりますか？

時間あたりの課金とデータ処理量で課金される仕組みは変わりません。安くなるとすれば、3AZでゾーナル3台を立てていた構成が1つのリージョナルNAT Gatewayに集約され、時間課金の台数が減るケースです。ただしAZをまたぐ通信が増えるとデータ転送料金は上がるため、差引きがどうなるかは通信の分布によります。実額はリージョンで異なるので、公式のAmazon VPC料金ページで確認してください。

NAT Gatewayにセキュリティグループは設定できますか？

できません。公式ドキュメントに、NAT Gatewayにセキュリティグループを関連付けることはできないと明記されています。通信を絞りたい場合は、配下のインスタンス側のセキュリティグループでアウトバウンドを制御するか、サブネットのネットワークACLで制御します。ネットワークACLを書く際は、NAT Gatewayが1024から65535のポートを使う点を踏まえて戻りのトラフィックを許可してください。

既存のTerraformコードにavailability_modeを足すだけで移行できますか？

コード上は1行ですが、terraform applyの挙動としてはリソースの置き換えになり、既存接続は切れます。subnet_idとallocation_idを同時に消す必要もあるため、差分は3行分です。無停止の切り替えにはならないので、先にリージョナル用のリソースを別名で追加し、aws_routeの向き先を変えてから旧リソースを削除する2段階にすると切り戻しが効きます。

VPCピアリング越しにNAT Gatewayを共用できますか？

VPCピアリング経由でNAT Gatewayへトラフィックをルーティングすることはできません。公式には「クライアントからピアリング、NAT、インターネット」という経路は非サポートで、逆に「クライアントからNAT、ピアリング、宛先」はサポートされると整理されています。後者では、宛先VPC側に戻りルートが無くても発信元のNAT Gatewayへ返る挙動があるため、遮断したい場合はネットワークACLで戻りを止めます。

NAT Gatewayが作成に失敗してFailedになる原因は何ですか？

公式が挙げる原因は3つです。サブネットに空きプライベートIPが無い、VPCにインターネットゲートウェイが付いていない、指定したElastic IPが他のリソースに関連付け済み。いずれもVPCコンソールのNAT Gateway詳細タブに表示されるState messageで判別できます。Failed状態のNAT Gatewayは約1時間で自動削除されるため、メッセージは早めに控えてください。