CDN Bandwidth Commitment Pricing: When Committed Plans Save Money vs Pay-As-You-Go

Back in 2018 I got a panicked call from a media startup I'd been advising — their CDN bill had jumped from $4,200 to $11,800 in a single month after a viral video, and they were still on pay-as-you-go. They'd assumed “pay for what you use” was the safest option, but they'd blown past the point where a commitment would have saved them nearly 40%. If you're serving more than a few terabytes a month, that choice isn't just a billing preference — it's the difference between predictable costs and a nasty surprise.

How Bandwidth Commitments Actually Work (And Why Providers Push Them)

Think of a bandwidth commitment like a gym membership for data transfer. You agree to pay for a minimum amount of traffic every month — say 10TB or 50TB — whether you use it all or not, and in return your per-gigabyte price drops significantly. It isn't about reserved capacity in the way dedicated servers work; your traffic still bursts as needed. You're just promising a baseline level of spend, which gives the CDN provider predictable revenue to plan network capacity. I've had clients who were nervous about that “pay even if you don't use it” part, but when your traffic is relatively stable, that commitment is pure savings.

Most providers structure this as a 12-month contract with 95th percentile or flat monthly transfer metering. You commit to, for example, 20TB per month at $0.04/GB instead of the on-demand $0.08/GB rate. If you push 25TB, you pay the committed rate for the first 20TB and then a slightly discounted overage rate — often still cheaper than full pay-as-you-go. If you only push 15TB, you still pay for 20TB. That's the trade-off you have to model carefully. Understanding this model is a core part of CDN Egress Cost Modeling: Understanding and Reducing Your Largest Bill Component, because egress is usually 60-80% of what you’ll pay any provider.

What tripped up that startup I mentioned wasn't the concept, it was that they never calculated their baseline. They had six months of data showing they consistently served 18-22TB, but nobody had mapped that against committed pricing. Once we did, it was obvious they'd been overpaying for almost a year. Don't assume your provider will tell you when you've crossed that threshold — you'll need to track it yourself.

# Simple commitment savings check (Python)
# Compare monthly PAYG cost vs committed cost

def monthly_cost(transfer_tb, payg_per_gb=0.08, commit_tb=20, commit_per_gb=0.04, overage_per_gb=0.05):
    transfer_gb = transfer_tb * 1000
    commit_gb = commit_tb * 1000
    
    payg_cost = transfer_gb * payg_per_gb
    
    if transfer_gb <= commit_gb:
        committed_cost = commit_gb * commit_per_gb  # you pay for the full commit
    else:
        overage_gb = transfer_gb - commit_gb
        committed_cost = (commit_gb * commit_per_gb) + (overage_gb * overage_per_gb)
    
    savings = payg_cost - committed_cost
    return payg_cost, committed_cost, savings

payg, committed, saved = monthly_cost(22)
print(f"PAYG: ${payg:.2f} | Committed: ${committed:.2f} | Saved: ${saved:.2f}")
# PAYG: $1760.00 | Committed: $900.00 | Saved: $860.00

The Crossover Point: When Pay-As-You-Go Starts Costing You More

Pay-as-you-go feels safe because you’re not locked in. For new projects, seasonal sites, or anything doing under 5TB a month, it usually is the right call. You’ve got flexibility, no penalties for low-traffic months, and you can switch providers without worrying about contract terms. I've recommended PAYG to at least a dozen early-stage companies where traffic was unpredictable — one month 800GB, the next 4TB after a Product Hunt launch. In those cases, committing would've meant paying for capacity they didn't use.

The problem is that PAYG pricing is intentionally premium. You're paying for that flexibility. As soon as your traffic stabilizes, you’re leaving money on the table. The crossover point is typically around 70-80% consistent utilization of a commit level. If you commit to 10TB at $0.04/GB ($400/month) and your PAYG rate is $0.085/GB, you break even at just 4.7TB. Anything above that, and the commitment wins — even if you waste a little in a slow month. I tell teams to look at their last 6 months of bandwidth graphs; if your lowest month is still above 75% of a potential commit, it's time to switch. This is also where CDN Request Pricing Analysis: Reducing Per-Request Costs at Scale matters, since high request counts can offset bandwidth savings if you don't model both together.

Don't forget to factor in overage handling. Some contracts charge overage at the committed rate, others bump it to a middle tier. Ask for that in writing. I've seen a retailer get burned during Black Friday — their 30TB commit covered normal months beautifully, but their November overage was billed at full PAYG rates because the fine print wasn't clear. Always model your peak month, not just your average one.

// Estimate break-even point in JavaScript
function breakEvenPoint(commitTB, commitPricePerGB, paygPricePerGB) {
  const commitGB = commitTB * 1000;
  const commitTotalCost = commitGB * commitPricePerGB;
  // how many GB on PAYG would cost the same as the full commit?
  const breakEvenGB = commitTotalCost / paygPricePerGB;
  return {
    commitCost: commitTotalCost,
    breakEvenGB: Math.round(breakEvenGB),
    breakEvenTB: (breakEvenGB / 1000).toFixed(2)
  };
}

console.log(breakEvenPoint(10, 0.04, 0.085));
// { commitCost: 400, breakEvenGB: 4705, breakEvenTB: "4.71" }
// If you consistently serve >4.71TB, the 10TB commit is cheaper than PAYG

What Real Pricing Looks Like From 10TB to 100TB Per Month

Let’s put real numbers on it. These figures are blended averages I've seen across major CDN providers in 2023-2024 for North America/Europe traffic — your actual quotes will vary by region, provider, and contract length, but the pattern holds everywhere. The key is how steeply the per-GB price falls once you commit, especially between 10TB and 50TB. That first step is often where you'll see the biggest percentage savings, which is why so many mid-size sites see immediate ROI after moving off PAYG.

