Gestión de costes en la nube: facturación, rightsizing, compromisos y FinOps

Un presupuesto on-premise lo decide una vez al año gente cuyo trabajo es decidir presupuestos. Un presupuesto cloud lo decide de forma continua cualquiera que haga merge de una pull request que añade una política de retención, cambia una familia de instancias o introduce una llamada entre regiones. La autoridad de gasto pasó a ingeniería y, en la mayoría de las organizaciones, la responsabilidad no la acompañó. Para cerrar esa brecha existe la gestión de costes.

Esta guía parte de la mecánica y va hacia arriba: cómo se compone una factura, qué cobra realmente cada medidor, cómo los compromisos y la capacidad interrumpible cambian las cuentas y, después, las prácticas —rightsizing, políticas de ciclo de vida, etiquetado, presupuestos y el ciclo FinOps— que mantienen el gasto proporcional al valor. Aquí no aparecen precios concretos: las tarifas públicas cambian y varían según la región, y lo que sigue siendo útil son las proporciones y las formas.

Cómo se compone realmente una factura

Una factura cloud es una lista larguísima de líneas medidas, cada una con un tipo de uso, una cantidad, una tarifa y un identificador de recurso. Cuatro propiedades de esa lista explican la mayor parte de la confusión que genera.

La unidad de facturación es fina y basada en el tiempo. El cómputo se factura por segundo o por hora de tiempo asignado, el almacenamiento por gigabyte-mes prorrateado por horas, las peticiones por millón y la transferencia de datos por gigabyte. Nada se factura por «aplicación», así que la relación entre una línea y una función de negocio solo existe si la creas con etiquetas.

Los cargos continúan mientras un recurso está inactivo. Una máquina virtual detenida sigue teniendo un disco conectado, una IP pública reservada, un snapshot y quizá un balanceador de carga, y todo eso se factura. Es, con diferencia, la fuente más habitual de gasto olvidado.

El informe de uso detallado es la fuente de verdad. Ambos proveedores exportan un informe horario, a nivel de línea —AWS Cost and Usage Report, Azure Cost Details— a un almacenamiento de objetos, con aproximadamente un día de retraso. Los paneles de la consola son agregaciones de ese informe, así que, cuando haya que explicar una cifra, consulta la exportación.

La amortización cambia el panorama. Un pago por adelantado de capacidad reservada aparece como un cargo grande en un solo mes en costes no combinados (unblended) y se reparte de forma uniforme en costes amortizados. Analiza las tendencias con costes amortizados, o un único prepago parecerá un servicio descontrolado.

-- Cost and Usage Report cargado en un motor de consultas: mayores variaciones mes a mes
SELECT line_item_product_code,
       resource_tags_user_team               AS team,
       SUM(CASE WHEN month = 8 THEN line_item_unblended_cost END) AS prev,
       SUM(CASE WHEN month = 9 THEN line_item_unblended_cost END) AS curr
FROM cur_daily
WHERE line_item_line_item_type = 'Usage'
GROUP BY 1, 2
ORDER BY (curr - prev) DESC NULLS LAST
LIMIT 25;

Dos decisiones estructurales simplifican todo lo que viene después: consolidar cuentas o suscripciones bajo un único acuerdo de facturación, para que los tramos por volumen y los compromisos se compartan en toda la organización, y separar los entornos en cuentas distintas, para no tener que desenredar nunca por etiqueta el gasto de producción del de desarrollo.

Economía unitaria: adónde va el dinero

Tres medidores dominan casi todas las facturas.

El cómputo suele ser la mayor partida. Pagas capacidad asignada a lo largo del tiempo, no trabajo realizado —una máquina virtual al 4 % de CPU cuesta lo mismo que al 90 %—, así que en las cargas basadas en servidores todo depende de la utilización. El comportamiento en reposo varía mucho según el modelo de ejecución: las máquinas virtuales y los nodos de contenedores se facturan de forma continua, mientras que las funciones serverless solo se facturan mientras se ejecutan, a una tarifa más alta por unidad de tiempo de cómputo. Las funciones ganan con claridad en trabajo con picos y bajo ciclo de actividad, y pierden en servicios sostenidos de alto rendimiento, donde el sobrecoste por invocación se acumula.

