Budgeting

Resumen

Esta guía de estudio independiente explica cómo se presupuesta y controla el gasto en la nube para la certificación LFCA.

No está afiliada ni avalada por la Linux Foundation ni por ningún proveedor.

Los modelos de precio se presentan de forma conceptual, sin importes, porque las tarifas cambian según región, servicio y momento. Los enlaces oficiales permiten consultar valores vigentes.

Los únicos números con forma de importe que aparecen más abajo pertenecen a ejemplos de cálculo: cifras inventadas y redondeadas para practicar el método, no tarifas de ningún proveedor.

Presupuestar no es predecir una factura y olvidarse, sino entender qué se paga, cómo varía el consumo, quién lo genera y qué decisiones reducen el coste sin degradar el servicio. FinOps conecta finanzas, ingeniería y operación.

Objetivos de aprendizaje

Explicar el pago por uso y su efecto en la previsión de costes.
Comparar conceptualmente precio bajo demanda, compromiso y capacidad puntual.
Identificar los factores que más influyen en una factura cloud.
Aplicar etiquetado, presupuestos y alertas como mecanismos de control.
Proponer optimización sin sacrificar rendimiento ni fiabilidad.

Prerrequisitos y conexiones

Se apoya en cloud-computing (modelos de servicio, elasticidad y responsabilidad compartida). Conecta con performance-availability, porque redundancia y reserva cuestan, y con cloud-best-practices, que integra el coste en la gobernanza.

Del consumo al coste

La nube sustituye gran parte del gasto de capital por gasto operativo: se paga por recursos usados, no por servidores comprados. Aporta flexibilidad, pero traslada la previsión al consumo; un entorno olvidado o un proceso que escala sin límite hacen crecer la factura.

La factura tiene varias dimensiones. El cómputo suele facturarse por tiempo y tamaño de instancia. El almacenamiento, por capacidad y a veces por operaciones o clase de acceso. La red incluye transferencia; el tráfico de salida hacia Internet o entre regiones suele costar, mientras que la entrada normalmente no. Los servicios gestionados pueden cobrar por peticiones, tiempo de ejecución, capacidad o licencias.

El coste total incluye también tiempo del equipo, complejidad y coste de oportunidad: un servicio gestionado más caro por hora puede ser más barato si elimina administración e incidentes.

Una factura, paso a paso

Supongamos un entorno con cuatro instancias encendidas todo el mes, una base de datos gestionada con 100 GB de almacenamiento y una transferencia de salida de 200 GB. Redondeando, el mes tiene unas 730 horas. Las cifras siguientes son inventadas para el ejercicio:

Concepto	Cálculo	Importe ilustrativo
Cómputo de las cuatro instancias	4 × 730 h × 1	2.920
Base de datos gestionada	730 h × 1,5 + 100 GB × 0,1	1.105
Almacenamiento de objetos	500 GB × 0,02	10
Transferencia de salida	200 GB × 0,05	10
Total estimado	suma de los conceptos	4.045

El ejercicio muestra dos cosas. Primero, el cómputo encendido sin descanso concentra la mayor parte del gasto, así que cualquier decisión sobre horarios, tamaños o redimensionado se juega ahí. Segundo, las cifras pequeñas por unidad, como el almacenamiento y la salida de datos, se vuelven relevantes cuando el volumen crece, por lo que conviene mirarlas antes de que el aumento las dispare.

Modelos de precio

Bajo demanda. Se paga por uso sin compromiso. Máxima flexibilidad y, normalmente, mayor precio unitario. Adecuado para cargas variables, pruebas y proyectos inciertos.
Compromiso. Se acepta un uso o gasto mínimo durante un periodo a cambio de un precio menor. Conviene si el patrón es estable; si el uso cae, se convierte en coste hundido.
Capacidad puntual. Se aprovecha capacidad excedente con descuento, pero el proveedor puede retirarla con aviso. Sirve para lotes o renderizado, no para bases de datos sin recuperación.
Niveles y clases. Almacenamiento y bases de datos ofrecen niveles con precios distintos. El más barato puede añadir latencia o costes de recuperación.
Reserva y planes de ahorro. Permiten reservar capacidad o comprometer gasto agregado aplicable a varias familias de recursos.

La elección combina previsibilidad y flexibilidad: cubrir la base estable con compromisos, dejar la variación en bajo demanda y usar capacidad puntual para trabajo tolerante a fallos. La mezcla se revisa cuando cambia el patrón.

Punto de equilibrio de un compromiso

Un compromiso cambia precio por estabilidad y su cuenta se puede hacer antes de firmarlo. Ejemplo ilustrativo: el uso estable es de 100 unidades al mes con precio 1, de modo que la partida asciende a 100; una oferta con precio 0,7 exige pagar 70 aunque el consumo varíe.

