A producción: hierro contra azúcar

Tu producto ya funciona en local. Ahora toca subirlo a internet y te encuentras con veinte proveedores, cada uno con su tabla de precios, y ninguno te dice claramente cuánto vas a pagar de verdad.

En un extremo tienes el hierro: tú te montas la máquina, tú te comes los problemas y tienes un gasto previsible. En el otro está lo que aquí llamaremos el azúcar: te lo dan todo hecho, despliegas en cuatro clics y le quitas el amargor al café. Entre medias hay de todo.

En este post recorremos cuatro niveles, desde el hierro hasta el azúcar, con precios reales y una chuleta final para ayudarte a elegir. No es una clasificación técnica: simplemente los hemos ordenado según cuánto trabajo te quita el proveedor. De hecho, Azure aparece en el nivel 2, pero vende desde máquinas peladas hasta servicios tan azucarados como los del nivel 3. Y no es una decisión para toda la vida: lo normal es cambiar conforme crece el proyecto, porque la solución se queda corta o porque la factura empieza a doler.

TL;DR;

Elegir qué aproximación de infraestructura usar no es nada fácil. No existe una opción correcta para todos: depende del tráfico, del tipo de aplicación, del equipo y de cuánto quieras encargarte tú mismo.

• Si estás empezando o no tienes a alguien dedicado a infraestructura, probablemente te interese comprar azúcar. Por 20 o 40 € al mes puedes desplegar fácilmente, absorber picos importantes y centrarte en conseguir clientes. Peeerooo, ojo con la letra pequeña: estudia bien si lo que ofrece el proveedor encaja con tu proyecto, porque determinados patrones de uso pueden acabar dando una sorpresa en la factura, o incluso que tu web deje de cargar durante un partido de fútbol 😅 (no es broma).

• Cuando tienes un tráfico alto, estable y previsible, un VPS o una máquina virtual pueden empezar a salir mejor de precio. El servidor puede costar bastante menos, pero parte de ese ahorro consiste en que la seguridad, las actualizaciones, las copias, el escalado y las caídas pasan a ser responsabilidad tuya.

• Si necesitas redes privadas, IP fija, determinadas certificaciones o requisitos corporativos, AWS, Azure o Google Cloud suelen ofrecer más opciones para cubrirlos. No siempre será la solución más barata ni la más sencilla, pero cuentan con servicios y herramientas pensados para este tipo de escenarios.

• El hierro propio suele reservarse para casos en los que el volumen, los requisitos o el ahorro potencial justifican comprar servidores y mantener un equipo especializado. Para la mayoría de los proyectos pequeños y medianos, probablemente no salgan las cuentas.

Antes de elegir proveedor, optimiza la aplicación. Una web estática, bien cacheada y con los assets en un CDN consume poco casi en cualquier sitio, y eso puede cambiar por completo las cuentas.

La trampa está en comparar únicamente la cuota mensual: unos proveedores te cobran una máquina; otros, CPU, memoria, tráfico, peticiones, usuarios, proyectos y complementos. El más barato de verdad no es necesariamente el que anuncia el precio más bajo, sino el que mejor encaja con tu carga de trabajo y con el equipo que tienes.

Si quieres ver cuánto azúcar estás comprando en cada nivel —y dónde puede esconderse la sorpresa en la factura—, seguimos.

---

Nivel 0: tu propio hierro

Así se desplegaba a principios de los 2000. Ponías un champiñón en un rack, le asignabas una IP fija y a correr.

Sigue teniendo sentido en dos casos: si quieres aprender de verdad cómo funciona todo, o si tienes el tamaño y el equipo para que el ahorro compense el trabajo que da mantenerlo.

El caso más comentado de los últimos años es el de 37signals, la gente de Basecamp: se salieron de la nube, se gastaron unos 600.000 $ en servidores y calculan un ahorro de unos 10 millones de dólares en cinco años sobre una factura de nube que rondaba los 3,2 millones anuales. Fíjate en que fueron en dirección contraria a la de este post: del azúcar de vuelta al hierro. Eso sí, tienen un equipo que sabe muy bien lo que hace.

Y un matiz que se malinterpreta mucho: "hierro propio" casi nunca significa montarte un centro de datos. Lo normal es comprar los servidores y meterlos en un sitio de colocation, que pone el edificio, la luz, la refrigeración y la conectividad. Es justo lo que hicieron ellos: los servidores son suyos, las naves no.

