This is engineering guidance, not legal advice. Confirm specifics with qualified counsel.

Why this matters

Every surveillance project picks a place to run its analytics, and that single decision quietly sets the monthly bill for the life of the system. The earlier articles in this block explained where analysis can run and when each tier makes sense; this one puts a number on it, so a product manager or integrator can defend the choice with a spreadsheet instead of a hunch. The stakes are real: the gap between the cheapest and the costliest way to run the same analytic is about a thousandfold, and most of that gap is invisible until the first full-scale invoice arrives. Read this before you size a deployment, sign a usage-based contract, or promise a client a price — because all three are expensive to undo a year in.

The money view of the edge-and-cloud split

This block has walked through the deployment tiers one at a time. The thesis — that where analytics run drives the whole system — lives in edge vs cloud analytics. The three tiers have their own articles: the camera itself in on-camera edge AI, a computer you own in edge servers and on-prem AI appliances, and a rented data center in cloud video analytics cost. The pattern most real systems settle on is the hybrid split. A commercial overview of the same trade-off is in our blog on edge AI versus cloud AI for video surveillance.

This article does one job those five do not: it lays all the tiers on a single cost grid, in dollars per camera per month, so you can compare them directly. We do it by breaking every system into the same three cost levers — bandwidth, compute, and storage — pricing each lever at each tier, and then finding the break-even points where one tier overtakes another. The numbers here are representative United States list prices for 2026; treat them as a model to fill in with your own quotes, not as a fixed quote.

The three levers, defined before we price them

Strip away the marketing and every analytics deployment spends money on exactly three things. Naming them precisely is half the battle, because vendors quote whichever one flatters their product.

The first lever is bandwidth — the cost of moving video from the camera to wherever the analysis happens. If analysis happens on the camera, the video barely moves and this lever is nearly free. If analysis happens in a distant cloud, every frame travels over the internet, and you pay for the connection that carries it. Bandwidth is measured in megabits per second (Mbps) of sustained throughput.

The second lever is compute — the cost of the processor that actually runs the AI model. This is usually the largest lever and the one that swings most violently between tiers, because a chip you bought once costs nothing more to run, while a per-minute rental keeps charging for every minute it watches. Compute is measured in dollars per hour of processor time, or per minute of video analyzed.

The third lever is storage — the cost of keeping the recorded video for as long as your retention policy requires. Storage is the steadiest of the three: it grows in a straight line with how many cameras you have and how long you keep their footage. It is measured in dollars per gigabyte (GB) per month. The full storage calculation has its own article in the retention math; here we use it only as one lever among three.

Diagram naming the three cost levers of video analytics — bandwidth to move the video, compute to analyze it, storage to keep it — each with its unit and the factors that multiply it. Figure 1. The three levers every analytics deployment pays for. Bandwidth moves the video, compute analyzes it, storage keeps it. Each lever carries its own unit and its own multipliers; where you run the analysis decides how big each one grows.

To keep the arithmetic honest, we hold one camera constant through the whole article: a 4-megapixel camera recording continuously in the efficient H.265 codec, which produces a stream of about 2 Mbps. (Why H.265 roughly halves the bitrate of older H.264 is a codec question, covered in choosing a surveillance codec.) Continuous means the meters never rest, which is exactly where costs either stay sane or run away: 60 minutes × 24 hours × 30 days = 43,200 minutes a month of video per camera.

Compute: the lever that swings a thousandfold

Compute is where the deployment decision earns or wastes the most money, so we price it at all four options a real system chooses between.

On the camera (edge). A camera with a built-in neural processing unit (an NPU, the small chip that runs AI models on-device) does the analysis for the cost of the electricity already flowing down its network cable. The marginal compute cost is therefore close to zero; what you pay is the premium of buying a smart camera instead of a basic one. A mainstream IP camera runs about $180 to $350; a camera with on-board analytics from a maker like Axis or Hanwha runs roughly $150 to $450 more. Spread a $150 premium over a five-year life:

$150 premium ÷ 60 months ≈ $2.50 per camera per month, compute.

On a server you own (edge server). A single inference server with one NVIDIA L4 graphics processor (a GPU, the chip built to run AI models fast) costs about $8,000 all-in and carries roughly 24 simultaneous 1080p streams through a light detector. Amortize the hardware over five years and add the power it draws — about 300 watts under load, at the 2026 United States commercial rate near $0.14 per kilowatt-hour:

