[アップデート]ALBのパブリックIPにIPAMプールで管理するIPを割り当てられるようになりました

お疲れさまです。とーちです。

AWS Application Load Balancer (ALB) に新しいアップデートが入り、ALBのパブリックIPアドレスをVPC IPAMプールから割り当てられるようになりました。今回はこの新機能を実際に試してみた内容を紹介します。

とりあえずまとめ

• ALBのパブリックIPアドレスにIPAMプールで管理するIPを割り当てられるようになりました
• 自社所有のIPアドレス(BYOIP)またはAmazonが提供する連続したIPv4アドレスブロックのいずれかを使用可能です
• 特定のCIDR範囲内からALBにIPアドレスを割り当てられるので、企業などでインターネット接続IPを制限しているケースで特に有効です
• IPAMプールのIPが枯渇した場合は、自動的にIPAMプール管理外のAWS管理のIPアドレスに切り替わります

そもそもIPAMってなに？

Amazon VPC IP Address Manager (IPAM) は、AWSクラウド内でIPアドレスを効率的に管理するためのサービスです。組織で使用するIPアドレスを管理・追跡・監視するための一元管理ツールになっています。

主要な概念

1. IPAM（IP Address Manager）

• IPアドレス管理のための基本システム
• 特定のAWSリージョンに作成します
• 作成時に自動的に2つのスコープが生成されます

2. スコープ（Scope）

• IPAMの最上位区分となる仕切り
• IPアドレス空間を大きく分類する役割があります
• 以下2種類のスコープが自動で作成されます
  • プライベートスコープ: 社内ネットワークで使用するIPアドレス用
  • パブリックスコープ: インターネットに公開可能なIPアドレス用
• 異なるスコープを使うことで、複数のネットワーク間でIPアドレスを重複させずに管理できます

3. プール（Pool）

• 連続したIPアドレス範囲をまとめた管理単位
• 用途に応じて整理できる「IPアドレスの入れ物」
• 階層構造を作れるので、組織構造に合わせた管理が可能です。例えば以下のような階層構造を作れます
  1. トップレベルのプール（全社共通のIPアドレス空間）
  2. リージョン別のサブプール（東京リージョン、シンガポールリージョンなど）
  3. 環境別のサブプール（各リージョン内で開発環境、テスト環境、本番環境など）

4. 割り当て（Allocation）

• プールから実際のAWSリソースにIPアドレスを割り当てること
• 例：VPC作成時にIPAMプールから特定のCIDRを割り当てる
• 割り当て状況を一元的に監視・管理できます

ALBにIPAMプールを割り当ててみる

IPAMについてざっと理解できたところで、早速ALBにIPAMプールを割り当ててみます。

BYOIPは持っていないので、Amazonが提供するIPv4アドレスブロックをALBに割り当ててみました。

IPAM関連リソースの作成

IPAM関連リソースの作成はマネージメントコンソールのVPCの画面から以下をクリックすることで遷移できます。

まだ作成していない場合は、最上位の概念であるIPAMから作成してください。私は以前、パブリックIPv4インサイトのためにIPAMを作っていたようなのでこれをそのまま使います（なお、IPAMはリージョンごとに一つまでしか作成できません※参考）。

IPAMの作成については以下の記事をご参照ください。

https://dev.classmethod.jp/articles/ipam-ipv4-insight/

なお今回使用するIPAMは以下のような設定です。無料利用枠のIPAMで設定していきます。

IPAMプールの作成

プールは以下から作れます。

プールを作成するIPAMスコープはパブリックを選択します。

ロケールにはIPAMプール内のIPアドレスを利用できるリージョンを選択します。サービスはEC2（EIP/VPC）のみ選択可能なのでこれを指定。パブリックIPソースは今回はAmazon所有のものを使うので、そのように設定しました。

プロビジョニングするCIDRとして/28を指定します。ALBのパブリックIPとして最低いくつ必要かを示すドキュメントがパッと見つからなかった（プライベートIPは各AZごとに８つ）のでとりあえず 16IP確保できるCIDR にしました。なお、ネットワークアドレス（例：18.177.123.0など）を指定して作成することはできません。Amazon所有のIPアドレス範囲から自動的に割り当てられる形です。

ここまで設定したらプールの作成ボタンを押してIPAMプールを作成します。

プールの作成をしたらCIDRタブから割り当てられたパブリックIPのCIDRが確認できます。CIDRのプロビジョンが失敗しちゃってますね。どうやらドキュメントを見るとデフォルトでは/29 or /30しか設定できないようです。なおサポートに申請すれば増加は可能なようです。

改めて/30でCIDRのプロビジョニングをしてみます。

今度はちゃんと割り当てられました。

「IP空間の可視化」タブから未割り当てのIP数も確認できます。

なお、18.99.69.240/30の場合、IPアドレス範囲は18.99.69.240 〜 18.99.69.243となります。

ALBの作成

プールができたので早速ALBを作ってみましょう。マネージメントコンソールでEC2の画面に移動してALBを作成していきます。

スキームはインターネット向け、ロードバランサーのIPアドレスタイプにはIPv4かDualstackを選びます。それ以外の設定は今回のIPAM統合のアップデートではサポートされていません。

注目すべきはネットワークマッピングの設定です。ここに新たに Use IPAM pool for public IPv4 addressesというチェックボックスが追加されています。ここにチェックをつけるとIPAMプールを選択するリストが出てくるので先ほど作成したIPAMプールを指定します。

