FinOps10 de octubre de 2026 10 min de lectura

De la factura cloud al coste por pedido: reparto por centro de coste y coste unitario en AWS, Azure y Google Cloud

Saber cuánto gastas en la nube no basta: negocio pregunta cuánto cuesta cada pedido y qué equipo lo gasta. Te contamos cómo AAA Sentinel reparte la factura por centro de coste y calcula el coste unitario, con un ejemplo completo sobre tres nubes.

Este artículo también está disponible en:enfrpt

«Este mes hemos gastado un 20 % más en la nube.» Dicho así, nadie sabe si es una mala noticia. Si los pedidos han crecido un 40 %, es una mejora. Si no han crecido, es un problema. Y en los dos casos falta la segunda pregunta: ¿qué equipo o qué producto se ha llevado ese dinero? La factura cloud no responde a ninguna de las dos. En este artículo te contamos cómo las responde AAA Sentinel, y lo hacemos con un ejemplo completo sobre AWS, Azure y Google Cloud.

Las dos preguntas que la factura no contesta

La factura de una nube está organizada por servicio: tanto de cómputo, tanto de almacenamiento, tanto de base de datos. Sirve para pagar, pero no para decidir. Para decidir hacen falta dos cosas que no vienen en ella:

  • A quién pertenece cada euro: qué centro de coste, equipo o producto lo ha gastado. Sin esto no hay responsables, sólo una cifra común que nadie siente suya.
  • Qué has conseguido con ese gasto: cuánto cuesta en nube cada pedido, cada cliente o cada transacción. Sin esto no se puede distinguir crecer de derrochar.

El coste unitario es la métrica que entiende negocio. «La nube cuesta 0,10 US$ por pedido» se puede comparar con el margen de un pedido; «la nube cuesta 12.000 US$ al mes» no.

Qué ganas con ello

Con el reparto y el coste unitario en marcha, la conversación sobre la nube cambia:

  • Cada equipo ve su parte de la factura y responde de ella, en vez de discutir un total.
  • Sabes si el gasto crece más deprisa que el negocio: si el coste por pedido sube, algo se ha vuelto menos eficiente aunque la factura parezca razonable.
  • Puedes poner precio con datos: conoces el coste de servir a un cliente antes de decidir cuánto cobrarle.
  • Ves cuánto gasto no tiene dueño, que es por donde suele empezar el ahorro.
  • Lo tienes para todas tus nubes en un solo sitio, con el mismo criterio de reparto.

Cómo lo resuelve AAA Sentinel: tres piezas

La funcionalidad está en el plan Business y se apoya en tres piezas que se configuran una vez:

  • Ingesta FOCUS: cada nube exporta su factura detallada en FOCUS, el formato abierto común a AWS, Azure y Google Cloud. AAA Sentinel la lee cada día y procesa el último mes cerrado. Se configura en cada cuenta, desde Mis cuentas cloud → Ingesta FOCUS, y la propia página trae una guía paso a paso para cada nube.
  • Reparto de costes por etiqueta: eliges las claves por las que quieres ver la factura desglosada (por ejemplo, centro_de_coste) y añades reglas para cubrir lo que no está etiquetado. Está en Configuración de la organización → Costes.
  • Métricas de negocio: declaras tu unidad (pedidos, clientes activos, transacciones) y aportas cuántas hubo cada mes, a mano o por la API. La plataforma divide el coste entre esas unidades.

El resultado se ve en Informes → Coste unitario: el coste por unidad del mes, el desglose por centro de coste y la evolución de los últimos meses.

Etiquetas reales y reglas virtuales

Lo ideal es que cada recurso lleve su etiqueta en la nube, pero en la práctica siempre queda una parte sin etiquetar. En vez de obligarte a etiquetarlo todo antes de ver un resultado, AAA Sentinel te deja cubrir el hueco con reglas de etiquetado virtual: «si el servicio es S3, asígnalo a datos», «si el nombre del recurso empieza por payments-, asígnalo a pagos». Las reglas no modifican nada en tu nube y siguen tres normas sencillas:

  • La etiqueta real siempre gana a la regla. Una regla nunca pisa lo que tu equipo ha etiquetado a propósito.
  • Si dos reglas asignan la misma clave, gana la primera de la lista.
  • Lo que no tiene ni etiqueta ni regla queda como «sin asignar». Nunca se reparte a ojo: ver cuánto queda sin dueño te dice dónde etiquetar o qué regla crear.

