Infraestructura global de la nube y organización de recursos

Una región es un área geográfica en la que un proveedor ofrece servicios en la nube desde un grupo de centros de datos. Elegir una región sitúa la mayoría de los recursos, como una base de datos, en esa área. Las regiones están diseñadas para operar de forma independiente, lo que ayuda a contener los fallos regionales.

Identifica correctamente la ubicación

AWS, Microsoft Azure y Google Cloud usan nombres distintos para ubicaciones similares. Un nombre visible ayuda a las personas a reconocer un lugar; un código lo identifica en comandos y plantillas.

Un nombre por sí solo puede inducir a error. West Europe de Azure (westeurope) está en los Países Bajos; North Europe está en Irlanda. La región europe-west4 de Google Cloud está en los Países Bajos, mientras que europe-west1 está en Bélgica. Europe (Frankfurt) de AWS usa eu-central-1. Si existe un requisito relativo al país, verifica la ubicación física documentada.

Los proveedores operan varias decenas de regiones en América, Europa, Asia-Pacífico, Oriente Medio y África. Su presencia sigue creciendo. Para decidir una ubicación, un mapa de infraestructura actualizado es más útil que un número de regiones memorizado.

Distingue la ubicación del ámbito

El ámbito de un recurso describe el área a la que pertenece o a la que puede prestar servicio.

La etiqueta regional por sí sola dice poco sobre la protección frente a fallos. Puede que sea posible acceder a un recurso regional desde varias zonas mientras depende de infraestructura de una sola. Comprueba su configuración de redundancia para saber si resiste una interrupción de zona.

La ubicación también requiere comprobar el flujo de datos. Una base de datos puede ejecutarse en la región elegida mientras una función de copia de seguridad o replicación copia sus datos a otro lugar. El almacenamiento con redundancia geográfica de Azure es un ejemplo. Comprueba dónde van los datos principales, las copias de seguridad y las réplicas antes de tratar la región como un límite completo de residencia.

Comprueba qué ofrece la región

Las listas de servicios y los precios varían según la región. Confirma que estén disponibles la función de base de datos, el tamaño de máquina y las opciones de resiliencia necesarios. También puede ser necesario habilitar el acceso para una cuenta: las regiones de AWS introducidas después del 20 de marzo de 2019 están desactivadas de forma predeterminada y algunas regiones de Azure tienen acceso restringido.

Supongamos que se creó una máquina en eu-west-1, pero ahora una lista de recursos de AWS muestra us-east-1. La lista vacía no significa que se haya eliminado la máquina. Cambia a la región donde se creó y comprueba la cuenta y los filtros seleccionados. Cambiar la vista deja la máquina funcionando y los cargos siguen acumulándose.

Una zona de disponibilidad es un grupo aislado de uno o varios centros de datos dentro de una región. Su suministro eléctrico, refrigeración y redes son independientes de los de otras zonas. AWS y Azure la llaman zona de disponibilidad; Google Cloud la llama zona.

Entiende las capas físicas

Un centro de datos es un edificio que contiene servidores y equipos de apoyo. Una zona puede usar varios edificios de este tipo y una región agrupa zonas. Considerar que una zona es exactamente un edificio da una idea equivocada de los límites de fallo del proveedor.

Las zonas están lo bastante separadas para reducir la exposición compartida a un incendio local, un problema eléctrico o una inundación, pero lo bastante cerca para comunicarse rápidamente. AWS sitúa las zonas a unos 100 km o menos entre sí; Azure indica que las zonas suelen estar a menos de 100 km y busca una comunicación de ida y vuelta inferior a unos 2 ms. Las conexiones rápidas hacen viable la replicación síncrona: una escritura solo se confirma después de almacenar las copias requeridas en las distintas zonas.

Un suceso regional de gran magnitud aún puede afectar a varias zonas. Varias zonas ofrecen protección frente al fallo de una zona; una segunda región proporciona una ubicación independiente para la recuperación regional.

Interpreta los identificadores de zona

AWS añade una letra al código de región, como en eu-central-1a. Google Cloud añade un guion y una letra, como en europe-west4-a. Azure usa números de zona lógica como 1, 2 y 3.

Que los nombres coincidan entre clientes puede inducir a error. La zona 1 de Azure puede corresponder a distintas zonas físicas en diferentes suscripciones. AWS asignó los nombres de forma independiente en sus regiones más antiguas para las cuentas creadas antes de noviembre de 2025; las cuentas más recientes usan una asignación uniforme. Un identificador de zona de disponibilidad de AWS, como euc1-az1, identifica la misma zona física en todas las cuentas. Los equipos que coordinan la ubicación física comparan los identificadores AZ o las asignaciones documentadas de zonas físicas.

AWS afirma que cada región tiene al menos tres zonas. Muchas regiones de Azure tienen tres, pero algunas no tienen ninguna. Las regiones de Google Cloud tienen varias zonas. Verifica conjuntamente la región elegida y la compatibilidad del servicio con las zonas.

Elige la protección que necesitas

Azure Storage ilustra por qué el número de copias por sí solo no basta. LRS mantiene tres copias locales en un centro de datos. ZRS distribuye copias entre tres zonas. GRS añade una copia en una segunda región para la recuperación. Tres copias en un edificio siguen compartiendo los riesgos de ese edificio; distribuirlas entre tres zonas elimina esa dependencia concreta.

