Deployment Scenarios

Small Office Deployment

Single-node deployment for basic log management and security monitoring

Architecture:

  • Single ELS Data Node: All-in-one deployment hosting all components

  • Licensing: 1x Log Management Plan license

  • Capacity: Up to 10 GB/day, 90-day retention

  • Use Cases: Compliance logging, basic security monitoring, operational troubleshooting

Technical Specifications:

  • Hardware: 8 CPU cores, 32 GB RAM, 1 TB SSD storage (storage requirements vary depending on log volume and retention period)

  • Components: ELS Data Node, ELS Console, ELS Network Node (co-hosted)

  • Performance: 2,000-5,000 EPS

  • Investment: Lowest entry point, suitable for budget-conscious organizations

Medium Enterprise Deployment

Multi-node cluster with role separation and enhanced performance

Architecture:

  • 3-Node Cluster: Separated roles for optimal performance and reliability

    • 3x Data Nodes (ELS Data Node for storage and processing)

    • 1x Dedicated ELS Network Node

  • Licensing: 3x Log Management Plan licenses + optional SIEM Plan

  • Capacity: 10-100 GB/day, 1-year retention

  • Use Cases: SOC operations, compliance automation, advanced threat detection

Technical Specifications:

  • Hardware per Data Node: 16 CPU cores, 64 GB RAM, 5 TB NVMe storage (storage requirements vary depending on log volume and retention period)

  • Network Node: 8 CPU cores, 16 GB RAM, 500 GB SSD (storage requirements vary depending on log volume and retention period)

  • Performance: 15,000+ EPS

  • High Availability: Node redundancy, automated failover

Large Enterprise Deployment

Distributed cluster with geographic redundancy and full SIEM capabilities

Architecture:

  • Multi-Site Cluster: 5+ nodes with geographic distribution

    • 5x Data Nodes (horizontal scaling based on data volume)

    • 2+ Dedicated ELS Network Nodes (load balancing and redundancy)

    • Multiple Network Probes (regional deployment)

  • Licensing: 5+ Log Management Plan + SIEM Plan + multiple Network Probes

  • Capacity: 100+ GB/day, multi-year retention

  • Use Cases: Enterprise SOC, advanced threat hunting, regulatory compliance

Technical Specifications:

  • Hardware per Data Node: 32+ CPU cores, 128+ GB RAM, 20+ TB NVMe storage

  • Geographic Distribution: Multi-region deployment for disaster recovery

  • Performance: 50,000+ EPS

  • Enterprise Features: Full SIEM capabilities, AI analytics, compliance automation

MSSP/Service Provider Deployment

Multi-tenant architecture for managed security service providers

Architecture:

  • Tenant Isolation: Dedicated clusters or logical separation per customer

  • Centralized Management: Unified console for multi-tenant operations

  • Scalable Infrastructure: Scalable infrastructure with flexible deployment options

  • Service Automation: Automated provisioning and customer onboarding

Licensing Considerations:

  • MSSP Pricing Model: Specialized pricing for service providers

  • Multi-Tenant Support: Built-in capabilities for customer separation

  • Flexible Scaling: Pay-as-you-grow model for service provider economics

  • Partner Support: Dedicated channel partner support and training

Supported Environments

Deployment Type

Use Case

Node Configuration

Storage Requirements

All-in-One

Small office, testing

Single node (all components)

500GB+ SSD

Distributed

Medium enterprise

3+ nodes, role separation

1TB+ per data node

Distributed: Large

Large enterprise, 24/7 SOC

5+ nodes, full redundancy

10TB+ distributed

Capacity Planning Guidelines

Two numbers drive every deployment: how much data arrives per day, and how long it stays searchable. Size the cluster to the on-disk footprint those two produce, not to the raw figure a customer quotes.

Raw volume versus on-disk size

The “GB per day” a customer reports is usually the raw or licensed figure. What lands on the data nodes differs, because the pipeline changes the size in both directions:

  • Parsing and enrichment add fields (geoIP, tags, normalized names), which grows the record.

  • Compression shrinks it. Live indices are compressed by default, and the Archive packs data further with zstd.

  • Every replica stores a full second copy, so each replica doubles the disk the primary data uses.

These factors depend on the data and the pipeline, so measure the ratio instead of assuming one. Ingest one real day into a test index, read its on-disk size, and divide by the raw input. Apply that ratio to the daily volume and the rest of the calculation follows.

Storage formula

Once you know the on-disk size of one day:

required storage = on_disk_per_day × retention_days × (1 + replicas) × 1.2

The 1.2 factor reserves headroom for segment merges, indexing overhead, and growth. Keep total usage below the disk watermarks (low 95%, high 97%, flood 99%; see Disk-based shard allocation) and plan so normal operation stays under the high watermark rather than at it.

Worked example

A customer ingests 300 GB/day raw, needs 90 days searchable, and keeps one replica. A one-day pilot shows the data lands at roughly the same size on disk after parsing and compression:

  • Flat, single tier: 300 GB × 90 × 2 × 1.2 ≈ 65 TB. Spread over three data nodes that is more than 20 TB of fast storage each. All-SSD at that size is what makes the hardware expensive.

  • Tiered: keep the recent, most-queried window on SSD and move the rest of the 90 days to cheaper high-capacity disk through shard allocation (see Index Management). The 90-day searchable requirement still holds, because the relocated data stays searchable; only the newest data needs sub-second speed. Retention is unchanged, the storage bill drops.

Retention beyond the online window belongs in the Archive, not on replicated fast disk. A one-year archive compressed with zstd is a fraction of the size of the same data held live.

Memory and shards

Storage is one axis; heap and shard count are the other. Right-size the JVM heap to the workload, cap it at 31 GB, reserve at least twice the heap in system RAM for the page cache, and keep the shard count in proportion to the heap. See JVM Configuration for the per-node tiers and the shards-per-heap ratio.

Quick reference

Use this as a starting point, then refine it with the measured ratio and the formula above. The storage column assumes tiered storage at the higher volumes, not a flat all-SSD layout.

Daily Data Volume

Recommended Architecture

ELS Data Nodes

Storage Requirements

< 10 GB/day

Single node deployment

1 node

1 TB total storage

10-100 GB/day

Small cluster

3 nodes

5 TB per node

100-500 GB/day

Medium cluster

5 nodes

10 TB per node

500GB-2TB/day

Large cluster

8+ nodes

20 TB per node

> 2TB/day

Enterprise cluster

15+ nodes

Custom sizing