Amazon VPC IP Address Manager (IPAM)

Amazon VPC IP Address Manager (IPAM) は、AWS 上で使う IP アドレス空間を組織横断で計画・割り当て・追跡・監視するためのマネージドサービスです。スプレッドシートや手作業で CIDR を管理する代わりに、階層化したプールから自動で割り当て、重複や枯渇を未然に防ぎます。

解決する課題

組織が AWS の利用を広げていくと、複数のアカウントやリージョンに数多くの VPC が増えていきます。従来は IP アドレスの割り当てをスプレッドシートやチーム間の調整で管理することが多く、次のような課題が生じがちでした。

• どの CIDR をどこで使っているか把握しきれず、別々のチームが同じ範囲を割り当ててしまう。後から VPC ピアリングや Transit Gateway でつなごうとすると、CIDR の重複が原因で接続できない。
• 大きすぎる範囲を割り当てて IP を浪費したり、逆に小さすぎて後から枯渇したりする。割り当てサイズの方針が属人的になる。
• 使用率の可視化が難しく、枯渇が近いことに気づくのが遅れる。手作業の台帳は実態とずれていく。
• マルチアカウント・マルチリージョンに広がると、横断的に整合の取れた IP 計画を維持する運用負荷が大きい。

IPAM は、IP アドレス空間を中央のプールとして定義し、そこから各アカウント・リージョン・VPC へ階層的に払い出す仕組みで、これらを解決します。割り当てが自動化され、重複が排除され、使用状況が継続的に可視化されます。

主要概念と用語

• IPAM: 組織の IP アドレスを管理する基盤となるリソース本体。通常は AWS Organizations の委任管理アカウントに 1 つ作成し、運用リージョン（ホームリージョン）を持つ。
• スコープ: IP アドレス空間の独立した管理単位。重複しない範囲を扱うパブリックスコープとプライベートスコープが既定で用意される。プライベートスコープを追加して、相互に重複してよい別系統の空間を分けて管理することもできる。
• プール: 割り当て元となる CIDR の集まり。プールは入れ子（階層）にでき、上位プールから下位プールへ範囲を切り出していく。最終的に VPC などのリソースへ割り当てる。
• 割り当て (Allocation): プールから特定のリソースや下位プールへ実際に払い出された CIDR のこと。手動で確保することも、VPC 作成時に自動で取得させることもできる。
• 割り当てルール: プールに設定する制約。割り当て可能な最小・最大のプレフィックス長や、必須タグなどを定義し、想定外のサイズや用途での払い出しを防ぐ。
• リージョン設定: プールをどのリージョンで利用可能にするか（ロケール）の指定。VPC へ割り当てるプールには、その VPC のリージョンに対応するロケールが必要になる。
• 共有: IPAM プールを AWS Resource Access Manager (RAM) で他アカウントへ共有し、組織内の各アカウントがそのプールから割り当てを受けられるようにする仕組み。

仕様・制限・クォータ

IPAM を設計する際に意識すべき仕様上の性質は次のとおりです。具体的な上限値はリージョンや時期で変わりうるため、定性的に把握し、正確な数値は公式ドキュメントとサービスクォータの画面で確認してください。

• IPAM 本体はホームリージョンを持ち、そこを起点に他リージョンの運用リージョンを束ねて横断管理する。
• プールは階層化でき、上位から下位へ CIDR を切り出す入れ子構造を取れる。階層の深さや 1 アカウントあたりのプール数・スコープ数にはクォータがある。
• IPv4 と IPv6 の双方を管理できる。パブリックスコープでは、AWS が提供するアドレスのほか、自分で持ち込んだアドレス範囲（Bring Your Own IP）も扱える。
• VPC に IPAM プールから CIDR を自動割り当てさせるには、その VPC のリージョンに合致するロケールを持つプールが必要になる。
• プールには割り当てルールとして許可するプレフィックス長の範囲を設定でき、これにより大きすぎる・小さすぎる払い出しを抑制する。
• 使用率の指標は定期的に集計され、即時反映ではなく一定の集計間隔を伴う。枯渇しきい値による警告もこの集計に基づく。

内部の仕組み

IPAM の中核は、IP アドレス空間を階層的なプールとして表現し、そこから割り当てを管理する点にあります。

まず、最上位に大きな CIDR を持つトッププールを作り、その配下に組織の構造（リージョン別、環境別、チーム別など）に沿った下位プールを切り出していきます。各下位プールはさらに分割でき、最終的に VPC などのリソースへ CIDR が割り当てられます。割り当ては重複しないように IPAM が調停するため、同じスコープ内で範囲がぶつかることはありません。

各アカウントやリージョンへプールを使わせるには、RAM でプールを共有します。共有されたアカウントは VPC を作成するとき、特定の CIDR を手で指定する代わりに「このプールから払い出してほしい」と指定でき、IPAM が空いている範囲を選んで割り当てます。割り当てルールに反するサイズや、必須タグを満たさない要求は拒否されます。

IPAM はさらに、組織内のリソースをモニタリングし、どの CIDR がどの VPC やサブネットで実際に使われているかを継続的に検出します。プールに紐づかない既存の VPC も発見対象に含められ、組織全体の IP 利用状況が一つのビューに集約されます。割り当ての作成・削除などの変化は履歴として記録され、後から「いつ、どの範囲が、どこに割り当てられたか」を追跡できます。

