La factura de AWS crece por capas. Cada servicio que se añade tiene su justificación interna: el equipo necesitaba ese RDS, ese Application Load Balancer era para un proyecto piloto, ese NAT Gateway fue temporal. Individualmente, cada decisión tiene sentido. En conjunto, el total se compone sin visibilidad y sin nadie que sea dueño del coste global. El problema estructural no es que AWS sea caro, sino que la arquitectura de precios de AWS premia exactamente el tipo de crecimiento orgánico que la mayoría de los equipos de ingeniería tienen: rápido, incremental, sin tiempo para optimizar.
La mayoría de los equipos descubren el problema cuando el CFO pregunta, no cuando el equipo de ingeniería lo detecta. A esas alturas, la factura ya lleva seis meses creciendo por encima del crecimiento del negocio, los tags son inconsistentes, y nadie sabe con precisión qué genera el 40% del gasto. Reducir costes desde esa posición es un proyecto, no un ajuste puntual.
Este artículo da un mapa práctico de dónde se acumula el coste real, cómo reducirlo sin introducir riesgo operativo, y cómo evitar que vuelva a crecer. No hay atajos mágicos. Hay mecanismos específicos, secuencias de decisión y una cadencia operativa que convierte la gestión de costes en un hábito del equipo, no en una crisis periódica.
El coste no está donde crees: dónde se acumula realmente
EC2 es lo primero que mira todo el mundo cuando aparece una factura inesperada. Es lo visible. Pero en la mayoría de arquitecturas modernas, EC2 ya no es el mayor centro de coste, y en las que sí lo es, el problema rara vez es el tipo de instancia. El problema es el volumen de instancias sobredimensionadas que nadie ha tocado desde que se lanzaron.
El coste real se esconde en sitios más difíciles de ver.
La transferencia de datos entre zonas de disponibilidad es consistentemente uno de los cargos más subestimados. Una arquitectura bien pensada para alta disponibilidad, con réplicas en tres AZs, puede generar cargos de transferencia de datos de cuatro a cinco cifras al mes simplemente porque nadie ha colocado los servicios que más se comunican en la misma zona. El cargo aparece en la factura fragmentado por servicio, lo que dificulta la correlación.
Los load balancers inactivos o casi inactivos son otro acumulador silencioso. Un ALB cuesta aproximadamente 0,008 USD por hora, unos 5,8 USD al mes, más cargos por LCU. Individualmente, insignificante. Un inventario de cincuenta ALBs de los cuales veinte fueron creados para proyectos que ya no existen genera cientos de euros al mes sin generar ningún valor.
Los volúmenes EBS huérfanos, aquellos que quedan sin asociar a ninguna instancia tras terminar un EC2, son un clásico. aws ec2 describe-volumes --filters Name=status,Values=available muestra todos los volúmenes disponibles pero no adjuntos. En cuentas con varios años de historia, este comando devuelve resultados sorprendentes.
Los cargos de NAT Gateway son quizás el área donde más sorpresas aparecen. Cada GB que pasa por un NAT Gateway cuesta 0,045 USD en eu-west-1. Un servicio que descarga actualizaciones, tira de registros de contenedor externos o acciona llamadas a APIs externas desde una subred privada puede generar cargos de decenas de miles de euros al año sin que nadie los haya proyectado.
| Categoría | Dónde se esconde el coste | Señal de detección |
|---|---|---|
| EC2 | Instancias sobredimensionadas, instancias stopped que siguen generando cargos de EBS y EIP | CPU media por debajo del 10% en CloudWatch durante 14 días |
| Transferencia de datos | Tráfico cross-AZ, salida hacia internet desde subredes privadas vía NAT Gateway | Desglose de Cost Explorer por tipo de cargo: DataTransfer |
| Load Balancers | ALBs y NLBs sin targets activos o con tráfico casi nulo | RequestCount menor de 100 en los últimos 7 días |
| RDS | Instancias sobredimensionadas para pico que nunca llegó, Multi-AZ donde no se necesita | FreeableMemory y CPUUtilization en CloudWatch durante 30 días |
| EBS | Volúmenes huérfanos, volúmenes gp2 que deberían migrar a gp3 | Estado available, tipo gp2 con más de 1 TB |
| NAT Gateway | Tráfico de salida a internet no planeado desde subredes privadas | VPC Flow Logs, Cost Explorer filtrado por NatGateway |
| S3 | Clases de almacenamiento incorrectas, versioning sin lifecycle policies, costes de request | S3 Storage Lens, Cost Explorer por bucket |
Right-sizing sin romper producción
El right-sizing mal ejecutado introduce riesgo operativo. La secuencia importa tanto como la decisión.
El primer paso es instrumentar antes de tocar nada. AWS Compute Optimizer analiza métricas de CloudWatch de los últimos 14 días por defecto, aunque puede extenderse a 93 días si se activa el perfil de análisis extendido. Sus recomendaciones son el punto de partida, no la decisión final. Compute Optimizer no conoce los requisitos de disponibilidad, los SLAs internos ni los patrones de carga estacionales que no han ocurrido en el periodo de análisis.
El segundo paso es validar las recomendaciones contra datos reales. Para instancias EC2, la combinación de CPUUtilization, NetworkIn/Out y, si tienes el agente de CloudWatch instalado, MemoryUtilization y DiskReadOps da una imagen suficientemente completa. Una instancia con CPU media del 8% pero picos del 80% en los deploys no es candidata a reducción agresiva, es candidata a evaluar si el pico es real o fruto de una configuración subóptima.
El tercer paso, antes de redimensionar en producción, es probar en staging con el tipo de instancia objetivo bajo carga representativa. Esto parece obvio pero rara vez ocurre. La consecuencia de saltarse este paso es un incidente de producción que obliga a un rollback urgente y que consume más tiempo del que habría costado la prueba.
La migración a Graviton merece un párrafo propio. Las instancias Graviton3, familia r7g, m7g, c7g, ofrecen hasta un 40% mejor precio-rendimiento que sus equivalentes x86 para cargas de trabajo CPU-bound que sean compatibles. La compatibilidad es el criterio decisivo: si tu código es x86-only o depende de librerías nativas sin builds para ARM64, la migración requiere trabajo previo. Para la mayoría de aplicaciones JVM, Go o Python moderno, la migración es directa y el ahorro real.
La secuencia de decisión antes de tocar producción:
- Recoger métricas de CloudWatch de mínimo 30 días, con p95 y p99, no solo promedios.
- Revisar las recomendaciones de Compute Optimizer con ese contexto.
- Identificar si el sobredimensionado es de CPU, memoria, red o una combinación.
- Evaluar si hay dependencias de arquitectura x86 para candidatos Graviton.
- Probar el tipo objetivo en staging bajo carga representativa durante al menos 48 horas.
- Planificar el cambio en producción fuera de ventanas de alto tráfico con rollback preparado.
Reserved Instances vs Savings Plans vs Spot: cuándo cada uno compensa
El error más frecuente es aplicar un único modelo de compromiso a toda la infraestructura. El resultado es pagar por flexibilidad que no se necesita en workloads predecibles, o comprometer capacidad en workloads variables y acabar con reservas infrautilizadas.
Las Reserved Instances son el instrumento correcto para workloads estables y predecibles con horizonte de uno a tres años: bases de datos de producción, servicios críticos con carga constante, infraestructura de plataforma que no va a desaparecer. A cambio de ese compromiso, el descuento oscila entre el 30% y el 60% sobre precio bajo demanda según el plazo y el modelo de pago.
Los Savings Plans ofrecen más flexibilidad porque el compromiso es sobre un nivel de gasto por hora en USD, no sobre un tipo de instancia específico. Compute Savings Plans cubren EC2 y Fargate, EC2 Instance Savings Plans cubren una familia de instancias en una región con descuentos mayores. El riesgo de los Savings Plans es comprometer un nivel de gasto antes de tener visibilidad clara sobre el mix de instancias futuro, lo que lleva a comprometer sobre la base equivocada y dejar el descuento mal aplicado.
Spot Instances ofrecen descuentos de hasta el 90% sobre precio bajo demanda con el único requisito de tolerar interrupciones de hasta dos minutos de aviso. Son la herramienta correcta para batch de ML, procesamiento de datos, workers de CI/CD, entornos de desarrollo efímeros y cualquier carga que pueda reiniciarse sin consecuencias. El error típico es intentar usar Spot para servicios de producción sin diseño para tolerancia a interrupciones, lo que convierte el ahorro en incidentes.
| Tipo de workload | Modelo de compromiso | Por qué |
|---|---|---|
| Base de datos de producción, RPO bajo | Reserved Instance 1 año, No Upfront o Partial Upfront | Carga predecible, no se puede interrumpir, el descuento compensa en menos de 8 meses |
| Microservicios de producción con tráfico variable | Savings Plan Compute + On-Demand para overflow | Flexibilidad de tipo de instancia, cubre Fargate si hay mix |
| ML training, batch analytics, procesamiento nocturno | Spot con On-Demand fallback vía Auto Scaling Group o Karpenter | Tolerancia a interrupción, el ahorro del 60-70% es real y sostenible |
| Entornos de desarrollo y staging | Spot + schedule para apagar fuera de horario laboral | Nadie los necesita a las 03:00, el ahorro es del 80-90% frente a tener instancias running 24/7 |
| Workers de CI/CD | Spot con fleet diversificado de tipos de instancia | Las builds se pueden reintentar, la interrupción es tolerable |
| Servicios nuevos sin histórico de carga | On-Demand durante 60-90 días, luego evaluar con datos reales | Comprometer antes de tener datos produce reservas mal dimensionadas |
Kubernetes en AWS: dónde se pierden más costes y cómo recuperarlos
EKS tiene costes directos e indirectos que la mayoría de equipos no contabilizan juntos. El cluster endpoint cuesta 0,10 USD por hora, unos 73 USD al mes. Los nodos son EC2 con su coste normal. El coste de transferencia de datos dentro del cluster aplica igual. Y el coste operativo de gestionar el cluster si no hay una plataforma dedicada es el más alto de todos, aunque no aparezca en la factura de AWS.
El problema más frecuente en EKS no es el tipo de nodo, es el bin-packing. Nodos con un 30% de utilización efectiva, pods con requests sobredeclarados que reservan CPU y memoria que nunca consumen, y node groups que no pueden reducirse porque un pod con anti-affinity o un DaemonSet mantiene el nodo ocupado. El resultado es pagar por capacidad que el scheduler ve como ocupada pero que no produce trabajo real.
Karpenter resuelve este problema mejor que los Cluster Autoscaler clásicos porque puede seleccionar el tipo de instancia óptimo para el pod que necesita escalar, no solo añadir nodos del tipo preconfigurado en el node group. Un nodo r6g.xlarge para un pod que necesita mucha memoria, un c7g.large para un pod CPU-bound. Esto solo es posible si los pods tienen requests bien declarados, que es la premisa que suele faltar. Puedes leer más sobre la comparativa en detalle en EKS Auto Mode vs Karpenter: cuál es mejor para tu cluster.
La atribución de costes por namespace, por equipo o por producto es el área donde más impacto organizativo se puede conseguir. Sin visibilidad de quién consume qué, la presión para optimizar no tiene destinatario claro. Kubecost y OpenCost, la versión open source, funcionan instalando un agente en el cluster que correlaciona el uso de recursos con los costes reales de AWS y los distribuye por namespace, label, equipo o cualquier dimensión que hayas definido. Con esa visibilidad, la conversación sobre costes pasa de ser una discusión entre finanzas e ingeniería a ser una conversación dentro de cada equipo sobre sus propias decisiones de arquitectura.
Un patrón que vale la pena mencionar: muchos equipos mantienen múltiples clusters pequeños por razones históricas, un cluster por proyecto, un cluster por cliente, un cluster por entorno. El coste del endpoint, el coste operativo de gestionar upgrades independientes, y la fragmentación de capacidad que impide el bin-packing eficiente hacen que esta arquitectura tenga un coste total significativamente mayor que un cluster bien gobernado con aislamiento por namespace y network policies. La consolidación tiene riesgos que hay que gestionar, pero el análisis de coste total casi siempre favorece la consolidación con buen diseño de gobernanza. La guía Kubernetes en producción en 2026: prácticas que reducen riesgo y coste profundiza en ese diseño de gobernanza.
El proceso de revisión mensual que evita que el coste vuelva a crecer
La optimización de costes que no se institucionaliza como proceso operativo tiene una vida media de tres meses. El equipo hace un sprint de ahorro, libera recursos, y seis meses después la factura vuelve al mismo nivel porque el crecimiento orgánico no tiene fricción.
El loop FinOps que funciona tiene cuatro pasos y se ejecuta mensualmente, no trimestralmente.
El primer paso es la revisión de anomalías. Cost Explorer con alertas de presupuesto configuradas en AWS Budgets detecta incrementos del 15% o más sobre la media de los últimos tres meses en cualquier servicio. Esto no elimina sorpresas, pero las convierte en sorpresas de días, no de semanas.
El segundo paso es la revisión de desperdicio activo. Volúmenes EBS sin adjuntar, EIPs sin asociar, snapshots con más de 90 días que nadie ha verificado si son necesarios, RDS instances stopped que llevan más de 7 días, porque AWS cobra el almacenamiento aunque la instancia esté parada. Este paso se puede automatizar con AWS Config rules o con scripts que generan un informe semanal.
El tercer paso es la revisión de commitments. Compara el uso real de Reserved Instances y Savings Plans contra el compromiso. Una cobertura por debajo del 85% indica que hay capacidad comprometida no utilizada. Una cobertura del 100% consistente durante tres meses indica que hay margen para ampliar el commitment y obtener más descuento.
El cuarto paso es la atribución y accountability. Cada categoría de coste tiene un propietario. No "el equipo de infraestructura" como responsable de todo, sino el equipo que genera el gasto como responsable de su optimización. Sin este paso, los tres primeros son un ejercicio de visibilidad sin consecuencias.
Errores que inflan la factura sin que nadie los detecte
Algunos patrones de coste son casi invisibles hasta que alguien los busca específicamente.
El primer patrón es el de los snapshots acumulados sin política de retención. Cada snapshot de EBS cuesta por GB-mes, y los snapshots incrementales acumulan espacio con el tiempo. Un volumen de 500 GB con snapshots diarios durante un año puede tener cientos de GB de datos incrementales que ya no son necesarios para ningún proceso de recovery real.
# Listar snapshots propios ordenados por fecha
aws ec2 describe-snapshots --owner-ids self \
--query 'Snapshots[*].[SnapshotId,StartTime,VolumeSize,Description]' \
--output table | sort -k2
El segundo patrón es el de las EIPs sin asociar. Cada Elastic IP no asociada a una instancia en ejecución cuesta 0,005 USD por hora, unos 3,6 USD al mes. Son pocos euros, pero indican recursos huérfanos.
# Listar EIPs no asociadas
aws ec2 describe-addresses \
--query 'Addresses[?AssociationId==null].[PublicIp,AllocationId]' \
--output table
El tercer patrón es el de los volúmenes EBS de tipo gp2. AWS lanzó gp3 en 2020 con un 20% menos de coste base y mejor rendimiento por defecto, 3000 IOPS y 125 MB/s sin coste adicional frente a las 100 IOPS base de gp2. Muchas cuentas tienen volúmenes gp2 simplemente porque nadie los ha migrado.
# Listar volúmenes gp2 con su tamaño
aws ec2 describe-volumes \
--filters Name=volume-type,Values=gp2 \
--query 'Volumes[*].[VolumeId,Size,State,Attachments[0].InstanceId]' \
--output table
El cuarto patrón es el de los ECR repositories con imágenes antiguas sin política de lifecycle. Un registro de contenedores que acumula imágenes durante meses puede tener cientos de GB de datos almacenados que cuestan 0,10 USD por GB-mes. Una política de lifecycle que mantiene solo las últimas 30 imágenes por repositorio suele reducir el coste de ECR en un 70-80%.
El quinto patrón es el de los CloudWatch Logs sin retention policy. Por defecto, los logs en CloudWatch se retienen indefinidamente. En sistemas con alto volumen de logs, esto puede generar costes de almacenamiento significativos en grupos de logs que nadie consulta después de 30 días.
Checklist de auditoría de costes AWS
| Item | Cómo verificar | Estado esperado |
|---|---|---|
| Instancias EC2 con CPU media menor de 10% en 30 días | CloudWatch Metrics, Compute Optimizer | Ninguna sin plan de right-sizing o justificación documentada |
| Volúmenes EBS sin adjuntar | aws ec2 describe-volumes --filters Name=status,Values=available | Cero volúmenes disponibles sin justificación |
| Volúmenes EBS de tipo gp2 | aws ec2 describe-volumes --filters Name=volume-type,Values=gp2 | Plan de migración a gp3 para todos |
| EIPs sin asociar | aws ec2 describe-addresses filtrado por AssociationId nulo | Cero EIPs sin asociar |
| Snapshots con más de 90 días | aws ec2 describe-snapshots --owner-ids self | Política de retención activa con lifecycle rules |
| Load Balancers sin tráfico activo | CloudWatch RequestCount menor de 100 en 7 días | Ninguno sin justificación o plan de eliminación |
| Instancias RDS con FreeableMemory consistentemente alta | CloudWatch, Compute Optimizer | Right-sizing completado o plan activo |
| Cobertura de Reserved Instances y Savings Plans | Cost Explorer, Coverage report | Entre 80% y 95% para workloads estables |
| NAT Gateway: cargos de Data Processing | Cost Explorer filtrado por NatGateway | Revisado y comparado contra tráfico esperado |
| Tagging de recursos críticos | AWS Resource Groups Tagging API | 100% de recursos con tags de equipo, entorno y producto |
| Políticas de lifecycle en S3 | S3 Console, lifecycle rules por bucket | Todas las clases de objetos con lifecycle configurado |
| Políticas de lifecycle en ECR | ECR Console, lifecycle policy por repositorio | Máximo de imágenes definido, política activa |
| Retention policy en CloudWatch Logs | CloudWatch Console, log groups | Ningún log group con retención "Never expire" sin justificación |
| Instancias EC2 stopped con más de 7 días | aws ec2 describe-instances --filters Name=instance-state-name,Values=stopped | Ninguna sin plan de terminación o justificación |
| Multi-AZ en RDS donde no se justifica el SLA | RDS Console, configuración de cada instancia | Revisado contra SLA real del servicio que lo usa |
Cuándo la factura ya supera lo aceptable
Si el coste es ya una restricción para la velocidad de entrega, el primer paso correcto no es una revisión general de la arquitectura. Es una auditoría de estructura de costes: identificar los tres o cuatro centros de coste que concentran el 70% del gasto, determinar si ese gasto está alineado con el valor que genera, y definir un plan de reducción con mecanismos específicos y plazos concretos, no una lista de recomendaciones.
Si necesitas ese proceso con experiencia en arquitecturas AWS de producción, la consultoría de infraestructura cloud y DevOps de Valendra está diseñada exactamente para eso: reducir el coste sin introducir riesgo operativo y sin comprometer la capacidad de entrega del equipo.
