料金 · Cloudflare Durable Objects ドキュメント

Durable Objects の課金は、コンピュートとストレージの 2 種類です。

Workers の Free プランでは、次のとおりです。

無料枠のいずれかの上限を超えると、その種類の以降の操作はエラーで失敗します。
1 日の無料上限は 00:00 UTC にリセットされます。

コンピュートの課金

Durable Objects は、オブジェクトがアクティブに実行している間、またはメモリ上でアイドルでもハイバネーションできない間のコンピュート継続時間（ウォールクロック時間）に対して課金されます。アイドルでハイバネーションの対象になる Durable Objects は、ランタイムがハイバネーションする前でも継続時間は課金されません。Durable Object へのリクエストは、オブジェクトをアクティブに保つか、非アクティブだった場合はオブジェクトを作成します。

各課金指標では、月間の含まれる枠を超えた分が課金対象です。この課金対象使用量は、対応する単価を適用する前に、次の課金単位へ切り上げます。たとえば、課金対象のコンピュート継続時間が 500,000 GB-s の場合、1,000,000 GB-s に切り上げて課金します。

	Free プラン	Paid プラン
リクエスト	100,000 / 日	1 million / 月、+ $0.15/million HTTP リクエスト、RPC セッション¹、WebSocket メッセージ²、アラーム呼び出しを含みます
継続時間³	13,000 GB-s / 日	400,000 GB-s / 月、+ $12.50/million GB-s^4,5

脚注

¹ 各 RPC セッションは、Durable Object へのリクエスト 1 件として課金されます。Durable Objects stub 上の RPC メソッド呼び出しは、それぞれが独立した RPC セッションであり、課金リクエスト 1 件になります。

RPC メソッド呼び出しは、RpcTarget を拡張するオブジェクト（stub）を返し、その stub に対して呼び出しを行えます。返された stub への後続の呼び出しは、同じ RPC セッションの一部であり、別リクエストとしては課金されません。例:

let durableObjectStub = OBJECT_NAMESPACE.get(id); // retrieve Durable Object stub
using foo = await durableObjectStub.bar(); // billed as a request
await foo.baz(); // treated as part of the same RPC session created by calling bar(), not billed as a request
await durableObjectStub.cat(); // billed as a request

² WebSocket 接続の作成にはリクエストが必要です。外向きの WebSocket メッセージ、および受信する WebSocket protocol pings ↗ には料金はかかりません。コンピュートリクエストの課金だけを目的に、受信 WebSocket メッセージには 20:1 の比率を適用し、リアルタイム通信の小さいメッセージを考慮します。たとえば、受信 WebSocket メッセージ 100 件は、課金上 5 リクエストになります。この 20:1 の比率は、実際の使用量を反映する Durable Object のメトリクスと分析には影響しません。

³ state.setWebSocketAutoResponse() が処理するアプリケーションレベルの自動応答メッセージは、追加のウォールクロック時間を発生させないため、課金されません。

⁴ 継続時間は、オブジェクトがアクティブでハイバネーション対象でないあいだ、ウォールクロック時間で課金されます。ただし、同じオブジェクト上で同時にアクティブなすべてのリクエストで共有されます。オブジェクト内で WebSocket に対して accept() を呼び出すと、その WebSocket が接続されている全期間の継続時間が課金されます。すべてのイベントハンドラーの実行が終わったあとに継続時間課金が発生しないようにするには、WebSocket Hibernation API の利用を推奨します。詳しくは Durable Object に継続時間課金が発生するのはいつですか？を参照してください。

⁵ 継続時間の課金は、実際の使用量にかかわらず、Durable Object に割り当てられた 128 MB のメモリに対して発生します。アカウントが同一 Durable Object クラスのインスタンスを多数作成する場合、Durable Objects は同じ物理マシン上の同じ isolate で動き、128 MB のメモリを共有することがあります。これらの Durable Objects は、それぞれに 128 MB が割り当てられているものとして課金されます。

ストレージの課金

Durable Objects Storage API は、Durable Objects の内部からのみ利用できます。料金は、Durable Objects のストレージバックエンドによって異なります。

SQLite バックエンドの Durable Objects（推奨）: 新しい Durable Object クラスには、SQLite ストレージバックエンドを推奨します。Workers Free プランでは、SQLite バックエンドの Durable Objects だけを作成およびアクセスできます。
Key-value バックエンドの Durable Objects: Key-value ストレージバックエンドは、Workers Paid プランでのみ利用できます。

SQLite ストレージバックエンド

	Workers Free プラン	Workers Paid プラン
読み取り行 ^1,2	5 million / 日	最初の 25 billion / 月を含む + $0.001 / million rows
書き込み行 ^1,2,3,4	100,000 / 日	最初の 50 million / 月を含む + $1.00 / million rows
SQL 保存データ ⁵	5 GB（合計）	5 GB-month、+ $0.20/ GB-month

脚注

¹ 読み取り行と書き込み行の含まれる上限と単価は、Cloudflare のサーバーレス SQL データベースである D1 の料金と同じです。