Y en el otro extremo de la escala está Meta. Facebook, Instagram y WhatsApp no corren sobre AWS ni sobre Azure: van sobre centros de datos, racks y servidores de diseño propio, que además publican en el Open Compute Project del que son fundadores. Para que te hagas una idea del nivel, tienen clústeres de 24.576 GPUs para entrenar sus modelos. Cuando llegas ahí, el hierro deja de ser un gasto y pasa a ser parte del producto.

Para el resto de los mortales, esto tiene más letra pequeña de la que parece, y cuánta depende de dónde metas las máquinas:

• En tus instalaciones te comes absolutamente todo: la luz, la conectividad, la refrigeración y la seguridad física del sitio.
• En colocation te quitas esa parte de encima, pero el hardware sigue siendo tuyo. Y con él, la arquitectura, la redundancia y las guardias.

Porque al final el hierro se rompe. Se quema una fuente de alimentación un domingo por la noche y ahí no hay botón de escalar: hay alguien conduciendo con un repuesto en el maletero.

Mucho dolor de cabeza. A cambio, un gasto mucho más previsible y sin un contador corriendo por cada petición.

Nivel 1: el VPS

Un VPS es una máquina virtual encendida las 24 horas. Alquilas un trozo de un servidor físico —CPU, memoria y disco— y lo configuras casi como si fuera tuyo. Aquí juegan Hetzner, OVH, DigitalOcean, Vultr, Linode, o CubePath entre otros.

Y ahora agárrate. Vamos a comparar un VPS de OVH con una máquina virtual y un App Service de Azure, cogiendo en los tres casos una cantidad de memoria parecida:

(Precios al mes, sin IVA, Linux, Europa Occidental y sin compromiso de permanencia. Consultados en agosto de 2026; los de Azure salen de su Calculadora oficial. Ojo, que la máquina virtual no incluye el disco, que se factura aparte. Y no es una comparación de rendimiento: usamos la memoria como referencia sencilla, pero los núcleos, el disco, la red y el SLA cambian entre columnas. Sirve para ver el orden de magnitud, no para decir que una opción rinde veinte veces más por euro.)

¡La leche, hasta casi veinte veces más! ¿Pero esto qué es?

Fíjate en la columna del medio, porque es la que suele sorprender: en un proveedor grande también puedes alquilar una máquina pelada, sin el azúcar del App Service. Sale bastante más cara que un VPS, pero poco más de la mitad que el servicio gestionado. O sea que "proveedor grande" no significa automáticamente "carísimo": significa que ahí hay de todo y tú eliges cuánto azúcar quieres. Y si te comprometes a uno o tres años, esa columna baja bastante más.

Y otro dato de la primera columna que conviene retener: esos VPS vienen con tráfico ilimitado. Acuérdate dentro de un rato.

Volviendo al contraste: es que no estás comparando lo mismo. Con el VPS te llevas la máquina; de ahí para arriba, es cosa tuya:

• Mantenerlo vivo y seguro: actualizaciones del sistema y del software, monitorización y certificados SSL. Algunos VPS traen una copia diaria básica —el de OVH del ejemplo la trae—, pero montar y probar una estrategia de recuperación de verdad sigue siendo cosa tuya.
• Que no se caiga: tolerancia a fallos y despliegues sin dejar el sitio fuera de servicio. Ninguna de las dos es trivial.
• Crecer: subir de máquina hasta cierto nivel es fácil (más RAM, más disco duro, más cores); poner varias máquinas a repartirse el trabajo ya son orquestación, balanceo y sesiones compartidas.

Todo eso no es gratis: es tiempo de alguien que sepa de infraestructura. Y si no lo tienes, te toca aprender a ti (spoiler... no es trivial), y es tiempo que no le dedicas a tu producto.

Además hay riesgos que no controlas por mucho que te apliques. En 2021 se incendió un centro de datos de OVH en Estrasburgo y millones de webs se quedaron fuera durante días. Muchos descubrieron ahí que sus backups estaban en el mismo edificio que ardió 😇.

Esto lo usan tanto empresas pequeñas como grandes, y funciona. Si has hecho un ciclo formativo superior de desarrollo web (DAW), seguro que el profe de PHP te mandó montarte un VPS para desplegar la práctica. Y va estupendamente... hasta que te dejas algo sin actualizar y te entran hasta la cocina, o falla el cron que renovaba el certificado y tu web amanece marcada como "no segura".

