24 abril 2026

7 Min. lectura · Fecha: 23.04.2026

Google Cloud ha lanzado Cloud Location Finder como servicio Pre-GA (Pre-General Availability). El nuevo servicio proporciona un inventario normalizado de regiones y zonas a través de Google Cloud, AWS, Microsoft Azure e Oracle Cloud Infrastructure. Para los arquitectos cloud en DACH (Alemania, Austria y Suiza), esto es más que un complemento multi-cloud: por primera vez, los datos de residencia, latencia y huella de carbono pueden consultarse mediante API a través de cuatro hyperscalers, sin necesidad de mantener una tabla de mapeo separada para cada proveedor. Quienes quieran cumplir con las normativas de límites de datos de la UE o realizar verificaciones de soberanía, obtienen una herramienta que ahorra semanas de investigación manual.

Lo más importante en resumen

  • Google Cloud ha publicado Cloud Location Finder como servicio pre-GA (pre-disponibilidad general), con inventario sobre GCP, AWS, Azure y OCI.
  • Acceso mediante REST-API y gcloud-CLI, actualmente sin costes de licencia adicionales.
  • Los datos incluyen metadatos de región y zona, Proximity, Territory-Code y huella de carbono por ubicación.
  • Casos de uso prácticos: selección de región multi-nube, auditorías de residencia de datos, optimización de latencia y verificaciones de cumplimiento.
  • El estado pre-GA significa: utilizable en producción, pero sin garantías de soporte estándar. Las decisiones de arquitectura deberían documentar este estado.

Lo que Google Cloud ha implementado recientemente

¿Qué es Google Cloud Location Finder? Cloud Location Finder es un nuevo servicio de Google Cloud que proporciona datos de ubicación de regiones y zonas en la nube a través de múltiples hyperscalers en un formato unificado. Cubre Google Cloud Platform, Amazon Web Services, Microsoft Azure e Oracle Cloud Infrastructure. El servicio está disponible a través de REST-API y gcloud-CLI, es gratuito y proporciona metadatos para cada región como ubicación geográfica, código de territorio, proximidad a otras ubicaciones e indicadores de huella de carbono.

El blog de Google Cloud describe el servicio como respuesta a una pregunta arquitectónica cotidiana: ¿Qué región de otro hyperscaler está más cerca de mi infraestructura en la nube existente? Antes de Cloud Location Finder, los arquitectos tenían que recopilar manualmente la respuesta de la documentación respectiva de cada proveedor, a menudo con diferentes convenciones de nomenclatura de regiones. Con el nuevo servicio, la consulta se realiza de forma unificada a través de una API, lo que acelera los scripts de arquitectura y las auditorías de cumplimiento.

Importante para su contextualización: el servicio se encuentra actualmente en la fase pre-GA (pre-lanzamiento general). Esto significa que el acceso productivo es posible, pero las garantías de soporte estándar aún no se aplican en su totalidad. Quienes utilicen el servicio en flujos de trabajo cercanos a producción, deberían documentar el estado pre-GA en la documentación de arquitectura interna y señalarlo en el régimen contractual. Una migración al estado GA típica seguirá en los próximos trimestres, con compromisos de SLA más vinculantes.

4 Hyperscaler
GCP, AWS, Azure, OCI en el inventario unificado

REST + CLI
Acceso vía REST-API y gcloud-CLI

0 USD
actualmente sin costos de licencia adicionales

Tres casos de uso para arquitectos cloud DACH

Tres clases de casos de uso justifican el esfuerzo de integrar Cloud Location Finder en la propia rutina de arquitectura. La primera clase se refiere a la selección de regiones multi-cloud. Quienes despliegan una carga de trabajo en AWS en Fráncfort y buscan simultáneamente una región de GCP para failover o replicación de datos, obtienen con Cloud Location Finder las regiones de GCP más cercanas junto con un indicador de proximidad. Anteriormente, esta información estaba profundamente enterrada en múltiples documentaciones de proveedores.

