8 min de lectura<\/p>\n
Google ha anunciado en la Cloud Next 2026 componentes que convierten el multi-cloud de la teor\u00eda arquitect\u00f3nica en una decisi\u00f3n operativa. Quien como CIO del DACH a\u00fan cree que una estrategia de cross-cloud fracasa por los costes de egress y los silos de datos, deber\u00eda mirar bien de cerca: hoy la palanca est\u00e1 en d\u00f3nde se encuentran los datos y en lo que cuesta moverlos.<\/strong><\/p>\n Quien en los \u00faltimos tres a\u00f1os ha intentado seriamente distribuir cargas de trabajo entre dos hyperscalers conoce el reflejo del lado del CFO: los costes de egress. AWS, Azure y GCP cobran por cada gigabyte de tr\u00e1fico saliente importes que, sumados en un pipeline de 80 terabytes al mes, alcanzan r\u00e1pidamente cifras de cinco d\u00edgitos. Estas tarifas responden a un c\u00e1lculo deliberado: as\u00ed se ve el vendor lock-in convertido en una partida del balance. Los datos que una vez descansan en un bucket vuelven a salir caros.<\/p>\n La funci\u00f3n de cross-cloud caching que Google present\u00f3 en la Next 2026 act\u00faa precisamente aqu\u00ed. Almacena localmente en la cach\u00e9 del lakehouse los datos que una vez cruzaron la frontera de la nube, de modo que las consultas recurrentes dejan de disparar egress en cada ocasi\u00f3n. Para un entorno de reporting que consume a diario el mismo conjunto de datos de un bucket de S3, eso significa en el mejor de los casos un orden de magnitud menos de tr\u00e1fico saliente. La verdad arquitect\u00f3nica que hay detr\u00e1s: el caching es una t\u00e9cnica de sobra consolidada, pero cuando un hyperscaler lo ofrece como servicio nativo a trav\u00e9s de las fronteras de nubes ajenas, el c\u00e1lculo del ROI para el cross-cloud se desplaza de forma masiva.<\/p>\n Un grupo industrial de tama\u00f1o medio que recoge los datos de sus m\u00e1quinas en AWS S3 y los analiza con GCP BigQuery registra, seg\u00fan sus propias cifras, unos 12 TB de egress cross-cloud al mes. Con las tarifas actuales de AWS, eso supone casi 1.080 euros al mes, solo por el movimiento de datos. Con una cache hit rate del 70 por ciento en las consultas recurrentes de anal\u00edtica, el tr\u00e1fico saliente baja a unos 3,6 TB y la factura a unos 330 euros. A lo largo del a\u00f1o, la diferencia asciende a 9.000 euros en un \u00fanico camino de datos. Quien opera varios pipelines de este tipo habla pronto de efectos de seis d\u00edgitos.<\/p>\n El segundo desplazamiento procede del propio lakehouse. Google llama „borderless“ a la nueva variante: la capa del lakehouse puede referenciar tablas que residen f\u00edsicamente en S3 o en Azure Data Lake, sin que haya que replicar los datos dentro de BigQuery. Para los equipos de ingenier\u00eda eso significa: menos ETL, menos sync jobs y menos puntos en los que un schema drift rompe el informe. Para los CIO significa: la pregunta de d\u00f3nde „pertenecen“ los datos puede responderse de nuevo a nivel pol\u00edtico y contractual, sin que cada respuesta desencadene de inmediato un proyecto de migraci\u00f3n.<\/p>\n La otra cara: quien controla la capa del lakehouse controla la l\u00f3gica de consulta. Google se posiciona aqu\u00ed como intermediario neutral, algo estrat\u00e9gicamente inteligente: el compute propio se convierte en la engine de consulta est\u00e1ndar sobre buckets ajenos. AWS y Azure tienen iniciativas comparables, aunque cada una est\u00e1 m\u00e1s anclada en su propio ecosistema. La elecci\u00f3n de qu\u00e9 capa de lakehouse se convertir\u00e1 en el est\u00e1ndar de facto en una enterprise del DACH es, con ello, una decisi\u00f3n estrat\u00e9gica de vendor con una larga vigencia.<\/p>\n „Hasta ahora el multi-cloud era una respuesta de compliance. Con las nuevas capas de lakehouse y de caching se convierte en una opci\u00f3n arquitect\u00f3nica, pero la elecci\u00f3n de qui\u00e9n lidera la capa de datos sigue siendo una decisi\u00f3n de lock-in a largo plazo.“<\/p>\n<\/blockquote>\n La Gemini Enterprise Agent Platform y la Agentic Data Cloud son el anuncio de mayor calado estrat\u00e9gico. Google agrupa agent registry, skill registry, tool registry y gobernanza en una capa concebida expl\u00edcitamente para gobernar conjuntamente las cargas de trabajo de AWS, Azure y GCP. Con ello, Google orienta su propuesta hacia el mensaje „seremos el plano de control sobre vuestras apps existentes“, dejando atr\u00e1s el cl\u00e1sico „migrad vuestras apps a nosotros“. Desde la \u00f3ptica del CIO resulta atractivo porque cambia la relaci\u00f3n de inversi\u00f3n: el gasto se desplaza del proyecto de migraci\u00f3n de workloads hacia una suscripci\u00f3n abstracta de control.<\/p>\n Eso s\u00ed, el riesgo solo se desplaza una capa hacia arriba. Quien dentro de dos a\u00f1os compruebe que el agent registry y el tool inventory est\u00e1n en Google experimentar\u00e1 con el „cambiamos de plano de control“ el mismo efecto de lock-in que el multi-cloud pretend\u00eda evitar. La \u00fanica respuesta sostenible: imponer est\u00e1ndares abiertos para definiciones de agentes, esquemas de skills y manifiestos de tools antes de que los formatos propietarios creen hechos consumados.<\/p>\n Lo que a menudo se pierde en el debate arquitect\u00f3nico: el RGPD, NIS2 y el EU AI Act prescriben d\u00f3nde se procesan los datos y qui\u00e9n puede verlos, mientras que la elecci\u00f3n del proveedor de nube queda en manos de cada empresa. Una capa de cross-cloud caching que conserva datos personales en una cach\u00e9 de GCP, aunque la tabla maestra resida en un centro de datos de AWS en Alemania, no es trivial desde la \u00f3ptica de la protecci\u00f3n de datos. La pregunta operativa es: qu\u00e9 categor\u00eda de datos se puede cachear y d\u00f3nde. Y c\u00f3mo se documenta el ciclo de vida de la cach\u00e9 cuando el regulador pregunta.<\/p>\n La respuesta del vendor ser\u00e1 el „policy-driven caching“, es decir, reglas que definen qu\u00e9 clases de datos pueden cruzar qu\u00e9 fronteras de nube. En la pr\u00e1ctica eso significa: antes del primer montaje productivo de un pipeline cross-cloud debe existir un esquema de clasificaci\u00f3n de datos. Quien lo posponga se construye un generador de hallazgos de auditor\u00eda.<\/p>\n 1. \u00bfD\u00f3nde est\u00e1n los datos maestros y d\u00f3nde se permite que est\u00e9n sus copias?<\/strong> El caching suena a cuesti\u00f3n de performance, pero es una cuesti\u00f3n de compliance. La clasificaci\u00f3n de datos es el requisito previo de cualquier cross-cloud caching.<\/p>\n 2. \u00bfQu\u00e9 engine de consulta se convertir\u00e1 en el est\u00e1ndar?<\/strong> Las capas de lakehouse tienen periodos de vigencia de cinco a diez a\u00f1os. La elecci\u00f3n de si BigQuery, Athena, Synapse o Snowflake se convertir\u00e1 en la ruta de consulta dominante es una decisi\u00f3n estrat\u00e9gica de vendor que va m\u00e1s all\u00e1 del tooling.<\/p>\n 3. \u00bfQui\u00e9n controla el plano de control de los agentes?<\/strong> Si el agent registry y el tool inventory est\u00e1n en un hyperscaler, el multi-cloud est\u00e1 en buen estado a nivel de compute, pero a nivel de inteligencia vuelve a estar centralizado. Las conversaciones sobre est\u00e1ndares abiertos deben empezar ahora, antes de que transcurran dos a\u00f1os.<\/p>\n Google no anunci\u00f3 precios de lista separados en la presentaci\u00f3n. La l\u00f3gica econ\u00f3mica reside en la reducci\u00f3n de las tasas de egress existentes, y el cach\u00e9 en s\u00ed se factura dentro de la capa de compute, mediante reservas de slots de BigQuery o pricing on-demand.<\/p>\n<\/details>\n Por ahora s\u00ed: la implementaci\u00f3n del cross-cloud lakehouse presupone que BigQuery es la engine de consulta. AWS y Azure tienen enfoques comparables (Athena Federated Queries, Synapse Link) que ponen respectivamente su engine de origen en el centro. La neutralidad real entre proveedores solo llega v\u00eda est\u00e1ndares abiertos como Apache Iceberg, que los tres hyperscalers ya admiten.<\/p>\n<\/details>\n Se vuelve relevante en el momento en que una empresa opera dos cuentas de nube productivas en paralelo, algo m\u00e1s frecuente de lo esperado en el Mittelstand del DACH, a menudo por adquisiciones o por proveedores SaaS con backends de nube cableados de forma fija. Quien paga m\u00e1s de 500 euros de egress al mes deber\u00eda calcular el ROI.<\/p>\n<\/details>\n Tres cosas: un esquema de clasificaci\u00f3n de datos con permisos de cach\u00e9 claros por categor\u00eda, una decisi\u00f3n sobre qu\u00e9 engine de consulta se convertir\u00e1 en el lenguaje est\u00e1ndar y una ruta de escalada documentada para los hallazgos de auditor\u00eda en torno al contenido de la cach\u00e9. Sin estos tres puntos, la primera carta del regulador ser\u00e1 dolorosa.<\/p>\n<\/details>\n Un CDN acelera los contenidos entregados en el borde de la red. El egress caching act\u00faa antes: mantiene los conjuntos de datos consultados con frecuencia cerca de la regi\u00f3n de compute, para que las consultas cross-cloud repetidas no disparen cada vez costosas tasas de egress. La ganancia est\u00e1 en la curva de costes.<\/p>\n<\/details>\n Fuente de la imagen: generada por IA (junio de 2026), certificado C2PA incrustado en la imagen<\/em><\/p>\nLo m\u00e1s importante en breve<\/h2>\n
\n
El egress como impuesto oculto sobre cada idea multi-cloud<\/h2>\n
Un ejemplo del DACH hace tangible la magnitud<\/h3>\n
Del silo de datos al lakehouse borderless<\/h2>\n
\n
Stack de agentes: quien controla los datos controla las skills<\/h2>\n
El compliance aterriza en la capa cross-cloud<\/h2>\n
Tres preguntas de control antes del siguiente paso multi-cloud<\/h2>\n
Preguntas frecuentes<\/h2>\n
\u00bfCu\u00e1nto cuesta en concreto el cross-cloud caching?<\/strong><\/summary>\n
\u00bfFunciona esto solo con Google en el centro?<\/strong><\/summary>\n
\u00bfEs relevante para el Mittelstand del DACH o es un tema exclusivo de grandes grupos?<\/strong><\/summary>\n
\u00bfQu\u00e9 deber\u00eda estar aclarado antes del primer proyecto de pipeline cross-cloud?<\/strong><\/summary>\n
\u00bfEn qu\u00e9 se diferencia el egress caching de un CDN cl\u00e1sico?<\/strong><\/summary>\n
M\u00e1s de la red MBF Media<\/h3>\n
\n