Cost engineering: the five line items and the patterns that 10x them

Reading the bill: five line items

When your CFO forwards an invoice, can you answer “which meter caused this” in twenty minutes? If not, this section gives you the framework to do it every time. A serverless Next.js bill decomposes into five meters, and each one is driven by a different part of your architecture. Function GB-hours — execution time times allocated memory, summed over invocations — is driven by how much of your traffic renders dynamically and how heavy each render is. Image optimization bills per transformation: each unique combination of source URL, width, and quality is one resize; repeat requests are cache hits and cost roughly nothing, so the meter counts unique variants, not image views. Bandwidth/egress is dollars per GB out: client bundles, images, RSC payloads, API responses. ISR reads and writes meter operations against the cache store that backs the Full Route and Data Caches. Edge/middleware invocations bill per million requests that pass through middleware or edge routes.

Which line dominates depends on the app’s shape, and guessing wrong wastes an optimization quarter. A content site with good caching spends on images and egress, and its GB-hours round to zero. A logged-in SaaS dashboard is the inverse: everything renders dynamically per user, so GB-hours dominate and images are noise. A big ISR catalog pays a third profile: reads and writes on the cache store plus regeneration compute. The first discipline of cost engineering is the twenty-minute decomposition from the Hook — name the dominant line item before optimizing anything, because the team’s intuition is usually a release behind the truth.

The patterns that 10x a bill

Each of these is a mechanism, not a vibe — and each has a one-screen fix.

The optimizer as a public resize farm. /_next/image is an open HTTP endpoint. With a remotePatterns wildcard, anyone on the internet can feed it any image URL at any width and quality, and every unique combination is a billed transformation plus a cache entry you store. Hotlinkers and scrapers enumerate widths for free. Fix: an explicit allowlist in remotePatterns, trimmed deviceSizes/imageSizes (every extra width multiplies the variant space), and a raised minimumCacheTTL so re-transforms amortize.

Middleware on every static asset. Without a matcher, middleware runs on every request — including the 40-50 /_next/static chunks, images, and favicons each pageview pulls. Your invocation count is not pageviews; it is pageviews times assets-per-page. The canonical matcher excludes _next/static, _next/image, and favicon.ico, cutting the multiplier from ~46x to 1x — and removing the added latency hop from every asset fetch.

revalidate: 1 on a long-tail catalog. A trafficked page with revalidate: 1 regenerates up to once per second: 86,400 potential writes per page per day. A hundred hot pages is 8.6 million daily ISR writes — for content that actually changes weekly. The honest window plus tag-based on-demand invalidation gives fresher content than the panic value, at four orders of magnitude fewer writes.

The accidental-dynamic tax. One cookies() call in a shared layout opts every route under it out of the Full Route Cache. A heavy RSC tree that should render once per deploy now renders per request: 5M requests a month times 0.4 GB-s each is 2M GB-s for pages whose HTML never differs. This is the pattern from the Hook, and the bill is its only symptom — latency stays acceptable, pages look right, the meter just runs 24/7. Audit: list routes by render mode and challenge every dynamic marketing page.

Bundles re-downloaded every deploy. /_next/static/* filenames are content-hashed — built to be served with Cache-Control: public, max-age=31536000, immutable. A self-host reverse proxy that drops or weakens those headers makes every user re-download every chunk after every deploy: users times megabytes times deploys-per-week of pure egress, plus the latency regression nobody attributes correctly.

Per-route math, the crossover, and guardrails

Before you decide whether to self-host or move to a managed platform, ask: what does this specific route actually cost, and is that what you intended? Cost decisions are per route, so do the arithmetic per route. A dynamic /pricing page at 1M requests/month, 280 ms at 1.7 GB allocated, costs about 0.48 GB-s per request — 480k GB-s a month. At raw infrastructure rates that is single-digit dollars; through a managed platform’s per-request pricing the same shape lands at a multiple of that — but the comparison that matters is against the alternative: rendered once per deploy and served from the CDN, the same page costs approximately zero compute and pennies of egress. The ratio between “dynamic by accident” and “static as designed” is effectively infinite, which is why the accidental-dynamic tax deserves its own audit. Run this math in the other direction too: a route that genuinely personalizes every response is supposed to cost GB-hours — the goal is a bill that matches intent, not a minimal bill.

The self-host crossover from the deployment unit gets sharper once you decompose. Steady traffic — say a sustained 80 req/s with bounded spikes — is flat-capacity-shaped: a pair of VMs plus a commodity CDN lands near 10-15% of a managed bill at the same profile, and the image pipeline (sharp on your own CPU behind CDN caching) is usually the single biggest line you can repatriate. Spiky, low-floor traffic inverts the math: per-request pricing beats paying for idle capacity, and the operational cost of running the fleet eats the savings. The decomposition tells you which shape you are — and whether to move everything, nothing, or just the image line.

Guardrails make this a system instead of a heroic quarterly audit. Spend alerts per line item, not per total — the Hook’s 14x image jump was a 3.4x total, and a 40x jump on a small line hides inside a 1.5x total for weeks. Cost review in the PR template for new routes: four questions — static or dynamic, and is that intentional? what request APIs does it touch? does it add image sources or widths? does it change the middleware matcher? Each question maps to one of the five meters. The monthly top-10 ritual: rank routes by requests times GB-s (add transformation counts for image-heavy apps), read the list out loud in fifteen minutes, and fix the head. The list is boringly stable — which is exactly why the one month it changes is the month you catch the regression early.