「カスタマー管理プレフィックスリスト」で IP 範囲をまとめ、 「AWS RAM」で他アカウントに共有すれば、
セキュリティグループやルートテーブルの IP 管理をたった 1 か所で一元管理できる。

📋 プレフィックスリストで
CIDRブロックをグループ化
🤝 AWS RAMで
他アカウントに共有
🔄 更新は1か所だけ
全アカウントに自動反映

🏢 全国チェーン店の「取引先連絡帳」で考えてみよう

あなたは全国にチェーン展開する会社の本部のネットワーク管理者です。
各支店(=各AWSアカウント)には、それぞれ「出入りを許可する取引先リスト」があります。
新しい取引先が増えるたびに、全支店に電話して「この会社を許可リストに追加して」と頼むのは大変ですよね?

そこで本部が「公式取引先連絡帳」を作り、全支店に配布します。
本部が連絡帳を更新すれば、全支店の許可リストが自動的に最新になる
これが「プレフィックスリスト × AWS RAM」のソリューションです!

🔗 たとえ話と実際のAWSサービスの対応表

たとえ話 AWSの実際 役割
公式取引先連絡帳 📋 カスタマー管理プレフィックスリスト CIDRブロック(IPアドレス範囲)をまとめたリスト
連絡帳に載っている取引先名と住所 🏠 プレフィックスリストのエントリ 個々のCIDRブロック(例: 10.0.0.0/16)
連絡帳を全支店に配る仕組み 🤝 AWS RAM(Resource Access Manager) リソースを他アカウント・OUに共有する仕組み
各支店 🏢 各AWSアカウント Organizations傘下のメンバーアカウント
支店の受付ルール 🛡️ セキュリティグループ / ルートテーブル プレフィックスリストを参照してアクセス制御
本部(管理者) 👑 ネットワーク管理アカウント(Owner) プレフィックスリストを作成・管理するアカウント

📋 プレフィックスリストとは?

複数のCIDRブロック(IPアドレス範囲)を1つのオブジェクトにまとめたものです。 セキュリティグループやルートテーブルで「このリストに載っているIP全部」と一括指定できます。

👤 カスタマー管理プレフィックスリスト
ユーザーが自分で作成・編集・共有できるプレフィックスリスト。 CIDRの追加・削除が自由にでき、AWS RAMで他アカウントへ共有可能。 バージョン管理もあり、過去の状態に復元できる。
☁️ AWS管理プレフィックスリスト
AWSが自動で提供するプレフィックスリスト。 S3やDynamoDB、CloudFrontなどのサービスのCIDRが自動更新される。 編集・共有は不可(読み取り専用)。

💡 ポイント:プレフィックスリストの「最大エントリ数」

プレフィックスリスト作成時に「最大エントリ数」を設定します。 セキュリティグループで参照する場合、この最大数がそのままルール数としてカウントされます。 例えば最大20エントリのプレフィックスリストを参照すると、実際のCIDR数に関わらず20ルール分を消費します。

🤝 AWS RAM(Resource Access Manager)とは?

自分のアカウントにあるAWSリソースを、他のアカウントやOU、組織全体と安全に共有するサービスです。 共有されたリソースは受取側のアカウントで直接参照できます。

RAMで共有できる主なリソース

📋 プレフィックスリスト
CIDRブロックのグループを他アカウントと共有
🌐 Transit Gateway
ネットワーク集約装置を共有して接続を集中管理
🔒 サブネット
VPCサブネットを他アカウントのリソースが利用可能に
📡 Route 53 Resolverルール
DNS解決ルールを他アカウントと共有

🗺️ 全体アーキテクチャ図:プレフィックスリスト × RAM

AWS Organizations 👑 管理アカウント(Owner) 📋 プレフィックスリスト pl-0123456abcdef 10.1.0.0/16 (本社) 10.2.0.0/16 (支店A) 172.16.0.0/12 (DC) 🤝 AWS RAM 共有 共有 共有 🏢 開発アカウント 🛡️ セキュリティグループ 参照: pl-0123456abcdef 🗺️ ルートテーブル 参照: pl-0123456abcdef 閲覧・参照のみ(編集不可) 🏢 本番アカウント 🛡️ セキュリティグループ 参照: pl-0123456abcdef 🗺️ ルートテーブル 参照: pl-0123456abcdef 閲覧・参照のみ(編集不可) 🏢 セキュリティアカウント 🛡️ セキュリティグループ 参照: pl-0123456abcdef 🗺️ ルートテーブル 参照: pl-0123456abcdef 閲覧・参照のみ(編集不可)

管理アカウントでプレフィックスリストを作成 → AWS RAMで共有 → 各アカウントのSG/ルートテーブルから参照

導入前 vs 導入後の比較

❌ 導入前:個別管理の世界

  • 新しいCIDR追加時、全アカウントのSGを手動更新
  • アカウントごとにCIDRがバラバラになるリスク
  • 拠点追加のたびに全アカウント巡回が必要
  • 設定ミスによるセキュリティホールの可能性
  • 変更履歴の追跡が困難

