LogSeam’s cost model shows how SOC scale shifts with consumption

At a glance

What this is: LogSeam breaks down how a usage-based SOC deployment is priced, showing how compute, storage, request volume, and support combine into a variable all-in bill.

Why it matters: It matters because security leaders need to budget for operational scale in a way that tracks volume, retention, and cloud commitments rather than assuming a single flat SIEM cost model.

By the numbers:

• At 1 TB of raw JSON a day, LogSeam costs about $0.20 per GB all-in on Core support at on-demand prices.
• The 1 TB a day bill is $6,079 a month on demand and $5,106 on 1-year plans.
• LogSeam says about 61% of the 1 TB bill is AWS infrastructure at cost, with node fees making up the rest.

Context

LogSeam is using pricing transparency to show how SOC economics change when log volume, retention and compute shape the bill. For security operations teams, the real question is not whether a platform can ingest data, but how cost behaves as usage grows, compresses or shifts across cloud commitments.

The article also highlights a governance issue that many procurement models miss: security tooling is increasingly consumed as elastic infrastructure, not as a fixed appliance. That makes budgeting, capacity planning and operational scaling part of the control problem, especially when AI-assisted workflows and 24x7 coverage increase demand unpredictably.

Key questions

Q: How should security teams budget for a usage-based SIEM model?

A: Treat it as an operational cloud workload, not a fixed software purchase. Break the bill into ingest, storage, search, compute and support, then model how each changes with volume, retention and query load. That gives finance and security a shared view of the actual cost drivers instead of a misleading headline rate.

Q: Why does log retention change security platform economics so much?

A: Because retained data accumulates while ingest is ongoing, so storage becomes a compounding cost rather than a one-time processing expense. Compression, storage class and the length of the retention window all affect the final bill. Teams that ignore retention usually understate the true operating cost of the SOC.

Q: What signals show that a security platform is becoming too expensive to scale?

A: Watch for storage growth outpacing ingest expectations, search activity driving a disproportionate compute bill, or monthly spend rising faster than log volume. Those patterns usually mean the environment has moved beyond the assumptions in the original sizing model and needs redesign.

Q: Should security teams compare SIEM licences with cloud-native consumption models?

A: Yes, but only after normalising the comparison around retention, compute shape, cloud discounts and support coverage. A licence price alone does not capture the economic reality of a distributed SOC. The right comparison is total cost for the required workload, not vendor pricing labels.

Technical breakdown

How usage-based SIEM pricing is built

Usage-based SIEM pricing is usually a sum of compute, storage, request volume and support, rather than a single licence fee. In this model, ingest, search and aggregation are distinct workload types with different instance shapes and runtime patterns. That matters because SOC usage is not linear: one layer may scale with raw volume, another with query pressure, and another with retention. When a vendor exposes the bill line by line, it becomes easier to see which part of the system is driving spend and which part is absorbing cloud discount benefits.

Practical implication: separate ingest, search, storage and support costs before deciding where to optimise.

Why retention and compression change the economics

Retention turns a daily ingest number into an accumulated storage burden, and compression determines how quickly that burden grows. If logs compress well, the lake grows more slowly and the storage line shrinks. If retention extends from days to a year, the economics shift from short-lived processing cost to long-lived storage cost. That is why any cost model for security data must treat retention policy as a financial control, not just an operational preference. In practice, the same raw ingest figure can produce very different bills depending on compression efficiency and the storage class chosen.

Practical implication: tie retention policy and storage class decisions directly to the SOC budget model.

Why cloud commitments and dynamic capacity matter

Elastic SOC platforms inherit the economics of the underlying cloud account. If the customer already has savings plans, reserved capacity or enterprise discounts, those terms can reduce the effective cost of the security stack. Dynamic nodes on spot capacity lower spend further, but they also introduce operational assumptions that must be managed. This is less about tooling and more about where the economic control point sits. When security operations run on customer-owned cloud infrastructure, procurement strategy becomes part of the architecture, and the platform’s bill is only one layer of the total cost picture.

