How to Size a Multi-Site VMS Architecture for 12 Buildings on Mixed WAN

How to Size a Multi-Site VMS Architecture for 12 Buildings on Mixed WAN

Multi-site VMS design goes wrong in the same place almost every time: someone sizes it like one big building instead of twelve small ones connected by links they don't control. The camera math is easy. The architecture question — what records where, what crosses the WAN, and what happens when a link drops for six hours — is where the project either becomes a system the customer trusts or a standing service ticket. I've rebuilt enough of the second kind to have a repeatable sizing process. Here it is, with a worked example, sized for the job that shows up constantly: around a dozen buildings on a mix of fiber, cable broadband, and the occasional cellular or point-to-point link.

Step 1: Define Centralized vs Federated

Decide the recording topology before you touch a bandwidth calculator, because everything downstream depends on it. Centralized means cameras stream across the WAN to recorders at a head end; it minimizes per-site hardware and puts all storage in one room, and it lives or dies on link quality. Federated means each site records locally and the WAN carries only management traffic, live view on demand, and clip export; the head end runs a directory or federation layer that presents twelve sites as one system to the operator. There's a hybrid worth naming: local recording with selective cloud or head-end archiving of flagged events only.

My default for mixed WAN is federated, and I hold that position until someone shows me twelve links that are all fiber with real SLAs. The arithmetic is unforgiving: a 40-camera building at a modest 6 Mbps per camera is 240 Mbps of continuous upstream. On a 1 Gbps fiber link that's plausible; on a 200/20 cable circuit it's not even a conversation — the upstream is 8 percent of what you need. Centralized architectures on consumer-grade circuits are how a customer ends up with 3 fps recordings and a purple face. Record at the edge, search across the federation.

Step 2: Per-Site Recording Plan

Size each building as its own standalone system first. Per camera: resolution, codec, frame rate, and a realistic bitrate — I plan 4–8 Mbps for 4MP H.265 continuous at 15 fps, 10–16 Mbps for 4K, and I add 25 percent to whatever the manufacturer's calculator says because scene complexity always runs hotter than the demo footage. Retention drives disk: cameras × average bitrate × retention days. A 30-camera elementary school at an average 6 Mbps and 30-day retention needs roughly 58 TB usable; with RAID-6 overhead and a hot spare you're speccing an 8-bay recorder with 12–16 TB surveillance-rated drives, not a desktop NVR. Hanwha's WAVE-based recorders and the Hanwha catalog generally are what I reach for on school-district work when the camera estate is already Hanwha — single-vendor camera-to-recorder support matters more on multi-site jobs because you don't have a tech standing in front of the rack when something misbehaves. Whatever recorder line you choose, spec the drives from the surveillance-rated tier — the NVR hard drives class built for 24/7 sequential write — and keep one cold spare drive per site model in a drawer.

Step 3: WAN Bandwidth Budget

Now budget what actually crosses the WAN in a federated design. Four flows: management and health telemetry (small, 50–200 kbps per site steady); live view pulled by the central operator (one stream per watched camera — and this is where you enforce that remote live view uses the secondary stream, 1–2 Mbps, not the 12 Mbps recording stream); event clips and alarm push (bursty, a few MB per event); and investigation export (the elephant — pulling an hour of 8-camera footage at 6 Mbps average is about 21 GB, which on a 20 Mbps upstream takes over two hours). Budget each site's upstream for: management + (expected concurrent live views × secondary-stream bitrate) + one export in progress, and confirm the result fits inside half the measured upstream, because these circuits carry the site's other traffic too. Where a site's link can't clear that bar — cellular-backhauled portables, the leased building with 10 Mbps up — plan for scheduled overnight trickle export and set operator expectations in writing.

Step 4: Cross-Site Search Latency

Operators judge the system by how search feels. A federated search fans the query out to every site recorder and merges results; on healthy links that round trip adds tens to a few hundred milliseconds and nobody notices. On a congested or high-latency link (cellular at 80–120 ms, a saturated cable circuit at 200 ms+ under load), thumbnail strips and timeline scrubbing get painful, and the operator starts skipping that site — a quiet failure that only shows up when an investigation misses footage. Two mitigations that work: enable thumbnail/metadata caching at the head end where the platform supports it, and QoS-mark the VMS management and search traffic above the site's general internet traffic. Set a measurable target while you still have leverage: sub-2-second timeline paint for any single site, and test it during the school day, not at 7 a.m. on commissioning morning.