You can't look at bandwidth in isolation though. A low bandwidth rate doesn't help if you're paying $0.01 per 10k requests or overpaying for origin storage. When I'm helping a team choose a CDN Storage Cost Optimization: Tiering, Compression, and Lifecycle Policies strategy, we always model bandwidth together with request and storage costs. Also, performance choices affect how much bandwidth you actually need — proper cache-control headers and efficient compression as described in the HTTP Working Group Specifications and practical guidance on web.dev Articles can reduce your transfer by 20-30% before you even negotiate a commit.

If you're on the fence, start with a 10TB commit with a 12-month term and a reasonable overage rate rather than jumping to 50TB. You can usually renegotiate upward mid-contract if you're consistently exceeding your commit — providers would rather up-sell you than lose you. Track your 95th percentile and total transfer for three consecutive months first. That data gives you real negotiating power.

Putting Your Commitment to Work: Monitoring, Alerting, and Overage Control

Buying a commit is the easy part. Not blowing past it — or worse, leaving 30% of it unused — is where most teams mess up. I've seen companies sign a 50TB/month commit at $0.015/GB to save against a $0.03/GB pay-as-you-go rate, then get hit with a $900 overage bill because nobody was watching the burn rate until day 24. You can't manage what you don't measure daily.

Your provider's dashboard isn't enough. You need your own tracking that pulls usage via API every few hours and projects your end-of-month total. The math is simple: take your month-to-date TB, divide by days elapsed, multiply by days in the month. If that projected number is trending 15% over your commit by day 10, you need to act — either throttle non-critical traffic, shift to a lower-cost origin shield, or accept you'll pay overage at $0.04-$0.06/GB. Set alerts at 60%, 80%, and 95% of commit. And don't forget that most commits are use-it-or-lose-it; if you're tracking at 40% on day 20, you're literally paying for bandwidth you're not using.

# Simple commit burn-rate monitor using CDN provider API
import requests
from datetime import datetime

COMMIT_TB = 50  # Your committed monthly volume
COMMIT_RATE = 0.015  # $/GB
OVERAGE_RATE = 0.045 # $/GB - typically 2-3x commit rate

def check_commit_status(api_key, zone_id):
    # Pull current month usage (example: Bunny.net / Cloudflare style API)
    resp = requests.get(
        f"https://api.cdnprovider.com/v1/zones/{zone_id}/usage",
        headers={"Authorization": f"Bearer {api_key}"}
    )
    used_gb = resp.json()["bandwidth_gb_month_to_date"]
    used_tb = used_gb / 1024
    
    day_of_month = datetime.now().day
    days_in_month = 30  # simplify or use calendar.monthrange
    projected_tb = (used_tb / day_of_month) * days_in_month
    utilization = (projected_tb / COMMIT_TB) * 100

    print(f"Used: {used_tb:.1f}TB | Projected: {projected_tb:.1f}TB | Commit: {COMMIT_TB}TB ({utilization:.1f}%)")
    
    if utilization > 95:
        cost = (COMMIT_TB * 1024 * COMMIT_RATE) + ((projected_tb - COMMIT_TB) * 1024 * OVERAGE_RATE)
        print(f"ALERT: Projected overage! Est. cost: ${cost:.2f} vs PAYG ${projected_tb*1024*0.03:.2f}")
    elif utilization < 70 and day_of_month > 20:
        print(f"WARNING: On track to waste {(COMMIT_TB - projected_tb):.1f}TB of commit. Consider backfilling with logs or prefetch.")
    
    return projected_tb

# Run via cron every 6 hours and push to Slack/PagerDuty
check_commit_status("your_api_key", "your_zone_id")

Advanced Strategies: Hybrid Commits, Regional Splits, and Fixing Under-Utilization

If your traffic isn't flat — and whose is? — a single global commit is rarely optimal. The smartest setup I've deployed is a hybrid model: commit to your baseline and pay-as-you-go for the peaks. Say your baseline is 40TB but Black Friday pushes you to 85TB for two weeks. Don't commit to 80TB. Commit to 45TB at $0.014/GB and let the burst ride on PAYG or, even better, CDN Spot Pricing for Edge Compute: Leveraging Unused Capacity for Savings for non-critical batch jobs like image re-encoding. This keeps you from paying for ghost bandwidth 10 months a year while still locking in 35-40% savings on your predictable traffic.

Watch out for regional commits, too. A lot of providers will offer you a killer rate — like $0.012/GB in North America and Europe — but APAC and South America stay at $0.04-$0.08/GB because their transit costs are brutal. If 25% of your 100TB is APAC, that blended rate matters more than the headline number. Always ask for a regional breakdown before signing. For predictable edge workloads, this is where a dedicated CDN Reserved Capacity Pricing: Locking In Rates for Predictable Workloads strategy for compute + bandwidth together can beat a bandwidth-only commit by another 10-15%.

Troubleshooting under-utilization? That's the silent killer. If you're consistently using only 60-70% of a 60TB commit for three months straight, you're not saving money — you're donating it. Don't wait for renewal. Most providers will let you downsize once per term if you ask, or let you roll unused bandwidth into edge compute hours. Pair that with CDN Edge Compute Cost Optimization: Function Pricing Models and Efficiency Tricks to shift some of that wasted commit into Workers or Lambda@Edge invocations instead of flushing it. And if you're chronically *over*, negotiate overage upfront — getting it in writing at 1.5x your commit rate instead of the standard 3x can save you $1,200+ on a single 20TB overage month.

Frequently Asked Questions