AWS Direct Connect パブリック VIF で Amazon Connect を閉域化する際の Prefix List 設計ノート

この記事で分かること

AWS Direct Connect の パブリック VIF で Amazon Connect の通信だけを閉域化する構成の考え方
Amazon Connect の通信が3系統に分かれること（音声/シグナリング/管理URL）
DX 経由で全通信を閉域化するには Amazon CloudFront の IP レンジも経路制御が必要なこと
CloudFront GLOBAL のルート数が膨大で、全登録は現実的でないこと
実際の Prefix List 構成例

はじめに

ある構築案件で、オンプレミスのコールセンターを Amazon Connect へ移行しました。音声通信の品質を担保するため、インターネットではなく AWS Direct Connect（閉域網）経由で Amazon Connect に接続する構成です。

Amazon Connect はパブリック AWS サービスなので、DX 経由で接続するには DX パブリック VIF（Public Virtual Interface） が必要です。DX パブリック VIF 自体、プライベート VIF と比べて採用されるケースが限られます。

通常の DX 構成（プライベート VIF）では、下記の通り、VGW を経由して VPC 内のリソースに接続します。

一方、今回の構成（パブリック VIF）では、VPC を経由せず AWS のパブリックサービスに直接接続します。

さらに今回は、DX パブリック VIF で受信する全 AWS パブリック IP 経路のうち、Amazon Connect 関連の通信だけを DX 経由にしたいという要件でした。DX パブリック VIF は接続すると AWS の全パブリック IP プレフィックスが BGP で広告されてくるため、閉域網接続サービス側の Prefix List で必要なルートだけをフィルタリングする設計が必要です。

AWS も AWS Direct Connect for Amazon Connect というホワイトペーパーを公開しており、この構成パターン自体は公式に想定されています。ただし、このホワイトペーパーは2022年11月公開で、現在は「historical reference only」の注記がついています。

基本的な構成パターンの参考にはなりますが、最新の設定値は CCP のネットワーク設定を参照するほうが良かったです。

実際に構築した事例の情報は少なく、設計時に悩むポイントが多々ありましたので、記録しておこうと思います。

当初、「Amazon Connect の IP レンジを DX で通せばいいんでしょ?」と思っていたのですが、実際にはそれだけでは足りませんでした。

Amazon Connect の通信は3系統ある

Amazon Connect の CCP（Contact Control Panel）が利用する通信は、大きく3つに分かれます。

通信種別	プロトコル	経由サービス	ip-ranges.json の service
音声メディア（TURN/SRTP）	UDP 3478（TURN）	Amazon Connect	`AMAZON_CONNECT`
CCP シグナリング/静的コンテンツ	HTTPS (TCP 443)	Amazon Connect シグナリングエンドポイント（EC2 IP レンジ）/ Amazon CloudFront	`EC2` / `CLOUDFRONT`
管理 URL アクセス	HTTPS (TCP 443)	Amazon CloudFront	`CLOUDFRONT`

公式ドキュメントの CCP のネットワーク設定にも記載がありますが、CloudFront は GLOBAL のエッジロケーションから静的コンテンツを配信するため、ip-ranges.json ベースで検討を行う際には、リージョン指定だけでは不十分です。

ポイントは、Amazon Connect の IP レンジだけでなく、EC2 と CloudFront の IP レンジも DX 経由にする必要があるということです。

経路制御の対象を整理する

Amazon Connect（AMAZON_CONNECT）

ip-ranges.json で "service": "AMAZON_CONNECT" かつ対象リージョンのエントリを抽出します。アジアパシフィック（東京）リージョン（ap-northeast-1）の場合、15.193.1.0/24 と 18.182.96.64/26 の2つが該当します（2026年4月時点）。

