How much storage does NAT logging need, and how do you work it out?

Subscribers, new connections per subscriber per day, bytes per stored record, and the number of days kept. Multiply those four and you have the raw figure. Everything difficult about this sits in the second number, which varies by a factor of ten between networks that appear identical from outside.

What decides the size, and what does not?

Connection count decides it. Not bandwidth, not the speed you sell, and not how much anybody downloads. A record is written when a connection is established, so a customer streaming for six hours produces very few, while a phone waking up dozens of apps produces a burst before anybody touches it.

This catches people out because every other capacity question on a network is about volume. A subscriber on a fast package and one on a slow package can produce almost the same number of records, and the household with more devices produces more than the household that uses more data.

Beyond how many customers you carry, the total moves on two things: how long material is held and whether anything is being written twice. Retention is a decision that belongs to somebody senior. Repetition is usually an accident, and a rule firing on every packet can multiply the raw figure many times over without anybody noticing the cause.

One more input hides inside the first. Subscriber counts on paper and subscriber counts in the evening are different numbers, because not every account is connected at once and not every connected line is busy. Sizing against accounts sold rather than lines carrying traffic overstates the result, usually by enough to matter.

What is the arithmetic?

Four values, in one line, with no cleverness anywhere in it.

Two of those you already know. Two need a figure to start from, and both have a defensible range.

A NAT record written as text runs to roughly 150 to 200 bytes, depending on how much of the line is kept. Stored in a structured form with indexes it lands in a similar place, sometimes a little more. Kept as compressed text it can fall to a fraction of that, because log lines repeat themselves heavily and compress well.

The connection figure per subscriber is the one worth arguing about. Residential customers commonly sit somewhere between a few thousand and several tens of thousands. That range is wide because it is genuinely wide, and using somebody else's figure is where sizing exercises go wrong.

What does the arithmetic give on a real network?

Take a network of a thousand subscribers, each producing fifteen thousand new connections a day, with records stored at a hundred and eighty bytes and kept for a year.

A terabyte for a thousand customers is a manageable number, and it is the reason this question is less frightening than it sounds. Storage of that size costs less than the equipment already sitting in the rack.

Now change one value. Halve the connection count and it is half a terabyte. Double it and it is two. That single input moves the answer more than everything else combined, which is why the next section matters more than this one.

The daily average hides something worth knowing separately. Records do not arrive evenly, they arrive in an evening peak that can run several times the daily mean, and that peak decides whether the collector keeps up rather than whether the disk is large enough. Size the disk on the day and check the write rate on the peak.

How do you measure your own connection count?

By counting, on your own network, for a full day. An hour will mislead you because evenings and mornings are nothing alike, and a weekday and a Sunday are nothing alike either.

1. Pick an ordinary day, not a holiday and not a day with an outage in it.
2. Count the records stored for that day, end to end.
3. Count how many subscribers were actually connected, rather than how many accounts exist.
4. Divide one by the other. That is your figure, and it is worth more than any published average.
5. Repeat it on a weekend day and take the higher of the two.

Before trusting the result, check it for repetition. Take one busy customer and set the number of rows against the count of separate source ports. Where rows heavily outnumber ports, you are measuring duplication rather than usage, and sizing against that number would buy disks to store the same connection over and over.

Networks with no collection running yet cannot do this, which is the awkward case. There the sensible approach is to start at the lower end of the range, buy something that expands, and correct the figure with real numbers within the first month.

Business customers deserve a separate look before the figure is settled. A workplace with forty staff behind one account behaves nothing like a household, and a handful of those accounts can lift a network average enough to make the whole calculation wrong. Measure them apart and add them in, rather than folding them into an average that describes neither.

What has to be added on top?

The raw figure is not the disk you buy. Four things sit above it, and leaving them out is how a correctly calculated plan still runs out of room.

Indexes come first. Anything searchable at speed carries structure alongside the records, and that structure occupies space in proportion to what it indexes. How much depends on how many fields are searchable.

Then working room. Nothing should run at the edge of its disk, because that is where writes start failing and where the failure mode is losing records rather than raising an alarm. Leaving a comfortable margin is not caution, it separates a full disk from a hole in what you hold.

Then backups, which live somewhere else and cost their own space, and finally growth. Sizing against the customers you have today, on a network working hard to add more, is planning for a problem you fully intend to create.

A practical way to hold all four is to work out the raw figure, then buy roughly twice it, then choose an arrangement where adding more later does not mean rebuilding.

Compression deserves a deliberate choice instead of an assumption. Log text repeats heavily, so material that is no longer being searched every day can be squeezed hard and stored small. What it costs is time when somebody eventually wants it, which is a fair trade for older periods and a poor one for the recent weeks that get searched most.

What makes the number wrong later?

Growth is the honest one, and it is the easiest to plan for because it is visible. The rest arrive quietly.

Device counts per household keep climbing, so connections per subscriber drift upward year after year even where the customer count stays flat. A figure measured today ages, slowly, in one direction only.

Configuration changes are the sharp version. A logging rule altered during troubleshooting, a second device added to the collector, or a category switched back on can multiply the daily volume overnight, and the first sign is usually a disk filling faster than the plan said it would.

The other quiet mover is the network itself. Splitting a busy area, adding a device, or moving where translation happens changes which equipment reports and how much, and the storage plan was built when the layout looked different. Any change to how the network is laid out is a reason to look at the daily figure again.

The defence is a number somebody looks at. Records per day, checked weekly against what it was last month, catches every one of these while room remains to react. It takes a minute and it is the only part of this exercise that has to be repeated.