Conferencia de 5 minutos

El 24 de abril, Google Cloud anunció el Cross‑Cloud Caching como una nueva función durante el resumen del Cloud Next 2026. La idea es que los datos de AWS y Azure se repliquen en Google Cloud Storage desde la primera lectura, para luego estar disponibles localmente para las solicitudes posteriores. Esto elimina los costos de e‑gress para las segundas, terceras y siguientes solicitudes. Para los arquitectos multi‑cloud DACH, este es un argumento de costo muy sólido en el papel. En la práctica, sin embargo, plantea una cuestión que rara vez recibe tanta atención directa: ¿qué nivel de soberanía sobre los datos justifica los costos de e‑gress?

Puntos clave en resumen

• Lo nuevo: el Cross‑Cloud Caching de Google Cloud carga los datos de AWS S3 y Azure Blob hacia el almacenamiento GCP desde la primera lectura y los almacena en caché para las solicitudes posteriores.
• Por qué es relevante ahora: el e‑gress desde AWS y Azure sigue siendo la parte más costosa de los entornos multi‑cloud. Cualquier lectura recurrente desde otros clouds genera un pago cada vez.
• Lo que aún debe aclararse: los datos permanecen físicamente en el almacenamiento GCP. Los equipos DACH que están sujetos a requisitos de soberanía de datos deben examinar esta cuestión antes de que la función se despliegue por completo.

El anuncio se realizó durante el resumen del Cloud Next 2026 el 24 de abril (cloud.google.com). El Cross‑Cloud Caching forma parte de la estrategia de Google para responder a la realidad multi‑cloud que muchas empresas DACH han estado viviendo durante años, pero que rara vez gestionan de manera elegante. Ya habíamos presentado el gran bloque de ruta: Lo que los arquitectos DACH esperan de la hoja de ruta del Cloud Next 2026. El Cross‑Cloud Caching constituye el mecanismo práctico de esta iniciativa.

Funcionamiento de la función

El principio es el caching, como los desarrolladores front‑end lo conocen en el contexto de los CDN, pero con una capa más profunda y más allá de las fronteras cloud. Un job en BigQuery o Vertex AI lee un conjunto de datos desde AWS S3. Durante la primera lectura, el tráfico pasa por el flujo habitual y genera costos de e‑gress. El Cross‑Cloud Caching copia el objeto en paralelo hacia Google Cloud Storage. Las solicitudes posteriores sobre el mismo conjunto de datos leen desde el cache local. Desde el punto de vista de AWS, no se activa ninguna actividad adicional después de la primera lectura.

Técnicamente, se trata de una combinación de replicación de almacenamiento y de routing inteligente: búsqueda en el cache antes de la lectura cross‑cloud, invalidación basada en el TTL y una capa de control que decide qué datos merecen ser almacenados en caché. Cualquiera que haya trabajado con caches de borde y con el principio «stale‑while‑revalidate» reconocerá el esquema. Lo novedoso radica en que Google ofrece esto a nivel de almacenamiento y lo integra en sus propios servicios de análisis.

Por qué los equipos de la región DACH lo vigilan de cerca

El egress ha sido durante mucho tiempo la línea más temida en las facturas de nube. AWS y Azure cobran aproximadamente entre 8 y 9 céntimos por GB cuando los datos salen de sus plataformas, según sus páginas de tarifas (AWS Data Transfer Pricing, Azure Bandwidth Pricing, a fecha de abril de 2026). Para cargas de trabajo que transfieren con frecuencia varios terabytes de datos desde nubes de terceros, estos costos pueden justificar rápidamente una revisión arquitectónica. El Cross‑Cloud Caching aborda directamente este problema.

Para los arquitectos de la región DACH, esto reviste especial importancia, pues muchas configuraciones de producción siguen este esquema de lectura: los datos históricos se almacenan en AWS o Azure, mientras que el equipo de analítica trabaja en BigQuery. Sin caché, el mismo conjunto de datos se recupera desde AWS cada mes. Con la caché, el tráfico se extrae una sola vez y luego permanece local. Cuando la línea de costos se estabiliza, la factura disminuye rápidamente. La semana pasada exploramos un principio similar en CloudFormation vs Terraform para la verificación práctica del Multi‑Cloud: las elecciones de herramientas suelen depender precisamente de estas gastos operativos recurrentes.

“El concepto: los datos de AWS y Azure se replican en Google Cloud Storage durante la primera lectura y permanecen locales para todas las solicitudes posteriores.”

Lo que falla, lo que funciona

El verdadero debate no es si debe utilizar la funcionalidad, sino dónde aplicarla y bajo qué restricciones. Los datos personales según el RGPD, las clases de datos reguladas procedentes de entornos de infraestructuras críticas o los conjuntos de datos con restricciones geográficas explícitas no son aptos para la caché. Los flujos de telemetría, los clickstreams o los conjuntos de datos de entrenamiento carentes de datos personales constituyen candidatos mucho mejores. Documente esta decisión en sus guías de arquitectura, no solo durante la revisión anual de FinOps.

Lo que los arquitectos de Europa Central deben abordar en los próximos 90 días

Comience con un informe claro de egress procedente de AWS y Azure, desglosado por conjunto de datos y nube de destino. Sin esta línea base, no podrá cuantificar los ahorros. A continuación, clasifique los conjuntos de datos según su viabilidad para el almacenamiento en caché y obtenga una validación de cumplimiento segura. Por último, lance un piloto sobre un único conjunto de datos con mucha lectura, idealmente telemetría o datos de entrenamiento. Esto le proporcionará una métrica concreta en lugar de depender de las estimaciones del proveedor.

Desde un punto de vista estratégico, la compensación del bloqueo merece un taller abierto: la caché multinube reduce los costes de egress pero introduce una nueva dependencia de la capa de almacenamiento de Google. Si su estrategia de salida multinube sigue vigente, integre esta funcionalidad en el plan antes de que se convierta discretamente en una realidad en producción.

Preguntas frecuentes

¿Cuál es el coste del Cross‑Cloud Caching?

Google Cloud no ha publicado tarifas unitarias para el servicio. Se prevé que los costes de almacenamiento en caché se combinen con tasas de salida (egress) reducidas. Solo serán posibles estimaciones fiables una vez que esté disponible la tabla de precios oficial.

¿Quién es el público objetivo?

Organizaciones que gestionan entornos multicloud con pipelines de lectura productivos entre AWS o Azure y Google Cloud Analytics, especialmente usuarios de BigQuery y Vertex AI que extraen datos con frecuencia desde nubes de terceros.

¿Cuáles son las implicaciones para la soberanía de los datos?

Los datos se replican físicamente en Google Cloud Storage. Los equipos sujetos a restricciones geográficas o estrictos requisitos normativos deben verificar la región de GCP que aloja la caché y garantizar el cumplimiento antes de activar la función.

Foto: Lovelano / Wikimedia Commons (CC BY 4.0)