Beginner question: What counts as 'premium' vs 'standard' log types?

At my last role managing security ops for a 2k-person fintech, I ingested about 2TB daily into Chronicle and spent months mapping this out. Here's the breakdown I built for our procurement team, focused on operational definitions.

1. **Primary Parse Complexity** - If Google has a native, detailed parser that builds rich UDM fields (user, process, network connections), it's premium. Raw firewall flow logs are standard, but CrowdStrike's process execution telemetry with command line and parent process details is premium.
2. **Source Tax** - Any log from a major paid security vendor (EDR, NDR, SIEM, Firewall) is almost always premium. I saw this with Palo Alto Strata logs, Cortex XDR, and even Splunk connector logs. Cloud audit logs from AWS CloudTrail or Azure AD are premium; generic S3 access logs are standard.
3. **Event Volume vs. Cardinality** - High-volume, low-variety logs like netflow or DNS queries are standard. Lower-volume logs with immense unique value per event, like a GCP Admin Activity audit log with 50+ populated fields, are premium. The pricing model assumes premium logs are more expensive to store and index.
4. **Contract Negotiation Point** - The final list is negotiable. In my last contract, we got Google to classify our specific VPC Flow Log format as standard after showing its limited field set, saving about $0.30 per GB ingested. You must get your final, written list of log source classifications attached to the contract.

My pick is to push for the clearest possible list in your agreement. For a straightforward use case like ingesting only cloud audit logs and a single EDR, expect about 70% of your volume to be premium. If you're mostly bringing in network and web server logs, you might keep it under 30% premium. Tell us your top three log sources by volume and I can give a sharper estimate.

You've nailed the vendor pattern. The "We Charge More Because We Can" category is spot on, but there's an even more cynical, cost-specific driver: automated correlation. Logs that feed Chronicle's built-in, out-of-the-box detections get tagged premium.

Your example about web server logs being security logs is the core of the billing ambiguity. If you use them for custom threat hunting, they're standard. If Google's pre-packaged "Web Application Attack" rule automatically consumes them, they'll often be counted as premium ingestion. The classification can change if you enable a new detection module. Always check your specific SKU mapping with your account team - it's contractual, not just technical.

Your point about *Event Volume vs. Cardinality* is critical, but I'd push further on the storage and indexing cost assumption. The per-unit compute cost for parsing a high-cardinality, low-volume GCP Admin Activity log is likely trivial compared to the real cost driver: the licensing fee for the proprietary parser logic and schema mapping.

The operational line often comes down to whether the log source requires a licensed integration, a paid partnership between Google and the vendor. If it does, that integration's development and support cost is amortized into the "premium" SKU. A generic syslog drain, even with complex data, might stay standard if there's no formal partnership, because the parsing and enrichment labor is your problem, not theirs.

That licensed integration point is a great lens to look through. It explains why some of our legacy on-prem app logs, even though they're noisy and complex, stayed as standard ingestion when we fed them via raw syslog.

But it makes the cost forecasting a moving target. A source can shift from standard to premium overnight if Google announces a new partnership with that vendor. Your billing becomes tied to their business development deals, not just your data's technical complexity.

Has anyone seen this happen mid-contract, or does the SKU mapping usually only change on renewal?

You're spot on that the "security log" example is vague and the real distinction often feels arbitrary from the outside. Your "We Charge More Because We Can" category is painfully accurate, but I'd add a practical litmus test based on my experience: logs that *natively* populate Chronicle's core entity fields (user, host, process) are almost always premium. If it takes significant parsing work on your end to get that data, it might slip under the standard wire.

That said, your list is a great starting point. I'd add "next-gen firewall logs with threat intel" to your premium column, while basic flow logs usually stay standard. The real catch is that, as others noted, the mapping isn't static.

Have you found any patterns in your evaluations where a vendor's marketing material actually lines up with the implementation contract?

Oh, that licensed integration point hits home. We ran into this exact scenario when we started piping in Okta logs. Our initial custom parser kept them as standard, but the moment we switched over to the official "Okta Integration" in the Chronicle marketplace, the billing team flagged the new data as premium.

It feels like the premium tag isn't just for the parser itself, but for the ongoing schema maintenance. If Google's team is on the hook to update fields every time Okta or CrowdStrike changes their API, they're going to charge for that service.

The cynical part is wondering if a log type gets reclassified as "standard" if the vendor partnership goes stale and Google stops updating the integration. Has anyone seen that happen?

Yeah, the licensed integration switcheroo is real. We saw the same thing with our SentinelOne data once the formal connector dropped in the marketplace. It's like you're paying a subscription for their parser team to stay awake during vendor API changes.

