Gestión de costes AWS con FinOps | Guía práctica

La gestión de costes AWS es el problema que cada CTO descubre tarde. No porque sea difícil de entender, sino porque la factura crece de formas que no activan alarmas hasta que ya es un problema de presupuesto real. EC2 que se provisionaron para un pico de tráfico y nunca se ajustaron. Bases de datos RDS con el doble de storage del que se usa. Node groups de EKS dimensionados para el peor escenario de hace dieciocho meses. NAT Gateways que procesan tráfico que podría ir directo. El patrón común es que cada decisión individual fue razonable en su momento. La acumulación es lo que resulta cara.

Esta guía de gestión de costes AWS con FinOps no es una lista de trucos de configuración. Es un marco de decisión para equipos técnicos que quieren reducir la factura de forma sostenida, sin introducir riesgo operativo ni crear deuda técnica nueva. El objetivo es gastar menos en lo que no diferencia, para poder invertir más en lo que sí. La página de FinOps y economía cloud de Valendra explica el servicio cuando necesitas convertir estas prácticas en un modelo operativo continuo.

Gestión de costes AWS empieza por saber dónde se acumula el gasto

Antes de optimizar, hay que saber dónde está el dinero. Cost Explorer con granularidad por servicio, cuenta y etiqueta es el punto de partida obligatorio. Sin esa visibilidad, la optimización es conjetura.

EC2 e instancias de cómputo son típicamente la categoría más grande en la mayoría de las organizaciones. El coste se acumula por tres vías: instancias sobredimensionadas que nunca alcanzaron el pico para el que se provisionaron, instancias en estado stopped que siguen generando coste de EBS adjunto, y reservas de capacidad mal dimensionadas que no se han revisado en más de doce meses. La combinación de on-demand sin reservas en workloads predecibles es consistentemente la forma más cara de operar cómputo en AWS.

RDS y bases de datos gestionadas acumulan coste por sobreprovisioning de instancia, storage con autoscaling habilitado pero sin límite superior, y snapshots automáticos retenidos durante periodos más largos de lo necesario. Multi-AZ en entornos de desarrollo y staging es una causa común de gasto injustificado.

Transferencia de datos es la categoría que más sorpresas genera porque no aparece de forma visible en los presupuestos iniciales. El egress de AWS hacia internet, la transferencia entre regiones, y el tráfico entre zonas de disponibilidad dentro de la misma región tienen precios distintos y se acumulan rápidamente en arquitecturas que no los diseñan explícitamente. Un servicio que hace llamadas cross-AZ sin necesidad puede duplicar su coste de red sin que ningún dashboard lo muestre claramente.

EKS y node groups son donde se pierde más coste en organizaciones que han adoptado Kubernetes. Un node group dimensionado para tolerar la pérdida de un nodo en el peor caso de tráfico del año pasado puede estar corriendo con un 40 o 50 por ciento de capacidad no utilizada de forma permanente. La fragmentación de workloads en múltiples node groups con binpacking deficiente multiplica ese problema.

Recursos idle y olvidados: Elastic IPs no asociadas, volúmenes EBS huérfanos, load balancers sin tráfico, snapshots de hace años, Lambda functions con configuraciones de memoria heredadas. Individualmente son pequeños. En cuentas grandes de AWS, la suma puede ser significativa y es puro desperdicio.

Reservas sobredimensionadas o mal convertidas son el coste oculto de las organizaciones que ya hicieron un primer esfuerzo de optimización. Una Reserved Instance de tres años para una instancia que luego se migró a un tipo diferente, o un Savings Plan demasiado agresivo que no refleja el uso real actual, puede convertirse en un compromiso de gasto sin utilización real.

Right-sizing: la palanca más directa

El right-sizing es la optimización con el ROI más rápido y el riesgo más bajo cuando se hace con datos. La razón por la que muchos equipos no lo hacen de forma sistemática es que requiere tiempo de análisis, un proceso de cambio controlado, y voluntad de tocar infraestructura que "funciona". Esos tres factores son exactamente los que una cultura FinOps aborda.

AWS Compute Optimizer es el punto de partida correcto. Analiza métricas de CloudWatch de las últimas dos semanas y genera recomendaciones de instancia para EC2, grupos de Auto Scaling, funciones Lambda, y volúmenes EBS. Lo que Compute Optimizer no hace es considerar contexto operativo: si una instancia necesita headroom por SLA, si el patrón de uso tiene estacionalidad que no aparece en el periodo analizado, o si hay restricciones de tipo de instancia por licencia o dependencias de hardware. Ese juicio sigue siendo del equipo.