El almacenamiento es barato por gigabyte y caro en conjunto, porque nunca se borra nada. Los medidores que hay que vigilar son la capacidad, el número de peticiones (que puede superar el coste de la capacidad en cargas con muchas lecturas pequeñas), las tarifas de recuperación en los niveles fríos, las duraciones mínimas de almacenamiento que te cobran por borrar antes de tiempo y los snapshots, que son incrementales pero se conservan para siempre salvo que una política los elimine. El almacenamiento en bloque conectado a máquinas virtuales cuesta varias veces más por gigabyte que el almacenamiento de objetos y se aprovisiona en lugar de consumirse: un disco de 1 TB lleno al 5 % cuesta lo mismo que uno lleno.

La transferencia de datos es el medidor que sorprende, porque su precio es direccional y asimétrico. El tráfico de entrada a la nube suele ser gratuito. Entre recursos de la misma zona de disponibilidad normalmente también lo es; entre zonas de una región cuesta una cantidad modesta, a menudo cobrada en ambos extremos; entre regiones, más; y hacia internet, lo que más, a una tarifa varias veces superior a la de entre regiones. Un service mesh muy hablador repartido en tres zonas, o un job analítico que descarga cada noche un dataset desde un bucket de otra región, puede generar una factura de transferencia mayor que el cómputo que hace el trabajo.

Dos efectos derivados merecen nombre propio. Los NAT gateways cobran por gigabyte procesado además de una tarifa horaria, así que enrutar por uno todo el tráfico saliente —incluido el que va al propio almacenamiento de objetos del proveedor— es un impuesto silencioso que los private endpoints eliminan. Y los servicios gestionados suelen facturar por una dimensión en la que no habías pensado: ingesta de logs por gigabyte, datos escaneados por consulta, unidades de rendimiento aprovisionadas o un cargo por petición en un almacén de secretos al que se llama en cada petición en lugar de cachearlo.

Modalidades de compra

En cargas estables, el precio de lista solo es el que pagas si nunca te fijas. Conviven cuatro modelos.

Los compromisos son instrumentos financieros, no técnicos: te comprometes a un nivel de uso o de gasto por hora durante uno o tres años, pagado por completo por adelantado, parcialmente por adelantado o mensualmente, a cambio de una tarifa sustancialmente menor. Los plazos de tres años y el pago anticipado dan los mayores descuentos y el menor margen para cambiar de idea. La regla general es comprometerse con el suelo de tu gráfica de uso —el nivel que estás seguro de seguir consumiendo dentro de dieciocho meses— y dejar la parte variable en on-demand. Quedarse corto pierde ahorro; pasarse significa pagar capacidad que ya no usas, lo cual es peor porque no tiene vuelta atrás.

Prefiere el instrumento flexible cuando exista. Un compute savings plan se aplica automáticamente a cualquier cómputo elegible que tengas en marcha, así que migrar de máquinas virtuales a contenedores o a una generación de instancias más reciente no deja el compromiso huérfano. Las reservas para bases de datos, cachés y clústeres de búsqueda gestionados suelen estar ligadas a una configuración concreta y, por tanto, conviene dimensionarlas con más prudencia.

La capacidad spot es el inventario sobrante del proveedor, ofrecido a una fracción de la tarifa on-demand y recuperable con poco aviso. Transforma la economía de todo lo interrumpible: runners de CI, analítica batch, procesamiento multimedia, entrenamiento de machine learning con checkpoints y capas web stateless que toleran perder parte de su flota. Para aprovecharla bien, diversifica entre varios tipos de instancia y zonas para que una recuperación en un pool no vacíe la flota, gestiona el aviso de interrupción para drenar de forma ordenada, añade checkpoints a los jobs largos y combina una base de capacidad on-demand o comprometida con un resto en spot.

Rightsizing, programación horaria y autoscaling

Comprar capacidad más barata vale menos que no comprarla. Tres técnicas aportan la mayor parte de la reducción disponible en un parque típico.

