Axoflow’s Storage Strategy: Building the Security Data Layer

Axoflow’s goal is to build the “ultimate” Security Data Layer - the foundation for any security operation. The first step is creating a stable, reliable, and effective pipeline. The next step is giving that pipeline memory so it can store and retrieve data.

A common debate arises: should you centralize logs before processing, or work right at the edge? The answer is the same as in all fields: it depends. Some workloads can be processed at the edge and add little value if centralized (especially for real-time detection). Others require complex correlation, thus centralization, and many fall somewhere in between. That’s why Axoflow covers all scenarios. We’ll look at three key use cases:

Storage at the Edge (with federated search)
Low-cost centralized collection
Aggregated stream processing

Storage at the Edge

Scaling storage with data is never trivial. Sometimes you don’t need centralized storage at all - you just need quick, local access to logs. This is especially valuable for operations teams during troubleshooting or debugging.

AxoStore makes this possible by offering low-footprint, queryable storage directly on the node where the data is processed. This opens new possibilities:

Store debug-level logs for a short window (e.g., 24h) to support “what if something happens” scenarios.
Collect data ad hoc for maintenance or debugging tasks.
Keep a lightweight local backup.

Traditionally, these needs were solved with hacks - like spinning up temporary storage or piping debug logs into a SIEM. Now, you can run federated queries from the AxoConsole that fan out across all AxoStore instances and return results seamlessly.

AxoLake: Low-cost Centralized Collection

Centralized log collection is still critical. Security data lakes are increasingly used as external sources for SIEMs and other security tools. A tiered security lake serves two main purposes:

Providing cheap, long-term archive storage.
Delivering accessible hot data for detection and analytics.

AxoLake was built to do both. It combines:

A scalable hot tier for fast queries.
A cost-efficient cold tier based on S3-compatible object storage.

This gives you the best of both worlds: open formats, cloud-native scalability, and long-term retention without breaking the budget.

Stream Processing with Aggregation

Sometimes workloads (e.g., login events) need to be aggregated in one place, enriched with external threat intelligence, and analyzed in real time. But that shouldn’t mean all data has to flow into the SIEM.

AxoRouter supports advanced stream processing at the edge. With policy-based routing, you can create specialized routers that:

Aggregate data locally.
Enrich it with threat intelligence.
Run real-time detection or AI.

Temporary storage ensures consistent time windows for analytics and reduces volatility. The result? Faster detection, less noise in your SOC, and more efficient use of SIEM storage.

Final Thoughts

Whether you need:

Temporary operational storage,
A cost-effective data lake, or
A special-purpose air-gapped deployment

Axoflow has you covered. With Pipeline, Storage, and AI all integrated, Axoflow provides the foundation of a true Security Data Layer.

AxoStore: A lightweight, queryable storage option built into the AxoRouter processing engine. It lets you temporarily store data locally and search from the AxoConsole, with federated queries across all AxoRouter nodes.

AxoLake: A scalable, tiered security data lake combining a fast hot tier with low-cost, S3-compatible cold storage. Designed for long-term retention, open access, and integration with SIEMs and security analytics.