La optimización de costes en 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 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 AWS 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í.
Dónde se acumula el coste en AWS
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 tiene un impacto de coste significativo. Las instancias basadas en Graviton 3 y Graviton 4 ofrecen una mejora de rendimiento por precio del 20 al 40 por ciento respecto a instancias x86 equivalentes para la mayoría de workloads de servidor web, APIs y procesamiento de datos. La limitación es compatibilidad: 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 es típicamente 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 son la opción de mayor descuento, típicamente entre el 60 y el 90 por ciento respecto al precio on-demand, pero con la condición de que 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 óptima para la mayoría de las organizaciones es: Savings Plans para la baseline de cómputo predecible, Spot para las cargas variables y tolerantes a interrupción, y on-demand solo para el overflow no predecible y los workloads que genuinamente no pueden tolerar interrupción ni comprometerse en tipo de instancia. El error típico es tener todo en on-demand porque "siempre hay algo que cambia". En organizaciones con más de tres años de historia en AWS, esa postura on-demand pura suele representar entre el 20 y el 35 por ciento de gasto no optimizado en cómputo.
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 para el coste. La diferencia entre una configuración por defecto y una configuración optimizada en costes puede ser del 30 al 50 por ciento del gasto en cómputo para organizaciones con clusters de tamaño medio.
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 Kubernetes en producción en 2026 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. A un dólar por GB al mes en almacenamiento gp3, cien volúmenes de cincuenta GB cada uno son cinco mil dólares al mes de gasto puro en nada. 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 de S3 y DynamoDB son gratuitos. 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 por categoría
| Categoría | Ahorro típico | 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 reducir el gasto de forma sostenida sin introducir riesgo operativo, el equipo de consultoría cloud y DevOps: AWS, Kubernetes, Terraform de Valendra trabaja desde la auditoría inicial hasta la implementación de controles continuos.