Los proveedores escalonan las actualizaciones entre zonas para limitar los efectos de un cambio defectuoso. Las copias también pueden generar costos de transferencia: a octubre de 2026, AWS y Google Cloud cobran por muchas transferencias entre zonas, mientras que Azure no cobra por las transferencias entre zonas de una misma región. Los precios específicos de cada servicio siguen siendo importantes al comparar un diseño completo.

Una ubicación de borde, o punto de presencia (PoP), acerca determinados servicios a los usuarios. Estas instalaciones ofrecen almacenamiento en caché y puntos de entrada a la red. No ofrecen el amplio catálogo de cómputo y bases de datos de una región. Los proveedores tienen cientos de instalaciones de borde, distribuidas más ampliamente que sus regiones.

Sigue una solicitud a través de una CDN

Una red de distribución de contenido (CDN) almacena copias reutilizables cerca de los lectores. Amazon CloudFront, Azure Front Door y Google Cloud CDN son ejemplos.

1. El enrutamiento envía la solicitud a una instalación de borde adecuada. CloudFront usa selección basada en DNS; otros servicios usan difusión a cualquiera, en la que varias instalaciones anuncian la misma dirección IP, o una combinación.
2. La instalación comprueba su caché, un almacén de contenido reutilizable.
3. Si hay un acierto de caché, devuelve una copia almacenada que puede utilizarse. Si hay un fallo de caché, obtiene el objeto del origen, el almacenamiento o servidor de referencia.
4. El contenido apto permanece en caché para solicitudes posteriores, sujeto a su tiempo de vida (TTL) y a las reglas de caché.

CloudFront también usa cachés de borde regionales más grandes entre muchas instalaciones de borde y el origen. Un objeto expulsado de una caché pequeña puede seguir disponible allí, lo que evita otro viaje al origen.

Las imágenes de un sitio de noticias se almacenan originalmente en Fráncfort. Un lector de São Paulo está a unos 9800 km en línea recta. Incluso un viaje de ida y vuelta ideal por fibra tarda unos 98 ms, y las rutas reales tardan más. Un fallo de caché sigue requiriendo obtener el contenido del origen. Los lectores posteriores pueden recibir la imagen almacenada en caché localmente en unos pocos milisegundos.

Las imágenes, los videos, los scripts, las hojas de estilo y las descargas funcionan bien porque muchas personas solicitan los mismos bytes. Un carrito de compras privado suele necesitar una respuesta nueva del origen. El borde puede ayudar con la conexión sin que todas las respuestas puedan almacenarse en caché. Las instalaciones de borde también pueden responder a consultas DNS, como con Route 53, o admitir tráfico en la red troncal de un proveedor, como con AWS Global Accelerator.

Distingue las opciones de infraestructura cercana

Azure Arc añade una conexión de administración: Azure Resource Manager puede administrar servidores y clústeres de Kubernetes fuera de Azure, incluso en instalaciones locales y en otras nubes. No convierte el edificio de un cliente en una región de Azure.

Sigue los datos almacenados en caché a través de las fronteras

Una CDN global puede almacenar contenido en varios países. Una regla que bloquea a los visitantes extranjeros controla el acceso del público; no determina dónde se encuentran las copias en caché ni dónde se procesan. El contenido sujeto a un límite estricto de país necesita una CDN que garantice las ubicaciones permitidas o una vía de distribución que evite almacenarlo en caché en el extranjero. Compruébalo por separado de la región del origen.

La alta disponibilidad significa seguir atendiendo a los usuarios cuando fallan componentes. Un punto único de fallo es cualquier dependencia cuya pérdida detiene la aplicación. Dos servidores web siguen compartiendo un punto único de fallo si ambos dependen de una sola base de datos sin protección.

Protege todo el recorrido de la solicitud

Ejecuta instancias de la aplicación en distintas zonas. Un equilibrador de carga comprueba su estado y envía las solicitudes a las instancias que funcionan correctamente. Protege también la capa de datos mediante una base de datos con redundancia entre zonas o una réplica síncrona en espera en otra zona, como en una configuración de Amazon RDS Multi-AZ.

Mantén las instancias de la aplicación sin estado cuando sea posible. Almacena la sesión de un usuario en un servicio de datos compartido y resiliente en lugar de hacerlo solo en la memoria de una instancia. Así, una instancia en buen estado de otra zona puede responder a la siguiente solicitud sin perder el carrito o la sesión del usuario.

Una sola máquina virtual permanece en la zona seleccionada. Elige varias instancias zonales o una opción de servicio que proporcione redundancia entre zonas.

Convierte el tiempo de actividad en tiempo de inactividad

Para un año de 365 días, hay 8760 horas. Convierte la disponibilidad en una fracción, réstala de uno y multiplícala por el período:

Con el 99,9 %, la fracción de indisponibilidad es 0,001, por lo que el tiempo de inactividad es de 8,76 horas al año. Con el 99,95 %, es de 4,38 horas. Con el 99,99 %, es de unos 52,6 minutos. Estas conversiones describen un porcentaje durante ese período; un acuerdo de servicio real también define cómo se mide la disponibilidad.

Como ejemplo ideal, supongamos que cualquiera de las dos zonas puede ejecutar la aplicación completa, cada una está disponible el 99,9 % del tiempo y sus fallos son independientes. La probabilidad de que ambas estén inactivas es:

