公開2024.08.30更新2026.10.18 27 人が閲覧（直近 30 日）インフラ・クラウド

ホットポテトルーティングとは？コールドポテトルーティングとの違い・BGPでの実装とクラウド3社の設定

ホットポテトルーティングは、外部宛てのトラフィックを自網の出口のうち最も近いところで隣の網へ渡すルーティングポリシーです。対になるコールドポテトルーティングは、宛先に最も近い出口まで自網で運んでから渡します。もとは ISP どうしのピアリング設計の用語で、いまは Azure のパブリック IP の「ルーティング設定」や Google Cloud の Network Service Tiers でどちらを選ぶか、という形で出会うことが多い語です。BGP のどの比較でこの差が生まれるかを FRRouting で再現した結果と、クラウド3社での対応、既定のコールドポテトが逆に遅くなる条件までをまとめました。

まとめ

ホットポテト＝closest exit。送信元に近い出口で手放し、残りの区間は相手網に運ばせる。多くの ISP の通常の挙動。
コールドポテト＝best exit。相手網が「宛先に近い」と広告した出口まで自網で運ぶ。品質を自分で握れる代わりに輸送を負担する。
BGP 上の差は、隣接 AS が付けた MED の差を自網内の出口選択に持ち込むかどうか。持ち込まなければ RFC 4271 の比較順で MED の次に来る「EBGP 優先」と「IGP コスト」で出口が決まり、ホットポテトになる。
両網がそろってホットポテトだと、往路と復路で別の接続点を通る非対称経路になりやすい。片方がコールドポテトなら経路は対称に近づく。
ホットポテトの出口は自網の IGP コストで決まるため、社内のリンク1本のコスト変更で外向きの出口が切り替わる。FRR の実測でも、隣接 AS が何も変えずに出口が移った。
Azure と Google Cloud は既定がコールドポテト側（Microsoft グローバルネットワーク、Premium Tier）。AWS は通常の通信に切り替えの選択肢がない。Global Accelerator は公開アプリケーションへのクライアント接続を最寄りのエッジから AWS 網に乗せる機能で、外向き通信の出口は変えない。
宛先が同じ都市の別クラウドや国内 ISP に集中しているなら、ホットポテト側の方が速く安いことがある。ただし Azure のパブリック IP はルーティング設定を変更できず、Google Cloud も同じ外部 IP のままティアを変更できないため、移行には別の IP アドレスが必要になる。

ホットポテトとコールドポテトの出口の選び方

どちらも、複数の地点で相互接続している自律システム（AS）どうしで「外部宛てのパケットをどの接続点から手放すか」を決めるポリシーです。RFC 4451 の 2.2節「MEDs and Potatoes」は、素手で持った熱いジャガイモのように誰もがすぐ手放したがる、という比喩で hot potato routing を説明しています。

ホットポテトルーティング＝送信元に最も近い出口（closest exit）

RFC 4451 は、ホットポテトを「隣接するトランジット網への最寄りのピアリングにトラフィックを送る」方式とし、これにより経路を担う事業者のトランジットトラフィックが最小になると書いています。自網内を運ぶ距離が短いので、バックボーンの帯域と輸送コストを抑えられます。代わりに、相手網に渡したあとの経路品質・輻輳・障害は自分の制御外になります。

コールドポテトルーティング＝宛先に最も近い出口（best exit）

コールドポテトは、相手網が「宛先に最も近い」と広告した接続点まで、自網のトランジット容量を使って運ぶ方式です。RFC 4451 はこれを「far less common（はるかに少ない）」と書き、広く使われた例として1990年代半ばの NSFNET を挙げています。いまこの方式を前面に出しているのは、世界規模のバックボーンを自前で持つ大手クラウドです。

観点	ホットポテト	コールドポテト
別名	closest exit	best exit
出口の選び方	送信元に最も近い出口	宛先に最も近い出口
BGP での実装	MED を IBGP に渡さない	MED を IBGP に渡す
自網内の輸送距離	短い	長い
経路品質の制御	相手網任せ	自網で握れる
Azure・Google Cloud	安い選択肢	既定

どちらが速いかに一般解はありません。利用者と自社のリージョンが遠いほどコールドポテトが効き、近いほど差は縮み、後で触れる条件では逆転します。

BGP の出口選択と MED・IGP コストの役割

ルータの設定に「ホットポテト」というスイッチがあるわけではありません。差を生むのは、隣接 AS から EBGP で受け取った MULTI_EXIT_DISC（MED）の扱いと、BGP の最良経路選択の比較順です。