Si el consumo se mantiene en 100, la cuenta sale: 70 frente a 100. Si cae a 60, el coste de lo realmente usado es 70 para 60 unidades, es decir, 1,17 por unidad, por encima del precio sin compromiso. El ahorro depende de que la utilización se mantenga cerca de lo pactado, y por eso el compromiso se firma sobre una base que ya existe en el histórico, no sobre una previsión optimista.

Antes de renovar conviene tener a la vista dos cifras: el porcentaje de lo comprometido que se consumió de verdad y el ahorro acumulado frente a la tarifa libre. La decisión se toma con esos números delante; la magnitud del descuento, por sí sola, no dice si el acuerdo compensó.

Anatomía de una reserva de capacidad

Una reserva se describe por cuatro parámetros: el periodo (habitualmente uno o tres años en los principales proveedores), la forma de pago (todo por adelantado, parcial o sin adelantado), el alcance (familia de recursos, región y zona) y el destino del descuento. Si el alcance no coincide con lo que la carga realmente usa, el descuento se aplica a recursos que no lo necesitan y el resto sigue a tarifa libre.

La reserva introduce amortización: el desembolso se reconoce a lo largo del contrato, no solo en el mes de compra. Ejemplo ilustrativo: una reserva cuesta 12.000 unidades por un año, es decir, 1.000 al mes. Si en un mes la misma carga habría costado 1.400 a tarifa libre, ese mes ahorra 400; si solo habría costado 700, el mes cierra con 300 de más. El acuerdo compensa cuando la suma de los meses en positivo supera la de los meses en negativo, y esa cuenta se revisa antes de renovar.

Al vencimiento conviene tratar la renovación como una decisión nueva: si la carga cambió de patrón o de región, renovar en automático conserva un acuerdo que ya no describe el uso real.

FinOps y asignación de costes

FinOps es un marco operativo que reúne a finanzas, tecnología y negocio para decidir sobre coste con datos. Se organiza en dominios y en un ciclo continuo de informar, optimizar y operar. No es una herramienta, sino una práctica.

El primer paso es visibilidad: sin coste atribuible no se puede decidir. Las etiquetas asocian recursos a equipos, proyectos, entornos o centros de coste. Deben ser obligatorias, consistentes y aplicarse desde el despliegue, no como limpieza posterior. La asignación puede ser directa, por recurso etiquetado, o compartida, cuando un recurso sirve a varios equipos.

El segundo paso es responsabilidad. Presupuestos y alertas convierten el gasto en una señal accionable. La alerta debe llegar al equipo que puede actuar y distinguir un pico puntual de una tendencia sostenida.

El tercer paso es previsión, que combina histórico, estacionalidad y cambios conocidos, como un lanzamiento o una migración. Conviene expresarla como escenario con supuestos y revisarla periódicamente.

Coste por unidad de negocio

La factura total dice poco sobre la rentabilidad; dividirla entre lo que la organización entrega conecta el gasto con el resultado. Se elige una unidad relevante, como peticiones atendidas, pedidos tramitados, informes generados o usuarios activos, y se calcula el coste de cada una para el periodo.

Ejemplo ilustrativo: un mes con 12.000 unidades de coste y 3 millones de operaciones da 0,004 por operación. Si el siguiente mes el gasto sube a 15.000 y las operaciones a 6 millones, la unidad baja a 0,0025: el gasto creció, pero cada operación salió más barata. Mirar solo los totales lleva a concluir que ha subido el coste cuando lo que ha crecido es el volumen.

La métrica sirve también para comparar alternativas: si una migración a un servicio gestionado reduce el coste por operación sin degradar la experiencia, la decisión es defendible ante quien financia; si solo mueve el gasto de una partida a otra, conviene mirar el desglose antes de comunicar un ahorro.

Optimización de costes

Optimizar no es recortar a ciegas, sino eliminar gasto que no aporta valor. Las palancas habituales son:

Derechosizing. Ajustar el tamaño de las instancias a la carga real; el sobredimensionamiento crónico es una causa común de desperdicio.
Apagado de recursos ociosos. Detener entornos de desarrollo y pruebas fuera del horario laboral.
Almacenamiento adecuado. Mover datos fríos a niveles económicos, eliminar copias obsoletas y definir ciclos de vida, respetando retención y recuperación.
Menos transferencia innecesaria. Acercar servicios a usuarios o datos, usar caché y evitar mover grandes volúmenes entre regiones.
Compromisos bien dimensionados. Cubrir solo la parte estable y revisar la utilización de lo comprometido.
Arquitectura. Desacoplar con colas y escalar por componentes suele ser más eficiente que mantener capacidad sobrada para picos globales.

