Understanding and optimizing content delivery network pricing

Tim Koschützki

Co-founder · Berlin, Germany · Show bio

Content delivery networks (CDNs) are essential for optimizing application and website performance in today's global digital landscape. However, understanding the pricing models behind CDNs can be complex. This guide breaks down current CDN pricing structures, discusses key cost drivers, and offers practical strategies to optimize your CDN expenses.

What is a CDN?

A Content Delivery Network is a distributed group of servers strategically positioned around the globe to deliver content quickly and reliably. By caching assets closer to end-users, CDNs reduce latency, improve load times, and enhance the overall user experience.

Overview of CDN pricing models

CDN providers typically offer several pricing models to fit various needs. Rate cards change often enough that any table printed here would mislead you within months, so what follows is the shape of each model plus the page that carries the authoritative numbers:

Check the current figures directly (links checked September 2026): Cloudflare plans⁠, Amazon CloudFront pricing⁠, Fastly pricing⁠, and Akamai pricing⁠. Most providers also publish a calculator, which beats any static table for estimating your own bill.

Key factors influencing CDN costs

Bandwidth and data transfer

Bandwidth usage is generally the largest component of CDN expenses. High-resolution media, large file downloads, and streaming services can drive up data transfer costs. Every metered provider also charges a different per-GB rate per delivery region, and the spread is wide enough to change a budget. Any percentage quoted here would be stale by the time you read it, so take the regional breakdown from the rate card itself: both CloudFront pricing⁠ and Fastly pricing⁠ publish a per-region table (checked September 2026).

Geographic distribution

Delivery costs vary based on geographic location due to differences in infrastructure and operational expenses. Understanding your audience's geographic distribution can help you optimize server placement and routing strategies, ultimately reducing costs.

Feature sets and security

Modern CDN providers bundle advanced security and performance features that can affect pricing. Many now offer free, automated SSL/TLS certificate provisioning, robust Layer 7 DDoS protection, and integrated Web Application Firewall (WAF) options. These features enhance security without detracting from performance.

Edge computing and modern features

Many CDNs now incorporate edge computing capabilities, enabling real-time data processing and serverless functions at the network edge. This approach lets you execute custom code closer to your users, dynamically optimizing content delivery while reducing latency.

Transforming image bytes inside the edge function itself is the tempting version of this, and also the expensive one: you pay CPU time on every request, and the result is awkward to cache because it depends on a request header rather than on the URL. The cheaper arrangement puts the variant in the URL. Your origin or your build step publishes /images/w/320/photo.avif next to /images/w/1024/photo.avif, and all that is left is picking which one to ask for. This Node.js example uses negotiator (npm install negotiator) to honor media ranges, quality preferences, and explicit format rejections in the request's Accept header:

import Negotiator from 'negotiator'

// URL selection only. This converts nothing: your origin (or your build step)
// must already publish /images/w/320/... and /images/w/1024/... in each format,
// and your templates have to request the URL this returns. Because width and
// format land in the path, they are part of the cache key with no negotiation.
const WIDTHS = new Map([
  ['small', '320'],
  ['large', '1024'],
])
const SOURCE_EXTENSION = /\.(jpe?g|png)$/i
const PUBLIC_PREFIX = '/images/'
const VARIANT_PREFIX = '/images/w/'

function buildVariantUrl(requestUrl, accept) {
  const url = new URL(requestUrl)

  // Rewrite only the prefix that is public and has variants published under it,
  // and never rewrite a variant URL again: /w/1024/w/1024/... does not exist.
  if (!url.pathname.startsWith(PUBLIC_PREFIX)) return null
  if (url.pathname.startsWith(VARIANT_PREFIX)) return null

  const extension = url.pathname.match(SOURCE_EXTENSION)?.[1].toLowerCase()
  if (extension === undefined) return null

  // Prefer the original format when the client only offers a wildcard. Do not
  // turn a PNG into JPEG (losing alpha), or select a format rejected with q=0.
  const formats = new Map([
    [extension === 'png' ? 'image/png' : 'image/jpeg', extension],
    ['image/avif', 'avif'],
    ['image/webp', 'webp'],
  ])
  const accepted = new Negotiator({ headers: { accept: accept ?? '*/*' } }).mediaType([
    ...formats.keys(),
  ])
  const format = formats.get(accepted)
  if (format === undefined) return null

  // A Map, so an unexpected ?w= value cannot reach an inherited object key such
  // as 'constructor' and produce a width the origin never published.
  const width = WIDTHS.get(url.searchParams.get('w')) ?? WIDTHS.get('large')
  const name = url.pathname.slice(PUBLIC_PREFIX.length).replace(SOURCE_EXTENSION, `.${format}`)

  const variant = new URL(url)
  variant.pathname = `${VARIANT_PREFIX}${width}/${name}`
  // Drop the query string outright. Nothing in it changes these bytes, and a
  // surviving ?utm_source= would fragment the cache once per campaign.
  variant.search = ''
  return variant.toString()
}