² get()、put()、delete()、list() などの Key-value メソッドは、非公開の SQLite テーブルにデータを保存・照会し、読み取り行および書き込み行として課金されます。

³ 各 setAlarm() は、書き込み行 1 件として課金されます。

⁴ 削除は書き込み行としてカウントされます。

⁵ Durable Objects は、データを削除するまで保存データに対して課金されます。データを削除すると、オブジェクトはシステムによって自動でクリーンアップされます。

Key-value ストレージバックエンド

	Workers Paid プラン
読み取りリクエストユニット^1,2	1 million、+ $0.20/million
書き込みリクエストユニット³	1 million、+ $1.00/million
削除リクエスト⁴	1 million、+ $1.00/million
保存データ⁵	1 GB、+ $0.20/ GB-month

脚注

¹ リクエストユニットは、読み取りまたは書き込みしたデータ 4 KB として定義します。4 KB を超える書き込みまたは読み取りのリクエストは複数ユニットを消費します。たとえば、9 KB の書き込みは書き込みリクエストユニット 3 件になります。

² リスト操作は、調べたデータ量に基づき、読み取りリクエストユニットで課金されます。たとえば、キーと値の合計が 80 KB になるリストリクエストは、読み取りリクエストユニット 20 件として課金されます。何も返さないリストリクエストは、読み取りリクエストユニット 1 件として課金されます。

³ 各 setAlarm は、書き込みリクエストユニット 1 件として課金されます。

⁴ 削除リクエストは容量課金されません。たとえば、100 KB の値を削除しても、削除リクエスト 1 件だけが課金されます。

Durable Objects のインメモリキャッシュにヒットするリクエスト、または get() / put() / delete() の複数キー版を使うリクエストは、キーごとに通常の個別リクエストと同じように課金されます。

コンピュート課金の例

これらの例には、Durable Objects を呼び出す Workers の料金は含まれません。Durable Object のコストを見積もるときは、次の点に注意してください。

リクエストを受けていない非アクティブなオブジェクトには、継続時間の課金は発生しません。
WebSocket Hibernation API を使うと、WebSocket プロトコルでクライアントと通信する Durable Objects の継続時間課金を大きく減らせます。メッセージの送信間隔がまばらな場合は特に効果的です。
- 外向き接続（connect() または外向き WebSocket）がアクティブだと、受信リクエストがなくても Durable Object はメモリに残り、接続あたり最大 15 分間の継続時間課金が発生します。詳細は Durable Object のライフサイクルを参照してください。

例 1

HTTP 経由で呼び出す、調整サービスとして使うシンプルな Durable Object の例です。

1 つの Durable Object が、Worker から 150 万回呼び出されました
その月のアクティブ時間は 1,000,000 秒です

この場合の月額概算は次のとおりです。

リクエスト:

150 万リクエスト - 含まれる 100 万リクエスト = 課金対象 500,000 リクエスト。
（四捨五入）1,000,000 リクエスト x $0.15 / 1,000,000 = $0.15。

コンピュート時間:

1,000,000 秒 * 128 MB / 1 GB = 128,000 GB-s。
128,000 GB-s は、含まれる枠 400,000 GB-s の範囲内 = $0.00。

概算合計: $0.15（リクエスト）+ $0.00（コンピュート時間）+ 月額最低利用料金 $5 = 月額 $5.15

例 2

接続中のクライアントへゲーム、チャット、リアルタイムのユーザー状態を配信するために WebSocket を使う、中程度のトラフィックの Durable Objects アプリの例です。

100 個の Durable Objects それぞれに、50 本の WebSocket 接続があります。
クライアントは、1 日 8 時間、月の毎日、およそ 1 分に 1 通のメッセージを送ります。

この場合の月額概算は次のとおりです。

リクエスト:

50 本の WebSocket 接続 * 100 個の Durable Objects で WebSocket を確立 = 1 日あたり 5,000 接続 * 30 日 = 150,000 件の WebSocket 接続リクエスト。
1 分あたり 50 メッセージ * 100 個の Durable Objects * 60 分 * 8 時間 * 30 日 = 72,000,000 件の WebSocket メッセージリクエスト。
150,000 +（7,200 万リクエスト / WebSocket メッセージの課金比率 20）= 375 万課金リクエスト。
375 万リクエスト - 含まれる 100 万リクエスト = 課金対象 2,750,000 リクエスト。
（四捨五入）3,000,000 リクエスト x $0.15 / 1,000,000 = $0.45。

コンピュート時間:

100 個の Durable Objects * 60 秒 * 60 分 * 8 時間 * 30 日 = 86,400,000 秒。
86,400,000 秒 * 128 MB / 1 GB = 11,059,200 GB-s。
11,059,200 GB-s - 含まれる 400,000 GB-s = 10,659,200 GB-s
（四捨五入）11,000,000 GB-s x $12.50 / 1,000,000 = $137.50。

概算合計: $0.45（リクエスト）+ $137.50（コンピュート時間）+ 月額最低利用料金 $5 = 月額 $142.95。