なお、公式ドキュメントの Option 2 では、AMAZON_CONNECT について「GLOBAL AND any region-specific entry」の両方を許可リストに含めるよう記載されています。GLOBAL エントリは 15.193.0.0/19 で、東京リージョンの上記2つはこの /19 に包含されます。より安全を期すなら GLOBAL の 15.193.0.0/19 を orlonger で登録する方が望ましいです。本案件では東京リージョンのエントリのみで運用し、ip-ranges.json の変更を定期的に追従する運用としました。

EC2（CCP シグナリング用）

CCP のシグナリング通信は EC2 エンドポイント経由です。"service": "EC2" かつ "region": "ap-northeast-1" のエントリを抽出します。

ただし、EC2 の IP レンジは AMAZON_CONNECT や CLOUDFRONT と比べて桁違いに広いです。東京リージョンだけでも数十エントリあり、/14 〜 /24 まで粒度もバラバラです。全部を Prefix List に登録するのは現実的ではないので、実際に CCP が通信するエンドポイントの IP が属するレンジだけに絞る必要があります。

具体的な特定手順は以下の通りです。

CCP のシグナリングエンドポイント（rtc*.connect-telecom.ap-northeast-1.amazonaws.com 等）の FQDN を DNS 名前解決する
解決先の IP アドレスを取得する
その IP が ip-ranges.json のどの EC2 エントリに属するかを照合する
該当するエントリの上位レンジ（/14 等）を特定する

本案件では、この手順で 13.112.0.0/14、52.196.0.0/14、57.180.0.0/14 の3つに絞り込みました。

CloudFront 東京リージョン（CLOUDFRONT）

CCP の静的コンテンツ配信は CloudFront 経由です。"service": "CLOUDFRONT" かつ "region": "ap-northeast-1" のエントリを抽出します。東京リージョンは以下の5エントリです（2026年4月時点）。

13.113.196.64/26
13.113.203.0/24
52.199.127.192/26
57.182.253.0/24
57.183.42.0/25

数が少ないので、そのまま Prefix List に登録します。

なお、2026年4月時点ではこれらは EC2 の上位レンジ（13.112.0.0/14 等）にたまたま包含されていましたが、この包含関係が将来も維持される保証はありません。ip-ranges.json の公式ドキュメントでもサービス間の包含関係は明示されていないため、CloudFront 東京は EC2 とは別に個別登録しておく方が安全です。

CloudFront GLOBAL ― ここが問題

管理用 URL（*.my.connect.aws 等）の名前解決先は CloudFront の GLOBAL エッジロケーションです。

公式ドキュメントにも以下の記載があります。

IP range allowlists for CloudFront are global and require all IP ranges associated with "service": "CLOUDFRONT" in ip-ranges.json.

ところが、DX パブリック VIF では AWS サービスの IP レンジが一括で広告されます。閉域網接続サービスのルーター上で確認したところ、GLOBAL のレンジが非集約（de-aggregated）状態で約5,047ルートとして BGP 広告されていました。ip-ranges.json 上の CLOUDFRONT エントリ数（約130件）とは大きく乖離しており、全ルートを Prefix List に登録するのは非現実的でした。

CloudFront GLOBAL はどう絞るか

全ルート登録が無理なら、実際に使う FQDN に限定して経路制御する方針に切り替えました。

具体的には：

管理用 URL（例: example.my.connect.aws）の DNS 名前解決を行う
解決先の CloudFront IP アドレスが属するレンジを特定する
そのレンジだけを orlonger（指定プレフィックスと同じか、より詳細な longer prefix のルートにマッチする条件。Juniper の prefix-list における表現で、Cisco では le 32 等が相当）で Prefix List に登録する

exact ではなく orlonger を使うのは、CloudFront のエッジロケーション IP が変わっても、上位のレンジ内であれば追従できるようにするためです。

実際の Prefix List 構成例

最終的に設定した Prefix List の構成例です（東京リージョン）。

注意: 以下の IP レンジは本記事の執筆にあたり 2026年4月時点の ip-ranges.json から取得したもので、実際に設定した値とは異なります。ip-ranges.json は随時更新されるため、設計・構築時には必ず最新の値を確認してください。

