Hey 0xAli — quick version: ES is what drives your sizing, not the 130 GB/day. Correlation searches and accelerated data models hit CPU and disk IOPS far harder than plain indexing, so size for the search load. Rough starting point: Indexers — plan ~80–100 GB/day each with ES (vs. ~300 for plain Splunk), so 130 is ~2 indexers of load. With RF2 and wanting to survive a node loss, make 3 your floor. 16 cores / 32 GB each on SSD/NVMe. On ES, IOPS bites before CPU does. ES search head — give it its own dedicated box, nothing else co-located. 16 cores / 32–64 GB, scaled up as correlation/acceleration load grows. Ad-hoc SH — separate from ES, sized to your concurrent-user count (roughly a core per active search). HFs + CM / LM / DS — easy at this volume. The single-instance reference spec is fine; just scale the DS by how many forwarders phone home. One design note: pointing network gear straight at an HF over UDP syslog drops events under load. Put SC4S (or syslog-ng/rsyslog writing to disk with a UF reading it) in front instead. For real procurement numbers, don't eyeball it — run your inputs through a sizing calculator, match the topology against the Validated Architectures, and for an ES build it's worth a quick capacity-planning session with Splunk PS or a partner before you buy. Docs worth referencing: Reference hardware (core/RAM baselines) Summary of performance recommendations Estimate your storage requirements ES performance reference Splunk Validated Architectures Splunk Lantern – platform capacity considerations Storage sizing calculator Splunk Connect for Syslog (SC4S) ... View more