Repatriar cargas de la nube: cuándo conviene y cuándo no

La repatriación de cargas, es decir, sacar aplicaciones o datos de la nube pública para llevarlos a un centro de datos propio o a un proveedor de colocation, se discute cada vez más. A veces la conversación arranca por una factura que creció más rápido que el negocio; otras, por una exigencia de soberanía de datos o por un cambio de estrategia. En casi todos los casos se plantea como una posición: "la nube es más cara" o "volver atrás es un error".

Las dos afirmaciones son demasiado generales para servir. La nube y la infraestructura propia tienen economías distintas, y cada carga encaja mejor en una u otra según su comportamiento y su arquitectura. Este artículo propone un criterio para decidirlo carga por carga, sin dogma en ninguna dirección.

Por qué la pregunta aparece ahora

Hay tres motivos que conviene separar. El primero es la madurez financiera: muchas organizaciones que migraron rápido ahora tienen datos de consumo de varios años y pueden comparar con números reales, no con estimaciones. Prácticas como las del FinOps Framework de la FinOps Foundation ayudan a que ese análisis sea sistemático en lugar de reactivo.

El segundo es el costo de salir. Mover datos fuera de un proveedor tiene un precio, y ese cargo ha sido históricamente una barrera para cambiar. Eso está cambiando por regulación y por decisión de los propios proveedores, como veremos más abajo.

El tercero es la soberanía. Sectores como banca, seguros y salud, en Latinoamérica y en España, enfrentan exigencias sobre dónde se almacenan y procesan ciertos datos, y quién puede acceder a ellos. A veces la región de nube adecuada existe; a veces no.

Ninguno de los tres motivos implica por sí solo que haya que repatriar. Implican que la decisión merece un análisis explícito.

Dos ejes para clasificar cada carga

Para un primer filtro, recomendamos ubicar cada carga en una matriz con dos ejes.

• Predecibilidad de la demanda. Una carga estable, con consumo parecido mes a mes y crecimiento previsible, aprovecha poco la elasticidad de la nube. Una carga con picos estacionales, campañas o crecimiento incierto la aprovecha mucho.
• Dependencia de servicios gestionados. Una carga que corre en máquinas virtuales o contenedores con componentes estándar se puede mover con relativa facilidad. Una que usa bases de datos gestionadas propietarias, colas, funciones sin servidor, servicios de analítica o de IA del proveedor tendría que reconstruir esas capacidades fuera.

La matriz no decide; ordena. Una carga en el cuadrante "candidata a repatriar" puede seguir conviniendo en la nube por motivos de resiliencia, de talento o de velocidad de cambio. Y una carga en "quedarse en la nube" puede tener que salir por una exigencia de soberanía. Lo que sí hace es evitar dos errores frecuentes: repatriar una carga elástica que necesitará sobredimensionar el hardware para sus picos, y repatriar una carga que depende de servicios gestionados que habría que reemplazar uno por uno.

El costo total, no solo el cómputo

El argumento más habitual a favor de repatriar compara la factura mensual de cómputo con el precio del hardware equivalente. Esa comparación casi siempre deja fuera la mitad de los costos de cada lado. La tabla siguiente resume los factores que conviene incluir.

Factor	En la nube	En infraestructura propia
Cómputo y almacenamiento	Pago por uso; descuentos por compromiso de uso	Amortización del hardware, dimensionado para el pico y no para el promedio
Transferencia de datos	Salida a internet y entre regiones con cargo; entrada en general sin cargo	Contratos de conectividad y tránsito; costo único de la migración
Licencias	Incluidas en algunos servicios gestionados	Licencias propias y soporte; reglas de licenciamiento por núcleo o por host
Personal	Equipo de plataforma y de FinOps	Operación de hardware, red y almacenamiento, guardias, contratación y retención
Centro de datos	Incluido en el precio	Espacio, energía, refrigeración y seguridad física, o contrato de colocation
Ciclo de renovación	Lo asume el proveedor	Renovación de servidores, almacenamiento y red cada pocos años
Capacidades gestionadas	Copias de seguridad, monitoreo y alta disponibilidad disponibles como servicio	Reemplazarlas con herramientas y procesos propios

Un ejemplo ilustrativo. Supón una carga que cuesta 20.000 unidades al mes en cómputo en la nube y un hardware equivalente que, amortizado, cuesta 8.000 al mes. La repatriación parece obvia. Pero si se suman 4.000 de espacio y energía, 6.000 de personal adicional y 2.000 de licencias y soporte, la diferencia mensual desaparece, y todavía falta el costo único de la migración. Con otros supuestos el resultado puede ser el contrario: el punto es que solo una comparación completa, a tres o cinco años y con el ciclo de renovación incluido, sirve para decidir.

