Optimización de costes AWS: guía práctica

Si tu factura de AWS crece cada mes sin que entiendas por qué, no estas solo. Según datos de Flexera, las empresas desperdician de media un 32% de su gasto en cloud. En Soamee hemos ayudado a clientes a reducir sus costes de AWS entre un 30% y un 60% sin sacrificar rendimiento. Esta guía recoge las estrategias que funcionan.

Antes de optimizar: entiende tu factura

El primer paso es saber donde se va el dinero. AWS Cost Explorer es tu herramienta principal.

Configuración inicial

1. Activa Cost Explorer en la cuenta root (tarda 24h en empezar a mostrar datos)
2. Configura tags de coste: Etiqueta todos los recursos con al menos Environment (prod/staging/dev), Team (equipo responsable) y Project (proyecto)
3. Activa alertas de facturación: En AWS Budgets, crea alertas al 50%, 80% y 100% de tu presupuesto mensual

# Crear una alerta de presupuesto con AWS CLI
aws budgets create-budget \
  --account-id 123456789012 \
  --budget '{
    "BudgetName": "MonthlyBudget",
    "BudgetLimit": {"Amount": "5000", "Unit": "USD"},
    "TimeUnit": "MONTHLY",
    "BudgetType": "COST"
  }' \
  --notifications-with-subscribers '[{
    "Notification": {
      "NotificationType": "ACTUAL",
      "ComparisonOperator": "GREATER_THAN",
      "Threshold": 80,
      "ThresholdType": "PERCENTAGE"
    },
    "Subscribers": [{
      "SubscriptionType": "EMAIL",
      "Address": "devops@tuempresa.com"
    }]
  }]'

Los sospechosos habituales

En nuestra experiencia, los mayores desperdicios estan en:

1. EC2: Instancias sobredimensionadas o que corren 24/7 sin necesidad
2. RDS: Bases de datos de desarrollo encendidas fuera de horario
3. EBS: Volumenes huerfanos (sin instancia asociada)
4. Elastic IPs: IPs elasticas no asociadas a ninguna instancia (se cobran)
5. S3: Datos que deberian estar en Glacier o eliminarse
6. NAT Gateway: Trafico innecesario a través del NAT (~0.045 USD/GB)
7. CloudWatch Logs: Retención infinita de logs que nadie consulta

Estrategia 1: Right-sizing (ahorro inmediato del 20-40%)

Right-sizing significa ajustar el tamaño de las instancias a lo que realmente necesitan. Es la forma más rápida de reducir costes.

Cómo detectar instancias sobredimensionadas

AWS Compute Optimizer analiza la utilizacion de CPU, memoria y red de tus instancias y recomienda tamaños más adecuados.

# Obtener recomendaciones de Compute Optimizer
aws compute-optimizer get-ec2-instance-recommendations \
  --filters Name=Finding,Values=OVER_PROVISIONED \
  --output table

Regla práctica:

• Si la CPU media es inferior al 20% durante 2 semanas, reduce un tamaño
• Si la memoria usada es inferior al 50%, considera una instancia con menos RAM
• Si el tráfico de red es bajo, no necesitas instancias “network optimized”

Ejemplo real

Solo con right-sizing de 3 instancias: 575 USD/mes de ahorro (6.900 USD/ano).

Estrategia 2: Reserved Instances y Savings Plans

Si ya sabes que vas a usar cierta capacidad durante 1-3 años, las Reserved Instances (RI) y Savings Plans ofrecen descuentos del 30-72%.

Savings Plans vs Reserved Instances

Nuestra recomendación: Empieza con Compute Savings Plans para el baseline de tu infraestructura (la carga que siempre está encendida). Son más flexibles que las RI y los descuentos son casí iguales.

Cómo calcular el compromiso correcto

Gasto on-demand mensual estable: 3.000 USD
Factor de seguridad: 0.8 (compromete el 80% del baseline)
Compromiso mensual: 2.400 USD
Descuento Savings Plan (1 año, sin adelanto): ~30%
Ahorro mensual: 720 USD
Ahorro anual: 8.640 USD

Regla de oro: Nunca comprometas más del 80% de tu carga base. El 20% restante te da flexibilidad para cambios.

