La mayoría de la infraestructura SaaS es multi-tenant por defecto. Una cuenta de AWS, un cluster de EKS, una instancia de RDS, todo compartido entre cientos o miles de clientes. Así se mantiene alta la utilización, pero responder "¿cuánto cuesta realmente operar al cliente X?" se vuelve casi imposible.
Esta pregunta aparece todo el tiempo, y las respuestas suelen ir desde "etiquetamos lo que podemos y el resto lo estimamos" hasta "nos rendimos y usamos el costo promedio por asiento". Ninguna alcanza si te importan los unit economics.
Acá va un análisis práctico de los enfoques, sus tradeoffs y dónde se cae cada uno.
El problema de fondo: los recursos compartidos no se etiquetan de forma limpia
AWS Cost Explorer y cualquier herramienta basada en facturación te muestran el costo por cuenta, región, servicio y tag. Eso funciona bien para modelos de tenant dedicado, donde cada cliente tiene su propia cuenta o namespace. Pero se cae cuando la infraestructura es compartida.
Un solo cluster de RDS que atiende a 400 clientes no tiene 400 líneas de costo. Tiene una. Un cluster de Kafka que sirve a una docena de equipos de producto sigue apareciendo como un único centro de costo compartido. Un node pool de EKS que corre workloads mixtos se factura como cómputo, no como "cliente A: $142k, cliente B: $89k".
El enfoque basado en tags se rompe acá de tres maneras:
- Los tags no se propagan a través de los recursos compartidos. Puedes etiquetar una instancia EC2 con un equipo o servicio. No puedes etiquetar una query contra una base de datos compartida.
- Los tags exigen esfuerzo continuo de Engineering. Cada nuevo recurso, cada nuevo servicio y cada nuevo deployment necesita un tag. En organizaciones que se mueven rápido, la cobertura se degrada en poco tiempo.
- Los tags te dicen qué es el recurso, no cómo se usó. Una instancia de RDS etiquetada te dice que pertenece al servicio de "payments". No te dice que el 60% de su carga vino de un solo cliente este mes.
Enfoque 1: análisis de tráfico en runtime (nuestra recomendación)
Cómo funciona: en lugar de leer exports de facturación o sumar instrumentación en la aplicación, se observa lo que realmente pasa a nivel de red y sistema: qué servicios llaman a qué bases de datos, qué customer IDs aparecen en qué queries, cuánta carga genera cada cliente sobre cada recurso compartido.
La distinción clave es que los sistemas de facturación solo ven cargos. Los sistemas de runtime ven consumo.
En la práctica, este es uno de los pocos enfoques que logra atribuir sistemas compartidos como RDS, Kafka o Elasticsearch a clientes individuales sin cambios en la aplicación ni una higiene perfecta de tags.
Además, entrega atribución en tiempo real en lugar de exports de CUR con retraso, y puede cubrir infraestructura autoadministrada que nunca aparece de forma limpia en los datos de facturación de AWS.
El tradeoff: se necesita un componente que observe el tráfico de red y las llamadas al sistema. Antes, recolectar este nivel de datos de runtime en producción era un dolor operativo. eBPF cambió eso. Las mismas primitivas detrás de herramientas como Cilium, Falco y Pixie también sirven para atribuir costos en runtime. La diferencia está en que extraes señales de consumo de recursos en lugar de eventos de seguridad u observabilidad.
Enfoque 2: una cuenta por tenant (o un namespace por tenant)
Cómo funciona: cada cliente recibe una cuenta de AWS o un namespace de Kubernetes dedicado, con la facturación aislada en consecuencia.
Dónde funciona: verticales con alta exigencia de cumplimiento (salud, finanzas), contratos enterprise con requisitos contractuales de aislamiento y clientes lo suficientemente grandes como para justificar económicamente la infraestructura dedicada.
Dónde falla: no escala a cientos de clientes SMB. La carga operativa de gestionar cientos de cuentas de AWS es enorme. La cobertura de Reserved Instances se fragmenta. Y aun así quedan servicios compartidos (pipelines de logging, infraestructura de observabilidad, data planes) que viven por fuera de las cuentas por tenant.
Enfoque 3: etiquetar todo y agregar en Cost Explorer
Cómo funciona: se imponen estándares de tagging en todos los recursos. Se usan tags de customer-id, team, service y environment. Se extraen los datos de costo etiquetados vía la API de Cost Explorer o los AWS Cost and Usage Reports (CUR). Sobre esa base se construye la lógica de agregación.
Dónde funciona: arquitecturas greenfield donde los estándares de tagging se aplican desde el día uno. Funciona razonablemente bien para cómputo dedicado (EC2, EKS node groups, Lambda), donde el mapeo entre recurso y cliente es limpio.
Dónde falla:
- Se cae en cuanto varios clientes comparten los mismos sistemas con estado. Un cluster de RDS o un deployment de Kafka compartido tiene, por naturaleza, una factura y muchos consumidores.
- En la práctica, la mayoría de las organizaciones maduras nunca sostiene una cobertura limpia de tags por mucho tiempo. Los owners cambian, los servicios se multiplican y los tags se degradan.
- Los datos de CUR llegan con 24 a 48 horas de retraso; siempre estás mirando hacia atrás.
- Los recursos compartidos (Kafka autoadministrado, Elasticsearch sobre EC2) son totalmente invisibles para los exports de facturación.
La mayoría de los equipos que lo usan tienen puntos ciegos importantes que conocen y aceptan.
Enfoque 4: instrumentación en la capa de aplicación
Cómo funciona: se instrumenta el código de la aplicación para emitir métricas por cliente: queries ejecutadas, bytes leídos/escritos, tiempo de cómputo consumido. Se arma un modelo de costos que mapea esas métricas al gasto en AWS. Se multiplica el consumo de cada métrica por el costo unitario para llegar a una estimación de costo por cliente.
Dónde funciona: equipos con una cultura sólida de observabilidad, aplicaciones donde el consumo de recursos está dominado por un número pequeño de operaciones medibles y equipos de product pricing que necesitan una aproximación.
Dónde falla:
- La cobertura de la instrumentación es incompleta por definición. Mides lo que decidiste medir.
- La infraestructura compartida (connection pooling, overhead de cluster, capacidad ociosa) no se atribuye a ninguna operación específica.
- Los modelos de costo requieren calibración continua a medida que cambian los precios.
- La infraestructura autoadministrada (Kafka sobre EC2, Elasticsearch sobre EC2) exige instrumentación a medida para cada tecnología.
- Este enfoque te dice el consumo proporcional, no el costo real.
Es una aproximación razonable para tener visibilidad interna, pero no sirve para un análisis real de cost-to-serve.
En resumen
La atribución de costos por cliente en arquitecturas multi-tenant de AWS es un problema resuelto para los modelos de tenant dedicado y un problema sin resolver por defecto para la infraestructura compartida. El stack estándar de FinOps (CUR, Cost Explorer, tagging) te da el costo por servicio y por equipo. No te da el costo por cliente.
Llegar hasta ahí implica moverte a una arquitectura menos compartida (alto costo operativo), invertir en instrumentación en la capa de aplicación (incompleta por naturaleza) u observar directamente el comportamiento en runtime (cobertura integral).
Si operas un modelo de precios basado en consumo o intentas identificar cuentas no rentables a escala, los enfoques incompletos no te van a llevar hasta el final. Si solo necesitas una asignación aproximada para reportería interna, el tagging más algo de modelado te acerca bastante.
La mayoría de los equipos se conforma con un modelo de asignación que sabe que es direccionalmente útil, pero no realmente preciso.
En general, el tooling de FinOps está pensado alrededor de las facturas de la nube, no del comportamiento compartido en runtime. Eso funciona hasta que necesitas una atribución más profunda dentro de sistemas altamente compartidos.
Llegado ese punto, la limitación normalmente no está en los datos de facturación de AWS. Está en la visibilidad sobre cómo se está consumiendo realmente la infraestructura compartida.
Attribute™ se enfoca justamente en esa capa de atribución en runtime para entornos multi-tenant.