RFC 4271 における MED・EBGP 優先・IGP コストの比較順

RFC 4271 の 9.1.2.2節は、同じ宛先に優先度の並んだ経路が複数あるとき、AS_PATH の長さ（a）、ORIGIN（b）に続けて、次の順で候補を減らすと定めています。

c）MED：同じ隣接 AS から学習した経路どうしで、MED の大きい方を外す。
d）EBGP 優先：候補に EBGP で受けた経路が1本でもあれば、IBGP で受けた経路を外す。
e）IGP コスト：NEXT_HOP までの内部コスト（interior cost）が大きい経路を外す。

MED が IBGP で運ばれてくれば c の段で「相手が宛先に近いと言った出口」が勝ちます。これがコールドポテトです。MED が消されていれば c では差がつかず、自分が出口ルータなら d で自分の EBGP 経路が、内側のルータなら e で IGP コストの小さい出口が選ばれます。これがホットポテトです。RFC 4451 の言い方では、ホットポテトは「EBGP で学習した MED を IBGP に渡さないこと」、コールドポテトは「渡すこと」で実現されます。

c の段には落とし穴があります。MED は同じ隣接 AS から学習した経路どうしでしか比べません。複数の上流から同じ宛先を受けていると、MED を渡していても意図した出口に寄らないことがあります。RFC 4451 は、商用網の多くが MED を顧客とは交換しても対等ピアとは交換していないと書いています。

両網のホットポテト運用による往復経路の非対称性

網 X と網 Y が東京と大阪の2か所で接続し、X の利用者は東京、Y の利用者は大阪にいるとします。両網がホットポテトなら、X から Y への往路は送信元に近い東京の接続点で Y に渡り、Y から X への復路は大阪の接続点で X に渡ります。往路と復路で別の接続点を通るわけです。RFC 4451 も、両事業者がそろってホットポテトか、そろってコールドポテトなら非対称が大きくなりやすく、片方がホットで片方がコールドなら経路は対称に近づくとしています。片方が宛先側の接続点まで運ぶので、往復とも同じ接続点に寄るからです。

実務では、片方向の traceroute だけを見て経路を判断しないことが要点です。復路は相手網のポリシーで決まるので、遅延の切り分けでは両端から traceroute を取って比べます。ISP 区間の切り分け手順はpingとpathpingで自宅かISPかを切り分ける方法で扱っています。

FRRouting で再現：出口が切り替わる3つの場面

MED の扱いとIGP コストで出口がどう動くかを、コンテナ上の FRRouting 10.4.1 で5台の構成を組んで確かめました。以下の設定と出力は、その実行結果からの抜粋です。

検証構成：出口ルータ2台と内側ルータ1台の AS 65001

AS 65001（自網）は内側ルータ A3 と出口ルータ A1・A2 の3台で、OSPF と IBGP のフルメッシュを張りました。A3 から A1 への OSPF コストは10、A3 から A2 は20です。AS 65002（相手網）の B1 は A1 と、B2 は A2 と EBGP で接続し、どちらも同じ 203.0.113.0/24 を広告します。宛先は B2 側に近いという想定で、B1 は MED 50、B2 は MED 10 を付けました。ホットポテトにする側は、A1・A2 で EBGP から受けた経路の MED を0に書き換えます。

! A1 の設定抜粋。OSPF・IBGP・update-source 等は設定済みが前提
! A2 では隣接 IP を読み替え、HOT を EBGP の受信側に適用する
route-map HOT permit 10
 set metric 0
router bgp 65001
 neighbor 172.31.11.11 remote-as 65002
 neighbor 3.3.3.3 remote-as 65001
 neighbor 3.3.3.3 next-hop-self
 address-family ipv4 unicast
  neighbor 172.31.11.11 route-map HOT in

コールドポテト時の A1 による A2 経由の選択

MED をそのまま IBGP に流した状態で、出口ルータ A1 の表を見ると、自分が B1 から直接受けた経路（MED 50）ではなく、A2 経由の経路（MED 10）が best になりました。選択理由は MED です。A1 は自分の出口を持っているのに、パケットを A3 経由で A2 まで運んでから相手網へ渡します。