Un atajo que nos funcionó: si cada producto vive en su propia región o suscripción, una regla por región o por subcuenta reparte casi toda la factura sin etiquetar un solo recurso. En una cuenta real con dos productos, dos reglas dejaron asignado el 83 % del gasto; el resto eran impuestos, que es correcto que no se repartan.

Caso práctico: ACME en tres nubes

ACME vende por internet. Tiene la tienda en AWS, la plataforma de datos en Azure y la analítica en Google Cloud. Quiere saber cuánto le cuesta cada pedido y cuánto gasta cada centro de coste: tienda, pagos y datos. En septiembre tuvo 9.900 pedidos. Esta es su factura del mes:

ACME · factura de septiembre por nube

AWS (tienda y pagos)
990 USD
Azure (plataforma de datos)
400 EUR
Google Cloud (analítica)
95 EUR

Paso 1: conectar la factura detallada de cada nube

Cada nube tiene su manera de exportar FOCUS y sus condiciones. Esto es lo que hay que hacer en cada una y lo que conviene saber antes de empezar:

  • AWS: activa la etiqueta en Billing → Cost allocation tags (sin activarla, AWS no la incluye en la exportación, y puede tardar hasta 24 horas en aparecer) y crea una exportación FOCUS 1.0 en CSV en Data Exports. La exportación sólo escribe desde el día en que la creas, así que el primer mes completo llega al cierre del mes en curso.
  • Azure: crea en Cost Management una exportación de tipo «Cost and usage details (FOCUS)» y da a la conexión el rol Storage Blob Data Reader sobre la cuenta de almacenamiento. Las etiquetas llegan solas, y con la herencia de etiquetas basta con etiquetar el grupo de recursos. Azure permite exportar meses pasados, así que puedes tener resultados el primer día. Sólo está disponible para contratos EA, MCA o de partner.
  • Google Cloud: activa la exportación FOCUS a BigQuery y da a la cuenta de servicio de la conexión permiso de lectura sobre el dataset. Con un dataset multirregión, Google rellena desde el inicio del mes anterior.

Una diferencia importante: la factura de Google Cloud llega agregada desde BigQuery, así que suma al coste unitario total pero no entra en el reparto por etiquetas ni se le aplican reglas. AWS y Azure sí se reparten.

Paso 2: definir el reparto una sola vez

El reparto se configura a nivel de organización y vale para todas las cuentas a la vez. ACME usa una sola clave, centro_de_coste, con los mismos valores en todas sus nubes, y tres reglas para lo que no está etiquetado:

AAA Sentinel · Reparto de costes por etiqueta

Clave de reparto
centro_de_coste
Regla 1 → pagos
Nombre de recurso · empieza por · payments-
Regla 2 → datos
Servicio · es igual a · Amazon Simple Storage Service
Regla 3 → datos
Subcuenta · es igual a · (id de la suscripción de datos de Azure)
  • Usa la misma clave y los mismos valores en todas las nubes. Si en una pones «Datos» y en otra «datos-eu», el informe los trata como centros distintos.
  • Las reglas se aplican a todas las cuentas, pero los nombres de servicio son distintos en cada proveedor: una regla por servicio de AWS no afecta a Azure. Para repartir Azure sin etiquetar, la regla por subcuenta (la suscripción) es la más práctica.

Paso 3: qué queda en cada centro de coste

Al procesar septiembre, AAA Sentinel aplica primero las etiquetas reales y después las reglas. Este es el resultado en la cuenta de AWS, recurso a recurso:

AWS · 990 USD repartidos

web-01 (300 USD) · etiqueta real tienda
tienda
cdn-tienda (150 USD) · etiqueta real tienda
tienda
orders-db (240 USD) · etiqueta real pagos
pagos
payments-webhook (60 USD) · sin etiqueta
pagos, por la regla 1
payments-reconciler (120 USD) · etiqueta real datos
datos: la etiqueta gana a la regla 1
acme-data-lake (90 USD) · sin etiqueta
datos, por la regla 2
acme-logs (30 USD) · sin etiqueta
sin asignar
  • AWS: tienda 450 USD, pagos 300 USD, datos 210 USD y 30 USD sin asignar. Sin las reglas, la cobertura habría sido del 82 %; con ellas, del 97 %.
  • Azure: datos 350 EUR y 50 EUR sin asignar.
  • Google Cloud: 95 EUR que cuentan en el total, pero no en el desglose.

