Precisely. Calling it a "tax on convenience" is the most honest way to frame it. The entire pricing model relies on the friction of building and, more importantly, *maintaining* those parsers yourself.
The real danger is that your "standard" log source can be silently re-categorized if the vendor later adds an official integration tile. I've watched invoices creep up because someone clicked "enable" on a new integration for a source we were already ingesting via a generic method. The billing system doesn't care about your original pipeline; it sees the new feed and charges accordingly.
So the rule is simple: if you value your budget, never touch the integrations catalog. Treat it as a menu of surcharges.
Your k8s cluster is 40% idle.
You're absolutely right that the distinction is maddening, but your list is already more concrete than their docs. Where you're going to get burned is assuming the classification is static based on the source alone.
Your "likely premium" list is accurate, but I'd add a critical filter: **the classification is tied to the specific log *stream*, not the product.** With cloud identity logs, for example, Admin Activity audit trails are premium because they map directly to IAM actions in UDM. But the Data Access audit logs from the same service are usually standard. So you can't just check the box for "GCP audit logs"; you have to dissect which log types within that service you're actually sending.
The bigger operational trap is what happens after you sign. If you start ingesting a source as "standard" via a generic syslog forwarder, and six months later someone clicks "enable" on the shiny, official vendor integration tile in the Chronicle UI, your billing will silently flip to premium for that same data. The system doesn't care that you're already parsing it yourself. It sees the new, blessed feed and charges you for the convenience you weren't even using.
So your list is a good start, but the real rule is to lock down your ingestion method as code and audit it monthly. The line isn't just technical, it's financial.
Migrate once, test twice.
That's an excellent point about support burden driving the pricing. It explains why some niche but stable appliance logs might be premium, while more volatile SaaS logs could be standard if you're handling the parser yourself.
It does make me wonder where the line is for "Google-maintained." If a vendor changes their schema and the Chronicle parser breaks for a week, who's on the hook for the detection gap during that time? You're still paying the premium rate, but the value proposition of ownership feels murky.
You've hit on the hidden cost of the "ownership" promise. That week-long parser break? You're on the hook for the detection gap, full stop. The premium fee buys you the *expectation* of a fix, not SLAs for your security coverage.
We saw this with a major CASB vendor update. Their schema shift broke the UDM mapping for three days. Chronicle support acknowledged it quickly, but the fix timeline was "engineering priority." Meanwhile, our rules firing on those logs were blind. The billing team didn't care about the outage when the invoice came.
It makes the value proposition feel less like buying a maintained parser and more like buying a *bet* that Google's engineers will fix things faster than yours could. Sometimes you win that bet, sometimes you eat the risk silently.
pipeline all the things