【入門編】 Amazon VPC IPAM(IP Address Manager)による大規模CIDRプール階層管理 – クラウドインフラと仮想化ネットワーク実践ガイド

こんにちは！クラウドインフラの世界へようこそ。第一線でSREとしてインフラの奔流に向き合っている私ですが、日々の業務で頭を悩ませるもののひとつに「IPアドレスの管理」があります。

「あれ、この開発環境のVPCと本番環境のVPC、CIDR（IPアドレスの範囲）が被っていませんか？」
「新しいプロジェクトが始まるたびに、空いているIPの範囲を探してスプレッドシートを更新する作業、もう限界じゃないですか？」

マルチアカウントやマルチVPCが当たり前になった現代のクラウド環境では、IPアドレスの管理はもはや個人の手作業でコントロールできるレベルを超えています。そこでAWSが用意してくれた強力な救世主が、今回解説する Amazon VPC IPAM（IP Address Manager） です。

今回は、インフラやネットワークに初めて触れる方でもスッと腹落ちするように、現実世界の「郵便配達」に例えながら、その仕組みと魅力を優しく紐解いていきましょう。一歩ずつ、丁寧に解説していきますね！

—

1. そもそも「VPCのCIDR管理」って、現実世界で例えると？

皆さんが暮らす街を想像してみてください。家を建てるには「住所」が必要です。
AWSのクラウド世界において、ひとつのVPC（Virtual Private Cloud）は、いわば「個別の街（あるいは巨大なマンション）」のようなものです。

  • IPアドレス（CIDR）: 街の番地や区画整理のルール（例: 10.0.0.0/16 というエリア）
  • サブネット: その街の中の「何丁目、何番地」という細かいブロック

もし、あなたがお友達に荷物を送る時、日本中に「1丁目1番地」という住所が何個もあったらどうでしょう？ 郵便配達員さんは「どの街の1丁目1番地ですか！？」とパニックになってしまいますよね。クラウドの中でも全く同じ現象が起きます。異なるVPCの間でIPアドレスの範囲（CIDR）が重複していると、AWSのネットワーク（VPCピアリングやTransit Gatewayなど）で繋いだときに「どっちのサーバーに通信を送ればいいの？」と迷子になってしまうのです。

従来のExcel管理の限界

これまでは、チームごとに「うちは 10.100.0.0/16 を使います」「うちは 10.200.0.0/16 ですね」と、GoogleスプレッドシートやExcelで手動管理していました。
しかし、システムが成長し、数百・数千のアカウントが乱立するようになると……。

  • 「あ、そのIPレンジ、さっき別のチームが使っちゃいました」
  • 「空き状況を調べ忘れて、アドレスが枯渇した！」

なんていうインフラあるあるの悲劇が毎日のように発生します。これを自動化し、組織全体のルールとして美しく整理してくれるのが VPC IPAM なんです。

—

2. Amazon VPC IPAMってどんな仕組み？（階層構造の魔法）

VPC IPAMは、いわば「一元化された超優秀な都市計画局」です。組織全体のIPアドレスの割り振りを一括してコントロールしてくれます。

IPAMの仕組みを理解する上で大切なキーワードが、「階層構造（Top-Downアプローチ）」です。現実の住所に例えてみましょう。

1. Top（最高位・IPAMプール）: 国全体の住所割り当て管理（例: 日本という国全体で使えるIPの大きなお札 10.0.0.0/8）
2. Middle（中間・リージョン別/事業部別プール）: 都道府県や大企業ごとの割り当て（例: 「開発部用エリア 10.10.0.0/16」「本番環境用エリア 10.20.0.0/16」）
3. Bottom（末端・VPC個別割り当て）: 実際の個別の家（VPC作成時に、IPAMが自動的に「じゃあ君のVPCには 10.10.1.0/24 をあげるね」と切り出す）

この仕組みがあるおかげで、現場の開発者が勝手に被ったIPアドレスを使ってしまうリスクが物理的（システム的）になくなります。すべては親プールから自動で「きれいな切り売り」がされるため、重複が起こりようがないのです。

—

3. 実践！AWS CLIでIPAMの階層プールを作ってみよう

「なるほど、概念は分かったけれど、実際にどうやって設定するの？」
ここからは、実務でそのまま参考にできるように、AWS CLIを使った基本的なIPAM構築の流れを見ていきましょう。

今回は、次のようなシンプルな階層を作ります。

  • 組織全体の親プール（ScopeとIPAM）
  • 開発部用の小プール（Child Pool）

ステップ1: IPAMの作成とデフォルトスコープの取得