La disponibilidad resultante es del 99,9999 %, unos 32 segundos de inactividad anual. Los errores de software compartido, los errores de configuración y las dependencias regionales invalidan la suposición de independencia. Este cálculo explica el beneficio de la redundancia; no es el tiempo de actividad prometido de la aplicación.

Deja suficiente capacidad disponible tras el fallo

Una tienda en línea necesita seis instancias en el pico de carga. Dos instancias en cada una de tres zonas proporcionan seis normalmente, pero solo cuatro después de que falle una zona. Para mantener seis tras la pérdida de cualquier zona, cada una de las dos zonas restantes debe proporcionar tres instancias. Implementa nueve en total.

Con dos zonas, cada una debe alojar las seis, por lo que el total pasa a ser 12. En general, para cantidades iguales de instancias entre zonas:

Aquí, $N$ es la capacidad necesaria en el pico y $z$ es el número de zonas. Redondea hacia arriba porque una instancia es una unidad entera. Para diez instancias entre cuatro zonas, diez dividido entre tres se redondea hacia arriba a cuatro por zona: 16 en total. La pérdida de una deja 12, lo que es suficiente. Este plan supone que la capacidad requerida ya está en funcionamiento; esperar nuevas instancias añade una dependencia para la recuperación.

Una segunda región permite la recuperación ante un desastre regional. También puede atender a usuarios lejanos, cumplir normas de ubicación específicas de un país o proporcionar un servicio o capacidad que no está disponible en la primera región. Cada motivo añade requisitos diferentes al diseño.

Establece dos objetivos de recuperación

El objetivo de punto de recuperación (RPO) es la pérdida máxima aceptable de datos, expresada en tiempo. El objetivo de tiempo de recuperación (RTO) es el tiempo máximo aceptable para restablecer el servicio. Una copia de seguridad puede conservar datos recientes, pero tardar demasiado en restaurarse; un reinicio rápido aún puede perder demasiados datos.

Una empresa copia su copia de seguridad nocturna a la 01:00 y pierde la región principal a las 17:00. A la copia disponible para la recuperación le faltan 16 horas de cambios. Esto incumple un RPO de una hora. Se necesitan copias de seguridad completadas con mayor frecuencia o replicación continua; una programación solo es útil cuando las copias llegan realmente a tiempo a la ubicación de recuperación.

Ajusta la preparación al tiempo de recuperación

Mantener más recursos en funcionamiento suele costar más y reduce el trabajo de recuperación. La copia de seguridad y restauración suele tardar horas o más. Activo-activo puede recuperarse en segundos o minutos, pero el diseño de la aplicación completa determina el resultado.

Entiende la diferencia entre copias

Entre regiones, la replicación suele ser asíncrona: una escritura se confirma antes de que se complete la copia remota. Fráncfort y el área de Washington D. C. están a unos 6500 km, por lo que solo el viaje ideal de ida y vuelta por fibra tarda unos 65 ms. Esperar ese viaje en cada escritura añadiría retraso.

El intervalo entre los datos actuales y la copia remota es el retraso de replicación. Puede aumentar durante cargas elevadas o problemas de red. Supervísalo en relación con el RPO. Una segunda región con una réplica antigua proporciona separación geográfica, pero no cumple el objetivo de pérdida de datos.

Usa correctamente los pares de Azure

Azure empareja muchas regiones, como North Europe con West Europe y East US con West US. El emparejamiento permite escalonar las actualizaciones de la plataforma, priorizar la recuperación y usar la replicación geográfica de algunos servicios. La mayoría de los pares permanecen en una misma zona geográfica. Brazil South es una excepción: su par es South Central US.

Un par no implementa una copia de la aplicación ni organiza todos los pasos de conmutación por error. Muchas regiones más recientes de Azure no tienen par y el cliente puede elegir otra región secundaria permitida. Comprueba el comportamiento de replicación de cada servicio.

El enrutamiento global puede dirigir a los usuarios hacia regiones en buen estado mediante Route 53, Azure Front Door o el equilibrio de carga global de Google Cloud. Incluye en el presupuesto los recursos duplicados y las transferencias entre regiones, y prueba toda la ruta de recuperación, incluidas las cuotas y los pasos manuales. Si los datos deben permanecer en un país con una sola región, usa sus zonas y opciones de recuperación local; una copia en el extranjero infringiría el requisito de ubicación.

La latencia es el retraso del viaje de los datos. El tiempo de ida y vuelta (RTT) mide el tiempo de una solicitud y su respuesta, normalmente en milisegundos. El ancho de banda mide cuántos datos transporta una conexión cada segundo. Más ancho de banda ayuda a mover un archivo grande, pero no puede eliminar el tiempo de viaje hasta una región lejana.

Estima el mínimo físico

La luz viaja por fibra a unos 200 000 km/s. Cada kilómetro añade unos 5 microsegundos en un sentido. Para estimar un RTT mínimo, duplica la distancia para los trayectos de ida y vuelta, divídela entre esa velocidad y convierte los segundos en milisegundos:

Esto da aproximadamente 1 ms por cada 100 km. Una distancia en línea recta es un límite inferior: los cables reales siguen rutas más largas y los enrutadores, las colas y el procesamiento añaden retraso.

Para los usuarios de Sídney, Singapur está a unos 6300 km. Al duplicar la distancia se obtienen 12 600 km. Al dividir entre 200 000 se obtienen 0,063 segundos, o unos 63 ms. El norte de Virginia está a unos 15 700 km, lo que da al menos unos 157 ms. Una región de Sídney puede reducir el viaje a unos pocos milisegundos.

