There is no universally superior data lake platform. Azure usually fits better into Microsoft ecosystems; AWS into distributed architectures on S3; Google Cloud into serverless analytics and open architectures with Iceberg; and Snowflake when the priority is on simplifying analytics, governance, and compute. The right decision depends on residency, interoperability, workloads, TCO, and existing capabilities.
1. Data lake
A data lake is an architecture that stores large volumes of structured, semi-structured, and unstructured data in scalable storage, typically object storage, so that various analytics, machine learning, and AI workloads can consume it later.
The key difference compared to a data warehouse is not simply “storing more data”: the lake decouples storage, transformation, and consumption, and allows information to be preserved with different levels of processing.
2. Lakehouse
A lakehouse combines the flexibility of data lake storage with capabilities traditionally associated with a warehouse: transactions, governance, schema evolution, cataloging, SQL, and query optimization.
Open formats like Apache Iceberg also allow multiple engines to operate on the same copy of the data. AWS Lake Formation supports Iceberg tables with Parquet stored in S3; Google Cloud offers managed Iceberg tables on client-owned buckets; and Snowflake allows using Iceberg with either in-house or external storage.
3. TCO of a data platform
The Total Cost of Ownership (TCO) of a data lake includes much more than storage:
- storage;
- computation;
- ingestion and transformation;
- operations and requests;
- catalog and governance;
- observability;
- networks and data transfer;
- recovery and replication;
- licenses or consumption of complementary services;
- human operation;
- migration and future departure of the platform.
Comparing only the price per TB is one of the fastest ways to approve a cheap architecture in Excel and a costly one in production.
Azure vs. AWS vs. Google Cloud vs. Snowflake for a data lake
Important: Snowflake is not equivalent one-to-one with Azure Data Lake Storage, S3, or Google Cloud Storage. The three hyperscalers provide basic infrastructure; Snowflake adds a data platform, compute, and governance layer on AWS, Azure, or Google Cloud.
| Criterion | Microsoft Azure | AWS | Google Cloud | Snowflake |
| Storage base | Azure Data Lake Storage Gen2 / Blob Storage | Amazon S3 | Cloud Storage | Storage managed by Snowflake or external storage in AWS, Azure, or GCP |
| Structure of the lake | Hierarchical namespaces, directories, and ACLs | Object storage + Glue Data Catalog/Lake Formation | Object storage + BigQuery/Lakehouse | Native Tablas and Iceberg + Horizon Catalog |
| Government | Azure RBAC + ACL POSIX + Microsoft ecosystem | Lake Formation + IAM + Glue Catalog | IAM + BigQuery + Dataplex/Lakehouse | RBAC + Horizon Catalog + Snowflake policies |
| Open formats | High compatibility via ADLS and external drives | Parquet, Iceberg, Hudi, Delta, among others | Parquet and Iceberg with strong focus on interoperability | Iceberg with external reading/writing via Horizon |
| Multi-engine | High | High | High | Growing; Horizon allows external engines compatible with Iceberg REST |
| SQL Analytics | Fabric, Synapse and other engines | Athena, Redshift, EMR | BigQuery | Snowflake SQL / virtual warehouses |
| AI/ML | Azure AI / Microsoft ecosystem | SageMaker and AWS services | Vertex AI + BigQuery | Snowpark and AI services from Snowflake |
| Operational complexity | Media | Medium-high by the number of possible components | Media | Lower-middle if the operation is focused on Snowflake |
| Dominant cost model | Storage + transactions + transfer + associated computing | Storage + requests + retrieval + transfer + computation | Storage + operations + network + BigQuery/other engines | Compute credits + storage + transfer + serverless services |
| Typical lace | Companies strongly Microsoft | AWS-native companies and modular architectures | Intensive analytics, serverless, ML, and open formats | Teams that prioritize managed platform, SQL, and unified governance |
| Risk to watch out for | Integration with the Microsoft stack | Complexity and dispersion of services | Processing/move costs and BigQuery-centric architecture | Credit consumption, egress, and dependency on the Snowflake layer |
Azure Data Lake Storage uses the Blob Storage capabilities and adds hierarchical namespace, Hadoop compatibility, RBAC, and POSIX ACLs; AWS Lake Formation centralizes the management of information stored in S3 and can apply controls at the column, row, and cell level.
Google Cloud is strengthening its architecture around Apache Iceberg: its managed Iceberg tables store data in client-owned buckets and enable interoperability with external engines. Snowflake, for its part, already allows reading and writing Iceberg tables from Iceberg-compatible REST engines through Horizon Catalog.
¿How to choose a platform for an enterprise data lake?
The correct question is not:
“Which cloud is better?”
The correct question is:
“What architecture reduces the cost and risk of moving our data from its origin to a business decision?”
At MaIA by Scanda, we start from that principle. Our Data Intelligence practice encompasses multi-source integration, MDM, governance, quality, DWH, predictive models and analytics, with an agnostic approach to the manufacturer. We don’t need to change the customer’s cloud to create value from their data.
The choice must be made based on seven variables.
Criterion 1: starting from where the data are generated and live
The first criterion should not be a comparison of functionalities. It should be the data gravity current.
Initial questions:
- Where is the ERP today?
- Where are CRM, e-commerce, POS, MES and operating systems?
- What percentage of workloads are on-premise?
- In which cloud do critical applications operate?
- Where is Power BI, Tableau, Looker, or another analytics layer located?
- Where will AI models be developed?
- How many TBs would it take to cross a cloud to reach the computing engine?
Moving large volumes of information between platforms can turn an alleged multi-cloud strategy into a permanent network bill.
When Azure has an advantage
Azure deserves more consideration when there is already a significant footprint of:
- Microsoft Entra ID;
- Power BI;
- Microsoft Fabric;
- Azure applications;
- Microsoft 365;
- NET ecosystems;
- Security controls and centralized networks in Azure.
Azure Data Lake Storage is not a standalone product of Blob Storage: Microsoft implements it on top of Storage and enables data lake capabilities through hierarchical namespace. This allows directory structure, atomic operations on directories, and POSIX ACLs.
The argument should not be “Microsoft integrates with Microsoft”. The economic argument is to avoid duplicating identity, security, networks, operation, and knowledge of the equipment when those components already exist.
When AWS has an advantage
AWS has a natural fit when:
- most of the systems are already running on AWS;
- S3 is the central repository;
- there are mature teams at IAM;
- Glue, Athena, EMR, Redshift or SageMaker are used;
- High modularity is required;
- Different units need different motors on the same lake.
Lake Formation manages data stored in S3 and uses the AWS Glue Data Catalog as a metadata layer. It can control access down to row, column, and cell levels.
In addition, AWS supports Iceberg on S3 through Glue and Lake Formation, which reduces the need to link the data to a single analytical engine.
When Google Cloud has an advantage
Google Cloud gains relevance when the priority is:
- SQL serverless analytics;
- BigQuery;
- machine learning;
- Vertex AI;
- large analytical workloads;
- Spark and Iceberg coexist with BigQuery;
- architectures where several engines must consult the same copy of the data.
Google allows Iceberg tables to be stored in client-controlled buckets and accessed through BigQuery and compatible engines. Its Lakehouse API provides a managed metastore for BigQuery, Spark, Flink, and Trino to share tables and metadata.
That changes an important discussion: the data no longer necessarily has to be copied every time the engine that processes it changes.
When Snowflake has an advantage
Snowflake should be evaluated differently.
It does not necessarily replace the hyperscaler's object storage. You can use:
- storage managed by Snowflake; or
- External customer storage in Amazon S3, Google Cloud Storage, or Azure Storage using Iceberg.
It makes more sense when a company is looking for:
- a more administered analytical layer;
- minor infrastructure operation;
- clear separation between storage and computing;
- SQL as the predominant interface;
- Unified government;
- sharing data between teams;
- maintain interoperability through Iceberg.
Starting in February 2026, Snowflake Horizon Catalog will generally allow external engines compatible with Iceberg REST to query Iceberg tables managed by Snowflake; it also supports reading and writing from external engines.
Criterion 2: Government, security and data residency
A platform can perform better and still be the wrong choice if it does not meet the constraints of:
- location of the data;
- encryption;
- identity;
- separation of functions;
- auditing;
- traceability;
- access by column or row;
- retention;
- continuity;
- access from third parties.
This criterion must be established before to compare speed or price.
The question that changes the design
Does the organization need to control only who enters the platform or also what information can be viewed within each dataset?
AWS Lake Formation allows granular policies over catalog and data. Azure combines RBAC with directory- and file-level ACLs. Google offers table-level governance and fine-grained access controls through its BigQuery/BigLake/Lakehouse stack. Snowflake centralizes controls through Horizon Catalog and RBAC.
For AI projects this matters even more: a model or agent should not be given access to information simply because it can technically consult it.
In MaIA by Scanda we contemplate a cloud-first approach, but when sovereignty or security require it, the design must allow sensitive information to remain within the authorized infrastructure and only the data necessary for each process to be extracted.
Criterion 3: Measuring interoperability and the risk of lock-in
The lock-in is not eliminated by saying “multi-cloud”.
It is necessary to identify where the lock-in lives.
It can be in:
- file format;
- table format;
- catalog;
- APIs;
- pipelines;
- security policies;
- ETL tools;
- data models;
- SQL owner;
- serverless services;
- team's competencies.
Apache Iceberg changes part of the equation
Iceberg provides transactions, schema evolution, versions, and metadata about object storage without forcing the computing engine to own the format.
AWS uses Iceberg on S3; Google uses it as the basis of its open lakehouse; and Snowflake has significantly expanded its Iceberg interoperability through Horizon Catalog.
Therefore, a more useful question for an RFP is:
“If I change my analytics engine within three years, can I continue using the same data and tables without having to rebuild the entire platform?”
That measures real portability.
Criterion 4: Calculate the total TCO, not just the cost per TB
A financial comparison should model at least:
Monthly TCO = storage + compute + ingestion + transformation + transactions + governance + observability + network/egress + operation
And separately:
Change cost = migration + reengineering + data transfer + testing + temporary double operation + training
What each platform charges
AWS documents that the cost of S3 can include storage, requests, retrieval, transfer, management, replication, and other functions.
Google Cloud Storage separates storage, processing — including operations and potential recovery charges — and network usage. BigQuery adds its own compute model, either by capacity or on-demand processing.
Azure Data Lake Storage considers storage, operations, retrieval, transfer, and, when the hierarchical namespace is enabled, metadata associated with the file and directory structure. Microsoft also notes that the size of the files affects transaction costs and analytical performance.
Snowflake separates consumption into compute, storage and data transfer, And certain serverless services generate additional consumption. The virtual warehouses consume credits while they are active.
The usual financial error
A CFO can receive four estimates such as:
“This platform costs X per TB.”.
And the four may be technically true and financially useless.
Two architectures with the same stored volume can have very different costs depending on:
- how many times the data is consulted;
- how much is moved between regions;
- how many engines process it;
- frequency of pipelines;
- volume of small files;
- retention;
- replication;
- attendance;
- computer windows.
That’s why at MaIA by Scanda we build the business case with customer data before turning an architecture into a budget. The defined working model for our practice uses information obtained through discovery and presents ROI in scenarios, not a generic proposal.
Criterion 5: decide which engines will consume the data
Before choosing where to store the information, it is necessary to know who will be using it.
If the main consumption will be Power BI and Microsoft
Azure is gaining more weight.
There will be Athena, EMR, Glue, Redshift, and SageMaker
AWS reduces friction.
If BigQuery and Vertex AI will be the main consumers
Google Cloud comes naturally.
If SQL, BI, and teams that want to abstract from infrastructure predominate
Snowflake can reduce operational complexity.
There will be several engines
The discussion should move towards:
- Parquet;
- Iceberg;
- catalog;
- ownership of the storage;
- Open APIs;
- transfer costs.
A data lake that only works properly with a motor is not necessarily an open lake; it can be a warehouse with a file storage area next to it.
Criterion 6: Evaluate AI and analytics as consumers of the lake
Building a data lake without knowing which use cases will consume it often creates a classic problem: too much information, little use.
Before deciding on a platform, at least three prioritized workloads should exist.
For example:
- forecasting;
- predictive maintenance;
- detection of abnormalities;
- corporate agents;
- computational vision;
- inventory optimization;
- financial consolidation;
- customer segmentation.
For each case it is advisable to measure:
- required sources;
- frequency;
- volume;
- allowed latency;
- sensitivity;
- historical requirement;
- processing engine;
- cost per execution;
- expected economic value.
At MaIA by Scanda, we treat Data Intelligence as the foundation that enables decisions and AI: integration, quality, governance, and analytics are part of the same problem, not independent projects.
Criterion 7: consider the operational capability of the team
Technically sophisticated architecture can destroy its own ROI if it requires ten specialists that the organization does not have.
It is necessary to evaluate:
- Current experience in Data Engineering;
- Knowledge of Python, SQL and Spark;
- maturity of DevOps/DataOps;
- FinOps;
- cloud security;
- identity management;
- government;
- pipeline monitoring;
- 24×7 support required.
AWS offers enormous modularity, but that same modularity can increase operational decisions.
Snowflake abstracts a larger part of the infrastructure, but it transfers the discipline to warehouse optimization, credit, government, and consumption.
Azure can simplify operations in companies that are already standardized in Microsoft.
Google Cloud can reduce administration in workloads focused on BigQuery and serverless services.
The correct architecture is not the one that includes more components. It is the one that the team can operate, govern and pay in a sustainable way.
Decision method for selecting platform
At MaIA by Scanda we recommend avoiding a matrix based on “number of functionalities”. Almost all providers can fill that table.
A useful matrix should weigh business constraints.
| Criterion | Suggested peso |
| Interfacing with existing systems and cloud | 20% |
| Government, security and residence | 20% |
| Performance and load types | 15% |
| Interoperability / risk of lock-in | 15% |
| TCO at 3 years | 15% |
| AI, ML and future analytics | 10% |
| Team capabilities | 5% |
| Total | 100% |
Step 1. Inventory the starting point
Documenting:
- source systems;
- current volume;
- annual growth;
- current cloud;
- BI;
- pipelines;
- identities;
- regulatory restrictions;
- Existing contracts.
Step 2. Define three to five use cases
Not designing a lake “for everything”.
Define which decisions or processes should be enabled first.
Step 3. Modeling data movement
Measuring:
- entrance;
- departure;
- crossings between regions;
- crosses between clouds;
- frequency.
Here, the cost that storage quotes do not show usually appears.
Step 4. Define the minimum open architecture
Establish from design:
- formats;
- catalog;
- ownership;
- policies;
- scheme of zones or layers;
- life cycle.
Step 5. Build the TCO in 36 months
Not just the first year.
Include growth and at least three scenarios:
- conservative;
- probable;
- High growth.
Step 6. Create a Proof of Value
Testing a real load with real data:
- ingestion;
- transformation;
- consultation;
- government;
- cost;
- Operational time.
Step 7. Make the decision with measurable results
The result should answer:
which platform produces the required value with the lowest total cost, lower operational risk, and sufficient future freedom.
Not which one got more popcorn in the manufacturer's PowerPoint.
The special criteria for companies in Mexico
For Mexican organizations, local residency can already be specifically included in the evaluation.
Microsoft list Central Mexico, Located in Querétaro, with three availability zones. AWS has the region available. Mexico (Central), mx-central-1, Also with three Availability Zones. Google Cloud operates northamerica-south1 in Querétaro with three zones.
There is an important nuance for Snowflake: as of October 2026, its documentation of commercial regions shows Mexico Central (Querétaro) only on Microsoft Azure; no Mexican region of Snowflake appears on AWS or GCP.
That means that an organization that simultaneously demands:
- Snowflake;
- residence in Mexico;
- and a specific cloud provider;
You must verify that combination before of the final design.
The existence of a region also does not guarantee that all necessary services are available there. Each architecture must validate service by service, including recovery, replication, AI, and private connectivity.
Predictive conclusion
Between 2026 and the next few years, choosing a data lake will depend less on the physical format of the file and more on the data itself. who controls the catalog, the policies, the calculation, and the cost of moving the data.
The direction is already visible: AWS, Google Cloud and Snowflake are expanding their support for Apache Iceberg and architectures where several engines use a single copy of the information. Snowflake has even opened in 2026 the reading and writing of Iceberg to external engines through Horizon Catalog.
That is why our recommendation at MaIA by Scanda is not to design a platform solely with the first analytical load in mind. It must be designed for the second engine, the next AI model and eventual negotiation with the provider.
The provider can change. The data and its government must survive that decision.
CTA final of MaIA
The platform should not be decided before the business case is determined.
At MaIA by Scanda We design data platforms based on what your business needs to decide, automate, or predict. We evaluate your current sources, architecture, governance, costs, and use cases to determine whether it’s worth building on Azure, AWS, Google Cloud, Snowflake, or a hybrid architecture.
Before migrating data or committing budget, we build the right business case and architecture for your operation.
FAQ
1. Which is better for a data lake: Azure, AWS, Google Cloud, or Snowflake?
There is no universal winner. Azure usually has an advantage when the enterprise ecosystem is already Microsoft; AWS when S3 and AWS services concentrate workloads; Google Cloud when BigQuery, AI, and serverless analytics weigh more; and Snowflake when SQL, governance, and a managed data platform are prioritized. The decision must be validated with TCO, residency, and use cases.
2. Is it cheaper to build the data lake directly in a hyperscaler or to use Snowflake?
Storage alone cannot be compared. AWS, Azure, and Google Cloud separate storage from multiple processing services; Snowflake primarily charges for storage, transfer, and compute consumption via credits. The result depends on concurrency, query frequency, data movement, and operation. The correct comparison is a 36-month TCO with actual workloads.
3. Does Snowflake replace Azure, AWS, or Google Cloud?
Not necessarily. Snowflake operates on infrastructure from AWS, Azure, or Google Cloud and can use its own storage or Iceberg data located in external object storage. It can function as the analytics and governance layer while the data remains in the hyperscaler. The decision must define who owns the storage, catalog, policies, and compute.
Español 
English