Durante la última década, el cloud público —con referentes como AWS, Google Cloud y Azure— se ha consolidado como la opción predilecta para escalar: pago por uso, un catálogo casi ilimitado de servicios y una promesa implícita de simplicidad. Sin embargo, en paralelo ha emergido una tendencia menos visible: empresas que, tras madurar, reconsideran sus costes y la complejidad acumulada y optan por “repatriar” parte de su infraestructura.

No se trata de una moda homogénea ni de un rechazo absoluto al cloud. Es más bien un ajuste estratégico: cuando las cargas de trabajo se estabilizan, el coste real y el control operativo adquieren un valor económico importante.

Basecamp/37signals: de gastar 3,2 millones en cloud a unos 840.000 dólares anuales “todo incluido”

Uno de los casos más citados es el de 37signals (Basecamp/HE). Su CTO, David Heinemeier Hansson, explicó que en 2022 invirtieron 3,2 millones de dólares en servicios cloud, de los cuales casi 1 millón correspondía al almacenamiento de 8 PB en S3 (replicados en varias regiones). El resto —unos 2,3 millones— se destinaba a servidores y servicios asociados.

Su estrategia para reducir esa partida se basa en dos factores concretos: una inversión en hardware cercana a 600.000 dólares (amortizada en cinco años) y gastos recurrentes de colocación, electricidad y conectividad de aproximadamente 60.000 dólares al mes para sus racks en dos centros de datos. Según sus cálculos, esto permite un coste anual cercano a 840.000 dólares “todo incluido” (ancho de banda, energía y servidores amortizados), en contraste con los 2,3 millones anuales que desembolsaban en cloud.

En su análisis, 37signals calcula que este cambio podría representar un ahorro de unos 7 millones de dólares en cinco años, sin aumentar el equipo de operaciones. La idea principal no es que “el cloud sea inviable”, sino que comparar el alquiler directo con la compra cuando la carga de trabajo es estable puede ser mucho más rentable.

Ahrefs: cuando el mercado “catálogo de precios” altera las matemáticas

El caso de Ahrefs destaca por ser aún más drástico, pero debe matizarse: no sólo alegan que “les salía caro”, sino que presentan análisis técnicos y financieros detallados.

En un artículo técnico (marzo de 2023), su equipo sostiene que lograron ahorrar aproximadamente 400 millones de dólares en unos 2,5 a 3 años al no basar toda su infraestructura en IaaS, y señalan que si su producto dependiera totalmente de AWS, probablemente no sería rentable o incluso no existiría.

En otro informe (mayo de 2024), Ahrefs amplia su visión: estima que han gastado unos 122 millones de dólares en infraestructuras on-premise desde 2017. Comparan esa inversión con alternativas en AWS y concluyen que el precio equivalente no baja de los 1.000 millones de dólares, dependiendo de los supuestos (instancias on-demand frente a reservas a 3 años).

El mensaje común de estos ejemplos no es que el cloud sea inviable, sino que para negocios con altas necesidades de computación y almacenamiento, la elasticidad tiene un coste. Cuando la demanda es predecible, la compra y gestión propia puede ofrecer ventajas competitivas y económicas importantes.

El error típico: planificar para “éxito infinito” antes de tiempo

Muchas startups eligen el cloud por un motivo sencillo: reducir fricciones. Poner algo en producción y comenzar a vender suele ser más valioso que optimizar cada euro gastado en CPU.

El problema surge cuando se diseña la arquitectura pensando en “escalar hasta el infinito” desde el inicio. Si la empresa se estabiliza y encuentra cargas previsibles, puede acabar pagando por una elasticidad que ya no necesita y que no explota.

La realidad incómoda es que sobreoptimizar técnicamente o sobre-diseñar la infraestructura puede generar costes durante años, igual que una subdimensionada puede perder clientes. Por ello, no se trata de una cuestión ideológica: el decidir cuándo y para qué migrar o abandonar el cloud es clave.

El vendor lock-in: la trampa no siempre es técnica, también económica

