I've been conducting a detailed evaluation of several SIEM and security analytics platforms for my organization, and Google Chronicle is a serious contender, particularly for its data ingestion and retention model. However, I've hit a significant roadblock during my financial analysis phase: I cannot, with any reasonable confidence, translate their published pricing into a predictable monthly operational expense.
The official pricing sheet and documentation emphasize the **Ingested Data Volume** and **Stored Data Volume** models, with costs per gigabyte per month for each. On the surface, this seems straightforward. Yet, the practical application is opaque. My primary confusion stems from the relationship between these two metrics and the operational realities.
* **Ingested Data Volume:** Is this calculated on the raw, uncompressed log size before any parsing or normalization by Chronicle? Or is it post-enrichment? A 1GB flat log file from a network appliance, once unpacked into its constituent fields within Chronicle, will likely consume more stored bytes. Which figure am I being billed for on ingestion?
* **Stored Data Volume:** The documentation states this is calculated based on the logical size of your data. Does this mean the post-parsing, post-enrichment size? Furthermore, how does the 10x compression factor they often cite play into billing? Is the billed "logical size" the uncompressed size of that structured data?
* **The Interdependency:** If I ingest 1TB of raw logs in a month, but after a year my total *stored* logical data set is 15TB, am I paying for both the 1TB monthly ingestion *and* the 15TB monthly storage concurrently? In other words, is storage billed cumulatively on the ever-growing dataset, while ingestion is billed on the monthly delta?
A concrete example would be invaluable. Let's assume a sustained ingestion of 50 GB/day of various telemetry (EDR, proxy, DNS). Using the listed pricing tiers:
1. What is the monthly ingested GB calculation? (Average daily GB * 30 days, or sum of daily varying sizes?)
2. How do I project the stored GB volume month-over-month, assuming a 12-month retention requirement?
3. Are there any ancillary costs that typically surprise new customers, such as API operation charges for extended data views, or costs associated with the Chronicle SOAR module?
I have a spreadsheet ready to compare the total cost of ownership over 36 months against other vendors, but without clarity on these calculation fundamentals, my model is fundamentally flawed. Has anyone successfully reverse-engineered a reliable billing formula or worked with Google Sales to get a transparent, worked example that isn't covered under an NDA? I am particularly interested in the transition between pricing tiers and how mixing ingestion types (e.g., some UEBA, some standard log) affects the aggregate.
Support is a product, not a department.
Oh yeah, that bill shock is real. I've been down this road with a few cloud services where the pricing model feels like it's designed by quantum physicists.
From what I remember when we did a trial, the ingested volume is based on the raw bytes you send them before any processing. Think of it as the size of the JSON, syslog, or flat file payload on the wire. But the stored volume is the tricky one, because that's the data after they've normalized it, indexed it, and probably added their own metadata. That stored number can balloon.
My advice? Run a pilot with a real, representative dataset for a month. Their dashboard should break down both metrics. That actual number, plus your expected growth, is the only way to get a forecast you can trust. The sheet is just a starting point. Good luck
it worked on my machine
You're right on the money with your confusion about raw vs. normalized data. From my own stack's telemetry pipeline, **Ingested Volume** was always the raw byte count of the payload hitting their endpoint - think gzipped JSONL files or syslog streams before they touch it.
The real kicker, and where forecasts go wrong, is the **Stored Volume** expansion. That normalized data with enriched context and indexes can easily be 1.5x to 3x the ingested size, depending on your log structure. You absolutely need that pilot with real data, like user238 said, but also monitor the *rate* of that expansion over the month. It's not a flat multiplier.
Have you looked at whether your planned retention period impacts the monthly stored cost calculation, or is that purely a function of the total volume at rest? That tripped us up initially.
K8s enthusiast
Oh man, that exact question about raw vs. normalized for the **Ingested Data Volume** cost stopped me too. I had to open a support ticket to finally get it clear. They bill on the raw, uncompressed byte size of the data *before* any Chronicle processing. So that 1GB flat file you mentioned, that's your ingestion cost right there.
But that leads to my own newbie follow-up, since you're looking at the monthly operational expense. How do you even reliably track that raw byte count before sending it to them? My pipeline has compression and batching, so my internal metrics are useless. Do you have to instrument something separate just for this bill forecast?