プレフィックスリストってなんなの？AWS公式ドキュメントで根本まで深堀りしてみた

Posted at 2026-06-13

どーも！shihopowerです！今回はプレフィックスリストについてお話します。SAP対策をしているとプレフィックスリストに関する問題が出てきて、「プレフィックスリストってなんやったっけ…」状態に。おさらいを兼ねてAWS公式ドキュメントだけを頼りに根本まで深堀りしてみました。「なんとなくわかってる」から「なぜそうなのか説明できる」を目指します！

本記事はAWS公式ドキュメントを参照して解説しています。

忙しい人向けの要約

プレフィックスリストとは「複数のCIDRブロックをひとまとめにしたオブジェクト」
セキュリティグループのルールの送信元・送信先指定にIDを使える
リストを更新するだけで、参照しているすべてのセキュリティグループに自動反映される
AWS RAMで組織全体に共有でき、マルチアカウント環境のCIDR一元管理に強い
ネットワークACLのルールでは参照できない（CIDRの直書きのみ）
S3向けのAWSマネージドプレフィックスリストが存在し、ゲートウェイエンドポイントと組み合わせて使える

そもそもCIDR範囲ってなに？
プレフィックスリストとは
プレフィックスリストはどこに作成されるのか
セキュリティグループとプレフィックスリストの関係
プレフィックスリストが効果的な場面
プレフィックスリストとS3の関係
ネットワークACLで参照できない理由
SAPで出てくるユースケース
まとめ

1. そもそもCIDR範囲ってなに？

プレフィックスリストを理解するには、まずCIDRを押さえておく必要があります。

CIDR（Classless Inter-Domain Routing）は、IPアドレスの範囲を表記する方式です。

表記例	意味
`10.0.0.0/8`	10.x.x.x のすべてのIPアドレス（約1,677万個）
`192.168.0.0/16`	192.168.x.x のすべてのIPアドレス（約6.5万個）
`203.0.113.1/32`	203.0.113.1 の1つだけ

セキュリティグループやルートテーブルでは、通信を許可・拒否する相手のIPアドレス範囲をこのCIDRで指定します。

2. プレフィックスリストとは

A managed prefix list is a set of one or more CIDR blocks.
（AWS公式ドキュメント）

一言で言えば、複数のCIDRブロックをひとまとめにしたオブジェクトです。

よく使うIPアドレスをプレフィックスリストにまとめておくことで、セキュリティグループルールやルートテーブルの設定・管理が格段に楽になります。

2種類のプレフィックスリスト

プレフィックスリストには2種類あります。

種類	説明	作成・変更
カスタマーマネージド	自分で定義・管理するCIDRのセット。他アカウントと共有可能	✅ できる
AWSマネージド	AWSサービスのIPアドレス範囲。AWSが管理・更新	❌ できない

AWSマネージドプレフィックスリストの例：

AWSサービス	プレフィックスリスト名
Amazon S3	`com.amazonaws.{region}.s3`
Amazon DynamoDB	`com.amazonaws.{region}.dynamodb`
Amazon CloudFront	`com.amazonaws.global.cloudfront.origin-facing`

CloudFrontのIPアドレスは定期的に変わりますが、AWSマネージドプレフィックスリストを使えばAWSが自動で最新状態に維持してくれます。手動でIP管理する必要がなくなるので非常に便利です。

3. プレフィックスリストはどこに作成されるのか

プレフィックスリストは 「AWSアカウント」の「リージョン」内 に作成されます。

重要な制約：プレフィックスリストはリージョンをまたげない

公式ドキュメントには「A prefix list applies only to the Region where you created it.」と明記されています。東京リージョンで作成したプレフィックスリストは、バージニアリージョンでは使えません。複数リージョンで使いたい場合は、リージョンごとに作成が必要です。

作成手順（コンソール）はシンプルです。

Amazon VPCコンソールを開く
ナビゲーションペインで「Managed Prefix Lists」を選択
「Create prefix list」をクリック
プレフィックスリスト名・最大エントリ数・アドレスファミリー（IPv4/IPv6）・CIDRブロックを入力して作成

4. セキュリティグループとプレフィックスリストの関係

セキュリティグループの基本

セキュリティグループは、関連付けられたリソースに到達・離脱するトラフィックを制御する仮想ファイアウォールです。インバウンドルール（受信）とアウトバウンドルール（送信）それぞれに、送信元・送信先・ポート範囲・プロトコルを指定します。

送信元・送信先の指定手段

セキュリティグループルールの送信元（インバウンドルール）または送信先（アウトバウンドルール）には以下のいずれかを指定できます。