El rightsizing ajusta la capacidad aprovisionada al uso observado. Ambos proveedores generan recomendaciones a partir de métricas históricas; trátalas como un punto de partida, porque ven CPU y memoria, pero no la ventana de batch en la que la carga necesita margen de verdad. Mira la utilización máxima y el p99 durante varias semanas en lugar de la media, y cambia una sola dimensión cada vez. Las familias de instancia más nuevas suelen ofrecer mejor rendimiento por unidad de coste, así que actualizar de generación suele ser un rightsizing sin inconvenientes.

La programación horaria apaga lo que nadie usa. Los entornos que no son de producción y se usan en horario de oficina están inactivos aproximadamente dos tercios de la semana; detenerlos fuera del horario laboral elimina esa proporción de su coste de cómputo. Es la acción de mayor retorno y menor riesgo en la mayoría de las organizaciones, y necesita un responsable, porque nunca ocurre por sí sola.

# Etiquetar una vez y luego detener según un horario todo lo que lleve esa etiqueta
aws ec2 create-tags --resources i-0a1b2c3d --tags Key=schedule,Value=office-hours

ids=$(aws ec2 describe-instances \
  --filters "Name=tag:schedule,Values=office-hours" "Name=instance-state-name,Values=running" \
  --query 'Reservations[].Instances[].InstanceId' --output text)
[ -n "$ids" ] && aws ec2 stop-instances --instance-ids $ids

El autoscaling es un control de costes tanto como de disponibilidad, pero solo si escala hacia abajo. Muchos parques escalan hacia fuera bajo carga y nunca vuelven, porque la política de scale-in falta, es demasiado conservadora o la bloquean conexiones de larga duración. Comprueba que la capacidad realmente baja por la noche; si la gráfica es una escalera que solo sube, la política no está haciendo su trabajo. En Kubernetes ocurre lo mismo en dos niveles —autoscaling de pods basado en métricas reales y un cluster autoscaler autorizado a eliminar nodos—, además de requests honestos, ya que unos requests sobredeclarados reservan capacidad que se factura y nunca se usa. Consulta los fundamentos de Kubernetes para ver la mecánica.

El ciclo de vida del almacenamiento es el equivalente para los datos. Escribe una política que mueva los objetos a niveles más fríos a medida que envejecen y los borre al final de su periodo de retención, y aplica el mismo criterio a los snapshots, a las imágenes de contenedor en los registros y a la retención de logs. La ingesta de logs y telemetría suele estar entre las cinco primeras líneas de la factura; muestrear trazas, descartar los logs de nivel debug en producción y acortar la retención en caliente archivando en almacenamiento de objetos suele reducirla sustancialmente sin perder capacidad de investigación. Las plataformas analíticas que cobran por byte escaneado responden de forma espectacular al particionado y a los formatos columnares, como se explica en arquitectura big data.

Asignación: etiquetas, showback y chargeback

No puedes delegar la responsabilidad del coste en un equipo que no ve sus propios costes, y esa visibilidad depende por completo de la asignación.

Diseña un conjunto pequeño de etiquetas obligatorias —normalmente propietario o equipo, entorno, aplicación o servicio, centro de costes y clasificación de datos— y hazlo cumplir en el momento de la creación en lugar de auditarlo después. Los motores de políticas de ambas plataformas pueden rechazar la creación de recursos sin etiquetar, y los módulos de infraestructura como código pueden aplicar etiquetas por defecto para que cumplir sea el camino de menor resistencia. Activa esas etiquetas como etiquetas de asignación de costes en la consola de facturación; si no, nunca llegan a los informes.

Parte del gasto es realmente compartido: el hub de red, la plataforma de observabilidad, las herramientas de seguridad, el descuento de los compromisos. Decide y publica una regla de reparto —a partes iguales, por uso, por equipo o en un fondo central— antes de que nadie discuta por ello. El objetivo no es un reparto perfecto, sino una regla que todo el mundo entienda.

El showback publica el gasto de cada equipo sin mover dinero y basta, en la mayoría de las organizaciones, para cambiar comportamientos. El chargeback traslada de verdad el coste al presupuesto del equipo, lo que genera incentivos más fuertes y bastante más discusión; compensa sobre todo cuando los equipos tienen autoridad presupuestaria real.