Practical implication: align security platform sizing with cloud procurement terms and capacity strategy.

NHI Mgmt Group analysis

Consumption governance is becoming a security operations discipline in its own right. When the platform cost moves with ingest, retention and query load, security teams cannot treat finance as a separate downstream concern. The operating model has to make cost visible at the same level as coverage and latency. Practitioners should treat elastic SOC spending as a governed control surface, not a surprise invoice.

Cost transparency changes procurement from a licence decision to an architecture decision. The article shows that the bill is shaped by instance mix, cloud discounts, storage class and support tier. That means teams need to evaluate how infrastructure choices affect observability economics before they commit to a platform. The practical conclusion is simple: budget design belongs in security architecture reviews.

AI-assisted operations increase the need for economic guardrails. The article explicitly assumes a post-AI world where agents and new workflow patterns change how security work is consumed. That creates a new governance problem: usage can expand faster than the old annual procurement model can absorb. Practitioners should plan for policy-based cost controls alongside security controls.

Elastic security platforms expose a cloud governance problem as much as a SOC one. If the customer’s own cloud discount and capacity terms flow through to the workload, then cloud procurement maturity directly affects security economics. That means identity, entitlements and cloud account governance now influence not just access risk, but also operational spend. Teams should include finance-aware cloud governance in security platform planning.

Open pricing is only useful when the organisation can operationalise the variables. Transparency helps, but it also creates room for self-inflicted inefficiency if teams do not understand workload shape, retention policy and cloud purchase terms. The point is not simply to buy the cheaper option. It is to make consumption predictable enough that security scale can grow without distorting the rest of the programme.

What this signals

Consumption-based security tooling forces procurement and architecture to converge. When the cost of visibility changes with volume, teams have to treat spend controls as part of SOC design rather than as a later finance review. That changes how budget owners think about retention, burst capacity and workload placement.

Elastic cloud pricing exposes where the real optimisation levers sit. The most important variables are not only licence terms but also storage class, compression efficiency and whether the security workload inherits existing cloud commitments. Practitioners should expect cost governance to become a normal part of platform engineering discussions.

For practitioners

• Define a security operations cost model Break SOC spend into ingest, storage, search, compute and support so finance and security can see which workload drives each line item.
• Tie retention to budget policy Set retention targets with explicit cost thresholds, then test how compressed storage changes total monthly spend before approving longer holding periods.
• Model cloud commitments against security demand Compare the platform’s compute mix with your existing savings plans or reserved capacity so the security workload benefits from the same discounts.
• Separate baseline from burst capacity Size always-on nodes for steady-state demand and treat dynamic capacity as a deliberate burst layer, not an undefined overhead.

Key takeaways

• The article’s core message is that SOC economics are governed by workload shape, not just software purchase terms.
• At 1 TB a day, LogSeam’s example lands at about $0.20 per GB on Core support, showing how quickly scale assumptions affect budget planning.
• Security teams should treat retention, compression and cloud commitment strategy as part of the architecture, because those choices materially change the operating cost.

Key terms

• Usage-Based SIEM Pricing: A pricing model where the cost of security monitoring scales with resource consumption instead of a fixed licence. The total bill usually reflects ingest, search, storage and support, which means operational choices directly influence financial outcomes.
• Log Retention: Log retention is the policy for how long logs are kept before archival or deletion. The practical question is not storage alone, but whether the organisation can preserve evidence long enough for forensics, compliance, and legal hold requirements without expanding exposure unnecessarily.
• Cloud Commitment: A purchasing agreement such as reserved capacity or savings plans that changes the effective price of cloud infrastructure. In security platforms that run in customer-owned clouds, these commitments can materially reduce the true operating cost of the service.
• Compression Ratio: The relationship between raw data volume and stored data volume after compression. Better compression reduces storage growth and total cost, especially in log-heavy environments where retention spans months or years.

Deepen your knowledge

NHI Mgmt Group’s NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security and secrets management. It helps practitioners connect identity controls to the broader security and operational decisions their programmes depend on.