パターン 1: 静的サイト（このブログの構成）#

1
Pages（Astro SSG）→ 静的 HTML/CSS/JS を配信

最もシンプルな構成で、Workers も KV も使いません。ビルド回数以外に上限を気にする要素がなく、無料枠を超える心配は事実上ゼロです。

ブログ、ポートフォリオ、ドキュメントサイトはこの構成で十分です。

パターン 2: 静的サイト + 簡易 API#

1
Pages（フロント）+ Pages Functions（API）+ KV（データ）

お問い合わせフォームやアクセスカウンターなど、軽量な動的機能を追加するパターンです。Pages Functions は Workers と同じリクエスト上限（10 万/日）を共有します。

KV の書き込み上限は 1,000 回/日とやや厳しいため、書き込み頻度が高い機能には不向きです。閲覧カウンターのように読み取りが中心のユースケースに適しています。

パターン 3: アプリ + DB + ストレージ#

1
Pages（フロント）+ Workers（API）+ D1（DB）+ R2（ファイル）

フルスタックの個人開発アプリ向けです。D1 の読み取り上限は 500 万行/日と余裕がありますが、書き込みは 10 万行/日です。

R2 はストレージが 10 GB まで無料で、egress（下り転送量）は無制限です。画像や PDF のホスティングに向いています。S3 互換 API なので、既存の S3 クライアントがそのまま使えるのも利点です。

Workers のリクエスト数を減らす#

10 万リクエスト/日は多いように見えますが、SPA のバックエンド API として使うと意外に消費します。以下の工夫で節約できます。

• 静的化できるレスポンスは Pages で配信する。Workers を経由させない
• Cache API を使う。Workers 内で caches.default にレスポンスをキャッシュすれば、同じリクエストに対する Workers の実行回数を減らせる
• バッチ API を設計する。フロントエンドから 10 回 fetch する代わりに、1 回のリクエストでまとめて取得できる API を作る

KV の書き込み上限に注意する#

KV の読み取りは 10 万回/日ですが、書き込みは 1,000 回/日です。2 桁違います。

セッション管理のように頻繁に書き込むユースケースには向きません。設定値やキャッシュのように「書き込みは稀、読み取りは頻繁」なデータに使います。頻繁な書き込みが必要なら D1 を検討してください。

D1 は行数ベースで考える#

D1 の制限は「リクエスト数」ではなく「行数」です。SELECT * FROM users が 100 行返せば、100 行分の読み取りとしてカウントされます。

1
-- 悪い例: 全件取得して JS で絞り込む
2
SELECT * FROM logs
3

4
-- 良い例: WHERE で絞ってから取得する
5
SELECT * FROM logs WHERE created_at > date('now', '-7 days') LIMIT 100

不要な行を読まない設計が、そのまま無料枠の節約になります。

R2 の Class A / B を理解する#

R2 の操作は Class A（変更系 + LIST: PUT, POST, DELETE, LIST）と Class B（読み取り系: GET, HEAD）に分類されます。

画像を CDN 的に配信する場合、読み取り（Class B）は 1,000 万回/月あるので十分です。一方で LIST 操作（ファイル一覧の取得）は Class A にカウントされるため、管理画面でファイル一覧を頻繁にリロードすると消費が早まります。