Bandwidth Considerations of Cloud Surveillance

In this whitepaper, we explore the concepts behind WAN bandwidth utilisation when deploying enterprise hybrid-cloud surveillance and access control solutions across the organisation.

With a misconception that deploying cloud-based physical security technology will impact the WAN connections, edge technology just like IoT technology is becoming a new norm, and bandwidth optimisation and considerations are consistently evolving to the point in which deploying large fleets of surveillance devices will have a minimal impact on the WAN.

What is hybrid-cloud surveillance?

As the title suggests, hybrid cloud indicates there is a component of onsite and cloud in the solution mix. In the case of hybrid-cloud surveillance solutions, such as those from Verkada, each camera acts independently on the network (just like IoT devices).

The cameras are self-sufficient in regards to not having to rely on internal servers or network video recorders (NVRs) to record or operate, nor do they require an active internet connection to continue recording (but will reduce feature sets and capabilities when WAN services are unavailable).

So where does edge technology come into play?

In traditional surveillance network models, often used by large organisations with multiple sites – each site would have a recording and software server which is then linked into a cloud service to allow operators to access each sites NVR. Video footage recording remains on the local network but playback would be pushed across the WAN (this is common in almost every solution). But the traditional CCTV design has limitations that are often overlooked after the first year of operation. With a traditional CCTV approach, the best the system will ever be is in the first year of operation, after which the organisation can expect emerging challenges that would include;

  • Outdated software and firmware with emerging exploits that need to be manually patched.
  • Limited warranty on the camera hardware (usually 1-2 years).
  • Server hardware and software issues that require ongoing maintenance.
  • Limited capacity for scalability without having to either upgrade or replace servers.
  • Security vulnerabilities in both hardware and software of the manufacturer, including firewall port requirements such as forwarders.
  • High bandwidth utilisation with limited user controls.

Edge technology is an emerging field of information technology and device management with similar properties of IoT deployment, removing the requirements for centralised processing and storage. Edge hardware such as business security cameras have inbuilt storage and processing capabilities that provide traditional CCTV features yet include an array of advanced features such as people and vehicle analytics, human identification, motion alerting and other artificial intelligence applications. With consideration to the above list of common challenges faced in the traditional CCTV systems, edge technology provides the following key benefits;

  • Outdated software and firmware with emerging exploits that need to be manually patched.
    • Being a hybrid-cloud model with edge technology, new software features are automatically updated and firmware is automatically installed on each camera across the organisation. There is no central server to update, you don’t have to manually update the firmware on each camera as this is handled from a single repository.
  • Limited warranty on the camera hardware (usually 1-2 years).
    • With solutions like Verkada, 10-year hardware warranties are included as part of the solution. No other solution on the market can provide this type of reassurance and enables organisations to plan out the solution as a 10-year project.
  • Server hardware and software issues that require ongoing maintenance.
    • With the device acting on the edge, the hardware becomes decentralised from a single server or NVR. Planning recording retention becomes easy as each camera would include a set number of days recording vs. traditional models which would require storage calculations that often limit image quality and future-state.
  • Limited capacity for scalability without having to either upgrade or replace servers.
    • Scalability is a key capability in edge technology, as each device is acting independently there is unlimited scalability possibilities. Enterprises do not need to consider storage or server specifications as the devices do not exist.
  • Security vulnerabilities in both hardware and software of the manufacturer, including firewall port requirements such as forwarders.
    • Devices create their own secure connection to the cloud and transmit at REST over secure port 443. There are no inbound firewall policies required as the edge device manages its own path to the cloud.
  • High bandwidth utilisation with limited user controls.
    • User sessions are timed out when no activity is detected and multiplexing technology is introduced to send a single stream to multiple users.

But what about WAN bandwidth requirements?

The biggest misconception with cloud-managed surveillance is the impact it will have on the organisations WAN connections, with a common belief that cameras are sending all recorded footage to the cloud. With emerging physical security solutions such as Verkada, each edge-device (or camera) stores recorded footage to its own internal storage thus eliminating the need for centralised servers or NVRs. Each camera has the capacity to store a defined set of recording days which can be mixed across the overall deployment.

When footage playback is requested, the video is either streamed via the cloud service or across the local network, dependant on where you are located (inside or outside the network). The browser or app will automatically determine the best path. This is key to understanding bandwidth impacts on the network when planning a large scale deployment.

