Cuando alguien me pide bajar su factura de AWS, la conversación casi siempre empieza igual: “creo que estamos pagando de más pero no sé en qué”. Y casi siempre acaba igual también: entre un 20 % y un 40 % del gasto se va en cosas que nadie está usando.
Esta guía está ordenada por retorno sobre esfuerzo. Empieza por arriba. Los tres primeros bloques suelen dar la mayor parte del ahorro y no requieren tocar arquitectura.
Antes de nada: mira dónde se va el dinero
No optimices a ciegas. Activa Cost Explorer y agrupa el gasto del último trimestre por servicio.
aws ce get-cost-and-usage \
--time-period Start=2026-05-01,End=2026-08-01 \
--granularity MONTHLY --metrics UnblendedCost \
--group-by Type=DIMENSION,Key=SERVICE
Normalmente el 80 % del gasto está en tres o cuatro servicios. Empieza por ahí y olvídate del resto.
1. Recursos huérfanos: dinero tirado
Esto es lo primero porque es puro ahorro sin ningún riesgo. Nadie usa estos recursos. Solo hay que borrarlos.
- Volúmenes EBS sin adjuntar. Discos de instancias que se apagaron hace meses y siguen facturando.
- IPs elásticas sin asociar. AWS te cobra precisamente por tenerlas ociosas.
- Instantáneas antiguas. Snapshots de 2023 que nadie va a restaurar jamás.
- Balanceadores sin destinos sanos.
- NAT Gateways en subredes que ya no tienen nada. Este duele: son unos 35 €/mes cada uno, más el tráfico.
# Volúmenes que no están adjuntos a nada
aws ec2 describe-volumes --filters Name=status,Values=available \
--query 'Volumes[].{ID:VolumeId,GB:Size,AZ:AvailabilityZone}' --output table
# IPs elásticas sin asociar
aws ec2 describe-addresses \
--query 'Addresses[?AssociationId==`null`].PublicIp' --output table
2. Dimensionamiento: pagas por lo que pediste, no por lo que usas
La mayoría de las instancias están sobredimensionadas porque alguien eligió el tamaño el primer día “por si acaso” y nadie volvió a mirarlo.
Activa Compute Optimizer: es gratis y te dice exactamente qué instancias están sobredimensionadas y cuánto ahorrarías bajando de tamaño.
Reglas prácticas:
- Si el pico de CPU de los últimos 30 días no pasa del 20 %, puedes bajar un escalón.
- Si tienes generaciones antiguas (
m4,t2,c4), migrar a la generación actual suele ser más barato y más rápido a la vez. No hay contrapartida. - Las bases de datos RDS de desarrollo casi nunca necesitan Multi-AZ.
3. Entornos que no hacen falta de noche
Desarrollo, staging y preproducción no necesitan estar encendidos 168 horas a la semana. Apagarlos fuera del horario laboral es aproximadamente un 70 % menos en esos entornos.
Se hace con un par de reglas de EventBridge. Es de las cosas con mejor retorno por hora de trabajo que existen en AWS.
4. Compromisos: Savings Plans y reservas
Cuando ya sabes cuál es tu suelo real de consumo —y solo entonces— comprometes ese suelo.
| Opción | Descuento típico | Flexibilidad | Cuándo usarla |
|---|---|---|---|
| Savings Plan de computación | 25-45 % | Alta: sirve para EC2, Fargate y Lambda | Casi siempre la mejor opción |
| Savings Plan de EC2 | 30-50 % | Media: te ata a familia y región | Carga muy estable y conocida |
| Instancias reservadas RDS | 30-50 % | Baja | Bases de datos que no van a moverse |
| Spot | 60-90 % | Ninguna: te la pueden quitar | Procesamiento por lotes, CI, trabajos tolerantes a fallo |
El error clásico es comprometerse antes de haber limpiado y redimensionado. Si compras un Savings Plan sobre un consumo inflado, te acabas de atar un año a pagar de más.
5. Almacenamiento
- Activa S3 Intelligent-Tiering en los buckets grandes. Mueve solo los objetos fríos y se paga solo.
- Pon reglas de ciclo de vida para eliminar versiones antiguas y subidas multiparte incompletas. Estas últimas son invisibles en la consola y pueden acumular terabytes.
- Los volúmenes
gp2deberían sergp3: más barato y más rápido.
6. Transferencia de datos
Es la línea de la factura que nadie entiende y casi nadie mira.
- El tráfico entre zonas de disponibilidad se cobra. Si tus servicios cotorrean entre AZs sin necesidad, estás pagando por ello.
- NAT Gateway cobra por cada gigabyte procesado. Si tus instancias privadas hablan mucho con S3 o DynamoDB, un VPC Endpoint elimina ese coste por completo.
- Sacar datos hacia internet es lo más caro de todo. Una CDN delante reduce la factura y además va más rápido.
Un orden razonable para las dos primeras semanas
- Día 1: Cost Explorer, identifica los tres servicios que más gastan.
- Día 2: borra huérfanos. Ahorro inmediato, riesgo cero.
- Días 3-5: Compute Optimizer y redimensiona lo evidente.
- Semana 2: apaga entornos no productivos por la noche.
- Semana 2: ciclos de vida en S3 y
gp2→gp3. - Después: cuando el gasto ya esté limpio, compra Savings Plans sobre el suelo real.
Nunca al revés.
Preguntas frecuentes
¿Cuánto se puede ahorrar de forma realista? En cuentas que nunca han sido revisadas, entre un 20 % y un 40 %. En cuentas ya trabajadas, entre un 5 % y un 15 %. Si alguien te promete un 60 % sin haber mirado tu cuenta, desconfía.
¿Bajar costes implica perder rendimiento? La mayor parte del ahorro sale de recursos que nadie usa y de instancias sobredimensionadas. Ahí no hay contrapartida. La tiene el uso de Spot o eliminar Multi-AZ, y esas son decisiones conscientes.
¿Merece la pena una herramienta de FinOps? Por debajo de unos 10.000 €/mes de gasto, normalmente no: Cost Explorer y Compute Optimizer, que son gratis, cubren la mayor parte. Por encima, empieza a compensar.
Trabaja conmigo: revisión de costes de AWS a precio cerrado.
Sigue leyendo: checklist de seguridad en AWS.