対象	ip-ranges.json の service	IPレンジ	フィルタールール
Amazon Connect (東京)	AMAZON_CONNECT	15.193.1.0/24	exact
Amazon Connect (東京)	AMAZON_CONNECT	18.182.96.64/26	exact
EC2 (東京)	EC2	13.112.0.0/14	exact
EC2 (東京)	EC2	52.196.0.0/14	exact
EC2 (東京)	EC2	57.180.0.0/14	exact
CloudFront (東京)	CLOUDFRONT	13.113.196.64/26	exact
CloudFront (東京)	CLOUDFRONT	13.113.203.0/24	exact
CloudFront (東京)	CLOUDFRONT	52.199.127.192/26	exact
CloudFront (東京)	CLOUDFRONT	57.182.253.0/24	exact
CloudFront (東京)	CLOUDFRONT	57.183.42.0/25	exact
CloudFront (GLOBAL) 本番用	CLOUDFRONT	99.86.0.0/16	orlonger
CloudFront (GLOBAL) 開発用	CLOUDFRONT	3.173.192.0/18	orlonger

EC2 の3行は、CCP シグナリングエンドポイント（rtc*.connect-telecom.ap-northeast-1.amazonaws.com 等）の DNS 名前解決結果から特定したレンジです。CloudFront 東京の5行は ip-ranges.json から直接抽出したものです。

IP レンジは ip-ranges.json から取得したものです。ip-ranges.json は随時更新されるため、定期的な確認が必要です。

なお、公式ドキュメントでは IP レンジによる許可リスト方式（Option 2）は推奨されておらず、ドメイン許可リスト方式（Option 1）が推奨されています。ただし、DX パブリック VIF の経路制御は BGP の Prefix List（IP プレフィックス単位）で行うため、ドメインベースの Option 1 は経路フィルタリングには適用できません。本案件では Option 2 を採用しました。

また、同一拠点から Amazon Connect 以外の EC2（自社の EC2 インスタンス等）にもアクセスしている場合、EC2 の /14 レンジを Prefix List に登録すると、Connect 以外の EC2 通信も DX 経由になります。BGP の経路制御は IP プレフィックス単位なので、同一レンジ内で「Connect 向けだけ DX、それ以外はインターネット」という分離はできません。この点は設計時にネットワーク全体のトラフィックフローを考慮する必要があります。

まとめ

当初は「Amazon Connect の IP レンジを DX で通せばいいんでしょ？」くらいに思っていたんですが、実際にはシグナリング（EC2）と CloudFront の経路制御まで必要で、特に CloudFront GLOBAL の扱いが一番の難所でした。

BGP 広告されるルート数が ip-ranges.json のエントリ数と全然違う、というのも設計段階では想定していなかったポイントです。ホワイトペーパーや公式ドキュメントだけでは辿り着けない部分が多く、実機で BGP テーブルを見て初めて分かることがかなりありました。

CloudFront GLOBAL を DNS 解決ベースで絞る手法も、正直ベストとは言い切れません。CloudFront が別のプレフィックスブロックにルーティングを変えたら orlonger でも追従できないリスクは残ります。それでも、5,047ルートを全登録するよりは現実的な落としどころだったかなと。

ip-ranges.json は随時更新されるので、Prefix List は「一度設定して終わり」ではなく継続的なメンテナンスが必要です。手動で定期確認する運用だと、変更に気づくのが遅れて通信断につながるリスクがあります。AWS は ip-ranges.json の変更を SNS トピック（arn:aws:sns:us-east-1:806199016981:AmazonIpSpaceChanged）で通知しているので、これを起点に変更検知 → Prefix List の差分チェックくらいは自動化しておかないと、運用負荷的にきついと思います。

この辺りの運用設計も含めて、同じ構成を検討している方の参考になれば幸いです。