Worked Example: 12-Building School District

The concrete version. District: 1 high school (110 cameras), 2 middle schools (60 each), 8 elementaries (30 each), 1 admin/bus depot (25 cameras). Total 555 cameras. WAN: district-owned fiber to the high school and middles (1 Gbps), 200/20–300/30 cable broadband to six elementaries, 100/20 to two, and a 50 Mbps point-to-point radio to the depot. Design: federated, one recorder cluster per building. High school: two recorders (split by wing) totaling ~200 TB usable for 30-day retention at an average 5.5 Mbps per camera. Middles: one 120 TB recorder each. Elementaries: one 60 TB recorder each. Depot: 45 TB. Head end at the high school runs the federation layer, a failover recording server for the two fiber-connected middles only (failover across broadband is theater), and the alarm/health dashboard. Remote live view locked to secondary streams at 1.3 Mbps. Budgeted steady WAN per elementary: under 4 Mbps — comfortably inside a 20 Mbps upstream with room for an export. District SRO station gets a saved layout of entrance cameras across all 12 sites: 24 concurrent secondary streams ≈ 31 Mbps of aggregate inbound at the head end, trivial on the fiber side. Total usable storage across the district: roughly 1.0 PB, all of it writing locally.

Multi-Site Architecture Field Checklist

Step 5: Failover and Investigation Paths

Failover is where multi-site designs get overpromised. True hot failover recording across a WAN requires the standby server to ingest the site's full camera load remotely — which we just established most links can't carry. So be honest in the design doc: fiber-connected sites can fail over to the head end; broadband sites get resilient local hardware instead — RAID-6, dual power supplies, UPS with 20+ minutes of runtime, and edge SD recording on entrance-critical cameras as the last-ditch buffer (a 512 GB card holds roughly a week of one camera at 6 Mbps). The investigation path needs the same honesty. Decide now: does an SRO or detective pull footage from the head end, or drive to the site? If it's the head end, the export bandwidth math from Step 3 becomes an SLA. The failure I keep seeing on rebuilt districts is an investigation workflow nobody designed — a vice principal with local admin on one recorder, USB-exporting evidence with no chain of custody and no audit trail. Give investigators one sanctioned path, audited, through the federation layer.

Two supporting details that make or break the federation in practice. First, time: every recorder and camera disciplined to a single NTP source, holding within a second across sites — because a cross-site investigation reconstructing a vehicle moving between buildings falls apart when site clocks disagree by 40 seconds, and I have watched a detective lose an afternoon to exactly that. Second, network segmentation: the camera VLAN at each site should never route to the district's general network, and the only cross-site paths are recorder-to-head-end on defined ports. That's a security posture, but it's also an operational one — it keeps student Chromebook traffic from ever competing with an evidence export.

Step 6: License Model Considerations

VMS licensing on multi-site jobs has real five-year cost consequences. Per-camera perpetual licenses with annual upgrade plans behave differently at 555 cameras than the brochure suggests: ask specifically how failover server licenses count, whether the federation layer is licensed separately, and what happens to licensing when a site's recorder is replaced (some platforms tie licenses to hardware IDs and make migration a support-ticket ordeal). Camera-vendor-aligned platforms often bundle device licenses with hardware — on an all-Hanwha estate the recorder-bundled path prices out very differently than a third-party VMS with per-channel licensing, sometimes by tens of thousands of dollars over five years. Whichever way you go, quote year-two-through-five support costs in the proposal — a district business office that discovers surprise renewal costs in year two remembers who didn't mention them. Plan the rollout in phases that match the license structure too: commissioning four buildings a summer for three summers is a very different licensing conversation than a single 555-camera activation, and some volume tiers only trigger if the purchase lands in one order. For a structured way to compare platforms on these axes, the VMS software buying guide covers the licensing and federation questions in more depth.

Where This Fits in a Deployment Program

Multi-site VMS sizing is the discipline that turns twelve buildings of cameras into one system an operator trusts — and it's mostly decided before the first camera ships: recording topology, per-site storage, WAN budget, and an investigation path with an audit trail. The hardware backbone for all of it lives in our Video & Storage catalog — recorders, commercial NVR picks, and surveillance-rated drives — alongside all Hanwha products for estates standardizing on one camera-to-recorder stack. If you're speccing a district, campus, or multi-branch rollout, send over your building list, camera counts, and per-site link speeds, and we'll help you pressure-test the recording topology and storage sizing before anything hits a purchase order.