設計パターン / ベストプラクティス

• 組織構造に沿って階層を設計する: トッププールの下を、リージョン → 環境（本番・検証）→ アカウントやチームのように段階的に分割すると、割り当てが整理され、ルーティングや集約も考えやすくなる。
• 委任管理アカウントに集約する: IPAM は Organizations の委任管理アカウントに置き、各アカウントへは RAM でプールを共有する。管理の単一窓口を作り、権限の所在を明確にする。
• 割り当てルールでガードレールを敷く: プールごとに許可するプレフィックス長を定め、過大・過小な払い出しや、別系統で使うべき範囲の誤用を機械的に防ぐ。必須タグで用途の記録も強制する。
• VPC の CIDR は自動割り当てを使う: 手動で CIDR を選ぶ運用をやめ、VPC 作成時に IPAM プールから自動取得させると、重複の余地がなくなり、台帳管理も不要になる。
• 既存環境はまず可視化から始める: いきなり全面移行せず、既存の VPC を IPAM に検出させて現状の利用状況を棚卸しし、重複や余剰を把握してから階層設計を固める。

運用・監視

• 使用率の追跡: プールごとの割り当て済み比率を継続的に確認し、枯渇に近づいているプールを早期に把握する。階層のどこが逼迫しているかを俯瞰できる。
• しきい値による警告: プールに枯渇のしきい値を設定し、使用率がそれを超えたら気づけるようにする。集計値をもとに監視と組み合わせ、早めの拡張や見直しにつなげる。
• 割り当て履歴の活用: いつ・どの範囲が・どこに割り当てられたかの履歴を、トラブルシュートや監査の証跡として利用する。手作業の台帳に頼らず実態を追える。
• 既存リソースの継続検出: プール管理外の VPC も検出対象に含め、組織全体の IP 利用が一つのビューで把握できる状態を保つ。シャドー的な割り当ての見落としを減らす。
• 自動化との連携: プールや割り当ての構成は Infrastructure as Code で管理し、誰がどのプールを使えるかという共有設定の変更も追跡できるようにする。

コスト

IPAM の料金は、おおむね次の考え方で構成されます。具体的な単価やサービス階層はリージョンや時期で変動するため、最新の料金ページで確認してください。

• 機能階層による違い: IPAM には基本的な管理機能の階層と、より高度な機能（横断的な監視や自動検出などの拡張）を含む上位階層があり、利用する階層によって課金の有無や水準が変わる。
• 管理対象に応じた課金: 上位の機能では、IPAM が管理・監視するアクティブな IP アドレスの量に応じて料金が発生する考え方を取る。管理規模が大きいほどコストも増える。
• トレードオフの評価: IP 管理の手作業や、重複起因の障害・手戻りにかかる人的コストと、IPAM の利用料を比較して導入規模を判断する。小規模なら基本機能で足りることも多い。

セキュリティ

• 集中管理による統制: IP 計画を一元化し、誰がどのプールから割り当てられるかを RAM の共有で制御することで、無秩序な割り当てや想定外のネットワーク到達性の温床を減らせる。
• 最小権限の運用: IPAM の操作権限は委任管理アカウントと必要なロールに絞る。プールの作成・共有・割り当てといった操作を IAM で適切に分離する。
• ガードレールとしての割り当てルール: プレフィックス長の制約や必須タグは、誤った範囲の払い出しを防ぐ予防的統制として機能する。
• 監査証跡: 割り当ての変更履歴を保持し、API 呼び出しの記録と合わせて、いつ誰が IP 構成を変えたかを後から追える状態にする。
• 持ち込みアドレスの扱い: 自分で持ち込むパブリックアドレス範囲を管理する場合は、所有権の検証や公開範囲の管理を慎重に行う。

関連サービス・比較

IPAM は Amazon VPC と密接に関わります。VPC が個々の仮想ネットワークを定義するのに対し、IPAM はそれらの VPC に割り当てる IP アドレス空間を組織全体で計画・管理する上位レイヤの役割を担います。次の表は、両者の役割の違いを整理したものです。

ハンズオン / CLI例

次は、IPAM を作成し、最上位プールを作って CIDR を切り出す基本的な流れの例です。スコープ ID や CIDR、リージョンは自分の環境の値に置き換えてください。

# IPAM を作成し、運用リージョンを指定する
aws ec2 create-ipam \
  --description "org-ipam" \
  --operating-regions RegionName=ap-northeast-1

# 既定のプライベートスコープ ID を確認する
aws ec2 describe-ipams \
  --query "Ipams[].[IpamId,PrivateDefaultScopeId]"

# プライベートスコープにトッププールを作成する
aws ec2 create-ipam-pool \
  --ipam-scope-id ipam-scope-0123456789abcdef0 \
  --address-family ipv4 \
  --locale ap-northeast-1

# トッププールに管理対象の CIDR を割り当てる（プロビジョニング）
aws ec2 provision-ipam-pool-cidr \
  --ipam-pool-id ipam-pool-0123456789abcdef0 \
  --cidr 10.0.0.0/8