Advanced lesson
Plan Camera Bandwidth, Storage and Network Access
Work a clear recording estimate, map network dependencies and define the tests that prove the design.
Reviewed September 2026 · 3 minute read
Eight cameras at an assumed 4 Mb/s
| Calculation | Result |
|---|---|
| 8 cameras × 4 Mb/s | 32 Mb/s of assumed video payload |
| 32 Mb/s × 86,400 seconds ÷ 8 | 345,600 MB/day = 345.6 GB/day |
| 345.6 GB/day × 14 days | 4,838.4 GB = about 4.84 TB |
This is a payload estimate with an assumed constant bitrate, not a recorder recommendation or a guaranteed 14-day capacity. Add filesystem and recording overhead, actual usable disk capacity, redundancy, measured variation and design margin. Variable bitrate and event-based recording change the result.
Follow recording and viewing separately
Camera to recorder
Size the uplinks and recorder ingest for all required streams and peak behavior.
Recorder to viewers
Playback and export create additional traffic. Remote viewing also depends on upload capacity and the supported access method.
Power and recovery
Include PoE limits, switches, recorder storage health, time service and required UPS runtime.
Camera count, codec, resolution, frame rate, scene movement and retention all matter. Confirm manufacturer limits and test with the intended workload.
Treat a camera as a managed endpoint
Inventory it, keep supported firmware, restrict administration, remove unneeded services and use a deliberate network boundary. Prefer the approved protected remote-access design instead of exposing camera administration directly to the internet.
Allow required recording, time, name-resolution, update and integration traffic explicitly. Then use the security access matrix to verify camera and guest restrictions. Restrict application roles as well as network paths.
What changes if the measured average doubles?
Using the same continuous-recording assumptions, calculate the video payload for eight cameras averaging 8 Mb/s over 14 days. Then identify what still needs measurement before selecting storage.
Check your result
The payload doubles to 9,676.8 GB, about 9.68 TB in decimal units. Usable storage, peak rates, overhead, retention behavior and the actual recorder limits still need verification.
Put it into practice
Check what you learned
Choose an answer for each question, then check your understanding. Your answers stay in this browser.
Read the answers and explanations
- No. Account for usable capacity, storage overhead, bitrate variation and the operating requirements.
The calculation is a planning input. Verify usable storage and actual recording behavior with the required allowances.
- It doubles.
Payload storage is proportional to average bitrate when count and duration stay fixed.
- Recording and approved viewing work under load, while prohibited access is blocked.
Business behavior and access boundaries both need evidence. Reachability alone is incomplete.
Sources and further reading
- Axis: edge storage
Explains recording storage and the factors behind capacity estimates. Our bitrate example is an original calculation with explicit assumptions.
- Axis: AXIS OS hardening guide
A detailed vendor example of device hardening, restricted services and network separation. Apply the exact guidance for the equipment and supported software in use.
Keep your momentum
Ready for the next step?
If you can explain the example and your answer, try the next lesson. Revisit the feedback whenever you need it.
FryAVSI · Updated September 10, 2026
Reference this lesson or use a section’s direct link for a particular chart or example. How to cite an example.
FryAVSI · Northeast Ohio and beyond
Turn the learning into a working result.
Share the site, the requirement and the next step with our team.