Cloud for Data Science — AWS vs GCP vs Azure 2026

A data scientist's laptop stops being enough at a predictable moment: the dataset no longer fits in memory, the model takes a night to train, or a colleague needs to run the same pipeline tomorrow. Renting computers by the hour solves all three, but the three biggest providers (Amazon Web Services, Google Cloud Platform, and Microsoft Azure) sell the same ideas under different names and bill for them in different ways. This article compares them on the things a data team actually touches: storage, query engines, Spark, machine learning platforms, notebooks, dashboards, free tiers, and the billing models that decide whether a month ends with a pleasant or an unpleasant invoice.

When the cloud beats a laptop, and when it does not

The case for the cloud is about shape, not size. A workload that runs for 20 minutes a week and needs 64 GB of memory is cheap to rent and absurd to own. A workload that runs every hour, all year, on the same machine is a different calculation, and for that one buying hardware can win.

Here is a way to test it without trusting anyone's price list. Take the hourly rate of the instance you would rent, multiply it by the hours you would really use it per month, and compare the result with the monthly cost of owning an equivalent machine (purchase price spread over its useful life, plus power, plus the time someone spends keeping it patched). Rented capacity wins when utilization is low or spiky. Owned capacity starts to win when utilization is high and steady, and you have somebody to look after it.

Three situations tip the balance firmly toward the cloud:

• Bursty compute. Training a model for six hours, then not touching a GPU for three weeks.
• Data that outgrows one machine. Once a table is measured in terabytes, a distributed query engine does the job that no laptop can.
• Shared, repeatable work. A pipeline that has to run on a schedule, with logs and access control, belongs on infrastructure that stays on when your laptop is closed.

One situation does not: exploratory analysis on a dataset that fits in memory. For that, an in-process engine on a laptop is often faster than a round trip to a cluster, a point our DuckDB vs Pandas comparison makes with benchmarks. Treat the cloud as the place where data work scales and gets shared, not as the default place to open a notebook.

How big each provider is, and what that number does not tell you

Market share is the first number everyone quotes, and it is also the one most often quoted wrong. Synergy Research Group, which tracks worldwide cloud infrastructure services, reported on November 19, 2025 that the market reached $106.9 billion in quarterly revenue in Q3 2025. Its estimate of provider shares for that quarter is in the table below (Synergy Research Group).

Provider	Worldwide share, Q3 2025	Source
Amazon Web Services	29%	Synergy Research Group, Nov. 19, 2025
Microsoft Azure	20%	Synergy Research Group, Nov. 19, 2025
Google Cloud	13%	Synergy Research Group, Nov. 19, 2025
Big Three combined	63%	Synergy Research Group, Nov. 19, 2025

Share measures how much money flows through a provider, across every workload: web hosting, enterprise software, video streaming, and AI. It says little about which one is best for analytics. A provider with a smaller share can have a better warehouse, and a provider with a larger one can have a clumsier notebook. For a data scientist, share matters in two indirect ways. It predicts how many job postings and tutorials mention a platform, and it hints at how many third-party tools integrate with it first.

What a cloud data science stack is made of

Before comparing brands, it helps to see the parts. A useful picture is a restaurant kitchen. Object storage is the walk-in pantry: cheap, huge, and slow to browse. A query engine is the prep station that turns raw ingredients into something usable. A machine learning platform is the line cook who follows a recipe repeatedly and consistently. Dashboards are the pass where finished plates go out to customers. Every provider builds all of these rooms; they differ in how the doors connect.

Layer	What it does	AWS	Google Cloud	Azure
Object storage	Holds files of any size cheaply	S3	Cloud Storage	Blob Storage
Query files in place	SQL over data sitting in storage	Athena	BigQuery external tables	Synapse serverless SQL
Warehouse	Managed, columnar SQL analytics	Redshift	BigQuery	Synapse dedicated SQL pools
Spark	Distributed processing of big tables	EMR, Glue	Dataproc	Synapse Spark, Azure Databricks
ML platform	Training, tracking, registry, serving	SageMaker AI	Vertex AI (Gemini Enterprise Agent Platform)	Azure Machine Learning
Business intelligence	Dashboards for non-coders	QuickSight	Looker Studio	Power BI