El proceso práctico de right-sizing tiene tres pasos. Primero, identifica las instancias con utilización de CPU o memoria consistentemente por debajo del 20 por ciento durante periodos de carga normal. Segundo, clasifica por coste anual para priorizar las que más impacto tienen. Tercero, define la política de reducción: cuánta headroom es aceptable según el tipo de workload, cuántas zonas de disponibilidad necesitas, y cuál es el proceso de validación antes de aplicar el cambio en producción.

La migración a Graviton merece un párrafo propio porque combina right-sizing con un cambio de arquitectura que puede tener un impacto de coste significativo. La mejora de rendimiento por precio frente a instancias x86 depende de la familia, la región, el workload y la compatibilidad del software; cualquier porcentaje debe tratarse como una hipótesis que validar, no como un ahorro garantizado. Si el software tiene dependencias de compilación nativa para x86, la migración requiere recompilación y validación. Para workloads en contenedores sobre arquitecturas modernas, esa barrera suele ser más baja.

Una regla práctica: empieza el right-sizing por los entornos de staging y desarrollo, donde el riesgo operativo es menor, para calibrar el proceso antes de aplicarlo en producción. Los ahorros en staging son marginales, pero el proceso validado en ese entorno reduce el riesgo cuando se aplica donde realmente importa.

Reserved Instances y Savings Plans

El modelo de compra de capacidad en AWS tiene más opciones de las que la mayoría de los equipos gestionan activamente, y esa falta de gestión activa es donde se pierden miles de dólares al mes en organizaciones de tamaño medio.

Reserved Instances dan un descuento a cambio de un compromiso de uso de un tipo específico de instancia en una región durante uno o tres años. Son la opción correcta cuando el workload es estable, predecible, y tiene un tipo de instancia específico que no va a cambiar. Las RI convertibles permiten cambiar familia, tipo, sistema operativo y tenancy dentro del periodo de compromiso, a cambio de un descuento ligeramente menor. Las RI estándar tienen mayor descuento pero no se pueden modificar. La decisión entre convertible y estándar depende de cuánta seguridad tienes sobre la arquitectura de tu infraestructura en el horizonte del compromiso.

Savings Plans son más flexibles que las RI y se han convertido en la opción preferida para la mayoría de los equipos. Los Compute Savings Plans aplican automáticamente a cualquier uso de EC2, Fargate o Lambda en cualquier región, familia de instancia y sistema operativo, a cambio de un compromiso de gasto por hora. Los EC2 Instance Savings Plans son menos flexibles pero ofrecen mayor descuento. La ventaja de Savings Plans es que la optimización de instancias y la migración entre tipos no "rompe" el compromiso, lo cual los hace mucho más compatibles con una cultura de right-sizing continuo.

Spot Instances pueden ofrecer un descuento muy alto frente al precio on-demand, pero el valor varía por tipo de instancia, región y momento. Además, AWS puede recuperar la instancia con dos minutos de aviso. Son adecuadas para workloads tolerantes a interrupción: procesamiento por lotes, entrenamiento de modelos, tareas CI/CD, y jobs de ETL que pueden ser interrumpidos y reiniciados. No son adecuadas para bases de datos stateful, APIs con latencia SLA estricta, o cualquier workload que no pueda manejar una terminación repentina de forma limpia.

La combinación adecuada depende de la previsibilidad y del riesgo aceptable: Savings Plans para la baseline de cómputo, Spot para cargas variables y tolerantes a interrupción, y on-demand para el overflow no predecible o los workloads que no pueden comprometerse. El error típico es tener todo en on-demand porque "siempre hay algo que cambia". Antes de cambiar el modelo de compra, mide qué parte del consumo es estable y qué parte necesita flexibilidad.

Kubernetes y EKS: dónde se pierden más costes

Kubernetes es extraordinariamente bueno para consolidar cómputo, pero requiere configuración activa para que esa consolidación ocurra. Por defecto, EKS toma las decisiones de scheduling que son correctas para la disponibilidad, no necesariamente para el coste. La diferencia entre una configuración por defecto y una configuración optimizada debe medirse con el consumo real del clúster, no asumirse por adelantado.

