AWSからCloudflare Workersへ移すと何が変わる？｜サーバを所有しない設計とコストの考え方

移したのは「AWS全部」ではなく、常時稼働の実行基盤

まず分けたいのは、クラウドの会社を変える話と、実行モデルを変える話です。スライドでは、AWSをすべて捨てたのではなく、RDSをAWSに残したまま、Elastic Beanstalkで動いていたアプリケーション実行基盤だけをWorkersへ移しています。

これは中小企業にも参考になります。データベース、ファイル、認証、バッチ、監視まで一気に移す必要はありません。まず「ユーザーからのリクエストを処理するために、常時確保していた計算資源」を切り離せるかを見る方が現実的です。

CloudflareのWorkers料金ページでも、Paid planは最低月5ドルで、リクエストやCPU時間などの利用量を見ます。固定費が消える一方で、見るべきメーターが変わると捉えるのが安全です。

「安くなった」の裏側では、キャッシュの要件が変わっている

スライドで印象的だったのは、移行後すぐにWorkers KVの請求通知が来たという話です。「キャッシュだから念のためKVに置く」という判断が、数日で31.64ドルの請求として見える化され、保存先の棚卸しにつながっています。

CloudflareのDocsでは、Cache APIはデータセンター単位の一時的な保存として説明されています。一方、KVはグローバルな低遅延Key-Value Storeですが、データは中央ストアへ書かれ、アクセスされた場所でキャッシュされる仕組みです。つまり、同じ「キャッシュ」という言葉でも、範囲、寿命、整合性、課金の意味が違います。

Workersは、サーバの暗黙の前提をコードからあぶり出す

サーバ上で動いていたコードには、見えにくい前提が残ります。メモリは十分ある、DBは近い、タイムゾーンはサーバ設定で保証される。こうした前提は、Workersへ移すと制約として表に出ます。

Cloudflare Docsでは、Workersのメモリは128MBと明示されています。これを単なる厳しい制限と見るより、「全部取ってからメモリで加工する」コードを見直すきっかけと考えた方が実務に効きます。

移行前: SELECT * FROM large_table → アプリで絞る
移行後: WHERE / LIMIT / 必要な列 → 必要量だけ取る

移行前: サーバ設定で timezone = Asia/Tokyo
移行後: appDate() のような共通処理で意味を保証

HyperdriveとPlacementは、距離を消す魔法ではなく計測対象

RDSをAWSに残したままWorkersへ移す場合、DBとの距離が問題になります。Cloudflare Hyperdriveは、既存のPostgresやMySQLをWorkersから使うための仕組みで、AWS、Google Cloud、Azure、Neon、PlanetScaleなどのDBをサポートすると説明されています。

ただし、HyperdriveはN+1クエリを自動で直してくれるものではありません。Placementも同じです。Cloudflare Docsでは、Workerをバックエンドに近い場所で実行することでレイテンシを減らせる場合があると説明されていますが、採用するかどうかは計測で決める必要があります。

ここは、AI活用にもつながる話です。生成AIが「Smart Placementを使えばよい」と提案したとしても、それは答えではなく仮説です。任せることと、確認しないことは違います。

海外記事の流れは「アプリ全体を軽く持つ」方向へ進んでいる

Cloudflare Blogの「Your frontend, backend, and database — now in one Cloudflare Worker」では、フロントエンド、バックエンド、DBをWorkers上でまとめて扱う方向が紹介されています。Payload CMSの記事でも、従来型CMSは24時間動くサーバ、依存関係、ポート、ファイアウォール、保守、スケール調整が必要になりがちだと説明されています。

また、Matrix homeserverの実験記事では、VPS、PostgreSQL、Redis、リバースプロキシ、TLS証明書などの運用負担を「tax」と表現しています。もちろん、これらはすべての業務システムをWorkersへ移せるという意味ではありません。読み取るべきなのは、運用の重さをアプリケーション設計の段階から減らす流れです。

中小企業が最初に見るべきチェックリスト

AWSからCloudflareへ移すかどうかは、流行で決めるものではありません。今のサービスで、常時稼働の固定費、DBへの近さ、サーバ設定、キャッシュ保存、バッチ実行のどれに依存しているかを棚卸しするところから始めます。

i-Styleでは、クラウド移行は「サービス名を変える作業」ではなく、プロダクトの前提を見直す作業だと捉えています。持たない。必要なときだけ使う。使った結果を測る。この順番をチームの標準にできると、次の新規事業や小さな業務アプリも出しやすくなります。

よくある質問

まとめ

• check_circleAWSからCloudflareへの移行は、AWSを全部捨てる話ではなく、常時稼働の実行基盤を利用量中心へ変える話として考えると整理しやすいです。
• check_circleCache APIとKVは、共有範囲、寿命、整合性で使い分けます。何でもKVへ置くと、別の形でコストや設計負債が出ます。
• check_circleWorkersはメモリ、DB距離、ホスト環境依存をあぶり出すため、インフラ移行がコードレビューにもなります。
• check_circleHyperdrive、Placement、AIの提案は便利ですが、最後は計測で採用・不採用を決める必要があります。

「サーバを所有しない」は、責任を手放すことではありません。どこまで持たず、どこを測り、どこをコードで保証するかを決めることです。小さなチームほど、この設計判断が次の挑戦の速さにつながります。

参考リンク

• 参考: AWSからCloudflareへ移してわかった「サーバを所有しない」こと（Google Slides / 2026-08-08確認）
• 参考: Cloudflare Workers limits（Cloudflare Docs / 2026-08-08確認）
• 参考: How the Cache works（Cloudflare Docs / 2026-08-08確認）
• 参考: How KV works（Cloudflare Docs / 2026-08-08確認）
• 参考: Placement（Cloudflare Docs / 2026-08-08確認）
• 参考: Hyperdrive overview（Cloudflare Docs / 2026-08-08確認）
• 参考: Workers pricing（Cloudflare Docs / 2026-08-08確認）
• 参考: Your frontend, backend, and database — now in one Cloudflare Worker（Cloudflare Blog / 2026-08-08確認）
• 参考: Bringing Node.js HTTP servers to Cloudflare Workers（Cloudflare Blog / 2026-08-08確認）
• 参考: Building a serverless, post-quantum Matrix homeserver（Cloudflare Blog / 2026-08-08確認）
• 参考: Payload on Workers（Cloudflare Blog / 2026-08-08確認）

関連記事