A1# show bgp ipv4 unicast 203.0.113.0/24
    2.2.2.2 (metric 30) from 2.2.2.2 (2.2.2.2)
      Origin IGP, metric 10, localpref 100, valid, internal, best (MED)
    172.31.11.11 from 172.31.11.11 (9.9.9.1)
      Origin IGP, metric 50, valid, external

A1 は自分の best しか広告せず、IBGP で受けた経路は他の IBGP ピアへ広告しません。そのためこの検証構成では、内側の A3 に届いた候補は A2 からの1本だけでした。

MED を0に統一した場合の最寄り出口の選択

A1・A2 の受信側で MED を0にすると、A1 は自分の EBGP 経路を選び、理由は Peer Type（RFC 4271 の d、EBGP 優先）に変わりました。内側の A3 には A1・A2 の両方から経路が届き、IGP コストの小さい A1 側（10）を選んでいます。

A3# show bgp ipv4 unicast 203.0.113.0/24
    1.1.1.1 (metric 10) from 1.1.1.1 (1.1.1.1)
      Origin IGP, metric 0, localpref 100, valid, internal, best (IGP Metric)
    2.2.2.2 (metric 20) from 2.2.2.2 (2.2.2.2)
      Origin IGP, metric 0, localpref 100, valid, internal
# A3 コンテナの Linux シェルで実行
ip route get 203.0.113.1
203.0.113.1 via 10.0.13.1 dev eth0 src 10.0.13.3

IGP コスト1か所の変更による外向き出口の切り替わり

ホットポテトのまま、A3 から A1 へのリンクの OSPF コストを10から30に上げました。相手網の B1・B2 は何も変えていませんが、A3 の best は A2 側（コスト20）に移り、転送先も A2 に変わりました。

A3# show bgp ipv4 unicast 203.0.113.0/24
    2.2.2.2 (metric 20) from 2.2.2.2 (2.2.2.2)
      Origin IGP, metric 0, localpref 100, valid, internal, best (IGP Metric)
    1.1.1.1 (metric 30) from 1.1.1.1 (1.1.1.1)
      Origin IGP, metric 0, localpref 100, valid, internal

社内の保守作業や障害で IGP コストが変わるだけで、外向きの BGP 経路が変わるということです。この現象を AT&T のバックボーンで測った Teixeira らの論文「Dynamics of Hot-Potato Routing in IP Networks」（SIGMETRICS 2004）では、経路コスト変化の99%超はどのプレフィックスの出口も変えなかった一方、ピアリング接続を持たない PoP のルータでは、ある1日の BGP 経路変更の82%がホットポテト由来でした。ふだんは静かでも、IGP のメンテナンスが集中した日に外向きの経路がまとめて動く、という性質です。IGP コストを変える作業の前には、外向きの出口が移るプレフィックスを洗い出しておくのが安全です。設定変更の影響を本番前に計算する方法はBatfishでネットワーク設定を本番前に検証する方法で紹介しています。

クラウド3社でのホットポテトとコールドポテトの対応

大手クラウドはこの選択をそのまま製品の設定項目にしています。名前が各社で違うので、対応関係を先に押さえておくと読み替えが速くなります。

クラウド	コールドポテト側	ホットポテト側	既定	設定単位
Azure	Microsoft グローバルネットワーク	Internet（ISP 網）	Microsoft 網	パブリック IP
Google Cloud	Premium Tier	Standard Tier	Premium Tier	プロジェクト既定／リソース
AWS	Global Accelerator	通常のリージョン出口	リージョン出口	アクセラレーター

Azure：パブリック IP ごとのルーティング設定

Microsoft Learn の「Azure でのルーティング優先設定」は、Microsoft ネットワーク経由と ISP ネットワーク（パブリックインターネット）経由の2択を、それぞれコールドポテトルーティング、ホットポテトルーティングとも呼ぶと明記しています。既定はすべての Azure サービスで Microsoft グローバルネットワーク経由で、同ページ（2026年1月12日更新）はこの網を165以上のエッジ POP と16万マイル超の光ファイバーと説明しています。Internet を選ぶと、サービスをホストしているリージョンの近くで Microsoft 網を出入りします。Internet 設定のパブリック IP でも、宛先が Azure 内なら Microsoft の WAN 内の直接経路を通ります。

Google Cloud：Premium Tier と Standard Tier

Network Service Tiers の概要（2026年3月3日更新）によれば、Premium Tier の受信はインターネット利用者にできるだけ近い Google の PoP から入り、Standard Tier は IP アドレスのリージョンに近い PoP で出入りします。Premium がコールドポテト、Standard がホットポテトに当たります。Premium の網は200か所以上の PoP を持つとされています。