$8,000 ÷ 60 months = $133/month hardware 0.3 kW × 720 hours × $0.14 = ~$30/month power ($133 + $30) ÷ 24 cameras ≈ $6.80 per camera per month, compute.

On a rented cloud GPU. The same L4 chip rents from a cloud provider for about $0.80 an hour. Run it around the clock and divide by the same stream density:

$0.80/hour × 24 × 30 = $576 per GPU per month $576 ÷ 24 cameras ≈ $24 per camera per month, compute.

On a per-minute cloud API. A managed analytics service — an application programming interface (API) that takes your video and returns detections — bills about $0.10 per minute of video. Point it at one camera running continuously:

43,200 minutes × $0.10 = $4,320 per camera per month, compute.

Read those four numbers together: about $2.50, $6.80, $24, and $4,320 for the identical analytic on the identical camera. The chip you own is essentially free to run once bought; the chip you rent costs a flat monthly fee; the per-minute API costs the same work nearly 180 times more than the rented GPU, because it bills every minute it watches. The lesson is not "never use the cloud" — it is that the billing model has to match the workload, a point we sharpen at the break-evens below.

Storage: the quiet, linear multiplier

Storage rarely shocks anyone in a single month, and then compounds into the largest line on a multi-year bill. Our 4-megapixel camera at 2 Mbps produces a predictable pile of data:

2 Mbps ÷ 8 = 0.25 megabytes per second 0.25 MB/s × 86,400 s/day × 30 days ≈ 648 GB per camera per month.

What that costs depends entirely on where the bytes live. On a local recorder, you buy surveillance-grade disk once. At about $18 per terabyte for the drive, and roughly $30 per usable terabyte after the redundancy overhead that protects against a failed disk:

0.648 TB × $30/TB ≈ $19 of disk per camera, for 30 days of footage (one-time).

In the cloud, you rent the same capacity every month, at about $0.023 per gigabyte-month:

648 GB × $0.023 ≈ $15 per camera per month, at 30-day retention.

The contrast is the whole point. Local storage is a roughly $19 one-time purchase; cloud storage is about $15 every month, forever. Over a five-year retention horizon, the cloud line totals $15 × 60 = $900 per camera, against about $19 of local disk plus its power. Cloud storage passes the entire cost of a local disk in its first five weeks and keeps charging. None of this makes cloud storage wrong — it buys you no hardware, no failed drives, and instant offsite copies — but for continuous recording of a large fleet it is the quiet line that compounds.

Retention is the multiplier sitting on top. Keep 90 days instead of 30 and you simply triple the resident video, so the cloud storage line rises toward $45 per camera per month and the local-disk purchase toward $57. Storage scales linearly with both fleet size and retention days, and with nothing else.

Bandwidth: the lever you pay even when nothing happens

Bandwidth is the lever that punishes the cloud and rewards the edge, and it has two halves.

The first half is the uplink — the upload capacity of your site's internet connection, which must sustain the full video stream if analysis happens off-site. Our camera needs 2 Mbps of upload, so a 50-camera site streaming everything up needs:

50 cameras × 2 Mbps = 100 Mbps of sustained upload, every second of every day.

A business symmetric 100-Mbps link runs roughly $100 a month, which spreads to about $2 per camera across 50 cameras — more if you need a guaranteed, dedicated circuit rather than a best-effort one. Note what this lever does not cost: sending data into a cloud is free at every major provider, so the upload itself carries no cloud charge. You pay your internet provider for the pipe, not the cloud for the bytes.

The second half is egress — the cloud's charge for pulling data back out, about $0.09 per gigabyte. You pay it every time an operator streams stored footage back to watch it. Even reviewing a modest 5% of a 100-camera site's footage adds up:

100 cameras × 648 GB × 5% = 3,240 GB reviewed 3,240 GB × $0.09 ≈ $292 per month ÷ 100 cameras ≈ $3 per camera per month.

Add the two halves and a cloud deployment carries roughly $5 per camera per month of bandwidth — small against compute, but real, and easy to forget because it bills the boring act of looking at video you already paid to store. On the edge and edge-server tiers this lever is nearly free, because the video stays on the local network and only alerts or short clips ever leave the building.

Cost per camera per month, all four tiers on one grid