Estrategia 3: Spot Instances (ahorro del 60-90%)

Las Spot Instances son capacidad excedente de AWS que se ofrece con descuentos de hasta el 90%. La contrapartida: AWS puede reclamarlas con 2 minutos de preaviso.

Dónde usar Spot

• CI/CD pipelines: Las builds toleran interrupciones
• Batch processing: Trabajos que pueden reiniciarse
• Workers de colas: Procesamiento asincrono (SQS consumers)
• Dev/staging environments: No necesitan 100% uptime
• Training de ML: Los frameworks modernos soportan checkpointing

Dónde NO usar Spot

• Bases de datos (obviamente)
• Servidores web en producción (a menos que tengas un buen setup de auto-scaling)
• Cualquier cosa stateful sin mecanismo de recuperación

Ejemplo: CI/CD con Spot

# GitHub Actions con runners self-hosted en Spot
# Configuración de Auto Scaling Group para runners
Resources:
  CIRunnerASG:
    Type: AWS::AutoScaling::AutoScalingGroup
    Properties:
      MixedInstancesPolicy:
        InstancesDistribution:
          OnDemandBaseCapacity: 1  # 1 instancia on-demand siempre
          OnDemandPercentageAboveBaseCapacity: 0  # El resto, Spot
          SpotAllocationStrategy: capacity-optimized
        LaunchTemplate:
          LaunchTemplateSpecification:
            LaunchTemplateId: !Ref CIRunnerLaunchTemplate
            Version: !GetAtt CIRunnerLaunchTemplate.LatestVersionNumber
          Overrides:
            - InstanceType: c5.xlarge
            - InstanceType: c5a.xlarge
            - InstanceType: c5d.xlarge
            - InstanceType: m5.xlarge

Resultado real: Un cliente nuestro paso sus builds de CI de c5.xlarge on-demand a Spot con fallback. Coste anterior: 800 USD/mes. Coste con Spot: 120 USD/mes. Ahorro del 85%.

Estrategia 4: Optimización de almacenamiento

S3: Lifecycle policies

La mayoría de los datos en S3 se acceden frecuentemente solo durante los primeros días. Después, nadie los toca.

{
  "Rules": [
    {
      "ID": "OptimizeCosts",
      "Status": "Enabled",
      "Transitions": [
        {
          "Days": 30,
          "StorageClass": "STANDARD_IA"
        },
        {
          "Days": 90,
          "StorageClass": "GLACIER_INSTANT_RETRIEVAL"
        },
        {
          "Days": 365,
          "StorageClass": "DEEP_ARCHIVE"
        }
      ],
      "Expiration": {
        "Days": 730
      }
    }
  ]
}

Coste por GB/mes:

• S3 Standard: 0.023 USD
• S3 Standard-IA: 0.0125 USD (-46%)
• Glacier Instant Retrieval: 0.004 USD (-83%)
• Glacier Deep Archive: 0.00099 USD (-96%)

EBS: Limpieza de volumenes huerfanos

# Encontrar volumenes EBS no asociados a ninguna instancia
aws ec2 describe-volumes \
  --filters Name=status,Values=available \
  --query 'Volumes[*].{ID:VolumeId,Size:Size,Type:VolumeType,Created:CreateTime}' \
  --output table

Es común encontrar cientos de GB en volumenes huerfanos de instancias que se eliminaron pero cuyos volumenes se olvidaron. A 0.10 USD/GB/mes para gp3, 500 GB huerfanos son 50 USD/mes innecesarios.

EBS: Migrar de gp2 a gp3

Si todavia tienes volumenes gp2, migralos a gp3. Mismo rendimiento base, 20% más baratos, y puedes configurar IOPS y throughput independientemente.

# Migrar un volumen de gp2 a gp3
aws ec2 modify-volume \
  --volume-id vol-0123456789abcdef0 \
  --volume-type gp3

Estrategia 5: Optimización de red

NAT Gateway: el coste silencioso

NAT Gateway cobra 0.045 USD/GB de datos procesados, además de 0.045 USD/hora. Si tus instancias privadas hacen muchas llamadas a APIs externas o descargan dependencias, el coste se dispara.