Cada medida tiene riesgo. Apagar recursos puede romper dependencias; mover datos a un nivel frío puede aumentar la latencia; un compromiso excesivo reduce agilidad. La optimización se evalúa con el mismo rigor que un cambio de arquitectura.

Presupuestos y alertas en la práctica

Un presupuesto útil tiene alcance claro (cuenta, suscripción, proyecto o etiqueta), periodo, umbral y acción. La acción puede ser notificar, revisar, escalar o limitar recursos, aunque el bloqueo automático debe usarse con cuidado para no tumbar cargas críticas.

Las alertas deben combinar gasto acumulado, previsión de cierre de mes y variación respecto al periodo anterior. Mirar solo el total puede llegar tarde; mirar cada recurso genera ruido. El equilibrio está en vigilar por servicio y por tendencia.

El informe debe ser comprensible para quien decide: explicar qué cambió, por qué y qué opciones existen. La conversación de coste debe ocurrir antes de desplegar, no solo cuando llega la factura.

Presupuesto con cifras ilustrativas

Un presupuesto mensual se arma con la base estable, los picos conocidos y un margen para lo imprevisto. Ejemplo redondeado: el entorno habitual consume 8.000 unidades al mes; una campaña prevista añade 2.500; un 10 % de imprevistos aporta 1.050. El total previsto queda en 11.550 y el umbral de alerta al 80 % se sitúa en 9.240.

Con esas cifras la alerta no avisa cuando ya se gastó, sino cuando queda margen para investigar. Si a mitad de mes la proyección de cierre marca 13.000, la diferencia respecto al previsto asciende a 1.450 y permite decidir con semanas de antelación: recortar el entorno de pruebas, aplazar la campaña o ampliar el presupuesto con una justificación.

Gobernanza del gasto

El control funciona cuando cada decisión tiene dueño. La repartición típica combina tres papeles: quien gasta revisa su desviación semanal, quien financia decide ampliaciones y compromisos con datos de uso, y quien diseña la plataforma aplica los límites técnicos.

Los controles de entrada evitan más de lo que las alertas corrigen después: limitar las regiones disponibles, impedir los tipos de instancia carosos fuera de producción o exigir aprobación para contratar un compromiso son medidas que actúan en el momento de comprar. La alerta sigue siendo necesaria, pero trabaja sobre un consumo ya ordenado.

Revisar los compromisos merece una cadencia propia, porque se pactan con meses de antelación: conviene agendar la evaluación cuando todavía queda margen para cambiar de estrategia, no cuando vence la fecha y renovar es la única opción sobre la mesa.

Ejemplos prácticos

Entornos de pruebas encendidos todo el mes. Se etiquetan por entorno, se programa el apagado fuera del horario laboral y se crea un presupuesto con alerta al responsable. El ahorro no exige cambiar la arquitectura.

Carga estable con picos estacionales. La base se cubre con un compromiso y el pico con bajo demanda. Antes de comprometer se revisa la utilización histórica para no pagar capacidad ociosa.

Proceso nocturno tolerante a interrupciones. Se ejecuta sobre capacidad puntual con checkpoints y reintentos. Si el proveedor retira la capacidad, el trabajo se reanuda sin pérdida grave.

Migración que disparó la transferencia. Durante una reorganización, un proceso copió copias completas entre regiones cada noche durante un mes. La partida de salida creció sin que el servicio mejorara; la corrección fue mover las copias dentro de una misma región y cifrarlas allí.

Clúster común a dos equipos sin etiquetas completas. Solo uno de los grupos tenía asignación correcta; cuando ese equipo recortó su gasto, la factura siguió alta y nadie miraba la parte sin etiquetar. La asignación compartida exige reglas de reparto acordadas antes de que llegue el importe.

Errores frecuentes

Presupuestar sin etiquetas. Sin atribución no se sabe qué equipo o servicio genera el gasto.
Confundir precio unitario con coste total. Un recurso barato puede exigir más operación o transferencia.
Sobredimensionar "por si acaso". La capacidad ociosa se paga todos los meses.
Comprometer uso que no es estable. Se pierde flexibilidad sin ahorro real.
Ignorar la transferencia de datos. La salida y el tráfico entre regiones pueden ser relevantes.
Optimizar sin medir el impacto. Apagar instancias o mover datos puede afectar al servicio.
Confundir crédito promocional con ahorro estructural. Los créditos caducan y ocultan el coste real de operar el servicio.
Dejar huérfanas las etiquetas tras una reorganización. El gasto sigue atribuido a un equipo que ya no existe y nadie responde por la desviación.

Puntos clave para el examen