Now we lay the three levers across the four tiers. This is the table the rest of the block defers to — the full cross-tier model in one place.

Cost lever (per camera / month, continuous) Edge — on camera Edge server — on-prem GPU Cloud — rented GPU Cloud — per-minute API
Compute ~$2.50 (amortized premium) ~$6.80 ~$24 ~$4,320
Storage (30-day, local vs cloud) ~$0.30 local ~$0.30 local ~$15 cloud ~$15 cloud
Bandwidth (uplink + egress) ~$0 (metadata only) ~$0 (stays on LAN) ~$5 ~$5
Total ≈ ~$3 ~$8 ~$45 ~$4,350

Table 1. The same continuous analytic on the same 4-megapixel camera, priced at every tier. Rates are representative US list prices (2026) and move with region, commitment, model, and resolution; reserved and spot cloud pricing lower the rented-GPU compute line, and operational overhead pushes the edge-server total toward $10–12 all-in. The single most important fact in the table is the spread: about a thousandfold from the cheapest column to the costliest, driven almost entirely by the compute lever.

The shape matters more than any single cell. Moving left to right, you trade falling capital and operational burden for a rising monthly meter. The edge keeps compute and bandwidth near zero but caps how heavy a model you can run. The owned server adds modest, fixed cost for far more compute. The rented cloud GPU is reasonable per camera and turns capital into a monthly fee. The per-minute API is in a different universe — priced for occasional clips, ruinous for a live fleet. A diagram makes the gap visible.

Bar chart on a logarithmic scale of cost per camera per month at four tiers: on-camera edge near three dollars, on-prem server near eight, rented cloud GPU near forty-five, and a per-minute API near four thousand three hundred fifty. Figure 2. Cost per camera per month for continuous analytics, four tiers, logarithmic scale. The per-minute API towers a thousandfold over the on-camera edge for the same work — the bars need a log scale just to fit on one canvas.

The break-even points a buyer actually needs

Tables tell you the cost at the extremes; break-evens tell you where to draw the line. Four of them decide most systems.

Break-even one: per-minute API versus your own GPU — about 8 minutes a day

This is the most useful number in the article. A rented or owned GPU costs a flat amount whether it analyzes one minute or every minute; the per-minute API costs $0.10 for each minute it runs. Set the API's per-camera cost equal to the rented GPU's per-camera compute and solve for the minutes:

$24 per camera per month ÷ $0.10 per minute = 240 minutes per month 240 minutes ÷ 30 days = 8 minutes of analysis per camera per day.

Below roughly 8 minutes of analysis per camera per day, the per-minute API is cheaper, because you use it so rarely that paying by the minute beats renting a whole chip. Above that — and continuous recording is 1,440 minutes a day — the GPU wins, by the 180-fold margin we saw above. This is the line that separates "analyze a clip after an alarm" from "watch the fleet around the clock." The crossover assumes you can pack the GPU to its full ~24 streams; with a half-full GPU the per-camera compute doubles and the break-even rises to about 16 minutes a day.

Line chart showing the per-minute API cost rising with minutes of analysis per day and crossing the flat rented-GPU cost at about eight minutes per camera per day, above which the GPU is cheaper. Figure 3. The duty-cycle break-even. The per-minute API (rising line) is cheaper only in the narrow band below about eight minutes of analysis per camera per day; past that crossover the flat-rate GPU wins, and continuous analysis sits far to the right where the API is roughly 180× more expensive.

Break-even two: rent the GPU or buy it — about 15 months

Once you know you need a GPU running continuously, the next question is rent or own. Renting the cloud L4 costs $576 a month. Buying the equivalent on-prem server costs about $8,000 plus roughly $30 a month of power. The owned server pays back the moment its cumulative cost drops below the rental's:

$8,000 ÷ ($576 − $30 per month) ≈ $8,000 ÷ $546 ≈ 14.7 months.

So for continuous work you expect to run longer than about 15 months, buying beats renting; for shorter or uncertain horizons, rent and stay flexible. And this is the conservative version of the case, because owning the server also erases the cloud's $15-per-camera storage line and $5-per-camera bandwidth line — count those and the real payback comes faster. Renting still wins for spiky demand you do not want to own, which is the cloud's genuine home.

Break-even three: the edge camera's premium pays back almost immediately