Otro factor que invita a reconsiderar el cloud es el vendor lock-in: cuando una empresa construye su infraestructura sobre servicios específicos (colas, bases gestionadas, funciones serverless, IAM, etc.), migrar equivale a rehacer sistemas, más allá de mover máquinas.

Además, los costes de transferencia de datos (“egress fees”) y las barreras económicas que encarecen mover datos fuera de una plataforma refuerzan esa dependencia. La OCDE ha documentado en sus análisis que estos modelos de precios dificultan la movilidad real de los clientes y favorecen el lock-in.

En el mercado surgen también incentivos: créditos para startups. Programas como AWS Activate ofrecen “hasta 100.000 USD”, Google entrega paquetes de hasta 200.000 USD (en algunos casos) y Microsoft también mantiene incentivos en distintos programas. En las etapas iniciales, aceptar esa ayuda es lógico, pero con el tiempo esos créditos pueden convertirse en un “anzuelo” que complica la salida estructural del sistema.

¿Y la seguridad? No es tan simple como “cloud = seguro”

La seguridad en cloud suele fallar donde siempre: en la capa de aplicación. Configuraciones incorrectas, permisos mal gestionados y errores humanos siguen siendo la causa principal de incidentes. Aunque el cloud proporciona herramientas robustas y una base sólida, también introduce complejidad: gestión de cuentas, roles, políticas, servicios que se multiplican y superficies de exposición que crecen con la oferta.

En paralelo, lo “on-premise” no garantiza automáticamente mayor seguridad. Requiere disciplina, procesos establecidos, parches adecuados, segmentación, respaldo sólido y control de accesos. La diferencia radica en el reparto de responsabilidades y en la gestión de los riesgos.

Un ejemplo local: Acumbamail y el cloud privado en Stackscale

En España, algunas compañías optan desde el principio por un modelo de cloud privado para equilibrar agilidad y control. Acumbamail, por ejemplo, es un caso en el que utilizan nube privada en Stackscale (Grupo Aire): recursos dedicados, virtualización y gestión propia, sin depender del esquema “pago por servicio” de los hyperscalers.

En su contexto, Acumbamail destaca el valor del almacenamiento en red y la opción de geo-replicación en Madrid. La estrategia busca aprovechar lo mejor de ambos mundos: flexibilidad, crecimiento controlado y un coste más predecible al diseñar alta disponibilidad en dos centros de datos locales.

La conclusión práctica: no se trata de “salir del cloud”, sino de auditar el modelo

Lo que une estos casos es una práctica poco glamourosa pero fundamental: hacer números con datos reales y revisar los supuestos en función de la realidad del negocio.

Para muchas empresas, el cloud público seguirá siendo la opción más adecuada por rapidez, alcance global, tiempo de llegada al mercado o por el uso de servicios gestionados. Pero para otras —con cargas estables, demandas específicas en CPU y almacenamiento, o necesidades de soberanía y previsibilidad—, empieza a tener sentido explorar alternativas, como:

• cloud privado con recursos dedicados,
• colocation con hardware propio,
• modelos híbridos (cloud para picos y servicios específicos; infraestructura física para cargas estables).

La clave no es ideológica. Es operativa y financiera: cuando la infraestructura impacta en la línea de P&L, conviene revisarla con rigor, como cualquier coste estratégico.

Fuentes

• DiSaaSter: El éxodo del cloud
• 37signals / DHH: desglose del gasto en cloud (3,2 M$ en 2022), cálculo del coste anual on-prem (~840.000 $) y ahorro estimado en 5 años (~7 M$)
• Ahrefs: análisis del ahorro estimado (~400 M$) y comparación entre gasto on-prem (122 M$ desde 2017) y alternativas en AWS (más de 1.000 M$ en supuestos).
• OCDE: barreras de switching y egress fees como elementos que refuerzan el vendor lock-in.
• Caso de éxito de Acumbamail en Stackscale: centros de datos en Madrid como base de arquitecturas locales de alta disponibilidad.