VPC内のIPアドレスを効率的に管理するVPC IP Address Managerが発表されました #reinvent

プール計画が重要です
2021.12.02

AWS re:Invent 2021にてAmazon VPC IP Address Managerが発表されました。

こちらのサービスを利用することで、VPC内のIPアドレスを効率的に管理できるようになりそうです。概要を紹介しつつ、実際に触れてみたいと思います。

概要

AWSワークロードで利用するIPアドレスの管理、および利用状況等が監視できるサービスになります。コンソールからIPアドレスの利用状況の確認や、VPCへのIPアドレス割り当てを自動で行えるため、スプレッドシート等で行っていたIPアドレスの管理等が不要になります。

料金は、IPAMで管理されるアクティブなIPアドレスごとに時間料金が発生します。アクティブなIPアドレスとは、EC2やENIなどのリソースに割り当てられたIPアドレスとして定義されています。

  • 時間料金: $ 0.00027(東京リージョン)

例えば、VPCに/16のCIDR(65536IP)を割り当て、EC2で5000IPアドレス使用していた場合、月額は以下のようになります。

  • 5000(アクティブIP) x 30(日) x 24(時間) x $0.00027(時間料金)= $ 972(月額)

詳細は以下が参考になります。

やってみた

今回は単一のAWSアカウントにて、IPAMを利用しVPCにアドレスを割り当ててみたいと思います。

service-linked role作成

IPAMはservice-linked roleを使用して、リソースに関連付けられたCIDRの管理を行います。ここでは、AWS CLIよりservice-linked roleを作成します。 *1

$ aws iam create-service-linked-role \
--aws-service-name ipam.amazonaws.com
{
    "Role": {
        "Path": "/aws-service-role/ipam.amazonaws.com/",
        "RoleName": "AWSServiceRoleForIPAM",
        "RoleId": "AROAVWTKLCOCHDNQGZALF",
        "Arn": "arn:aws:iam::xxxxxxxxxxxxx:role/aws-service-role/ipam.amazonaws.com/AWSServiceRoleForIPAM",
        "CreateDate": "2021-12-02T03:20:53+00:00",
        "AssumeRolePolicyDocument": {
            "Version": "2012-10-17",
            "Statement": [
                {
                    "Action": [
                        "sts:AssumeRole"
                    ],
                    "Effect": "Allow",
                    "Principal": {
                        "Service": [
                            "ipam.amazonaws.com"
                        ]
                    }
                }
            ]
        }
    }
}

IPAMにおけるservice-linked roleの詳細については、以下が参考になります。

IPAM作成

コンソールよりIPAMを作成します。「データレプリケーションを許可」にチェックを入れ、名前を付与し運用リージョンを選択します。

01

IPAMが作成されると、1つのプライベートスコープと1つのパブリックスコープが作成されます。

02

スコープはIPAMにおけるの最上位の概念となり、IPアドレスの重複を防ぎます。スコープ内でプール(管理するIPアドレス範囲)を作成して利用します。

なお、デフォルトではリージョンごとに作成可能なIPAMは1つとなっていますので、複数作成する場合はクォータの調整が必要です。

03

プール計画

今回は以下の構成で、プールを作成していきたい思います。プールは後から追加可能で、最大10階層まで作成できるようです。

aw-pool(トップレベルのプール) … 192.0.0.0/8
└── ap-northeast-1-pool(リージョナルプール) … 192.0.0.0/12
    └── test-pool(開発プール) … 192.0.0.0/14
      └── VPCの割り当て … 192.0.0.0/16

プール計画については、以下が参考になります。

トップレベルのプール作成

トップレベルで管理するCIDRをプールに設定します。トップレベルのため、ソースプールは指定せず、CIDRを設定しました。

04

リージョナルプール作成

上記プール計画の通り、トップレベルのプール配下にリージョンナルプールを作成します。ソースプールにトップレベルのプールを指定し、CIDRを設定しました。 05

開発プール作成

上記プール計画の通り、リージョンナルプール配下に開発プールを作成します。こちらは、今回、最下層となるプールです。 ソースプールにリージョンナルプールを指定し、CIDRを設定しました。 *2ここでは、ネットマスク長にルールを設けてみました。(最小/16、最大/24)

06

これで計画どおりの構成でプールを作成できました。

07

VPCへの割り当て

IPAMから割当を選択してVPCを作成しました。 08

開発プールでネットマスク長を設定していたので、ネットマスクは指定の範囲から選択しました。

09

以下、VPCが作成できました。

10

プールの詳細画面

作成したVPCでEC2を起動し、開発プールの詳細画面を確認してみました。プールの割当状況や、利用可能なIPなどを確認することができました。

11

リソースの状況も確認することが可能です。

12

以上となります。

今回のプール構成で実際に運用していく場合は、以下のように開発プールが増えていくことになると思います。

▲ 重複も防ぐ

最後に

今回は、単一のAWSアカウントを使用してやってみましたが、マルチアカウントでの利用や、organizationと統合することも可能です。 本番で利用する際は、管理するCIDR、用途にあわせ、プール計画が重要になりそうです。スプレッドシートでのIP管理に負荷を感じていたり、大規模ネットワークを管理する際は利用を検討してみてはいかがでしょうか。

参考

脚注

  1. 本検証はコンソールからおこなっていましたが、今回の利用においてコンソールから作成するタイミングがなく、自動で作成されている様子もありませんでした。それにより、IPAMによるリソースの自動検出が行えなかったため、AWS CLIにて作成しました。
  2. プール作成時に自動インポートの設定を「Don't allow」にしてしまったので、プール作成後に設定を更新しました。