Cuenta los viajes repetidos

Un retraso puede parecer pequeño hasta que una tarea lo repite. Supongamos que abrir una conexión y obtener una primera respuesta requiere cuatro viajes de ida y vuelta secuenciales. Con 157 ms cada uno, el tiempo de viaje es de 628 ms. Con 5 ms cada uno, es de 20 ms. El número exacto de viajes depende de la reutilización de la conexión y del comportamiento del protocolo; cuenta los viajes que realiza realmente la carga de trabajo.

El mismo efecto ocurre entre las partes de una aplicación. Una página realiza 50 consultas a una base de datos una tras otra. Si cada consulta remota añade 15 ms, la secuencia añade 750 ms. Con 1 ms dentro de la misma región, añade 50 ms. Estos son tiempos de comunicación de las consultas; el trabajo de la base de datos puede añadir más. Mantener juntos los componentes que se comunican con frecuencia evita pagar repetidamente el costo de la distancia.

Elige el cambio adecuado

Una caché de borde ayuda cuando puede responder a la solicitud. No puede hacer que una transacción de base de datos que no está en caché sea local para cada usuario. Del mismo modo, aumentar el ancho de banda no cambia la distancia hasta el origen.

Mide desde las ubicaciones reales de los usuarios

Las rutas de red siguen las conexiones disponibles, el emparejamiento de redes y las condiciones del tráfico, no la línea más corta en un mapa. Compara los RTT medidos o los tiempos de respuesta de la aplicación desde los lugares donde los usuarios se conectan realmente. Prueba horarios y solicitudes representativos antes de decidirte por una región. Una región cercana es una buena candidata; las mediciones determinan si su ruta real es adecuada para la carga de trabajo.

Una elección de región útil comienza por la carga de trabajo: quién la usa, qué servicios necesita, adónde pueden ir sus datos y cómo debe recuperarse. Comparar regiones sin estos requisitos puede dar como resultado un precio bajo para una ubicación que no puede ejecutar la aplicación.

Filtra antes de puntuar

Suelen importar seis factores: cumplimiento normativo y residencia de los datos, latencia para los usuarios, disponibilidad de servicios y funciones, precio, opciones de resiliencia y sostenibilidad. Separa los requisitos obligatorios de las preferencias. Una restricción de país o la ausencia de un servicio esencial elimina una región de la lista. Un buen precio no puede compensar el incumplimiento de ese requisito.

Para las regiones restantes, elige una escala de puntuación uniforme y pesos que sumen el 100 %. Las puntuaciones más altas siempre deben indicar una mejor adecuación, incluida una puntuación de precio mayor para un costo menor. Multiplica cada puntuación por su peso y suma los resultados.

Resuelve una decisión

Una empresa de Alemania exige almacenar los datos en la UE. Elimina una región de Estados Unidos antes de comparar dos candidatas permitidas. Las puntuaciones van de 1 a 5, y 5 es la mejor.

La empresa asigna un peso del 50 % a la latencia, del 30 % al precio y del 20 % a los servicios:

B va ligeramente por delante. Para una pantalla de operaciones bursátiles, la empresa cambia los pesos al 70 %, 20 % y 10 %:

La recomendación cambia porque cambió la prioridad de la empresa. Indica los pesos y los datos que respaldan las puntuaciones para que otra persona pueda entender la elección. Un total que parece preciso solo es tan útil como los datos utilizados para calcularlo.

Calcula el precio de la solución completa

Los precios de cómputo varían entre regiones según la energía, el suelo, la demanda y otros costos locales. Incluye en la comparación el almacenamiento, las copias de seguridad, la capacidad en una segunda región y el movimiento de datos. Las transferencias entre regiones y hacia internet suelen facturarse; la entrada de datos suele ser gratuita. Situar en distintas regiones partes de la aplicación que manejan muchos datos puede anular un pequeño ahorro en el precio de cómputo.

Para evaluar la resiliencia hay que comprobar la compatibilidad con zonas y una ubicación de recuperación permitida. Para evaluar la sostenibilidad hay que examinar la electricidad usada en la región; los proveedores publican indicadores como la proporción regional de energía libre de emisiones de carbono de Google Cloud. Una electricidad más limpia puede reducir la huella de una misma carga de trabajo.

Por último, prueba las regiones mejor puntuadas con mediciones reales de latencia y la calculadora de precios del proveedor. Registra la ubicación elegida, los requisitos obligatorios, los pesos y los motivos. Migrar recursos y datos almacenados requiere trabajo, así que revisa la elección cuando cambien las ubicaciones de los usuarios, las leyes, los servicios o la presencia regional del proveedor.

La residencia de los datos describe dónde se almacenan y procesan los datos. La localización obligatoria de los datos es un requisito legal que exige mantener determinados datos dentro de un país. La soberanía de los datos se refiere a las leyes y autoridades que pueden regir los datos, incluso a través de la empresa que los posee. El almacenamiento local y el control legal están relacionados, pero responden a preguntas distintas.

Rastrea más que la base de datos

Una base de datos en Azure germanywestcentral sitúa su almacenamiento principal en Alemania. Examina también las copias de seguridad, las réplicas, los registros, el acceso de soporte, los servicios globales de identidad y las cachés de CDN. Cualquiera de ellos puede introducir otra ubicación. EU Data Boundary de Microsoft, completado en febrero de 2025, añade compromisos de almacenamiento y procesamiento en la UE y la AELC para los servicios y datos cubiertos, con un alcance y excepciones documentados.

