Durante la última década, el cloud público —con AWS, Google Cloud y Azure como referentes— se ha vendido como el camino natural para escalar: pago por uso, catálogo casi infinito de servicios y una promesa implícita de simplicidad. Pero en paralelo está creciendo otra conversación, mucho menos publicitada: empresas que, tras madurar, están replanteándose la factura y la complejidad acumulada y optan por “repatriar” parte de su infraestructura.

No es una moda homogénea ni un rechazo total al cloud. Es más bien un ajuste de estrategia: cuando los workloads se estabilizan, el coste real deja de ser un detalle y el control operativo pasa a tener valor económico.

Basecamp/37signals: de 3,2 millones en cloud a 840.000 al año “todo incluido”

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

Su cálculo para “salir” de esa parte de la factura se apoyó en dos números muy concretos: una inversión de hardware en el entorno de 600.000 dólares (amortizada a cinco años) y un gasto recurrente de colocación, electricidad y conectividad de aproximadamente 60.000 dólares al mes para sus racks en dos centros de datos. La suma, según su propia estimación, deja un coste anual cercano a 840.000 dólares “para todo” (bandwidth, energía y servidores amortizados), frente a los 2,3 millones anuales del tramo de cloud que pretendían llevar a cero.

En esa misma pieza, 37signals proyecta un ahorro de unos 7 millones de dólares en cinco años, sin aumentar el tamaño del equipo de operaciones. El argumento de fondo no es “el cloud es malo”, sino que no comparar el alquiler con la compra cuando el negocio ya es estable puede salir caro.

Ahrefs: cuando el cloud “a precio de catálogo” cambia las matemáticas

El caso de Ahrefs suele sonar aún más extremo, pero merece una matización importante: Ahrefs no se limita a decir “nos salía caro”, sino que publica comparativas técnicas y financieras detalladas.

En un artículo técnico (marzo de 2023), su equipo sostiene que ha ahorrado alrededor de 400 millones de dólares en unos 2,5–3 años al no basar toda su infraestructura en IaaS, y llega a afirmar que si su producto estuviera 100% en AWS no sería rentable o quizá ni existiría.

En una pieza posterior (mayo de 2024), Ahrefs amplía el enfoque: estima un gasto on-prem acumulado de 122 millones de dólares desde 2017 y compara ese recorrido con equivalentes en AWS, concluyendo que el “precio equivalente” no baja de la barrera del 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 ambos casos no es que el cloud sea inviable, sino que para negocios intensivos en computación y almacenamiento, la elasticidad tiene un precio, y cuando la demanda es relativamente predecible, la compra y la colocación pueden ofrecer una ventaja estructural.

El error típico: diseñar para el “éxito infinito” antes de tiempo

En muchas startups, el cloud es la elección correcta por un motivo simple: reduce fricción. Poner algo en producción y empezar a vender suele ser más valioso que optimizar euros por CPU.

El problema llega cuando la arquitectura se construye pensando en “escalar al infinito” desde el día uno. Si la empresa termina siendo un negocio estable con cargas previsibles, puede encontrarse con un escenario en el que sigue pagando por una elasticidad que ya no explota.

Esta es la parte incómoda: la sobre-optimización técnica y la infra sobre-diseñada pueden costar dinero durante años, igual que la infra subdimensionada puede costar clientes. Por eso, el punto no es “cloud sí/no”, sino cuándo y para qué.

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

Otro factor que empuja a replantear el cloud es el bloqueo por diseño (vendor lock-in): cuando una empresa construye alrededor de servicios nativos muy específicos (colas, bases gestionadas, funciones serverless, IAM, etc.), la salida deja de ser “migrar máquinas” y pasa a ser “rehacer sistemas”.

A eso se suma el componente económico del cambio: egress fees y costes de transferencia que penalizan mover datos fuera de una plataforma. La OCDE ha recogido en su análisis de competencia del mercado cloud que estos modelos de precios y barreras de switching refuerzan el lock-in y limitan la movilidad real de los clientes.

Y hay un incentivo de mercado que lo complica todo: los créditos para startups. Programas como AWS Activate ofrecen “hasta 100.000 USD” en créditos, mientras que Google promociona paquetes de hasta 200.000 USD (o más en ciertos casos), y Microsoft mantiene ofertas de créditos para startups en distintos itinerarios. En fase temprana, es lógico aceptar esa ayuda. El riesgo es que, con el tiempo, esos créditos se conviertan en el anzuelo que hace demasiado cara la salida.

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

La seguridad en cloud suele fallar donde siempre: en la capa de aplicación, en configuraciones, permisos y errores humanos. El cloud aporta herramientas potentes y un baseline sólido, pero también introduce complejidad: cuentas, roles, políticas, servicios que se multiplican y superficies de exposición que crecen con el catálogo.

En paralelo, lo “on-prem” no es automáticamente más seguro: exige disciplina, procesos, parches, segmentación, backup serio y control de accesos. Lo que cambia es el reparto de responsabilidades.

Un ejemplo local: Acumbamail y el cloud privado en Stackscale

En España, hay compañías que han optado desde el principio por un modelo de cloud privado para equilibrar agilidad y control. Acumbamail, por ejemplo, aparece como caso de uso de nube privada en Stackscale (Grupo Aire): el enfoque consiste en recursos dedicados al cliente, virtualización y operación sin depender de la lógica “pago por cada servicio” del hyperscaler.

En el contexto descrito, Acumbamail destaca además el valor del almacenamiento en red y opciones de geo-replicación en Madrid. Este tipo de planteamiento busca capturar lo mejor de ambos mundos: flexibilidad de la virtualización y capacidad de crecimiento, con un coste más predecible y control del diseño de alta disponibilidad en dos CPDs locales.

La conclusión práctica: no es “salir del cloud”, es auditar el modelo

Lo que une a los casos que lideran esta tendencia es un hábito poco glamuroso: hacer números con datos reales y revisar supuestos.

Para muchas empresas, el cloud público seguirá siendo la mejor respuesta: por rapidez, por alcance global, por time-to-market o por dependencia de servicios gestionados. Pero para otras —especialmente con cargas estables, intensivas en CPU/almacenamiento o con necesidad de soberanía y predictibilidad—, empieza a tener sentido considerar alternativas como:

• cloud privado con recursos dedicados,
• colocation con hardware propio,
• modelos híbridos (cloud para picos y servicios concretos; “metal” para base estable).

La cuestión no es ideológica. Es operativa y financiera: cuando la infraestructura se convierte en una línea de P&L que pesa, conviene revisarla como se revisa cualquier coste estratégico.

---

Fuentes

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