Coste en Kubernetes EKS por namespace: cómo imputar y controlar el gasto por equipo
Guía técnica para desglosar el coste de Amazon EKS por namespace, equipo o servicio: herramientas, estrategias de etiquetado y cómo hacer showback y chargeback en Kubernetes.
Amazon EKS es potente para ejecutar cargas de trabajo en contenedores, pero su modelo de facturación compartida hace que sea difícil responder a la pregunta más básica de FinOps: ¿quién está gastando qué? Cuando múltiples equipos comparten un mismo clúster, la factura de AWS muestra un total agregado que no permite imputar costes a servicios, equipos o features concretas. Esta guía explica cómo implementar visibilidad de costes por namespace en EKS, qué herramientas usar y cómo construir un modelo de showback o chargeback funcional.
Comparativa de herramientas para visibilidad de costes en EKS
No existe una única solución perfecta para todos los escenarios. La elección depende del nivel de granularidad necesario, la integración con los procesos existentes y el coste de la propia herramienta de visibilidad.
| Herramienta | Granularidad | Integración AWS | Coste | Ideal para |
|---|---|---|---|---|
| Kubecost | Pod, namespace, label, equipo | Nativa (EC2, EBS, LB) | Gratis hasta 1 clúster; enterprise desde $499/mes | Equipos que necesitan chargeback detallado |
| OpenCost | Pod, namespace, deployment | Parcial (requiere configuración) | Gratuito (CNCF) | Startups y equipos con presupuesto limitado |
| AWS Cost Allocation Tags | Recurso AWS (nodo, volumen) | 100% nativa | Incluido en AWS | Visibilidad básica sin herramienta adicional |
| CloudZero | Negocio (feature, cliente, equipo) | Alta (multi-cloud) | Desde ~$2.000/mes | Empresas que correlacionan coste con métrica de negocio |
Reducción de desperdicio tras implementar visibilidad por namespace
Resultados típicos en los primeros 6 meses tras activar showback en EKS
Checklist de implementación: plan 30/60/90 días
Primeros 30 días — Activar etiquetado y línea base
- Activar AWS Cost Allocation Tags para los tags de equipo, entorno y servicio en la consola de Billing
- Etiquetar todos los node groups de EKS con
team,envycost-center - Añadir labels obligatorias a namespaces:
team,service,environment - Generar un informe baseline del coste actual del clúster desglosado por node group
- Identificar los 3-5 namespaces con mayor consumo de recursos
Días 31-60 — Desplegar herramienta de visibilidad
- Instalar Kubecost u OpenCost en el clúster vía Helm
- Configurar la integración con AWS Cost and Usage Report (CUR) para datos reales de facturación
- Crear dashboards por namespace y equipo en Kubecost o Grafana
- Enviar el primer informe de showback a los líderes de equipo con los datos del mes anterior
- Identificar namespaces con recursos sobredimensionados (requests muy superiores al uso real)
Días 61-90 — Establecer presupuestos y alertas
- Definir presupuestos mensuales por namespace o equipo en Kubecost
- Configurar alertas de Slack o email cuando un namespace supera el 80% de su presupuesto
- Implementar LimitRanges y ResourceQuotas por namespace para prevenir consumo descontrolado
- Establecer una revisión mensual de costes con cada equipo propietario
- Evaluar si el modelo de showback está listo para evolucionar a chargeback formal
Guías relacionadas
¿Quieres visibilidad real del coste de tu Kubernetes?
En SysCu implementamos visibilidad de costes por namespace, equipo y servicio en clústeres EKS, desde el etiquetado hasta los dashboards de chargeback. Sin costes ocultos, sin sorpresas en la factura de AWS.
Validación técnica y evidencia recomendada
Para que este enfoque sea defendible ante dirección y equipos técnicos, conviene acompañar la implementación con pruebas repetibles, métricas comparables y un registro claro de decisiones.
Pruebas técnicas mínimas
- Cobertura de tagging en recursos con coste relevante (>= 90%).
- Análisis de coste por producto, entorno y equipo antes/después del cambio.
- Prueba de rightsizing con observación mínima de 7 días en carga real.
- Simulación de Savings Plans o Reserved Instances sobre consumo estable.
Protocolo de validación reproducible
| Fase | Objetivo | Método | Criterio de aceptación |
|---|---|---|---|
| Baseline | Mapear gasto por unidad de negocio | Clasificar consumo por cuenta, entorno, servicio y etiqueta | >= 90% del coste total con ownership identificable |
| Hipótesis | Priorizar palancas de ahorro con bajo riesgo | Seleccionar top 3 fuentes de gasto con bajo uso o sin compromiso | Plan de acciones con ahorro esperado y riesgo técnico |
| Validación | Reducir coste sin degradar fiabilidad | Rightsizing, scheduling o compromisos sobre cargas estables | Ahorro neto y SLO/latencia dentro de rango |
| Escalado | Operar FinOps de forma recurrente | Ritual semanal coste-rendimiento por producto | Backlog FinOps activo y gobernanza continua |
Datos que debes conservar como evidencia
| Métrica | Herramienta | Cadencia | Objetivo |
|---|---|---|---|
| Coste por servicio | AWS Cost Explorer | Diario | Reducción 10-25% |
| Coste unitario | CUR + BI | Semanal | Tendencia descendente |
| Recursos sin owner | Tag Policy | Semanal | < 5% |
| Desviación presupuestaria | Budgets + Alerts | Semanal | < 10% |
Dashboard mínimo recomendado
| Panel | Fuente | Actualización | Umbral operativo |
|---|---|---|---|
| Top variaciones coste | Cost Explorer + etiquetas | Diario | Variación semanal > 8% genera revisión |
| Cobertura tagging | Tag Policies / Config | Diario | >= 90% en recursos facturables |
| Eficiencia compute | CloudWatch + Trusted Advisor | Diario | CPU p95 y memoria p95 en rango objetivo |
| Compromisos activos | Savings Plans / RI | Semanal | Cobertura y utilización > 80% |
Curva de madurez esperada (referencial)
Esta visualización sirve como referencia operativa para 90 días. Debe ajustarse con tus datos reales, complejidad técnica y contexto de negocio.
Inventario y asignación de ownership de coste.
Quick wins ejecutados (limpieza, scheduling, rightsizing inicial).
Ahorro estable sin degradación de servicio.
Gobernanza FinOps integrada en ritmo operativo.
Riesgos que invalidan resultados
- Comprar compromisos sin validar estacionalidad del consumo.
- Reducir capacidad sin comprobar latencia, cola y saturación.
- No revisar tráfico de salida y almacenamiento, que suele ocultar sobrecostes.
- Aplicar FinOps solo a infraestructura y no a arquitectura.
Recomendaciones de implementación real
- No optimizar solo compute: revisar red, almacenamiento y servicios gestionados.
- Aplicar guardrails de coste en CI/CD para evitar regresiones.
- Acordar objetivos FinOps con producto y finanzas para evitar bloqueos.
- Priorizar quick wins de bajo riesgo y medir impacto real en margen.
Preguntas frecuentes que suele hacer un equipo técnico
¿Qué ahorro es razonable en una primera fase FinOps?
En organizaciones sin gobernanza previa suele verse entre 10% y 25% en 60-90 días, dependiendo del nivel de sobreaprovisionamiento y disciplina de etiquetado.
¿Savings Plans o rightsizing, qué va primero?
Primero rightsizing y limpieza de desperdicio. Luego compromisos sobre cargas estables para no fijar ineficiencias a largo plazo.
¿Cómo evitar que el ahorro frene al producto?
Definiendo guardrails por servicio crítico y evaluando ahorro junto con SLO, latencia y conversión de negocio.
Preguntas frecuentes
¿Por qué es tan difícil atribuir costes en Kubernetes EKS?
Kubernetes agrupa cargas de trabajo de múltiples equipos en nodos compartidos, lo que hace que la factura de AWS muestre el coste total del clúster sin desgloses por namespace, equipo o aplicación. Además, los recursos como el control plane, el balanceador de carga, el almacenamiento persistente y la transferencia de datos se facturan por separado y no están asociados directamente a ningún workload. Sin una estrategia explícita de etiquetado y una herramienta de visibilidad de costes, es prácticamente imposible saber qué equipo está gastando qué.
¿Cuál es la diferencia entre showback y chargeback en Kubernetes?
Showback consiste en mostrar a cada equipo cuánto está costando su uso de Kubernetes sin que ese coste se descuente de ningún presupuesto real. Es un primer paso para crear conciencia de costes y modificar comportamientos. Chargeback va un paso más allá: el coste atribuido a cada equipo se descuenta formalmente de su presupuesto o se factura internamente. La mayoría de organizaciones empiezan con showback para establecer una línea base y maduran hacia chargeback una vez que los datos son fiables y el proceso está establecido.
¿Qué herramientas existen para ver el coste por namespace en EKS?
Las opciones más utilizadas son Kubecost (la más completa, con versión open source y enterprise), OpenCost (estándar CNCF, gratuito), AWS Cost Allocation Tags combinado con AWS Cost Explorer, y CloudZero para organizaciones que quieren correlacionar coste de Kubernetes con coste de negocio. Cada una tiene un enfoque diferente en cuanto a granularidad, integración con AWS y facilidad de configuración. La elección depende del tamaño del clúster, el número de equipos y el presupuesto disponible para la herramienta de visibilidad.
¿Cómo ayuda el etiquetado a controlar el coste en EKS?
El etiquetado (tagging) en dos niveles es fundamental: a nivel de recursos AWS (nodos EC2, volúmenes EBS, load balancers) para que AWS Cost Explorer pueda agrupar el gasto, y a nivel de metadatos de Kubernetes (labels en pods y namespaces) para que herramientas como Kubecost puedan hacer la correlación. La estrategia más efectiva consiste en etiquetar con team, environment, service y cost-center, y luego configurar AWS Cost Allocation Tags para activar esos campos en los informes de facturación.
Checklist FinOps AWS: 40 puntos para recortar tu factura
El mismo checklist que usamos en cada diagnóstico. Márcalo sobre tu cuenta AWS y sabrás dónde se te va el dinero.
- 40 puntos de revisión en 5 áreas
- Quick wins aplicables en 2–4 semanas
- El mismo checklist que usamos en los diagnósticos
¿Quieres aplicarlo con ayuda en FinOps?
Si quieres priorizar quick wins y un plan ejecutable para tu equipo, podemos ayudarte con una sesión técnica de 30 minutos. Sin comerciales y sin compromiso.
¿Prefieres hacerlo por tu cuenta? Atlas Insight automatiza este análisis sobre tus cuentas AWS.