Una revisión eficaz pregunta tanto adónde va cada copia como qué organización puede obtener acceso. Las políticas pueden restringir las ubicaciones de los recursos; las claves de cifrado controladas por el cliente y los controles de acceso de soporte abordan otras partes del problema. Un solo control no puede responder a todas las preguntas.

Aplica el marco de transferencias del RGPD

El Reglamento General de Protección de Datos (RGPD) se aplica al tratamiento dentro de su ámbito territorial. Esto incluye los establecimientos del EEE y ciertas organizaciones en el extranjero que ofrecen bienes o servicios a personas de la UE o supervisan su comportamiento. El EEE incluye la UE, Islandia, Liechtenstein y Noruega. El RGPD permite el almacenamiento en el extranjero cuando se cumplen las condiciones aplicables; no impone una regla general de almacenamiento exclusivo en el EEE.

Para una transferencia a un destinatario distinto fuera del EEE, el capítulo V ofrece estas vías:

Japón, el Reino Unido y Suiza son ejemplos de destinos con decisión de adecuación. El Marco de Privacidad de Datos UE-EE. UU., adoptado el 10 de julio de 2023, cubre a las organizaciones estadounidenses participantes certificadas. Sustituyó la anterior vía del Escudo de Privacidad, invalidada en Schrems II el 16 de julio de 2020. El Tribunal General rechazó una impugnación del marco en septiembre de 2025; en octubre de 2026 había un recurso pendiente. Una decisión de transferencia requiere conocer la situación actual del marco y la certificación del destinatario.

Distingue el acceso del almacenamiento

Poner datos conservados en el EEE a disposición de una organización de soporte distinta fuera del EEE puede ser una transferencia aunque la base de datos permanezca localmente. El Comité Europeo de Protección de Datos distingue este caso del de un empleado del mismo responsable del tratamiento que accede a datos mientras está en el extranjero; eso no es una transferencia a otro destinatario según el capítulo V. El tratamiento sigue necesitando una protección adecuada.

La Ley CLOUD de Estados Unidos de 2018 puede exigir a los proveedores sujetos a la jurisdicción estadounidense que entreguen datos bajo su posesión, custodia o control, incluidos los almacenados en el extranjero, mediante el procedimiento legal aplicable. Por tanto, la dirección de un servidor por sí sola no puede resolver la cuestión de la soberanía.

Una clínica neerlandesa que usa un proveedor establecido en Estados Unidos elige una región de la UE, identifica los destinatarios y flujos de soporte en el extranjero, comprueba la vía aplicable del Marco de Privacidad de Datos o de las cláusulas contractuales tipo, y administra las claves de cifrado y las políticas de ubicación permitida. Documenta estas decisiones junto con sus otras obligaciones de protección de datos. Otros países y contratos añaden sus propias restricciones, especialmente para historiales médicos y registros financieros y gubernamentales.

Una nube soberana añade controles sobre los datos, las operaciones y la dependencia de sistemas globales para cumplir los requisitos de una jurisdicción. Una región normal en el país adecuado proporciona una opción de ubicación. Una oferta soberana también puede cambiar quién opera el servicio y con qué independencia puede funcionar.

Haz tres preguntas distintas

La soberanía de los datos pregunta dónde se conservan los datos y quién controla el acceso y las claves de cifrado. La soberanía operativa pregunta quién administra el servicio y presta soporte, y dónde trabajan esas personas. La soberanía técnica pregunta si el entorno puede funcionar sin los sistemas globales del proveedor. Evalúa cada dimensión frente al requisito legal, contractual o de seguridad real.

Compara entornos separados

Los entornos gubernamentales admiten programas como FedRAMP, con una cobertura específica por servicio y responsabilidades para el cliente. Los entornos de China están separados de los servicios globales y requieren las cuentas y los puntos de conexión adecuados. Las particiones independientes de la nube tienen sus propios límites de identidad y API; una sesión iniciada en la nube global no da acceso automáticamente a sus recursos.

Identifica el nivel de la oferta europea

A octubre de 2026, AWS European Sovereign Cloud está disponible, tras lanzar su primera región en Brandeburgo, Alemania, en enero de 2026. Está separada física y lógicamente de las demás regiones de AWS y sus operaciones en la UE están a cargo de residentes de la UE bajo empresas constituidas en Alemania.

Microsoft Sovereign Cloud incluye controles de Sovereign Public Cloud en regiones públicas, Sovereign Private Cloud que usa Azure Local en las instalaciones del cliente y nubes de socios nacionales como Bleu en Francia y Delos Cloud en Alemania. Estas opciones ofrecen distintas modalidades operativas.

La gama de Google Cloud incluye controles Data Boundary dentro de la nube pública, ofertas Dedicated en infraestructura separada operada por socios y entornos Air-Gapped basados en Google Distributed Cloud que funcionan desconectados de Google y de internet. S3NS en Francia y la oferta de Thales en Alemania ilustran el enfoque de socios locales. Los nombres de los productos por sí solos no determinan qué servicios, ubicaciones o compromisos de independencia incluye un contrato.

Elige suficiente control sin perder la capacidad necesaria