✅ 導入後:一元管理の世界

  • 管理アカウント1か所でCIDR更新するだけ
  • 全アカウントで常に同じCIDRセットを参照
  • 拠点追加はプレフィックスリストの1エントリ追加で完了
  • Ownerのみが編集可能でガバナンスが効く
  • バージョン管理で変更履歴を追跡可能

🔐 Owner と Consumer の権限の違い

操作 Owner(管理アカウント) Consumer(共有先アカウント)
プレフィックスリストの作成 ✅ 可能 ❌ 不可
エントリ(CIDR)の追加・削除 ✅ 可能 ❌ 不可
プレフィックスリストの閲覧 ✅ 可能 ✅ 可能
SG / ルートテーブルで参照 ✅ 可能 ✅ 可能
共有の管理(追加・解除) ✅ 可能 ❌ 不可
再共有(別アカウントへ) ✅ 可能 ❌ 不可

⚠️ 重要な制約

共有されたプレフィックスリストを別のアカウントにさらに再共有することはできません。 また、AWS管理プレフィックスリスト(S3やDynamoDB用など)はRAMで共有できません。 共有できるのは「カスタマー管理」のプレフィックスリストのみです。

🛠️ セットアップ手順(5ステップ)

1

プレフィックスリスト
を作成

2

CIDRエントリ
を追加

3

RAMリソース共有
を作成

4

共有先で
招待を承認

5

SG / RTで
参照設定

Step 1 & 2:プレフィックスリストの作成とCIDR追加(AWS CLI)

# プレフィックスリストを作成(最大エントリ数を指定)
aws ec2 create-managed-prefix-list \
    --prefix-list-name "corporate-networks" \
    --address-family "IPv4" \
    --max-entries 20 \
    --entries '[
        {"Cidr":"10.1.0.0/16","Description":"本社ネットワーク"},
        {"Cidr":"10.2.0.0/16","Description":"支店Aネットワーク"},
        {"Cidr":"172.16.0.0/12","Description":"データセンター"}
    ]'

# 作成されたプレフィックスリストのIDを確認
aws ec2 describe-managed-prefix-lists \
    --filters "Name=prefix-list-name,Values=corporate-networks"

Step 3:AWS RAM リソース共有の作成

# RAMリソース共有を作成し、プレフィックスリストを追加
aws ram create-resource-share \
    --name "shared-prefix-lists" \
    --resource-arns "arn:aws:ec2:ap-northeast-1:111111111111:prefix-list/pl-0123456abcdef" \
    --principals "arn:aws:organizations::111111111111:organization/o-example" \
    --allow-external-principals false

# Organizations全体に共有する場合、招待の承認は不要(自動承認)
# 個別アカウントへの共有の場合はStep 4で招待承認が必要

Step 5:セキュリティグループでプレフィックスリストを参照

# 共有先アカウントでセキュリティグループにルール追加
aws ec2 authorize-security-group-ingress \
    --group-id "sg-0abc123def456" \
    --ip-permissions '[{
        "IpProtocol": "tcp",
        "FromPort": 443,
        "ToPort": 443,
        "PrefixListIds": [{"PrefixListId": "pl-0123456abcdef"}]
    }]'

# ルートテーブルでプレフィックスリストを参照
aws ec2 create-route \
    --route-table-id "rtb-0abc123def456" \
    --destination-prefix-list-id "pl-0123456abcdef" \
    --transit-gateway-id "tgw-0abc123def456"

📄 CloudFormation テンプレート例

管理アカウント側:プレフィックスリスト + RAM共有の作成

AWSTemplateFormatVersion: "2010-09-09"
Description: "Prefix List + RAM Share"

Parameters:
  OrgArn:
    Type: String
    Description: "AWS Organizations ARN"

Resources:
  # プレフィックスリスト
  CorporatePrefixList:
    Type: AWS::EC2::PrefixList
    Properties:
      PrefixListName: "corporate-networks"
      AddressFamily: "IPv4"
      MaxEntries: 20
      Entries:
        - Cidr: "10.1.0.0/16"
          Description: "本社"
        - Cidr: "10.2.0.0/16"
          Description: "支店A"
        - Cidr: "172.16.0.0/12"
          Description: "データセンター"

  # RAM リソース共有
  PrefixListShare:
    Type: AWS::RAM::ResourceShare
    Properties:
      Name: "shared-corporate-prefixes"
      AllowExternalPrincipals: false
      Principals:
        - !Ref OrgArn
      ResourceArns:
        - !GetAtt CorporatePrefixList.Arn

💡 代表的なユースケース

🏢 拠点CIDRの一元管理

全国の拠点のIPアドレス範囲を1つのプレフィックスリストにまとめ、全アカウントのセキュリティグループで参照。 新拠点追加時はエントリ1つ追加するだけで全アカウントに反映。

🔒 ホワイトリスト管理