The mapping is loose, because the products are not identical twins. BigQuery, for instance, is both a warehouse and a way to query external files, so it appears twice. If you know one provider's vocabulary, this table is the translation key for the other two, and the habit of translating is more valuable than any single brand.

Worth knowing: Amazon S3 offers strong read-after-write consistency for object PUT and DELETE requests in every AWS Region, so a file you just wrote is the file you read next (AWS S3 documentation). That guarantee removes a whole class of "the file is not there yet" bugs from pipelines.

Amazon Web Services: the broadest catalog

AWS is the provider with the most services and, for data teams, the longest list of ways to do the same job. That breadth is a strength when you need an unusual capability and a weakness when you are choosing among five tools for a simple task.

Storage and query on AWS

The usual starting point is S3, an object store that organizes files into buckets. Its documentation now describes several bucket types, including table buckets for Apache Iceberg tables and vector buckets for embeddings, alongside the original general purpose bucket. On top of S3 sits Athena, which runs SQL directly against files and charges by the amount of data a query scans. AWS prices Athena SQL queries at $5 per terabyte scanned, and its own example makes the arithmetic plain: a query scanning 3 TB costs $15 (Athena pricing).

That billing model rewards discipline. Athena's performance guide devotes whole sections to columnar storage formats and partitioning, because both reduce the bytes a query has to read (Athena performance tuning). A hypothetical shows why this matters. A dashboard that runs a query scanning 200 GB (0.2 TB) costs about $1 per run at the $5 rate. If it refreshes 50 times a day, that is $50 a day, or roughly $1,500 over 30 days, for one dashboard. Store the same data in a columnar format with sensible partitions so the query reads 10 GB, and the bill drops by a factor of 20. The numbers are illustrative, but the lever is real.

Redshift and Glue

For a warehouse, AWS offers Redshift. Its Serverless option bills at $0.375 per RPU-hour (a Redshift Processing Unit, a bundle of compute and memory), charged per second with a 60-second minimum, and base capacity can be set between 4 and 1,024 RPUs. Redshift managed storage is listed at $0.024 per GB-month, billed independently of how many compute nodes you run (Redshift pricing). For data preparation, AWS Glue prices ETL jobs at $0.44 per DPU-hour, billed by the second (Glue pricing). A DPU is a data processing unit, Glue's measure of workers.

SageMaker, now a wider umbrella

SageMaker used to mean "the AWS machine learning platform." AWS now describes it as "the center for all your data, analytics, and AI," with SageMaker Unified Studio as a single development environment, SageMaker AI covering model development (including HyperPod for distributed training, JumpStart, and MLOps tooling), a lakehouse layer that unifies S3 data lakes with Redshift warehouses, and a catalog for governance (SageMaker overview). The upshot for a practitioner is that older tutorials may show a console that no longer looks the same. Check the date on any SageMaker walkthrough before copying its steps.

Where AWS fits

AWS suits teams that want the widest set of building blocks and are comfortable assembling them. It is a sensible choice when your company already runs production systems there, since moving data between services inside one provider is simpler and often cheaper than moving it across providers. The cost of that flexibility is choice overload: a newcomer facing S3, Athena, Glue, EMR, Redshift, and SageMaker has to learn which of them they actually need.

Google Cloud: built around the warehouse

Google Cloud's data story starts with BigQuery. It is a serverless warehouse, meaning there is no cluster to size or patch; you load or point at data and write SQL.

How BigQuery charges