単一のIPv4アドレス（例：203.0.113.1/32）
単一のIPv6アドレス
CIDRブロック（例：10.0.0.0/8）
プレフィックスリストのID（例：pl-1234abc1234abc123）
セキュリティグループのID

プレフィックスリストIDは、CIDRやセキュリティグループIDと並ぶ正式な指定手段の一つです。

プレフィックスリストIDを使う利点

① 複数CIDRを1つのルールに集約できる

社内拠点のIPが5つあれば、通常はセキュリティグループに5行のルールが必要です。プレフィックスリストを使えば1行で済みます。

② CIDR変更時にすべての参照先が自動更新される

プレフィックスリストのCIDRを更新すると、そのIDを参照しているすべてのセキュリティグループが自動的に更新されます。CIDRを直書きしていた場合は、すべてのセキュリティグループを一つひとつ手動で修正しなければなりません。

③ 変更はすべての関連リソースに即時適用される

公式ドキュメントより：

When you add, update, or remove rules, your changes are automatically applied to all resources associated with the security group.

注意点：ルール数カウントへの影響

プレフィックスリストを参照する場合、セキュリティグループの最大ルール数へのカウント方法が通常と異なります。

指定方法	ルール数カウント
CIDRブロック	1ルール
セキュリティグループID	1ルール
カスタマーマネージドプレフィックスリスト	最大エントリ数分（例：最大20エントリなら20ルール分）
AWSマネージドプレフィックスリスト	ウェイト分（例：S3のウェイトは1、CloudFrontは55）

CloudFrontのプレフィックスリストを参照する場合、デフォルトのルール上限60に対して55ルール分を消費するため、残り5ルールしか追加できなくなります。クォータへの影響を事前に確認しましょう。

5. プレフィックスリストが効果的な場面

① 同じCIDRを多くのセキュリティグループルールで繰り返し使っている

オンプレミス拠点のIPアドレス帯をセキュリティグループで許可している場合などが典型例です。拠点が増えるたびにすべてのセキュリティグループを修正するのは大変ですが、プレフィックスリストを使えばリスト1つの更新で完結します。

② 複数のAWSアカウントで共通ルールを適用したい（AWS RAMとの組み合わせ）

AWS Resource Access Manager（RAM）を使うことで、プレフィックスリストを組織内の他アカウントと共有できます。

共有の粒度は柔軟で、以下から選べます。

特定のAWSアカウント（組織内外問わず）
特定のOU（組織単位）
組織全体

プレフィックスリストの共有に追加料金は発生しません。

共有後の権限は以下のように分かれます。

役割	できること	できないこと
所有者（Owner）	プレフィックスリストの作成・編集・削除	コンシューマーのリソース内の参照を変更
コンシューマー	プレフィックスリストの参照・閲覧	プレフィックスリストの変更・削除

コンシューマーはプレフィックスリストを参照してセキュリティグループルールに設定できますが、リスト自体を変更することはできません。これが「開発者はセキュリティグループに新しいCIDRを追加できるが、共通の許可リスト自体は変更できない」という要件を実現する仕組みです。

③ セキュリティグループ以外にも同じIPセットを使いたい

プレフィックスリストは以下のリソースから参照できます。

VPCセキュリティグループ
サブネットルートテーブル
Transit Gatewayルートテーブル
AWS Network Firewallルールグループ
Amazon Managed Grafanaネットワークアクセスコントロール
AWS Outpostsラックローカルゲートウェイ

同じIPセットをセキュリティグループとルートテーブルの両方で参照させることができます。

6. プレフィックスリストとS3の関係

S3向けAWSマネージドプレフィックスリスト

S3にはAWSが管理するプレフィックスリストが用意されています。

対象	プレフィックスリスト名	ウェイト
Amazon S3（通常）	`com.amazonaws.{region}.s3`	1
Amazon S3 Express One Zone	`com.amazonaws.{region}.s3express`	6

S3ゲートウェイエンドポイントとの連携

VPC内のEC2インスタンスからS3へアクセスする際に使う「S3ゲートウェイエンドポイント」と、プレフィックスリストは密接に関係します。

ゲートウェイエンドポイント経由でS3にアクセスするインスタンスのセキュリティグループでは、S3のプレフィックスリストIDをルールに指定できます。これにより、S3のIPアドレスをCIDRで直書きする必要がなくなります。

ネットワークACLでは参照できないという制限

設定箇所	プレフィックスリストIDの参照	代替手段
セキュリティグループのルール	✅ できる	—
ネットワークACLのルール	❌ できない	プレフィックスリストからIPアドレス範囲を取得し手動で記載

