> For the complete documentation index, see [llms.txt](https://docs.console.zenlayer.com/welcome/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.console.zenlayer.com/welcome/elastic-compute/networking/01-overview/05-aggregated-95th.md).

# Aggregated Burstable 95th Billing

## What it is

Aggregated Burstable 95th pools your ZEC EIPs into a single meter, then bills the monthly 95th-percentile of their combined bandwidth — the max of ingress and egress — minus a commitment floor that you always pay for regardless of usage.

Any ZEC EIP that picks this billing method joins the aggregation. There is no "same kind" or "same city" restriction at the billing level — the 95th is computed across all EIPs that opt into the method on your account.

***

## Why aggregation is the whole point

If you have 100 EIPs and you bill each one's 95th percentile independently, you pay for 100 separate peaks. In practice, those peaks don't happen at the same minute — batch jobs, user traffic, cron timers, all out of phase. When you aggregate first and take the 95th of the *sum*, the combined peak is almost always much smaller than the sum of the individual peaks.

Aggregated Burstable 95th is designed for fleet-scale workloads. The statistical averaging only produces meaningful savings when you have a large number of EIPs with uncorrelated peaks — typically 50 or more. For smaller deployments, [Flat Rate](/welcome/elastic-compute/networking/01-overview/04-flat-rate.md) or [Data Transfer](/welcome/elastic-compute/networking/01-overview/03-data-transfer.md) are simpler and usually more cost-effective.

***

## How billing works

At the end of the month:

1. The platform collects **5-minute** Mbps samples from every EIP opted into this method, for both ingress and egress.
2. The samples are **summed across EIPs** (so you get one sample per 5-minute interval, not one per EIP).
3. For each interval, the **max of ingress and egress** is taken.
4. The aggregated samples are sorted, and the top 5% are discarded.
5. The highest remaining sample is the **billable 95th**.
6. You pay for the **commitment floor** (Mbps) regardless of what the billable 95th turned out to be. The overage — the amount by which the billable 95th exceeds the commitment — is billed on top at the overage rate.

Setting a higher commitment usually unlocks a lower per-Mbps price on the commitment line, so it pays off when you know your sustained level.

***

## When this is the right choice

* **Large fleet (50+ EIPs).** The aggregation discount only becomes meaningful at scale.
* **Uncorrelated peaks.** If your EIPs peak at different times — user-facing workloads in different timezones, batch jobs on staggered cron schedules — the aggregated 95th will be a lot lower than the sum of individual ones.
* **You want one commitment line, not per-EIP pricing.** Simpler than sizing each EIP separately.

## When to reach for something else

* **Fewer than 50 EIPs.** The statistical discount is small; [Flat Rate](/welcome/elastic-compute/networking/01-overview/04-flat-rate.md) or [Data Transfer](/welcome/elastic-compute/networking/01-overview/03-data-transfer.md) will be simpler and usually cheaper.
* **All EIPs peak at the same moment.** Aggregation only helps when peaks are spread out. If everything is driven by one upstream event (say, a scheduled release), the aggregated peak is the sum of the individual peaks.

***

## Interval 95th: settling on each commitment change

By default the billable 95th is computed once over the whole month. **Interval 95th** is an optional variant of the aggregated meter: each time you change the commitment mid-month, the interval that just ended is settled immediately on an aggregated 95th computed **only from that interval's own 5-minute samples**, not the whole month. The next interval then starts a fresh 95th.

Reach for it when the fleet's traffic swings hard within a single month — for example, a 3-day flash sale or live event that spikes bandwidth, followed by a low, steady baseline for the rest of the month. Under the monthly 95th, the event's peak dominates the single whole-month value and inflates the overage charged for the quiet remainder. Interval 95th bills each period on its own realized 95th, so the quiet period is not charged against the event's peak.

Worked example — `500 Mbps` commitment = `$600`/month, `100 Mbps` commitment = `$300`/month, overage = `$1.50`/Mbps/month, in a 30-day month:

* **Apr 1 – Apr 10** — commitment `500 Mbps`, interval aggregated 95th = `600 Mbps`
  * Commitment fee = `$600` × 10/30 = `$200.00`
  * Overage fee = (`600` − `500`) × `$1.50` × 10/30 = `$50.00`
  * Subtotal = `$250.00`
* **Apr 11 – Apr 30** — commitment `100 Mbps`, interval aggregated 95th = `120 Mbps`
  * Commitment fee = `$300` × 20/30 = `$200.00`
  * Overage fee = (`120` − `100`) × `$1.50` × 20/30 = `$20.00`
  * Subtotal = `$220.00`
* **Monthly total = `$470.00`**

Under the default monthly 95th, the event peak (`600 Mbps`) would also apply to the quiet period, making its overage `(600 − 100) × $1.50 × 20/30 = $500.00` and the monthly total `$950.00`.

Interval 95th is not self-service. If your fleet has this kind of fluctuation, contact Zenlayer to arrange it.

***

## Relationship to Flat Rate and Data Transfer

Aggregated Burstable 95th replaces **per-EIP** public-network billing for every EIP that opts into it. You don't also get a per-EIP Flat Rate or Data Transfer line for those EIPs — the aggregated meter *is* the meter.