BigQuery's on-demand model bills for the amount of data a query processes, measured in tebibytes (TiB, 1,024 GiB). Google's cost documentation lists the controls that follow from that model (BigQuery cost best practices):

• A dry run estimates the bytes a query would process before you run it.
• A maximum bytes billed setting makes a query fail rather than exceed a limit you chose.
• On tables that are not clustered, a LIMIT clause does not reduce the bytes read, and so does not reduce the cost. Many beginners assume it does.

The free tier is generous for learning: 1 TiB of querying and 10 GiB of storage per month, with no end date, though Google may change these limits with 30 days' notice (Google Cloud free features). Here is a query against one of Google's public datasets, which needs no data loading:

-- Ten most common baby names registered in Texas, 1910-2013
SELECT name, SUM(number) AS total
FROM `bigquery-public-data.usa_names.usa_1910_2013`
WHERE state = 'TX'
GROUP BY name
ORDER BY total DESC
LIMIT 10;

Run it first as a dry run (bq query --dry_run, or the validator in the console) to see how many bytes it would touch. Make that a habit, and the pay-per-scan model stops being a source of surprises.

Vertex AI and its new name

Google's machine learning platform was branded Vertex AI. Its documentation hub now carries the heading "Gemini Enterprise Agent Platform," while many components still use the older names. The documented pieces include training jobs, a model registry, a feature store, online inference endpoints, and Model Garden, a catalog of models. If you are reading an older tutorial, expect some of those labels to have moved, and search the docs for the component name, not the brand.

Colab: free, but not guaranteed

Google Colab is the notebook service that brought free GPUs to students. Its FAQ is candid about the limits: access to GPUs in the free tier is "heavily restricted," resources are "not guaranteed and not unlimited," Google does not publish the usage limits, and a free notebook can run "for at most 12 hours, depending on availability" (Colab FAQ). Paid plans buy compute units and better availability, with Pro+ supporting execution for up to 24 hours when you have enough units. For a course project, that is plenty. For a training job that must finish on a deadline, it is a gamble.

Where Google Cloud fits

Google Cloud suits analytics-heavy teams that want SQL on large data without running infrastructure, and learners who value a free tier they can use without a cloud background. Its smaller enterprise footprint (13% of spending, per the table above) means fewer shops standardize on it, which can matter for hiring and for the number of tools with first-class integrations.

Microsoft Azure: strongest where Microsoft already is

Azure is the natural pick for organizations that run on Microsoft identity, Office, and SQL Server, since single sign-on, permissions, and data sources are already in place.

Azure Machine Learning

Microsoft describes Azure Machine Learning as a service that "accelerates and manages the machine learning project lifecycle." Its studio offers managed notebooks, a no-code designer, an automated ML interface, and data labeling. Models built in PyTorch, TensorFlow, scikit-learn, XGBoost, or LightGBM can be deployed to managed endpoints for real-time or batch scoring, and MLflow integration tracks experiments (Azure Machine Learning overview).

The same page carries a warning worth heeding for anyone building language-model applications: prompt flow in Azure Machine Learning and Microsoft Foundry is scheduled for retirement on April 20, 2027, with Microsoft pointing users to the Microsoft Agent Framework. Cloud AI tooling turns over quickly, and building on a component with a published end date is a decision to make with open eyes.

Databricks and Synapse

Azure Databricks is documented on Microsoft Learn as "a unified, open analytics platform" for data, analytics, and AI. The same page notes that Delta Lake, MLflow, Apache Spark, and Unity Catalog are open source projects originally created by Databricks employees, which matters for portability, since skills and code transfer to other places those projects run (Azure Databricks overview). For teams whose daily work is large-scale ETL (extract, transform, load) in Spark, that is a strong pairing, and our Apache Spark explainer covers the engine underneath.

Azure Synapse Analytics, meanwhile, bundles SQL, Spark, pipelines, and a log-analytics engine. Its SQL side comes in a serverless model for unpredictable workloads and dedicated pools that reserve capacity for steady ones (Synapse overview). That overview page carries a 2024 date, so confirm the current product direction with Microsoft before starting a new warehouse project on it.