If on-camera analytics meet your accuracy needs, the smart-camera premium is the cheapest compute you will ever buy. That ~$150 premium, set against the alternatives it replaces:

vs a per-minute API (~$4,320/month): pays back in under one day vs a rented-GPU cloud (~$29/month of compute + bandwidth saved): ~5 months

The catch is in the conditional. A camera's few watts run a smaller model than a server's GPU, so edge accuracy is lower for hard scenes. Whether that trade is acceptable is a performance question, not a cost one, and it has its own article in latency and accuracy at each tier. The economics simply say: when the edge is good enough, it is almost always cheapest.

Break-even four: cloud storage versus a local disk — about five weeks

We met this one already, and it deserves its own line because retention quietly dominates long-run cost. Cloud storage at ~$15 per camera per month passes the ~$19 cost of a local disk in about 1.3 months, and over five years costs roughly $900 against $19. The longer your retention policy, the more decisively local or hybrid storage wins for continuously recorded video — which is exactly why the leading "cloud" surveillance vendors record locally and upload selectively rather than streaming every frame up.

The multipliers: how resolution and retention scale the bill

The grid in Table 1 prices one camera at one resolution and one retention period. Five multipliers scale it, and each one pushes on a different lever — knowing which is how you cut a bill without losing the analytic.

Diagram mapping five multipliers — resolution, inference frame rate, retention days, duty cycle, and number of models — to the bandwidth, compute, and storage levers each one scales. Figure 4. Which multiplier moves which lever. Resolution pushes all three; inference frame rate and model count push compute; retention pushes storage alone; duty cycle pushes compute and the per-minute meter. Pull the lever that matches the bill you are trying to cut.

Resolution and bitrate push all three levers at once. Going from 2 to 4 to 8 megapixels roughly doubles the bitrate at each step, which roughly doubles storage and uplink, and raises compute because there are more pixels to process. H.265 softens the storage and bandwidth half of this; nothing softens the compute half except analyzing fewer pixels.

Inference frame rate pushes compute alone, and it is the lever teams most often forget. You can record at 25–30 frames per second for smooth playback while running the AI model at only 5–10 frames per second — most objects do not move far in a fifth of a second. Decoupling inference rate from recording rate can cut the compute lever three- to sixfold with no loss of recorded footage.

Retention days push storage alone. Doubling retention doubles the storage line and touches nothing else — which is why retention belongs in a storage conversation, not a compute one. The maximum is often capped by privacy law, not just budget; see the retention math.

Duty cycle — how much of the day you actually analyze — pushes compute and, brutally, the per-minute meter. Analyzing only when motion is present, instead of continuously, can cut analyzed minutes by 80–95%, which is what moves a workload across the 8-minute break-even and back into per-minute-API territory. The recording-mode choices behind this live in recording strategies.

Number of models pushes compute linearly. Running detection, license-plate reading, and face matching together is roughly three analytics' worth of compute on the same stream. Each model you add is another full multiple of the compute lever — a reason to run only the analytics a site genuinely needs.

A common mistake to avoid

The costliest pattern we see is pricing a system on the compute lever alone and discovering the other two at scale. A team benchmarks a model, sees a tidy per-camera compute figure, and signs off — then the cloud storage line compounds month after month and the egress meter bills every operator who watches a clip, and the real cost lands at two or three times the estimate. The fix is to price all three levers together, at the real retention period and the real review habits, before choosing a tier. Its twin mistake is using the wrong billing model for the duty cycle — wiring a per-minute API to continuous video because the demo cost a dollar, then meeting the 43,200-minute invoice. Match the meter to the workload: own or rent a GPU for continuous analysis, call a per-minute API only for the occasional clip, and pre-filter at the edge so the expensive tiers see only the minutes that matter.

Where Fora Soft fits in

Fora Soft has built real-time video, streaming, and computer-vision software since 2005, across 625+ shipped projects, and the three-lever cost model is the first thing we work through with a client — before a line of code, on a spreadsheet. Teams come to us when a deployment that looked affordable on the compute number turned into a five-figure monthly bill on storage and egress, or when they cannot tell whether to rent or buy the GPU, or when a per-minute proof-of-concept needs re-architecting before it meets a fleet. We price each lever against how the system will actually behave under load — the real camera count, the real retention, the real review fraction, the real duty cycle — and we lead with the realistic precision and recall a model delivers in your scene, never a demo's perfect score. A workload placed on the tier that bills it kindly, with each multiplier tuned to the job, routinely costs a fraction of the same system designed on the compute number alone.

