ENGINEER BLOG ENGINEER BLOG
  • 公開日
  • 最終更新日

【Amazon VPC IPAM】マルチアカウント環境でIPAMを構築してみた

この記事を共有する

目次

はじめに

皆さんこんにちは！パーソル＆サーバーワークスの小泉です。
マルチアカウント環境を運用していると、「このCIDR、どこかのアカウントと被ってないかな？」と不安になることはないでしょうか。
今回は、その課題を解決してくれる Amazon VPC IP Address Manager（以下、IPAM） を、マルチアカウント・マルチリージョン構成で実際に構築してみました。
プールの設計から、別アカウントへのCIDR払い出し、SCPによる統制まで一通り触ってみたので、その手順と所感をまとめます。

※IPAMの基本用語を知りたい方はこちらの記事をご覧ください

なぜこれをやったのか

IPアドレス管理でよくある悩みは、だいたい次の3つに集約されると思います。

  • Excel台帳が属人化し、更新漏れで実態とズレる
  • アカウントをまたいだCIDRの重複に気づけず、ピアリングやTGW接続時に初めて発覚する
  • どのアカウント・リージョンに、どんなCIDRが、どれだけ使われているのか全体像が見えない

IPAMはこれらをまとめて面倒見てくれるサービスです。ただ、機能の話を聞くだけではピンとこなかったので、実際に手を動かして「どこまでできるのか」を確かめることにしました。

今回構築する構成

アカウント構成

今回はAWS Organizations配下の3アカウントを使います。それぞれ役割が異なります。

アカウント構成.png

アカウント役割主な操作
管理アカウント組織の管理者IPAM管理者の委任、RAM組織共有の有効化、SCPアタッチ
IPAM管理者IPアドレスの設計・管理者IPAM作成、プール階層の構築、プール共有
開発者VPCを使う側共有プールからCIDRを払い出してVPC作成

注意点としては管理アカウント自身はIPAM管理者になれないので必ずメンバーアカウントに委任します。

リージョン構成

IPAMのホームリージョンは東京（ap-northeast-1）、オペレーティングリージョンに大阪（ap-northeast-3）を追加します。これにより、東京・大阪両方のリソースをIPAMが検出・管理します。

IPAM管理リージョン.png

プール階層とVPC払い出しの全体像

これらを合わせた全体像が以下です。

全体.png

プールは4階層で設計します。トップレベルの「Global pool」を起点に、リージョンごとのプール（東京・大阪）、さらに東京の下に開発用の「Pre-prod pool」を作ります。

プールCIDR用途
Global pool10.0.0.0/16全体の親。直接は払い出さない
Regional pool 東京10.0.0.0/18東京リージョン用
Regional pool 大阪10.0.64.0/18大阪リージョン用
Pre-prod pool10.0.0.0/20開発VPC用。/24固定・タグ必須

なお、IPAMの操作はAWS CLIで進めました。マネジメントコンソールでも同じことができますが、手順が再現しやすいのでCLIで記載します。

手順

1. IPAM管理者を委任する

まず管理アカウントで、IPAM管理者となるメンバーアカウントを委任します。これは管理アカウントのIPAMコンソール「組織設定」から行います。

委任①.png

「委任」ボタンから、IPAM管理者にしたいメンバーアカウントのIDを入力します。

委任②.png

2. IPAMを作成する

ここからは委任したIPAM管理者アカウントで作業します。IPAM本体を作成します。

aws ec2 create-ipam \
  --description "ipam-blog-verification" \
  --operating-regions RegionName=ap-northeast-1 RegionName=ap-northeast-3 \
  --tier advanced \
  --region ap-northeast-1

--regionで指定したリージョン（東京）が「ホームリージョン」になります。--operating-regionsには、IPAMに管理させたいリージョンを並べます。今回は東京と大阪を指定しました。

IPAMを作成すると、privateとpublicの2つのスコープが自動で作られます。
プライベートIP（VPCのCIDRなど）はprivateスコープ、パブリックIP（EIPなど）はpublicスコープで管理されます。今回はprivateスコープを使います。
作成後、PrivateDefaultScopeIdをメモしておきます。以降のプール作成で使います。