Power BI

For dashboards, Power BI Desktop is a free download, while sharing and collaboration need a paid license. Microsoft lists Power BI Pro at $14.00 per user per month and Premium Per User at $24.00, both billed yearly (Power BI pricing). Teams already living in Excel and Teams often find this the shortest road from a model's output to a chart a manager will open.

Where Azure fits

Azure fits organizations with Microsoft licenses and identity already in place, teams doing Spark-heavy engineering on Databricks, and regulated environments where the existing Microsoft compliance relationship is an asset. It is a less obvious pick for an individual learner who has no Microsoft environment to plug into.

How each provider bills: the part that causes surprises

Two billing philosophies run through all three clouds, and recognizing which one a service uses is worth more than memorizing price lists.

Pay per byte scanned. BigQuery on-demand and Athena charge according to how much data a query reads. Idle time costs nothing, and a badly written query on a huge table can cost a lot. The fix is in your SQL and your table design.

Pay per compute time. Redshift Serverless, Glue, SageMaker training jobs, and Databricks clusters charge for the seconds or hours of compute you consume. A small query is cheap, a long-running forgotten cluster is not. The fix is in your habits: shut things down.

Service	What you are billed for	Verified price point	Source
Athena	Data scanned	$5 per TB scanned	AWS Athena pricing
Glue ETL	DPU-hours, per second	$0.44 per DPU-hour	AWS Glue pricing
Redshift Serverless	RPU-hours, per second, 60 s minimum	$0.375 per RPU-hour	AWS Redshift pricing
Redshift managed storage	Data stored	$0.024 per GB-month	AWS Redshift pricing
BigQuery on-demand	Data processed per query	First 1 TiB per month free	Google Cloud free features
Power BI Pro	Per user	$14.00 per user per month	Microsoft pricing page
Power BI Premium Per User	Per user	$24.00 per user per month	Microsoft pricing page

Prices are US list prices as read from the provider pages in October 2026, and they vary by region, commitment, and contract. The BigQuery on-demand rate per TiB is deliberately absent from the table: it is published on Google's pricing page, which should be read directly because the rate differs by location and has changed before.

Costs that hide outside the service price

• Data transfer out. Moving data to the internet or another provider is billed separately from storage. AWS includes 100 GB per month of free outbound transfer, aggregated across services and Regions, as part of its pricing structure, and Google's Cloud Storage free tier includes 100 GB of outbound transfer from North America.
• Idle resources. A notebook instance left running over a weekend, or a model endpoint serving no traffic, still bills by the hour.
• Storage that outlives the project. Intermediate tables, old model artifacts, and snapshots accumulate quietly.

The cheapest protection is boring: set budget alerts on day one, tag resources with an owner, and schedule a monthly review of anything that has run for 30 days straight.

What you can try for free

Free tiers change, and several have changed recently, so this table records what each provider states on its own pages as of October 2026.

Provider	Trial credit	Always-free or ongoing allowance	Catch
AWS	Free plan with up to $200 in credits: $100 at sign-up and up to $100 more for exploring services	More than 30 services stay free within monthly limits	The free plan account closes after six months or when credits run out, unless you upgrade to the paid plan
Google Cloud	$300 Welcome credit, usable over 90 days	BigQuery: 1 TiB of queries and 10 GiB of storage per month. Cloud Storage: 5 GB-months of regional storage in US regions	Free-tier limits apply to specific regions and can change on 30 days' notice
Azure	Credit terms vary by sign-up offer, so read the current offer page	65+ always-free services; free monthly amounts of selected services for 12 months for new customers	The 12-month benefits need an upgrade to pay-as-you-go within 30 days of sign-up to continue

