リージョナルNAT GatewayがAWSマネジメントコンソールから操作できるようになったのでIPAMとの連携をしてみた

リージョナルNAT Gatewayの自動割り当て機能を使いつつ、割り当てられるIPアドレス範囲を固定化したい際にはIPAMを使用しよう
2025.11.21
 リージョナルNAT Gatewayをマネジメントコンソールで操作したいこんにちは、のんピ(@non____97)です。
皆さんリージョナルNAT Gatewayをマネジメントコンソールで操作したいなと思ったことはありますか? 私はあります。
先日、リージョナルNAT GatewayがGAされました。
https://dev.classmethod.jp/articles/aws-nat-gateway-regional-availability/
ただし、GAされたタイミングではAWS CLIやAWS SDKのみでしか操作できず、AWSマネジメントコンソール上では操作はできませんでした。
「まだまだAWSマネジメントコンソールから操作できるようになるのには時間がかかるのかな」
と思っていると、GAされた翌日投稿されたAWS Blogsの記事にAWSマネジメントコンソールからリージョナルNAT Gatewayを操作している画面キャプチャがあるではないですか。
https://aws.amazon.com/jp/blogs/networking-and-content-delivery/introducing-amazon-vpc-regional-nat-gateway/
これは嬉しいですね。
ただ、リージョナルNAT GatewayをAWSマネジメントコンソールから操作するだけは面白くありません。
以下記事で紹介されているようにリージョナルNAT GatewayとIPAMを連携させて、リージョナルNAT Gatewayに割り当てられるElastic IPアドレスを指定した範囲に絞り込んでみます。
https://aws.amazon.com/jp/blogs/networking-and-content-delivery/build-scalable-ipv4-addressing-with-aws-nat-gateway-in-regional-availability-mode-amazon-vpc-ipam-policies-and-prefix-lists/
「外部連携先のAllow Listがあり、割り当てられるIPアドレス範囲を固定化したい。リージョナルNAT Gatewayの自動割り当て機能も使いたい。」という場合に刺さるでしょう。
以降紹介します。
 いきなりまとめリージョナルNAT Gatewayがマネジメントコンソールから操作できるようになった
AWS CLI v2でも操作可能になった

リージョナルNAT Gatewayの自動割り当て機能を使いつつ、割り当てられるIPアドレス範囲を固定化したい際にはIPAMを使用しよう
IPAMポリシーを用いることで、指定したリージョンのリージョナルNAT Gatewayへ強制的にIPAMプールのCIDRブロック内のIPアドレスを割り当てることが可能

アベイラビリティモードが自動割り当てのリージョナルNAT Gatewayを削除すると、Elastic IPアドレスが自動で解放される
 やってみた 検証環境検証環境は以下のとおりです。
先日投稿したリージョナルNAT GatewayのGA記事のものをそのまま使用します。
 現在のIPAMの確認まず、現在のIPAMの確認をします。
私の環境ではパブリックとプライベートの2種類のIPAMスコープを作成しています。
パブリックスコープダッシュボードは以下のとおりです。
既存のリージョナルNAT Gatewayが存在しており、Elastic IPアドレスを1つ関連づけているため、リソースCIDRタイプでEIPが1と表現されていますね。
プライベートスコープダッシュボードは以下のとおりです。
CIDRブロックを持っているリソース数や重複しているCIDR数が分かりますね。
Public IP Insightsは以下のとおりです。
先述の通り、既存のリージョナルNAT Gatewayが存在しており、Elastic IPアドレスを1つ関連づけています。このIPアドレスの扱いとしてはサービスマネージドIPであり、Amazon所有EIPとは別物のようです。
そのため、EIP使用状況のグラフのメトリクスは現在いずれも0を指しています。
 IPAMプールの作成それでは、IPAMプールを作成して、リージョナルNAT Gatewayに割り当てたいElastic IPアドレスのCIDRブロックを設定します。