Una tienda puede cumplir sus requisitos con una región ordinaria de la UE, garantías de transferencia y claves administradas por el cliente. Un organismo con un requisito de acreditación nacional comprueba si una oferta concreta de un socio o una oferta soberana posee esa acreditación para los servicios necesarios. El trabajo clasificado sin conexión puede requerir un entorno aislado de redes externas.

Un aislamiento más estricto puede reducir la oferta de servicios, retrasar las funciones nuevas, aumentar el costo y dejar menos regiones de recuperación. Compara el catálogo real de servicios, los requisitos de acceso, los compromisos operativos y las ubicaciones de recuperación permitidas. La denominación soberana por sí sola no garantiza inmunidad frente a todas las leyes extranjeras.

Los proveedores sitúan los recursos de servicio implementados dentro de contenedores de administración. Estos contenedores separan los costos, el acceso y los límites de servicio. Sus nombres difieren: una cuenta de AWS, una suscripción de Azure y un proyecto de Google Cloud desempeñan funciones similares en términos generales.

Distingue un contenedor de una persona

Una persona puede acceder a varios contenedores y un contenedor puede servir a muchas personas. Compartir el acceso no coloca un recurso en un segundo contenedor. Por ejemplo, dar a un analista permiso para consultar un conjunto de datos de otro proyecto mantiene la titularidad del conjunto de datos en su proyecto original.

Una cuenta de AWS tiene un ID de cuenta de 12 dígitos. Su usuario raíz está asociado al correo electrónico con el que se creó la cuenta y tiene privilegios excepcionales. Protégelo con autenticación multifactor y resérvalo para las tareas que requieren el usuario raíz. El trabajo diario suele usar roles y otras identidades autorizadas. Un ID de cuenta identifica un límite de recursos, no a un empleado concreto.

Entiende la relación con el directorio de Azure

Un inquilino de Microsoft Entra es el directorio de identidades de una organización. Una suscripción es un límite de administración de recursos y facturación que confía en exactamente un inquilino. Un inquilino puede admitir muchas suscripciones. Una persona que inicia sesión puede tener permisos en algunas y ninguno en otras.

La expresión «cuenta de Azure» puede referirse a una identidad de inicio de sesión o a una modalidad de facturación, por lo que es demasiado imprecisa al hablar de dónde pertenece una máquina virtual. Identifica por separado la suscripción y el inquilino.

Interpreta los identificadores de proyecto de Google Cloud

Un proyecto tiene un nombre visible, un identificador de proyecto permanente y un número de proyecto asignado por el proveedor. El nombre puede cambiar y no tiene que ser único. El identificador es único en todo el mundo y no puede cambiar después de la creación. Usa de 6 a 30 letras minúsculas, dígitos o guiones, empieza por una letra y no puede terminar en guion. Por ejemplo, lumen-shop-prod es un identificador de proyecto, mientras que «Lumen Shop Production» puede ser su nombre visible.

Los proyectos organizan los servicios implementados, mientras que los recursos de organización y carpeta organizan los proyectos por encima de ellos. La facturación se vincula por separado, por lo que varios proyectos pueden compartir una cuenta de facturación sin convertirse en un solo proyecto.

Divide el trabajo en límites útiles

Una empresa separa su tienda en desarrollo, pruebas y producción. Usa tres cuentas de AWS, tres suscripciones de Azure o tres proyectos de Google Cloud. Cada entorno obtiene un ámbito de permisos y una vista de costos distintos. La separación limita los daños que puede causar un error de desarrollo cuando los permisos se configuran en consecuencia.

Los contenedores también tienen cuotas, como límites regionales de CPU virtuales. Los contenedores nuevos pueden comenzar con cuotas bajas y muchos límites pueden aumentarse previa solicitud. Un entorno de recuperación necesita suficiente cuota antes de que ocurra un fallo; una plantilla funcional por sí sola no reserva capacidad ni aumenta esos límites.

Los equipos suelen dividir los contenedores por entorno, departamento o producto para que los costos y el acceso sean comprensibles. La ubicación geográfica es una elección independiente: un contenedor puede contener recursos en varias regiones.

Los recursos que se crean, cambian y eliminan juntos comparten un ciclo de vida. Los grupos de recursos de Azure convierten ese ciclo de vida en un límite de administración. Las etiquetas añaden descripciones que se pueden buscar entre recursos sin cambiar su ubicación física.

Usa grupos de recursos de Azure

Para los recursos ordinarios de servicios de Azure implementados, un grupo de recursos se encuentra dentro de una suscripción. Cada uno de esos recursos pertenece a un grupo; los grupos no pueden contener otros grupos. Los recursos de nivel de suscripción y los objetos de administración existen en ámbitos superiores, por lo que la jerarquía también tiene objetos fuera de los grupos de recursos.

Un grupo tiene una ubicación para sus metadatos, los registros que describen el grupo y sus recursos. Esa ubicación no obliga a que todos sus miembros estén en la misma región. Un servidor web en una región y su recurso de recuperación en otra pueden compartir un grupo.

Eliminar un grupo de recursos elimina su contenido. Esto es práctico para el trabajo temporal y peligroso cuando se incluyen recursos de producción no relacionados. Un bloqueo de eliminación puede impedir la eliminación accidental hasta que una persona autorizada lo quite. Elige un grupo cuyos miembros puedan compartir de forma segura las decisiones de creación, acceso y retirada.

Por ejemplo, este comando de la CLI de Azure crea un grupo para la tienda de producción:

az group create --name rg-shop-prod-weu --location westeurope

