はじめに

AWSでEC2などのリソースを作成する場合に、
そのリソースに対して特定のIPからのみアクセス出来る様にする形で配置しようとすると、
Network ACLやSecurity Groups等でCIDRを限定する事があると思います。

Security Groupsを中心に利用する場合、ルールに対してCIDRを追加しても良いですが、
ルールに対してプレフィックスリストを適用する事で、
柔軟で保守容易性に優れた形でCIDRを管理する事が可能になります。

プレフィックスリストとは？

AWSプレフィックスリストはCIDRをまとめて管理する事が出来る様になる、
AWSにおけるリソースの一つです。

VPCのダッシュボードのサイドバーにある「マネージドプレフィックスリスト」から
実際に確認する事が可能です。

AWSが管理して作成されている「AWSマネージドプレフィックスリスト」の他に、
自ら「カスタマーマネージドプレフィックスリスト」を作成する事も可能です。

カスタマーマネージドプレフィックスリストでは、
以下の様に自ら管理するCIDRをまとめて格納しておくことが出来ます。

Security Groupの他に、Route Tableへの割り当ても可能になっています。

プレフィックスリストの主な用途はSecurity Groupsになると思いますが、
特に複数の拠点がある様な場合に効果を発揮します。

以下に例を挙げます。
まず、3つの拠点があるとして、それらの拠点から接続できるEC2が3つあると考えます。
EC2にはそれぞれ異なるSecurity Groupsを割り当てるとしました。

それらの依存関係は以下の様になります。

実際には見た目程複雑な設定ではありませんが、図にすると大分複雑に見えます。

ここで、拠点XのIPが変更になった場合を想定します。
拠点XのIPが変更になった場合、影響範囲は以下の様になります。

この場合、EC2毎に割り当てられている全てのSecurity Groupsを変更する必要があります。

これらのSecurity GroupsのルールのCIDRの一覧が適切に管理されていて、
かつ見落としなく作業出来るなら問題は無いかもしれませんが、
例えばこのSecurity Groupsがもっと多かった場合を考えた時、
保守の管理の面から言えば、この手法はあまり適切で無いかもしれません。

この様な構成において、Security Groupsに対してプレフィックスリストを適用していると、
依存関係は以下の様になります。

先程と同様に拠点XのIPが変更になった場合を考えると、影響範囲は以下の様になります。

上の図のように、拠点に関するCIDRの変更影響範囲を極小化させる事が可能になります。
これはCIDRの変更や追加に対して柔軟である構成と考える事が出来ます。

プレフィックスリストは、保守容易性を向上させる為のツールの一つとなります。

今回の様にIP(CIDR)という具体的なアイテムを取り扱う際に、
プレフィックスリストをインターフェースとして取り扱う事で、
「抽象化による柔軟性の確保」を行う事が出来ます。
設計思想という観点からすれば「依存関係逆転の法則」に近しい、と考える事も可能です。

プレフィックスリストは再利用性も高く、
バージョン管理によって復元を行える事も大きなメリットと成り得ます。
terraformやCloudFormationなどのIaCとも相性が良いです。

今回は複数のCIDRを指定するケースを例に挙げましたが、
単独のCIDRを指定する様なケースであってもプレフィックスリストを経由する事で、
変更に対する柔軟性を確保する事が出来ます。

設定の一貫性を確保したり、人的ミスを防ぐなど、
保守容易性を向上させることで得られるメリットは運用面において非常に大きいです。
長くクラウドを運用する事を考慮した時には保守容易性の向上についても、
システムの中に考慮すると運用が非常に楽になるかと思います。