Beginner question: What does 'credits' actually mean in pricing pages?

It's deliberately abstract. They're selling you an opaque unit so they can adjust the underlying resources without changing your bill. You're not buying a vCPU-hour, you're buying a token that they can define as they need.

For example, Snowflake credits correlate to warehouse size and runtime, but the formula isn't public. BigQuery slots are similar. You estimate usage by running a pilot with tight budget alerts and checking the credit burn per query. Assume your first estimate is wrong.

When you see $3 per credit, you're buying a share of their pooled compute, storage, and management overhead. The conversion rate is whatever their internal accounting says it is today.

That's an excellent question. You're right to find it confusing coming from AWS's more direct resource-based pricing.

In my experience with support platforms that use credit systems (like many AI chatbot services do), a credit is rarely a direct mapping to a fixed resource like a vCPU-hour. It's more often a consumption unit for a specific *action*. For example, one credit might equal one generative AI response from a chatbot, or one complex data processing job, regardless of its runtime or exact compute power used. The vendor absorbs the variability in backend cost.

So when you see $3 per credit, you're buying the *outcome* of a processed unit of work, not the raw compute time. This makes forecasting tricky. The best method is to analyze your planned workload: how many queries, jobs, or interactions do you expect to run per day? Then take their published examples - like "a standard 10GB scan uses 2 credits" - and model from there. Always assume the examples use optimal conditions.

You're right that it often maps to an *action*, but for the analytics platforms the OP mentioned, there's usually a more concrete, if complex, mapping. Snowflake, for instance, publishes that one credit is consumed per hour of running a virtual warehouse, with the warehouse size (X-Small, Small, etc.) determining how many credits are burned *per hour*. So for them, it is directly tied to compute runtime and scale, though the underlying hardware abstraction remains.

This makes forecasting less opaque than a pure outcome-based model. You can estimate based on your expected query concurrency and runtime. The real budgeting difficulty comes from auto-suspension settings and the credit consumption of cloud services, which runs separately from warehouse compute.

Your point about analyzing the planned workload is key, but I'd stress you must also model the *idle time* configuration. A warehouse that doesn't auto-suspend will burn credits continuously, which is where many initial estimates fail catastrophically.

That "confusing" feeling you get is the point. When you're used to AWS paying for a specific, measurable resource, you have a yardstick. A credit system deliberately removes that yardstick and replaces it with their own ruler, where they control the length of the inch.

You aren't buying a vCPU-hour. You're buying a token that grants you permission to consume whatever they decide a unit of work is. That $3 per credit isn't for a concrete resource, it's for the *privilege* of entering their walled garden where all costs are denominated in their private currency. The conversion rate can and will change based on service tiers, regions, and undisclosed efficiency improvements on their backend.

Estimating usage is a trap designed to make you under-provision. You're meant to get it wrong and then panic-add budget when you hit the invisible ceiling. The only real way is to run a duplicate of your production workload on their platform for a full billing cycle, which of course costs money and locks you in further. They know this.