¿Cuánto cuesta realmente desplegar una aplicación en Internet? Hay una pregunta que parece sencilla y que, cuando intentamos responderla con cierta precisión, d...
Hay una pregunta que parece sencilla y que, cuando intentamos responderla con cierta precisión, deja de serlo rápidamente:
¿Cuánto cuesta poner una aplicación en Internet?
Como ya comenté en el primer artículo sobre cómo está desarrollada esta web comenté que mi primer proceso de despliegue a producción para esta misma web estaba basado en una Static Frontend (únicamente una web que se encargaba de mostrar contenido estático haciendo uso de alguna API de terceros de forma puntual) alojada en Netlify.
La respuesta habitual suele ser algo parecido a esto: un VPS, un dominio y poco más. Si utilizamos servicios gratuitos para el repositorio y los despliegues, quizá podamos tener una aplicación funcionando por unos pocos euros al mes.
Y técnicamente no es una respuesta incorrecta.
El problema es que tampoco es una respuesta especialmente útil.
Porque una aplicación desplegada en Internet no es solamente un proceso ejecutándose en un servidor. Es una pequeña cadena de servicios y decisiones: DNS, TLS, red, almacenamiento, automatización, backups, seguridad, monitorización y, sobre todo, capacidad disponible aunque durante buena parte del día nadie esté utilizando la aplicación.
En mi caso, una aplicación relativamente sencilla utiliza un VPS de Contabo como infraestructura principal, GitHub Actions para automatizar los despliegues, un dominio gestionado mediante un registrador, Cloudflare delante de la aplicación y Cloudflare R2 para almacenamiento de objetos.
No es una arquitectura especialmente compleja. Precisamente por eso resulta interesante.
Permite hacerse una pregunta más útil que "¿cuánto cuesta mi servidor?":
¿Cuánto cuesta realmente mantener una aplicación disponible en Internet?
Empecemos por lo evidente.
Tenemos un VPS. Pagamos una cantidad fija cada mes y obtenemos una determinada cantidad de CPU, memoria, almacenamiento y transferencia de red.
Es un modelo bastante cómodo porque convierte la infraestructura en una cantidad relativamente predecible.
Si el servidor cuesta X euros al mes, sabemos que, independientemente de que nuestra aplicación reciba diez peticiones o diez millones, la factura del servidor no cambia de forma inmediata.
Pero hay algo importante escondido aquí.
Estamos comprando capacidad, no consumo.
Si nuestro VPS tiene 4 vCPU y durante el 95 % del tiempo utiliza el equivalente a media CPU, no estamos pagando por media CPU. Estamos pagando por tener disponibles cuatro.
Esto introduce uno de los conceptos fundamentales de la economía de la infraestructura: utilización.
Una máquina infrautilizada no necesariamente es una mala decisión. De hecho, tener margen puede ser exactamente lo correcto. Una aplicación que funciona constantemente al 90 % de CPU tiene poco espacio para absorber un pico de tráfico.
La pregunta no es:
"¿Estoy utilizando todos los recursos que pago?"
La pregunta correcta es:
"¿Cuánto valor obtengo del margen que estoy pagando?"
Ese margen es capacidad de absorción. Es lo que permite que una campaña, un proceso inesperadamente costoso o simplemente un aumento de tráfico no conviertan un servidor normal en un cuello de botella.
En otras palabras, parte de lo que pagamos no es capacidad utilizada.
Pagamos capacidad disponible.
La ventaja de un VPS pequeño es que la abstracción es mínima.
Tenemos una máquina virtual y somos responsables de prácticamente todo lo que ocurre dentro.
Sistema operativo. Actualizaciones. Firewall. Docker, si lo utilizamos. Procesos. Logs. Certificados, dependiendo de cómo hayamos diseñado la arquitectura. Backups. Monitorización. Recuperación ante fallos.
Esto tiene una consecuencia interesante:
el precio del VPS no representa el coste de la infraestructura.
Representa únicamente el precio que nos cobra el proveedor por una parte de ella.
El resto lo pagamos con nuestro tiempo.
Y el tiempo es probablemente el recurso más caro de toda esta arquitectura.
Supongamos que el VPS cuesta 10 € al mes.
Podríamos decir que nuestra infraestructura cuesta 120 € al año.
Pero si una actualización problemática nos obliga a dedicar tres horas a investigar por qué el servicio ha dejado de arrancar, la contabilidad real acaba de cambiar.
Esto no significa que debamos convertir cada minuto de nuestra vida en euros. Sería absurdo.
Pero sí conviene reconocer que existe un coste operativo que no aparece en ninguna factura.
Es una de las razones por las que comparar únicamente precios entre proveedores de infraestructura puede resultar engañoso.
El dominio probablemente sea uno de los componentes más baratos de toda la arquitectura.
Y, sin embargo, tiene una característica que lo hace mucho más importante que su precio.
Es nuestra identidad.
El servidor puede cambiar. El proveedor puede cambiar. Incluso Cloudflare puede desaparecer de la arquitectura.
El dominio permanece.
Por eso un dominio es un ejemplo curioso de infraestructura: técnicamente es sencillo, económicamente es barato y conceptualmente es crítico.
Podemos cambiar de VPS sin que el usuario tenga que enterarse.
Podemos cambiar de proveedor de almacenamiento.
Podemos cambiar nuestro sistema de CI/CD.
Pero si perdemos el dominio, hemos perdido una parte fundamental de la aplicación.
Esto introduce otra dimensión del coste: el coste de dependencia.
No todas las dependencias tienen el mismo impacto.
Una dependencia que podemos reemplazar en una tarde no tiene el mismo riesgo que otra cuya pérdida implica que nuestros usuarios dejan de encontrar el servicio.
En esta arquitectura Cloudflare ocupa una posición especialmente interesante.
Porque desde fuera puede parecer simplemente "el DNS".
Pero DNS es solamente una parte de lo que puede hacer.
Cloudflare puede actuar como DNS autoritativo, terminador TLS, proxy inverso, CDN y capa de protección frente a determinados tipos de tráfico malicioso.
Y aquí aparece algo que me parece particularmente interesante:
no todo lo que mejora una arquitectura tiene que ser un servidor adicional.
Durante mucho tiempo pensamos en infraestructura como una colección de máquinas:
Usuario
↓
Servidor
↓
Base de datos
La infraestructura moderna es bastante más abstracta:
┌── DNS
├── TLS
Usuario → Cloudflare├── Proxy
├── CDN
└── Protección
↓
VPS
↓
Aplicación
↓
R2
Cloudflare está absorbiendo una serie de responsabilidades que, de otro modo, tendríamos que implementar o mantener nosotros.
Y eso nos lleva a una idea importante:
El precio de un servicio de infraestructura no debería medirse únicamente por lo que cuesta, sino también por cuánto trabajo evita.
Imaginemos que decidimos prescindir de Cloudflare.
No significa necesariamente que tengamos que pagar más dinero.
Pero probablemente tengamos que asumir más responsabilidades.
Gestión de certificados.
Configuración del tráfico.
Protección ante determinados patrones de abuso.
Caching.
Rate limiting.
DNS.
Y probablemente alguna estrategia adicional para absorber tráfico que no queremos que llegue directamente a nuestro servidor.
Podemos hacerlo.
La cuestión es si queremos hacerlo.
Esta diferencia entre poder implementar algo y tener sentido implementarlo es una de las decisiones que más separa una arquitectura madura de una arquitectura construida únicamente alrededor de la capacidad técnica.
Porque prácticamente todo puede construirse.
La pregunta interesante es:
¿Deberíamos construirlo nosotros?
El almacenamiento de objetos introduce otra dimensión.
Una aplicación puede almacenar archivos directamente en el disco del VPS. Para empezar es sencillo y, en algunos casos, perfectamente razonable.
Pero entonces nuestro almacenamiento queda acoplado al servidor.
Si el VPS desaparece, desaparecen los archivos.
Si necesitamos migrar, tenemos que moverlos.
Si tenemos varias instancias, necesitamos decidir cómo comparten esos datos.
Aquí aparece R2.
La idea fundamental de un object storage es separar el almacenamiento de objetos de la máquina que ejecuta la aplicación.
La aplicación procesa.
El almacenamiento almacena.
Parece una distinción trivial, pero arquitectónicamente es importante.
Aplicación
│
├── código
├── lógica
└── datos temporales
↓
Object Storage
│
├── imágenes
├── documentos
├── backups
└── otros objetos
Hemos introducido una dependencia más.
Pero también hemos reducido otra.
La aplicación ya no necesita saber dónde está físicamente el archivo.
Eso es desacoplamiento.
Y el desacoplamiento casi siempre tiene un precio.
A veces ese precio es dinero.
Otras veces es latencia.
Otras veces es complejidad.
Pero normalmente merece la pena cuando reduce el acoplamiento entre componentes.
Una de las trampas al hablar de object storage es fijarse exclusivamente en el precio por gigabyte.
"Guardar un terabyte cuesta X."
Bien.
Pero un sistema de almacenamiento no existe para guardar datos. Existe para que alguien pueda acceder a ellos.
Y ahí aparece uno de los conceptos económicos más importantes de las arquitecturas cloud:
egress.
Guardar datos y transferir datos son operaciones diferentes.
Podemos tener un almacenamiento muy barato y una aplicación que genera grandes costes simplemente porque mueve enormes cantidades de información.
Por eso, cuando analizo el coste de una arquitectura, intento pensar en tres dimensiones diferentes:
El tamaño del disco es solamente una parte de la ecuación.
Hay otro componente que a primera vista parece gratuito porque no forma parte del runtime de la aplicación.
GitHub Actions.
Nuestro código está en GitHub. Hacemos un commit. Se ejecutan tests. Construimos la aplicación. Generamos una imagen, quizá. Y finalmente desplegamos en el VPS.
Desde nuestra perspectiva hemos hecho simplemente:
git push
Pero detrás puede haber bastantes cosas:
git push
↓
CI
↓
Tests
↓
Build
↓
Artifact / Image
↓
Deploy
↓
Restart
↓
Health check
Cada ejecución consume recursos.
CPU.
Memoria.
Tiempo.
Almacenamiento temporal.
Y, sobre todo, automatiza trabajo que anteriormente tendría que hacer una persona.
Por eso tampoco me parece demasiado interesante preguntar si GitHub Actions "cuesta cero".
La pregunta interesante es:
¿Cuánto trabajo manual ha eliminado?
Un pipeline que tarda cinco minutos y se ejecuta cien veces al mes está consumiendo recursos.
Pero si esos cien despliegues antes requerían intervención manual, probablemente estemos comprando una de las cosas más valiosas de cualquier sistema de ingeniería:
repetibilidad.
Un buen pipeline no solamente despliega.
Reduce incertidumbre.
Si cada despliegue sigue exactamente los mismos pasos, podemos razonar sobre él.
Si además tenemos tests automáticos, comprobaciones y rollback, podemos cometer errores sin que cada error implique necesariamente una incidencia grave.
Esto tiene un valor económico difícil de meter en una hoja de cálculo.
Un despliegue automatizado reduce el coste marginal de publicar una nueva versión.
El primer despliegue puede haber requerido mucho trabajo.
El número 500 debería costar prácticamente lo mismo que el número 499.
Ese es uno de los grandes beneficios de la automatización:
convertir una operación en un proceso reproducible.
Hasta ahora hemos hablado de infraestructura.
Pero todavía falta una parte.
¿Quién se entera si el VPS deja de responder?
¿Tenemos backups?
¿Se prueban esos backups?
¿Tenemos alertas?
¿Sabemos cuánto tardaríamos en reconstruir el servidor?
¿Tenemos documentado el procedimiento?
¿Podemos desplegar desde cero?
¿Tenemos logs suficientes para investigar un error?
¿Sabemos cuánto tiempo podemos permitirnos estar caídos?
Estas preguntas no aparecen en la factura de Contabo.
Pero forman parte del coste de operar una aplicación.
Aquí aparece un concepto fundamental:
RTO y RPO.
El Recovery Time Objective responde a cuánto tiempo podemos tardar en recuperar el servicio.
El Recovery Point Objective responde a cuántos datos podemos permitirnos perder.
Una aplicación personal puede tener un RTO de varias horas y un RPO de un día.
Una aplicación crítica puede necesitar minutos o incluso segundos.
Y las decisiones de infraestructura cambian completamente dependiendo de esas respuestas.
Una única VPS es una arquitectura sencilla.
También es un Single Point of Failure.
Si esa máquina desaparece, nuestra aplicación desaparece.
Podemos añadir una segunda instancia.
Después un balanceador.
Después una base de datos replicada.
Después almacenamiento redundante.
Después varias zonas de disponibilidad.
Y de repente hemos convertido una aplicación que costaba unos pocos euros al mes en una arquitectura que cuesta cientos.
¿Hemos mejorado la arquitectura?
Sí.
¿Necesitábamos hacerlo?
No necesariamente.
Este es probablemente uno de los errores más frecuentes cuando se habla de arquitectura cloud:
confundir una arquitectura técnicamente superior con una arquitectura adecuada.
La alta disponibilidad tiene sentido cuando el coste de una interrupción es superior al coste de evitarla.
Si nuestra aplicación genera 20 € al mes y perderla durante una hora tiene un coste económico prácticamente nulo, quizá no necesitemos Kubernetes, múltiples regiones y una base de datos distribuida.
No porque esas tecnologías sean malas.
Sino porque el problema que resuelven no existe todavía.
Cada componente nuevo añade una línea en nuestro diagrama.
Pero también añade:
Podemos llamar a esto complejidad operacional.
Y es uno de los costes más importantes y menos visibles de una arquitectura.
Por eso una arquitectura pequeña puede ser extraordinariamente buena.
No porque tenga menos componentes.
Sino porque tiene solamente los componentes necesarios.
Si simplificamos la arquitectura, tenemos algo parecido a esto:
Componente | Tipo de coste |
|---|---|
VPS Contabo | Fijo |
Dominio | Anual |
Cloudflare | Variable / según servicio |
R2 | Variable |
GitHub Actions | Según uso / plan |
Tiempo de mantenimiento | Invisible |
Backups | Variable |
Monitorización | Variable |
Conocimiento técnico | Invisible |
Las primeras cinco líneas son relativamente sencillas de calcular.
Las últimas cuatro son mucho más interesantes.
Porque son precisamente las que solemos ignorar.
Podemos plantear una fórmula muy sencilla:
Coste total = infraestructura + servicios + operación + riesgo
La primera parte es fácil.
La segunda también.
La tercera requiere conocer cuánto tiempo dedicamos.
La cuarta es más difícil.
El riesgo es el coste esperado de aquello que puede salir mal.
Si tenemos una probabilidad determinada de sufrir una incidencia y sabemos cuánto nos costaría recuperarnos de ella, podemos incluso aproximarlo:
coste esperado del riesgo = probabilidad × impacto
No necesitamos construir un modelo financiero sofisticado para una aplicación pequeña.
Pero pensar de esta manera cambia la conversación.
Una copia de seguridad no es solamente "otro servicio que cuesta dinero".
Es una forma de comprar una reducción de riesgo.
Un segundo servidor no es simplemente "otro VPS".
Es una forma de reducir el impacto de un fallo.
Cloudflare no es simplemente "un proxy".
Es una forma de delegar determinadas responsabilidades de red y seguridad.
Y GitHub Actions no es simplemente "el pipeline".
Es una forma de reducir el coste y el riesgo del proceso de entrega.
Si hablamos exclusivamente de dinero, probablemente sorprendentemente poco.
Una aplicación pequeña puede funcionar con una infraestructura de unos pocos euros o unas pocas decenas de euros al mes.
Pero esa cifra es engañosa si la interpretamos como el coste completo.
El coste real depende de qué estamos intentando conseguir.
Una aplicación personal que puede estar caída unas horas tiene unas necesidades.
Una aplicación que genera ingresos tiene otras.
Un servicio utilizado por miles de personas tiene otras.
Y un sistema del que depende un proceso crítico tiene otras completamente diferentes.
Por eso quizá la pregunta correcta no sea:
"¿Cuánto cuesta desplegar una aplicación?"
Sino:
"¿Cuánto estoy dispuesto a pagar para que esta aplicación siga funcionando cuando algo salga mal?"
Ahí empieza realmente la ingeniería de infraestructura.
Existe una tentación natural cuando conocemos el precio de cada componente: intentar reducirlo todo.
Buscar el VPS más barato.
Eliminar servicios.
Compartir recursos.
Reducir backups.
Prescindir de monitorización.
Mantenerlo todo en una única máquina.
Y, desde el punto de vista de la factura mensual, probablemente funcione.
Pero estamos optimizando una métrica.
No necesariamente el sistema.
Si conseguimos ahorrar cinco euros al mes pero necesitamos dos horas adicionales para resolver cada incidencia, hemos realizado una optimización bastante discutible.
El coste no desaparece.
Simplemente ha cambiado de columna.
Hay algo que me parece especialmente importante cuando trabajamos con aplicaciones pequeñas.
La infraestructura no debería convertirse en el producto.
Es fácil pasar de:
"Necesito desplegar esta aplicación."
a:
"Voy a diseñar una plataforma de despliegue completamente automatizada, observable, redundante y multi-región."
Y terminar dedicando más tiempo a mantener la infraestructura que a desarrollar la aplicación que realmente queríamos construir.
La tecnología debe estar al servicio del problema.
No al revés.
Un VPS con un buen pipeline, backups, observabilidad razonable y una arquitectura sencilla puede ser una solución mucho más profesional que una infraestructura espectacular que nadie sabe mantener.
La madurez técnica no consiste necesariamente en utilizar más tecnología.
A menudo consiste en saber cuánta tecnología no necesitamos.
Al final, mi aplicación tiene una factura relativamente pequeña.
Un VPS.
Un dominio.
Algún servicio adicional.
Almacenamiento.
Automatización.
No estamos hablando de una infraestructura de miles de euros al mes.
Y precisamente ahí está lo interesante.
Porque cuando el coste monetario es pequeño, empiezan a verse con mucha más claridad los otros costes.
El tiempo que cuesta mantener el sistema.
El conocimiento necesario para recuperarlo.
El riesgo de una dependencia.
El coste de una caída.
El coste de perder datos.
El coste de una arquitectura demasiado compleja.
Y también el valor de todo lo que hemos automatizado.
Como conclusión desde mi experiencia desplegar en la mayoría de casos para perfiles amateur es prácticamente gratuito, nadie nace aprendido y acoplarse a soluciones de terceros es un proceso por el que pasamos todos los desarrolladores cuando comenzamos. Como promulga el desarrollo Agile lo más importante es intentar captar feedback lo más rápido posible sobre lo se pretende entregar, por lo que diseñar una infraestructura "profesional" puede convertirse en un gran obstáculo en nuestro proceso de captación de valor y mucho más sino contamos con una extensa formación u experiencia que nos proporcionen los criterios adecuados para determinar qué es una buena infraestructura, el proceso de CI/CD más óptimo y el mejor sistema para asegurar que el DEVex no interfiere en nuestra capacidad creativa.
Última actualización: 23 de octubre de 2026
