Cloudflare TURN の料金は、RFC 8656 の図 1 ↗ に示されているとおり、Cloudflare エッジから TURN クライアントへ送られたデータに基づきます。つまり、認証成功後に TURN サーバーから TURN クライアントへ送られたデータが対象で、TURN のオーバーヘッドを含むすべてのデータを捉えます。
Cloudflare Realtime TURN サービスの料金は、使用データ 1 GB あたり $0.05 です。
stun.cloudflare.com の Cloudflare STUN サービスは無料で、上限はありません。
課金が始まる前に 1,000 GB の無料枠があります。Cloudflare Realtime の請求は、SFU と TURN の両方を含む 1 行として Cloudflare の請求書に表示されます。
Cloudflare Realtime TURN と Cloudflare Realtime SFU、または Cloudflare Stream（WHIP/WHEP）の間のトラフィックには、料金はかかりません。
---
title: Cloudflare Realtime TURN の料金
---
flowchart LR
Client[TURN Client]
Server[TURN Server]
Client -->|"入力（無料）"| Server
Server -->|"出力（課金対象）"| Client
Server <-->|課金対象外| PeerA[Peer A]
Cloudflare の 認証とコンプライアンスの資料 ↗ を確認し、詳細は Cloudflare の Enterprise アカウントマネージャーに問い合わせてください。
Cloudflare Realtime TURN は、TURN over TLS など暗号化を使う場合に FIPS 140-3 をサポートします。TURN 自体は、TURN データ層の下を流れるデータの暗号化を制御しません。中継するメディアやデータをエンドツーエンドで暗号化するには、TURN より上の層がその暗号化を提供する必要があります（例: TURN を WebRTC と使う場合の DTLS）。
Cloudflare Realtime TURN サーバーは Cloudflare のグローバルネットワーク ↗ 上で稼働します。数百か所に分散した数千台のマシンからなる、拡大中のグローバルネットワークです。ただし Cloudflare の China Network は対象外です。
Cloudflare Realtime TURN サービスの性能や機能レベルに、Enterprise プランとセルフサーブプランの差はありません。ただし Enterprise プラン ↗ では、優先サポート、予測しやすい定額料金、SLA 保証を利用できます。
Cloudflare の China Network は Realtime トラフィックの処理には参加しません。中国からの TURN トラフィックは、中国外の Cloudflare 拠点へ接続します。
TURN の利用状況は、30 秒で分析に表示されます。
Cloudflare Realtime TURN を WebRTC と併用する場合、Cloudflare は中継するメディアの内容にアクセスできません。WebRTC はすべてのメディアストリームに Datagram Transport Layer Security（DTLS）暗号化を使い、TURN サーバーに届く前に通信ピア間でデータをエンドツーエンド暗号化するためです。その結果、Cloudflare は暗号化されたパケットを中継するだけで、音声、映像、データチャネルの情報を含むメディア内容を復号したり検査したりできません。
データプライバシーの観点では、TURN サービスを運用するために Cloudflare が処理する情報は、リレー接続の確立と維持に必要なメタデータだけです。これには TURN クライアントの IP アドレス、ポート番号、セッションのタイミング情報が含まれます。暗号化されたメディアストリーム内の個人を特定できる情報には、Cloudflare はアクセスできません。
このアーキテクチャにより、Cloudflare Realtime TURN を経由するメディア通信は参加者間のエンドツーエンド暗号化を維持します。Cloudflare は暗号化された内容を見ることなく、仲介リレーとしてだけ機能します。
TURN プロトコル（RFC 8656 ↗）は、TURN over TLS などのラッパープロトコルを超える暗号化については扱いません。TURN を WebRTC と使う場合は、WebRTC の層でデータを暗号化します。
Cloudflare Realtime TURN の割り当ては、anycast ルーティングにより、TURN クライアントから最も近い利用可能な Cloudflare データセンターに配置されます。接続の両端が Cloudflare Realtime TURN を使っている場合、Cloudflare はルーティングを制御でき、可能であれば TURN パケットを Cloudflare Backbone 経由で送ります。
TURN と SFU は異なる問題を解きます。一緒に使うことも多いです。
2 つのピア間のポイントツーポイント接続があり、NAT やファイアウォールを越える必要があるときは TURN を使います。両方のピアは、サーバー側のメディア処理なしで、リレー経由で直接メディアをやり取りします。
1 人の配信者が多数の購読者へメディアを送るファンアウトや、多数の配信者がグループでメディアをやり取りする場合は SFU を使います。SFU は参加者間で選んだメディアストリームを転送し、サイマルキャストや購読者側のトラック選択などの機能をサポートします。
ユースケースが 1 対 1 の通信（オペレーターと遠隔機器の間の遠隔操作リンクなど）なら、TURN だけで十分なことが多いです。そのトポロジーに SFU を足す必要はありません。
ありません。Cloudflare Realtime TURN と SFU は、Cloudflare のグローバルネットワーク上の同じマシン群で動き、同じデータパスを共有します。一方を選ぶことによる意味のあるレイテンシやスループットのペナルティはありません。
判断は性能ではなく、トポロジーで決めます。
- ポイントツーポイントのリレーには TURN を使います。
- ファンアウト、グループ通話、トラックの選択転送が必要なときは SFU を使います。
必ずしも同じではありません。両方のピアが Cloudflare Realtime TURN でリレーすると、2 つの Cloudflare エッジ間のトラフィックは Cloudflare Backbone を使えるため、Cloudflare が端から端まで経路を制御できます。片方のピアだけが TURN を使う場合、もう一方の区間はパブリックインターネットを通り、レイテンシとパケットロスは、そのピアと最寄りの Cloudflare データセンター間の相互接続に依存します。
両端で TURN を使うことで、より一貫して改善するのは、生のレイテンシではなく、信頼性とパケットロスの挙動です。Backbone のレイテンシはパブリックインターネットより良いことが多いですが、改善幅は地理によって変わります。パケットロスの減少のほうが、一般により予測しやすいです。
使えます。Cloudflare Realtime TURN は、オペレーターと遠隔機器の間で低レイテンシの双方向メディアやデータチャネルが必要な、ロボットの遠隔操作、遠隔車両制御、フリート管理のワークロードに適しています。
遠隔操作では、通常 TURN をポイントツーポイントで使います。一端はオペレーターのネットワーク、もう一端はロボットのセルラーまたは有線アップリンクです。WebRTC と DTLS がメディアストリームをエンドツーエンドで暗号化し、Cloudflare Realtime TURN が 2 つのエンドポイント間の NAT 越えとリレーを処理します。両方のエンドポイントが TURN 経由で接続すると、Cloudflare エッジ間のトラフィックは Cloudflare Backbone を使え、長距離リンクでのパケットロス特性が改善します。
ロボットのテレメトリやカメラフィードを複数の購読者（オペレーター、監督者、フリートダッシュボードなど）へファンアウトする必要があるワークロードでは、TURN に加えて Cloudflare Realtime SFU も使えます。接続の両端を制御できる場合は、テレメトリや遠隔操作向けに Cloudflare の Media over QUIC（MoQ）実装も検討する価値があります。WebRTC より、信頼性と再送の挙動を明示的に制御しやすいためです。
Cloudflare Realtime TURN は、許可リストに追加する IP アドレスがほかのプロバイダーより少ないため、厳格なファイアウォールを持つ IT 管理者でも使いやすいです。IPv6 と IPv4 の両方を許可リストに追加してください。
次の IP アドレスを許可リストに追加します。
2a06:98c1:3200::1/1282606:4700:48::1/128141.101.90.1/32162.159.207.1/32
推奨はしませんが、IP アドレスのハードコードが役立つ状況はごくわずかにあると理解しています。その場合は、turn.cloudflare.com の DNS 応答（A レコードと AAAA レコード）の変化を検出するアラートを設定し、DNS 変更から 14 日以内にハードコードした IP アドレスを更新してください。この DNS 応答は、複数の IP アドレスを返すことがあります。加えて、ハードコードした IP アドレスへの接続に問題がある場合は、DNS クエリへのフェイルオーバーを設定してください。Cloudflare は TURN サービスで使う IP アドレスが変わらないよう努めますが、Enterprise 契約に含まれていない限り保証できません。静的 IP、保証、その他の取り決めの詳細は、Enterprise アカウントチームと相談してください。
turn.cloudflare.com の TURN サービスは、バインディングリクエスト（「STUN リクエスト」）にも応答します。
Cloudflare Realtime の資格情報生成関数は、期限切れの RFC ドラフト「draft-uberti-behave-turn-rest-00」 ↗ に似た JSON 構造を返しますが、TTL 値は含みません。この形式の応答が必要な場合は、バックエンドサーバーまたは Cloudflare Workers で、Cloudflare Realtime の資格情報生成エンドポイントからの JSON を必要な形式に変換できます。
パケットロスは UDP では普通に起き、信頼できる接続でもたまに発生します。ただし、系統的なパケットロスを観測する場合は、次を検討してください。
- 単一の TURN クライアントから高いレート（50〜100 Mbps 超）でデータを送受信していませんか？ Realtime TURN は、速度を落とすよう合図するためにパケットを落とすことがあります。
- 単一の TURN クライアントから、非常に小さいパケットサイズで大量のデータ（高いパケットレート、5〜10 kpps 超）を送受信していませんか？ Cloudflare Realtime がパケットを落とすことがあります。
- ポートスキャン ↗ のような挙動で、新しい一意のアドレスへ高いレートでパケットを送っていませんか？
資格情報の発行に定義された上限はありません。500 資格情報/秒から始め、線形にスケールアップしてください。発行した資格情報の 50% 超を使ってください。
資格情報の有効期限は、最大で 48 時間先まで設定できます。TURN 割り当てをこれより長く維持する必要がある場合は、TURN 資格情報を 更新 ↗ してください。
サポートします。Cloudflare Realtime は、TURN クライアントから TURN サーバーへの通信で IPv4 と IPv6 の両方を利用できます。ただし、RFC 6156 ↗ に記載されている IPv6 のリレーアドレスは発行しません。
発行しません。Realtime TURN は、指定されていても REQUESTED-ADDRESS-FAMILY STUN 属性を尊重せず、IPv4 アドレスだけを発行します。
サポートしません。Realtime は RFC6062 ↗ を実装しておらず、REQUESTED-TRANSPORT STUN 属性を尊重しません。
Cloudflare Realtime は、プライベート IP 範囲（ループバックアドレス、リンクローカルユニキャスト、マルチキャストブロックなど）や BYOIP に含まれる IP アドレスが使われた場合、CreatePermission または ChannelBind リクエストを拒否します。
Cloudflare の BYOIP のお客様で、Realtime TURN から BYOIP 範囲へ接続したい場合は、詳細をアカウントマネージャーに問い合わせてください。
TURN 割り当てに最大継続時間の制限はありません。RFC 8656 セクション 3.2 ↗ のとおり、リレー用トランスポートアドレスが割り当てられたら、クライアントは割り当てを維持する必要があります。そのため、クライアントは定期的にサーバーへ Refresh リクエストを送ります。Refresh リクエストは、有効な TURN 資格情報で認証する必要があります。資格情報の最大継続時間は 48 時間です。より長い割り当てが必要な場合は、少なくとも 48 時間ごとに新しい資格情報を生成してください。
よくあることではありませんが、一部のシナリオでは TURN 割り当てが中断されることがあります。原因は、割り当てを処理している Cloudflare サーバーのメンテナンスや、TURN パケットが別の Cloudflare データセンターに届くインターネットのトポロジー変化などです。理由にかかわらず、クライアントによる ICE restart ↗ のサポートを強く推奨します。
Cloudflare Realtime は、課金と分析用の利用記録をすぐに停止します。短い遅延のあと、接続は切断されます。