Overprovisioning de node groups es el problema más común. Un node group con instancias grandes y un minimum node count alto garantiza disponibilidad, pero si los pods no llenan esa capacidad, pagas por cómputo que no hace nada. El primer paso es medir la utilización real de CPU y memoria a nivel de cluster, namespace y workload. CloudWatch Container Insights o Prometheus con Grafana dan esa visibilidad. Sin ella, cualquier decisión de sizing es conjetura.

Karpenter es la respuesta de AWS al problema de bin-packing deficiente del Cluster Autoscaler. En lugar de escalar node groups predefinidos, Karpenter aprovisiona nodos de cualquier tipo según los requisitos exactos de los pods en cola. Eso permite usar instancias Spot de forma más agresiva, ajustar el tamaño de nodo al workload real, y consolidar pods en menos nodos cuando la carga baja. Los artículos EKS Auto Mode vs Karpenter y Migración a Kubernetes | Guía de producción cubren la decisión de arquitectura con detalle.

Atribución de costes por namespace es el pilar de FinOps en Kubernetes que más se ignora. Si no sabes qué gasta cada equipo dentro del cluster, no puedes responsabilizarlos de reducirlo. La atribución requiere etiquetado consistente de pods y namespaces, y una herramienta que correlacione ese etiquetado con el gasto real en nodos. OpenCost y Kubecost son las opciones open source más adoptadas para este caso de uso.

Resource requests y limits mal calibrados son el origen del problema anterior. Si los pods declaran requests de CPU y memoria que no reflejan su uso real, el scheduler toma decisiones de bin-packing basadas en datos incorrectos y el nodo parece lleno cuando en realidad tiene capacidad disponible. Auditar requests versus uso real con Vertical Pod Autoscaler en modo recomendación es el camino más rápido para identificar pods sobredeclarados.

Proceso de revisión de costes mensual

La optimización de costes sin proceso se degrada. Las decisiones puntuales que generan ahorro se deshacen con el siguiente pico de trabajo si no existe un ciclo de revisión que las mantenga. El modelo FinOps propone cuatro fases que se repiten mensualmente.

Descubrir: en la primera semana del mes, revisar Cost Explorer por servicio y etiqueta, comparar con el mes anterior, e identificar los diez ítems de mayor gasto. Confirmar que todos los recursos tienen etiqueta de equipo y entorno. Los recursos sin etiquetar son candidatos inmediatos a revisión o eliminación.

Optimizar: en la segunda semana, ejecutar las acciones identificadas. Right-sizing de instancias identificadas el mes anterior, revisión de reservas que expiran en los próximos noventa días, eliminación de recursos idle confirmados, y revisión de alertas de presupuesto. Esta fase requiere coordinación con los equipos propietarios de cada workload, no se puede hacer de forma unilateral.

Operar: durante el resto del mes, mantener los controles en funcionamiento. Alertas de presupuesto activas por cuenta y servicio, dashboard de utilización de cluster actualizado, y proceso claro para que los equipos soliciten capacidad adicional con justificación.

Medir: al final del mes, comparar el resultado contra el objetivo de ahorro, documentar qué funcionó y qué no, y ajustar las hipótesis para el siguiente ciclo. Sin medición, el proceso pierde credibilidad interna y se abandona.

Errores típicos que inflan la factura

Conocer los errores más comunes permite priorizarlos en la auditoría inicial. En organizaciones con más de dos años de historia en AWS, varios de estos aparecen simultáneamente.

EBS huérfanos y snapshots sin política de retención son el gasto invisible clásico. Cuando se termina una instancia EC2, el volumen EBS puede quedar sin borrar. Como referencia, a 0,08 dólares por GB al mes para gp3 en regiones habituales, cien volúmenes de cincuenta GB cada uno suman unos 400 dólares al mes de gasto puro en nada, antes de contar snapshots. Los snapshots sin política de expiración se acumulan durante años y rara vez se auditan.

Recursos sin etiqueta de propietario: si un recurso no tiene una etiqueta que identifica el equipo o el proyecto responsable, nadie lo examina en la revisión mensual y nadie tiene incentivo para eliminarlo. El tagging debe ser un requisito no negociable en el proceso de despliegue, no un esfuerzo de limpieza posterior.

Transferencia de datos cross-AZ innecesaria: muchos servicios internos hacen llamadas entre zonas de disponibilidad sin necesidad de disponibilidad multi-AZ. Si un servicio y su base de datos están en zonas distintas por defecto, cada query paga tráfico de red cross-AZ. La decisión de zona de disponibilidad tiene que ser parte del diseño de arquitectura, no el resultado por defecto del wizard de consola.

