費用の考え方

Vercel

主な課金の軸関数の実行（アクティブなCPU時間、メモリ、呼び出し回数）、画像最適化の変換回数、データ転送、ビルド

膨らみやすい要因画像最適化・SSRの多用、アクセス急増

対策支出上限を設定する。静的生成できるページは静的にする

Supabase

主な課金の軸コンピュート（インスタンスサイズ）、月間アクティブユーザー数、データ転送量、ストレージ

膨らみやすい要因toCでのユーザー増加、Storageからの大量配信

対策画像や動画の配信はCDN（Cloudflare Images等）に逃がす。規模が見えたら §24 の移行パスを検討する

Neon

主な課金の軸コンピュート時間、ストレージ

膨らみやすい要因常時起動の設定、使っていないブランチやプロジェクトの放置

対策自動停止（scale to zero）を有効にする。不要なブランチを削除する

Amazon RDS

主な課金の軸インスタンスの稼働時間、ストレージ、I/O、バックアップ

膨らみやすい要因過大なインスタンスサイズ、使っていない検証環境の常時稼働

対策検証環境は夜間停止する。リザーブドインスタンスを検討する

ECS Fargate

主な課金の軸vCPU・メモリの稼働時間

膨らみやすい要因過大なタスクサイズ、最小タスク数の設定しすぎ

対策実測に合わせて調整する。検証環境はSpotを使う

AWS Lambda

主な課金の軸リクエスト数、実行時間×メモリ（初期化にかかった時間も課金対象）

膨らみやすい要因常時トラフィックをLambdaで処理している

対策§23-2 の目安で常駐コンテナへ移す

NAT Gateway

主な課金の軸稼働時間、処理したデータ量

膨らみやすい要因プライベートサブネットからの外部通信量（イメージ取得、外部API）

対策VPCエンドポイントを使う。検証環境では構成を見直す

S3

主な課金の軸保存量、リクエスト数、データ転送

膨らみやすい要因外部への大量配信

対策CloudFront経由で配信する。配信が多いならR2を検討する

Cloudflare R2

主な課金の軸保存量、操作回数（外部への転送は無料）

膨らみやすい要因大量の小さなファイル操作

対策まとめて扱う

CloudWatch

主な課金の軸ログの取り込み量、保存期間、Logs Insightsでスキャンした量、カスタムメトリクス

膨らみやすい要因デバッグログの出しっぱなし、保存期間を無期限のままにする

対策ログレベルと保存期間を決める。参照頻度の低いロググループは低頻度アクセスのクラスにする

Datadog

主な課金の軸ホスト数、ログ量、カスタムメトリクス

膨らみやすい要因ログの全量送信、タグの組み合わせ爆発

対策送信するログを絞る。サンプリングを使う

Sentry

主な課金の軸エラー数、トレースのスパン数、セッションリプレイ数、ログ量

膨らみやすい要因同じエラーの大量発生、トレースの全量送信

対策トレースのサンプリング率を設定する。既知のノイズを除外する

Clerk／Auth0

主な課金の軸月間アクティブユーザー数

膨らみやすい要因toCでユーザーが急増

対策規模が見えたら §24 の移行パスを検討する

Algolia

主な課金の軸検索リクエスト数、レコード数

膨らみやすい要因入力のたびに検索する実装

対策デバウンスを入れる。規模次第でMeilisearchを検討する

LLM API

主な課金の軸入出力のトークン数

膨らみやすい要因長いプロンプトの繰り返し送信、不要な再生成

対策プロンプトキャッシュを使う。用途ごとに小さいモデルを使い分ける

Stripe／KOMOJU

主な課金の軸決済額に対する手数料率

対策決済手段ごとの料率を事前に確認する