Ask an operations manager running a 50-site estate what’s wrong with their central monitoring, and the answer is almost always “bandwidth.” The video wall lags. Feeds drop. The SOC pulls up a site and waits three seconds for it to paint. So the request goes to IT: more bandwidth. It’s a reasonable instinct, and up to a point it’s even correct — a starved link will absolutely choke video. But past a certain size, multi-site video surveillance architecture stops being a bandwidth question and becomes a design question. The estates that run 200 sites into one Security Operations Centre (SOC) smoothly aren’t the ones that bought the biggest pipe. They’re the ones that stopped moving footage nobody is watching.
This is the difference between throwing money at symptoms and fixing the system. Let’s walk through where the money actually goes.
The 50-Site SOC Problem, Concretely
Picture a retail chain: 50 stores, eight cameras each — entrances, tills, stockroom, loading bay. 400 cameras total. Head office has a SOC with four operators and a video wall, and the mandate is simple to say and hard to build: see everything, from anywhere, right now.
“See everything” hides a lot. It means any operator can pull up any camera at any of the 50 sites on demand. It means the video wall cycles through a live mosaic of priority feeds. It means when a loading-bay alarm fires at store 37, the operator gets a clean, low-latency live view in under a couple of seconds — not a frozen frame, not a spinner. And it means all of this keeps working when a store’s internet has a bad afternoon.
The same shape shows up everywhere: bank branch networks, warehouse complexes, hospital campuses, quick-service restaurant chains. Many remote sites, one central room, and an expectation that the room is omniscient. The naive way to deliver that is to have every site stream every camera to the center, all the time, so it’s always there when someone wants it. That single decision — always-on push — is where the cost story begins.
Why “Just Add Bandwidth” Runs Out of Road
Bandwidth is a real constraint, so let’s be fair to it before we move past it.
Where more bandwidth genuinely helps
If your remote sites are on thin, contended links — a single ADSL line at a rural branch, a saturated 4G failover — then yes, more capacity directly buys you smoother live views and fewer drops. If the SOC’s own uplink is the choke point, upgrading it helps every feed at once. For small estates, five or ten sites, “buy a bigger pipe” is often the right answer because it’s cheaper than re-architecting anything. Don’t over-engineer a problem you don’t have yet.
Where it stops helping
The trouble is that bandwidth scales linearly with a design that scales badly. If every one of your 400 cameras pushes its live stream to the center 24/7, you are paying to move 400 streams whether or not a human is looking at any of them. At 2 Mbps per live sub-stream — a conservative figure; the high-detail main-stream is heavier — that’s 800 Mbps of sustained ingest at the SOC before a single operator does anything. Double the estate to 100 sites and you need 1.6 Gbps. You are not buying visibility. You are buying the privilege of transporting footage into a room where nobody is watching most of it. No pipe is big enough to make that math stop hurting, because the math is the problem, not the pipe.
That leads straight to the first real cost driver.
Cost Driver #1: Always-On Push vs On-Demand Pull
What streaming every camera, all the time, actually costs
Let’s put real numbers on the retail example. 400 cameras, live sub-stream at 2 Mbps, running around the clock.
Per camera: 2 Mbps × 86,400 seconds ≈ 21.6 GB per day.
Whole estate: 400 × 21.6 GB ≈ 8.6 TB per day, or roughly 259 TB per month.
If that traffic lives entirely inside your own network — site-to-SOC over private links you already pay a flat fee for — the meter isn’t running per gigabyte, but the capacity still has to exist, and you’re sizing every link and every SOC uplink for peak-everything-at-once.
Now put it in a cloud-hosted setup where video crosses a metered boundary. At a representative egress rate of $0.09 per GB, moving 259 TB works out to roughly $23,300 per month — call it $280,000 a year — to relay footage that is, for the overwhelming majority of those camera-hours, watched by no one. That’s the number that makes finance sit up, and it’s entirely self-inflicted by the always-on assumption.
On-demand pull: only move what someone is watching
Here’s the lever. At any given moment, how many of your 400 cameras is a human actually viewing? Four operators, a handful of tiles each, plus a video wall cycling a couple of dozen priority feeds — realistically you’re looking at 30 to 40 live streams at peak, not 400. Everything else is recording locally at the site (where it belongs) and sitting quiet until someone calls for it.
If the architecture only transports streams that are being viewed, your center-bound live traffic drops from 800 Mbps to under 100, and that $23,300 cloud egress line falls to roughly $2,300 — about a tenth. Same coverage. Same “see everything on demand.” You simply stopped paying to move the 90% that no one had open.
The whole cost gap in one view:
| Dimension | Always-on push | On-demand pull |
|---|---|---|
| Live streams transported | All 400 cameras, 24/7 | ~30–40 (only those on screen) |
| Sustained bandwidth at the SOC | ~800 Mbps | Under 100 Mbps |
| Monthly data moved to centre | ~259 TB | ~26 TB |
| Cloud egress @ $0.09/GB | ~$23,300 / month | ~$2,300 / month |
| On-premise (flat-licensed) | Capacity sized for peak-everything | No per-GB meter at all |
Assumptions: 50 sites × 8 cameras = 400 cameras; live sub-stream at 2 Mbps (main-stream is higher); egress at $0.09/GB where video crosses a metered cloud boundary. On-premise deployment removes the egress line entirely.
That 10× gap is the single biggest cost decision in the whole system, and it’s an architecture decision, not a bandwidth purchase. On-demand fixes the volume problem. The next one is subtler: even the streams you are watching can get duplicated.
Cost Driver #2: One Camera, Many Operators
Say store 37’s loading bay is interesting this afternoon. Operator A pulls it up. So does Operator B. It’s also on the video wall. That’s the same physical camera being watched three ways at once.
In a naive setup, the site uploads that one feed three separate times — once per viewer — because each viewer opened its own independent connection back to the source. Three viewers, three times the upload from a site that may only have a modest connection to begin with. Add the wall and it’s four. The camera hasn’t changed; the cost and the strain have tripled, and the site’s link is now the bottleneck for exactly the feed everyone cares about.
The fix is to send the stream out of the site once and let a central layer copy it to as many operators as need it — the site’s upload cost stays flat no matter how many people watch. This “one stream in, many streams out” fan-out is the quiet workhorse of every large monitoring operation, and getting it wrong is how a system that tested fine with two operators falls over the day a real incident draws a crowd to the same feed.
So far we’ve assumed the sites stay up. They won’t.
What Breaks When a Site Drops Offline
Remote sites lose connectivity. A store’s ISP has an outage, a digger cuts a line, the 4G failover is flaky. The question isn’t whether it happens — it’s what your SOC does in the ninety seconds after.
Three things determine whether an outage is a shrug or an incident. Detection: does the SOC actually notice store 37 went dark, or does the operator just assume it’s quiet? A wall of green tiles that silently freezes is worse than useless — it’s false confidence. The blind-spot window: while the site is offline, is it still recording locally so you have the footage later, or is that time simply gone? Reconnection: when the link comes back, does the site rejoin the SOC automatically and cleanly, or does someone have to notice and manually re-establish eight camera feeds?
The operational cost here isn’t bandwidth — it’s the coverage gap you didn’t know you had. A well-designed multi-site system treats every site as independently resilient: recording continues locally through the outage, the SOC is told clearly when a site is unreachable, and reconnection is automatic. A poorly designed one presents a frozen tile as a live one, and you find out during the incident review that the camera you needed was dark for an hour.
Detection, local resilience, clean reconnect — none of that comes from a bigger pipe either. It comes from the same architectural choices as everything above. So let’s put the whole picture together.
What a Multi-Site Video Surveillance Architecture Should Actually Look Like
Strip away the jargon and the design is three layers.
At each site — a local relay. Every site keeps its own cameras, its own local recording, and a small piece of software that acts as the site’s single point of contact with the outside world. Cameras talk to it locally over the network they already use; it talks to the center. Recording stays on-site and survives outages. Only one controlled connection leaves the building.
In the middle — an aggregation layer that fans out. The center receives streams from all sites and is responsible for the “one in, many out” copying — so three operators and a wall watching store 37 cost the site one upload, not four. Critically, it only pulls a site’s live stream when someone actually requests it, which is what keeps the 10× cost gap on the right side.
At the SOC — operators and walls that pull on demand. Any operator opens any camera at any site and the stream is routed to them in near real time. Nothing is being transported that isn’t being watched.
Get those three layers right and the outcomes follow: bandwidth sized for what’s watched rather than what exists, per-site upload that doesn’t balloon with viewer count, and sites that fail gracefully instead of silently. Whether you build this, buy a cloud VMS that does it, or embed an existing platform is its own decision — we walk through that trade-off in the build, buy, or embed guide [link] — but the shape above is what you’re evaluating any option against.
This fan-out-on-demand pattern is, mechanically, what a Selective Forwarding Unit does: receive from many sources, forward to many viewers, copy nothing you don’t have to. Samvyo is real-time video infrastructure based on SFU architecture, which is why the multi-site → central-SOC problem is its native shape rather than a bolt-on. A few things that matter specifically for estates like the one above: it deploys on-premise, so if your video never has to cross a metered cloud boundary, that $23,300 egress line simply doesn’t exist. Its licensing is flat, not per-minute, which matters when you’re running live monitoring around the clock — per-minute pricing and always-on surveillance are a bad marriage. And it’s white-label / OEM, which is the relevant bit if you’re a managed service provider running many client estates from one platform and need tenant isolation between them.
Where it doesn’t fit: if you have a handful of sites and a cloud VMS you’re happy with, none of this is worth re-architecting for — the bigger-pipe answer is genuinely cheaper for you. Samvyo is infrastructure for teams that have outgrown the off-the-shelf ceiling, not a replacement for a working small setup. The concession is the point: match the architecture to the estate, not to the vendor.
The Bottom Line
At multi-site scale, bandwidth is a symptom and architecture is the cure. The three decisions that actually move cost and reliability are: pull streams on demand instead of pushing everything always-on (roughly a 10× swing on the traffic that dominates the bill), fan a watched feed out centrally instead of re-uploading it per viewer, and make every site independently resilient so an outage is a logged event rather than a silent blind spot. Buy a bigger pipe only after you’ve made those three choices — not instead of them.
What’s Next?
Own the architecture rather than the budget? The technical companion to this post covers the implementation: site-edge relay design, WAN tuning for long-haul links, failover and reconnection logic, and multi-tenant isolation: link to technical version.
It also pairs naturally with the earlier pieces on tapping the stream without fighting the NVR and the real cost of adding browser video to an existing CCTV estate [link].
Frequently Asked Questions
How much bandwidth do I need to connect 50 sites to one SOC?
It depends entirely on whether you push all cameras always-on or pull streams on demand. Always-on for 50 sites × 8 cameras at 2 Mbps is about 800 Mbps sustained at the SOC. On demand — transporting only the 30–40 streams actually being watched at peak — it’s under 100 Mbps for the same estate. The design choice matters far more than the pipe size, which is why infrastructure built on SFU architecture, such as Samvyo, forwards only what’s being viewed.
Is always-on streaming or on-demand pull cheaper for multi-site surveillance?
On-demand is typically an order of magnitude cheaper because you stop transporting footage no one is watching. For a 400-camera estate, the difference on metered cloud egress can be roughly $23,000 versus $2,300 a month. On-premise deployment removes the per-gigabyte meter entirely, which is why platforms like Samvyo that run on-prem with flat licensing suit around-the-clock monitoring.
Can one central SOC realistically monitor 200 remote sites?
Yes, provided the multi-site video surveillance architecture pulls on demand and fans watched streams out centrally rather than having every site push everything continuously. The limit isn’t the number of sites; it’s whether you’re moving all cameras all the time or only the ones in view. Get the on-demand and fan-out design right and the site count becomes almost incidental.
What happens when a remote site loses its internet connection?
In a well-designed system the site keeps recording locally through the outage, the SOC is clearly notified that the site is unreachable rather than shown a frozen tile, and the site reconnects automatically when the link returns. The risk to avoid is a monitoring wall that presents a dead feed as a live one. Local resilience plus explicit outage signalling is an architecture property, not a bandwidth one.
Why does watching the same camera from multiple operators strain the system?
If each viewer opens an independent connection back to the source, the site uploads that one feed once per viewer — three operators and a video wall can mean the same camera is sent four times. Central fan-out solves this: the stream leaves the site once and is copied at the center to every viewer. This “one in, many out” behaviour is exactly what an SFU-based platform like Samvyo provides, keeping per-site upload flat regardless of viewer count.
Should a multi-site retailer or bank use cloud VMS or self-hosted infrastructure?
Small estates with a few sites are often best served by an off-the-shelf cloud VMS — it’s cheaper than re-architecting. Larger estates hit two walls: metered cloud egress on always-on video, and data-residency requirements (footage is personal data under regimes like DPDP). At that point on-premise or self-managed infrastructure with flat licensing — the model Samvyo is built for — usually wins on both cost and compliance.
