When bandwidth pooling makes sense

A multi-server fleet rarely uses every node at the same time. One region may spike while another is quiet; one channel may surge while a VOD node idles.

A pool lets the commercial capacity model follow the fleet instead of trapping unused capacity on the wrong server.

A bandwidth pool does not change each server's physical port. A 10 Gbps server cannot push 40 Gbps just because the total pool is larger.

Treat pooling as fleet capacity planning and billing, not a replacement for correct per-node sizing.

Alerting thresholds, upgrade paths, overage handling, eligible servers, and measurement windows should be confirmed before relying on a pool for production traffic.

The public page describes the model; the written quote should define the commercial rules.

Suppose two servers on 10 Gbps ports send 8 and 2 Gbps at noon, then 3 and 7 Gbps in the evening. The combined peak in these samples is 10 Gbps, not 15. If both nodes instead hit 8 and 7 Gbps at noon, a 12 Gbps pool falls short even though neither port is full.

Before requesting a shared bandwidth pool, align both traffic series to the same time zone and sampling interval. Repeat with one node out of service. A surviving 10 Gbps port cannot send 12 Gbps simply because the fleet has capacity left.