FinOps conecta el coste de una plataforma con el valor y los requisitos que entrega. Su primera pregunta es qué unidad de trabajo se quiere sostener y con qué latencia, disponibilidad y recuperación. Una factura menor puede resultar de eficiencia, de menor demanda o de un servicio que dejó de cumplir su contrato; esas situaciones requieren decisiones distintas.
El trabajo combina ingeniería, operación y responsables de presupuesto. Necesita datos atribuibles, supuestos visibles y decisiones que conserven el comportamiento relevante del producto.
Unidades y alcance del cálculo
Una estimación debe indicar moneda, región, periodo, precios aplicables y alcance. Compute, almacenamiento, solicitudes, transferencia, observabilidad, backups y réplicas pueden facturarse con unidades diferentes. Los descuentos o compromisos cambian la relación entre uso y pago; no deben incorporarse como un ahorro universal.
Un modelo simplificado para un periodo puede escribirse así:
C_total [USD] =
H_compute [instance-hours] × P_compute [USD/instance-hour]
+ S_avg [GiB-month] × P_storage [USD/GiB-month]
+ (N_requests / 1,000,000) [million requests] × P_requests [USD/million requests]
+ D_transfer [GiB] × P_transfer [USD/GiB]
+ C_other [USD]S_avg representa almacenamiento ponderado por tiempo, expresado en GiB-month; no es la suma de snapshots sin considerar su duración y facturación. Las tarifas por tramos, regiones, tipos de transferencia e impuestos pueden exigir términos adicionales. Este modelo organiza unidades y supuestos, sin sustituir el precio y la factura del servicio real.
Por ejemplo, una tarifa hipotética, ajena a una oferta concreta, de 0.10 USD por instance-hour aplicada a dos instancias durante 24 horas produce 2 × 24 × 0.10 = 4.80 USD de compute. No incluye transferencia, disco, logs ni impuestos. La finalidad del ejemplo es comprobar dimensiones, no afirmar un precio de AWS.
Atribución y coste unitario
Las cuentas, etiquetas y categorías deben permitir relacionar gasto con entorno, producto y responsable. Recursos compartidos necesitan una regla explícita de reparto: bytes, solicitudes, capacidad reservada o un criterio acordado. Cambiar esa regla altera el coste atribuido aunque la factura total siga igual.
El coste por operación exitosa puede medirse como:
unit_cost [USD/successful operation] =
attributable_cost [USD] / successful_operations [operations]El numerador y denominador deben corresponder al mismo alcance y periodo. Si no hay operaciones exitosas, el cociente no está definido. Un pipeline asíncrono puede pagar trabajo hoy y entregar resultados después; hay que elegir una ventana o cohorte compatible. El coste por petición recibida puede mejorar mientras aumenta el error rate, ocultando deterioro.
--- config: look: handDrawn --- flowchart TD usage["Datos de uso y facturación<br/>Unidades y actualización con retraso"] --> allocate["Atribuir por producto y entorno"] outcomes["Resultados exitosos y objetivos de servicio"] --> model["Modelo de coste unitario<br/>Supuestos explícitos"] allocate --> model model --> decision["Decisión de capacidad o arquitectura"] decision --> guardrails["Cuotas, admisión y permisos"] guardrails --> observe["Observar coste y comportamiento del servicio"] observe --> usage observe --> outcomes budget["Umbral de presupuesto"] -.->|"Alerta con retraso o acción configurada"| decision
Capacidad y compromisos
La eficiencia requiere observar utilización y saturación, no solo CPU promedio. Memoria, IO, conexiones y una clave caliente pueden limitar antes que CPU. Reducir tamaño o réplicas cambia el margen frente a un fallo. Los destinos supervivientes deben sostener la carga admitida cuando desaparezca una zona.
Autoscaling ajusta capacidad dentro de una política y tiene tiempos de reacción. Un máximo limita una dimensión de recursos, pero no todas las partidas de la factura; al alcanzarlo necesita control de admisión o una degradación prevista. Una cola sin límites puede posponer trabajo y prolongar compute incluso después de terminar el pico.
Los compromisos de capacidad o gasto necesitan una base estable y un análisis de utilización, cobertura y flexibilidad. Comprar sobre un pico temporal puede dejar pago sin uso. La decisión debe incluir variaciones de demanda y el coste de no poder cambiar de arquitectura durante el compromiso.
Spot puede servir para trabajo flexible, tolerante a fallos y reiniciable. No garantiza capacidad ni que una ejecución termine. El aviso de interrupción de dos minutos es best effort; en hibernación, el proceso comienza sin esa ventana. Checkpoints, draining y reanudación deben funcionar bajo el contrato real y calcular el coste de trabajo repetido. Un descuento por hora no prueba menor coste por resultado terminado.
Presupuestos y guardrails
AWS Budgets utiliza datos de facturación con retraso. Puede avisar cuando un umbral ya fue superado y no es un hard cap. Las acciones configuradas necesitan permisos y coordinación con otros controles; detener una instancia puede hacer que un autoscaling group cree otra. Un circuito de coste debe observar el sistema completo y su comportamiento.
Los guardrails más cercanos al consumo incluyen cuotas, permisos para crear recursos, límites de escalado y rate limits para operaciones caras. También conviene definir retención de logs y datos, limpieza de entornos temporales y detección de recursos sin responsable. El borrado de datos o la reducción de redundancia requiere revisar su impacto antes de aplicarse.
Un CDN puede reducir trabajo del origen y añadir cargos por entrega; la evaluación usa hits, misses, bytes y precios reales. Blue-green añade capacidad durante la convivencia, que debe estimarse con duración y frecuencia de releases. Terraform permite revisar el alcance de infraestructura, pero un plan correcto no demuestra que su coste sea aceptable.
Qué verificar
Se debe comparar estimación y gasto observado, explicar partidas ausentes y probar los límites con carga representativa en un entorno adecuado. Un escenario debe alcanzar el máximo de autoscaling; otro debe interrumpir un worker reiniciable. Debe comprobarse qué ocurre mientras la alerta de presupuesto aún no llega.
La decisión conserva evidencia de unidades, tarifas, supuestos y efecto sobre errores, latencia, backlog y recuperación. El ahorro solo se acepta junto al comportamiento que la plataforma debe mantener.