Sources: AWS Free Tier, Google Cloud free features, and Azure free services. Note the AWS wording in particular: its page describes the credit-based free plan as applying to new customers "as of July 15, 2025," so older advice built around a different free structure may not match how new accounts work.

A practical reading of the table: for learning SQL and analytics, Google's always-free BigQuery allowance is the least likely to expire under you. For learning a full ML platform, every provider's credits will cover a handful of experiments, and none of them covers a casual weekend of GPU training. Whatever you choose, create the budget alert before the first experiment.

Resilience and lock-in: two risks to price in

Single-region dependency

On October 19 and 20, 2025, a latent race condition in the DNS management system behind Amazon DynamoDB left the service's regional endpoint in N. Virginia (us-east-1) with an empty DNS record. AWS reported the overall event ran from 11:48 PM PDT on October 19 to 2:20 PM PDT on October 20, about 14.5 hours, with other services that depend on DynamoDB affected (AWS post-event summary). For a data team, the lesson is not that one provider is unreliable. Any pipeline pinned to one region inherits that region's bad days, and it is worth deciding in advance which jobs can wait out an outage and which need a second location.

Lock-in

Lock-in is mostly about data formats and orchestration, not about the cloud itself. Three habits keep the exits open:

1. Store data in open file and table formats such as Parquet and Apache Iceberg. S3 now offers table buckets built around Iceberg, and Azure Databricks is built on Delta Lake, which its documentation lists among open source projects.
2. Track experiments with a portable tool. MLflow is integrated with Azure Machine Learning and listed as an open source project in the Databricks docs, so run histories are not trapped in one vendor's console.
3. Keep infrastructure in code. A pipeline defined in version-controlled files can be recreated elsewhere. A pipeline built by clicking through a console cannot.

None of this makes migration free, because data transfer fees and rewritten glue code remain. It does turn migration from impossible into merely expensive, and that is often enough.

Which cloud for which situation

Rankings with stars hide the trade-offs, so this table states the reasoning in each row instead.

Your situation	Reasonable starting point	Why
Student learning SQL and analytics	Google Cloud (BigQuery free tier)	Ongoing free allowance, no expiry date, nothing to provision
Student learning ML with a GPU	Colab, then whichever provider's credits you have	Free GPUs exist but are not guaranteed; credits cover short experiments
Startup with no existing cloud	AWS or Google Cloud	Both have credits, mature managed services, and large communities
Company standardized on Microsoft 365	Azure	Identity, permissions, and Power BI are already in place
Spark-heavy data engineering	Azure Databricks, or Databricks on another cloud	The platform is the main product, and the cloud underneath matters less
SQL analytics on very large tables	BigQuery or Redshift Serverless	Managed warehouses that need no cluster sizing
Existing production workloads on one cloud	Stay on that cloud	Moving data between providers adds cost and complexity
Hiring-driven learning goal	Check job postings in your target market	Share varies by region and industry, and postings are better evidence than any average

The most common right answer is the least exciting: use the cloud your employer or client already pays for. Data gravity is real. Once terabytes sit in one provider's storage, every analysis that touches them is cheapest and fastest when it runs nearby.

Skills transfer more than the brand names suggest

The nouns differ and the verbs do not. Every provider has object storage, managed relational databases, a warehouse, a Spark service, and an ML platform with the same lifecycle: prepare data, train, register a model, deploy an endpoint, monitor. A short translation list:

Concept	AWS	Google Cloud	Azure
Object storage	S3	Cloud Storage	Blob Storage
Managed relational database	RDS	Cloud SQL	Azure SQL Database
ML platform	SageMaker AI	Vertex AI	Azure Machine Learning
Warehouse	Redshift	BigQuery	Synapse dedicated SQL pools