パブリックスコープを選択してプールを作成をクリックします。
プール階層を選択します。
今回は上位のIPAMプールは存在しないため、ソースはIPAMスコープになります。
また、us-east-1のリージョナルNAT Gatewayに割り当てたいため、ロケールはus-east-1で、サービスEC2 (EIP/VPC)としました。
パブリックIPソースAmazon 所有としていますが、BYOIPもできるので、オンプレで使用していたIPアドレスを引き続き使用したい場合も問題ありません。
プロビジョニングするCIDRブロックのサブネットマスクは/29としました。EIPをどの程度スケールさせたいかでサブネットマスクの値は調整すると良いでしょう。
プールを作成をクリックすると、CIDRのプロビジョニングが開始されます。
現在は保留中のプロビジョンとなっています。
1分ほど待つとプロビジョン済みとして3.41.135.112/29が割り当てられました。
割り当てられたCIDRブロックはプールの詳細タブからも確認できます。利用可能なIPが8となっていますね。
ちなみに、このタイミングでElastic IPアドレスをマネジメントコンソールから割り当てようとすると、作成したIPAMプールを指定できるようになっていました。
 IPAMポリシーの作成続いて、リージョナルNAT GatewayとIPAMプールを関連づけるため、IPAMポリシーを作成します。
IPAMポリシーは指定したリソースタイプを使用する際に、強制的にIPAMプールからIPアドレスを割り当てる機能です。
https://aws.amazon.com/about-aws/whats-new/2025/11/amazon-vpc-ipam-policies-ip-allocation-strategy/
IPAMポリシーが適用されたアカウントでパブリックIPアドレスを必要とするAWSリソースを作成する場合は以下のような挙動で割り当てを行います。
IPAMがポリシールールを順番にチェックする
ルールがリソースタイプと一致する場合、IPAMが指定されたプールからIPアドレスを割り当てる
プールが空でオーバーフローが有効になっている場合、Amazon所有のIPアドレスを割り当てる
一致するルールがない場合は、デフォルトの動作が適用される
参考 : Define public IPv4 allocation strategy with IPAM policies - Amazon Virtual Private Cloud
実際に試してみましょう。
Create policyをクリックします。
ポリシー名と関連付けたいIPAM IDを選択して、Create policyをクリックします。
IPAMポリシーの作成が完了しました。
割り当てルールを作成します。Create allocation rulesをクリックします。
割り当て対象のリソースが存在するリージョンとリソースタイプ、IPAMプールを選択してCreate allocation rulesをクリックします。
ちなみにリソースタイプは現状以下2種類をサポートしています。
EIP
リージョナルNAT Gateway
割り当てルールの作成が完了しました。
これでリージョナルNAT Gatewayを自動割り当て = Elastic IPアドレスを明示的に指定せずに作成してもIPAMプールからIPアドレスを割り当ててくれるようになります。
 リージョナルNAT Gatewayの作成リージョナルNAT Gatewayを作成しましょう。
アベイラビリティモードでリージョナル、Elastic IP割り当て方法で自動を選択してリージョナルNAT Gatewayを作成します。
ちなみにマニュアルを選択した場合は各AZごとにElastic IPアドレスを選択できるようになります。
リージョナルNAT Gatewayの作成が開始されました。
今までAWSマネジメントコンソール上で確認できなかったアベイラビリティモードやEIP割り当ての方法が確認できるようになりました。
IPアドレスタブでのリロードボタンを押して待っていると、関連付けが始まりました。
リージョナルNAT Gatewayの作成を開始をして2分ほどで1つ目のElastic IPアドレスの割り当てが完了しました。3.41.135.112はIPAMプールの3.41.135.112/29内のIPアドレスですね。
さらに数十秒後、もう一つのElastic IPアドレスの割り当ても完了しました。こちらもIPAMプールのCIDRブロック内のものです。
割り当てられたElastic IPアドレスを確認すると、アドレスプールがIPAMプールのIDとなっていました。
IPAMコンソールからIPAMプールを確認すると、リソースに割り当て済みのIPアドレスが全体の25%を占めていることが分かります。
また、リソースを確認すると、IPv4の世界でIPAMプールや既に割り当てられているIPアドレスをグラフィカルに表示できるようになっていました。