Soluciones:

• VPC Endpoints para servicios AWS (S3, DynamoDB, SQS): eliminan el tráfico por NAT
• Cachear dependencias: No descargues npm packages de internet en cada build; usa un registry privado o cache
• Revisar logging: CloudWatch Logs Agent puede generar tráfico significativo

# Crear VPC Endpoint para S3 (ahorra tráfico NAT)
aws ec2 create-vpc-endpoint \
  --vpc-id vpc-0123456789abcdef0 \
  --service-name com.amazonaws.eu-west-1.s3 \
  --route-table-ids rtb-0123456789abcdef0

Caso real: Un cliente tenía 2 TB/mes de tráfico S3 a través de NAT Gateway. Coste: 90 USD/mes solo en datos. Después de crear el VPC Endpoint: 0 USD.

Estrategia 6: Automatización del ahorro

Apagar entornos de desarrollo fuera de horario

Tus entornos de dev y staging no necesitan correr a las 3 AM un domingo.

# Lambda function para apagar/encender instancias por horario
import boto3

def lambda_handler(event, context):
    ec2 = boto3.client('ec2')
    action = event.get('action', 'stop')  # 'stop' o 'start'

    # Buscar instancias con tag AutoSchedule=true
    filters = [
        {'Name': 'tag:AutoSchedule', 'Values': ['true']},
        {'Name': 'tag:Environment', 'Values': ['dev', 'staging']}
    ]

    if action == 'stop':
        filters.append({'Name': 'instance-state-name', 'Values': ['running']})
        instances = ec2.describe_instances(Filters=filters)
        ids = [i['InstanceId']
               for r in instances['Reservations']
               for i in r['Instances']]
        if ids:
            ec2.stop_instances(InstanceIds=ids)
            print(f"Stopped {len(ids)} instances: {ids}")

    elif action == 'start':
        filters.append({'Name': 'instance-state-name', 'Values': ['stopped']})
        instances = ec2.describe_instances(Filters=filters)
        ids = [i['InstanceId']
               for r in instances['Reservations']
               for i in r['Instances']]
        if ids:
            ec2.start_instances(InstanceIds=ids)
            print(f"Started {len(ids)} instances: {ids}")

Ahorro típico: Si tus entornos de dev cuestan 1.500 USD/mes corriendo 24/7, apagarlos de 20:00 a 08:00 y fines de semana ahorra ~65%: 975 USD/mes.

Dashboard de costes con Grafana

Configura un dashboard que el equipo pueda ver diariamente:

• Coste diario vs presupuesto
• Top 10 servicios por coste
• Coste por equipo/proyecto (basado en tags)
• Tendencia mes a mes
• Anomalias (picos inesperados)

Checklist de optimización rápida

Si necesitas resultados inmediatos, ejecuta este checklist:

• Eliminar Elastic IPs no asociadas
• Eliminar volumenes EBS huerfanos
• Eliminar snapshots antiguos (más de 6 meses sin uso)
• Migrar volumenes gp2 a gp3
• Configurar lifecycle policies en S3
• Crear VPC Endpoints para S3 y DynamoDB
• Activar Compute Optimizer y revisar recomendaciones
• Configurar alertas de presupuesto
• Apagar entornos de dev fuera de horario
• Revisar logs de CloudWatch (retención y volumen)
• Revisar instancias RDS de desarrollo

Tiempo estimado: 4-8 horas. Ahorro típico: 15-25% inmediato.

Herramientas de terceros que ayudan

Plan de acción recomendado

Resultado típico tras 1 mes de optimización: reducción del 35-55% en la factura mensual.

Conclusion

Optimizar costes en AWS no es un proyecto puntual, es un habito. Las empresas que mejor lo hacen tienen un “cloud cost champion” en el equipo (no necesariamente a tiempo completo) que revisa la factura semanalmente y mantiene las buenas prácticas.

Si tu factura de AWS se ha descontrolado y no sabes por dónde empezar, contacta con nosotros. Hacemos auditorías de costes cloud donde identificamos oportunidades de ahorro y te ayudamos a implementarlas.