まずは、AWSアカウントの中に「都市計画局（IPAM）」を立ち上げます。

# IPAM本体を作成し、東京リージョン（ap-northeast-1）を指定します
aws ec2 create-ipam \
    --region ap-northeast-1 \
    --description "全社共通のIPAM一元管理プール" \
    --operating-regions RegionName=ap-northeast-1

# 返却される JSON から "IpamId" （例: ipam-0123456789abcdef0）をメモしておきます
# 同時に自動作成される「パブリック用」「プライベート用」のスコープID（DefaultPrivateScopeId）を確認します

ステップ2: 親プール（Top-Level Pool）の作成

次に、全社で使える大元のCIDRブロック（今回は 10.0.0.0/8）を持つ親プールを作ります。

# プライベートスコープIDを指定して、親プールを作成します
aws ec2 create-ipam-pool \
    --ipam-id ipam-0123456789abcdef0 \
    --ipam-scope-id ipam-scope-0123456789abcdef0 \
    --address-family ipv4 \
    --description "全社プライベートIPの親プール" \
    --locale ap-northeast-1

# 作成されたプールID（例: ipam-pool-11112222333344445）に対して、実際のCIDRを割り当てます
aws ec2 provision-ipam-pool-cidr \
    --ipam-pool-id ipam-pool-11112222333344445 \
    --cidr 10.0.0.0/8

ステップ3: 開発部用の小プール（Child Pool）の切り出し

親プールから、開発部向けに 10.0.0.0/12 という少し小さめのブロックを切り出して、子プールを作ります。

# 親プール（ipam-pool-11112222333344445）を親（Parent）として指定します
aws ec2 create-ipam-pool \
    --ipam-id ipam-0123456789abcdef0 \
    --ipam-scope-id ipam-scope-0123456789abcdef0 \
    --address-family ipv4 \
    --parent-ipam-pool-id ipam-pool-11112222333344445 \
    --description "開発部専用のCIDRプール" \
    --locale ap-northeast-1

# 子プール側にもCIDRの割当範囲をプロビジョニングします（例として /12 を切り出し）
aws ec2 provision-ipam-pool-cidr \
    --ipam-pool-id ipam-pool-99998888777766554 \
    --cidr 10.0.0.0/12

この開発部用プール（ipam-pool-99998888777766554）を、開発チームが使うAWSアカウントやVPC作成時に指定するようにポリシーを定めれば、開発チームはもうIPアドレスの重複に怯える必要がなくなるのです！

—

4. 現場で役立つSREの知見：IPAM運用のベストプラクティス

最後に、実際の現場でIPAMを導入・運用する際に気をつけておきたいポイントを、SREの視点からいくつかシェアしますね。

1. マルチアカウント環境では「AWS Organizations」と連携する

  • IPAMは単一のアカウントだけでなく、組織（Organizations）内の別アカウントへも管理権限（RAM: Resource Access Manager経由）を安全に配布できます。「子会社のA社」「独立した事業部のB社」それぞれにプールを綺麗に切り分けて委譲しましょう。

2. CIDRのサイジング（大きめの設計）を最初にしておく

  • 「とりあえず小さめでいいか」と切り出すと、後からCIDRの拡張（拡張やマイグレーション）で痛い目をみます。クラウドのIPは枯渇させないよう、余裕を持ったブロック設計（例えば /16 や /12 など）を心がけてください。

3. TerraformやCloudFormationでのコード化（IaC）を徹底する

  • 先ほどCLIの例を出しましたが、実務では必ずTerraformなどのIaC（Infrastructure as Code）で管理しましょう。aws_vpc_ipam や aws_vpc_ipam_pool リソースを使って、誰が変更しても履歴が残る状態にしておくことが、トラブルを防ぐ一番の近道です。

—

まとめ

今回は、Amazon VPC IPAMによる大規模CIDRプールの階層管理について、郵便配達のたとえや実際のCLI設定を交えて解説しました。

  • IPAMは、組織全体のIPアドレスを一元管理する「優秀な都市計画局」である。
  • 親プールから子プールへの階層構造（Top-Down）により、アドレスの重複や枯渇をシステム的に防げる。
  • IaCやOrganizationsと組み合わせることで、マルチアカウント環境のインフラ運用が劇的にスッキリする。

「IPの重複チェック」という、かつてインフラエンジニアを悩ませていた泥臭い作業を自動化し、より価値のあるアプリケーションの設計や信頼性向上に時間を使えるようにしていきましょう。

それでは、また次のクラウドでお会いしましょう！SREチームの主筆ライターより、愛を込めて。

スポンサーリンク

コメント

タイトルとURLをコピーしました