Un grupo independiente rg-shop-test contiene un entorno de pruebas que puede eliminarse. Al eliminar ese grupo de pruebas se elimina todo su contenido. El grupo de producción permanece separado. El patrón del nombre identifica el tipo de recurso, la aplicación, el entorno y la ubicación, lo que facilita la revisión de las listas.

El acceso asignado a un grupo, como Reader, se aplica a sus recursos. Muchos tipos de recursos pueden moverse entre grupos o suscripciones, sujetos a las restricciones del servicio. Ese traslado cambia su ubicación administrativa; no migra un recurso a otra región.

Compara la agrupación de AWS

AWS Resource Groups puede reunir recursos mediante etiquetas coincidentes o una pila de recursos de CloudFormation. Un recurso puede aparecer en varios de esos grupos. Eliminar un AWS Resource Group elimina la agrupación, pero conserva sus recursos. Esto difiere del contenedor de ciclo de vida obligatorio de Azure para los recursos ordinarios implementados. En Google Cloud, los proyectos proporcionan el principal límite de agrupación de recursos de servicio.

Añade etiquetas útiles

Las etiquetas de AWS y Azure y las etiquetas de Google Cloud adjuntan descripciones de clave y valor. Algunos ejemplos son environment=prod, cost-center=4120 y owner=web-team. Ayudan a filtrar inventarios e informes de costos o a seleccionar recursos para la automatización.

Usa claves y valores acordados. Si un equipo escribe «prod» y otro escribe «Prod», un informe puede separar recursos que pertenecen al mismo grupo. Las etiquetas del grupo de recursos de Azure no se transmiten de forma predeterminada a los recursos miembros; una política o automatización puede aplicar los valores previstos.

Una etiqueta es un metadato descriptivo. Una etiqueta que diga «privado» no aísla el tráfico de red y llamar «Europe» a un grupo no mueve allí sus recursos. Las reglas de acceso, las redes y la configuración de región proporcionan esos controles.

Una jerarquía de administración organiza contenedores en un árbol. Los ámbitos superiores permiten a una organización administrar conjuntamente muchas cuentas, suscripciones o proyectos. La herencia significa que las configuraciones aplicables de un elemento superior se transmiten a sus descendientes.

Compara los árboles de los proveedores

Azure da a cada inquilino un grupo de administración raíz, llamado «Tenant root group» de forma predeterminada. Los grupos de administración pueden anidarse seis niveles de profundidad, sin contar la raíz ni el nivel de suscripción. Cada grupo de administración o suscripción tiene un elemento superior.

AWS Organizations tiene una cuenta de administración que crea la organización y paga las facturas consolidadas. Las unidades organizativas (OU) agrupan cuentas y pueden anidarse cinco niveles por debajo de la raíz. Una cuenta pertenece a una organización a la vez. La cuenta de administración tiene una función distinta y no está controlada por las políticas de control de servicios de la organización.

La organización de Google Cloud está asociada al dominio de la empresa. Las carpetas requieren una organización y pueden contener carpetas anidadas. Una persona que aprende usando una prueba gratuita puede tener un proyecto sin organización.

Sigue una regla heredada

Una empresa separa Retail y Logistics, cada uno con producción y desarrollo. Azure usa grupos de administración departamentales con suscripciones debajo. AWS usa OU departamentales con cuentas debajo. Google Cloud usa carpetas departamentales con proyectos debajo.

Si una política de grupo de administración de Azure permite implementaciones solo en regiones de la UE, las suscripciones inferiores heredan esa restricción. El nombre del grupo es solo una etiqueta; la política hace cumplir la regla de ubicación. En AWS, una política de control de servicios (SCP) de una OU puede establecer un límite máximo de permisos para las cuentas miembro. Una SCP no concede por sí misma permiso a un usuario para trabajar en esas cuentas.

Entiende el acceso heredado

En el control de acceso basado en roles de Azure y en las políticas de autorización de IAM de Google Cloud, las concesiones se suman entre ámbitos. Una concesión de solo lectura en un elemento inferior no cancela el acceso de escritura heredado de un elemento superior. Para eliminar ese acceso amplio, cambia el ámbito que lo concede o usa un control de denegación adecuado.

Azure Policy puede rechazar configuraciones de recursos que no cumplen las normas, como una ubicación prohibida. Es independiente de las asignaciones de roles que conceden acceso. Las políticas de denegación de Google Cloud pueden bloquear permisos concretos. Las políticas de AWS Organizations también son distintas de las concesiones de acceso a cuentas; IAM Identity Center puede asignar conjuntos de permisos a varias cuentas.

Un equipo de auditoría al que se concede acceso de lectura adecuado en la parte superior de una jerarquía de Azure o Google Cloud puede leer los recursos de los departamentos inferiores. La pertenencia a una OU de AWS por sí sola no da a ese equipo acceso a las cuentas.

Mantén el árbol separado del mapa

Mover una suscripción o un proyecto cambia sus políticas y accesos heredados. Los recursos permanecen en sus regiones actuales. Revisa las reglas efectivas de la nueva rama antes de un traslado: una reorganización lógica puede afectar a los permisos de muchas personas sin mover un solo servidor.

Un botón en el navegador, un comando y un programa pueden solicitar la misma operación en la nube. Cada uno envía una solicitud autenticada a una interfaz de programación de aplicaciones (API). La interfaz cambia cómo trabaja una persona o aplicación; los permisos y los límites de servicio siguen aplicándose.