So what are typical bandwidth consumptions of a hybrid-cloud physical security solution?

Typically 20-50 kbps per camera is the standard WAN consumption at rest meaning no streaming is occurring from the camera and it is simply recording within its environment. Remember, when the camera is recording no footage is being sent to the cloud (unless scheduled cloud backup is occurring – more on that later) but some metadata is being sent to the cloud such as people analytics. In busy environments where a lot of people are seen, this can spike to 100+ kbps, however, this spike is not consistent and often calms outside of business hours.

So for an example environment running 50 cameras on an internal VLAN (best practice to segment LAN services such as CCTV), we would calculate a minimum WAN impact of approx 1.75 Mbps (35 kbps * 50 cameras). We also need to account for the bandwidth required to stream video to users outside of the network. The bandwidth needed when footage is viewed external to the network is 600 kbps for standard definition, 1.5 Mbps for high-definition and between 2-3 Mbps for 4k quality. Using the same 50 camera deployment example, we may factor in 3 external streams (2 being SD and 1 being HD), this would add an additional 2.7 Mbps on top of the 1.75 Mbps utilisation, giving us a total WAN utilisation of approx 4.45 Mbps – it would also make sense to provide a bandwidth buffer on top of these indicative numbers to accommodate scenarios where some cameras may experience higher activity during certain times of the day – for this example above budgeting 6-8 Mbps for all 50 cameras plus external streaming users would be a fair calculation.

Some of the larger organisations we work with require over 200 cameras on a single network to provide the required coverage, which includes a team of loss prevention and compliance professionals who are reviewing footage from multiple locations. In this scenario, with 5 external viewers all streaming in HD, we have seen WAN utilisation of a site with 200 cameras be less than 20 Mbps during busy times of the day. Night time WAN utilisation drops to a low 6 Mbps (without cloud backup occurring) – realistically these figures represent less than 20% of an enterprise-grade internet connection yet provide features that would otherwise require high CAPEX purchase for speciality AI processing workloads and a huge amount of storage.

View the official Verkada camera setup and best practices guide

What about cloud backup and archiving?

With systems like Verkada, you have the option to enable 24/7 or scheduled cloud backup, which enables the camera to upload all recorded footage to the cloud. Generally, you only need this feature for cameras in high-risk locations such as alley-ways or rear entrances. When a camera has backup enabled, you can select to either back up to the cloud in SD or HD, by a schedule and by video in which motion was detected. These streaming bandwidth consumptions are the same in terms of WAN utilisation.

With reference to our 50 camera deployment model above in which we determined 4.45 Mbps of bandwidth is required, let’s mark 3 of the cameras as requiring standard-definition scheduled night-time backups (out of hours). Based on the initial estimate of 4.45 Mbps, this consumption would be unchanged during business hours, however, when the scheduled backup takes effect the WAN consumption would increase to 6.25 Mbps ((4.45 Mbps + (600 kbps * 3)). Archiving is similar in terms of backup of video, however, it’s based on timeslots set by the user so realistically there is no point making an allowance for this due to the ad-hoc nature of creating video clips.

What about local streaming, do I still consume the WAN?

When the camera can detect connectivity to the cloud, normal WAN consumption will continue to occur, but this does not mean that internal network users will impact WAN utilisation. When the camera’s live stream is accessed, the device accessing it prioritise streaming over the LAN before the WAN – if available. If the private IP address of the camera is routable to the client on the internal network, the computer will establish an HTTPS connection with the device to directly receive the live feed, thus not sending the stream out the WAN and back into the LAN. This is based on the assumption that internal VLANs can route to each other and no ACLs are in place to block local network traffic from the source to destination.


We see a solution like that of Verkada provide the following bandwidth utilisation to operate on the network:

  • Cameras idle typically at 20-50 kbps
  • Streams from a camera as high as 4k will consume 2 Mbps. In most scenarios streaming at SD is adequate which consumes 600 kbps
  • Cloud backup can be enabled with a range of options, with HD enabled we would see a 1.5 Mbps WAN consumption
  • External streaming of video will consume WAN bandwidth, with the typical being HD streaming at 1.5 Mbps
  • Cameras act as edge devices that include their own internal storage and processing units – thus eliminating servers and NVR equipment
  • A single site with over 200+ cameras can use less than 20 Mbps of WAN consumption, yet still enable advanced analytics and streaming external users.