Be clear about what that is and is not. It is URL selection, so it belongs wherever you build image URLs: a template helper, a build step, or an edge function that answers with a redirect. It does not encode an image, and it does not deploy anything to a provider. The origin still has to generate and serve every variant, and the frontend still has to request the returned URL, because that is what puts the width and the format into the cache key.

The alternative, serving one URL and marking it Vary: Accept, is weaker than it looks. Cloudflare documents per-variant caching of a Vary: Accept image response as a separate feature, Vary for Images⁠, listed as available on Pro, Business and Enterprise and not on Free (checked September 2026). So the header alone is not what buys you per-format cache entries; check what your own plan and provider actually do before relying on it. Keeping the format in the path needs no such setting anywhere.

The cost lesson generalizes: every byte an edge function rewrites is CPU time you are billed for, and a response whose content depends on a request header is a response your CDN may decline to cache at all.

Implementing effective caching

Effective caching minimizes unnecessary data transfers and reduces overall CDN costs. Two rules do most of the work, and both are narrower than "cache static assets for a long time".

First, a one-year immutable lifetime is only safe when the URL changes whenever the bytes change. Build tools give you that for free through content hashes such as app.7f3a91c2.js. Applying the same header to /logo.png means an edge somewhere will keep serving last year's logo, and you cannot call it back.

Second, decide cacheability from the route, never from the file extension. /account/avatar.jpg and /api/private.css both end in an extension a naive rule calls static, and both can carry bytes that belong to one signed-in user. Attaching the policy to the mount that serves your build output makes that mistake unrepresentable:

npm install express
npm pkg set type=module

// server.js - run with: node server.js
import express from 'express'

// A content hash in the filename is what makes 'immutable' safe: the URL is a
// promise that these bytes never change.
const FINGERPRINTED = /\.[0-9a-f]{8,}\.(?:css|js|jpe?g|png|gif|webp|avif|woff2?)$/

function cacheControlFor(filePath) {
  if (FINGERPRINTED.test(filePath)) return 'public, max-age=31536000, immutable'

  // Unversioned build output: let the edge serve it, but revalidate every hour
  // so a replaced file is picked up in an hour rather than in a year.
  return 'public, max-age=3600, stale-while-revalidate=86400'
}

const app = express()

// Everything under dist/assets is build output, so it is public by
// construction. setHeaders runs once the file has been resolved, which is why
// filePath is the real path rather than a guess made before routing.
app.use(
  '/assets',
  express.static('dist/assets', {
    setHeaders: (res, filePath) => {
      res.setHeader('Cache-Control', cacheControlFor(filePath))
    },
  }),
)

// Anything the mount did not serve is private until proven otherwise, including
// a 404 for a missing asset and every error below.
app.use((_req, res, next) => {
  res.setHeader('Cache-Control', 'no-store')
  next()
})

app.get('/account/avatar.jpg', (_req, res) => {
  // Per-user bytes in a real app. The point here is the header above: the path
  // ends in .jpg, and it still must not reach a shared cache.
  res.type('jpg').send('per-user bytes')
})

app.get('/api/private.css', (_req, res) => {
  res.type('css').send(':root{--brand:rebeccapurple}')
})

app.listen(3000)

Performance monitoring and optimization

Monitoring key performance metrics is crucial for controlling CDN costs. By tracking response times, cache hit ratios, data transfer sizes, and status codes, you can identify inefficiencies and fine-tune your content delivery. A probe worth trusting has to do four things the one-liner version skips: bound itself in time, treat a non-2xx as a failure rather than as a healthy sample, read the body so the number it reports is a transfer time instead of a time to first byte, and release the connection on every path.

// edge-monitor.js - run with: node edge-monitor.js
import { setTimeout as sleep } from 'node:timers/promises'