I hadn't considered the reclassification if a partnership goes stale, that's a really interesting point. I wonder if the logs would stay "premium" on the books even if the integration broke, just because the SKU is already in your contract. Has your account team ever given a straight answer on that, or is it always a maybe?

You've started to map out the category that causes the most confusion, and I think your initial list is directionally correct for the reasons others have already unpacked. My addition would be that the *operational line* often becomes concrete at the point of ingestion configuration. If you're setting up the feed through a dedicated, vendor-branded integration tile within the Chronicle UI, you're almost certainly opting into the premium SKU. If you're using a generic syslog forwarder or a cloud storage bucket listener with a custom parser you wrote, you have a fighting chance for standard.

The philosophy versus concrete definitions problem you mentioned is exactly why I keep a spreadsheet of every log source, its ingestion method, and the corresponding line item from our invoice. The mapping is never fully documented in public because it's a commercial negotiation, not an engineering spec.

I would add "IAM logs from SaaS providers (Okta, Duo, JumpCloud)" to your likely premium list, following the same licensed integration logic.

You're right to question the "security logs" example. In practice, the most concrete operational line I've found is the **ingestion method used within the Chronicle UI**. If you select a source from the "Integrations" catalog that has a vendor-specific name and a pre-built parser, that feed will almost always be classified as premium. If you push data to a generic syslog or Pub/Sub ingestion point, even from a security source, you can sometimes keep it standard - but you're trading off the automated parsing.

Your point about web server logs is key, and it exposes the real metric: whether the log **natively maps to UDM fields without significant transformation**. Application logs that require regex or custom parsers to extract a user or process will often be standard, even if you use them for security. The moment you enable a Google-curated detection that consumes those logs automatically, the classification pressure shifts.

That's a good question about the stale partnership. I've heard second-hand that once a SKU is in the contract, the classification sticks unless you renegotiate, even if the integration breaks. It's like buying a software license that never gets updated but you still pay maintenance.

But it makes me wonder, if the integration breaks and you have to build a custom parser as a workaround, are you *technically* still sending "premium" logs? Or does the billing system even detect that switch on the backend? Might be a loophole, or a good way to annoy your account rep.

You've zeroed in on the frustration exactly. Your "value and complexity" axis is correct, but let me make it operational from my last audit.

Your "Likely Premium" list is accurate for EDR and cloud identity logs, but I'd sharpen the cloud example. In GCP, the *Admin Activity* audit log is premium, but *Data Access* audit logs are typically standard. That's a concrete line. The premium tag hits logs that map directly to IAM changes and high-risk actions, not just any cloud event.

The real trap is assuming your ingestion method is locked. I've seen teams set up a generic syslog feed for a "standard" source, only to have an eager engineer later enable the shiny official integration in the UI for better parsing. That flips the classification to premium automatically, and you won't see it until the invoice arrives. The system tracks the source and integration method, not just the bytes.

Your point about the GCP Admin Activity versus Data Access audit logs is a critical operational distinction that I've verified in our own billing. It underscores that the "premium" label often maps to logs with high forensic value for incident response, where entity resolution is already done.

The automatic reclassification trap you described is a major cost control gap. We mitigated it by implementing Terraform for all our Chronicle ingestion configurations, treating the integration method as infrastructure-as-code. This prevents ad-hoc UI changes and gives us a commit log of any classification shifts.

A follow-up question from your audit: did you find any pattern where using the official integration but stripping out parsed fields *before* ingestion could keep the classification standard, or does the mere presence of the licensed parser trigger the premium SKU regardless of field population?

You've hit the nail on the head with the "value and complexity" angle. Your EDR and cloud identity examples are spot-on for premium, but I'd add a concrete operational line based on support burden. Logs that generate the most parsing-related support tickets for their engineering team (like when a vendor changes a JSON schema) tend to get the premium tag. That's why generic syslog is standard - you own the parsing headaches.

The web server log example is perfect for highlighting the philosophy problem. In practice, if you're using those logs for security and they're parsed into UDM fields by a Google-maintained parser, they'll likely be premium. If you're sending them raw for your own custom detections, they'd probably stay standard. The line is less about the log source and more about who does the work to make it useful in Chronicle.

They keep it vague on purpose. Your axes are right, but it's simpler: premium is anything they can sell as a "solution."

> web server logs *are* my security logs

That's the point. If you use their pre-built parser for them, they'll call it premium security telemetry. If you send them raw and parse them yourself later, it's standard.

It's a tax on convenience, not a technical category.