Durante la última década, el cloud público —con AWS, Google Cloud y Azure como referentes— se ha consolidado como la opción natural para escalar: pago por uso, un catálogo casi infinito de servicios y una promesa implícita de simplicidad. Sin embargo, en paralelo ha crecido otra conversación, menos publicitada: empresas que, tras madurar, reconsideran su facturación y la complejidad acumulada y deciden “repatriar” parte de su infraestructura.
No se trata de una tendencia homogénea ni de un rechazo total al cloud. Es más bien un ajuste estratégico: cuando las cargas de trabajo 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 dólares anuales “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, 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— fue para servidores y servicios asociados.
Su cálculo para reducir esa parte de la factura se apoyó en dos cifras concretas: una inversión de hardware en torno a 600.000 dólares (amortizada en cinco años) y un gasto recurrente en 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 propio análisis, sitúa el coste anual en cerca de 840.000 dólares “para todo” (ancho de banda, energía y servidores amortizados), frente a los 2,3 millones anuales del tramo en cloud que pretendían neutralizar.
En ese mismo análisis, 37signals proyecta un ahorro de unos 7 millones de dólares en cinco años, sin incrementar su equipo de operaciones. La idea central no es “el cloud es malo”, sino que no comparar el alquiler con la compra cuando el negocio ya es estable puede ser costoso.
Ahrefs: el cloud “a precio de catálogo” que modifica las matemáticas
El caso de Ahrefs suele aparecer aún más radical, pero merece matizarse: 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 aproximadamente 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, quizás no sería rentable o incluso no existiría.
En un análisis posterior (mayo de 2024), Ahrefs amplía el enfoque: estima un gasto on-prem de 122 millones de dólares desde 2017 y compara esa cifra con costes equivalentes en AWS, concluyendo que el “precio equivalente” supera 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 en ambos casos es que no se trata de que el cloud sea inviable, sino que para negocios intensivos en computación y almacenamiento, la elasticidad tiene un coste. Cuando la demanda es relativamente predecible, la compra y el despliegue físico pueden ofrecer ventajas estructurales.
El error típico: planificar para el “éxito infinito” antes de tiempo
En muchas startups, el cloud es la elección correcta precisamente porque reduce fricciones. Poner algo en producción y empezar a vender suele ser más valioso que optimizar cada euro de CPU.
El problema aparece cuando la arquitectura se diseña pensando en “escalar al infinito” desde el comienzo. Si con el tiempo la empresa se estabiliza con cargas previsibles, puede acabar pagando por una elasticidad que ya no necesita o no explota.
Lo incómodo es que la sobre-optimización técnica y la infraestructura sobredimensionada pueden costar dinero durante años, igual que una infra subdimensionada puede perder clientes. Por eso, la clave no es “cloud sí o 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 lleva a replantear el cloud es el bloqueo por diseño (vendor lock-in): cuando una empresa construye su infraestructura alrededor de servicios nativos muy específicos (colas, bases gestionadas, funciones serverless, IAM, etc.), salir del ecosistema no consiste en “migrar máquinas”, sino en “rehacer sistemas”.
Sumado a esto, el coste económico del cambio —como las egress fees y los costes de transferencia— penaliza mover datos fuera de una plataforma. La OCDE, en su análisis del mercado cloud, señala que estos modelos de precios y barreras para cambiar refuerzan el lock-in y limitan la movilidad real de los clientes.
Además, existe un incentivo de mercado que complica aún más las cosas: los créditos para startups. Programas como AWS Activate ofrecen “hasta 100.000 USD” en créditos, Google promociona paquetes de hasta 200.000 USD (o más en ciertos casos), y Microsoft mantiene ofertas de créditos para startups en varias rutas. En fases tempranas, es lógico aprovechar esta ayuda. Pero el riesgo es que, con el tiempo, esos créditos se conviertan en un “anzuelo” que encarece demasiado la salida.
¿Y la seguridad? No es tan simple como “cloud = seguro”
La seguridad en cloud suele fallar en el mismo lugar que 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.
Por otro lado, lo “on-prem” no es automáticamente más seguro: requiere disciplina, procesos, parches, segmentación, backups adecuados y control de accesos. La diferencia radica en el reparto de responsabilidades.
Un ejemplo local: Acumbamail y su cloud privado en Stackscale
En España, algunas empresas optan desde el principio por modelos de cloud privado para equilibrar agilidad y control. Acumbamail, por ejemplo, es uno de los casos de uso de cloud privado en Stackscale (Grupo Aire): el enfoque consiste en recursos dedicados al cliente, virtualización y operación sin depender de la lógica de “pago por servicio” de los hyperscalers.
En este contexto, Acumbamail también resalta el valor del almacenamiento en red y las opciones de geo-replicación en Madrid. Se busca captar lo mejor de ambos mundos: flexibilidad en virtualización y capacidad de crecimiento, con un coste más predecible y controlado para garantizar 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 a estos casos es un hábito sencillo, pero poco glamuroso: hacer cálculos con datos objetivos y revisar los supuestos.
Para muchas organizaciones, el cloud público seguirá siendo la mejor opción por velocidad, alcance global, tiempo de lanzamiento o dependencia de servicios gestionados. Pero para otras —sobre todo aquellas con cargas estables, intensivas en CPU/almacenamiento, o con requisitos de soberanía y previsibilidad—, empieza a tener sentido considerar alternativas como:
- cloud privado con recursos dedicados,
- colocación con hardware propio,
- modelos híbridos (cloud para picos y servicios específicos; hardware dedicado para cargas estables).
La decisión no es ideológica, sino operativa y financiera: cuando la infraestructura pasa a ser una línea de P&L que impacta en resultados, conviene revisarla como 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) versus costes equivalentes en AWS (>1.000 M$ según supuestos)
- OCDE: barreras de switching y egress fees que refuerzan el vendor lock-in en cloud
- Ejemplo de Acumbamail en Stackscale y centros en Madrid para arquitecturas locales HA