OpenSearch sizing

In short

• Amazon OpenSearch Service: source × (1 + replicas) × (1 + indexing overhead) ÷ 0.95 ÷ 0.80, which AWS simplifies to about source × (1 + replicas) × 1.45.
• Self-managed OpenSearch has no service overhead; ObservKit divides stored size by a planning disk utilization target based on the default 85% low watermark.
• Shards: target roughly 10–50 GB each, and check the per-node shard limit for your deployment and version (self-managed default 1,000; Amazon OpenSearch Service is version- and heap-dependent).
• Reference scenario 250 GB/day for 90 days, one replica, 25% growth: 81.4 TB on Amazon OpenSearch Service, 72.8 TB self-managed.

Amazon OpenSearch Service vs self-managed

They are different products with different overheads, so ObservKit switches model instead of blending them. On Amazon OpenSearch Service, Linux reserves 5% of each volume and the service reserves 20% (up to 20 GiB per instance), and storage tiers such as UltraWarm and cold storage live in S3. Self-managed clusters allocate against disk watermarks (85% low, 90% high, 95% flood stage by default) that are evaluated per node. The aggregate planning target in the calculator is a simplification of that.

Storage formula

AWS’s guide notes that source data plus its index is often about 110% of the source, so ObservKit uses an index factor of 1.1 for both deployment types. Measure your own with _cat/indices?v and the pri.store.size column on a sample index.

Reference scenario Without the index overhead (factor 1.0) the Amazon result drops from 81.4 TB to 74 TB. With no replica it is 40.7 TB. Open this scenario

Shards

OpenSearch documents 10–50 GB per shard as the rule of thumb; AWS suggests 10–30 GiB for latency-sensitive search and 30–50 GiB for write-heavy workloads such as log analytics. The per-node shard limit depends on the deployment: self-managed OpenSearch defaults to 1,000 (cluster.max_shards_per_node, configurable); Amazon OpenSearch Service uses 1,000 up to OpenSearch 2.15 and, from 2.17, 1,000 per 16 GiB of JVM heap up to 4,000. The calculator estimates data nodes from the shard limit only when it knows which applies. Too many small shards add overhead per shard; very large shards recover and relocate slowly.

Reference scenario 250 GB/day indexed at 1.1 and rolled over daily with a 30 GB target gives 10 primary shards per day of about 27.5 GB each. For a 2 GB/day source the same daily rollover creates a shard of only about 2.2 GB; rolling over every 14 days brings it to about 15.4 GB. Open this scenario

Replicas

Each replica adds a full copy to hot storage and helps availability and search throughput. Zero replicas risks data loss on a node failure; AWS recommends at least one. In UltraWarm and cold storage the data is in S3, so the calculator counts primary shards only.

Storage tiers

On Amazon OpenSearch Service you can move older indexes to UltraWarm and cold storage. UltraWarm indexes are read-only and need dedicated master nodes. Reference scenario A year of retention with 14 days hot, 76 days UltraWarm and 275 days cold totals 133.3 TB, against 330.2 TB if all 365 days stay hot. Open this scenario

Worked example

Reference scenario EPS to OpenSearch: 8,000 events/s at about 700 bytes is 483.84 GB/day. Held entirely hot for 30 days on Amazon OpenSearch Service with one replica and 25% growth, the total is 52.5 TB. Open this scenario

Common mistakes

• Using the Amazon formula for a self-managed cluster, or the reverse.
• Forgetting that the index is part of the stored size (index factor).
• Counting UltraWarm and cold storage with replicas.
• Sizing from storage alone and ignoring shard counts.
• Daily rollover for a small source, producing very small shards.

Disk planning on self-managed clusters

OpenSearch protects nodes with three disk watermarks: at the low watermark (85% by default) the cluster stops allocating new shards to a node, at the high watermark (90%) it tries to relocate shards away, and at the flood stage (95%) it applies a read-only block to indexes with a shard on that node. These thresholds are checked per node, so one full node can cause trouble while the cluster average looks healthy. The calculator divides stored data by an aggregate utilization target (85% by default) to leave room for this; treat that as a starting point for a capacity conversation, not as a per-node guarantee.

Leave room for more than steady-state data. Segment merges need temporary space, a node failure moves its shards onto the survivors, and a snapshot restore or reindex briefly holds two copies of the same index. If you expect those events, lower the utilization target in Expert mode rather than relying on the growth buffer, which is meant for next year’s ingest.

Which model should you use?

• You run Amazon OpenSearch Service. Keep the deployment on Amazon, split retention across hot, UltraWarm and cold only if you will use those tiers, and expect the result to include the AWS reserved space and service overhead.
• You run OpenSearch yourself. Use the self-managed model. It has no tiers: if you also keep snapshots or a separate archive, size those on their own.
• You are still choosing a platform. Compare Elasticsearch, Loki and OpenSearch on the capacity hub, and remember that OpenSearch and Elasticsearch use different formulas and defaults here.

Limitations

The calculator does not model node counts, instance types, EBS volume types and IOPS, UltraWarm node counts, OpenSearch Optimized instances, self-managed warm tiers or searchable snapshots, backups, or the AWS guideline of at most 25 shards per GiB of JVM heap. The 20% service overhead is capped at 20 GiB per instance, so the Amazon figure overestimates when nodes have large volumes.

Sources

• Calculating storage requirements — Amazon OpenSearch Service documentation.
• Choosing the number of shards — Amazon OpenSearch Service documentation.
• UltraWarm storage — Amazon OpenSearch Service documentation.
• Cold storage — Amazon OpenSearch Service documentation.
• OpenSearch introduction — OpenSearch documentation: shard size and replicas.
• Cluster settings — OpenSearch documentation: disk watermarks and max_shards_per_node.

Last reviewed: October 2026 · OpenSearch Sizing Calculator · Capacity Planning · Methodology