注意したいのは Premium の送信側です。同ページは、送信は利用者への BGP ベストパスに従い、利用者が複数の場所で Google とピアリングする網にいる場合は、利用者の最寄りまで Google 網に留まることを保証しないと書いています。コールドポテトでも、出口は相手網が広告する経路しだいで変わるということです。

Standard Tier は経路以外の制約も大きく、グローバル外部 IP（Anycast）が使えない、Cloud VPN と Cloud CDN で使えない、ロードバランサのバックエンドが単一リージョンに限られる、といった差があります。SLA は Premium が99.99%、Standard が99.9%です。Standard には、リージョンごと、SKU ごとに月200GB の無料枠があります。ロードバランサ側の選び分けはCloud Load Balancingの種類と選び分けで整理しています。

AWS：既定のリージョン出口と Global Accelerator

AWS には Azure や Google Cloud のようなインターネット経路の選択肢がなく、通常の通信はリージョンから公衆インターネットへ出ます。公開アプリケーションへのクライアント接続を AWS のエッジからバックボーンへ取り込む場合は、AWS Global Accelerator を使います。これは、EC2 などから開始する任意のインターネット向け通信の出口を切り替える機能ではありません。公式ドキュメントは、Global Accelerator の静的 IP アドレスが AWS エッジネットワークから Anycast で広告され、利用者に最も近いエッジロケーションから AWS グローバルネットワークに入ると説明しています。料金は固定費とデータ転送の両方がかかるので、月額はAWS Global Acceleratorの料金と仕組みで試算してから決めてください。静的コンテンツの配信が目的ならAmazon CloudFrontのエッジキャッシュで足りることもあります。

既定のコールドポテトが裏目に出る条件

コールドポテトは「宛先に最も近い自網の出口」を選ぶのであって、「宛先までの最短経路」を選ぶわけではありません。相手網との接続点が近くになければ、自網の都合で遠くまで運ばれます。

アルファシステムズの技術ブログ「クラウド間の通信がなぜか遅くて、ルーティングの違いに行き着く」（2023年5月22日）がその例です。Azure 東日本と OCI 東京の間の IPsec VPN が10〜20Mbps、RTT 50〜60ms しか出ず、同じ Azure から AWS 東京へは RTT 約2msでした。筆者は、Azure の転送料金にオーストラリア東部リージョンからの課金が計上されていたことを根拠に、Microsoft 網で海外を経由してから ISP に渡っていた可能性が高いと推定しています。Basic SKU のパブリック IP は Microsoft 網に固定されていたため、Standard SKU で Internet を選んだところ、140〜160Mbps、RTT 2〜3ms に改善しました。

ホットポテト側を試す価値があるのは、次のどれかに当てはまるときです。

マルチクラウド構成で、別クラウドの同じ都市のリージョンと大量に通信する。
利用者がほぼ国内にいて、国内 ISP との相互接続が十分にある。
バッチ転送やバックアップ同期のように、遅延より転送単価が効く。

逆に、利用者が複数の大陸に散っている対話型サービスなら既定のまま触らない方が無難です。クラウド間の通信量が多いなら、インターネット経路を選び分けるより、AWS Interconnect – multicloudやAzure ExpressRouteのような閉域接続を先に比べる方が筋のよい場合もあります。複数クラウドをまたぐ経路の設計から相談したい場合は、AWS・Google Cloud・Azureのインフラ構築支援でも対応しています。

ホットポテト側へ切り替える手順と制約

Azure も Google Cloud も、ホットポテト側への切り替えは既存の IP アドレスを書き換える操作ではなく、新しい IP アドレスを作る操作です。DNS の切り替えを含めて計画してください。

Azure：Internet ルーティング設定のパブリック IP の作成

Microsoft Learn が挙げる制約は次のとおりです。

作成後に変更できない：ルーティング設定はパブリック IP の作成時に決まる。
SKU：ゾーン冗長の Standard SKU のみ。Standard v2 SKU と Basic SKU は非対応。
IPv4 のみ：IPv6 のパブリック IP は非対応。
使えないリソース：NAT ゲートウェイ、IP ベースのパブリックロードバランサー。
関連付けられるリソース：仮想マシン、仮想マシンスケールセット、AKS、パブリックロードバランサー（NIC ベースのバックエンドのみ）、Application Gateway、Azure Firewall。
ストレージ：ストレージアカウントはStorage 側のネットワークルーティング設定で、パブリックエンドポイントの既定を Internet routing に変えたり、経路別のエンドポイントを足したりできる。Azure Files を含むアカウントは Microsoft routing のままにする（Internet routing は AD ドメイン参加と Azure File Sync に非対応）。
リージョン：東日本・西日本は対応一覧に入っている（2026年1月12日時点。一覧にない新しいリージョンはポータルの作成画面で確認する）。

