Beyond SC4S: multi-destination log routing without vendor lock-in

Splunk Connect for Syslog (SC4S) is the tool a lot of security teams use to get syslog into Splunk. And for good reason: it does a genuinely hard job well. But if your architecture has outgrown a single destination — or you're tired of paying premium SIEM prices to store data you rarely search — it's worth asking what a modern, vendor-neutral pipeline looks like. This post walks through what SC4S does, where are its limits, and what multi-destination routing unlocks for a cost-aware security team.

What SC4S does well

SC4S sits in front of Splunk and turns the chaos of real-world syslog into something usable. It receives logs from network devices, firewalls, and appliances, then filters and parses those messages, corrects the broken, non-compliant syslog that so many vendors emit, and enriches each event with the Splunk sourcetype and index metadata that Splunk needs to route correctly.

That's real value. Getting sourcetype right at the edge — instead of leaning on Splunk's expensive index-time processing — is exactly the kind of work that belongs in the collection layer.

The catch: SC4S is built for Splunk, and only Splunk

SC4S is, by design, a Splunk connector. Its entire model — setting sourcetype and index, formatting for the HTTP Event Collector — assumes the data is going to Splunk. That assumption is baked deep enough that everything else becomes a workaround.

Other destinations are hard, and the data often arrives wrong

SC4S can send to other destinations, but it's an uphill effort. Configuration is manual and fragile, and because SC4S forwards essentially plain syslog, the data frequently doesn't land in the shape the receiving system expects. One common casualty is the hostname: fields that Splunk interprets correctly can end up misattributed in another SIEM, which quietly breaks host inventory, correlation, and detection downstream.

No normalization for anything but Splunk

Beyond routing, there's the question of format. SC4S doesn't normalize data to each destination's best practices — it sends raw-ish syslog and leaves the transformation, field mapping, and schema work to you. If you want data shaped for a different SIEM, or a modern schema like OCSF, you're building and maintaining that logic by hand.

The vendor database is hard to extend

Much of SC4S's parsing power lives in its device/vendor definitions. Extending that database to cover a product it doesn't already handle requires specific syslog-ng know-how, and every addition is yours to maintain going forward. For a security team that just wants its logs parsed correctly, that's a steep tax.

A shared heritage — and where the paths diverge

Here's a detail worth knowing: SC4S is built on syslog-ng. So is Axoflow. Our CEO, Balázs Scheidler, is the original creator of syslog-ng, and Axoflow actively develops AxoSyslog, a modern syslog-ng fork. Axoflow comes from the same engineering lineage that made SC4S possible — and then takes it several steps further, past the Splunk-only ceiling. As Mark Bonsack, co-author of SC4S, and Director of SE Axoflow (retired) said:

We started SC4S with the hope of it becoming something like Axoflow turned out to be. It realizes everything users want to do when it comes to automatic data classification, curation and routing.

What Axoflow does differently

Axoflow treats the destination as a first-class variable, not a fixed assumption. The result is a pipeline that's genuinely multi-destination — and that changes the economics.

Routes to many destinations, formatted correctly for each

Axoflow classifies and normalizes every message according to the requirements of where it's going. Send data from the same source to Splunk, Microsoft Sentinel, a data lake, or a detection tool, and each one receives data in the format and schema it expects — including normalization to open schemas like OCSF. No manual field mapping per destination, no hostnames mangled in transit.

A curated database for hundreds of products

Instead of asking you to extend a parser database yourself, Axoflow maintains classification, parsing, and normalization for hundreds of products out of the box, and keeps it current. Your logs get parsed and enriched correctly without you becoming a syslog-ng expert.

Data reduction that cuts SIEM cost 40–70%

Because Axoflow understands your data, it can drop the noise before it ever hits a metered destination — typically reducing ingested volume by 40–70%. SIEM licensing is priced on volume, so that reduction lands straight on your bill.

Multi-destination means reusing the same data everywhere

This is the payoff for a cost-aware team: you no longer have to send everything to Splunk. Route security-relevant events to your SIEM, mirror what you need to a data lake or detection stack, and send the high-volume, low-urgency events you're only keeping for compliance to cheap object storage like Amazon S3 or AxoLake. Have one collection pipeline, reused across SIEM, storage, and analytics, instead of paying SIEM rates to warehouse data that you'll never use and just sits there.

SC4S alternative: the short version

SC4S is a solid Splunk connector. But if you're routing to more than one place — or you want to stop paying premium prices to store logs you rarely touch — its Splunk-centric design becomes the limitation. Axoflow, built by the people behind syslog-ng, routes and normalizes your logs to any destination, cuts SIEM data volume by 40–70%, and lets you reuse the same data across every tool that needs it.

Ready to see it on your own data? Book a demo or check out the detailed Axoflow vs SC4S comparison.