Estimation

In one line: size the storage first, because in this system it is the architecture.

Per camera

Start from bitrate and never from resolution. Resolution without a bitrate tells you nothing, because the encoder decides how many bits a given picture costs.

bytes/sec        = bitrate_Mbps / 8 * 1,000,000
GB per day       = bitrate_Mbps / 8 * 86,400 / 1,000
TB per 30 days   = GB per day * 30 / 1,000

Run it for the plausible camera classes:

The bottom two rows are the same sentence in the prompt. That is why the unit question came first.

Per fleet

Take the committed scenario — 1,000 cameras at 4 Mbps, thirty days:

sustained ingest = 4 Mbps * 1,000            = 4 Gbps, continuous
steady state     = 1.3 TB * 1,000            = 1.3 PB, held at all times
daily written    = 43 GB * 1,000             = 43 TB/day
daily deleted    = 43 TB/day  (at steady state, in = out)

Two observations that are worth saying out loud.

The ingest figure is sustained, not peak. Four gigabits per second with no diurnal pattern and no idle window is unusual — most systems get nights and weekends off, and this one does not. Capacity planning has no headroom from traffic shape, only from over-provisioning.

At steady state the system deletes as much as it writes. A retention system that is not deleting 43 TB a day is not at steady state, and that makes deletion throughput a real capacity requirement rather than a background chore.

The bill

Storage cost at AWS list prices, order of magnitude, for the 1.3 PB steady state:

The minimum-duration column is the trap, and it interacts viciously with a 30-day retention policy. If you transition objects into Glacier Instant Retrieval and then delete them at day 30, you are billed for 90 days per object anyway. You would pay for storage you deliberately destroyed.

That single interaction rules out the cheapest tiers for a short-retention system, and knowing it is a strong signal. Deep tiers pay off for the long-retention slice — the flagged incidents kept for a year — not for the rolling window.

The number that catches people

Storage volume is the obvious estimate. Object count is the one almost nobody computes, and it changes a design decision.

Segments have to be small enough to serve live viewing and to bound the damage from a corrupt write. Suppose four-second segments:

segments/camera/day = 86,400 / 4          = 21,600
fleet writes/sec    = 21,600 * 1,000 / 86,400 = 250 PUT/s, sustained
objects live        = 21,600 * 1,000 * 30 = 648,000,000

Six hundred and forty-eight million live objects, and a quarter of a thousand writes per second that never stops. At roughly $0.005 per thousand PUTs, the request charges alone run about $3,200 a month — before a single byte of storage is billed.

Now vary the segment length:

So segment length is a two-sided lever. Short segments buy lower live latency and finer-grained deletion; long segments buy cheaper requests, a far smaller index, and less metadata to manage. It is not a detail to be settled by convention, and it is one of the better things to raise unprompted.

The levers, ranked

Against the ~$30,000/month baseline, what each change is worth:

The last row is the point of the table. Every meaningful saving is a decision about what and how long to record, and none of them is a decision about servers.

Next: the camera, which has already solved more of this problem than most designs give it credit for.