Calculator tool
How this calculator works
Use the explanation to understand the formula, assumptions, and practical limits behind the calculator result.
The Core Formula
Daily raw ingest is EPS multiplied by average event size multiplied by seconds in a day, then scaled by the indexing overhead factor.
Where:
- = daily ingest in gigabytes
- = events per second
- = average compressed event size in bytes
- = indexing and storage multiplier, where 1.35 means 35% overhead
- = retention storage in terabytes
- = retention days
Worked Example — Mid-Size Enterprise
Environment: 500 endpoints, 20 servers, 5 network devices, 2 cloud environments
| Log source | Typical EPS | Avg event size |
|---|---|---|
| Windows endpoints (500) | 1,000 | 800 bytes |
| Linux servers (20) | 300 | 600 bytes |
| Firewall / IDS (5) | 800 | 500 bytes |
| Cloud (AWS/Azure) | 400 | 700 bytes |
| Total | 2,500 | ~650 bytes |
With , , , and :
At 342/month**.
EPS Benchmarks by Log Source
| Source type | Low EPS | Typical EPS | High EPS |
|---|---|---|---|
| Windows DC (per server) | 50 | 200 | 800 |
| Windows workstation (per host) | 1 | 3 | 10 |
| Linux server (per host) | 5 | 15 | 100 |
| Palo Alto / Fortinet firewall | 100 | 500 | 5,000 |
| IDS/IPS sensor | 200 | 1,000 | 10,000 |
| Web application (per node) | 10 | 100 | 2,000 |
| AWS CloudTrail (per account) | 5 | 50 | 500 |
Multiply per-host EPS by the device count in your environment. For planning, add 30–50% headroom for incident response spikes and new source onboarding.
Indexing Overhead
Raw EPS is not what your SIEM actually stores. Vendors add metadata, field extractions, and index structures:
| Factor | Effect on stored volume |
|---|---|
| Field extraction (parsing) | +20–40% |
| Index structures | +15–25% |
| Compression | −40–70% (depends on log type) |
| Net typical overhead | +10–50% |
Splunk typically runs at 1.5–2× raw; Elastic with compression closer to 1.0–1.3×. Use the overhead field to enter your vendor's observed ratio from a pilot deployment.
Storage Tiers
Not all retention data needs the same access speed or cost tier:
| Tier | Access time | Relative cost | Typical use |
|---|---|---|---|
| Hot (SSD/SAN) | <1 second | High | Last 7–30 days, active investigation |
| Warm (spinning disk) | Seconds | Medium | 30–90 days, routine queries |
| Cold (object store, S3/GCS) | Minutes | Very low | 90–365+ days, compliance archive |
A tiered architecture — hot for recent data, cold for compliance — can reduce storage cost by 60–80% compared to keeping everything on SSD. Verify your SIEM supports tiered storage before designing for it.
Frequently asked questions
Should I use peak or average EPS?
Use average EPS for storage sizing and peak EPS for ingest pipeline capacity planning.
Storage is determined by total volume over time — average EPS × seconds is the right metric. But your ingest pipeline (log forwarders, collectors, message queues) must handle peak load without dropping events. Peaks during incident response, scans, or business hours can be 5–10× the average EPS. Size ingest capacity for peak; size storage for average.
How do I find my actual EPS?
If you have an existing SIEM or log management system, query the events-per-second metric from its monitoring dashboard. Most SIEMs expose EPS as a built-in operational metric.
For a new deployment, run your log sources into a sample pipeline for one week — ideally including a business day, weekend, and a period of elevated activity. Divide total events by total seconds to get average EPS. This sample is far more reliable than a theoretical estimate and will also reveal event size averages from real log data.
What retention period should I plan for?
Start with your legal, regulatory, customer, and internal policy requirements. Do not assume one retention period fits every organization or every log type.
Useful planning anchors:
- PCI DSS commonly requires audit log history for at least 12 months, with at least the most recent 3 months immediately available for analysis.
- GDPR-style storage limitation does not set one fixed security-log period; personal data should be kept only as long as necessary for the purpose and legal basis.
- SOC 2, ISO 27001, and internal security policies usually depend on the controls, contracts, risk assessment, and auditor expectations.
From a threat-hunting perspective, many teams keep 30–90 days searchable and move older logs to cheaper retention. Confirm the final retention design with compliance, legal, and security leadership.
How does SIEM compression affect the storage estimate?
Log data often compresses well because syslog, JSON, CEF, and similar formats repeat field names and values. A SIEM does not store only raw text, though. It may add parsed fields, search indexes, correlation state, enrichment data, and retention metadata.
That is why the overhead field is an assumption, not a universal vendor truth. Some deployments store less than raw volume after compression; others store more after indexing and enrichment. The right number depends on log type, parser design, compression settings, hot/warm/cold tiering, and whether raw archives are kept separately.
Run a pilot with representative sources before committing to architecture. Measure raw bytes, indexed bytes, retained bytes after rollover, and query performance. Then enter the observed multiplier into the calculator instead of relying on a generic sizing claim.