ALBの配置をするサブネットをパブリックサブネットに指定し、その他の設定はデフォルトのままALBを作成します。

ALBが正常に作成されました！さっそくALBのパブリックIPを確認してみます。

digコマンドでALBに付与されたDNS名の名前解決をします。

18.99.69.240/30の場合、IPアドレス範囲は18.99.69.240 〜 18.99.69.243でした、果たしてALBのパブリックIPはどのようになっているでしょうか？

> dig alb-ipam-update-1101690900.ap-northeast-1.elb.amazonaws.com

; <<>> DiG 9.10.6 <<>> alb-ipam-update-1101690900.ap-northeast-1.elb.amazonaws.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 2992
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;alb-ipam-update-1101690900.ap-northeast-1.elb.amazonaws.com. IN        A

;; ANSWER SECTION:
alb-ipam-update-1101690900.ap-northeast-1.elb.amazonaws.com. 60 IN A 18.99.69.243
alb-ipam-update-1101690900.ap-northeast-1.elb.amazonaws.com. 60 IN A 18.99.69.240

;; Query time: 20 msec
;; SERVER: 2404:1a8:7f01:b::3#53(2404:1a8:7f01:b::3)
;; WHEN: Mon Mar 10 07:13:12 JST 2025
;; MSG SIZE  rcvd: 120

上記の通り、18.99.69.243と18.99.69.240と見事にIPAMプールのCIDR内でIPが割り振られていますね。

IPAMプール枯渇時の挙動を確認

IPAMプール枯渇時にどうなるかが気になったので、複数のALBを同一のIPAMプールで作成してみました。

すると以下のような結果でした。

alb-ipam-update2：18.99.69.241なのでIPAMプールからの割当て

> dig alb-ipam-update2-1578504068.ap-northeast-1.elb.amazonaws.com

; <<>> DiG 9.10.6 <<>> alb-ipam-update2-1578504068.ap-northeast-1.elb.amazonaws.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6474
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;alb-ipam-update2-1578504068.ap-northeast-1.elb.amazonaws.com. IN A

;; ANSWER SECTION:
alb-ipam-update2-1578504068.ap-northeast-1.elb.amazonaws.com. 60 IN A 18.99.69.241

;; Query time: 23 msec
;; SERVER: 2404:1a8:7f01:b::3#53(2404:1a8:7f01:b::3)
;; WHEN: Mon Mar 10 07:22:01 JST 2025
;; MSG SIZE  rcvd: 105

alb-ipam-update3：18.99.69.242なのでIPAMプールからの割当て

> dig alb-ipam-update3-36650622.ap-northeast-1.elb.amazonaws.com

; <<>> DiG 9.10.6 <<>> alb-ipam-update3-36650622.ap-northeast-1.elb.amazonaws.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22205
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;alb-ipam-update3-36650622.ap-northeast-1.elb.amazonaws.com. IN A

;; ANSWER SECTION:
alb-ipam-update3-36650622.ap-northeast-1.elb.amazonaws.com. 60 IN A 18.99.69.242

;; Query time: 23 msec
;; SERVER: 2404:1a8:7f01:b::3#53(2404:1a8:7f01:b::3)
;; WHEN: Mon Mar 10 07:22:08 JST 2025
;; MSG SIZE  rcvd: 103

alb-ipam-update4：18.177.123.115なのでAWS管理IPからの割当て

> dig alb-ipam-update4-207935954.ap-northeast-1.elb.amazonaws.com

; <<>> DiG 9.10.6 <<>> alb-ipam-update4-207935954.ap-northeast-1.elb.amazonaws.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26422
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;alb-ipam-update4-207935954.ap-northeast-1.elb.amazonaws.com. IN        A

;; ANSWER SECTION:
alb-ipam-update4-207935954.ap-northeast-1.elb.amazonaws.com. 60 IN A 18.177.123.115

;; Query time: 335 msec
;; SERVER: 2404:1a8:7f01:b::3#53(2404:1a8:7f01:b::3)
;; WHEN: Mon Mar 10 07:22:14 JST 2025
;; MSG SIZE  rcvd: 104

What's Newにも記載のある通り、IPAMプールのIPが優先的に割当てられるのですが、IPAMプールのIPが枯渇しているときはエラーや警告等は出ずに通常どおり、AWS管理のIPアドレスの中からランダムで割当てられるようですね。

注意点とまとめ

気になるのはALBのパブリックIPが後から増えるケースです。alb-ipam-updateがそうだったのですが、最初は１IPでしたが、何度か試しにアクセスをしていたらパブリックIPが２つに増えていました。ALBが割り当てるパブリックIPはAZごとに1IPだと思いますので、ALBをいくつのAZに配置するかも考えつつ、IPAMプールを割り当てる必要がありそうです。

また、Application Load Balancers公式ドキュメントを見ると以下のような注意事項が記載されていましたので、注意しましょう。

• IPAM IP アドレス プールは、内部ロード バランサー、またはパブリックIPv4 IP アドレス タイプのない Dualstack では使えない
• 別の IPAM IP アドレス プールへの移行中、既存の接続はロード バランサーの HTTP クライアント キープアライブ期間に従って終了

ALBのパブリックIPにIPAMプールで管理するパブリックIPを割り当てられるようになったアップデートでした。このアップデートにより組織からALBへのIP制限がやりやすくなる一方、上記の通り、IPAMプールが枯渇していても正常にALB自体は作成出来てしまうのでIPAMプールのIP在庫を常にチェックする仕組みとセットで運用する必要がありそうに思いました。

以上、とーちでした。