Cómo reducir costos en AWS sin afectar la operación

1. Recursos huérfanos: el dinero más fácil de recuperar

Los recursos huérfanos son servicios de AWS que siguen corriendo y facturando pero ya no tienen un propósito activo. Son el resultado natural de meses o años de operación sin limpieza sistemática.

Los más comunes y más costosos:

• Snapshots de EBS sin usar: cada snapshot de disco que creas para un backup se queda ahí indefinidamente si no tienes una política de retención. Una empresa mediana puede acumular cientos de snapshots de meses pasados. A $0.05/GB/mes, 5 TB de snapshots viejos son $250 mensuales que nadie ve.
• Elastic IPs sin asignar: AWS cobra por las IPs elásticas que reservaste pero que no están asociadas a una instancia activa. Son $0.005/hora — $3.6 por IP al mes, pero si tienes 20 IPs sin usar, son $72 mensuales completamente desperdiciados.
• Volúmenes EBS desconectados: cuando terminas una instancia EC2 pero olvidas borrar el volumen de disco, el volumen sigue facturando. A $0.10/GB/mes para gp3, un volumen de 200 GB desconectado son $20 mensuales.
• Load Balancers sin targets: un Application Load Balancer cuesta alrededor de $16/mes base más $0.008 por LCU. Si quedó activo después de borrar las instancias o el servicio que balanceaba, está facturando sin hacer nada.
• NAT Gateways subutilizados: cada NAT Gateway cuesta $0.045/hora ($32/mes) más $0.045 por GB de datos procesados. Si tienes uno por subnet sin necesitar alta disponibilidad, puedes reducir el número.

Cómo encontrarlos: AWS Trusted Advisor (disponible gratis con Business Support o superior) tiene una categoría de “Cost Optimization” que identifica muchos de estos recursos automáticamente. También puedes revisarlos manualmente desde la consola de AWS filtrando por región y estado.

2. Rightsizing: pagar por lo que realmente usas

El rightsizing es ajustar el tamaño de las instancias EC2 y bases de datos RDS al consumo real — no al consumo máximo teórico. La mayoría de instancias que vemos están usando entre el 10% y el 30% de su CPU promedio. Una instancia que usa 15% de CPU promedio probablemente puede moverse a una instancia 50% más pequeña sin afectar el rendimiento.

Cómo hacerlo con seguridad: usa CloudWatch para revisar el promedio y pico de CPU, memoria (via CloudWatch Agent) y IOPS durante las últimas 2-4 semanas. Si el pico máximo de CPU en ese período fue 40%, bajar al siguiente tamaño de instancia es seguro. Si el pico fue 80%, necesitas mantener el tamaño actual o revisar si hay código ineficiente que explique ese consumo puntual.

El proceso correcto: cambiar el tipo de instancia requiere reinicio (para EC2 la mayoría de los casos). Planifícalo en una ventana de mantenimiento, baja una instancia a la vez si tienes varias detrás de un load balancer, y monitorea durante 24 horas antes de bajar las siguientes.

3. Savings Plans: el mayor ahorro con el menor riesgo

Los Savings Plans son un compromiso de gasto mínimo en AWS (por ejemplo, “me comprometo a gastar $200/hora en cómputo durante 1 año”) a cambio de descuentos del 20% al 66% sobre el precio on-demand. No es una reserva de instancias específicas — es un compromiso de gasto que aplica automáticamente a cualquier instancia elegible.

Hay dos tipos principales:

• Compute Savings Plans: el más flexible. Aplica a EC2 en cualquier región, familia de instancias y sistema operativo, y también a Fargate y Lambda. Descuento de hasta 66% vs on-demand. Recomendado si tu arquitectura puede evolucionar durante el año.
• EC2 Instance Savings Plans: más restrictivo (aplica a una familia de instancias específica en una región específica), pero con mayor descuento — hasta 72% vs on-demand. Útil si tienes cargas estables y predecibles que no van a cambiar de familia de instancias.

Cuándo comprarte un Savings Plan: cuando llevas al menos 3 meses con AWS y tienes visibilidad de tu consumo base estable. El recomendador de AWS en Cost Explorer te dice exactamente qué plan comprar y cuánto ahorrarías. La regla práctica: compra Savings Plans para cubrir el 70-80% de tu consumo base, y deja el resto en on-demand para manejar variabilidad.

4. S3: ciclos de vida y clases de almacenamiento

S3 tiene múltiples clases de almacenamiento con precios muy diferentes según la frecuencia de acceso:

• S3 Standard: $0.023/GB/mes — para datos de acceso frecuente
• S3 Standard-IA (Infrequent Access): $0.0125/GB/mes — para datos que accedes menos de una vez al mes. 46% más barato.
• S3 Glacier Instant Retrieval: $0.004/GB/mes — para backups y archivos que rara vez necesitas. 83% más barato que Standard.
• S3 Glacier Deep Archive: $0.00099/GB/mes — para retención de largo plazo. 96% más barato que Standard.

La solución es configurar políticas de ciclo de vida (lifecycle rules): después de 30 días, los objetos pasan a Standard-IA; después de 90 días, a Glacier Instant Retrieval; después de 365 días, a Deep Archive. Esto se configura en minutos desde la consola de S3 y no requiere ningún cambio de código.

Impacto típico: una empresa con 10 TB en S3 Standard donde el 70% son logs y backups viejos puede bajar su costo de S3 de $230/mes a menos de $80/mes solo con políticas de ciclo de vida.

5. Data transfer: el costo invisible que escala

La transferencia de datos entre regiones AWS o hacia internet tiene costo. Los más comunes que generan sorpresas:

• Transferencia inter-AZ: mover datos entre Availability Zones dentro de la misma región cuesta $0.01/GB en cada dirección. Si tienes microservicios que se comunican frecuentemente y están en AZs diferentes, esto escala. La solución puede ser usar endpoints privados o revisar si todos los servicios que se comunican frecuentemente necesitan estar en AZs distintas.
• S3 hacia internet sin CloudFront: si sirves archivos estáticos directamente desde S3 a internet, pagas $0.09/GB de salida. Con CloudFront (CDN de AWS), el costo de transferencia de S3 a CloudFront es $0 dentro de la misma región, y el costo de CloudFront a usuarios es más bajo para volúmenes altos.
• RDS en Multi-AZ: la replicación sincrónica entre AZs en RDS Multi-AZ tiene costo de transferencia. Esto es inherente al diseño de alta disponibilidad y generalmente no es optimizable — pero es útil saberlo cuando calculas el costo de HA.

El orden correcto de ataque

No todo se optimiza al mismo tiempo. Este es el orden que usamos en CloudTing, de menor riesgo a mayor riesgo operativo:

1. 1.Limpiar recursos huérfanos — riesgo cero, impacto inmediato en la siguiente factura
2. 2.Configurar ciclos de vida en S3 — cambio de configuración, sin impacto en aplicaciones
3. 3.Comprar Savings Plans — compromiso financiero, pero sin cambios técnicos
4. 4.Rightsizing de instancias — requiere reinicio, hacerlo por ventanas de mantenimiento
5. 5.Optimización de data transfer — puede requerir cambios de arquitectura, planificar con calma