NAT Gateway para tráfico que podría usar endpoints privados: si los pods de EKS acceden a S3 o DynamoDB a través del NAT Gateway, están pagando por tráfico que podría ir por un VPC endpoint sin coste de transferencia. Los endpoints gateway de S3 y DynamoDB no tienen coste adicional. Créenos cuando decimos que esto aparece con frecuencia en auditorías de cuentas AWS maduras.

Compromisos de compra mal gestionados: una Reserved Instance comprada hace dos años para una instancia que luego fue migrada a Graviton, o un Savings Plan cuyo nivel de compromiso supera el uso real actual. Estas situaciones se acumulan sin que nadie las revise porque el gasto ya está comprometido y parece "pagado". La auditoría de utilization de RI y SP debe ser parte del proceso mensual.

Tabla de impacto orientativo por categoría

Los porcentajes siguientes son rangos orientativos de auditoría, no benchmarks universales ni promesas de ahorro. Dependen de la región, la arquitectura, el patrón de uso, los compromisos existentes y la capacidad de aplicar cambios sin aumentar el riesgo. No deben sumarse: valida cada hipótesis con Cost Explorer, Compute Optimizer y la AWS Pricing Calculator antes de aprobarla.

Categoría	Ahorro orientativo	Esfuerzo	Riesgo operativo
Right-sizing EC2	20-40% del gasto EC2	Medio	Bajo con validación previa
Migración a Graviton	20-30% del gasto EC2 afectado	Medio-alto	Medio, requiere pruebas
Reserved Instances / Savings Plans	30-60% vs on-demand	Bajo	Bajo, solo riesgo de compromiso
Spot para workloads tolerantes	60-80% vs on-demand	Medio	Alto si el workload no es tolerante
Karpenter en EKS	20-40% del gasto de nodos	Alto	Medio, requiere validación de scheduling
Eliminación de recursos idle	Variable (típico 5-15%)	Bajo	Muy bajo si se confirma inactividad
Endpoints VPC para S3/DynamoDB	30-80% del gasto NAT Gateway	Bajo	Muy bajo
Política de retención de snapshots	Variable	Bajo	Muy bajo con periodo de gracia
Atribución de costes Kubernetes	Visibilidad, no ahorro directo	Medio	Sin riesgo operativo
Revisión de compromisos de compra	10-25% de reservas mal utilizadas	Bajo	Sin riesgo operativo

Cuándo actuar

Si la factura de AWS crece más rápido que el uso real, o si no puedes responder "qué equipo genera este gasto" para los principales ítems de la factura, el proceso FinOps no está funcionando. El primer paso es la visibilidad: etiquetado consistente, Cost Explorer por equipo, y un proceso mensual de revisión.

Si necesitas apoyo técnico para la gestión de costes AWS sin introducir riesgo operativo, el equipo de FinOps y economía cloud de Valendra trabaja desde la auditoría inicial hasta la implementación de controles continuos.

Preguntas frecuentes sobre gestión de costes AWS

¿Por dónde empieza una gestión de costes AWS con FinOps?

Empieza por visibilidad y ownership: cuentas, servicios, etiquetas, entornos y equipos responsables. Después prioriza los diez conceptos de mayor gasto y valida cada oportunidad con su impacto, esfuerzo y riesgo. Sin esa línea base, right-sizing y compromisos de compra se convierten en conjeturas.

¿Qué diferencia hay entre Savings Plans, Reserved Instances y Spot?

Savings Plans ofrecen flexibilidad a cambio de un compromiso de gasto; las Reserved Instances encajan mejor cuando el tipo de instancia y la región son estables; Spot reduce mucho el precio, pero permite interrupciones. La elección depende de la previsibilidad y tolerancia al fallo del workload, no solo del descuento anunciado.

¿Cómo se atribuyen los costes de EKS a los equipos?

Combina etiquetas consistentes, namespaces con ownership claro y una herramienta que relacione el consumo de nodos con workloads y equipos. OpenCost o Kubecost pueden aportar esa visibilidad, pero la atribución solo sirve si los responsables revisan los datos y actúan sobre ellos.

¿Optimizar costes AWS implica reducir la disponibilidad?

No necesariamente. Empieza por recursos idle, derechos de sizing con margen validado, compromisos que reflejen el uso real y tráfico que no necesita pasar por NAT. Cada cambio en producción debe tener owner, métrica de éxito, ventana de validación y rollback. Ahorrar eliminando redundancia crítica no es FinOps; es trasladar coste a incidentes.