Este es justo el momento en el que uno empieza a pensar en el azúcar y su paz mental.

Nivel 2: los proveedores grandes

AWS (Amazon), Azure (Microsoft) y GCP (Google). Te dan de todo, desde cosas muy pegadas al hierro hasta servicios muy azucarados, pasando también por todo lo que hay en medio.

Siguiendo con el ejemplo de App Service, lo que compras por esos 134 € es:

• Reservas unos recursos (X cores, X gigas) y despliegas encima una o varias aplicaciones que se los reparten.
• Despliegas con contenedores Docker si te viene bien.
• Escalas hacia arriba (más recursos) o hacia los lados (más instancias), y puedes automatizarlo.
• Enlazas tu dominio y te dan certificado SSL gratis que se renueva solo.
• Le enchufas lo que necesites: métricas, copias programadas, IP de salida fija... con su coste, claro.

La diferencia con el VPS es que no te preocupas de nada: no hay que parchear, ni reiniciar, ni configurar un balanceador, ni montar un cron para las copias de seguridad. Y si algún día necesitas escalar, lo haces en un par de clics.

Y ojo con una cosa, porque esos 134 € pueden asustar y no todo el mundo tiene que empezar ahí. Para un sitio con poco tráfico, bien optimizado y ejecutándose sobre Node o similar, un plan Basic va sobrado: la B1 (Linux, 1 core, 1,75 GB de RAM) cuesta alrededor de 11,53 € al mes y la B2 (2 cores, 3,5 GB) 23,07 €.

¿Y cuánto puede aguantar? Si el App Service Plan está dedicado exclusivamente a ese sitio, probablemente más de lo que parece. 100.000 visitas al mes equivalen a unas 3.300 al día, una media muy baja para una aplicación Node bien optimizada. Pero el promedio mensual engaña: lo que realmente importa son los picos simultáneos (no es lo mismo 100.00 visitas repartidas en un mes, que todas a la vez porque un streamer famoso te menciona en un directo 😉), cuánto trabajo hace el servidor en cada petición y cuánto tardan la base de datos y los servicios externos. Si buena parte de las páginas y recursos se sirven desde caché o CDN, una B1 puede manejar cifras bastante superiores; si cada visita provoca varias consultas pesadas, puede quedarse corta con mucho menos tráfico.

Eso sí, mira la letra pequeña del Basic: escala a mano hasta tres instancias y no trae autoescalado, que aparece al subir de plan. Si quieres que escale solo, el siguiente escalón en la tabla de precios es ya Premium: la P0v3 son unos 57 € al mes. O sea, que pasar de "me apaño" a "que escale solo" te multiplica mínimo por cinco la factura, si partes de una B1.

Hay dos cosas más que suelen decidir la partida en empresas medianas. La primera es el cumplimiento: traen certificaciones, auditorías y contratos que te facilitan muchísimo cumplir con ISO 27001, SOC 2, PCI DSS, HIPAA o el RGPD. Si tu cliente te pide papeles, aquí los hay. Eso sí, contratar Azure no convierte tu aplicación en conforme por arte de magia: hay un modelo de responsabilidad compartida y parte de los controles siguen siendo tuyos. Pero partes con medio camino andado, que no es poco. La segunda es que si algún día necesitas jugar en serio, tienes Kubernetes y compañía sin cambiar de casa.

Y una reflexión que conviene hacerse: esto va sobrado para la inmensa mayoría de los desarrollos. Nos comemos mucho la cabeza montando arquitecturas para millones de usuarios cuando lo difícil es conseguir los primeros mil.

Nivel 3: el azúcar

Aquí están Vercel, Netlify, Cloudflare, Render, y compañía. Se parecen todos en esto:

• Tienen un plan gratuito para empezar.
• Desplegar es absurdamente fácil: conectas el repo y listo.
• Escalan de maravilla. Un pico que te tumbaría un VPS lo absorbe el CDN sin despeinarse. En la parte dinámica ya dependes de los límites de tu plan y, sobre todo, de si tu base de datos aguanta.
• Suelen traerte resueltos DDoS, CDN, certificados, copias de seguridad, entornos de preview por rama... (mira bien qué entra en tu plan, que no todos traen lo mismo).
• Van como un tiro.
• Y de primeras el precio parece regalado para todo lo que dan.