La segunda clase se refiere a las auditorías de residencia de datos. Quienes trabajan en sectores regulados con requisitos DORA (Digital Operational Resilience Act), NIS2 (Network and Information Systems Directive) o específicos de la industria, deben poder demostrar que ciertos datos se procesan exclusivamente en regiones de la UE. Cloud Location Finder proporciona por proveedor una lista procesable por máquina con códigos de territorio, lo que acelera tanto las auditorías iniciales como los controles de cumplimiento continuos. Equipos de FinOps utilizan los mismos datos para los cálculos de Cost-of-Compliance.

La tercera clase se refiere a la optimización de la huella de carbono. Los informes ESG (Environmental, Social, and Governance) exigen cada vez que las cargas de trabajo de TI se clasifiquen según la eficiencia energética y el perfil de CO2. Cloud Location Finder proporciona indicadores de huella de carbono por región, lo que facilita significativamente la selección para cargas de trabajo sensibles al clima. Para empresas medianas que elaboran informes ESG o tienen obligaciones CSRD (Corporate Sustainability Reporting Directive), esto es una base de datos bienvenida. Quienes incorporan estos valores en sus decisiones de arquitectura tendrán datos concretos para la próxima reunión con el consejo de administración.

Lo que Cloud Location Finder ofrece

  • Unificada datos de regiones y zonas en cuatro hyperscalers
  • Acceso basado en API para scripts de arquitectura y cumplimiento
  • Indicadores de huella de carbono para selección relevante ESG
  • Datos de proximidad para optimización de latencia en configuración multi-cloud

Lo que Cloud Location Finder no ofrece

  • Medición en tiempo real de latencia entre regiones
  • Certificación de cumplimiento vinculante por proveedor
  • Soporte estándar con SLA estrictos, mientras esté en estado Pre-GA
  • Cobertura completa de proveedores regionales más pequeños como Hetzner, OVHcloud, IBM Cloud

Cómo los arquitectos cloud pueden implementar el servicio en 30 días

Cuatro semanas son suficientes para integrar Cloud Location Finder en la rutina de arquitectura propia. La siguiente lógica de pasos ha demostrado su eficacia en varios equipos cloud de la región DACH (Alemania, Austria y Suiza).

Días 1-3
Exploración de API. Probar Cloud Location Finder mediante gcloud-CLI, testar los endpoints REST y realizar las primeras extracciones de datos para las regiones cloud propias más importantes.

Días 4-7
Selección de casos de uso. ¿Qué dos o tres preguntas de arquitectura queremos responder con este servicio? ¿Mapeo de failover multi-cloud? ¿Auditoría de residencia de datos? ¿Reportes ESG?

Días 8-14
Integración de scripts. Integrar Cloud Location Finder en pipelines existentes de Infrastructure-as-Code, reportes de FinOps o dashboards de cumplimiento. Presentar la primera evaluación a la dirección de arquitectura.

Días 15-21
Aclaración contractual. Coordinar con el departamento legal propio el estado Pre-GA (pre-general availability). Si se planea un uso productivo, documentar la evaluación de riesgos.

Días 22-30
Rutina de reporting. Ejecución de evaluaciones semanales o mensuales. Incorporar el spreadsheet de resultados en el propio reporting de gobierno cloud e informar a los responsables de arquitectura.

Lo que el movimiento muestra más allá del servicio

Cloud Location Finder es parte de un movimiento más amplio. AWS lanzó en abril de 2026 AWS Interconnect Multicloud GA, con Google Cloud como primer socio de lanzamiento y conexión con Azure en los próximos meses. Microsoft Azure está desarrollando sus propias herramientas de plataforma multi-nube. En 2026, los hyperscalers reconocen que la multi-nube ya no es una excepción, sino una realidad. Quienes ofrecen herramientas que simplifican las arquitecturas multi-nube, obtienen una posición estratégica en el stack de arquitectura de los clientes.

