No existe una plataforma de data lake universalmente superior. Azure suele encajar mejor en ecosistemas Microsoft; AWS en arquitecturas distribuidas sobre S3; Google Cloud en analítica serverless y arquitecturas abiertas con Iceberg; y Snowflake cuando se prioriza simplificar analítica, gobierno y cómputo. La decisión correcta depende de residencia, interoperabilidad, cargas, TCO y capacidades existentes.
1. Data lake
Un data lake es una arquitectura que conserva grandes volúmenes de datos estructurados, semiestructurados y no estructurados en almacenamiento escalable, normalmente object storage, para que distintas cargas de analítica, machine learning e IA puedan consumirlos posteriormente.
La diferencia clave frente a un data warehouse no es simplemente “guardar más datos”: el lake desacopla almacenamiento, transformación y consumo, y permite conservar información con distintos niveles de procesamiento.
2. Lakehouse
Un lakehouse combina la flexibilidad del almacenamiento de un data lake con capacidades tradicionalmente asociadas a un warehouse: transacciones, gobierno, evolución de esquema, catálogo, SQL y optimización de consultas.
Formatos abiertos como Apache Iceberg permiten además que varios motores operen sobre una misma copia de los datos. AWS Lake Formation soporta tablas Iceberg con Parquet almacenadas en S3; Google Cloud ofrece tablas Iceberg administradas sobre buckets propiedad del cliente; y Snowflake permite utilizar Iceberg con almacenamiento propio o externo.
3. TCO de una plataforma de datos
El Total Cost of Ownership (TCO) de un data lake incluye mucho más que almacenamiento:
- almacenamiento;
- cómputo;
- ingestión y transformación;
- operaciones y solicitudes;
- catálogo y gobierno;
- observabilidad;
- redes y transferencia de datos;
- recuperación y replicación;
- licencias o consumo de servicios complementarios;
- operación humana;
- migración y salida futura de la plataforma.
Comparar únicamente el precio por TB es una de las formas más rápidas de aprobar una arquitectura barata en Excel y cara en producción.
Azure vs. AWS vs. Google Cloud vs. Snowflake para un data lake
Importante: Snowflake no es equivalente uno a uno con Azure Data Lake Storage, S3 o Google Cloud Storage. Los tres hyperscalers proporcionan infraestructura base; Snowflake agrega una capa de plataforma de datos, cómputo y gobierno sobre AWS, Azure o Google Cloud.
| Criterio | Microsoft Azure | AWS | Google Cloud | Snowflake |
| Base de almacenamiento | Azure Data Lake Storage Gen2 / Blob Storage | Amazon S3 | Cloud Storage | Storage administrado por Snowflake o almacenamiento externo en AWS, Azure o GCP |
| Estructura del lake | Namespace jerárquico, directorios y ACL | Object storage + Glue Data Catalog/Lake Formation | Object storage + BigQuery/Lakehouse | Tablas nativas e Iceberg + Horizon Catalog |
| Gobierno | Azure RBAC + ACL POSIX + ecosistema Microsoft | Lake Formation + IAM + Glue Catalog | IAM + BigQuery + Dataplex/Lakehouse | RBAC + Horizon Catalog + políticas Snowflake |
| Formatos abiertos | Alta compatibilidad vía ADLS y motores externos | Parquet, Iceberg, Hudi, Delta, entre otros | Parquet e Iceberg con fuerte orientación a interoperabilidad | Iceberg con lectura/escritura externa vía Horizon |
| Multi-engine | Alto | Alto | Alto | Creciente; Horizon permite motores externos compatibles con Iceberg REST |
| Analítica SQL | Fabric, Synapse y otros motores | Athena, Redshift, EMR | BigQuery | Snowflake SQL / virtual warehouses |
| IA/ML | Ecosistema Azure AI / Microsoft | SageMaker y servicios AWS | Vertex AI + BigQuery | Snowpark y servicios de IA de Snowflake |
| Complejidad operativa | Media | Media-alta por número de componentes posibles | Media | Baja-media si se concentra la operación en Snowflake |
| Modelo de costo dominante | Storage + transacciones + transferencia + cómputo asociado | Storage + requests + retrieval + transferencia + cómputo | Storage + operaciones + red + BigQuery/otros motores | Créditos de cómputo + storage + transferencia + servicios serverless |
| Encaje típico | Empresas fuertemente Microsoft | Empresas AWS-native y arquitecturas modulares | Analítica intensiva, serverless, ML y formatos abiertos | Equipos que priorizan plataforma administrada, SQL y gobierno unificado |
| Riesgo a vigilar | Acoplamiento al stack Microsoft | Complejidad y dispersión de servicios | Costos por procesamiento/movimiento y arquitectura BigQuery-centric | Consumo de créditos, egress y dependencia de la capa Snowflake |
Azure Data Lake Storage utiliza las capacidades de Blob Storage y agrega namespace jerárquico, compatibilidad Hadoop, RBAC y ACL POSIX; AWS Lake Formation centraliza el gobierno de información almacenada en S3 y puede aplicar controles a nivel de columna, fila y celda.
Google Cloud está reforzando su arquitectura alrededor de Apache Iceberg: sus tablas Iceberg administradas almacenan los datos en buckets propiedad del cliente y permiten interoperabilidad con motores externos. Snowflake, por su parte, ya permite leer y escribir tablas Iceberg desde motores compatibles con Iceberg REST mediante Horizon Catalog.
¿Cómo elegir plataforma para un data lake empresarial?
La pregunta correcta no es:
“¿Cuál nube es mejor?”
La pregunta correcta es:
“¿Qué arquitectura reduce el costo y el riesgo de llevar nuestros datos desde su origen hasta una decisión de negocio?”
En MaIA by Scanda partimos de ese principio. Nuestra práctica de Data Intelligence contempla integración multifFuente, MDM, gobierno, calidad, DWH, modelos predictivos y analítica, con un enfoque agnóstico de fabricante. No necesitamos cambiar la nube del cliente para crear valor sobre sus datos.
La elección debe hacerse sobre siete variables.
Criterio 1: partir de dónde viven y se generan los datos
El primer criterio no debería ser una comparación de funcionalidades. Debe ser el data gravity actual.
Preguntas iniciales:
- ¿Dónde está hoy el ERP?
- ¿Dónde están CRM, e-commerce, POS, MES y sistemas operativos?
- ¿Qué porcentaje de las cargas está on-premise?
- ¿En qué nube operan las aplicaciones críticas?
- ¿Dónde se encuentra Power BI, Tableau, Looker u otra capa analítica?
- ¿Dónde se desarrollarán los modelos de IA?
- ¿Cuántos TB cruzarían una nube para llegar al motor de cómputo?
Mover grandes volúmenes de información entre plataformas puede convertir una supuesta estrategia multi-cloud en una factura permanente de red.
Cuándo Azure tiene ventaja
Azure merece mayor ponderación cuando ya existe una huella importante de:
- Microsoft Entra ID;
- Power BI;
- Microsoft Fabric;
- aplicaciones Azure;
- Microsoft 365;
- ecosistemas .NET;
- controles de seguridad y redes centralizados en Azure.
Azure Data Lake Storage no es un producto aislado de Blob Storage: Microsoft lo implementa sobre Storage y habilita capacidades de data lake mediante hierarchical namespace. Esto permite estructura de directorios, operaciones atómicas sobre directorios y ACL POSIX.
El argumento no debería ser “Microsoft se integra con Microsoft”. El argumento económico es evitar duplicar identidad, seguridad, redes, operación y conocimiento del equipo cuando esos componentes ya existen.
Cuándo AWS tiene ventaja
AWS tiene un encaje natural cuando:
- la mayor parte de los sistemas ya corre en AWS;
- S3 es el repositorio central;
- existen equipos maduros en IAM;
- se utiliza Glue, Athena, EMR, Redshift o SageMaker;
- se requiere alta modularidad;
- distintas unidades necesitan motores diferentes sobre el mismo lake.
Lake Formation gobierna datos almacenados en S3 y utiliza el AWS Glue Data Catalog como capa de metadatos. Puede controlar acceso hasta niveles de fila, columna y celda.
Además, AWS soporta Iceberg sobre S3 mediante Glue y Lake Formation, lo que reduce la necesidad de ligar el dato a un único motor analítico.
Cuándo Google Cloud tiene ventaja
Google Cloud gana relevancia cuando la prioridad está en:
- analítica SQL serverless;
- BigQuery;
- machine learning;
- Vertex AI;
- grandes cargas analíticas;
- Spark e Iceberg coexistiendo con BigQuery;
- arquitecturas donde varios motores deban consultar la misma copia del dato.
Google permite almacenar tablas Iceberg en buckets controlados por el cliente y consultarlas mediante BigQuery y motores compatibles. Su Lakehouse API proporciona un metastore administrado para que BigQuery, Spark, Flink y Trino compartan tablas y metadatos.
Eso cambia una discusión importante: el dato ya no necesariamente tiene que copiarse cada vez que cambia el motor que lo procesa.
Cuándo Snowflake tiene ventaja
Snowflake debe evaluarse de forma diferente.
No sustituye necesariamente al object storage del hyperscaler. Puede utilizar:
- almacenamiento administrado por Snowflake; o
- almacenamiento externo del cliente en Amazon S3, Google Cloud Storage o Azure Storage mediante Iceberg.
Tiene mayor sentido cuando una empresa busca:
- una capa analítica más administrada;
- menor operación de infraestructura;
- separación clara entre almacenamiento y cómputo;
- SQL como interfaz predominante;
- gobierno unificado;
- compartir datos entre equipos;
- mantener interoperabilidad mediante Iceberg.
Desde febrero de 2026, Snowflake Horizon Catalog permite de forma general motores externos compatibles con Iceberg REST para consultar tablas Iceberg administradas por Snowflake; también soporta lectura y escritura desde motores externos.
Criterio 2: gobierno, seguridad y residencia de datos
Una plataforma puede tener mejor rendimiento y aun así ser la elección incorrecta si no satisface las restricciones de:
- ubicación del dato;
- cifrado;
- identidad;
- segregación de funciones;
- auditoría;
- trazabilidad;
- acceso por columna o fila;
- retención;
- continuidad;
- acceso desde terceros.
Este criterio debe establecerse antes de comparar velocidad o precio.
La pregunta que cambia el diseño
¿La organización necesita controlar solamente quién entra a la plataforma o también qué información puede ver dentro de cada conjunto de datos?
AWS Lake Formation permite políticas granulares sobre catálogo y datos. Azure combina RBAC con ACL a nivel de directorio y archivo. Google ofrece gobierno a nivel de tablas y controles de acceso fino mediante su stack BigQuery/BigLake/Lakehouse. Snowflake centraliza controles mediante Horizon Catalog y RBAC.
Para proyectos de IA esto importa todavía más: un modelo o agente no debería recibir acceso a información simplemente porque técnicamente puede consultarla.
En MaIA by Scanda contemplamos una ruta cloud-first, pero cuando soberanía o seguridad lo requieren, el diseño debe permitir que la información sensible permanezca dentro de la infraestructura autorizada y que sólo salgan los datos necesarios para cada proceso.
Criterio 3: medir interoperabilidad y riesgo de lock-in
El lock-in no se elimina diciendo “multi-cloud”.
Hay que identificar dónde vive el lock-in.
Puede estar en:
- formato de archivos;
- formato de tablas;
- catálogo;
- APIs;
- pipelines;
- políticas de seguridad;
- herramientas ETL;
- modelos de datos;
- SQL propietario;
- servicios serverless;
- competencias del equipo.
Apache Iceberg cambia parte de la ecuación
Iceberg proporciona transacciones, evolución de esquema, versiones y metadatos sobre almacenamiento de objetos sin obligar a que el motor de cómputo sea propietario del formato.
AWS utiliza Iceberg sobre S3; Google lo utiliza como base de su lakehouse abierto; y Snowflake ha ampliado considerablemente su interoperabilidad Iceberg mediante Horizon Catalog.
Por eso, una pregunta más útil para un RFP es:
“Si dentro de tres años cambio mi motor de analítica, ¿puedo seguir utilizando los mismos datos y tablas sin reconstruir toda la plataforma?”
Eso mide portabilidad real.
Criterio 4: calcular el TCO completo, no solo el costo por TB
Una comparación financiera debería modelar al menos:
TCO mensual = almacenamiento + cómputo + ingestión + transformación + transacciones + gobierno + observabilidad + red/egress + operación
Y por separado:
Costo de cambio = migración + reingeniería + transferencia de datos + pruebas + doble operación temporal + capacitación
Qué cobra cada plataforma
AWS documenta que el costo de S3 puede incluir almacenamiento, requests, retrieval, transferencia, gestión, replicación y otras funciones.
Google Cloud Storage separa almacenamiento, procesamiento —incluyendo operaciones y posibles cargos de recuperación— y uso de red. BigQuery agrega a esto su propio modelo de cómputo, ya sea por capacidad o por procesamiento bajo demanda.
Azure Data Lake Storage considera storage, operaciones, retrieval, transferencia y, cuando se habilita el namespace jerárquico, metadatos asociados con la estructura de archivos y directorios. Microsoft también señala que el tamaño de los archivos afecta el costo de transacciones y el rendimiento analítico.
Snowflake separa el consumo en compute, storage y data transfer, y determinados servicios serverless generan consumos adicionales. Los virtual warehouses consumen créditos mientras están activos.
El error financiero habitual
Un CFO puede recibir cuatro estimaciones como:
“Esta plataforma cuesta X por TB”.
Y las cuatro pueden ser técnicamente ciertas y financieramente inútiles.
Dos arquitecturas con el mismo volumen almacenado pueden tener costos muy distintos dependiendo de:
- cuántas veces se consulta el dato;
- cuánto se mueve entre regiones;
- cuántos motores lo procesan;
- frecuencia de pipelines;
- volumen de archivos pequeños;
- retención;
- replicación;
- concurrencia;
- ventanas de cómputo.
Por eso, en MaIA by Scanda construimos el business case con datos del cliente antes de convertir una arquitectura en presupuesto. El modelo de trabajo definido para nuestra práctica utiliza información obtenida en discovery y plantea ROI en escenarios, no una propuesta genérica.
Criterio 5: decidir qué motores consumirán los datos
Antes de elegir dónde guardar la información, hay que saber quién va a utilizarla.
Si el consumo principal será Power BI y Microsoft
Azure obtiene mayor peso.
Si habrá Athena, EMR, Glue, Redshift y SageMaker
AWS reduce fricción.
Si BigQuery y Vertex AI serán consumidores principales
Google Cloud resulta natural.
Si predominan SQL, BI y equipos que quieren abstraerse de infraestructura
Snowflake puede reducir complejidad operativa.
Si habrá varios motores
La discusión debe moverse hacia:
- Parquet;
- Iceberg;
- catálogo;
- ownership del storage;
- APIs abiertas;
- costos de transferencia.
Un data lake que sólo funciona correctamente con un motor no es necesariamente un lake abierto; puede ser un warehouse con un estacionamiento de archivos al lado.
Criterio 6: evaluar IA y analítica como consumidores del lake
Construir un data lake sin saber qué casos de uso lo consumirán suele crear un problema clásico: mucha información, poca utilización.
Antes de decidir plataforma deberían existir al menos tres cargas priorizadas.
Por ejemplo:
- forecasting;
- mantenimiento predictivo;
- detección de anomalías;
- agentes corporativos;
- visión computacional;
- optimización de inventario;
- consolidación financiera;
- segmentación de clientes.
Para cada caso conviene medir:
- fuentes requeridas;
- frecuencia;
- volumen;
- latencia permitida;
- sensibilidad;
- histórico requerido;
- motor de procesamiento;
- costo por ejecución;
- valor económico esperado.
En MaIA by Scanda tratamos Data Intelligence como la base que habilita decisiones e IA: integración multifFuente, calidad, gobierno y analítica forman parte del mismo problema, no proyectos independientes.
Criterio 7: considerar la capacidad operativa del equipo
Una arquitectura técnicamente sofisticada puede destruir su propio ROI si requiere diez especialistas que la organización no tiene.
Hay que evaluar:
- experiencia actual de Data Engineering;
- conocimiento de Python, SQL y Spark;
- madurez DevOps/DataOps;
- FinOps;
- seguridad cloud;
- administración de identidades;
- gobierno;
- monitoreo de pipelines;
- soporte 24×7 requerido.
AWS ofrece enorme modularidad, pero esa misma modularidad puede aumentar las decisiones operativas.
Snowflake abstrae una parte mayor de la infraestructura, pero traslada la disciplina hacia optimización de warehouses, créditos, gobierno y consumo.
Azure puede simplificar operación en compañías ya estandarizadas en Microsoft.
Google Cloud puede reducir administración en workloads centrados en BigQuery y servicios serverless.
La arquitectura correcta no es la que incluye más componentes. Es la que el equipo puede operar, gobernar y pagar de manera sostenible.
Método de decisión para seleccionar plataforma
En MaIA by Scanda recomendamos evitar una matriz basada en “número de funcionalidades”. Casi todos los proveedores pueden llenar esa tabla.
Una matriz útil debe ponderar restricciones de negocio.
| Criterio | Peso sugerido |
| Encaje con sistemas y nube existentes | 20% |
| Gobierno, seguridad y residencia | 20% |
| Rendimiento y tipo de cargas | 15% |
| Interoperabilidad / riesgo de lock-in | 15% |
| TCO a 3 años | 15% |
| IA, ML y analítica futura | 10% |
| Capacidades del equipo | 5% |
| Total | 100% |
Paso 1. Inventariar el punto de partida
Documentar:
- sistemas fuente;
- volumen actual;
- crecimiento anual;
- nube actual;
- BI;
- pipelines;
- identidades;
- restricciones regulatorias;
- contratos vigentes.
Paso 2. Definir tres a cinco casos de uso
No diseñar un lake “para todo”.
Definir qué decisiones o procesos debe habilitar primero.
Paso 3. Modelar movimiento de datos
Medir:
- entrada;
- salida;
- cruces entre regiones;
- cruces entre nubes;
- frecuencia.
Aquí suele aparecer el costo que las cotizaciones de almacenamiento no muestran.
Paso 4. Definir la arquitectura abierta mínima
Establecer desde diseño:
- formatos;
- catálogo;
- ownership;
- políticas;
- esquema de zonas o capas;
- ciclo de vida.
Paso 5. Construir el TCO a 36 meses
No sólo primer año.
Incluir crecimiento y al menos tres escenarios:
- conservador;
- probable;
- alto crecimiento.
Paso 6. Hacer un Proof of Value
Probar una carga real con datos reales:
- ingestión;
- transformación;
- consulta;
- gobierno;
- costo;
- tiempo operativo.
Paso 7. Tomar la decisión con resultados medidos
El resultado debería responder:
qué plataforma produce el valor requerido con menor costo total, menor riesgo operativo y suficiente libertad futura.
No cuál obtuvo más palomitas en el PowerPoint del fabricante.
El criterio especial para empresas en México
Para organizaciones mexicanas, la residencia local ya puede incluirse de forma concreta en la evaluación.
Microsoft lista Mexico Central, ubicada en Querétaro, con tres zonas de disponibilidad. AWS tiene disponible la región Mexico (Central), mx-central-1, también con tres Availability Zones. Google Cloud opera northamerica-south1 en Querétaro con tres zonas.
Hay un matiz importante para Snowflake: a octubre de 2026, su documentación de regiones comerciales muestra Mexico Central (Querétaro) únicamente sobre Microsoft Azure; no aparece una región mexicana de Snowflake sobre AWS o GCP.
Eso significa que una organización que exija simultáneamente:
- Snowflake;
- residencia en México;
- y un proveedor cloud específico;
debe verificar esa combinación antes del diseño definitivo.
La existencia de una región tampoco garantiza que todos los servicios necesarios estén disponibles en ella. Cada arquitectura debe validar servicio por servicio, incluyendo recuperación, replicación, IA y conectividad privada.
Conclusión predictiva
Entre 2026 y los próximos años, elegir un data lake dependerá cada vez menos del formato físico del archivo y más de quién controla el catálogo, las políticas, el cómputo y el costo de mover el dato.
La dirección ya es visible: AWS, Google Cloud y Snowflake están ampliando su soporte a Apache Iceberg y a arquitecturas donde varios motores utilizan una sola copia de la información. Snowflake incluso abrió en 2026 lectura y escritura de Iceberg a motores externos mediante Horizon Catalog.
Por eso nuestra recomendación en MaIA by Scanda es no diseñar una plataforma pensando únicamente en la primera carga analítica. Hay que diseñarla para el segundo motor, el siguiente modelo de IA y la eventual negociación con el proveedor.
El proveedor puede cambiar. El dato y su gobierno deben sobrevivir a esa decisión.
CTA final de MaIA
La plataforma no debería decidirse antes que el caso de negocio
En MaIA by Scanda diseñamos plataformas de datos a partir de lo que tu empresa necesita decidir, automatizar o predecir. Evaluamos tus fuentes actuales, arquitectura, gobierno, costos y casos de uso para determinar si conviene construir sobre Azure, AWS, Google Cloud, Snowflake o una arquitectura híbrida.
Antes de migrar datos o comprometer presupuesto, construyamos el business case y la arquitectura correcta para tu operación.
FAQ
1. ¿Cuál es mejor para un data lake: Azure, AWS, Google Cloud o Snowflake?
No existe un ganador universal. Azure suele tener ventaja cuando el ecosistema empresarial ya es Microsoft; AWS cuando S3 y los servicios AWS concentran las cargas; Google Cloud cuando BigQuery, IA y analítica serverless pesan más; y Snowflake cuando se priorizan SQL, gobierno y una plataforma de datos administrada. La decisión debe validarse con TCO, residencia y casos de uso.
2. ¿Es más barato construir el data lake directamente en un hyperscaler o usar Snowflake?
No se puede responder comparando únicamente almacenamiento. AWS, Azure y Google Cloud separan storage de múltiples servicios de procesamiento; Snowflake cobra principalmente almacenamiento, transferencia y consumo de cómputo mediante créditos. El resultado depende de concurrencia, frecuencia de consultas, movimiento de datos y operación. La comparación correcta es un TCO de 36 meses con cargas reales.
3. ¿Snowflake sustituye a Azure, AWS o Google Cloud?
No necesariamente. Snowflake opera sobre infraestructura de AWS, Azure o Google Cloud y puede utilizar almacenamiento propio o datos Iceberg ubicados en object storage externo. Puede funcionar como la capa de analítica y gobierno mientras el dato permanece en el hyperscaler. La decisión debe definir quién será propietario del almacenamiento, catálogo, políticas y cómputo.
Español 
English