Aquí viene lo curioso: muchos corren por encima de AWS, Azure o GCP (Cloudflare es la excepción gorda: monta su propia red y corre todos sus servicios en sus más de 300 centros de datos). Y si le pagan a un proveedor grande, ¿cómo pueden ofrecerte un precio de entrada tan bajo? Pues porque tienen equipos dedicados a exprimir esos recursos y a compartirlos entre miles de clientes. Funciona de maravilla mientras encajes en el molde. El problema es cuando te sales.

Dónde se sale de madre

Si estás en el caso de uso perfecto, por 20 o 40 € al mes lo tienes todo resuelto. Fuera de ahí, hay unos cuantos sitios por los que la factura se puede disparar, dependiendo del proveedor, te puedes encontrar con estas sorpresas:

Te cobran por persona. En algunos, el plan incluye una sola cuenta con permiso para desplegar. Cada usuario adicional con esos permisos son otros 20 $ al mes. Un equipo de cinco desarrolladores con esos permisos son 100 $ antes de servir una sola visita.

Te cobran por proyecto. Ejemplo real: tu base de datos en la nube te recomienda restringir el acceso a una lista de IPs autorizadas. Para tener IP fija de salida, hay proveedores de azúcar que cobran 100 $ al mes por cada proyecto. Has leído bien, por proyecto. En un proveedor grande, un NAT Gateway con su IP fija ronda los 35-50 € al mes de coste base, y lo comparten todas las aplicaciones conectadas a esa misma red virtual (más los datos procesados, que también se facturan).

Te cobran por conceptos que no estás acostumbrado a medir. No pagas "un servidor", pagas una lista: CPU activa, memoria, peticiones, ancho de banda, builds, logs... Hay que leerlas con lupa. Por ejemplo, hay proveedores que te cobran la memoria también mientras tu petición está esperando a la base de datos. Traducido: una consulta lenta o un servidor de base de datos que esté en otro datacenter te sube la factura aunque tu código esté bien optimizado.

El ancho de banda es otro mundo. ¿Te acuerdas del VPS de 7 €? Pues OVH lo vende con "tráfico ilimitado" en todos sus planes: lo que te limitan es la velocidad del enlace (de 500 Mb/s a 3 Gb/s según el plan), no los gigas que muevas. En el azúcar, pasado el cupo incluido, se paga por giga. Si sirves vídeo, descargas o catálogos con muchas imágenes, esta línea puede acabar siendo la mitad de tu factura.

Si apuestas por serverless, hereda su letra pequeña. La caché en memoria deja de ser compartida y desaparece cuando muere la instancia, el pooling de conexiones se complica y puedes acabar multiplicando las conexiones contra tu base de datos, hay arranques en frío que se notan, y a veces no puedes desplegar contenedores Docker.

Y si apuestas por instancias siempre encendidas, lee también la letra pequeña: dependiendo del proveedor, puedes encontrarte con sorpresas como estas:

• La escalera de planes engaña: subes del gratuito al de pago por unos euros y puedes pensar que con esa cuota ya está incluido el alojamiento. Pues no: en Render, la cuota del workspace determina las funcionalidades y los límites del plan, pero el cómputo y el almacenamiento de cada servicio se facturan aparte.

• Pagas por instancia encendida, no por uso. Tu factura no crece con las visitas, crece con el número de servicios. Si has partido el backend en seis microservicios, son seis facturas aunque no reciban tráfico.

• La región se elige al crear el servicio y ahí se queda. Render lo dice con todas las letras: no permite cambiar la región de un servicio existente. Si el cliente te pide de repente que los datos estén en Europa, toca crear el servicio de cero y migrar a mano.

El ecosistema engancha. Los complementos están muy bien y resuelven mucho, pero cada uno que adoptas es una pieza que tendrás que reconstruir si algún día te vas. No es un candado contractual, es un candado de arquitectura, y esos son los que de verdad cuestan.

Y ojo con el cumplimiento. Que un proveedor tenga centro de datos en Europa no siempre garantiza que tus datos se queden en Europa. Sin ir más lejos, Vercel reconoce en en el apartado 13.1 de us contrato de tratamiento de datos que sus principales instalaciones de procesamiento están en Estados Unidos y que puede tratar los datos en otros países donde opere Vercel o alguno de sus subencargados. Estas transferencias pueden contar con mecanismos legales como las cláusulas contractuales tipo, pero si trabajas con requisitos normativos o de residencia del dato, debes comprobarlo por escrito y no darlo por supuesto.

