Cómo comprobar dónde se almacenan tus datos antes de migrar a la nube

Saber en qué región se almacena un recurso ayuda a evaluar requisitos de residencia, latencia, redundancia y recuperación. La ubicación debe revisarse según el servicio y el recurso: en Cloud Storage, por ejemplo, el tipo de ubicación determina cómo se replica la información.

Para una migración regulada, separa tres preguntas: dónde se guardan los datos principales, dónde pueden replicarse o procesarse y qué entidades pueden acceder a ellos. La ubicación debe evaluarse por recurso y servicio, junto con las condiciones aplicables a la organización.

La ubicación también afecta decisiones técnicas. En Cloud Storage de Google, una región, una birregión y una multirregión tienen comportamientos distintos de redundancia y coste; colocar el almacenamiento cerca de la computación puede ayudar al rendimiento. Elige la ubicación según el requisito concreto, no porque el nombre geográfico parezca suficiente.

En Cloud Storage de Google, una región es un lugar geográfico específico; una birregión comprende dos regiones y una multirregión abarca una zona geográfica amplia con dos o más regiones. El tipo de ubicación determina cómo se replica y se tarifa la información. Las opciones concretas dependen del servicio.

No asumas que un código de región identifica un único edificio. En Cloud Storage, Google distingue ubicaciones regionales, birregionales y multirregionales; los objetos de una birregión se replican en las regiones que la componen, mientras que una multirregión cubre una zona geográfica más amplia. La granularidad que configura el cliente depende del servicio y no debe confundirse con la localización física de cada copia.

Tampoco todos los servicios de un mismo proyecto heredan una ubicación única. La documentación de Firebase indica que productos como Cloud Firestore y Cloud Storage requieren ubicaciones configuradas por instancia o bucket, y que algunas funciones tienen una región predeterminada si no se especifica otra. Una configuración del proyecto no prueba automáticamente dónde están todos sus recursos.

Empieza por inventariar los servicios que contendrán datos personales o confidenciales: bases de datos, buckets, discos, copias de seguridad, colas, registros y servicios de analítica. Para cada elemento, anota el identificador del recurso, el servicio, la región configurada, la cuenta o proyecto propietario y las dependencias que puedan generar copias o procesamiento adicional. La unidad de comprobación es el recurso, no solo la cuenta cloud.

En Google Cloud Storage, la ubicación forma parte de los metadatos del bucket y puede consultarse con permisos adecuados. La documentación oficial distingue región, birregión y multirregión, y especifica que la ubicación elegida influye en la replicación y el precio. En Firebase, la guía de ubicaciones describe dónde revisar la ubicación de bases de datos, buckets, backends y funciones; algunos productos, como Gemini Developer API en Firebase AI Logic, se describen como globales.

La guía de AWS DataSync indica que, para transferir datos a un bucket de Amazon S3 o desde él, se crea una ubicación de transferencia y se concede a DataSync acceso al bucket mediante un rol de IAM. Esa configuración describe el acceso necesario para la transferencia.

Azure Portal permite administrar recursos y verlos organizados por servicio y grupo de recursos. Para verificar residencia, identifica la región concreta de cada recurso y comprueba por separado las funciones que lo acompañan, como redundancia geográfica, recuperación ante desastres y servicios de monitorización. Una región de despliegue no demuestra que todo dato derivado o auxiliar tenga idéntico alcance territorial.

ISO/IEC 27001 se refiere a un sistema de gestión de seguridad de la información dentro de un alcance definido; no es un mapa de centros de datos ni una certificación universal de residencia. Antes de atribuirle valor para una migración, identifica qué entidad, servicio, región y actividades cubre el certificado, además de su vigencia y organismo emisor.

Los proveedores publican alcances que pueden variar por servicio o geografía. Por ejemplo, Esri explica que el alcance de su certificación ISO 27001 para ArcGIS ISO Cloud se aplica a servicios alojados en su ubicación regional europea y no se extiende automáticamente a APAC. También aclara que las certificaciones de AWS o Microsoft Azure sobre infraestructura subyacente no amplían por sí mismas el alcance de la certificación de Esri.

La página de cumplimiento de OVHcloud distingue los servicios incluidos y señala un perímetro específico para centros de datos de Estados Unidos. Como comprobación práctica, solicita el certificado y revisa su alcance para el servicio contratado. Una certificación respalda controles incluidos en ese alcance.

Evalúa por separado seguridad, privacidad, cumplimiento y localización. Comprueba el alcance concreto de cada certificado o informe: puede identificar la entidad, los servicios y las ubicaciones incluidos. OVHcloud, por ejemplo, indica que sus certificados e informes cubren servicios alojados en sus centros de datos, con un perímetro específico para Estados Unidos.

Para conocer la ubicación de un recurso, consulta los metadatos o la configuración de ubicación que ofrece el servicio. En Cloud Storage, la ubicación del bucket forma parte de sus metadatos y puede consultarse con los permisos adecuados.

Otro error es asumir que todos los servicios de un mismo proyecto tienen una ubicación única. Firebase distingue recursos cuya ubicación se configura por instancia, bucket o backend, y productos para los que no se puede seleccionar una ubicación, como Gemini Developer API en Firebase AI Logic. Revisa la ubicación según el producto y el recurso.

Por último, no confundas disponibilidad regional con ubicación de cada objeto. Las opciones de redundancia pueden implicar réplicas en varias regiones; eso puede ser deseable para resiliencia, pero debe encajar con las restricciones de residencia. Confirma qué modalidad está activa, cómo se comporta la recuperación y si existen restricciones para cambiar o mover la ubicación.

Antes de aprobar el traslado, convierte el requisito legal y operativo en comprobaciones que puedan demostrarse y mantenerse. Una captura de pantalla puede servir como registro puntual, pero no reemplaza una cláusula contractual ni un procedimiento de control de cambios. Conserva la configuración y su fecha de revisión en el inventario de activos.

• Identifica cada servicio y recurso que almacenará, replicará o procesará datos sensibles.
• Registra región, zona si aplica, modalidad de redundancia y ubicación de copias de seguridad.
• Comprueba en consola o metadatos la ubicación efectiva y quién tiene permisos para modificarla.
• Revisa las ubicaciones de registros, soporte, monitorización, analítica y servicios conectados.
• Solicita certificados e informes con alcance, entidad, servicio, geografía y vigencia identificables.
• Contrasta residencia y transferencias con el contrato, los términos del servicio y el análisis legal aplicable.
• Define quién revisará cambios de región, nuevas réplicas y excepciones después de la migración.

La decisión final no consiste en elegir un país a partir de una etiqueta de producto, sino en comprobar que la arquitectura satisface el requisito. Documenta las ubicaciones y modalidades de redundancia configuradas para cada recurso y evalúa cualquier componente cuya ubicación no puedas determinar frente a las necesidades de la carga de trabajo.

El resultado práctico es un expediente por carga de trabajo: recursos identificados, ubicaciones documentadas, alcance contractual y certificaciones pertinentes, junto con responsables y controles de cambio. Si no puedes demostrar la ubicación de una pieza crítica, no la trates como equivalente a las demás ni presupongas que queda cubierta por la región principal.