Relaciona la interfaz con la tarea

Las herramientas gráficas son AWS Management Console, Azure portal y Google Cloud console. Los principales programas de CLI son aws, az y gcloud. Azure PowerShell y AWS Tools for PowerShell proporcionan otro estilo de comandos. Las aplicaciones móviles son útiles para comprobar el estado y las alertas.

Por ejemplo, aws ec2 describe-instances --region eu-central-1 enumera las instancias de EC2 en Fráncfort. az group list enumera los grupos de recursos de Azure y gcloud compute zones list enumera las zonas de Google Cloud. Son clientes de API, no inventarios separados de recursos.

AWS CloudShell, Azure Cloud Shell y Google Cloud Shell proporcionan la CLI correspondiente en un navegador. Reducen el trabajo de instalación y usan el contexto de la nube de la sesión iniciada. Aun así, debes comprobar a qué cuenta, suscripción o proyecto se dirige la sesión.

Sigue la ruta de API correcta

En Azure, las operaciones del plano de control crean, cambian o eliminan recursos mediante Azure Resource Manager. Este aplica la autorización y las políticas a las solicitudes de administración de recursos. Las operaciones del plano de datos usan el punto de conexión propio del servicio, por ejemplo, al cargar un archivo en una cuenta de almacenamiento existente. Un programa puede realizar ambos tipos de operaciones mediante distintos clientes.

Los SDK admiten lenguajes como Python, JavaScript, Java, C# y Go. Ayudan con la firma de solicitudes, las llamadas a servicios y los reintentos tras fallos temporales. Una aplicación web usa un SDK cuando cada carga de un usuario debe desencadenar una operación de almacenamiento; no necesita que una persona maneje la consola.

Comprueba el contexto de destino

Los valores predeterminados pueden elegir el destino equivocado sin avisar. La configuración de AWS puede establecer una región predeterminada. La configuración de Google Cloud puede seleccionar un proyecto y una región de cómputo, por ejemplo, con gcloud config set project lumen-shop-prod y gcloud config set compute/region europe-west4.

Azure usa una suscripción seleccionada, mientras que los comandos de creación de recursos usan sus parámetros de ubicación documentados o valores predeterminados. La ubicación de los metadatos de un grupo de recursos no selecciona de forma universal la ubicación de cada recurso. Comprueba el destino del comando antes de ejecutarlo.

Usa credenciales de corta duración, como roles o sesiones iniciadas, cuando estén disponibles. Mantén las claves de acceso fuera del código fuente y de los documentos compartidos. Cambiar de la consola a una CLI no elude los controles de acceso: una operación de API denegada sigue denegada independientemente del cliente que la envíe.

Crear a mano un recurso temporal puede ser práctico. Reconstruir el mismo entorno para pruebas, producción y recuperación necesita un proceso que evite pequeñas diferencias entre clics repetidos. La infraestructura como código (IaC) guarda la descripción de los recursos en archivos de texto y usa una herramienta de implementación para crear o actualizar el entorno.

Describe un estado o una secuencia

Una plantilla declarativa indica qué debe existir, como dos máquinas virtuales con un tamaño y una ubicación elegidos. La herramienta de implementación compara ese estado deseado con el entorno actual y determina los cambios. Un script imperativo enumera las acciones en orden, como «crea el grupo y después crea las máquinas».

Una pila agrupa los recursos administrados por una implementación de CloudFormation. Los valores de los parámetros permiten a un equipo reutilizar una plantilla para distintas ubicaciones o tamaños sin mantener varios archivos copiados.

Reutiliza un entorno probado

Un equipo tiene una plantilla de tienda web probada en Fráncfort, eu-central-1. Para preparar su infraestructura de recuperación en Irlanda, proporciona eu-west-1 como parámetro de región. Para las pruebas, proporciona un tamaño de máquina menor. El control de versiones registra la plantilla y sus cambios revisados, lo que hace visible para el equipo la configuración prevista.

Reutilizar el código de infraestructura no copia los datos activos de la aplicación. Las copias de seguridad o la replicación siguen proporcionando esos datos, y la región de recuperación elegida sigue necesitando los servicios, permisos y cuotas requeridos y cumplir los requisitos legales. Las plantillas hacen repetible la construcción de infraestructura uniforme; el plan de recuperación completo incluye estas otras dependencias.

Aplica los cambios de forma uniforme

Una operación idempotente puede repetirse sin añadir otro cambio después de alcanzar el resultado previsto. Si la configuración, las entradas y los recursos no cambian, una implementación declarativa que ha alcanzado el estado deseado no debería producir más cambios en la infraestructura. Un script compuesto solo por comandos de creación puede fallar o crear duplicados al volver a ejecutarse.

La desviación de la configuración es una discrepancia entre la configuración declarada y los recursos activos. Alguien podría aumentar el tamaño de una máquina en la consola sin actualizar su plantilla. La detección de desviaciones de CloudFormation o un terraform plan pueden ayudar a identificar esas diferencias. Un plan de Terraform muestra los cambios propuestos; revísalos antes de aplicarlos.

IaC permite revisar los cambios, conserva su historial y ayuda a reconstruir entornos perdidos. También requiere mantener los archivos y entender la herramienta. Usa la interfaz manual para una exploración puntual y después incorpora al código los cambios estables y repetidos del entorno para que la descripción revisada siga siendo precisa.