How to Size IP Camera Bandwidth Without Underspeccing the Switch Uplink
The aggregation surprise
Most camera-bandwidth tools hand you a per-camera number and stop there. Most surveillance projects that fail in production fail because nobody multiplied that number by the camera count, then again by the oversubscription factor of a switch uplink that is also carrying voice, workstations, management traffic, and a nightly backup. A sixteen-camera install at four megabits each is sixty-four megabits of camera traffic — comfortably inside a one-gigabit uplink on paper. In practice that uplink shares queue depth with everything else on the network, and the cameras start dropping frames at eleven at night when the backup kicks off. By month eight the network is dropping frames during business hours and the integrator is getting called back.
The per-camera number is the easy part. Aggregate sizing — and the loads competing with the cameras on the same switch — is where the design earns its accuracy. This calculator does the aggregation math: it multiplies the per-camera sustained bitrate by the camera count, applies the headroom factor you choose, and recommends the smallest switch-uplink class that carries the result. The rest of this article explains the inputs so the number it produces survives contact with the rest of the network.
The bitrate times camera-count math
The aggregate scales linearly with camera count in one direction; where designs drift is what you count per camera. The per-camera sustained bitrate comes from the same vendor curve the storage calculator uses — a 4-megapixel camera in H.265 sits around two megabits per second sustained at thirty frames, an H.264 stream roughly double that, and a 4K stream several times higher. The aggregate is simply that per-camera figure times the number of cameras, and that product is the load the access switch presents to its uplink.
Three terms most calculators omit stack on top of the obvious main-stream total. Sub-streams, recorded for preview or mobile clients, add roughly ten to fifteen percent when the recorder records both streams. Audio adds thirty-two to one-hundred-twenty-eight kilobits per channel when enabled — small per camera, but it accumulates across sixteen or more cameras. And variable-bitrate streams climb to their constant-bitrate ceiling during motion-heavy moments, so the sustained aggregate from variable bitrate is typically only fifty to seventy percent of the ceiling-times-count figure, but the bursts still reach the ceiling for seconds at a time.
Two fifty-to-seventy-percent factors compound here, and most tools show neither. On the camera side, variable-bitrate sustained is about fifty to seventy percent of the constant-bitrate ceiling. On the switch side, real-world sustained throughput is typically fifty to seventy percent of the theoretical line rate because of backplane, buffer, and processing overhead.[1] Plan the aggregate budget against both factors, not just the on-paper total — the uplink gates the bursts, not the long-run average.
Switch uplink sizing — when one gigabit stops being enough
A one-gigabit uplink delivers about five hundred to seven hundred megabits of sustained throughput in practice, applying the switch-side factor above.[1] At a typical H.265 1080p sustained bitrate of two to three megabits per camera, that is roughly eighty to one hundred fifty cameras before the uplink saturates — assuming surveillance is the only traffic on the port. In a mixed environment with voice, workstations, and management traffic, the practical ceiling drops to thirty to sixty cameras before queue-depth competition starts dropping frames during busy moments.
A rule of thumb for systems over sixteen cameras is to plan dedicated gigabit uplinks between the edge switch and the core or recorder; shared uplinks above that threshold start to gate the burst aggregate. The subtler trap is the aggregation layer: most installs spec the access switch the cameras plug into carefully and forget the distribution-layer uplink, where camera traffic merges with workstation traffic on the way to the core.[2] The bottleneck is often there, not at the camera edge. For deployments above eighty cameras or any mixed-traffic install, model both layers separately — and remember the fifty-to-seventy-percent throughput factor applies at every layer.
Oversubscription — sharing the uplink
A twenty-four-port access switch with a single one-gigabit uplink and twenty-four gigabit access ports is oversubscribed twenty-four to one. That ratio works for general data because workstations rarely talk at line rate. It does not work for surveillance, where cameras stream sustained traffic around the clock. General data tolerates four-to-one up to twenty-to-one; real-time voice tightens to one-and-a-half-to-one or two-to-one; surveillance video belongs in that same tight band of one-and-a-half-to-one to two-to-one because it is sustained and carries periodic key-frame bursts. A mixed switch carrying data, cameras, and voice lands around two-to-one to three-to-one, depending on the quality-of-service policy.
Two practical implications follow. First, camera port density matters: a twenty-four-port switch fully populated with 1080p cameras at three megabits each is seventy-two megabits to the uplink, comfortably inside one gigabit, but the same switch carrying voice and workstations alongside cameras hits the oversubscription ceiling far earlier even though the aggregate megabits look fine. Second, when cameras cannot move to their own network segment, quality-of-service marking is the fix — classifying camera traffic at the access port so it survives congestion. A separate hidden load is camera management traffic — firmware updates, configuration sync, discovery broadcasts — which bursts unpredictably and is counted in no per-camera bitrate spec; field practice is to plan five to ten percent of additional headroom above the sized aggregate to absorb it.
WAN considerations — the cloud-failover gotcha
Cloud recording platforms impose a sustained-upload constraint on top of the LAN aggregation problem. Continuous-record guidance is commonly about four megabits of upload per camera, though an H.265 1080p stream typically sustains two to three. The constraint bites because most small-business cable plans are asymmetric: ten to thirty-five megabits of upload even on advertised three-hundred-megabit-to-gigabit download tiers, and voice, business file sync, and cloud collaboration all share that same upload pipe. A twenty-megabit upload carrying sixteen megabits of camera traffic leaves four megabits for everything else — workable for a small office with no active video conferencing, and a failure the moment anyone joins a call.
Two architectural choices recover the situation. A hybrid local-then-cloud design makes the local recorder the primary record and runs cloud sync off-hours or on motion events only, dropping sustained WAN demand to a fraction of continuous-record; this is the practical default for small-business cloud surveillance today. Symmetric fiber, where available, makes the upload constraint disappear outright. If the install is on asymmetric internet and needs cloud retention, size the camera count to the upload constraint first, not to the cloud plan storage tier — the upload pipe, not the LAN, is the binding limit.
Validate at commissioning
The calculator gives a defensible starting number, not the final number. Four habits separate integrators who get called back from those who do not. Measure the actual sustained megabits at the switch uplink under representative load — capture aggregate utilization for at least seven days, long enough to catch the backup window, the management-traffic spikes, and the busiest hour; if the ninety-fifth-percentile measured value exceeds seventy percent of the uplink line rate, the design is already at its ceiling.[3]
Spec the uplink one tier above the calculator recommendation when the design sits within thirty percent of a class ceiling — cameras get added, resolutions get upgraded, and the cost delta between switch classes is rarely the line item that kills a bid. Monitor per-port utilization, not just the aggregate, because a single port at one hundred percent can drop frames while the total still looks healthy. And document the assumptions — the oversubscription ratio, the non-camera traffic mix, the cloud-failover mode, the sub-stream recording state, the quality-of-service markings — so that three years from now the design rationale is recoverable. The calculator is the starting point; the field is where the number earns its accuracy.