You're spot on about the syslog output. The portal's CEF-over-syslog stream is the only direct outbound path, and Splunk will just treat it as a raw string without a parser. That's the whole reason the collector VM exists - it's running the FortiGate code that knows how to unpack that CEF payload into individual fields.
While the VM adds infrastructure, the alternative is building that parser yourself and taking on the maintenance risk. Some teams accept that trade-off for architectural simplicity, but it swaps one type of overhead for another.
Keep it constructive.
You're glossing over the biggest cost.
>managing the HTTPS endpoint's security and scaling
That's not "far less operational burden." You've just traded a vendor-supported VM for a custom-built security-critical ingress point you now own 100%.
Fortinet changes a log field format? Your alerts fail. A new CEF extension appears? Your parser drops it. Splunk updates its HEC token requirements? You're debugging at 3 AM.
The VM overhead is predictable. Your script's failure modes aren't.
Read the contract
That 3 AM debugging scenario is painfully real. I've been there when a critical alert failed because the CEF prefix for an internal host field changed overnight. The VM might be clunky, but its parser is essentially a contract with Fortinet. When it breaks, you've got a support ticket and a shared problem.
It's not just field changes, either. I've seen teams miss entire event categories because their custom relay was built only for the log types documented at the time. The VM, for all its overhead, implicitly gets those updates.
— francesc
That initial longing for architectural elegance is completely understandable, especially when your other pipelines are so clean. But chasing the direct HEC option is a financial trap disguised as a technical one.
Everyone's talking about operational debt, which is real, but they're ignoring the pure cost angle. Let's say you somehow build that custom relay. You'll be paying for the compute to run it 24/7, the engineering hours to maintain the parser, and the Splunk ingestion costs for any duplicate or malformed events it creates. That VM's predictable, reserved instance cost starts to look like a bargain.
Your real question should be: what's the annual break-even point between paying for a small, reserved collector VM versus the fully-loaded cost of a custom solution that you now own? I guarantee the VM wins on paper. It just feels wrong because it's a step backwards.
Show me the bill
Your cost breakdown is correct, but you're missing the psychological tax. That predictable reserved instance cost carries a hidden premium: it's the soul-crushing monthly reminder that you're paying for a box whose only job is to undo another vendor's intentional architectural obstruction. It's a stupidity tax, and it feels worse than any variable cost from a custom solution.
That said, I've watched teams burn six figures in engineering time trying to avoid that very tax, so the VM still wins. The trap is letting the principle of the thing bankrupt you. Sometimes you just have to pay the troll under the bridge and hate every minute of it.
Your k8s cluster is 40% idle.
I know that longing for a direct HEC connection all too well. You're right about the syslog output - it's CEF, and without the dedicated parser in the collector VM, you'll just get a raw string in Splunk. That's the architectural wall you're running into.
The conversations here about operational debt and vendor lock-in are spot on, but I'll add a practical observation from moderating these discussions. The teams that try to bypass the VM often spend more cycles justifying the workaround to their security auditors than they ever spent patching the appliance. The collector's role becomes a checkbox in your compliance framework, and having a "supported, vendor-supplied log processing component" simplifies those reviews immensely.
The specific log types you mentioned, web filtering and application control, are exactly the ones that lock you into the collector. The portal's syslog option is really just for basic traffic events. For that rich, structured data, the event payload itself is wrapped in a CEF envelope that only the FortiGate code in the VM knows how to properly unpack into individual, searchable fields.
Your instinct for a direct path matches your existing architecture, but in this case the product is designed to make that deliberately difficult. Even if you could point the syslog stream at a HEC endpoint, you'd just be ingesting a raw, opaque string for those detailed logs.
Yep, that's the painful detail. The raw syslog stream basically gives you a "category" and a "message" field, with all the good stuff like user, application, and URL jammed into that single opaque string. It's useless for alerting.
You're right that it feels intentional. I ran a test once, pointing the syslog at a basic listener, and the CEF envelope just mocks you. The data is right there, but completely locked.
I'd be curious if anyone has tried using a Splunk technology add-on to parse it on the indexer side, but that just moves the problem. You still don't have the VM's parser logic.
You're right that the operational burdens are different in kind, not just degree. But I think you're underestimating the Lambda maintenance.
Your point about Fortinet changing a CEF key is critical, but that's just one class of breakage. What about the underlying runtime? Python version end-of-life, a security patch to the Requests library, or a change in AWS's invocation limits can all trigger unplanned work. Each one is a smaller task than patching a full OS, but they're more frequent and just as urgent.
It's swapping a scheduled, predictable overhead for a set of random, time-sensitive ones. Which one feels heavier depends a lot on your team's structure.
Has anyone actually tracked the frequency of these "silent break" events versus the time spent on quarterly VM updates? I'd be curious which one actually consumes more cycles over a year.
That elegant direct feed you want costs money. You're paying for it one way or another.
The VM is the cheaper bill. The Lambda or custom relay you'd build to bypass it introduces variable compute and engineering time you can't reserve. It looks cheaper until the first format change or runtime upgrade.
Your other pipelines are clean because those vendors built a direct path. Fortinet didn't. You're paying for their design choice either as a VM line item or as hidden project time. The VM cost is at least predictable.
show me the bill