3. トップレベルプールを作成する

プール階層の起点となるGlobal poolを作ります。トップレベルなのでロケール（割当先リージョン）は指定しません。 

aws ec2 create-ipam-pool \
  --ipam-scope-id  \
  --description "Global pool" \
  --address-family ipv4 \
  --region ap-northeast-1

作成できたら、CIDRをプロビジョニングします。プールは作っただけでは使えず、CIDRを割り当てて初めて払い出し可能になります。

aws ec2 provision-ipam-pool-cidr \
  --ipam-pool-id  \
  --cidr 10.0.0.0/16 \
  --region ap-northeast-1

4. リージョンプールを作成する

Global poolを親（ソース）に、東京・大阪それぞれのリージョンプールを作ります。

東京：

aws ec2 create-ipam-pool \
  --ipam-scope-id  \
  --source-ipam-pool-id  \
  --locale ap-northeast-1 \
  --description "Regional pool ap-northeast-1" \
  --address-family ipv4 \
  --region ap-northeast-1

大阪も同様に、CIDR「10.0.64.0/18」で作成します。それぞれCIDRのプロビジョニングまで済ませます。

5. 開発用プール（Pre-prod pool）を作成する

東京リージョンプールを親に、開発用のPre-prod poolを作ります。このプールには「払い出すCIDRは/24固定」「environment=pre-prod タグが必須」という割り当てルールを設定します。

aws ec2 create-ipam-pool \
  --ipam-scope-id  \
  --source-ipam-pool-id  \
  --locale ap-northeast-1 \
  --description "Pre-prod pool" \
  --address-family ipv4 \
  --allocation-min-netmask-length 24 \
  --allocation-default-netmask-length 24 \
  --allocation-max-netmask-length 24 \
  --allocation-resource-tags "Key=environment,Value=pre-prod" \
  --region ap-northeast-1

CIDR「10.0.0.0/20」をプロビジョニングすれば、4階層のプール構造が完成します。コンソールで見るとこのような階層になっています。

プール.png

Global → 東京/大阪 → Pre-prod ときれいに階層化されているのが分かります。Pre-prod poolの「コンプライアンス」タブを開くと、設定した割り当てルールが確認できます。

コンプライアンス.png

ネットマスクが/24で固定され、environment=pre-prodタグが必須になっています。このルールが、後ほど効いてきます。

6. プールをRAMで共有する

開発者アカウントがPre-prod poolを使えるように、AWS Resource Access Manager（RAM）で共有します。

まず管理アカウントで、RAMの組織内共有を有効化しておきます。

RAM組織共有.png

次に、IPAM管理者アカウントでPre-prod poolを共有します。共有先には、開発者アカウントが所属するOUを指定します。

aws ram create-resource-share \
  --name "ipam-preprod-pool-share" \
  --resource-arns  \
  --principals  \
  --region ap-northeast-1

7. IPAMプールからVPCを払い出す（タグ必須の挙動確認）

ここからは開発者アカウントでの作業になります。
共有されたPre-prod poolを使って、VPCコンソールからVPCを作成します。

CIDRブロックで「IPAM割り当てのIPv4 CIDRブロック」を選び、IPv4 IPAMプールにPre-prod poolを指定します。ネットマスクは、プール側で/24固定にしているため、/24しか選べません。

まずは、わざとタグを付けずに作成してみます。

VPC-tag.png

期待どおり、エラーになりました。

The resource is missing one or more of the resource tags required by the IPAM pool.

Pre-prod poolに設定した「environment=pre-prodタグ必須」のルールが効いています。タグを付け忘れたVPCは作れない、というガバナンスが働いているわけです。

タグ（environment=pre-prod）を追加して再度作成すると、今度は成功し、「10.0.0.0/24」が払い出されました。

