Cloudflare、パブリックトラフィックをプライベートオリジンにルーティングし、それらを公開せずに

Cloudflareは、Application Services for Private Originsのクローズドベータ版を発表した。この機能により、顧客はパブリックトラフィックをプライベートアプリケーションにルーティングし、それらのオリジンをインターネットに公開する必要がなくなる。パブリックIP、ファイアウォールの例外、またはオリジン上でのcloudflaredの実行の代わりに、プロキシされたDNSレコードをプライベートIPに向け、Cloudflareのプロキシに残りを処理させることができる。

核となる考え方は、WAF、レート制限、ボット管理、キャッシング、Workersなどのセキュリティおよびパフォーマンスサービスが、内部API、AIエージェントバックエンド、MCPサーバーなどのプライベートアプリケーションにも、パブリックウェブサイトと同様に適用されるべきだということだ。これまで、これらのサービスをプライベートオリジンに適用するには、トレードオフが必要だった。オリジンをパブリックに公開するか、コネクタソフトウェアを実行するか、パブリック向けロードバランサーやリバースプロキシのような並列インフラを維持するかである。

仕組み

この機能は、Cloudflareの既存のプライベートネットワーキングレイヤー（Cloudflare Tunnel、Cloudflare One、Cloudflare Mesh、Cloudflare WANで使用）をアプリケーションサービススタックに拡張する。プロキシされたDNSレコードでプライベートルーティングを有効にすると、Cloudflareのプロキシはuse_private_routingフラグを認識し、直接のパブリック接続を試みる代わりに、顧客の既存のプライベート接続（IPsec、GRE、CNI、Tunnel、Mesh）を介してトラフィックをルーティングする。

APIは簡単だ。プライベートIPを持つDNSレコードに"use_private_routing": trueを追加する。CloudflareのOrigin APIは、プロキシにプライベートネットワークパスを使用するよう指示するメタデータを返す。

POST /zones/{zone_id}/dns_records
{
  "type": "A",
  "name": "app.example.com",
  "content": "10.0.0.50",
  "ttl": 300,
  "proxied": true,
  "use_private_routing": true
}

舞台裏では、プロキシがOrigin APIにクエリを実行し、次の応答を受け取る。

{
  "zone_name": "example.com",
  "ipv4_addresses": ["10.0.0.50"],
  "use_private_routing": true
}

このフラグがプライベートネットワーキングレイヤーをトリガーし、顧客の既存のトンネルまたはWANリンクを介して接続をルーティングする。

HTTPを超えて

同じモデルは、Spectrum（レイヤー4プロキシ）とWorkers VPCバインディングを介して、非HTTPトラフィックにも拡張される。オリジン設定でvirtual_network_idを指定することで、プライベートIPで動作するTCPデータベースやUDPロギングエンドポイントの前にSpectrumを配置できるようになった。Workersはまた、VPCバインディングを介してプライベートAPIを直接呼び出すことができ、同じルーティングレイヤーを使用する。

欠けているもの

本日のリリースは、パブリックからプライベートへのトラフィックをカバーしている。Cloudflareは、プライベートからプライベート（例えば、プライベートネットワーク上のユーザーがCloudflareのセキュリティスタックを介してプライベートアプリにアクセスする）が次だと述べている。クローズドベータ版は、対象となるEnterprise顧客が利用できる。

すでにCloudflare WANまたはMeshを実行しているチームにとって、これは大きな運用上の負担を取り除く。内部APIの前にWAFを配置するためだけに、別のパブリック向けロードバランサーやTLS終端レイヤーを維持する必要がなくなる。プライベートオリジンはプライベートのままであり、Cloudflareがセキュリティとパフォーマンスのレイヤーを処理する。