Azure CLI では次のように作成します（公式手順は Azure CLI 2.0.49 以降）。公式例には可用性ゾーンの指定がないため、ゾーン冗長を確実にするなら --zone 1 2 3 を足します。

az network public-ip create \
  --name MyRoutingPrefIP \
  --resource-group MyResourceGroup \
  --location japaneast \
  --ip-tags 'RoutingPreference=Internet' \
  --sku STANDARD \
  --allocation-method static \
  --version IPv4 \
  --zone 1 2 3

料金差はインターネット送信のデータ転送料金に出ます。公式ページは、Microsoft 網経由の単価が従来のインターネット送信料金と同じだとしていますが、Internet 側との差額は書いていません。金額は Azure の帯域幅料金ページで確かめてください。

Google Cloud：プロジェクト既定・リソース単位での Standard の指定

Network Service Tiers の使用の手順では、プロジェクトの既定を変えるか、IP アドレスや VM ごとに指定します。両方を指定した場合はリソース側が優先されます。プロジェクトの既定値を変更しても既存リソースのティアは変わらず、変更後に作成する対象リソースに適用されます。

# プロジェクトの既定を Standard にする
gcloud compute project-info update \
  --default-network-tier STANDARD

# Standard Tier のリージョン外部 IP を予約する
gcloud compute addresses create my-standard-tier-ip-address \
  --region asia-northeast1 \
  --network-tier STANDARD

Premium と Standard は IP アドレスのプールが別です。エフェメラル IP の VM のティアを変えると IP アドレスも変わり、予約済みのアドレスを別のティアへ移すことはできません。また、障害中に Standard から Premium へ切り替えても、障害の間は Standard として扱われるため、Premium を Standard の予備には使えません。

よくある質問

なぜ「ポテト」と呼ぶのですか？

熱いジャガイモは素手で持っていられないのですぐ隣へ渡す、という比喩です。RFC 4451 もこの比喩で hot potato routing を説明しています。冷めたジャガイモなら遠くまで持って運べるので、宛先近くまで自網で運ぶ方がコールドポテトです。

hot potato routing には別の意味もありますか？

あります。パケット交換の分野では、ノードがバッファで待たずに空いているリンクへすぐ送り出す方式を指します。Paul Baran の1964年の報告「On Distributed Communications」が、優先リンクが使用中なら待たずに次善の空きリンクを選ぶ方式として説明しており、Greenberg と Hajek の1992年の論文は、deflection routing を Baran の定義した hot potato routing と本質的に同じものと位置づけています。本記事で扱っているのは、AS 間の出口選択という意味の方です。

ホットポテトとコールドポテト、結局どちらが速いのですか？

距離だけでは決まりません。利用者が複数の大陸に散っている場合は、区間の大部分を自網のバックボーンで運ぶコールドポテト（Azure の Microsoft グローバルネットワーク、Google Cloud の Premium Tier）が中継 ISP の輻輳を避けやすくなります。一方、アルファシステムズの事例のように宛先が同じ都市の別クラウドにあると、コールドポテトの方が遠回りになり、Internet ルーティングに変えて RTT が50ms台から2〜3ms に縮んだ例もあります。宛先の分布を見て、両方の IP で実測してから決めるのが確実です。

BGP の MED は必ず尊重されますか？

いいえ。MED は受信側が削除・書き換えできる経路選択用の属性です。ホットポテト運用では、受信した MED の差を削除や固定値への書き換えで無効化する方法があります。MED を比べる場合でも、RFC 4271 の規定では同じ隣接 AS から学習した経路どうしでしか比べません。

Azure や Google Cloud の設定は後から変更できますか？

Azure のルーティング設定はパブリック IP の作成時にしか指定できず、切り替えるには新しいパブリック IP を作って関連付け直します。Google Cloud も、ティアごとに IP アドレスのプールが分かれているため、ティアを変えると IP アドレスが変わります。どちらも IP アドレスの変更を前提に、DNS の TTL を下げてから移行してください。