現在のPublic IP Insightsは以下のとおりです。サービスマネージドIPが1つから3つになっていますね。


 us-east-1cにEC2インスタンスを追加した場合の挙動の確認このまま終わるのも面白くないので、us-east-1cにEC2インスタンスを追加した場合の挙動の確認もしてみます。
14:17:47にEC2インスタンスを起動しました。
起動したEC2インスタンスで、以下のようにcheckip.amazonaws.comに1秒間隔でアクセスしてインターネットに出る際に使用しているIPアドレスを確認します。
$ while true; do 
  echo "$(date '+%Y/%m/%d %H:%M:%S') - $(curl -s --no-keepalive http://checkip.amazonaws.com)"
  sleep 1
done
2025/11/21 05:33:02 - 3.41.135.112
2025/11/21 05:33:03 - 3.41.135.112
2025/11/21 05:33:04 - 3.41.135.112
2025/11/21 05:33:05 - 3.41.135.112
.
.
(以下略)
.
.
ひたすらにus-east-1bに関連づけられている3.41.135.112へ通信をしています。
また、リージョナルNAT Gatewayの状態も30秒ごとに確認します。
> while true; do
  echo "-----"
  date '+%Y/%m/%d %H:%M:%S'
  aws ec2 describe-nat-gateways \
    --nat-gateway-ids nat-13f42e2ece2fee424 \
    --query '{NatGatewayAddresses : NatGateways[].NatGatewayAddresses[]}'
  sleep 30
