Cómo reducir costes en AWS sin sacrificar rendimiento

Cuando auditamos la infraestructura cloud de una empresa por primera vez, el patrón se repite: instancias sobredimensionadas, snapshots acumuladas desde 2021, datos en S3 Standard que nadie ha tocado en dos años y transferencias de datos que nadie pensó que costarían tanto.

El resultado habitual: entre un 30% y un 60% de la factura mensual se puede eliminar sin tocar una sola línea de código ni degradar el rendimiento.

Estas son las 5 palancas que aplicamos en cada auditoría.

1. Rightsizing de instancias EC2

El problema más común. Un equipo lanza una instancia m5.2xlarge para estar seguros durante un pico de tráfico, el pico pasa, y la instancia se queda corriendo así para siempre.

AWS Cost Explorer tiene una sección de Rightsizing Recommendations que analiza el uso de CPU y memoria de los últimos 14 días. Lo que casi siempre encontramos:

• Instancias con menos del 10% de uso de CPU durante el 90% del tiempo
• Memoria utilizada por debajo del 30%

La solución no es bajar siempre de tipo. A veces la solución correcta es pasar de m5 (propósito general) a t3 (burstable), que cuesta un 40% menos y maneja perfectamente cargas de trabajo intermitentes.

# Ver recomendaciones de rightsizing con AWS CLI
aws ce get-rightsizing-recommendation \
  --service EC2 \
  --configuration '{"RecommendationTarget":"SAME_INSTANCE_FAMILY","BenefitsConsidered":true}'

2. Savings Plans y Reserved Instances

Si tienes cargas de trabajo estables y predecibles, pagar on-demand es como alquilar un coche al precio de aeropuerto todos los días cuando tienes un coche propio en casa.

Los Compute Savings Plans ofrecen hasta un 66% de descuento a cambio de comprometerte a un gasto mínimo por hora durante 1 o 3 años. No te atan a un tipo de instancia específico — si cambias de m5 a m6i, el descuento sigue aplicando.

La regla que seguimos: cubre con Savings Plans el baseline de consumo que tienes garantizado. El resto, on-demand.

3. S3: ciclos de vida y clases de almacenamiento

S3 Standard cuesta $0.023/GB/mes. S3 Glacier Instant Retrieval cuesta $0.004/GB/mes. Si tienes datos a los que accedes una vez al mes o menos, estás pagando 6 veces más de lo necesario.

Una política de ciclo de vida sencilla que aplicamos por defecto:

{
  "Rules": [
    {
      "Status": "Enabled",
      "Transitions": [
        {
          "Days": 30,
          "StorageClass": "STANDARD_IA"
        },
        {
          "Days": 90,
          "StorageClass": "GLACIER_IR"
        }
      ],
      "NoncurrentVersionExpiration": {
        "NoncurrentDays": 30
      }
    }
  ]
}

Versiones antiguas de objetos acumulándose sin política de expiración es uno de los errores más caros y más fáciles de corregir.

4. Transferencia de datos (el coste invisible)

AWS no cobra por los datos que entran, pero sí por los que salen. Y cobra diferente según el destino: región a región, hacia internet, entre zonas de disponibilidad dentro de la misma región.

Lo que más sorprende a los equipos: el tráfico entre AZs dentro de la misma región cuesta $0.01/GB en cada dirección. En una arquitectura de microservicios con tráfico intenso entre servicios en distintas AZs, esto suma.

Las soluciones habituales:

• Agrupar servicios que se comunican frecuentemente en la misma AZ
• Usar VPC Endpoints para que el tráfico hacia servicios AWS (S3, DynamoDB) no salga a internet
• Activar CloudFront delante de S3 para cachear contenido estático cerca del usuario

5. Recursos huérfanos

Snapshots de EBS de instancias terminadas hace meses. Elastic IPs sin asignar (cuestan $0.005/hora si no están en uso). Load Balancers con 0 tráfico. Funciones Lambda sin invocaciones en 90 días.

Ninguno de estos recursos es caro por sí solo. El problema es que suele haber decenas o cientos de ellos acumulados.

Un script de auditoría básico para encontrar EIPs sin usar:

aws ec2 describe-addresses \
  --query 'Addresses[?AssociationId==null].[PublicIp,AllocationId]' \
  --output table

El orden importa

No todas estas palancas tienen el mismo impacto ni el mismo esfuerzo. Nuestra secuencia habitual:

1. Recursos huérfanos — impacto inmediato, riesgo cero
2. S3 lifecycle policies — impacto alto, implementación de 30 minutos
3. Rightsizing — requiere análisis, pero suele ser el mayor ahorro
4. Savings Plans — solo tras estabilizar la arquitectura
5. Transferencia de datos — requiere cambios arquitectónicos, impacto a largo plazo

---

Si quieres saber cuánto podrías ahorrar en tu infraestructura actual, pídenos una auditoría. En dos semanas tenemos un informe ejecutivo con los cambios de mayor impacto ordenados por coste, riesgo y esfuerzo.