Y con el DNS pasa algo parecido. Cloudflare, por ejemplo, te pide apuntarle los nameservers del dominio; mantener tu DNS actual y enrutar solo algunos subdominios requiere plan Business o Enterprise. Con un cliente que tenga su DNS corporativo intocable, eso puede ser un no rotundo.

Si tu negocio principal está en España, imagina que tu web deja de cargar para parte de tus usuarios durante los partidos de fútbol.** ¿A que suena a cachondeo? Pues no lo és, mira lo que le está pasando a Cloudflare, y tiene pinta de que al menos hasta 2027 no se va a arreglar, y explicale eso a un cliente al que le has montado un e-commerce y que se queda sin ventas la franja semanal de máxima compra.

¿Significa esto que el azúcar es malo? En absoluto. Para muchísimos proyectos es la mejor opción que hay. Solo hay que saber cómo te van a facturar antes de meterte, porque cuanto más tiempo pase, más caro te puede costar salir.

---

Antes de elegir: que tu aplicación consuma poco

Esto es lo primero, y va antes que la decisión de hierro, proveedor de cloud grande, o azúcar. Da igual dónde despliegues: si tu aplicación consume lo mismo que un mechero, todo es más barato y más fácil.

• ¿Es un sitio de contenido? Si no cambia a menudo, con tecnologías como Astro, puedes tirar de generación estática y servir HTML y JS puros, y puedes usar un CMS headless detrás para actualizar contenido y redesplegar. Va como un tiro y casi no consume.

• ¿Necesitas SSR? Los CMS headless suelen darte los assets ya en un CDN. Para el resto —principalmente los textos—, cachea o utiliza una solución como Dynamic Snapshot, que permite servir el contenido directamente desde un snapshot cargado en memoria.

• No ates la sesión a la instancia. El problema no es guardarla en el servidor, es guardarla en la memoria o el disco local de una máquina concreta: eso es lo que te impide escalar hacia los lados. Una cookie firmada —y cifrada, si lleva algo sensible— o un Redis compartido son opciones perfectamente válidas.

• Cachea todo lo que puedas, y si creces, que la caché sea distribuida.

Una web ligera cambia los números de verdad. Si consigues que tus páginas pesen la mitad, tu factura de tráfico también se parte por la mitad, despliegues donde despliegues.

La chuleta

Ojo, esto es una orientación a muy alto nivel, no una receta. La decisión de verdad depende mucho del tipo de producto que estés construyendo, de las restricciones que tengas —normativa, exigencias del cliente, presupuesto, plazos— y de lo que ya sepa hacer tu equipo. Tómalo como punto de partida, pero haz tus propios números antes de decidir.

Antes de la tabla, la pregunta que decide más que ninguna otra: ¿tienes a alguien que sepa de infraestructura y tenga tiempo para dedicarle? Porque un VPS de 7 € y un App Service de 134 € pueden servir para lo mismo, y lo que cambia entre uno y otro es quién hace el trabajo. Si ese "alguien" no existe, la columna de la izquierda es la tuya, aunque los números de la derecha sean más bonitos.

Un apunte sobre la primera fila, que es la que más sorprende: con una web razonablemente ligera, el plan de entrada de un proveedor de azúcar aguanta mucho más tráfico del que la gente imagina. Con unos supuestos normalitos —unas 20 peticiones al CDN por página y dos páginas y media por visita— el cupo de peticiones incluido en un plan de pago típico da para del orden de 200.000 visitas al mes. Ojo, que ahí solo estamos mirando las peticiones: en una aplicación real habría que comprobar también transferencia, funciones, base de datos y cómo se concentran los picos. Sirve para situarte, no como garantía.

En resumen

No hay ganador. Hay un nivel que encaja con dónde estás hoy.

Si estás empezando, el azúcar te deja centrarte en el producto, que es lo único que importa cuando todavía no tienes clientes. Si ya tienes tráfico estable y previsible, los números empiezan a favorecer al VPS. Y si te piden certificaciones y controles corporativos, los grandes te facilitan mucho el camino.

Lo importante es que la decisión la tomes con los números delante y sabiendo por qué conceptos te cobran. La sorpresa desagradable casi nunca es que el proveedor sea caro: es que estabas pagando por algo que no te esperabas.