Definition: Burst Rate
Burst Rate is the temporary performance ceiling a provider allows above your committed baseline—for example, spiking a 500 Mbps circuit to 1 Gbps for brief periods, or letting a storage volume burst from 1,000 to 3,000 IOPS when workloads surge. If you’re asking what is Burst Rate, think of it as headroom on demand: you contract for steady-state capacity, and the service lets you burst higher—within limits—so short spikes don’t throttle the business.
Where “Burst” shows up (it’s not just internet bandwidth)
A paragraph first: bursting appears across the stack, not just on WAN links.
- Network access: Dedicated Internet Access (DIA), Carrier Ethernet (E-Line/E-LAN), and Cloud Connect often publish a Committed Information Rate (CIR) with a burst rate the port can hit for short windows.
- Cloud compute & storage: General-purpose disks, object storage, and shared CPUs commonly use credit-based burst—you earn credits at idle, spend them to surge.
- Data protection windows: Backup or sync jobs may burst throughput so they complete in maintenance windows without permanently reserving high capacity.
Practically, burst lets you buy for the average while surviving the peak—as long as you know the rules.
How burst actually works (plain-English mechanics)
Two patterns dominate:
- Token bucket (networks): Your service fills a virtual “bucket” with tokens at the CIR. When bursts arrive, packets “spend” tokens to pass up to the burst rate. If you run out, a policer drops or re-marks traffic, or a shaper buffers to smooth the spike. Providers define burst size (how many tokens you can draw) and sometimes a distinct excess burst where packets are allowed but not guaranteed.
- Credit pools (storage/compute): Volumes or instances earn credits while under baseline. When work spikes, they spend credits to surge above baseline until the pool depletes, then slip back to baseline.
Key takeaway: burst is finite. It protects short spikes; sustained peaks need a bigger baseline.
Burst vs. Flat Rate (and 95th-percentile billing)
Before bullets, keep this simple: choose based on how long and how often you peak.
- Flat rate: You pay for a fixed, always-on capacity (e.g., 1 Gbps). Best for constant high usage, predictable SLAs, and workloads that must never shape.
- Burst with CIR: You pay for a lower CIR (e.g., 300 Mbps) with the ability to burst (e.g., up to 1 Gbps) briefly. Great when traffic is spiky and you can tolerate shaping once burst is spent.
- 95th percentile billing (some carriers/IX): Your bill reflects the 95th-percentile sample of usage over the month; brief spikes are ignored. If your peaks are short and infrequent, 95th can feel like “free burst.”
Podcast pick: Get More for Less: The Hidden Benefits of Choosing Burst Over Flat Rate Bandwidth breaks down real-world savings and what to watch in the fine print.
Benefits you can feel (and where teams misstep)
What you gain
- Right-sized spend: Buy the steady state you need; use burst to cover marketing campaigns, payroll closes, or patch nights.
- Fewer fire drills: Short spikes don’t trigger user complaints or timeouts.
- Faster batch windows: Backups, analytics, and sync jobs finish inside maintenance windows.
Where it goes wrong
- Sustained peaks on a tiny CIR: If “spikes” last hours, you’ll ride the policer. Users feel jitter and drops.
- Unknown burst limits: Teams assume “up to port speed,” but the provider caps lower. Ask for the burst rate and burst size in writing.
- Unprioritized traffic: If everything bursts equally, the wrong flows win. Add QoS so business-critical classes consume burst first.
- Credit starvation (storage/compute): Volumes that never idle never earn credits—burst disappears when you need it most.
Capacity planning with burst (a practical approach)
- Plot the real workload. Pull a month of flow/APM data and mark peak duration and frequency for top apps (checkout, EHR, UC/voice, SFTP).
- Choose the baseline by “area under the curve.” Size CIR to the typical band, not the extreme crest.
- Set the burst target by business impact. If call quality or payments break during spikes, your burst rate must cover those classes first.
- Use QoS to make burst count. Map DSCP or app IDs so real-time, interactive, and transactional flows get priority during burst—and shaping trims bulk sync first.
- Test with a change window. Generate controlled load, confirm the burst rate is honored, and watch where shaping begins.
Align the result to SLAs you can enforce and report on monthly.
How burst interacts with QoS, SD-WAN, and Cloud Connect
A paragraph first: bursting without control is just a faster way to congest yourself.
- QoS: Mark interactive classes (voice, telemedicine, trading) with strict priority. When you hit the burst ceiling, lower classes shape first so critical traffic remains clean.
- SD-WAN: Use policy-based forwarding to move bulk flows to an alternate path when a link burns through burst credits. Some SD-WANs detect transient loss/jitter and reroute in real time.
- Cloud Connect and Interconnection: Private on-ramps often support burstable virtual circuits. Design multiple VCs by app class so critical cloud paths retain burst even if bulk analytics are hammering their own VC.
Pricing and contract levers (read these lines twice)
- Document the numbers: CIR, burst rate, and burst size (or credit pool rules).
- Clarify shaping behavior: Drop vs. re-mark vs. buffer once burst is spent—and whether per-class QoS is preserved.
- SLA scope: Confirm whether latency/jitter SLAs apply during burst and under what conditions.
- Billing method: Flat MRC? 95th percentile? Any overage when bursting above a soft cap?
- Upgrade flexibility: Can you raise CIR mid-term without resetting the contract? This matters when spikes turn into the new normal.
For negotiation mindset and risk checks, see How a Private Cloud Provider Helped Escape Lock-In for vendor-flex patterns you can mirror on network contracts.
Use cases where burst shines
- Seasonal campaigns & launches: E-commerce traffic pops for minutes/hours, not months. Burst absorbs it.
- Patch Tuesday / OS updates: Thousands of endpoints download at once; burst pulls the spike forward in time so it finishes fast.
- Backup & DR windows: Nightly jobs hit storage/network hard. Burst lets them complete inside the window instead of bleeding into business hours.
- Healthcare imaging peaks: Uploads are lumpy; burst keeps radiology transfers snappy without over-buying baseline.
- Dev/test build storms: CI/CD bursts on commit; you need throughput now, not an all-year commit.
For healthcare cloud choices and bandwidth posture, see Private Cloud vs Public Cloud: What Works for Healthcare IT? and Top Advantages of Private Cloud You Should Know.
Monitoring and proving it works
A strong burst strategy is measured, not assumed.
- Per-class graphs: Track utilization by class against CIR and burst ceilings.
- Max hold time: How long did you sustain at burst before shaping? Does it match the contract?
- Loss/jitter during burst: Voice MOS and API p95 latency prove whether QoS is working under pressure.
- Storage/compute credits: Watch credit pools and refill rates so you know when you’ll run dry.
- Event stamps: Correlate burst events with business moments (campaign launches, closes) to justify capacity tweaks.
Deciding between burst and flat: a quick rubric
Choose burst when peaks are short (minutes), infrequent, and tolerant of shaping for non-critical traffic.
Choose flat when peaks are long (hours), daily, or mission-critical (voice trading floors, ICU telemetry) where any shaping hurts outcomes.
Mix both with multiple circuits/VCs: flat for critical classes; burst for bulk and episodic work.
Our blog Private Cloud vs Public Cloud: What Works for Healthcare IT? highlights how clinical needs drive stricter baselines, whereas back-office tasks can ride burst.
Implementation roadmap (pragmatic and phased)
- Instrument first. Pull 30–60 days of traffic and storage metrics; isolate top talkers and their peak duration.
- Set CIR & burst targets. For each link/VC/volume, pick a CIR that covers steady use and a burst ceiling that protects business-critical spikes.
- Wire QoS and classes. Mark interactive apps; shape backups/sync lower. Validate with synthetic and real traffic in a change window.
- Contract with clarity. Lock CIR, burst rate/size, shaping behavior, and SLA scope into the order form, not just marketing slides.
- Pilot with one site or workload. Choose a branch with spiky traffic or a backup job. Validate hold time at burst and user experience.
- Roll out and review monthly. Compare peaks to burst ceilings, note chronic overages, and either raise CIR or move flows off that path.
- Evolve your mix. As traffic patterns shift (e.g., more SaaS), move flat capacity where it matters and let the rest ride burst.
Risk and compliance notes
- SLA awareness: Some providers exclude burst conditions from latency/jitter SLAs. If real-time apps depend on burst, make sure SLAs do too.
- Change control: Backups or patch pushes that rely on burst should be scheduled to avoid overlap (two spikes at once defeat the point).
- Audit evidence: Keep reports showing CIR, burst ceilings, and performance during peaks as part of your GRC package—proof you engineered capacity on purpose, not by luck.
Related Solutions
Burst delivers the most value when it rides on top of the right underlay and is governed by smart controls. Dedicated Internet Access (DIA) provides deterministic paths where you can set a CIR and negotiate burst confidently, while SD-WAN steers flows so priority traffic benefits most from available headroom. For low-latency, predictable paths into cloud regions, Cloud Connect lets you burst where it matters most. If you need fixed, high-capacity headroom for short windows, Wavelength services can pin critical replication or backup jobs to optical lanes.