Para los equipos de nube de DACH (Alemania, Austria y Suiza), este es un mensaje pragmático. La época de las discusiones sobre multi-nube de tipo «o esto o aquello» ha terminado en 2026. Se trata de herramientas concretas que funcionan en la práctica arquitectónica y se integran con los requisitos de cumplimiento propios. Cloud Location Finder es una primera herramienta de este tipo, que se puede utilizar activamente y no genera costos de licencia adicionales. La barrera de entrada es baja.

Stratégicamente, merece la pena una segunda observación. Los hyperscalers están construyendo la simplificación multi-nube ellos mismos, en lugar de dejarla en manos de terceros. Esto cambia la posición de herramientas multi-nube especializadas como HashiCorp Terraform, Pulumi y Crossplane. Estas siguen siendo relevantes para el aprovisionamiento de infraestructura, pero la capa de datos para temas de ubicación y cumplimiento se desplaza hacia los propios hyperscalers. Quien tome decisiones de arquitectura en los próximos 18 meses, debería tener este cambio en mente.

Una última observación sobre el modelo de negocio: Cloud Location Finder es actualmente gratuito. Esto probablemente no cambiará en la fase pre-GA. Con la transición a GA y la adopción creciente, es posible que surja una discusión sobre precios. Los equipos de FinOps deberían incluir el servicio en sus revisiones trimestrales y comunicar los cambios de precios con antelación. Quien integre críticamente el servicio en su propia pipeline, debería tener un plan B si las barreras cambian. Las experiencias con la dispersión de SaaS muestran que las herramientas gratuitas rara vez permanecen gratuitas a lo largo de su ciclo de vida. Una estrategia contractual consciente protege contra sorpresas futuras.

Preguntas frecuentes

¿Cuándo alcanzará Cloud Location Finder el estado GA?

Google Cloud no ha comunicado una fecha definitiva para el estado GA. Experiencias con otros servicios de GCP permiten esperar 2026 o principios de 2027. Quienes utilicen el servicio en producción deberán observar activamente el anuncio de GA y ajustar las condiciones contractuales en consecuencia.

¿Qué datos específicos proporciona el servicio por región?

ID de región, IDs de zona, ubicación geográfica, código de territorio, valores de proximidad a otras regiones e indicadores de huella de carbono. La profundidad de los datos varía ligeramente según el hyperscaler, pero el esquema uniforme se aplica a los cuatro proveedores cubiertos.

¿Cómo se relaciona el servicio con HashiCorp Terraform y Pulumi?

Cloud Location Finder es un servicio de datos, no una herramienta de aprovisionamiento. Terraform y Pulumi siguen siendo relevantes para la implementación de infraestructura. Cloud Location Finder puede integrarse como fuente de datos en módulos de Terraform, por ejemplo, para la selección dinámica de regiones en configuraciones multi-nube.

¿Es adecuado el servicio para auditorías de cumplimiento en DACH?

Como base de datos sí, como certificación de cumplimiento vinculante no. Quienes necesiten demostrar en el contexto de NIS2 o DORA que los datos se procesan en regiones de la UE pueden utilizar Cloud Location Finder como fuente de datos. La certificación legal sigue correspondiendo al hyperscaler respectivo.

¿Qué riesgos pre-GA son operativamente relevantes?

Compromisos de SLA limitados, posibles cambios disruptivos en las actualizaciones de API y sin contratos de soporte completos. Quienes utilicen Cloud Location Finder en pipelines de producción deberían tener un plan alternativo y observar activamente las actualizaciones.

¿Qué tan actualizados están los datos de región?

Según la documentación, Google Cloud actualiza regularmente el inventario sin especificar un intervalo de actualización fijo. Las nuevas regiones suelen aparecer pocas semanas después del anuncio oficial del proveedor. Quienes necesiten datos muy actualizados también deberán consultar las páginas de estado respectivas de los proveedores.

Fuente imagen de portada: Pexels / Pixabay (px:269790)

También disponible en

Una revista de Evernine Media GmbH