ちなみに、このタグ必須やネットマスクのルールは「そのプールにだけ」効きます。試しにIPAM管理者アカウントから上位の東京リージョンプールを直接選んでVPCを作ったら、タグなしでも作れてしまいました。
東京リージョンプールにはルールを設定していないので当然なのですが、ここで「制約を効かせたいプールだけを開発者に共有し、上位プールは共有しない」という設計の意味が腑に落ちました。
開発者アカウントにはPre-prod poolしか共有していないので、開発者は必ずルールに従うことになります。

8. 払い出したVPCがIPAMに自動で現れる

IPAM管理者アカウントに戻り、IPAMコンソールの「リソース」を見てみます。

ipam-overview(リソース一覧).png

先ほど開発者アカウント（別アカウント）で作ったVPC「10.0.0.0/24」が、ちゃんと検出されています。Organizations統合により、IPAMが各メンバーアカウントのリソースを自動でディスカバリしてくれるためです。

リソースごとの状態はこのようになっていました。

プール経由のVPCデフォルトVPC（172.31系）
管理状態マネージドアンマネージド
コンプライアンス準拠（対象外）
重複ステータス重複なし重複

IPAMプールから払い出したVPCは「マネージド・準拠・重複なし」、一方で各アカウントにもともとあるデフォルトVPC（すべて172.31.0.0/16）は「アンマネージド・重複」と判定されています。
複数アカウントのデフォルトVPCが同じCIDRなので、当然といえば当然なのですが、これが重複CIDRの検出になります。

9. ダッシュボードで全体像を把握する

IPAMのダッシュボードを見ると、スコープ全体のサマリがウィジェットで表示されます。

ipam-overview.png

リソースCIDRの種類（VPC/サブネット）、管理状態（マネージド/アンマネージド）、重複の有無、ルール準拠の状況などが円グラフでまとまっています。
「重複するリソースCIDR」のウィジェットが赤く出ているのが分かりますね。これが先ほどのデフォルトVPCの重複です。

マルチアカウント・マルチリージョンの全体像が、この1画面で把握できるのは率直に便利だと感じました。

10. SCPでIPAMの利用を強制する

最後に、ガバナンスをもう一段階固めます。プールを共有しただけでは、開発者が手動でCIDRを指定してVPCを作ることも依然として可能です。そこで、SCP（サービスコントロールポリシー）で「IPAMプールを使わないVPC作成を禁止」します。

管理アカウントで、以下のSCPを作成します。

SCP.png

{
    "Version": "2012-10-17",
    "Statement": [{
        "Effect": "Deny",
        "Action": ["ec2:CreateVpc", "ec2:AssociateVpcCidrBlock"],
        "Resource": "arn:aws:ec2:*:*:vpc/*",
        "Condition": {
            "Null": {
                "ec2:Ipv4IpamPoolId": "true"
            }
        }
    }]
}

ec2:Ipv4IpamPoolIdが指定されていない（=IPAMを使わない）VPC作成を拒否する、という内容です。これを検証用のOUにアタッチします。

アタッチ後、開発者アカウントで手動CIDR（192.168.100.0/24）を指定してVPCを作ろうとすると、こうなります。

VPC-SCP.png

You are not authorized to perform this operation ... with an explicit deny in a service control policy

SCPによって明示的に拒否されました。

所感

実際に手を動かしてみて、IPAMの良さがよく分かりました。
特に良いと感じた点は以下です。

  • マルチアカウントの自動検出：委任設定をするだけで、各アカウントのVPCやサブネットが自動でIPAMに集約される。
  • 重複CIDRの可視化：デフォルトVPCの重複が、何もしなくても「重複」として検出される。
  • プールによる統制：ネットマスクやタグのルールをプールに持たせ、SCPと組み合わせることで「ルールに沿ったVPCしか作れない」状態を作れる

この記事は私が書きました

小泉 和貴

記事一覧

全国を旅行することを目標に、仕事を頑張っています。

小泉 和貴

この記事を共有する

クラウドのご相談

CONTACT

クラウド導入や運用でお悩みの方は、お気軽にご相談ください。
専門家がサポートします。

お問い合わせ

サービス資料ダウンロード

DOWNLOAD

ビジネスをクラウドで加速させる準備はできていますか？
今すぐサービス資料をダウンロードして、詳細をご確認ください。

資料請求