SOC Search Capacity & Cost Assessment
Is your Elastic or OpenSearch cluster sized for the work your SOC actually does?
We observe your existing cluster for seven consecutive days and assess its cost against ingestion, detection, investigation and historical-search demands.
- Standalone assessment
- Seven consecutive observation days
- Reduce, keep or add capacity
- Evidence for your next decision
01 / Two sizing questions
Ingest what you need. Retain what you must. Size each for the work it serves.
Data capture and search performance are different requirements.
- 01
Capture and retention
How much security data arrives, and what must remain available?
- 02
Search and serving
Which detection and investigation workloads require which performance, and how should the remaining history be accessed?
Your platform must ingest the required data and retain the required evidence. That does not automatically mean every retained record needs the same storage and search footprint. Both requirements belong in the capacity decision. Elastic: data tiers ↗
You may still need more servers. The assessment identifies what that capacity must support, rather than assuming that all collected history needs the fastest tier. See how growth affects each side →
02 / What the SOC does with it
One security dataset supports different jobs.
Detection
Scheduled rules have their own execution and look-back requirements.
Elastic: rule settings ↗Triage
Analysts investigate alerts by following related users, hosts, processes and timelines.
Elastic: alert details ↗Hunting and incident scoping
Teams may revisit older activity when the evidence requires it. Historical access remains a security requirement.
Microsoft Sentinel: historical investigation ↗
Keep the Windows, server, cloud and other evidence your organization or customers require. Validate the performance needed to detect and investigate, not a generic number of days.
In a large environment, an untested assumption can affect a substantial retained dataset. For MSPs and MSSPs, it can repeat across many customer clusters, and each customer’s requirements are its own.
03 / The whole bill
The hot tier is one example. The assessment follows the bill.
The review connects your spend to the work and operating decisions behind it. A hot-window change is one possible finding; the evidence may support keeping or increasing capacity.
- IngestWhat arrives, from which sources, and what it is used for.
- IndexingMappings, fields and replicas that multiply every byte you store.
- ComputeNode sizes and counts, and the searches and rules that keep them busy.
- StorageWhat sits on fast disk, what sits on cheaper tiers, and why.
- Data lifecycleHow long data stays in each tier, and whether that matches how it is used.
- LicensingWhat your licence or subscription unlocks, and whether a different one pays for itself.
- Step 1
Scope and setup
Agree the clusters, tenants, workloads, access, collection overhead and fixed fee before observation starts.
- Step 2
Observe for seven days
Seven consecutive days of agreed measurement, with available historical metrics and known peaks for context.
- Step 3
Analyze and read out
Review capacity, cost scenarios and confidence with your leads. Setup and analysis timing are agreed separately.
- Step 4
Validate decisions
Leave with prerequisites, acceptance criteria and rollback considerations. Implementation is separately scoped.
What we need from you
- A kickoff call to agree workloads and requirements
- The access we agree before work starts
- A named contact for questions
- Your leads at the readout
We do the analysis. Your team keeps running the SOC.
04 / What you get
Are you paying for more cluster than you need?
Get a measured view of your cluster, costed options for resizing, and a plan to test changes before they reach production. The findings may show that you can reduce capacity, should keep it, or need more.
Find out whether you are overprovisioned
See how your current capacity compares with observed ingestion, searches, detection jobs and investigation requirements. We identify unused headroom, bottlenecks and evidence gaps.
See what you could save
Compare current costs with right-sizing options. See estimated monthly and annual impact, implementation considerations, and whether savings are available now or depend on renewal.
Get a practical change plan
See the proposed changes, the requirements each must preserve, and the tests and rollback steps needed before implementation.
Recommendations are based on the agreed observation period and available history. Savings are estimates; resizing requires validation.
The analysis
Five outputs for a standalone decision
- 01
Workload profile
Actual ingestion, detection, investigation and historical-search demand, including differences between the agreed MSSP tenants and clusters.
- 02
Capacity findings
Where resources appear excessive, appropriate or insufficient, with evidence, confidence and limitations. The answer may be to reduce, keep or add capacity.
- 03
Cost and right-sizing scenarios
Current spend compared with conservative resizing and deeper architecture options, including assumptions, estimated impact and security consequences.
- 04
Cost impact and timing
Separate reductions available now from renewal-dependent reductions and capacity recovered for growth. Recovered headroom is not automatically a cash saving.
- 05
Validation roadmap
Prerequisites, risks, acceptance criteria and rollback considerations for proposed changes. A hot-window change is one possible finding, not a predetermined answer.
Included to help you act on it
So the plan reaches the people who decide
- 06
Executive decision brief
A concise account of the options, evidence, estimated impact and security consequences for finance and leadership.
- 07
Stakeholder readout
A walkthrough of the findings with your security, platform and finance leads. The assessment stands on its own, whether or not you commission further work.
SOC Search Capacity & Cost Assessment
Fixed fee agreed upfront
A bounded deployment scope, seven consecutive days of observation, then analysis and readout on an agreed schedule.
The review covers agreed workloads. No production changes by default; implementation and deeper validation are separately approved and scoped. The evidence may support keeping the architecture, changing it or adding capacity.
Discuss your cluster assessmentDouglas Miller
Elastic expert and founder of SmartSearch AI
05 / Who does the work
Requirements first. Then the budget.
The recommendation starts from your detection, investigation and retention requirements, not from a target number. Weblink Technologies has built and tuned Elasticsearch and OpenSearch for enterprise and security teams for more than 13 years, across 75+ engagements, as an Elastic partner.
06 / Start here
Find out what’s driving your logging bill.
Start with fit, timing and scope.
Who this is for
MSPs, MSSPs and SOC teams spending $100,000+ a year on Elasticsearch or OpenSearch
Licence, cloud and servers, counted across all customer clusters, or about to commit that much in new capacity. Typical sources: Windows machines and servers, cloud logs, identity systems, network and security devices.
Well under $100,000 a year and not adding capacity? This is not the right fit.
Timing. Observation runs for seven consecutive days. We agree setup, analysis and readout timing separately, including your decision deadline.
Evidence. Available historical metrics and known incident or month-end peaks help us interpret the week. Missing evidence lowers confidence; it does not justify assuming you can shrink.
Collection. Raw security data and query bodies are not required by default. Access and collection overhead are agreed before work starts.
- 01Tell us about your platform and timing.
- 02We agree scope, access, timing and the fixed fee.
- 03Setup, seven days of observation, then analysis and readout.
Good to know
Clear scope. No surprises.
What does it cost?
The fixed fee is agreed upfront for a defined set of clusters, tenants and workloads. There is no open-ended estate-wide scope. Implementation and deeper validation are separately scoped. Submitting the form does not commit you to anything.
Who is this for?
MSPs, MSSPs and SOC teams spending $100,000 or more a year on Elasticsearch or OpenSearch, counting licence, cloud and servers across all customer clusters, or about to commit that much in new capacity. We confirm fit and a bounded deployment scope before work starts.
Is everything completed in seven days?
No. Seven consecutive days refers to the observation period. Setup, analysis and the stakeholder readout have separately agreed timing. Access readiness and evidence quality affect the overall schedule.
What if the week misses an incident or month-end peak?
We use available historical metrics, known incidents and expected peaks to contextualize the observation week. Missing evidence lowers confidence and may require further observation or validation; it does not justify assuming the cluster can shrink.
Is it only about the hot tier?
No. The assessment covers ingest, indexing, compute, storage, data lifecycle and licensing. A hot-window change is one possible recommendation when the evidence supports it.
Will you tell us to cut retention?
Only if your requirements and the evidence support it. The plan shows what each change means for detections, investigations and retention. Evidence your organization or customers require is protected.
Do you guarantee a saving?
No. You get the estimated impact and evidence behind each scenario, including when savings could be realized. Estimates are not verified savings. Sometimes the right answer is to keep the architecture or add capacity.
Do you work with OpenSearch?
Yes. Our automated hot-tier measurement runs on Elasticsearch today; for OpenSearch we agree the collection approach before work starts. Tiering, hosting and licensing options differ by platform and deployment.
What access or data do you need?
We agree scoped collection and access before work starts. Raw security data and query bodies are not required by default. We review the required metrics, any collection overhead and your data-handling requirements during setup.
Will you change our production cluster?
No production changes by default. Any customer-side collection settings are agreed in advance. Implementation and deeper validation require separate approval and scope.
Our decision is close. Can you still help?
Tell us the date. We check the real cutoff and access first. Completion before a near-term deadline is not guaranteed.
What happens after I submit the form?
Your request is stored privately and sent to Douglas Miller. He reviews your timing and replies to discuss fit and scope. Nothing is booked and no work starts on submission.