La nube convierte gran parte del gasto fijo en gasto variable y medido.
Bajo demanda, compromiso y capacidad puntual responden a patrones de uso distintos.
FinOps es una práctica continua de visibilidad, optimización y operación.
El etiquetado es la base de la asignación y del control presupuestario.
Las alertas deben ser accionables y llegar a quien puede corregir el gasto.
Optimizar es eliminar desperdicio, no recortar capacidad necesaria.
El desglose por conceptos señala dónde actúa la primera palanca antes de plantear cambios de arquitectura.
Dividir el gasto entre unidades de negocio permite comparar periodos y alternativas con un mismo rasero.
Un compromiso se juzga por la utilización real alcanzada, no por el tamaño del descuento anunciado.
Los controles aplicados al crear recursos ordenan el gasto antes de que las alertas tengan que corregirlo.

Recursos externos

FinOps Foundation, FinOps Framework: https://www.finops.org/framework/
FinOps Foundation, FinOps domains: https://www.finops.org/framework/domains/
AWS, Pricing: https://aws.amazon.com/pricing/
Microsoft Azure, Pricing: https://azure.microsoft.com/en-us/pricing/
Google Cloud, Pricing: https://cloud.google.com/pricing

Autoevaluación

1. ¿Qué caracteriza al pago por uso?

Respuesta: Se paga por los recursos consumidos, sin comprar capacidad de antemano.

Justificación: El consumo medido sustituye en parte el gasto de capital. La flexibilidad es mayor, pero la factura depende de la disciplina operativa.

2. ¿Cuándo conviene un compromiso de uso?

Respuesta: Cuando existe una base de consumo estable y predecible durante el periodo.

Justificación: Reduce el precio unitario a cambio de estabilidad. Si el uso cae, se paga capacidad no utilizada.

3. ¿Para qué carga es adecuada la capacidad puntual?

Respuesta: Para cargas tolerantes a interrupciones, con checkpoints o reintentos.

Justificación: El proveedor puede retirar la capacidad con aviso. Un servicio crítico o una base sin recuperación no deberían depender solo de ella.

4. ¿Cuál es el primer requisito para controlar el gasto?

Respuesta: Tener visibilidad y atribución del coste, normalmente mediante etiquetado.

Justificación: Sin saber qué recurso genera el gasto y a quién pertenece no se puede presupuestar ni corregir. Las alertas y la optimización llegan después.

5. ¿Qué debe hacer una alerta de presupuesto para ser útil?

Respuesta: Llegar al equipo que puede actuar y distinguir un pico de una tendencia sostenida.

Justificación: Una alerta sin responsable ni contexto genera ruido. La señal debe incluir alcance, periodo y acción esperada.

6. Un importe aparece en un ejemplo de esta guía. ¿Es una tarifa real?

Respuesta: No; las cifras de los ejemplos son inventadas y redondeadas para practicar el cálculo.

Justificación: Las tarifas reales varían según región, servicio y momento, así que conviene retener el método: dividir, comparar y proyectar, en lugar del número concreto.

7. El gasto total sube pero el coste por operación baja. ¿Qué está pasando?

Respuesta: El volumen crece más rápido que el gasto.

Justificación: Dividir entre unidades de negocio separa el efecto del crecimiento del efecto del precio medio; mirar los totales aislaría solo una de las dos fuerzas.

8. ¿Qué presupuesto conviene revisar con meses de antelación?

Respuesta: El de los compromisos de uso, porque se pactan antes de conocer el comportamiento futuro de la carga.

Justificación: Acercarse al vencimiento deja como única opción renovar; programar la evaluación a tiempo conserva la alternativa de volver a tarifa libre con datos en la mano.

9. ¿Por qué la alerta se fija en el 80 % del presupuesto y no en el 100 %?

Respuesta: Para dejar margen para investigar y corregir antes de que el gasto esté consumido.

Justificación: Al llegar al tope ya no queda decisión que tomar; el umbral anticipado convierte la señal en una acción posible.

10. El equipo apaga las instancias de pruebas y el ahorro no aparece completo. ¿Qué partida revisar?

Respuesta: El almacenamiento y las direcciones que los recursos apagados siguen reteniendo.

Justificación: Apagar el cómputo no libera discos ni reservas asociadas; sin revisar la factura por concepto, el ahorro medido en horas se queda corto frente al importe real.

11. ¿Qué diferencia hay entre showback y chargeback?

Respuesta: Showback informa a cada equipo cuánto cuesta lo que consume; chargeback traslada ese importe a su presupuesto real.

Justificación: El showback crea conciencia sin afectar cuentas internas, mientras el chargeback exige reglas de atribución acordadas y defendibles. Empezar por showback permite validar el etiquetado antes de mover dinero entre áreas.