A learner who has trained and deployed one model on one platform has learned most of what the second platform asks, mainly the names and the permission model. The deeper skills (SQL, Python, experiment tracking, and cost awareness) carry over untouched. If you are deciding what to learn alongside the cloud, our guides to SQL for data science and the best data science tools of 2026 cover the layer that sits on top of any provider. For the model-serving side, MLOps for beginners explains what happens after training, and feature stores explained covers the shared-features pattern that SageMaker and Vertex AI both include.

Mistakes that cost real money

Most cloud bills that make headlines come from a short list of avoidable errors.

Running the biggest instance "just in case." Start small, measure, then scale. GPU hours are the expensive line item, and our explainers on why AI needs so much computing power and training versus inference show why training dominates the bill and serving dominates the long-term cost.

Treating LIMIT as a cost control. As Google's own documentation states, on non-clustered tables it does not reduce bytes read. Use partition filters, selected columns instead of SELECT *, and dry runs.

Forgetting to shut things down. Notebook servers, development endpoints, and clusters bill until stopped. Set auto-shutdown on idle where the service offers it.

Copying a stale tutorial. Product names and consoles move quickly: SageMaker's repositioning, Vertex AI's documentation rebrand, and the planned retirement of Azure's prompt flow are all recent examples. Check the page's date before following its steps.

Choosing on a benchmark you cannot reproduce. Vendor comparisons tend to favor the vendor. Run your own representative query or training job on each candidate during the free trial, and record time and cost.

Moving data without counting the transfer. Copying a large dataset between providers is billed as outbound transfer from the source. Estimate that before promising a migration date.

Frequently asked questions

Q: Should I commit to one platform first? A: For learning, yes. Go deep on one provider until you can ingest data, query it, train a model, deploy it, and read the bill. The concepts carry over, so the second platform takes far less time. For a company, the exception is a real business reason such as an acquisition or a regulatory requirement to use more than one.

Q: Is the free tier enough for real projects? A: It is enough for learning and small prototypes, particularly BigQuery's 1 TiB of monthly queries. It is not a base for production, and several free allowances come with expiry dates or restrictions that can change. Read the current terms before building on them, and set a budget alert.

Q: Is Colab good enough for serious work? A: For coursework and experiments, often yes. Google states that free GPU access is heavily restricted, not guaranteed, and that limits are unpublished, so it is a poor fit for jobs with deadlines. Paid compute units or a cloud notebook service give you predictability.

Q: Which cloud is cheapest? A: There is no honest single answer. The cheapest provider depends on the workload's billing model, region, commitments, and how well the queries or jobs are written. A scan-priced query on poorly organized data can cost more than the same job on a time-priced cluster, and the reverse is also true. Run a representative workload and compare actual bills.

Q: Do cloud certifications matter? A: They can help at the screening stage and for learning structure, and employers differ widely in how much weight they give them. A portfolio that shows a deployed model with a cost write-up often says more. Our guide to building a data science portfolio covers what to include.

Q: Can I avoid the cloud entirely? A: Yes, for work that fits on one machine. In-process analytics engines handle datasets far larger than most people expect, and our comparison of Python and R notes that both languages run happily on a laptop. The cloud becomes necessary when data, sharing, or scheduling outgrow a single machine.

The takeaway

The three providers have converged on the same menu, so the useful question is which billing model and which surrounding tools fit your work. If you query large tables often, understand whether you are paying per byte scanned or per hour of compute, because that single fact predicts most surprises. If your organization already runs on one cloud, start there, since data gravity beats marginal feature differences. And if you are learning, pick the platform with the most forgiving free allowance, set a budget alert before your first experiment, and verify any tutorial against the current documentation. The skills that compound are SQL, Python, cost awareness, and the habit of checking the bill, and those belong to you, not to any provider.

---

Read next:

• Data Engineering vs Data Science: Which Career Path 2026
• AWS Bedrock vs Google Vertex AI Compared
• Cloud Computing Explained: AWS, Azure, GCP

Prices and free-tier terms were read from provider pages in October 2026 and change often. Verify against the linked sources before committing budget.