Comparing cloud costs across providers isn't really about which one is cheaper. Two workloads with identical compute and storage needs can land on very different bills depending on which discount mechanism you use, how the provider meters usage, and how its account hierarchy maps to your org. This guide compares the billing and discount mechanics that actually drive the difference, first across AWS, Azure, and GCP, then between Databricks and Snowflake.
TLDR
- AWS, Azure, and GCP all offer commitment-based discounts, but the mechanics differ: AWS separates Reserved Instances from Savings Plans, Azure layers Reservations with the Hybrid Benefit for existing licenses, and GCP applies sustained use discounts automatically on top of Committed Use Discounts.
- Account hierarchy differs too: AWS Organizations and linked accounts, Azure subscriptions and resource groups, and GCP projects and billing accounts all group resources differently, which is why a tagging strategy that works in one rarely ports cleanly to another.
- Databricks bills primarily on Databricks Units (DBUs) layered on top of the underlying cloud's compute cost, while Snowflake bills primarily on credits consumed by virtual warehouses, with storage priced separately in both.
- Auto-suspend and auto-scaling exist in both Databricks and Snowflake, but the levers that actually reduce spend differ: warehouse sizing and auto-suspend timing in Snowflake, cluster and workload type (all-purpose vs. jobs vs. SQL) in Databricks.
- None of this is a reason to avoid multi-cloud or multi-platform architectures. It's a reason not to expect a single dashboard to normalize the numbers for free.
AWS: granular usage types, layered discounts
AWS meters usage at a granular level, which shows up on the bill as a large number of distinct usage types even for a single service. Discounting runs on two separate mechanisms: Reserved Instances, tied to a specific instance family and region, and Savings Plans, which trade some of that specificity for flexibility across instance families in exchange for a spend commitment. Account structure runs through AWS Organizations, with linked accounts that can each carry their own tagging discipline, or lack of one.
Azure: subscriptions, resource groups, and the Hybrid Benefit
Azure's discount story adds a mechanism AWS and GCP don't have in the same form: the Azure Hybrid Benefit, which lets organizations apply existing on-premises Windows Server and SQL Server licenses toward cloud compute costs. Reservations work similarly to AWS Reserved Instances in concept. Azure's account hierarchy runs through subscriptions and resource groups, which map more naturally to organizational units than AWS's linked-account model, but that mapping only helps allocation if the hierarchy was set up with allocation in mind from the start.
GCP: automatic sustained use discounts
GCP is the outlier of the three in one respect: sustained use discounts apply automatically based on how long a resource runs within a billing month, no commitment required. Committed Use Discounts stack on top for further savings in exchange for a term commitment, similar in spirit to AWS Savings Plans. GCP's hierarchy runs through projects grouped under a billing account, which tends to produce more, smaller units of allocation than AWS or Azure's model.
What this means for a normalized, multi-cloud view
Because AWS, Azure, and GCP meter usage differently, structure discounts differently, and organize accounts differently, mapping "the same workload" across all three to a single normalized cost figure takes real reconciliation work, not just a currency conversion. This is where tag-based allocation tends to break down fastest: a tagging convention built for AWS Organizations doesn't map cleanly onto Azure resource groups or GCP projects, so multi-cloud environments accumulate allocation gaps faster than single-cloud ones. See our guide on cloud cost allocation tools for how resource-level allocation avoids depending on tagging discipline holding up across all three.
Databricks vs Snowflake: DBUs vs credits
Databricks and Snowflake solve overlapping problems (running large-scale data and AI workloads) with different pricing units. Databricks bills in Databricks Units, a rate that varies by workload type: all-purpose compute (interactive notebooks), jobs (scheduled pipelines), and SQL (warehouses for BI-style queries) are priced differently, layered on top of the underlying cloud provider's compute cost for the instances Databricks provisions. Snowflake bills primarily in credits, consumed by virtual warehouses sized from X-Small up through larger tiers, with storage billed separately from compute.
The optimization levers differ accordingly. In Snowflake, warehouse sizing and auto-suspend timing (how quickly an idle warehouse spins down) are the primary cost controls, since compute keeps consuming credits as long as a warehouse is running. In Databricks, workload type and cluster configuration matter more: an interactive all-purpose cluster left running between sessions burns DBUs at a materially different rate than a scheduled job cluster that starts and stops automatically with the job.
Frequently asked questions
Is there a multi-cloud cost management tool that works well for AWS and Azure together?
Look for a Cloud Efficiency Posture Management (CEPM) platform built around resource-level detection rather than tag-based reporting alone, since that approach doesn't depend on a tagging convention porting cleanly between AWS's and Azure's different account hierarchies.
How do I tag resources consistently across AWS, Azure, and GCP?
In practice, most organizations don't fully succeed at this, which is why resource-level cost allocation (measuring actual usage rather than relying on a tag being present and correct) tends to hold up better across providers than a shared tagging taxonomy enforced by policy alone.
Is there a single tool for tracking Snowflake, Databricks, and cloud infrastructure costs together?
Look for a platform with native coverage of both data platforms rather than one that treats them as a generic line item on the cloud bill, since Databricks' DBU-based pricing and Snowflake's credit-based pricing need separate detection logic to optimize well.
The bottom line
AWS, Azure, and GCP aren't interchangeable once you look past the compute and storage line items: their discount mechanics, metering granularity, and account hierarchies are different enough that a normalized multi-cloud view takes deliberate reconciliation, not just a shared dashboard. Databricks and Snowflake split the same difference in the data platform layer, DBUs versus credits, with different levers for controlling each. Treat both as they actually work, not as functionally identical clouds with different logos.
PointFive's DeepWaste engine covers all five natively: AWS, Azure, GCP, Databricks, and Snowflake are among its 500+ detections, alongside Kubernetes and BigQuery, so allocation and waste detection work the same way regardless of which combination an environment actually runs.
Methodology
This guide draws on public AWS, Azure, GCP, Databricks, and Snowflake pricing documentation. For corrections, reach out at pointfive.co/contact.