done
18分ほどすると、us-east-1cへの割り当てが開始され始めました。
.
.
(中略)
.
.
-----
2025/11/21 14:35:08
{
    "NatGatewayAddresses": [
        {
            "AllocationId": "eipalloc-04c883b9df657294a",
            "PublicIp": "3.41.135.112",
            "AssociationId": "eipassoc-0333269b38fa14402",
            "Status": "succeeded",
            "AvailabilityZone": "us-east-1b",
            "AvailabilityZoneId": "use1-az1"
        },
        {
            "AllocationId": "eipalloc-0703e7cb9884cce49",
            "PublicIp": "3.41.135.113",
            "AssociationId": "eipassoc-0176000ff3dbda634",
            "Status": "succeeded",
            "AvailabilityZone": "us-east-1a",
            "AvailabilityZoneId": "use1-az6"
        }
    ]
}
-----
2025/11/21 14:35:42
{
    "NatGatewayAddresses": [
        {
            "AllocationId": "eipalloc-04c883b9df657294a",
            "PublicIp": "3.41.135.112",
            "AssociationId": "eipassoc-0333269b38fa14402",
            "Status": "succeeded",
            "AvailabilityZone": "us-east-1b",
            "AvailabilityZoneId": "use1-az1"
        },
        {
            "AllocationId": "eipalloc-0703e7cb9884cce49",
            "PublicIp": "3.41.135.113",
            "AssociationId": "eipassoc-0176000ff3dbda634",
            "Status": "succeeded",
            "AvailabilityZone": "us-east-1a",
            "AvailabilityZoneId": "use1-az6"
        },
        {
            "Status": "associating",
            "AvailabilityZone": "us-east-1c",
            "AvailabilityZoneId": "use1-az2"
        }
    ]
}
.
.
(中略)
.
.
このタイミングでEIPは生えてきていました。
なお、このElastic IPアドレスの割り当て先ENIの所有者は自AWSアカウントのものではないようです。AWSマネージドのVPCの世界なのでしょう。
割り当て開始から5分後、割り当てが完了しました。
.
.
(中略)
.
.
-----
2025/11/21 14:40:57
{
    "NatGatewayAddresses": [
        {
            "AllocationId": "eipalloc-04c883b9df657294a",
            "PublicIp": "3.41.135.112",
            "AssociationId": "eipassoc-0333269b38fa14402",
            "Status": "succeeded",
            "AvailabilityZone": "us-east-1b",
            "AvailabilityZoneId": "use1-az1"
        },
        {
            "AllocationId": "eipalloc-0703e7cb9884cce49",
            "PublicIp": "3.41.135.113",
            "AssociationId": "eipassoc-0176000ff3dbda634",
            "Status": "succeeded",
            "AvailabilityZone": "us-east-1a",
            "AvailabilityZoneId": "use1-az6"
        },
        {
            "Status": "associating",
            "AvailabilityZone": "us-east-1c",
            "AvailabilityZoneId": "use1-az2"
        }
    ]
}
-----
2025/11/21 14:41:31
{
    "NatGatewayAddresses": [
        {
            "AllocationId": "eipalloc-04c883b9df657294a",
            "PublicIp": "3.41.135.112",
            "AssociationId": "eipassoc-0333269b38fa14402",
            "Status": "succeeded",
            "AvailabilityZone": "us-east-1b",
            "AvailabilityZoneId": "use1-az1"
        },
        {
            "AllocationId": "eipalloc-0703e7cb9884cce49",
            "PublicIp": "3.41.135.113",
            "AssociationId": "eipassoc-0176000ff3dbda634",
            "Status": "succeeded",
            "AvailabilityZone": "us-east-1a",
            "AvailabilityZoneId": "use1-az6"
        },
        {
            "AllocationId": "eipalloc-01b17c5df8153726b",
            "PublicIp": "3.41.135.114",
            "AssociationId": "eipassoc-0a6f0af2b5967a643",
            "Status": "succeeded",
            "AvailabilityZone": "us-east-1c",
            "AvailabilityZoneId": "use1-az2"
        }
    ]
}
割り当て済みのものから連番で3.41.135.114が割り当てられていますね。
curlの実行状況を確認すると、us-east-1cの割り当てが完了したタイミングで即座にus-east-1cに割り当てられたElasitc IPアドレスを用いて通信するようになっていました。
.
.
(中略)
.
.
2025/11/21 05:41:28 - 3.41.135.112
2025/11/21 05:41:29 - 3.41.135.112
2025/11/21 05:41:30 - 3.41.135.112
2025/11/21 05:41:31 - 3.41.135.112
2025/11/21 05:41:32 - 3.41.135.112
2025/11/21 05:41:33 - 3.41.135.112
2025/11/21 05:41:34 - 3.41.135.114
2025/11/21 05:41:35 - 3.41.135.114
2025/11/21 05:41:36 - 3.41.135.114
2025/11/21 05:41:37 - 3.41.135.114
2025/11/21 05:41:38 - 3.41.135.114
良い感じですね。
IPAMプールを確認すると、先ほどよりもリソースに割り当て済みのIPアドレス数が増加したことが分かります。
リソースからも追加で割り当てられたElastic IPアドレスを確認できました。
今までの検証を整理すると以下のとおりです。
なお、リージョナルNAT Gatewayを削除すると、自動でElastic IPアドレスも解放されました。




 リージョナルNAT Gatewayの自動割り当て機能を使いつつ、割り当てられるIPアドレス範囲を固定化したい際にはIPAMを使用しようリージョナルNAT GatewayとIPAMの連携を試してみました。
リージョナルNAT Gatewayの自動割り当て機能を使いつつ、割り当てられるIPアドレス範囲を固定化したい際にはIPAMを使用しましょう。
この記事が誰かの助けになれば幸いです。
以上、クラウド事業本部 コンサルティング部の のんピ(@non____97)でした!