例 3

ユーザー固有の状態を、各 Durable Object に接続した 1 クライアントへ WebSocket で送る、水平スケールした Durable Objects アプリの例です。

100 個の Durable Objects それぞれに、1 本の WebSocket 接続があります。
クライアントは月を通して 1 秒に 1 通メッセージを送り、Durable Objects は月全体でアクティブでした。

この場合の月額概算は次のとおりです。

リクエスト:

100 件の WebSocket 接続リクエスト。
1 秒あたり 1 メッセージ * 100 接続 * 60 秒 * 60 分 * 24 時間 * 30 日 = 259,200,000 件の WebSocket メッセージリクエスト。
100 +（2 億 5,920 万リクエスト / WebSocket の課金比率 20）= 12,960,100 リクエスト。
12,960,100 リクエスト - 含まれる 100 万リクエスト = 課金対象 11,960,100 リクエスト。
（四捨五入）12,000,000 リクエスト x $0.15 / 1,000,000 = $1.80。

コンピュート時間:

100 個の Durable Objects * 60 秒 * 60 分 * 24 時間 * 30 日 = 259,200,000 秒
259,200,000 秒 * 128 MB / 1 GB = 33,177,600 GB-s
33,177,600 GB-s - 含まれる 400,000 GB-s = 32,777,600 GB-s
（四捨五入）33,000,000 GB-s x $12.50 / 1,000,000 = $412.50

概算合計: $1.80（リクエスト）+ $412.50（コンピュート時間）+ 月額最低利用料金 $5 = 月額 $419.30

例 4

接続中のクライアントへゲーム、チャット、リアルタイムのユーザー状態を配信するために WebSocket Hibernation を使う、中程度のトラフィックの Durable Objects アプリの例です。

100 個の Durable Objects それぞれに、ハイバネーション可能な WebSocket 接続が 100 本あります。
クライアントは 1 分に 1 通メッセージを送り、webSocketMessage() ハンドラーで 1 通あたり 10ms かかります。各 Durable Object は 100 本の WebSocket を扱うため、累計では 1 分あたり 1 秒間 JS を実行します（100 WebSockets * 10ms）。

この場合の月額概算は次のとおりです。

リクエスト:

100 本の WebSocket 接続 * 100 個の Durable Objects で WebSocket を確立 = 初期の WebSocket 接続リクエスト 10,000 件。
1 分あたり 100 メッセージ¹ * 100 個の Durable Objects * 60 分 * 24 時間 * 30 日 = 432,000,000 リクエスト。
10,000 +（4 億 3,200 万リクエスト / WebSocket の課金比率 20）= 21,610,000 リクエスト。
21,610,000 リクエスト - 含まれる 100 万リクエスト = 課金対象 20,610,000 リクエスト。
（四捨五入）21,000,000 リクエスト x $0.15 / 1,000,000 = $3.15。

コンピュート時間:

100 個の Durable Objects * 1 秒² * 60 分 * 24 時間 * 30 日 = 4,320,000 秒
4,320,000 秒 * 128 MB / 1 GB = 552,960 GB-s
552,960 GB-s - 含まれる 400,000 GB-s = 152,960 GB-s
（四捨五入）1,000,000 GB-s x $12.50 / 1,000,000 = $12.50

概算合計: $3.15（リクエスト）+ $12.50（コンピュート時間）+ 月額最低利用料金 $5 = 月額 $20.65

¹ 1 分あたり 100 メッセージは、各 DO に 100 クライアントが接続し、それぞれが 1 分に 1 通送るためです。

² 例では 1 秒を使っています。各 Durable Object が 1 分あたり 1 秒アクティブだからです。4 億 3,200 万リクエストのそれぞれが 10 ms 実行される、とも考えられます（4,320,000 秒）。

よくある質問

Durable Object に継続時間課金が発生するのはいつですか？

Durable Object は、JavaScript を実行中（リクエストの処理、またはイベントハンドラーの実行）のとき、あるいはアイドルでも休止（hibernation）の条件を満たしていないときに、継続時間課金が発生します。休止の条件を満たすアイドルの Durable Object には、ランタイムが休止する直前の短い時間も含め、継続時間課金は発生しません。

オブジェクトがメモリからエビクションされたあと、次に必要になったときは再作成され、コンストラクターが再度呼び出されます。

Durable Object の休止を妨げ、継続時間課金が続く要因はいくつかあります。

詳細は Durable Object のライフサイクルを参照してください。

空のテーブル / SQLite データベースはストレージに計上されますか？

はい。ただしごくわずかです。空のテーブルでも、列数（テーブル幅）に応じて少なくとも数キロバイトを消費します。空の SQLite データベースは、およそ 12 KB のストレージを消費します。

Durable Objects に保存したメタデータはストレージに計上されますか？

SQLite バックエンドの Durable Object への書き込みはすべて、Durable Object 内の内部テーブルにわずかな量のメタデータを保存します。このメタデータは課金対象のストレージに含まれます。

メタデータは、deleteAll() を呼び出すまで Durable Object に残ります。