![[アップデート] リージョンレベルでの可用性があるリージョナルNAT Gatewayが利用可能になりました](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-50706ca4b3af64b50895745fa3ba1180/47af3f43efd69adb20976f201c9c3366/amazon-vpc?w=3840&fm=webp)
[アップデート] リージョンレベルでの可用性があるリージョナルNAT Gatewayが利用可能になりました
NAT Gatewayの可用性と切り替えの手間が気になる
こんにちは、のんピ(@non____97)です。
皆さんはNAT Gatewayの可用性と切り替えの手間が気になったことはありますか? 私はあります。
NAT GatewayはAZレベル = Zonalなサービスです。そのため、AZレベルの障害が発生した場合はNAT Gatewayへルーティングしていたリソースは通信ができなくなります。
そちらの対応としてNAT GatewayをMulti-AZ構成にすることがありますが、各AZ間のNAT Gatewayの振り分けが課題となります。
NAT Gatewayにルーティングする前段にNLBを挟んだとしても通信はできません。
また、NLBとNAT Gatewayとの間にSquidのようなプロキシサーバーを挟み、クロスリージョン負荷分散を行うことで、利用するNAT Gatewayへの負荷分散は行うことは可能です。ただし、プロキシサーバーから外部ネットワークへの通信経路のヘルスチェックが正常に行われなければなりません。
無理やり対応するとするならば、プロキシサーバーのcronやsytemd-timerで、いくつか信頼できるIPアドレスに対してpingをうち、いずれのIPアドレスからも応答がない場合は、プロキシのプロセスやサービスを停止し、NLBのヘルスチェックを失敗させるなどの手間が必要です。
他にもあるAZのNAT Gatewayが正常に動作していない場合にLambda関数で、正常に動作していないNAT Gatewayを参照しているルートを編集し、生きている方のNAT Gatewayに振り分けるといった対応もあります。ただし、ヘルスチェックのようなNAT Gatewayが正常に動作していないと直接的に判断するメトリクスはありません。PacketsDropCountなどで間接的に判断する必要があります。
このようにNAT Gatewayのリージョンレベルでの冗長化は人類の夢でした。
それが今回アップデートによりリージョンレベルでのNAT Gatewayを作成できるようになりました。
ありがとうございます。ありがとうございます。ありがとうございます。ありがとうございます。ありがとうございます。
AWS Blogsにも投稿されていますね。
このリージョナルNAT Gatewayですが、リージョンレベルでの冗長性があるだけではなく、他にも機能追加がなされています。
以降紹介します。
いきなりまとめ
- リージョンレベルでの可用性があるリージョナルNAT Gatewayが使用できるようになった
- リージョナルNAT GatewayはプライベートNAT Gateway用途以外の全てのユースケースで推奨される
- パブリックサブネットなしで動作可能
- 作成してもENIは生えてこない
- AZごとにElastic IPアドレスが関連付けられる
- 要Internet Gateway
- リージョナルNAT Gateway作成の裏側でエッジルートテーブルが作成され、デフォルトゲートウェイとして設定されるため
- 作成してもENIは生えてこない
- NAT GatewayのElastic IPアドレスとAZの自動関連付け機能により、AZ上にあるENIに応じて自動で関連付けおよび解除が行われる
- 検証で計測したところ関連付けは10分-15分ほど、解除は60分ほど
- リージョナルNAT Gateway作成後の本機能の有効/無効の切り替えは不可
- 自動割り当てで作成してから、手動割り当てを行うことはできない
- 固定IPの要件があるのであれば手動割り当てが望ましい
- NAT Gatewayで扱うIPアドレスの自動拡張機能により、同時接続数に応じて割り当てられるIPアドレス数が増加
- 最大32個
- Zonal NAT Gatewayの場合は8つ
- リージョナルNAT Gateway作成後の本機能の有効/無効の切り替えは不可
- AZを跨いだ負荷分散は行われない
- AZでアフィニティがある
- ただし、送信元リソースのAZにElastic IPアドレスが関連付けられていない場合は、リージョナルNAT GatewayのいずれかのElastic IPアドレスが使用される
- データ転送量およびAZあたりの料金はZonal NAT Gatewayと同等
- リージョナルNAT GatewayのElastic IPアドレスが関連付くAZごとに料金が発生
- Zonal NAT GatewayとリージョナルNAT Gateway間での切り替え時にはダウンタイムが発生する
- 検証した限り、2025/11/20現在ではリージョナルNAT GatewayをEgress VPCで動作させ、インターネットへのアウトバウンド通信の集約に利用することはできないように見える
- リージョナルNAT Gatewayのエッジルートテーブルにルートを追加することができず、戻りの通信をTransit Gatewayにルーティングできないため
ドキュメントから仕様の確認
概要
ドキュメントから仕様の確認をします。
参考になるドキュメントは以下です。
リージョナルNAT Gatewayはその名の通り、リージョンレベルで動作するNAT Gatewayです。そのため、VPC内の一部AZで障害が発生したとしても業務を継続することが可能です。
図示すると以下のようになります。
抜粋 : Regional NAT gateways for automatic multi-AZ expansion - Amazon Virtual Private Cloud
この図のとおり、リージョナルNAT GatewayはVPC内に存在していません。後ほど検証しますがVPC内にENIも生えてきません。VPC自体に関連付くような形になっています。ZonalなNAT Gatewayで行っていたように自身で各AZにNAT Gatewayを配置するプロセスは必要ありません。Gateway型のVPCエンドポイントのような形と捉えるとイメージしやすいかもしれません。
ENIが作成されない関係でパブリックサブネットは不要になります。パブリックサブネットをNAT Gatewayのためだけに用意している環境においてはサブネットを削除しても良いでしょう。CloudFrontのVPC Originに似たような嬉しみがありますね。
リージョナルNAT Gatewayにルーティングをする際は従来通りVPCルートテーブルでルートを追加する形で行います。これだけです。
また、嬉しい機能としては以下2点あります。
- NAT GatewayのElastic IPアドレスとAZの自動関連付け
- NAT Gatewayで扱うIPアドレスの自動拡張
NAT GatewayのElastic IPアドレスとAZの自動関連付け
NAT GatewayのElastic IPアドレスとAZの自動関連付けについてです。
先ほど
ZonalなNAT Gatewayで行っていたように自身で各AZにNAT Gatewayを配置するプロセスは必要ありません。
と表現をしましたが、実際は裏側でVPC内の各AZにNAT Gatewayで使用するElastic IPアドレスの割り当てが行われます。
このAZにElastic IPアドレス割り当てのタイミングはリージョナルNAT Gatewayを作成したVPC内のAZに、ENIが作成されたタイミングとなります。
例えば2つのAZを使ってシステムを構築している状態から、3つのAZを使用する状態になったときに自動で追加AZ分のElastic IPアドレスとの関連付けが行われます。
この機能によって今まで発生していた以下作業から解放されます。
- 追加したAZ分のNAT Gatewayの作成
- 追加しいAZを割り当てるサブネットに関連づけるルートテーブルの作成
- 作成したルートテーブルに、追加したAZ分のNAT Gatewayへのルート追加
さらにAZ内で使用しているENIがが全て削除された場合はElastic IPアドレスの解放も行われます。
ドキュメント上の関連する記載は以下のとおりです。
On the other hand, with a regional NAT Gateway, you don't need to create a public subnet to host it. You also don't have to create and delete NAT Gateways and edit your route tables every time your workloads expand to new Availability Zones. Instead, you simply create a NAT Gateway with regional mode, choose your VPC, and it automatically expands and contracts across all AZs based on your workload's presence to offer high availability. As shown in diagram B, you can route traffic from your resources in a private subnet across all AZs to this single regional NAT Gateway ID, or use the same route table across subnets in your AZ to perform network address translation. Once you create your regional NAT Gateway, AWS automatically creates a route table for it, which comes with a pre-configured route to the internet gateway. You can use this route table to add return routes to your middleboxes.
Regional NAT gateways for automatic multi-AZ expansion - Amazon Virtual Private Cloud
AutoProvisionZones -> (string)
For regional NAT gateways only: Indicates whether Amazon Web Services automatically manages AZ coverage. When enabled, the NAT gateway associates EIPs in all AZs where your VPC has subnets to handle outbound NAT traffic, expands to new AZs when you create subnets there, and retracts from AZs where you’ve removed all subnets. When disabled, you must manually manage which AZs the NAT gateway supports and their corresponding EIPs.
A regional NAT gateway is a single NAT Gateway that works across multiple availability zones (AZs) in your VPC, providing redundancy, scalability and availability across all the AZs in a Region.
For more information, see Regional NAT gateways for automatic multi-AZ expansion in the Amazon VPC User Guide .
Possible values:
- enabled
- disabled
自動関連付けまでは最大で60分ほどかかるようです。また、拡張完了までは既に関連付けられているElastic IPアドレスを用いて通信を行えるようです。
It may take your regional NAT Gateway up to 60 minutes to expand to a new Availability Zone after a resource is instantiated there. Until this expansion is complete, the relevant traffic from this resource is processed across zones by your regional NAT Gateway in one of the existing Availability Zones.
NAT GatewayのElastic IPアドレスとAZの自動関連付けは強制ではなく、手動で割り当てることも可能です。
--availability-zone-addresses (list)
For regional NAT gateways only: Specifies which Availability Zones you want the NAT gateway to support and the Elastic IP addresses (EIPs) to use in each AZ. The regional NAT gateway uses these EIPs to handle outbound NAT traffic from their respective AZs. If not specified, the NAT gateway will automatically expand to new AZs and associate EIPs upon detection of an elastic network interface. If you specify this parameter, auto-expansion is disabled and you must manually manage AZ coverage.
A regional NAT gateway is a single NAT Gateway that works across multiple availability zones (AZs) in your VPC, providing redundancy, scalability and availability across all the AZs in a Region.
日次などでECS Fargateのタスク実行をしており、インターネットに出る際のグローバルIPアドレスを固定化するためにNAT Gatewayを使用している場合は、手動で割り当てる形が良いでしょう。
NAT Gatewayで扱うIPアドレスの自動拡張
NAT Gatewayを介した同時接続数が多い場合の対策として、NAT Gatewayに複数のIPアドレスを割り当てることが挙げられます。
今までは手動で追加する必要がありましたが、リージョナルNAT Gatewayにおいては同時接続数が増加すると自動でElastic IPアドレスを割り当ててくれます。
AutoScalingIps -> (string)
For regional NAT gateways only: Indicates whether Amazon Web Services automatically allocates additional Elastic IP addresses (EIPs) in an AZ when the NAT gateway needs more ports due to increased concurrent connections to a single destination from that AZ.
For more information, see Regional NAT gateways for automatic multi-AZ expansion in the Amazon VPC User Guide .
Possible values:
- enabled
- disabled
また、Zonal NAT Gatewayの場合は割り当て可能なIPアドレス数は8つまででしたが、リージョナルNAT GatewayはAZごとに32個まで割り当て可能です。Egress VPCなどアウトバウンド通信の出口を集約したい場合はこのぐらいまでスケールすると安心ではないでしょうか。
Higher port and IP limits – Your regional NAT Gateways support up to 32 IP addresses per Availability Zone (compared to 8 for zonal NAT gateways). Each IP address increases the limit on concurrent connections to a popular destination (identified by unique combination of destination IP, destination port and protocol) by 55,000.
Regional NAT gateways for automatic multi-AZ expansion - Amazon Virtual Private Cloud
ただし、以下についてはドキュメントには記載ありませんでした。
- どのタイミングで割り当ててくれるのかという具体的な条件や閾値
- 追加されたElastic IPアドレスの自動解放の有無
- 自動解放される場合は、どのIPアドレスから解放されるのか
- そもそものこの機能の無効化の方法
NAT Gatewayに関連付けたElastic IPアドレスをホワイトリストに登録しているなど、IPアドレスの固定化をしたい場合は注意が必要でしょう。
Zonal NAT Gatewayからの切り替え
Zonal NAT Gatewayからの切り替えは無停止で行うことはできません。
また、ボタンひとつでZonal NAT GatewayからリージョナルNAT Gatewayに変更するというものでもありません。
移行プロセスはZonal NAT Gatewayで使用していたElastic IPアドレスを継続して使用するか否かによって決まります。
- Zonal NAT Gatewayで使用していたElastic IPアドレスを継続して使用する
- リージョナルNAT Gatewayを作成する
- Zonal NAT GatewayのElastic IPアドレスを解放する
- 解放したZonal NAT GatewayのElastic IPアドレスをリージョナルNAT Gatewayに関連付ける
- ルートテーブルを変更して送信先がZonal NAT GatewayとなっているルートをリージョナルNAT Gatewayに変更する
- Zonal NAT Gatewayで使用していたElastic IPアドレスを継続して使用しない
- リージョナルNAT Gatewayを作成する
- ルートテーブルを変更して送信先がZonal NAT GatewayとなっているルートをリージョナルNAT Gatewayに変更する
ダウンタイムは前者の方が長くなります。注意しましょう。
料金
気になる料金です。
料金はリージョナルNAT GatewayのElastic IPアドレスが関連付けられているAZごとに発生します。
Regional NAT Gateway Pricing
If you choose to create a NAT gateway with regional availability in your VPC, you are charged for each hour that the NAT Gateway is configured in each availability zone. For example, if your regional NAT is running across three Availability Zones(AZs) for one hour, you'll be billed for three 'NAT Gateway-hours'. When your regional NAT removes support from an AZ following changes in your workload footprint, billing automatically adjusts - you'll stop incurring charges for that specific AZ. Data processing charges apply for each gigabyte processed through the NAT gateway regardless of the traffic's source or destination. Each partial NAT Gateway-hour consumed is billed as a full hour. You also incur standard AWS data transfer charges for all data transferred via the NAT gateway. If you no longer wish to be charged for a NAT gateway, simply delete your NAT gateway using the AWS Management Console, command line interface, or API.
Regional NAT Gateway Hourly Charge Regional NAT Gateway Data Processing Charge $0.062 $0.062
時間単価およびデータ転送量の単価はいずれもZonal NAT Gatewayと同じでした。
「Multi-AZでNAT Gatewayを動作させている場合において、リージョナルNAT Gatewayに変更したことによってコストが高くつく」ということはなさそうです。
Elastic IPアドレスの手動割り当てをすることも可能なので、リージョナルNAT Gatewayのコストのコントロールをすることも可能です。「Zonal NAT GatewayをSingle-AZでデプロイする」場合と比較してもコスト的には特に気にならないのではないでしょうか。
ただし、手動割り当てを忘れて複数AZにリソースを配置すると、その分追加のNAT Gateway + Elastic IPアドレスのコストがかかってきます。注意しましょう。
注意点
リージョナルNAT GatewayはプライベートNAT Gatewayとして動作はできません。
AWS公式ドキュメントでは、それ以外のケースでは全てのユースケースでリージョナルNAT Gatewayが推奨されるような表現がありました。
When to use regional NAT gateways
Consider using Regional NAT Gateways for all use cases except those that require private connectivity. Regional NAT Gateways do not offer private connectivity and we recommend using your NAT Gateways in zonal availability mode for private NAT use cases.
Regional NAT gateways for automatic multi-AZ expansion - Amazon Virtual Private Cloud
新たなベストプラクティスが発生した音が聞こえました。
やってみた
検証環境
実際に触ってみましょう。
検証環境は以下のとおりです。
以下記事の検証をしたときの居抜きVPCです。Public Subnet達の出番はありません。
リージョナルNAT Gatewayの作成
早速リージョナルNAT Gatewayを作成します。
2025/11/20時点ではAWSマネジメントコンソールからリージョナルNAT Gatewayを作成できません。AWS CLIやAWS SDK、AWS APIなどそれ以外の手法を取る必要があります。
手元の端末で作成しようとしてみます。
> aws ec2 create-nat-gateway \
--availability-mode regional \
--vpc-id vpc-0287f01407d1276f0
aws: [ERROR]: the following arguments are required: --subnet-id
usage: aws [options] <command> <subcommand> [<subcommand> ...] [parameters]
To see help text, you can run:
aws help
aws <command> help
aws <command> <subcommand> help
> aws --version
aws-cli/2.31.39 Python/3.13.9 Darwin/24.6.0 source/arm64
どうやら手元の端末のAWS CLIでまだリージョナルNAT Gatewayの操作に対応をしていませんでした。
AWS CLI v2よりもv1の方が新しい機能への追従が早いので、AWS CLI v1で試します。
AWS CLI v1は以下記事を参考にCloudShell上で実行します。
~ $ python3 -m venv ~/aws-cli-v1
~ $ source ~/aws-cli-v1/bin/activate
(aws-cli-v1) ~ $ pip3 install --upgrade awscli
Collecting awscli
Downloading awscli-1.43.0-py3-none-any.whl (4.6 MB)
.
.
(中略)
.
.
Successfully installed PyYAML-6.0.3 awscli-1.43.0 botocore-1.41.0 colorama-0.4.6 docutils-0.19 jmespath-1.0.1 pyasn1-0.6.1 python-dateutil-2.9.0.post0 rsa-4.7.2 s3transfer-0.14.0 six-1.17.0 urllib3-1.26.20
(aws-cli-v1) ~ $ aws --version
aws-cli/1.43.0 Python/3.9.24 Linux/6.1.156-177.286.amzn2023.x86_64 exec-env/CloudShell botocore/1.41.0
# 以降 `(aws-cli-v1) ~ ` は省略
$ aws ec2 create-nat-gateway \
--availability-mode regional \
--vpc-id vpc-0287f01407d1276f0
{
"ClientToken": "f2145ce0-8b07-4bab-b22e-32c9750cdad1",
"NatGateway": {
"CreateTime": "2025-11-19T23:45:25.000Z",
"NatGatewayAddresses": [],
"NatGatewayId": "nat-136acf3c1acb11690",
"State": "pending",
"VpcId": "vpc-0287f01407d1276f0",
"ConnectivityType": "public",
"AvailabilityMode": "regional",
"AutoScalingIps": "enabled",
"AutoProvisionZones": "enabled"
}
}
作成できましたね。
AWSマネジメントコンソールからもリージョナルNAT Gatewayを確認できました。
数分待つとAvailableになりました。
サブネットの関連付けやENIの作成が行われないので、サブネットやプライマリネットワークインターフェイスIDが-となっています。また、セカンダリIPアドレスの関連付けはできませんでした。
AWS CLIから確認すると以下のとおりです。
$ aws ec2 describe-nat-gateways --nat-gateway-ids nat-136acf3c1acb11690
{
"NatGateways": [
{
"CreateTime": "2025-11-19T23:45:25.000Z",
"NatGatewayAddresses": [
{
"AllocationId": "eipalloc-0a22b07feb2ef491a",
"PublicIp": "18.235.104.107",
"AssociationId": "eipassoc-0e9c7c6995b7429ae",
"Status": "succeeded",
"AvailabilityZone": "us-east-1a",
"AvailabilityZoneId": "use1-az6"
}
],
"NatGatewayId": "nat-136acf3c1acb11690",
"State": "available",
"VpcId": "vpc-0287f01407d1276f0",
"Tags": [],
"ConnectivityType": "public",
"AvailabilityMode": "regional",
"AutoScalingIps": "enabled",
"AutoProvisionZones": "enabled",
"RouteTableId": "rtb-0e9beaa9ae02f158f"
}
]
}
us-east-1に関連付けられていることが分かります。
これはこのVPCのus-east-1のサブネットにEC2 Instance Connect Endpointが存在していたためです。
割り当てられているElastic IPアドレスはAWSマネジメントコンソールからも確認できます。Service managedがrnatとなっていますね。
現在の構成を図示すると以下のとおりです。
リージョナルNAT GatewayのElastic IPアドレスが関連付けられていないAZへのEC2インスタンスの追加
AZへの自動関連付けを体感するためにリージョナルNAT GatewayのElastic IPアドレスが関連付けられていないAZへのEC2インスタンスの追加を行います。
8:56:2にEC2インスタンスをus-east-1bに作成しました。
以降1分ごとにリージョナルNAT Gatewayの状態を確認します。
$ while true; do
date
aws ec2 describe-nat-gateways --nat-gateway-ids nat-136acf3c1acb11690
sleep 60
done
Thu Nov 20 12:02:47 AM UTC 2025
{
"NatGateways": [
{
"CreateTime": "2025-11-19T23:45:25.000Z",
"NatGatewayAddresses": [
{
"AllocationId": "eipalloc-0a22b07feb2ef491a",
"PublicIp": "18.235.104.107",
"AssociationId": "eipassoc-0e9c7c6995b7429ae",
"Status": "succeeded",
"AvailabilityZone": "us-east-1a",
"AvailabilityZoneId": "use1-az6"
}
],
"NatGatewayId": "nat-136acf3c1acb11690",
"State": "available",
"VpcId": "vpc-0287f01407d1276f0",
"Tags": [],
"ConnectivityType": "public",
"AvailabilityMode": "regional",
"AutoScalingIps": "enabled",
"AutoProvisionZones": "enabled",
"RouteTableId": "rtb-0e9beaa9ae02f158f"
}
]
}
.
.
(中略)
.
.
Thu Nov 20 12:04:49 AM UTC 2025
{
"NatGateways": [
{
"CreateTime": "2025-11-19T23:45:25.000Z",
"NatGatewayAddresses": [
{
"AllocationId": "eipalloc-0a22b07feb2ef491a",
"PublicIp": "18.235.104.107",
"AssociationId": "eipassoc-0e9c7c6995b7429ae",
"Status": "succeeded",
"AvailabilityZone": "us-east-1a",
"AvailabilityZoneId": "use1-az6"
},
{
"Status": "associating",
"AvailabilityZone": "us-east-1b",
"AvailabilityZoneId": "use1-az1"
}
],
"NatGatewayId": "nat-136acf3c1acb11690",
"State": "available",
"VpcId": "vpc-0287f01407d1276f0",
"Tags": [],
"ConnectivityType": "public",
"AvailabilityMode": "regional",
"AutoScalingIps": "enabled",
"AutoProvisionZones": "enabled",
"RouteTableId": "rtb-0e9beaa9ae02f158f"
}
]
}
.
.
(中略)
.
.
Thu Nov 20 12:09:52 AM UTC 2025
{
"NatGateways": [
{
"CreateTime": "2025-11-19T23:45:25.000Z",
"NatGatewayAddresses": [
{
"AllocationId": "eipalloc-0a22b07feb2ef491a",
"PublicIp": "18.235.104.107",
"AssociationId": "eipassoc-0e9c7c6995b7429ae",
"Status": "succeeded",
"AvailabilityZone": "us-east-1a",
"AvailabilityZoneId": "use1-az6"
},
{
"AllocationId": "eipalloc-0fb816a1d85ee4478",
"PublicIp": "184.73.77.140",
"AssociationId": "eipassoc-085fce24843eb666d",
"Status": "succeeded",
"AvailabilityZone": "us-east-1b",
"AvailabilityZoneId": "use1-az1"
}
],
"NatGatewayId": "nat-136acf3c1acb11690",
"State": "available",
"VpcId": "vpc-0287f01407d1276f0",
"Tags": [],
"ConnectivityType": "public",
"AvailabilityMode": "regional",
"AutoScalingIps": "enabled",
"AutoProvisionZones": "enabled",
"RouteTableId": "rtb-0e9beaa9ae02f158f"
}
]
}
us-east-1bへの関連付けが行われましたね。
- ENI追加して8分ほどで検出してAZ関連付け開始
- そこからさらに5分ほどでAZ関連付け完了
といった具合ですね。
マネジメントコンソール上でもElastic IPアドレスが追加されていることを確認できます。
現在の構成を図示すると以下のとおりです。
疎通確認
疎通確認をします。
ルートテーブルのルートを変更して、デフォルトゲートウェイがリージョナルNAT Gatewayになるようにします。
ルートテーブルをサブネットに関連付けます。
この状態のVPCのリソースマップは以下のとおりです。現状リージョナルNAT Gatewayは「ネットワーク接続」で表現されていないですね。
us-east-1b上のEC2インスタンスにSSM Session Managerで接続して、どのIPアドレスでインターネットに出ているのか確認をします。
$ TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
$ curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/placement/availability-zone
us-east-1b
$ curl http://checkip.amazonaws.com
184.73.77.140
$ while true; do curl http://checkip.amazonaws.com; done
184.73.77.140
.
.
(中略)
.
.
184.73.77.140
^C
リージョナルNAT Gatewayのus-east-1bへの関連付けをしているElastic IPアドレスである184.73.77.140を使用していることが分かりました。
続いて、us-east-1aにEC2インスタンスを作成し、同様の操作を行います。
$ TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
$ curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/placement/availability-zone
us-east-1a
$ curl http://checkip.amazonaws.com
18.235.104.107
$ while true; do curl http://checkip.amazonaws.com; done
18.235.104.107
.
.
(中略)
.
.
18.235.104.107
^C
us-east-1aに関連付けられている18.235.104.107を使用していることが分かります。
それぞれ何回か時間を置いたりしてみて操作をしましたが、結果は変わりませんでした。送信元のリソースが存在しているAZとリージョナルNAT Gatewayで使用するElastic IPアドレスにはアフィニティがあることが分かります。
続いて、us-east-1cの場合です。
サブネットとEC2インスタンスの作成およびルートテーブルへの関連付けを行います。
EC2インスタンスの作成は9:43:34です。
まだ、us-east-1cへの関連付けは行われていません。
$ while true; do
date
aws ec2 describe-nat-gateways --nat-gateway-ids nat-136acf3c1acb11690
sleep 60
done
Thu Nov 20 12:44:36 AM UTC 2025
{
"NatGateways": [
{
"CreateTime": "2025-11-19T23:45:25.000Z",
"NatGatewayAddresses": [
{
"AllocationId": "eipalloc-0a22b07feb2ef491a",
"PublicIp": "18.235.104.107",
"AssociationId": "eipassoc-0e9c7c6995b7429ae",
"Status": "succeeded",
"AvailabilityZone": "us-east-1a",
"AvailabilityZoneId": "use1-az6"
},
{
"AllocationId": "eipalloc-0fb816a1d85ee4478",
"PublicIp": "184.73.77.140",
"AssociationId": "eipassoc-085fce24843eb666d",
"Status": "succeeded",
"AvailabilityZone": "us-east-1b",
"AvailabilityZoneId": "use1-az1"
}
],
"NatGatewayId": "nat-136acf3c1acb11690",
"State": "available",
"VpcId": "vpc-0287f01407d1276f0",
"Tags": [],
"ConnectivityType": "public",
"AvailabilityMode": "regional",
"AutoScalingIps": "enabled",
"AutoProvisionZones": "enabled",
"RouteTableId": "rtb-0e9beaa9ae02f158f"
}
]
}
先ほど同様の操作を行います。
$ TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
$ curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/placement/availability-zone
us-east-1c
$ curl http://checkip.amazonaws.com
18.235.104.107
$ while true; do curl http://checkip.amazonaws.com; done
18.235.104.107
.
.
(中略)
.
.
18.235.104.107
^C
us-east-1aに関連付けられている18.235.104.107を使用していることが分かります。
時間を置いても結果は変わらず18.235.104.107でした。
EC2インスタンスを作成して10分ほど待つと、associatingに変わりました。
$ while true; do
date
aws ec2 describe-nat-gateways --nat-gateway-ids nat-136acf3c1acb11690
sleep 60
done
.
.
(中略)
.
.
Thu Nov 20 12:53:42 AM UTC 2025
{
"NatGateways": [
{
"CreateTime": "2025-11-19T23:45:25.000Z",
"NatGatewayAddresses": [
{
"AllocationId": "eipalloc-0a22b07feb2ef491a",
"PublicIp": "18.235.104.107",
"AssociationId": "eipassoc-0e9c7c6995b7429ae",
"Status": "succeeded",
"AvailabilityZone": "us-east-1a",
"AvailabilityZoneId": "use1-az6"
},
{
"AllocationId": "eipalloc-0fb816a1d85ee4478",
"PublicIp": "184.73.77.140",
"AssociationId": "eipassoc-085fce24843eb666d",
"Status": "succeeded",
"AvailabilityZone": "us-east-1b",
"AvailabilityZoneId": "use1-az1"
},
{
"Status": "associating",
"AvailabilityZone": "us-east-1c",
"AvailabilityZoneId": "use1-az2"
}
],
"NatGatewayId": "nat-136acf3c1acb11690",
"State": "available",
"VpcId": "vpc-0287f01407d1276f0",
"Tags": [],
"ConnectivityType": "public",
"AvailabilityMode": "regional",
"AutoScalingIps": "enabled",
"AutoProvisionZones": "enabled",
"RouteTableId": "rtb-0e9beaa9ae02f158f"
}
]
}
この状態でhttp://checkip.amazonaws.comにアクセスしても18.235.104.107のままでした。
さらに6分ほど待つとus-east-1cでの関連付けが完了しました。
.
.
(中略)
.
.
Thu Nov 20 12:59:46 AM UTC 2025
{
"NatGateways": [
{
"CreateTime": "2025-11-19T23:45:25.000Z",
"NatGatewayAddresses": [
{
"AllocationId": "eipalloc-0a22b07feb2ef491a",
"PublicIp": "18.235.104.107",
"AssociationId": "eipassoc-0e9c7c6995b7429ae",
"Status": "succeeded",
"AvailabilityZone": "us-east-1a",
"AvailabilityZoneId": "use1-az6"
},
{
"AllocationId": "eipalloc-0fb816a1d85ee4478",
"PublicIp": "184.73.77.140",
"AssociationId": "eipassoc-085fce24843eb666d",
"Status": "succeeded",
"AvailabilityZone": "us-east-1b",
"AvailabilityZoneId": "use1-az1"
},
{
"AllocationId": "eipalloc-09fdf15a4bf8f5a75",
"PublicIp": "3.221.9.11",
"AssociationId": "eipassoc-03e1b66eb8a669df1",
"Status": "succeeded",
"AvailabilityZone": "us-east-1c",
"AvailabilityZoneId": "use1-az2"
}
],
"NatGatewayId": "nat-136acf3c1acb11690",
"State": "available",
"VpcId": "vpc-0287f01407d1276f0",
"Tags": [],
"ConnectivityType": "public",
"AvailabilityMode": "regional",
"AutoScalingIps": "enabled",
"AutoProvisionZones": "enabled",
"RouteTableId": "rtb-0e9beaa9ae02f158f"
}
]
}
この状態で再度http://checkip.amazonaws.comへアクセスします。
$ curl http://checkip.amazonaws.com
3.221.9.11
$ while true; do curl http://checkip.amazonaws.com; done
3.221.9.11
.
.
(中略)
.
.
3.221.9.11
^C
us-east-1cに関連付けられた3.221.9.11を使うようになったことが分かりました。
現在のリソースと疎通確認結果を図示すると以下のようになります。
AZ内の全ENIを削除した場合の挙動
自動割り当て関連の最後の検証として、AZ内の全ENIを削除した場合の挙動を確認します。
10:03:40にus-east-1cのEC2インスタンスを削除しました。
.
.
(中略)
.
.
Thu Nov 20 01:58:12 AM UTC 2025
{
"NatGateways": [
{
"CreateTime": "2025-11-19T23:45:25+00:00",
"NatGatewayAddresses": [
{
"AllocationId": "eipalloc-0a22b07feb2ef491a",
"PublicIp": "18.235.104.107",
"AssociationId": "eipassoc-0e9c7c6995b7429ae",
"Status": "succeeded"
},
{
"AllocationId": "eipalloc-0fb816a1d85ee4478",
"PublicIp": "184.73.77.140",
"AssociationId": "eipassoc-085fce24843eb666d",
"Status": "succeeded"
},
{
"AllocationId": "eipalloc-09fdf15a4bf8f5a75",
"PublicIp": "3.221.9.11",
"AssociationId": "eipassoc-03e1b66eb8a669df1",
"Status": "succeeded"
}
],
"NatGatewayId": "nat-136acf3c1acb11690",
"State": "available",
"VpcId": "vpc-0287f01407d1276f0",
"Tags": [],
"ConnectivityType": "public"
}
]
}
Thu Nov 20 01:59:13 AM UTC 2025
{
"NatGateways": [
{
"CreateTime": "2025-11-19T23:45:25+00:00",
"NatGatewayAddresses": [
{
"AllocationId": "eipalloc-0a22b07feb2ef491a",
"PublicIp": "18.235.104.107",
"AssociationId": "eipassoc-0e9c7c6995b7429ae",
"Status": "succeeded"
},
{
"AllocationId": "eipalloc-0fb816a1d85ee4478",
"PublicIp": "184.73.77.140",
"AssociationId": "eipassoc-085fce24843eb666d",
"Status": "succeeded"
},
{
"AllocationId": "eipalloc-09fdf15a4bf8f5a75",
"PublicIp": "3.221.9.11",
"AssociationId": "eipassoc-03e1b66eb8a669df1",
"Status": "disassociating"
}
],
"NatGatewayId": "nat-136acf3c1acb11690",
"State": "available",
"VpcId": "vpc-0287f01407d1276f0",
"Tags": [],
"ConnectivityType": "public"
}
]
}
.
.
(中略)
.
.
Thu Nov 20 02:06:20 AM UTC 2025
{
"NatGateways": [
{
"CreateTime": "2025-11-19T23:45:25+00:00",
"NatGatewayAddresses": [
{
"AllocationId": "eipalloc-0a22b07feb2ef491a",
"PublicIp": "18.235.104.107",
"AssociationId": "eipassoc-0e9c7c6995b7429ae",
"Status": "succeeded"
},
{
"AllocationId": "eipalloc-0fb816a1d85ee4478",
"PublicIp": "184.73.77.140",
"AssociationId": "eipassoc-085fce24843eb666d",
"Status": "succeeded"
}
],
"NatGatewayId": "nat-136acf3c1acb11690",
"State": "available",
"VpcId": "vpc-0287f01407d1276f0",
"Tags": [],
"ConnectivityType": "public"
}
]
}
- ENI追加して56分ほどで検出してAZ関連付け解除開始
- そこからさらに7分ほどでAZ関連付け解除完了
といった具合でした。数十分レベルではないのでよかったです。
Transit Gatewayを用いたEgress VPCとしての動作
リージョナルNAT GatewayをEgress VPCで動作させてインターネットへのアウトバウンド通信を集約できるか気になってきました。
ということで検証します。
構成図は以下のとおりです。
パブリックサブネットなしでEgress VPCの作成をします。
作成完了しました。Internet Gatewayは関連付けられていません。
リージョナルNAT Gatewayを作成します。
$ aws ec2 create-nat-gateway \
--availability-mode regional \
--vpc-id vpc-0eda45958335d3a92
{
"ClientToken": "1ad2e864-8311-43c4-97dd-8ee4eebd25b1",
"NatGateway": {
"CreateTime": "2025-11-20T03:24:21.000Z",
"NatGatewayAddresses": [],
"NatGatewayId": "nat-12cac8e1ee21c544d",
"State": "pending",
"VpcId": "vpc-0eda45958335d3a92",
"ConnectivityType": "public",
"AvailabilityMode": "regional",
"AutoScalingIps": "enabled",
"AutoProvisionZones": "enabled"
}
}
少し様子を見ると、Internet GatewayがVPCに割り当てられていないと怒られていました。
$ aws ec2 describe-nat-gateways \
--nat-gateway-ids nat-12cac8e1ee21c544d
{
"NatGateways": [
{
"CreateTime": "2025-11-20T03:24:21.000Z",
"FailureCode": "Gateway.NotAttached",
"FailureMessage": "Network vpc-0eda45958335d3a92 has no Internet gateway attached",
"NatGatewayAddresses": [
{
"Status": "associating",
"AvailabilityZone": "us-east-1c",
"AvailabilityZoneId": "use1-az2"
}
],
"NatGatewayId": "nat-12cac8e1ee21c544d",
"State": "failed",
"VpcId": "vpc-0eda45958335d3a92",
"Tags": [],
"ConnectivityType": "public",
"AvailabilityMode": "regional",
"AutoScalingIps": "enabled",
"AutoProvisionZones": "enabled"
}
]
}
AWSマネジメントコンソールからも確認できました。
CloudFrontのVPC Originと同じようにパブリックサブネットは不要であってもInternet Gatewayは必要なようです。
Internet Gatewayを作成し、VPCに割り当てを行います。
割り当て後、しばらく様子を見ましたが、リージョナルNAT Gatewayの状態は変わりませんでした。
もう一度作成しましょう。
$ aws ec2 create-nat-gateway \
--availability-mode regional \
--vpc-id vpc-0eda45958335d3a92
{
"ClientToken": "32f7ef58-bd4f-43d0-bcc7-080ee2fd2a23",
"NatGateway": {
"CreateTime": "2025-11-20T03:34:59.000Z",
"NatGatewayAddresses": [],
"NatGatewayId": "nat-1f41ed76e254eb191",
"State": "pending",
"VpcId": "vpc-0eda45958335d3a92",
"ConnectivityType": "public",
"AvailabilityMode": "regional",
"AutoScalingIps": "enabled",
"AutoProvisionZones": "enabled"
}
}
$ aws ec2 describe-nat-gateways --nat-gateway-ids nat-1f41ed76e254eb191
{
"NatGateways": [
{
"CreateTime": "2025-11-20T03:34:59.000Z",
"NatGatewayAddresses": [
{
"AllocationId": "eipalloc-0cbae8be1c6135c60",
"PublicIp": "54.164.139.220",
"AssociationId": "eipassoc-0b630d9f1f72079d5",
"Status": "succeeded",
"AvailabilityZone": "us-east-1b",
"AvailabilityZoneId": "use1-az1"
}
],
"NatGatewayId": "nat-1f41ed76e254eb191",
"State": "available",
"VpcId": "vpc-0eda45958335d3a92",
"Tags": [],
"ConnectivityType": "public",
"AvailabilityMode": "regional",
"AutoScalingIps": "enabled",
"AutoProvisionZones": "enabled",
"RouteTableId": "rtb-045b599542015ddbf"
}
]
}
作成完了しましたね。
Transit Gatewayやルートテーブルは先述の構成図のとおり設定します。
それでは疎通確認です。
まず、us-east-1aのインスタンスからです。
$ TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
$ curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/placement/availability-zone
us-east-1a
$ curl http://checkip.amazonaws.com -m 5
curl: (28) Connection timed out after 5001 milliseconds
$ curl http://checkip.amazonaws.com -vm 5
* Host checkip.amazonaws.com:80 was resolved.
* IPv6: (none)
* IPv4: 23.20.249.94, 35.170.169.94, 3.222.182.34, 3.86.128.11, 52.3.168.227, 54.83.63.118, 3.217.8.166, 13.216.28.7
* Trying 23.20.249.94:80...
* ipv4 connect timeout after 2499ms, move on!
* Trying 35.170.169.94:80...
.
.
(中略)
.
.
* ipv4 connect timeout after 311ms, move on!
* Trying 52.3.168.227:80...
* Connection timed out after 5000 milliseconds
* closing connection #0
curl: (28) Connection timed out after 5000 milliseconds
おや、疎通できません。Egress VPCのリージョナルNAT Gatewayが関連づけられているElastic IPアドレスがus-east-1bのみだからでしょうか。
では、us-east-1bのEC2インスタンスから疎通確認をします。
$ TOKEN=$(curl -s -X PUT "http://169.254.169.254/latest/api/token" -H "X-aws-ec2-metadata-token-ttl-seconds: 21600")
$ curl -s -H "X-aws-ec2-metadata-token: $TOKEN" http://169.254.169.254/latest/meta-data/placement/availability-zone
us-east-1b
$ curl http://checkip.amazonaws.com -m 5s.com -m 5
curl: (28) Connection timed out after 5001 milliseconds
こちらもです。
VPCルートテーブルやTransit Gatewayルートテーブルを確認しましたが、特に設定漏れはなさそうです。
こんな時に役立つのはReachability Analyzerですよね。送信元をus-east-1aのEC2インスタンス、送信先をcheckip.amazonaws.comのIPアドレスに指定して試します。
はい、2回ほどトライしましたが、いずれもAnalysis failed The request failed due to an internal error. Wait a few minutes and try again.となります。
何か手掛かりはないかとEgress VPCのリソースマップを確認したところ、どのサブネットにも関連づけられていないルートテーブルを発見しました。
こちらのルートテーブルを確認すると、Edgeの関連付けがリージョナルNAT GatewayになっていることからリージョナルNAT Gatewayのエッジルートテーブルであることが分かります。
つまりは、リージョナルNAT Gatewayのルーティングはこちらのルートテーブルで管理されていると言えます。
Edgeの関連付けタブからも何故か×マークが付いており、明らかにエラーの状態のように見えますが、Associatedと関連付けられていることが分かります。
デフォルトゲートウェイがInternet Gatewayとなっていることから、Internet GatewayがVPCに未アタッチの状態でリージョナルNAT Gateway作成時にエラーとなったのは、Internet Gatewayをデフォルトゲートウェイとするルートが設定できなかったためでしょう。
これで「パブリックサブネットは不要だがInternet Gatewayは必要」の意味が分かりましたね。
リージョナルNAT Gatewayのエッジルートテーブルを図に加えると以下のとおりです。かなり解像度が上がってきましたね。
ちなみにこちらのエッジルートテーブルはマネジメントコンソールのルートテーブル一覧に表示されません。
リソースマップから辿るか、AWS CLIで確認しましょう。
> aws ec2 describe-route-tables --route-table-ids rtb-045b599542015ddbf
{
"RouteTables": [
{
"Associations": [
{
"Main": false,
"RouteTableAssociationId": "rtbassoc-045cfb3ed709bf573",
"RouteTableId": "rtb-045b599542015ddbf",
"GatewayId": "nat-1f41ed76e254eb191",
"AssociationState": {
"State": "associated"
}
}
],
"PropagatingVgws": [],
"RouteTableId": "rtb-045b599542015ddbf",
"Routes": [
{
"DestinationCidrBlock": "192.168.0.0/24",
"GatewayId": "local",
"Origin": "CreateRouteTable",
"State": "active"
},
{
"DestinationCidrBlock": "0.0.0.0/0",
"GatewayId": "igw-0ad1ae5e686348693",
"Origin": "CreateRoute",
"State": "active"
}
],
"Tags": [],
"VpcId": "vpc-0eda45958335d3a92",
"OwnerId": "<AWSアカウントID>"
}
]
}
今現在通信できないのはエッジルートテーブルに送信元のVPC CIDR10.0.0.0/16のルートが存在しないためと考えます。こちらのルートが存在しないがために、戻りの通信がTransit Gatewayにルーティングできないのでしょう。
ということで、Transit Gatewayへのルートの追加をしようとしてみます。
はい、Route table is associated with a NAT gateway. The requested route is not supported.となりました。
AWS CLIでも同様の結果になりました。
> aws ec2 create-route \
--route-table-id rtb-045b599542015ddbf \
--destination-cidr-block 10.0.0.0/16 \
--transit-gateway-id tgw-070ff0538aa32b8dd
An error occurred (RouteNotSupported) when calling the CreateRoute operation: Route table is associated with a NAT gateway. The requested route is not supported.
こちらのルート追加の操作は受け付けられないようです。
先述のAWS Blogsに投稿されている記事では以下のように「できる」と紹介されています。
Centralized egress
You can deploy a centralized egress VPC with a NAT gateway in regional availability mode that serves multiple application VPCs. Application VPCs connect to the egress VPC via AWS Transit Gateway or AWS Cloud WAN. Outbound traffic flows through the transit gateway to the egress VPC, where the NAT gateway performs network address translation using Elastic IP addresses from your IPAM pool.
AWSマネジメントコンソールからのリージョナルNAT Gatewayは現在作成できませんし、一時的な不具合なのでしょうか。
念の為問題切り分けのために、Egress VPCのus-east-1aのサブネットにEC2インスタンスを作成し、pingを叩いてみます。
$ ping 192.168.0.135
PING 192.168.0.135 (192.168.0.135) 56(84) bytes of data.
64 bytes from 192.168.0.135: icmp_seq=1 ttl=126 time=3.07 ms
.
.
(中略)
.
.
64 bytes from 192.168.0.135: icmp_seq=7 ttl=126 time=0.927 ms
^C
--- 192.168.0.135 ping statistics ---
7 packets transmitted, 7 received, 0% packet loss, time 6070ms
rtt min/avg/max/mdev = 0.902/1.232/3.067/0.749 ms
正常に通りました。ということはTransit Gatewayを介した通信は問題なく行えていると言えます。
続いて、1.1.1.1へpingを叩きます。
$ ping 1.1.1.1
PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.
^C
--- 1.1.1.1 ping statistics ---
401 packets transmitted, 0 received, 100% packet loss, time 415966ms
はい、通りません。
Transit Gateway Flow Logsを確認すると、1.1.1.1の通信もTransit Gatewayを通っています。
version resource-type account-id tgw-id tgw-attachment-id tgw-src-vpc-account-id tgw-dst-vpc-account-id tgw-src-vpc-id tgw-dst-vpc-id tgw-src-subnet-id tgw-dst-subnet-id tgw-src-eni tgw-dst-eni tgw-src-az-id tgw-dst-az-id tgw-pair-attachment-id srcaddr dstaddr srcport dstport protocol packets bytes start end log-status type packets-lost-no-route packets-lost-blackhole packets-lost-mtu-exceeded packets-lost-ttl-expired tcp-flags region flow-direction pkt-src-aws-service pkt-dst-aws-service
.
.
(中略)
.
.
6 TransitGateway <AWSアカウントID> tgw-070ff0538aa32b8dd tgw-attach-0113cb9bfafdfd8c9 <AWSアカウントID> <AWSアカウントID> vpc-0287f01407d1276f0 vpc-0eda45958335d3a92 subnet-0887c0204936561a6 subnet-0e0268fc8bf2efd62 eni-023c5cbe4fa53efd5 eni-0adcc9dbe6e6c9ca7 use1-az1 use1-az1 tgw-attach-0d5316ed94f6c1bbf 10.0.6.4 1.1.1.1 0 0 1 58 4872 1763613900 1763613959 OK IPv4 0 0 0 0 0 us-east-1 ingress - -
.
.
(中略)
.
.
6 TransitGateway <AWSアカウントID> tgw-070ff0538aa32b8dd tgw-attach-0d5316ed94f6c1bbf <AWSアカウントID> <AWSアカウントID> vpc-0287f01407d1276f0 vpc-0eda45958335d3a92 subnet-0887c0204936561a6 subnet-0e0268fc8bf2efd62 eni-023c5cbe4fa53efd5 eni-0adcc9dbe6e6c9ca7 use1-az1 use1-az1 tgw-attach-0113cb9bfafdfd8c9 10.0.6.4 1.1.1.1 0 0 1 58 4872 1763613900 1763613959 OK IPv4 0 0 0 0 0 us-east-1 egress - -
やはり戻りの通信がTransit Gatewayに到達できないのでしょう。図示すると以下のとおりです。
ちなみに現在のEgress VPCのリージョナルNAT Gatewayはus-east-1cにもElastic IPアドレスの関連付けを完了させています。
$ aws ec2 describe-nat-gateways --nat-gateway-ids nat-1f41ed76e254eb191
{
"NatGateways": [
{
"CreateTime": "2025-11-20T03:34:59.000Z",
"NatGatewayAddresses": [
{
"AllocationId": "eipalloc-0cbae8be1c6135c60",
"PublicIp": "54.164.139.220",
"AssociationId": "eipassoc-0b630d9f1f72079d5",
"Status": "succeeded",
"AvailabilityZone": "us-east-1b",
"AvailabilityZoneId": "use1-az1"
},
{
"AllocationId": "eipalloc-001005b40e742febc",
"PublicIp": "50.16.195.34",
"AssociationId": "eipassoc-06d154874e1aa32bf",
"Status": "succeeded",
"AvailabilityZone": "us-east-1a",
"AvailabilityZoneId": "use1-az6"
}
],
"NatGatewayId": "nat-1f41ed76e254eb191",
"State": "available",
"VpcId": "vpc-0eda45958335d3a92",
"Tags": [],
"ConnectivityType": "public",
"AvailabilityMode": "regional",
"AutoScalingIps": "enabled",
"AutoProvisionZones": "enabled",
"RouteTableId": "rtb-045b599542015ddbf"
}
]
}
Elastic IPアドレスの手動割り当て
$ aws ec2 associate-nat-gateway-address \
--nat-gateway-id nat-136acf3c1acb11690 \
--availability-zone us-east-1c \
--allocation-ids eipalloc-0b0a72a971dd98a90
An error occurred (InvalidParameter) when calling the AssociateNatGatewayAddress operation: AllocationIds cannot be associated to a Regional NAT with AutoScalingIpsEnabled set to true.
どうやらAutoScalingIpsEnabledを無効にする必要があるようです。
では、AutoScalingIpsEnabledをどのようにして無効にすれば良いのでしょうか。
残念ながらAWS CLIのCommand Referenceを確認したところ、既存のリージョナルNAT GatewayのAutoScalingIpsEnabledを変更するコマンドはありませんでした。
要するに、リージョナルNAT Gatewayを作成するタイミングで自動割り当てのみか、手動割り当てのみかが決まるような形になります。
手動割り当てのリージョナルNAT Gatewayを作成します。
$ aws ec2 create-nat-gateway \
--availability-mode regional \
--vpc-id vpc-0287f01407d1276f0 \
--availability-zone-addresses AvailabilityZone=us-east-1b,AllocationIds=eipalloc-0b0a72a971dd98a90
{
"ClientToken": "f4ed0e92-ca97-463c-a7f4-bc9c20c47497",
"NatGateway": {
"CreateTime": "2025-11-20T11:30:41.000Z",
"NatGatewayAddresses": [
{
"AllocationId": "eipalloc-0b0a72a971dd98a90",
"Status": "associating",
"AvailabilityZone": "us-east-1b",
"AvailabilityZoneId": "use1-az1"
}
],
"NatGatewayId": "nat-1f93b2507aa052c3d",
"State": "pending",
"VpcId": "vpc-0287f01407d1276f0",
"ConnectivityType": "public",
"AvailabilityMode": "regional",
"AutoScalingIps": "disabled",
"AutoProvisionZones": "disabled"
}
}
$ aws ec2 describe-nat-gateways --nat-gateway-ids nat-1f93b2507aa052c3d
{
"NatGateways": [
{
"CreateTime": "2025-11-20T11:30:41.000Z",
"NatGatewayAddresses": [
{
"AllocationId": "eipalloc-0b0a72a971dd98a90",
"PublicIp": "3.85.148.229",
"AssociationId": "eipassoc-0ab8153b3baea05cd",
"Status": "succeeded",
"AvailabilityZone": "us-east-1b",
"AvailabilityZoneId": "use1-az1"
}
],
"NatGatewayId": "nat-1f93b2507aa052c3d",
"State": "available",
"VpcId": "vpc-0287f01407d1276f0",
"Tags": [],
"ConnectivityType": "public",
"AvailabilityMode": "regional",
"AutoScalingIps": "disabled",
"AutoProvisionZones": "disabled",
"RouteTableId": "rtb-0d40732f8616b6ddf"
}
]
}
作成完了しました。NatGateways[0].NatGatewayAddresses.Statusがsucceededになるまでの時間は数秒ほどでした。流石に早いです。また、リージョナルNAT Gateway作成時に--availability-zone-addressesを指定しなかった場合と比べてAutoProvisionZonesとAutoScalingIpsがfalseになっていることが分かります。
この後、us-east-1aおよびus-east-1bからhttp://checkip.amazonaws.comにアクセスをし、3.85.148.229が返ってくることを確認しました。
NAT Gatewayのベストプラクティスが変わった
リージョンレベルでの可用性があるリージョナルNAT Gatewayが使用できるようになったアップデートを紹介しました。
NAT Gatewayのベストプラクティスが変わりましたね。
個人的に可用性が重要視される本番環境においては、動作に不安があるEgress VPC用途以外はリージョナルNAT Gatewayを使おうと思います。
この記事が誰かの助けになれば幸いです。
以上、クラウド事業本部 コンサルティング部の のんピ(@non____97)でした!