Antes de comparar, conviene agotar la optimización en la nube: eliminar recursos sin uso, ajustar tamaños y usar compromisos de uso para la base estable. Una carga mal dimensionada en la nube también estará mal dimensionada al repatriarla. Y el costo de personal se mide con el mismo rigor con que se mide el ahorro de la automatización, como explicamos en medir el valor de la automatización.

Latencia, soberanía y regulación

No todo es costo. Hay cargas que vuelven, o que nunca deberían haber salido, por razones técnicas o regulatorias.

• Latencia. Sistemas que intercambian grandes volúmenes de datos con aplicaciones que siguen en el centro de datos propio, o que necesitan tiempos de respuesta muy bajos frente a equipos locales, pueden funcionar mejor cerca de ellos. También al revés: dividir una aplicación entre dos entornos puede crear un tráfico cruzado que penaliza latencia y costo.
• Soberanía y ubicación de datos. Si la normativa o el supervisor exigen que ciertos datos permanezcan en el país y no hay una región de nube que lo cumpla, la decisión está tomada. Antes de asumirlo, valida con Cumplimiento qué exige exactamente la norma.
• Concentración y salida. En servicios financieros, los supervisores esperan que la entidad pueda salir de un proveedor crítico. Ese requisito no obliga a repatriar, pero sí a que la salida sea viable, como desarrollamos en gobierno de la nube en servicios financieros.

En la Unión Europea, el Reglamento (UE) 2023/2854, conocido como Data Act, cambia el costo de salir. Entró en vigor el 11 de enero de 2024 y se aplicará de forma general a partir del 12 de septiembre de 2025. Su capítulo sobre el cambio entre servicios de tratamiento de datos obligará a los proveedores a facilitar que el cliente pase a otro proveedor o a infraestructura propia, y retira de forma gradual los cargos por cambio, que incluyen los cargos de salida de datos asociados al cambio. Desde el 11 de enero de 2024 y hasta el 12 de enero de 2027 los proveedores solo pueden cobrar cargos reducidos, que no superen los costos directamente vinculados al proceso de cambio; a partir del 12 de enero de 2027 no podrán cobrarlos.

Dos matices importantes. Primero, el reglamento se refiere al proceso de cambio, no al tráfico de salida de la operación diaria, que sigue cobrándose según la lista de precios de cada proveedor. Segundo, algunos proveedores ya anunciaron por su cuenta exenciones de cargos de salida para clientes que trasladan sus datos fuera; AWS, por ejemplo, lo publicó en marzo de 2024, con condiciones y solicitud previa. Revisa las condiciones vigentes de tu proveedor y valida con Legal cómo aplica el reglamento a tus contratos.

El riesgo de ejecución

Una repatriación es una migración, con todos sus riesgos, en la dirección que el equipo ya no practica. Los puntos que más suelen subestimarse son:

• Capacidades perdidas. Monitoreo, copias de seguridad, alta disponibilidad entre zonas y gestión de identidades vienen integrados en la nube. Fuera, cada uno es un proyecto. Si la observabilidad cambia de plataforma, la selección merece su propio análisis, como explicamos en cómo elegir una plataforma APM.
• Plazos de hardware. Comprar, recibir, instalar y certificar equipos lleva meses. Durante ese tiempo se paga la nube y se invierte en la infraestructura nueva a la vez.
• Talento. Operar hardware, almacenamiento y redes físicas requiere perfiles que muchas organizaciones redujeron al migrar.
• Procedimientos operativos. Los runbooks y la automatización escritos para la nube no sirven tal cual. Conviene reescribirlos como código desde el inicio, siguiendo la lógica de pasar del runbook al playbook.

Cómo decidir, carga por carga

1. Inventaria y mide. Para cada carga, reúne al menos doce meses de consumo, su patrón de demanda y la lista de servicios gestionados que usa.
2. Ubícala en la matriz. Descarta pronto las que están en los cuadrantes de quedarse u optimizar, salvo que haya una exigencia regulatoria.
3. Optimiza primero. Ajusta tamaños y compromisos en la nube y vuelve a medir. La comparación debe hacerse contra la mejor versión de la nube, no contra la actual.
4. Calcula el costo total a tres o cinco años con todos los factores de la tabla, incluidos la migración y el ciclo de renovación.
5. Evalúa el riesgo de ejecución y el plan de salida inverso: si la decisión resulta equivocada, ¿cuánto cuesta volver?
6. Decide y revisa. Documenta los supuestos y revísalos al menos una vez al año, porque precios, regulación y arquitectura cambian.

El resultado más común de este análisis no es "todo a la nube" ni "todo de vuelta", sino una cartera mixta, con cada carga donde su economía y sus requisitos la ubican mejor. Para decisiones con impacto material en costo o en cumplimiento, involucra a Finanzas, Riesgo y Cumplimiento antes de comprometer inversión.