async function probeEdge(url, timeoutMs = 5000) {
  const start = performance.now()
  const response = await fetch(url, { signal: AbortSignal.timeout(timeoutMs) })
  try {
    // A 503 from the edge is a monitoring signal, not a sample to average in.
    if (!response.ok) return { url, ok: false, status: response.status }

    // Reading to completion is what makes `duration` a transfer time. Awaiting
    // fetch() alone stops at the response headers.
    let bytes = 0
    if (response.body) {
      for await (const chunk of response.body) bytes += chunk.byteLength
    }
    return {
      url,
      ok: true,
      status: response.status,
      bytes,
      duration: performance.now() - start,
      cache: response.headers.get('cf-cache-status') ?? 'unknown',
    }
  } finally {
    // A no-op once the body has been read. On the error path nothing consumed
    // it, and an unread body holds the connection until the GC gets to it.
    if (!response.bodyUsed) await response.body?.cancel()
  }
}

// Log the origin and path, never the query string: a monitored URL can carry a
// signed token, and these lines end up in a log sink other people can read.
function formatProbe(result) {
  const { origin, pathname } = new URL(result.url)
  if (!result.ok) {
    // An error name, not a message: fetch puts the full URL in `message`.
    return `${origin}${pathname} FAIL ${result.error ?? `HTTP ${result.status}`}`
  }
  const duration = `${result.duration.toFixed(0)}ms`
  return `${origin}${pathname} ${result.status} ${duration} ${result.bytes}B cache:${result.cache}`
}

// Sequential and stop-aware. setInterval with an async callback fires on a
// fixed clock whether or not the previous probe has finished, so a slow edge
// quietly turns your monitor into a load generator against it.
async function monitorEdge(url, signal, intervalMs = 300_000) {
  while (!signal.aborted) {
    const result = await probeEdge(url).catch((error) => ({ url, ok: false, error: error.name }))
    console.log(formatProbe(result))
    // Aborting the sleep rejects. That rejection is the stop signal, not a
    // failure, and the loop condition above picks it up on the next pass.
    await sleep(intervalMs, undefined, { signal }).catch(() => {})
  }
}

const controller = new AbortController()
process.once('SIGINT', () => controller.abort())
await monitorEdge('https://cdn.example.com/assets/app.js', controller.signal)

cf-cache-status is Cloudflare's header. Other providers use their own: Fastly and Akamai report cache state in X-Cache, and CloudFront uses X-Cache plus X-Amz-Cf-Pop. Read whichever your provider documents, and treat a missing header as unknown rather than as a miss.

Two honest limits. duration is a single synthetic sample from wherever the process runs, so it measures your path to one PoP and nothing about your users' paths; treat it as a regression alarm, not as a latency figure to report. And a probe is itself a billable request, which is why the default interval here is five minutes rather than five seconds.

Strategies for optimizing CDN costs

Optimizing CDN expenses requires both minimizing data transfers and leveraging caching effectively.

Minimizing unnecessary data transfers

Reducing payload sizes through compression can substantially lower costs. Add compression to the server.js above, before the static mount, so the files it serves are compressed on the way out:

npm install compression

// Add to server.js, directly after `const app = express()`.
import compression from 'compression'

app.use(
  compression({
    filter: (req, res) => {
      if (req.headers['x-no-compression']) return false
      return compression.filter(req, res)
    },
    level: 6,
    threshold: 0,
  }),
)

Compressing in your origin is the fallback, not the goal: most CDNs can compress at the edge and cache both encodings, which saves you the CPU on every miss. Check what your provider already does before paying for it twice.

Leveraging caching effectively

Beyond per-request headers, normalize cache keys at the edge. Marketing query strings such as ?utm_source=newsletter produce a distinct cache entry per campaign for identical bytes, which quietly turns hits into misses. Every major CDN offers a cache-key or query-string-handling setting to strip parameters that do not change the response; configuring it is usually the single cheapest cache-hit-ratio win available. The buildVariantUrl helper earlier applies the same idea at the origin by refusing to carry a query string into a variant URL at all.

Conclusion

Optimizing CDN costs involves balancing performance with efficiency. By understanding various pricing models, monitoring key metrics, implementing effective caching strategies, and leveraging edge computing features, you can develop a cost-effective approach to content delivery.

At Transloadit, we are committed to helping developers build efficient and cost-effective applications. For powerful file uploading and processing solutions, check out Transloadit.