公式ドキュメントより：

You can't reference prefix lists in network ACL rules, but you can get the IP address range for Amazon S3 from the prefix list for Amazon S3.

ネットワークACLでは参照できませんが、プレフィックスリストの中身（CIDRの一覧）を確認して、それをネットワークACLに手動で記載することは可能です。

7. ネットワークACLで参照できない理由

公式ドキュメントはこの制限の技術的な理由を明示していません。ただし、両者の設計思想の違いから背景を読み解くことができます。

ネットワークACLのルール構造

公式ドキュメントによれば、ネットワークACLのルールを構成する要素は以下の通りです。

ルール番号
タイプ（例：SSH）
プロトコル
ポート範囲
送信元・送信先（CIDR範囲）
許可／拒否

送信元・送信先は「CIDR範囲」と明記されており、プレフィックスリストIDを受け付ける設計になっていません。

セキュリティグループとネットワークACLの設計思想の違い

特性	セキュリティグループ	ネットワークACL
動作レベル	インスタンスレベル	サブネットレベル
ルール種別	許可ルールのみ	許可と拒否の両方
ステート	ステートフル（戻りの通信を自動許可）	ステートレス（戻りの通信も明示的に許可が必要）
ルール評価	すべてのルールを評価	番号順に評価し最初に一致したルールを適用
プレフィックスリスト参照	✅ できる	❌ できない
位置づけ	主役（主要なアクセス制御）	補助役（粗粒度のサブネットガードレール）

公式ドキュメントでは、セキュリティグループを「主要な制御手段」、ネットワークACLを「補助的な制御」と位置づけています。プレフィックスリストのような動的な参照機能は、より高機能な制御を担うセキュリティグループ側に集約されている、という設計です。

8. SAPで出てくるユースケース

SAP対策をしていて私が実際に出会った問題を1つ紹介します。

問題の要件

AWS Organizations配下に多数のAWSアカウントがある
組織全体のセキュリティグループに共通のCIDR（オンプレミスネットワークのIP）を適用したい
CIDRが変わったときは自動で全アカウントに反映したい
開発者はセキュリティグループに追加のCIDRを足せるが、共通リストを勝手に変更・削除はできない
最小の運用オーバーヘッドで実現

正解のアーキテクチャ（選択肢C）

セキュリティチームのAWSアカウント
    ↓ カスタマーマネージドプレフィックスリストを1つ作成
      （内部CIDRをすべて登録）
    ↓ AWS RAMで「組織全体」に共有

各開発者アカウント
    → セキュリティグループのルールにプレフィックスリストIDを参照として設定

[CIDR変更時]
セキュリティチームがプレフィックスリストを更新するだけ
    → 全アカウントの参照先が自動的に最新状態になる
    → 各アカウントでの作業は不要

他の選択肢がNGな理由

選択肢	NGな理由
SNS + 各アカウントにLambda	LambdaとSNSの管理コストが増加。継続的な運用負荷が発生
各アカウントに個別のプレフィックスリストを作成	CIDR変更のたびに全アカウントで手動更新が必要。最小運用オーバーヘッドに反する
各アカウントにIAMロール + Lambdaでセキュリティグループを更新	複数アカウントのIAMロール管理やLambdaの管理が複雑。セキュリティリスクも増加

9. まとめ

テーマ	ポイント
定義	複数のCIDRブロックをひとまとめにしたオブジェクト
作成場所	AWSアカウントのリージョン内（リージョンをまたげない）
種類	カスタマーマネージド（自作）/ AWSマネージド（S3・CloudFront等）
セキュリティグループとの関係	インバウンド・アウトバウンドルールの送信元・送信先にIDを指定できる
自動更新	リストを更新すると参照しているすべてのセキュリティグループに自動反映
マルチアカウント	AWS RAMで組織全体・OU・特定アカウントに共有可能（追加料金なし）
ネットワークACL	プレフィックスリストIDを参照できない（CIDRの直書きのみ）
S3との関係	S3向けAWSマネージドプレフィックスリストあり。ゲートウェイエンドポイントのセキュリティグループルールに使える

プレフィックスリストは「ただのCIDRのグループ」ではなく、変更が自動伝播する仕組みとアカウント間共有が組み合わさることで、大規模なマルチアカウント環境のネットワーク管理を大幅に簡素化してくれる機能です。SAPの試験でも「最小運用オーバーヘッド」がキーワードになっているときはプレフィックスリスト + AWS RAMの組み合わせを疑ってみてください！

参考

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up