VPCプレフィックスリストの最大エントリ数指定で注意すべきこと

しばたです。

先月末にVPCプレフィックスリストを作成できる機能が提供されましたが、プレフィックスリストの仕様を誤認してハマってしまったのでこの場で共有します。

2021年8月28日追記 : 最大エントリ数が変更可能になりました

2021年8月28日のアップデートによりプレフィックスリストの最大エントリ数を自由に変更できる様になりました。

このため現在においては最大エントリ数の設計をよりカジュアルにできる様になっています。

ただし、計上されるルール数についてはこれまで通り変更はありません。
このため後から最大エントリ数を増やそうとしてもセキュリティグループやルートテーブル側の余力がなく増やせない場合がありますのでご注意ください。

(追記ここまで)

TL;DR

VPCプレフィックスリストで計上されるルートテーブル/セキュリティグループのルール数は 常に最大エントリ数 となります。
また、最大エントリ数は後で変更できないためここに設定する値は事前に十分な考慮が必要になります。

どういうこと？

最初に紹介した記事にある通り、

なお、以下のドキュメントによるとプレフィックスリストあたりのエントリ数には制限がないようですが、プレフィックスリストに記載したエントリ数がルートテーブル/セキュリティグループのルール数としてカウントされるようです。

と、VPCプレフィックスリストを使用してもルートテーブルおよびセキュリティグループで使用するルール数を集約することはできないのですが、私はこれを「プレフィックスリストにあるエントリ数だけ計上される」と誤解していました。

セキュリティグループを例に挙げると、デフォルトでは1つのセキュリティグループあたり最大60ルール設定可能となっています。(上限緩和申請した場合は別)

例えば「最大10エントリ、そのうち2エントリを記載したプレフィックスリスト」を作成したとします。
適当なセキュリティグループに1行(1ルール相当)記載した場合、私はプレフィックスリストに記載されている2エントリ分で2ルール計上されると思っていたのですが、実際にはこの場合最大エントリ数である10ルール分計上されます。

改めてドキュメントを確認すると、

• リソース内でプレフィックスリストを参照する場合、プレフィックスリストのエントリの最大数は、リソースのルールまたはエントリの同じ数としてカウントされます。たとえば、最大エントリ数が 20 個のプレフィックスリストを作成し、セキュリティグループルール内でそのプレフィックスリストを参照する場合、セキュリティグループの 20 個のルールとしてカウントされます。

とあり、確かにきっちり書いてありました...

ハマってみた

ここまでいろいろ述べましたが言葉で説明するより実際に試してみる方が手っ取り早くわかりやすいでしょう。

セキュリティグループの場合

上限緩和申請していない個人検証アカウントで試します。
1セキュリティグループあたり最大60ルール設定可能です。

最初に最大ルール数をギリギリオーバーする最大エントリ61のプレフィックスリストを作成してみます。
ざっくり下図の様に作成します。

これで「最大エントリ61、使用エントリ1」のプレフィックスリストが出来上がりました。
続けて適当なセキュリティグループを新規作成し、インバウンドルールにこのプレフィックスリストを登録してみます。

すると1行しかないセキュリティグループなのに

The maximum number of rules per security group has been reached.

と最大数オーバーのエラーが出てしまいます。

次に上限ギリギリの「最大エントリ60、使用エントリ1」のプレフィックスリストを作ってみます。

これを先程のセキュリティグループに適用してみると、

無事登録できました。

さらにもう1ルール追加しようとするとエラーになってしまいます。

ルートテーブルの場合

ルートテーブルの場合はデフォルトで1ルートテーブル当たり最大50ルートまで設定可能です。

• Amazon VPC のクォータ

ただしルートテーブルの場合は必ず「localルート」が存在しますので最初は「最大エントリ50、使用エントリ1」のプレフィックスリストを作ってみます。

これを適当なルートテーブルに追加してみると、ちゃんと？最大数オーバーになります。

次に「最大エントリ49、使用エントリ1」のプレフィックスリストを作って、

ルートテーブルに追加してみると問題なく作成できましたが、

もう1エントリ追加しようとすると最大数オーバーとなってしまいます。

最後に

以上となります。

ドキュメントをちゃんと読んでない私が完全に悪いのですがこの仕様は正直つらいです。
私の想定してるユースケースでは設定時において最大数を予想しにくいものが多く、とりあえず多めの最大数を設定して運用したかったのですがそれは叶いませんでした。

1セキュリティグループ/ルートテーブルに設定可能なルール数はさほど多くありません。
最大エントリ数に余裕は持たせたいですが、余裕を持たせすぎると貴重なルール数を無駄に消費してしまいます。
余裕を持たせつつも極力無駄がない様にする慎重な設計が求められますので皆さんご注意ください。

ちょっと追記

ちなみにですが、ゲートウェイ型のVPCエンドポイント(S3およびDynamoDB)によって生成されるAWS管理のプレフィックスリストでは最大エントリ数の記載はありませんが 最大エントリ数=1と同等 という扱いになってました。

(上図はS3のVPCエンドポイントにより生成されたプレフィックスリストで登録されてるエントリは4つありますが消費されるルール数は常に1だけです)

【2022年2月】さらに追記

2022年になりCloudFrontで使用するCIDRをまとめたプレフィックスリストが追加されました。

それに合わせて各サービス毎で消費するルール数(重み)が公開されています。

• AWS-managed prefix list weight

こちらによればS3とDynamoDBは消費ルール数(重み)は1ですが、CloudFrontは55となっており1つのリストでかなりルール数を消費するのでご注意ください。