Hay una conversación que se repite en foros de desarrollo con una regularidad sospechosa. Alguien publica una captura de su factura de nube, el importe tiene un dígito de más, y la pregunta siempre es la misma: no entiendo de dónde salió esto.
Las respuestas también se parecen. Casi nunca el problema fue el servidor. Fue la transferencia de datos, un registro que nadie apagó, o un entorno de prueba encendido desde marzo.
Por qué la estimación falla siempre en la misma dirección
Estimar el costo de un servidor es fácil, porque el precio está publicado y se multiplica por los meses. Ese cálculo es el que todo el mundo hace, y es el que casi nunca falla.
Lo que falla es todo lo que no se estimó, porque se cobra por unidades que nadie sabe cuántas va a consumir. Nadie tiene una intuición de cuántos gigabytes salen de su aplicación al mes, ni de cuántas peticiones recibe un almacenamiento de archivos, ni de cuánto ocupa un registro de eventos al cabo de un año.
El resultado es una asimetría constante: la parte estimada sale bien y la no estimada sale cara. Por eso la factura del primer mes suele cuadrar y la del segundo o tercero no.
La transferencia de salida, el cargo que sorprende a todos
Si hay un concepto que explica la mayoría de las facturas inesperadas, es este. Meter datos en la nube suele ser gratis. Sacarlos, no.
Cada imagen que sirve tu aplicación, cada respuesta de la API, cada archivo que un usuario descarga son bytes que salen y se facturan. Con poco tráfico es irrelevante. Cuando el proyecto crece, o cuando alguien enlaza un archivo tuyo desde un sitio con visitas, deja de serlo.
Lo que lo vuelve difícil de anticipar es que el cargo no guarda relación con lo que cuesta almacenar ese archivo. Un vídeo de cien megabytes cuesta céntimos al mes guardado, y puede costar mucho más que eso si se descarga mil veces.
Toma el peso medio de una página o respuesta de tu aplicación, multiplícalo por las visitas mensuales que esperas y compáralo con el precio por gigabyte de salida de tu proveedor.
Es una cuenta de dos minutos que casi nadie hace, y es la que convierte la transferencia de un misterio en una cifra que cabe en el presupuesto.
La forma habitual de reducirlo es poner una red de distribución de contenido delante, que sirve las copias desde su propia caché y suele cobrar la salida bastante más barata. No elimina el cargo: lo mueve a un sitio donde cuesta menos.
Los cinco cargos que no aparecen en la estimación inicial
Más allá de la transferencia, hay un grupo de conceptos que comparten una característica: son baratos por unidad y se consumen en cantidades que nadie cuenta.
- Peticiones al almacenamiento. No pagas solo por guardar archivos, también por cada operación de lectura o escritura. Una aplicación que consulta miles de objetos pequeños puede gastar más en peticiones que en almacenamiento.
- Registros y monitoreo. Guardar todo lo que el sistema escribe parece prudente hasta que el volumen se factura. Es uno de los cargos que más crece solo, porque nadie revisa cuánto se está guardando ni por cuánto tiempo.
- Entornos que no se apagan. Una copia de producción creada para probar algo en marzo sigue facturando en noviembre. Es el gasto más fácil de eliminar y el más frecuente.
- Direcciones IP y recursos reservados. Varios proveedores cobran por recursos asignados aunque no estén en uso, precisamente para que no se acaparen.
- Copias de seguridad e instantáneas. Se acumulan por diseño. Sin una política que borre las antiguas, el costo crece de forma indefinida sobre datos que ya nadie va a restaurar.
Ninguno es caro visto de uno en uno, y ese es exactamente el motivo de que ninguno se estime.
Cómo estimar de verdad antes de escalar
Una estimación útil no necesita ser exacta, necesita tener las unidades correctas. El método que funciona es traducir el crecimiento esperado a las cantidades que el proveedor factura.
En lugar de pensar en usuarios, piensa en lo que cada usuario provoca. Si esperas diez mil visitas al mes, eso son diez mil cargas de página, cada una con su peso en datos de salida, sus peticiones al almacenamiento, sus consultas a la base de datos y sus líneas de registro.
Con esas cuatro cifras aproximadas y la página de precios del proveedor delante, sale una estimación que se equivoca por un margen razonable en lugar de por un factor de diez.
Y conviene hacerla tres veces: para el tráfico de hoy, para el que esperas en un año, y para diez veces ese. El tercer escenario no es pesimismo, es la comprobación de que un pico inesperado no produce una factura que no puedas pagar.
Las tres medidas que evitan la sorpresa
Estimar bien ayuda, pero lo que de verdad protege es enterarse a tiempo. Tres cosas, en orden de importancia:
Un aviso de gasto, configurado antes de desplegar. Todos los proveedores grandes permiten avisar cuando el gasto acumulado del mes cruza un umbral. Es la diferencia entre descubrir un problema el día cuatro y descubrirlo en la factura.
Un tope donde el proveedor lo permita. En los modelos que cobran por ejecución, limitar la concurrencia evita que un error en bucle facture sin freno. Un tope que frena el servicio es peor que un servicio lento, pero mucho mejor que una factura impagable.
Etiquetas desde el primer día. Marcar cada recurso con el proyecto y el entorno al que pertenece cuesta un minuto al crearlo. Sin eso, una factura con cuarenta líneas es un enigma, y averiguar qué se puede apagar lleva una tarde.
El gasto que crece sin que nadie toque nada
Hay una categoría de cargo que merece atención aparte, porque no responde al tráfico ni a ninguna decisión del equipo. Crece por acumulación, y esa es la razón de que pase desapercibido.
Los registros de un sistema en marcha se escriben todos los días. Las copias de seguridad se generan según lo programado. Las versiones antiguas de los archivos quedan guardadas si el almacenamiento tiene el historial activado. Ninguna de esas cosas es un error, y todas suman.
La diferencia con los demás cargos es que aquí el uso no aumenta: aumenta el tiempo. Un proyecto con exactamente los mismos usuarios que hace un año puede pagar bastante más solo porque lleva un año generando datos que nadie borra.
La regla que dice cuánto tiempo se guarda cada cosa antes de eliminarse: treinta días de registros, siete copias diarias, cuatro semanales.
Es una línea de configuración en casi cualquier proveedor, y es lo único que convierte un gasto que crece sin límite en uno estable.
Conviene decidirla pronto, aunque sea de forma aproximada, porque aplicarla más tarde obliga a revisar qué se puede borrar sin perder algo que haga falta. Al principio esa pregunta se responde en un minuto; con dos años de acumulación encima, no.
Por qué el mismo servicio cuesta distinto en cada proveedor
Comparar precios entre nubes es más difícil de lo que parece, y no por falta de transparencia: es que cada una agrupa los conceptos de forma distinta.
Un proveedor incluye cierta transferencia de salida en el precio de la máquina y otro la factura aparte desde el primer gigabyte. Uno cobra las peticiones al almacenamiento y otro las regala, pero cobra más por el espacio. La comparación por el precio de la máquina, que es la que casi todo el mundo hace, deja fuera justo las partidas donde está la diferencia.
La forma de compararlos que sí funciona es construir el mismo escenario en las calculadoras oficiales de cada uno, con las mismas cifras de tráfico, almacenamiento y salida, y mirar solo el total. Lleva veinte minutos y suele cambiar la intuición de partida.
Conviene además mirar el precio del tramo siguiente, no solo el del actual. Algunos proveedores son muy baratos al principio y suben con fuerza al cruzar cierto umbral, que es exactamente el momento en que menos ganas se tienen de migrar.
Qué hacer cuando la factura ya llegó alta
Si la sorpresa ya ocurrió, el orden en que se revisa importa, porque casi siempre el grueso está en pocas líneas.
- Ordena la factura por importe, de mayor a menor. Lo habitual es que dos o tres conceptos expliquen la mayor parte del total, y el resto sea ruido que no vale la pena tocar todavía.
- Compara con el mes anterior, concepto por concepto. Lo que importa no es qué es caro, sino qué cambió. Un cargo alto y estable estaba previsto; uno que se duplicó, no.
- Busca lo que factura sin usarse. Entornos de prueba, discos sin conectar, direcciones reservadas, copias de bases de datos que ya no existen. Ahí está el ahorro inmediato y sin riesgo.
- Deja el rediseño para el final. Cambiar la arquitectura para ahorrar es lo más caro en tiempo y lo último que conviene intentar, después de haber apagado lo que sobra.
Y una vez resuelto, configura el aviso que no estaba. La factura alta es cara una vez; no enterarse a tiempo es caro todos los meses.
Qué pasa cuando la infraestructura la propone una IA
Pedirle a un modelo que monte la infraestructura de un proyecto produce, casi siempre, una arquitectura correcta y más cara de lo necesario. No por error: porque optimiza para que funcione y escale, que es lo que se le pidió, y nadie mencionó el presupuesto.
Aparecen entonces componentes que un proyecto pequeño no necesita todavía: una caché gestionada, un balanceador, varias zonas de disponibilidad, una base de datos con réplica. Cada uno tiene su justificación técnica y su cargo mensual.
La corrección es simple y hay que hacerla explícita, porque no se deduce sola. Di cuánto puedes pagar al mes y pide que te diga qué componentes son imprescindibles para arrancar, cuáles se pueden añadir después, y cuánto cuesta cada uno por separado.
Esa última parte es la que más rinde. Un total mensual no se puede negociar, pero una lista con el costo de cada pieza sí, porque deja ver cuáles se pueden posponer sin riesgo.
Revisar la factura como una tarea, no como una reacción
La factura de nube es el único documento que dice qué está encendido de verdad, frente a lo que crees que está encendido. Leerla una vez al mes, con calma, es una práctica más útil que cualquier estimación previa.
Basta con mirar tres cosas: qué concepto creció respecto al mes pasado, qué recursos hay que ya nadie usa, y si el total sigue guardando relación con el tráfico real. Cuando un cargo crece sin que el uso haya crecido, casi siempre hay algo acumulándose solo.
Y si el proyecto todavía no tiene usuarios, esa revisión es aún más importante, porque cualquier cifra distinta de casi cero significa que algo está encendido sin motivo.