Paso 4: declarar la métrica y aportar las unidades

En Configuración de la organización → Costes → Métricas de negocio, ACME crea la métrica «Pedidos», con la unidad «pedido» y la clave de reparto centro_de_coste. Después aporta las unidades del mes. Hay dos formas:

  • A mano, una vez al mes, desde Informes → Coste unitario: el total (9.900 pedidos) y, si quieres el desglose, las unidades de cada centro de coste. Volver a enviar un valor lo corrige, no lo suma.
  • Automáticamente, cada noche, desde tu sistema de pedidos, con una aplicación OAuth2 con el permiso metrics:write. Si envías valores diarios, envíalos todos los días: los días sin unidades quedan fuera del cálculo y la plataforma te avisa.

El identificador de la métrica no se puede cambiar después, porque es el que usa la API. Elígelo corto y en minúsculas: pedidos, clientes, transacciones.

Paso 5: leer el informe

Con el coste repartido y las unidades declaradas, Informes → Coste unitario muestra esto para septiembre:

ACME · coste unitario de septiembre (9.900 pedidos)

Tarjeta en USD (AWS)
990 USD ÷ 9.900 = 0,10 US$ por pedido
Tarjeta en EUR (Azure + Google Cloud)
495 EUR ÷ 9.900 = 0,05 € por pedido
Coste real de un pedido
0,10 US$ + 0,05 €
  • Una tarjeta por moneda, y nunca se convierten. Cada nube factura en su moneda y mezclarlas obligaría a inventar un tipo de cambio; el coste real de un pedido es la suma de las tarjetas.
  • Desglose por centro de coste, también por moneda: en USD aparecen tienda, pagos y datos de AWS; en EUR, datos de Azure. El desglose no suma el total, porque lo que quedó sin asignar no aparece en él.
  • Evolución de los últimos meses, que es donde está el valor: una cifra aislada dice poco, la tendencia dice si cada pedido te cuesta más o menos que antes.
  • Cuentas fuera del cálculo: si a una cuenta le falta la ingesta del mes, el informe la enseña con su nombre, el motivo y cómo resolverlo. Un coste que falta sin avisar bajaría el ratio y parecería una mejora.

Que te avise cuando el coste unitario suba

Una vez que el circuito funciona, no hace falta mirar el informe cada mes. En Alertas → Canales de alerta puedes activar «Coste unitario al alza» y fijar un porcentaje: la plataforma compara cada mes con el anterior y sólo avisa de las subidas. Es la alerta que detecta que algo se ha vuelto menos eficiente aunque la factura total siga pareciendo normal.

Lo que aprendimos montándolo

Configuramos todo esto en nuestras propias cuentas antes de escribir el artículo. Esto es lo que conviene saber antes de empezar:

  • El reparto trabaja sobre meses cerrados. Calcula cuándo tendrás el primer resultado: en AWS, al cierre del mes en que creas la exportación; en Azure y Google Cloud puedes tenerlo antes, porque exportan meses pasados.
  • Cambiar las claves o las reglas no recalcula solo un mes ya procesado. Después de cambiarlas, pulsa «Ejecutar ahora» en la Ingesta FOCUS de cada cuenta.
  • Comprueba la reconciliación: la página de ingesta compara el coste importado con la factura de la nube. Si no cuadra, lo habitual es que la ruta apunte a más de una exportación.
  • Empieza por las reglas y etiqueta después. Con dos o tres reglas bien elegidas tienes un primer reparto útil en minutos, y el «sin asignar» te dice qué merece la pena etiquetar.
  • Decide los valores antes de etiquetar. Pocos, en minúsculas y escritos siempre igual.

Checklist para empezar

Con esto en orden, la próxima vez que alguien pregunte cuánto cuesta la nube podrás contestar con lo que de verdad quiere saber: cuánto cuesta cada pedido y quién lo gasta.

  • Plan Business y acceso como propietario de la organización.
  • Tus cuentas cloud conectadas y la Ingesta FOCUS configurada en cada una.
  • Una clave de reparto con valores acordados, igual en todas las nubes.
  • Reglas para lo que no está etiquetado, y el «sin asignar» revisado.
  • Una métrica de negocio con sus unidades del mes, a mano o por la API.
  • La alerta de coste unitario al alza activada.