What to read next

Call to action

References

  1. Amazon Web Services — "Amazon Rekognition pricing" (stored-video analysis billed about $0.10 per minute — the per-minute managed-analytics rate behind the ~$4,320/camera/month continuous compute figure). Vendor pricing (tier 4). https://aws.amazon.com/rekognition/pricing/
  2. Google Cloud — "Cloud Video Intelligence API pricing" (label detection about $0.10 per minute after a free monthly allowance — the second provider confirming the ~$0.10/min rate). Vendor pricing (tier 4). https://cloud.google.com/video-intelligence/pricing
  3. Amazon Web Services — "Amazon EC2 G6 instances" (NVIDIA L4 GPU instances from about $0.80 per hour on demand — the basis for the rented-GPU compute figure of ~$24/camera/month at ~24 streams). First-party engineering / vendor pricing (tier 3/4). https://aws.amazon.com/ec2/instance-types/g6/
  4. Amazon Web Services — "Amazon S3 pricing" (S3 Standard about $0.023/GB-month; internet egress about $0.09/GB with the first 100 GB/month free; ingress free — the basis for the storage and bandwidth lever math). Vendor pricing (tier 4). https://aws.amazon.com/s3/pricing/
  5. NVIDIA — "L4 Tensor Core GPU" and "DeepStream SDK — multi-stream video analytics" (the L4 is a 72-watt inference GPU running roughly 16–40 simultaneous 1080p streams with a light detector — the stream-density figure that converts a GPU's cost into a per-camera cost). First-party engineering (tier 3). https://developer.nvidia.com/deepstream-sdk
  6. Seagate / Western Digital — "SkyHawk and WD Purple surveillance drive pricing" (purpose-built 24/7 surveillance drives at roughly $17–19 per terabyte in 2026 — the basis for the ~$30/usable-TB local-storage figure after redundancy overhead). Vendor pricing (tier 4). https://www.seagate.com/products/video-analytics/skyhawk-hard-drive/
  7. U.S. Energy Information Administration — "Electric Power Monthly — average retail price of electricity, commercial sector" (US commercial electricity near $0.14/kWh in 2026 — the rate behind the edge-server power line). Institutional (tier 5). https://www.eia.gov/electricity/monthly/epm_table_grapher.php?t=epmt_5_6_a
  8. ITU-T — "Recommendation H.265 (HEVC)" (High Efficiency Video Coding; roughly halves the bitrate of H.264 at equal quality — the codec basis for the 4-megapixel ≈ 2 Mbps assumption used throughout the math). Primary standard (tier 1). https://www.itu.int/rec/T-REC-H.265
  9. ONVIF — "Profile M — Metadata and events for analytics applications" (standardizes the analytics metadata and events a tier exchanges with the VMS; a conformant consumer can be a camera, a server, or a cloud service — so the cost choice does not change the integration interface. Profile M Specification v1.1, 2024). Primary standard (tier 1). https://www.onvif.org/profiles/profile-m/
  10. European Union — "GDPR, Regulation (EU) 2016/679, Chapter V (Arts. 44–50)" (restricts transfers of personal data — including identifiable video — outside the EEA absent a legal mechanism; a cost-relevant constraint because it can rule the cloud tier out regardless of price). Primary law (tier 1). https://eur-lex.europa.eu/eli/reg/2016/679/oj
  11. European Union — "Artificial Intelligence Act, Regulation (EU) 2024/1689, Art. 5 and Annex III" / Illinois General Assembly — "Biometric Information Privacy Act (BIPA), 740 ILCS 14" (biometric identification is restricted or high-risk under both; the legal gate that can override the cheapest tier for face or plate workloads). Primary law (tier 1). https://eur-lex.europa.eu/eli/reg/2024/1689/oj
  12. Fora Soft — "Edge AI vs Cloud AI for Video Surveillance: 2026 latency, cost & privacy" (commercial overview finding that above roughly 20 continuous-stream cameras, edge analytics undercut cloud within about 12 months — the real-world corroboration of the break-evens here). Vendor engineering (tier 4). https://www.forasoft.com/blog/article/edge-ai-vs-cloud-ai-video-surveillance