Cloud Repatriation 2026: cuándo compensa el camino de vuelta
Cloud Repatriation 2026 como decisión TCO: desde qué perfil de carga compensa el co-location más Kubernetes frente a AWS y Azure.
La Cloud Repatriation suena en 2026 a marcha atrás, pero es solo la cuenta que vence después de tres años de operación en hyperscalers. La pregunta no es «fuera de la cloud», sino: desde qué perfil de carga se vuelve el co-location más Kubernetes más atractivo, numéricamente, que AWS o Azure. Quien no pase el modelo por hoja de cálculo, o ahorra dinero en una cloud cara, o lo quema en un rack mal dimensionado.
Lo esencial en resumen
- La repatriación es una decisión TCO, no una religión. Cargas con base estable y egress alto son los candidatos; las APIs bursty no pertenecen ahí.
- La línea de ruptura está entre el 60 y el 70 por ciento de uso. Por debajo, la elasticidad del hyperscaler gana al co-lo. Por encima se paga 24/7 por capacidad que de todas formas se necesita, más personal, que todos infravaloran.
- Lo híbrido es la arquitectura realista de destino. Kubernetes más GitOps hace abordable el repliegue; los casos interesantes mueven del 60 al 80 por ciento del compute, los managed services y los picos se quedan en la cloud.
RelacionadoCostes de inferencia IA 2026: FinOps para cargas GPU / Platform Engineering 2026: Internal Developer Platforms
El debate está en marcha desde que 37signals calculó públicamente en 2023 que ahorraba una cifra de siete dígitos con servidores propios. Después llegaron muchas columnas de opinión, pocos números. En el contexto enterprise falta un armazón TCO honesto: no para el backend que corre en el portátil, sino para cargas con una curva de carga real, requisitos de compliance y responsabilidad operativa.
Este artículo entrega ese armazón. Sin ideología, sin palos a los hyperscalers. Solo las palancas que marcan la diferencia. Más una cuenta que se puede seguir en una servilleta.
Cuándo el camino de vuelta tiene sentido numérico
La mayoría de los casos de repatriación no fracasan por la técnica, sino por el perfil de las propias cargas. Los hyperscalers venden elasticidad. Para eso es justo un recargo sobre los costes de baremetal. Se vuelve injusto cuando nunca se usa la elasticidad. Una pipeline de análisis que corre 24 horas al día y muestra cada jornada más o menos la misma curva de recursos es el caso de libro para co-location. Un webshop con pico de Black Friday, más bien no.
El segundo factor que muchos ignoran es el egress. En AWS las salidas de datos cuestan dinero de verdad desde el primer terabyte. En Azure el cuadro es parecido. Las cargas que expulsan grandes volúmenes de datos – video transcoding, destinos de backup, entrenamientos ML con dataset externo – sostienen su estancia en el hyperscaler en buena parte vía tráfico, no vía compute.
Como regla para el primer filtro: si la carga media de CPU de las instancias en la media mensual está por encima del 60 por ciento y la cuota de egress en la factura cloud aporta dos dígitos porcentuales, el modelo de cálculo merece la pena. Si estáis por debajo, quedaos en el hyperscaler y haced FinOps. Es más barato que un proyecto de migración.
Fuente: modelo TCO de cloudmagazin, supuestos en el apartado siguiente
El modelo de cálculo que cabe en una servilleta
Para no quedarnos en lo vago, tomemos una carga realista. Cien nodos de compute, equivalentes aproximadamente a AWS m7i.4xlarge (16 vCPU, 64 GB RAM). En la cloud on-demand alrededor de 0,80 euros por hora e instancia, con reserved instances a un año unos 0,48 euros. Storage y red los dejamos a propósito aparte, porque dependen de la carga.
En el lado cloud aterrizamos con reserved instances en unos 420.000 euros al año solo compute, on-demand en alrededor de 700.000 euros. Los costes de egress, con uno o dos terabytes outbound al día, suman aproximadamente entre 60.000 y 120.000 euros. Factura anual realista solo de esta carga: entre medio millón y algo menos de un millón de euros.
| Partida de coste | Hyperscaler | Co-location | Chequeo de realidad |
|---|---|---|---|
| Compute | on-demand + reserved/savings plans | CAPEX de baremetal + amortización 3-5 años | Por encima del 60 por ciento de uso, el co-lo empieza a ganar |
| Egress | caro desde el primer TB | contratos de tránsito, típicamente más baratos con volumen | partida principal en cargas de vídeo, backup y datasets ML |
| Personal | managed services, overhead SRE bajo | mínimo 2 SRE dedicados, rotación 24/7 permanente | la partida que todos infravaloran; es mínimo, no lujo |
| Plataforma | managed K8s, queues, bases de datos | stack propio K8s + GitOps + monitoring | sin capa de plataforma no hay repliegue abordable |
Valoración propia. Las cifras concretas dependen del perfil de carga, la región y la posición de negociación.
En el lado del co-location la cuenta es distinta. Dos racks en un centro de datos DACH con energía y refrigeración, equivalente a entre 48.000 y 72.000 euros al año. Amortización de hardware para cien nodos de Dell o Supermicro a cinco años, con entre 10.000 y 14.000 euros de precio de catálogo por nodo, es decir entre 200.000 y 280.000 euros al año. Uplink de red 10 Gbit redundante: entre 20.000 y 35.000 euros. Dos SRE dedicados con responsabilidad operativa de Kubernetes y hardware: con coste pleno unos 220.000 euros. Colchón para repuestos, remote hands y cambio de provider: 40.000 euros.
Suma: entre 528.000 y 647.000 euros al año. Frente a la factura cloud de 480.000 a casi un millón, no es una bala de plata, sino un corredor en el que la decisión se toma por el perfil de carga y por el egress. Interesante no es en cien nodos, sino con 300 o 500, donde los costes de hardware actúan de forma decreciente pero el personal y los racks no escalan linealmente.
Qué cambia realmente Kubernetes en el co-lo
En 2019 la repatriación, operativamente, no era divertida. Servidores baremetal con Ansible y configuraciones LB cuidadas a mano son un viaje en el tiempo que nadie quiere hacer. En 2026 el asunto es otro. Kubernetes sobre hardware propio ya no es un setup exótico, sino una opción por defecto de plataforma: Cluster API para el lifecycle, Rancher u OpenShift para la operación, Flux o ArgoCD para GitOps, Cilium para la red, Longhorn o Ceph para storage.
Lo que marca la diferencia es la abstracción. Los desarrolladores siguen viendo una API de Kubernetes, esté debajo EKS, AKS o un clúster en el co-lo de Frankfurt. Esa es la verdadera palanca: la repatriación se convierte en un swap de backend, no en un rewrite de la aplicación.
Son críticos tres puntos en los que la abstracción se filtra. Primero, storage: un volumen EBS se comporta distinto a un volumen Longhorn o Ceph RBD, sobre todo bajo presión de latencia. Segundo, networking: AWS Load Balancer Controller y Cilium LB sobre MetalLB entregan funciones parecidas, pero los tiempos de failover y la lógica de configuración son propios. Tercero, identidad: la federación al estilo IRSA sobre hardware propio es factible, pero requiere SPIRE o una capa equivalente de workload identity, que hay que mantener operativamente.
Quien no haya resuelto esos tres temas antes del go-live, tendrá que resolverlos después en producción, en medio de incidentes. Es el camino más caro. Al mismo tiempo, en 2026 la comunidad ha avanzado lo suficiente como para que runbooks, helm charts y arquitecturas de referencia para esos puntos concretos estén disponibles de forma abierta. SUSE, Red Hat y las comunidades de clientes aportan plantillas que ya no hay que construir desde cero.
Eso cambia el carácter del proyecto. La repatriación de 2019 era una obra nueva en descampado. La de 2026 es un swap estructurado con buena tool-chain, documentación sólida y una comunidad que ya ha visto la mayoría de los escollos.
Así se ve una ruta de migración realista
- Inventario de cargas con cifras honestas. Uso de CPU p95 en 90 días, necesidad de memoria, egress de red, dependencias con managed services como RDS o Cosmos DB. Los candidatos son servicios estables, con poco estado y base alta.
- Landing zone en el co-lo antes de mover una sola carga. Dos racks, Kubernetes vía Cluster API, enganche de identidad al IdP existente, logs y métricas al mismo stack que en la cloud. Objetivo: intercambiable operativamente.
- Mover un workload piloto que duela si cae. Nada de herramientas internas primero. Si la operación y la pipeline de deploy no aguantan la presión productiva, la arquitectura no está lista.
- Bases de datos al final, y solo con plan claro. Postgres gestionado o Cosmos DB son a menudo la palanca que se queda en la cloud. Un clúster propio de Postgres es factible, pero exige tiempo real de DBA y una estrategia de backup limpia.
- Definir criterios de salida antes de empezar. A partir de qué incidente, qué empeoramiento del MTTR o qué drift de presupuesto, el repliegue se convierte en camino de vuelta. Por escrito, no en la cabeza.
Los trade-offs honestos
Toda arquitectura tiene costes que solo se ven en operación. En el co-location esos no son las partidas evidentes de hardware, sino los factores blandos. Aquí la comparación sin maquillaje:
- Costes planificables, sin sorpresas de billing a fin de mes
- Control del hardware para perfiles GPU, storage o red especiales
- Residencia de datos y compliance sin matriz de países de servicios
- Margen de performance que en public cloud solo se paga caro
- Licencias por cores caras (Oracle, MSSQL) a menudo más baratas on-prem
- Sin autoscaling para picos sin un acople híbrido
- Lógica de inversión en vez de OpEx: la conversación con el CFO se endurece
- Tema de personal: 2 SRE son el mínimo, no el confort
- Se pierden managed services o hay que operarlos en casa
- La distribución geográfica necesita más de un co-lo
Quien lea esta lista y sienta que la columna derecha pesa más, probablemente haya acertado. El co-location no gana a los hyperscalers porque la cloud sea cara. Gana cuando el perfil de carga, la estructura de costes y el setup de equipo encajan.
Dónde se sitúa realistamente la línea híbrida en 2026
La mayoría de los proyectos que he visto de cerca en los últimos doce meses no aterrizan en «todo fuera». Aterrizan en una arquitectura híbrida en la que entre el 60 y el 80 por ciento de la carga compute está en el co-lo. La cloud se queda entonces para tres cosas: bases de datos gestionadas que no se quieren operar internamente, capacidad pico vía federation de clústeres Kubernetes y servicios edge o globales para los que una sola ubicación co-lo no basta.
Esta línea no es un compromiso, sino la respuesta honesta a una cuenta que solo una parte de las cargas supera. Quien lo acepte ya tiene medio camino hecho. Quien exija «todo o nada» vuelve a caer en la trinchera ideológica en la que el debate ha estado demasiadas veces desde 2023.
Lo que hace además interesante a la arquitectura destino: desacopla compra y operación. La amortización del hardware corre a cinco años, los contratos de colo a 24 o 36 meses. Los contratos cloud se pueden, en caso de duda, girar en semanas. Esa mezcla de CAPEX y OPEX es más legible para los CFOs que una factura cloud que cada mes pinta distinta. Quien recorra una vez con su equipo financiero un cálculo híbrido bien montado se dará cuenta: la aparente inversión hardware anticuada es la parte más planificable del roadmap de infraestructura.
El precio para eso es disciplina en el capacity planning. Quien mantenga permanentemente un 30 por ciento de headroom en el co-lo, pierde parte de la ventaja de coste. Quien dimensione demasiado justo, hace pedidos en seis meses y pierde tiempo. Los mejores equipos que he visto trabajan con forecasts rodados de 12 meses y una opción de cloud burst justo para los picos que no pueden prever con seguridad.
Conclusión
La Cloud Repatriation en 2026 no es una retirada, sino un proceso de madurez. La técnica está lista. Kubernetes en el propio rack ya no es un proyecto de investigación. La decisión sigue siendo comercial: utilización media, cuota de egress, capacidad del equipo. Quien no conozca esas tres cifras debería aparcar la idea de repatriación y recuperar primero FinOps. Quien las conozca y el corredor cuadre, obtendrá al final un setup que corre de forma planificable, y un CFO que ya no se estremece cada mes cuando llega la factura cloud.
Preguntas frecuentes
¿A partir de qué factura cloud compensa siquiera mirar la repatriación?
Por debajo de unos 300.000 euros de coste cloud al año, el esfuerzo organizativo se come el ahorro. A partir aproximadamente de medio millón de euros, el modelo de cálculo empieza a ponerse interesante, siempre que el perfil de carga encaje. Por debajo, casi siempre es mejor palanca FinOps.
¿Necesito forzosamente dos ubicaciones co-lo para redundancia?
Para cargas productivas con compromisos de SLA: sí, dos ubicaciones o un camino de failover a la cloud. Un solo centro de datos es single point of failure. La mayoría de los setups híbridos lo resuelven dejando la cloud como destino de DR, no como operación primaria.
¿Cuánto cuesta de forma realista, al año, operar un clúster Kubernetes en el co-lo?
Sin hardware, solo operación: entre dos y tres plazas SRE a jornada completa para un clúster con 100 a 200 nodos, más licencias del stack de observability y, en su caso, Rancher u OpenShift. Realistas son entre 300.000 y 450.000 euros al año. Quien crea que basta con media plaza infravalora la operación de incidentes y el lifecycle.
¿Se pueden llevar managed services como RDS o Cosmos DB?
No sin más. Existen equivalentes auto-operables (CloudNativePG, CrunchyData, YugabyteDB), pero exigen tiempo de DBA y procesos de backup limpios. En muchos setups híbridos, las bases de datos se quedan conscientemente en la cloud aunque la parte compute se mueva.
¿Cuánto dura una repatriación parcial realista?
Desde la decisión hasta cerrar el primer traslado de carga: entre seis y nueve meses. La fase de landing zone por sí sola, es decir co-lo, Kubernetes, identidad, observability, necesita entre tres y cuatro meses. Quien quiera estar en tres meses, o bien lo tiene todo ya listo, o hunde el proyecto.
¿Cuál es el fallo más frecuente en proyectos de repatriación?
La inversión hardware se calcula con rigor, los costes de personal se maquillan. Dos SRE se convierten en 1,5, que además ayuda en otra parte. Ocho meses después, el equipo está sobrecargado. La calidad operativa cae por debajo del nivel que antes se tenía en la cloud. Ese es el clásico del que hay que protegerse.
Recomendaciones de lectura
- Costes de inferencia IA 2026: FinOps para cargas GPU
- Platform Engineering 2026: Internal Developer Platforms en operación
- Valkey 9 vs. Redis: 18 meses tras el fork del cache
Más en la red MBF Media
Data Act: qué deben regular ahora los fabricantes IoT
Cloud Repatriation 2026 desde la perspectiva del CIO
Infostealers 2026 y el riesgo de sesión MFA
Fuente de la imagen de portada: Pexels / Brett Sayles (px:5480781)