信頼できるパートナー企業のIPレンジを管理。取引先が変わっても管理アカウント側で1回更新すれば、 全環境のアクセス制御が即座に更新される。

🌐 ハイブリッド接続のルーティング

オンプレミスのCIDRブロックをプレフィックスリストにまとめ、 各アカウントのルートテーブルでTransit GatewayやVPN先のルートとして一括設定。

🚫 ブロックリストの共有

既知の不正IPアドレス範囲をプレフィックスリストにまとめ、 全アカウントのNACLやNetwork Firewallのルールで参照して一括ブロック。

🔄 CIDR追加時の更新フロー

新しい支店(10.3.0.0/16)が追加された場合の流れを見てみましょう。

① 管理者が更新 プレフィックスリストに 10.3.0.0/16 を追加 (新バージョン作成) 自動 ② RAM経由で伝播 共有先アカウントの プレフィックスリスト参照が 最新バージョンに更新 🏢 開発アカウント → SG更新済 🏢 本番アカウント → SG更新済 🏢 セキュリティ → SG更新済 ✨ ポイント:管理者は1回の操作で済み、各アカウントでの手動更新は一切不要! 参照先は常に最新バージョンのプレフィックスリストを自動的に使用します

ベストプラクティス

📏 最大エントリ数は余裕を持って設定
現在のCIDR数ギリギリではなく、将来の拡張を見越して余裕を持たせる。 ただしSGのルール上限に影響するため大きすぎにも注意。
📁 用途ごとにリストを分離
「社内拠点用」「パートナー用」「ブロック用」のように目的別にプレフィックスリストを分ける。 命名規則を統一し管理しやすくする。
🏗️ IaCで管理する
CloudFormationやTerraformでプレフィックスリスト+RAM共有を管理。 コード化することで変更履歴が残り、レビュープロセスも組み込める。
🔍 変更前にAssociationsを確認
エントリ削除前に、どのリソースがそのプレフィックスリストを参照しているかを必ず確認。 想定外の通信断を防ぐ。

⚠️ 注意点とトラブルシューティング

🚨 リージョン制限

プレフィックスリストは作成したリージョンでのみ利用可能です。 東京リージョン(ap-northeast-1)で作ったプレフィックスリストは、大阪リージョン(ap-northeast-3)では使えません。 マルチリージョン展開する場合は、各リージョンにプレフィックスリストを作成してください。

⚠️ IPv4 / IPv6 は混在不可

1つのプレフィックスリストにIPv4とIPv6のCIDRを混在させることはできません。 IPv4用とIPv6用を別々のプレフィックスリストとして作成する必要があります。

⚠️ 削除時の注意

プレフィックスリストを削除するには、まずすべてのリソース(SGやルートテーブル)からの参照を解除する必要があります。 RAMで共有している場合は、共有先アカウントでの参照も含みます。

💡 Organizations内共有なら招待承認は不要

AWS Organizations内でRAM共有を有効化している場合、組織内のアカウントへの共有は自動承認されます。 外部アカウントへの共有のみ、招待の承認が必要です。

よくある質問(FAQ)

🤔 プレフィックスリストの更新中にダウンタイムはある?
ありません。プレフィックスリストの更新はアトミック操作で、新しいバージョンとして作成されます。 参照先のリソースは自動的に最新バージョンに切り替わるため、通信が途切れることはありません。
🤔 共有先のアカウントがプレフィックスリストを勝手に変更できる?
できません。Consumer(共有先)はプレフィックスリストの閲覧と参照のみが可能です。 エントリの追加・削除・編集はOwner(管理アカウント)のみが行えます。 これにより、確実なガバナンスが保たれます。
🤔 RAMで共有を解除したら、既存の参照はどうなる?
共有解除後も、Consumer側で既に設定されたSGルールやルートは引き続き機能します。 ただし、Consumerはプレフィックスリストの内容を閲覧できなくなり、新しい参照を追加することもできなくなります。 Ownerがプレフィックスリストを更新した場合、既存の参照には引き続き反映されます。
🤔 プレフィックスリストに追加料金はかかる?
追加料金はかかりません。プレフィックスリストの作成・共有ともに無料です。 AWS RAMによる共有にも追加料金は発生しません。
🤔 間違えてCIDRを削除してしまったら復元できる?
バージョンを使って復元できます。プレフィックスリストには変更のたびにバージョンが作成されます。 restore-managed-prefix-list-version コマンドで過去のバージョンに戻すことが可能です。

📋 プレフィックスリスト × 🤝 AWS RAM
= マルチアカウント環境でのIP管理の最適解

「全国チェーン店の取引先連絡帳」のように、本部(管理アカウント)が1つのリストを管理し、 全支店(各アカウント)に配布する。更新は本部が1回行うだけで、 全支店のセキュリティルールが自動的に最新化される。 コスト追加なし、ダウンタイムなしで、ガバナンスの効いたネットワーク管理を実現しましょう。

Created by SSuzuki1063

AWS SAP Learning Resources