La cifra que cambia las conversaciones no es el gasto total, sino el coste unitario: coste por cliente activo, por cada mil pedidos, por gigabyte ingerido. Un gasto total que sube un 20 % mientras el coste unitario baja un 10 % es un negocio que crece y se vuelve más eficiente. Sin el denominador, cada subida parece un fracaso y cada bajada, un éxito.

Presupuestos, anomalías y el ciclo FinOps

Define presupuestos por cuenta, por equipo y por servicio principal, con alertas en varios umbrales y sobre la previsión, no solo sobre el gasto real: una alerta por previsión el día 8 del mes es útil; una alerta por gasto real el día 29 es un post-mortem. Añade por encima la detección de anomalías: ambos proveedores ofrecen detección basada en machine learning que señala un servicio cuyo gasto se aparta de su propio patrón, y eso es lo que detecta un clúster aprovisionado por error o un bucle de reintentos desbocado en un día en lugar de a fin de mes.

FinOps, como se conoce generalmente esta práctica, describe un ciclo repetitivo de tres fases. Informar: asignación, paneles, métricas unitarias, previsiones; todo el mundo puede ver sus propios números. Optimizar: rightsizing, programación horaria, compra de compromisos, cambios de arquitectura, cada acción con un responsable y un ahorro estimado. Operar: hacerlo continuo; el coste como punto en las revisiones de arquitectura, una estimación de coste adjunta a los cambios de infraestructura relevantes, una revisión periódica de la cartera de compromisos y salvaguardas que eviten los peores errores. El pilar de costes del Well-Architected Framework plasma ese mismo ciclo en preguntas de revisión.

Sustos en la factura que conviene anticipar

Recursos olvidados. Balanceadores sin destinos, discos desconectados, NAT gateways inactivos, snapshots de una migración de hace dos años, un clúster de prueba de concepto en una región que nadie vigila. Búscalos de forma programada; nunca desaparecen por sí solos.

Tráfico entre zonas y entre regiones. Una malla de microservicios repartida entre zonas por disponibilidad multiplica la transferencia entre zonas. Un enrutamiento que tenga en cuenta las zonas y prefiera una réplica local elimina la mayor parte.

Egress de un servicio con muchos datos. Servir contenido multimedia o exportaciones grandes directamente desde el almacenamiento de objetos a internet contabiliza cada byte. Una CDN delante suele ser más barata, además de más rápida.

Explosiones de logs y métricas. Un solo flag de debug olvidado en producción, o una etiqueta de métrica de alta cardinalidad como un identificador de usuario, puede multiplicar una factura de observabilidad de la noche a la mañana.

Cargos por petición invocados en bucle. Los almacenes de secretos, los almacenes de parámetros y los servicios de gestión de claves cobran por llamada a la API. Obtener un secreto en cada petición en lugar de cachearlo convierte una línea insignificante en una bien visible.

Entornos de no producción siempre encendidos. Casi universal, totalmente evitable y, normalmente, el mayor ahorro disponible en una primera revisión de costes.

Conclusiones clave

• Una factura cloud es un registro de medidores muy detallado; la exportación de uso detallado es la fuente de verdad, y los recursos inactivos siguen facturándose hasta que se eliminan.
• El cómputo se factura por tiempo asignado sea cual sea la utilización, el almacenamiento se acumula porque no se borra nada, y la transferencia de datos es direccional y asimétrica: el egress y el tráfico entre regiones dominan.
• Comprométete con el suelo del uso estable mediante savings plans flexibles, reserva los recursos fijos y duraderos, y ejecuta el trabajo interrumpible en spot con diversificación y gestión de interrupciones.
• No comprar capacidad es mejor que comprarla barata: dimensiona según los picos observados, apaga los entornos de no producción fuera de horario, comprueba que el autoscaling escala hacia abajo y haz caducar los datos con políticas de ciclo de vida.
• Impón un conjunto pequeño de etiquetas obligatorias al crear recursos, publica un showback por equipo y sigue el coste unitario para no confundir crecimiento con despilfarro.
• FinOps es un ciclo continuo de informar, optimizar y operar, respaldado por presupuestos sobre la previsión y alertas de anomalías que sacan a la luz los errores en días y no a fin de mes.