Cómo optimizar costos en AWS, Azure y GCP sin perder rendimiento

Estrategias probadas para reducir 40-70% tu factura cloud manteniendo (o mejorando) velocidad, disponibilidad y experiencia de usuario

Introducción

La factura cloud que parecía razonable a $500/mes en fase de MVP ahora alcanza $8,000/mes con el mismo tráfico, solo porque nadie optimizó configuraciones iniciales ni apagó recursos de testing olvidados. Este escenario se repite en 70% de las empresas que operan en cloud: pagan 2-3x más de lo necesario por desconocimiento de herramientas de optimización, falta de gobernanza de costos y arquitecturas que escalan pero no optimizan.

Según estudios de FinOps Foundation 2025, organizaciones que implementan prácticas estructuradas de optimización de costos cloud reducen gastos 40-70% en 6-12 meses sin sacrificar performance, disponibilidad ni seguridad. La clave no es “gastar menos” sino “gastar inteligentemente”: usar instancias correctas, eliminar desperdicio, automatizar escalado y negociar compromisos cuando el uso es predecible.

Esta guía cubre el arsenal completo de optimización cloud para los tres proveedores principales: análisis de facturación actual para identificar waste, rightsizing de instancias compute, optimización de storage con tiering inteligente, estrategias de reservas y savings plans, arquitecturas cost-aware, herramientas de monitoreo de costos, automatización de apagado de recursos no productivos, y gobernanza FinOps para equipos. No es teoría; son tácticas operativas que puedes implementar esta semana para ver impacto inmediato en tu próxima factura.

Por Qué Cloud es Caro (y Cómo se Desperdicia Dinero)

Fuentes comunes de desperdicio cloud:

1. Recursos idle o huérfanos (30-40% del gasto)

• Instancias EC2/VMs de dev/test corriendo 24/7 cuando solo se usan 8h/día
• Volúmenes EBS/discos no adjuntos a ninguna instancia
• Load balancers sin tráfico
• Bases de datos RDS/SQL en ambientes no productivos sin apagar

2. Overprovisioning (25-35%)

• Instancias con CPU <10% pero memoria adecuada (debería usar compute-optimized)
• Bases de datos con IOPS provisionados 5x superiores al uso real
• Ancho de banda redundante en entornos sin tráfico crítico

3. Falta de compromisos (15-25%)

• On-demand pricing cuando podrías usar Reserved Instances (30-70% descuento)
• No aprovechar Spot Instances para workloads tolerantes a interrupciones
• Ignorar Savings Plans que cubren múltiples servicios

4. Data transfer y storage mal gestionado (10-20%)

• Snapshots antiguos nunca eliminados
• Logs en S3 Standard cuando deberían estar en Glacier
• Tráfico inter-región innecesario
• Imágenes/videos sin compresión servidos desde origin en lugar de CDN

5. Falta de gobernanza (10-15%)

• Equipos lanzando recursos sin límites presupuestarios
• Tags inexistentes imposibilitan atribuir costos por proyecto/equipo
• Alertas de facturación configuradas demasiado altas

Fase 1: Análisis de Costos Actuales

Paso 1: Habilitar Cost Explorer y herramientas nativas

AWS:

bash# Cost Explorer ya está habilitado, accede vía consola
# AWS Console → Billing → Cost Explorer

# Habilita tags de asignación de costos
# Billing → Cost Allocation Tags → Activate user-defined tags

# Configura AWS Budgets
aws budgets create-budget \
  --account-id 123456789012 \
  --budget file://budget-config.json \
  --notifications-with-subscribers file://notifications.json

Azure:

bash# Azure Cost Management ya está disponible
# Portal → Cost Management + Billing → Cost analysis

# Configurar presupuestos
az consumption budget create \
  --budget-name monthly-budget \
  --amount 5000 \
  --time-grain Monthly \
  --start-date 2025-11-01

GCP:

bash# Habilitar billing export a BigQuery
gcloud billing accounts list
gcloud billing accounts export \
  --billing-account=BILLING_ACCOUNT_ID \
  --dataset=billing_dataset \
  --project=PROJECT_ID

# Configurar presupuestos
gcloud billing budgets create \
  --billing-account=BILLING_ACCOUNT_ID \
  --display-name="Monthly Budget" \
  --budget-amount=5000

Paso 2: Identificar top 10 servicios/recursos más costosos

AWS CloudWatch + Cost Explorer:

• Agrupa costos por servicio (EC2, RDS, S3, Data Transfer)
• Filtra por tags (Environment: production, Team: backend)
• Identifica tendencias: ¿qué crece más rápido?

Pregunta clave: ¿El 80% del costo viene del 20% de recursos? Enfócate en optimizar esos primero.

Paso 3: Auditar recursos idle y huérfanos

AWS CLI para encontrar recursos no utilizados:

bash# EC2 instances con CPU <5% promedio últimos 7 días
aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=i-1234567890abcdef0 \
  --start-time 2025-10-20T00:00:00Z \
  --end-time 2025-10-27T00:00:00Z \
  --period 86400 \
  --statistics Average

# Volúmenes EBS no adjuntos
aws ec2 describe-volumes \
  --filters "Name=status,Values=available" \
  --query "Volumes[*].[VolumeId,Size,VolumeType]" \
  --output table

# Load balancers sin targets activos
aws elbv2 describe-load-balancers --query 'LoadBalancers[?State.Code==`active`]'
aws elbv2 describe-target-health --target-group-arn <arn>

# RDS instances detenidas >7 días
aws rds describe-db-instances \
  --query 'DBInstances[?DBInstanceStatus==`stopped`]'

Herramientas third-party recomendadas:

• AWS Trusted Advisor: auditoría automática de optimización (requiere Business/Enterprise support)
• CloudHealth / CloudCheckr: dashboards multi-cloud con recomendaciones
• Spot.io / ProsperOps: optimización automatizada de instancias
• Kubecost: para clusters Kubernetes

Fase 2: Rightsizing de Compute

Qué es rightsizing: ajustar tipo y tamaño de instancias para que recursos (CPU, RAM, red) coincidan con uso real, no con estimación inicial sobreprovisionada.

AWS EC2 Rightsizing:

Paso 1: Analizar métricas de utilización

bash# Obtener utilización CPU/memoria de instancias
aws cloudwatch get-metric-statistics \
  --namespace AWS/EC2 \
  --metric-name CPUUtilization \
  --dimensions Name=InstanceId,Value=i-xxxxx \
  --start-time $(date -u -d '14 days ago' +"%Y-%m-%dT%H:%M:%S") \
  --end-time $(date -u +"%Y-%m-%dT%H:%M:%S") \
  --period 3600 \
  --statistics Average,Maximum

Paso 2: Identificar candidatos a downsize

Escenario	Acción
CPU <20%, RAM <40%	Reducir tamaño (t3.large → t3.medium)
CPU alto, RAM bajo	Cambiar a compute-optimized (c6i)
RAM alto, CPU bajo	Cambiar a memory-optimized (r6i)
Tráfico de red alto	Cambiar a network-optimized (m5n)

Paso 3: Cambiar tipo de instancia (requiere downtime breve)

bash# Detener instancia
aws ec2 stop-instances --instance-ids i-xxxxx

# Cambiar tipo
aws ec2 modify-instance-attribute \
  --instance-id i-xxxxx \
  --instance-type t3.medium

# Iniciar
aws ec2 start-instances --instance-ids i-xxxxx

Savings esperados: 30-50% al reducir de t3.xlarge ($0.1664/h) a t3.large ($0.0832/h) si uso lo permite.

Azure VM Rightsizing:

bash# Listar recomendaciones de rightsizing
az advisor recommendation list \
  --category Cost \
  --query "[?contains(impactedValue, 'virtualMachines')]"

# Cambiar tamaño de VM
az vm resize \
  --resource-group myResourceGroup \
  --name myVM \
  --size Standard_D2s_v3

GCP Compute Engine Rightsizing:

bash# Obtener recomendaciones automáticas
gcloud recommender recommendations list \
  --project=PROJECT_ID \
  --recommender=google.compute.instance.MachineTypeRecommender \
  --location=us-central1

# Cambiar machine type
gcloud compute instances set-machine-type INSTANCE_NAME \
  --zone=us-central1-a \
  --machine-type=n1-standard-2

Fase 3: Estrategias de Reservas y Compromisos

Reserved Instances / Reserved VMs (AWS, Azure)

Qué son: Compromiso de 1-3 años con instancias específicas a cambio de 30-70% descuento vs. on-demand.

Cuándo usarlos: Workloads con utilización predecible >75% del tiempo (bases de datos, servicios core).

Tipos de RIs:

AWS Reserved Instances:

• Standard RI: 72% descuento, no se puede cambiar tipo de instancia
• Convertible RI: 54% descuento, puedes cambiar tipo de instancia
• Scheduled RI: para workloads que corren ciertos horarios (ej: batch jobs nocturnos)

bash# Comprar Reserved Instance
aws ec2 purchase-reserved-instances-offering \
  --reserved-instances-offering-id <offering-id> \
  --instance-count 5

Cálculo de ROI:

textOn-demand t3.xlarge: $0.1664/h × 730h/mes = $121.47/mes
Reserved Instance (1 año, pago upfront): $73/mes
Savings: $48.47/mes (40%)

Azure Reserved VM Instances:

bash# Ver opciones de reservas
az reservations reservation-order list

# Comprar reserva
az reservations reservation-order purchase \
  --reservation-order-id <order-id> \
  --sku Standard_D2s_v3 \
  --term P1Y \
  --quantity 3

Savings Plans (AWS, GCP Committed Use Discounts)

Ventaja sobre RIs: Flexibilidad; compromiso es por $ gastados/hora, no por instancias específicas.

AWS Savings Plans:

• Compute Savings Plans: aplica a EC2, Lambda, Fargate; hasta 66% descuento
• EC2 Instance Savings Plans: solo EC2; hasta 72% descuento pero más flexible que RI standard

bash# Ver recomendaciones de Savings Plans
aws ce get-savings-plans-purchase-recommendation \
  --savings-plans-type COMPUTE_SP \
  --term-in-years ONE_YEAR \
  --payment-option NO_UPFRONT

GCP Committed Use Discounts:

bash# Crear compromiso de uso
gcloud compute commitments create my-commitment \
  --region=us-central1 \
  --resources=vcpu=10,memory=40GB \
  --plan=12-month

Regla práctica: Si utilizas capacidad >75% del tiempo durante 1 año, Reserved/Committed tiene ROI positivo.

Spot Instances / Preemptible VMs (hasta 90% descuento)

Qué son: Capacidad de computación no utilizada que proveedores venden con gran descuento; pueden ser interrumpidas con aviso de 30-120 segundos.

Casos de uso ideales:

• Procesamiento batch (render de video, análisis de datos)
• CI/CD pipelines
• Workers de colas (SQS, Pub/Sub)
• Ambientes de dev/test
• Entrenamiento de modelos ML

AWS Spot Instances:

bash# Lanzar Spot Instance
aws ec2 run-instances \
  --image-id ami-xxxxx \
  --instance-type t3.medium \
  --instance-market-options '{"MarketType":"spot","SpotOptions":{"MaxPrice":"0.05","SpotInstanceType":"one-time"}}' \
  --count 1

Azure Spot VMs:

bashaz vm create \
  --resource-group myResourceGroup \
  --name mySpotVM \
  --image UbuntuLTS \
  --priority Spot \
  --max-price 0.05 \
  --eviction-policy Deallocate

GCP Preemptible VMs:

bashgcloud compute instances create my-preemptible-vm \
  --zone=us-central1-a \
  --preemptible \
  --machine-type=n1-standard-4

Estrategia avanzada: Combina on-demand + spot con auto-scaling; usa on-demand para baseline y spot para picos.

Fase 4: Optimización de Storage

Tiering automático de datos:

AWS S3 Intelligent-Tiering:

bash# Configurar lifecycle policy
aws s3api put-bucket-lifecycle-configuration \
  --bucket my-bucket \
  --lifecycle-configuration file://lifecycle.json

# lifecycle.json
{
  "Rules": [{
    "Id": "MoveToGlacier",
    "Status": "Enabled",
    "Transitions": [
      {
        "Days": 90,
        "StorageClass": "GLACIER"
      },
      {
        "Days": 365,
        "StorageClass": "DEEP_ARCHIVE"
      }
    ]
  }]
}

Costos por tier (por GB/mes):

• S3 Standard: $0.023
• S3 Infrequent Access: $0.0125 (45% más barato)
• S3 Glacier: $0.004 (83% más barato)
• S3 Glacier Deep Archive: $0.00099 (96% más barato)

Regla: Datos accedidos <1 vez/mes → IA; <1 vez/trimestre → Glacier; <1 vez/año → Deep Archive.

Azure Blob Storage Tiering:

bashaz storage blob set-tier \
  --account-name mystorageaccount \
  --container-name mycontainer \
  --name myblob \
  --tier Cool  # Hot, Cool, Archive

GCP Cloud Storage Classes:

bashgsutil lifecycle set lifecycle.json gs://my-bucket

# lifecycle.json
{
  "lifecycle": {
    "rule": [{
      "action": {"type": "SetStorageClass", "storageClass": "NEARLINE"},
      "condition": {"age": 30}
    }]
  }
}

Eliminar snapshots antiguos:

bash# AWS: Eliminar snapshots >90 días
aws ec2 describe-snapshots --owner-ids self \
  --query 'Snapshots[?StartTime<=`2025-07-27`].[SnapshotId]' \
  --output text | \
  xargs -I {} aws ec2 delete-snapshot --snapshot-id {}

# Azure: Eliminar snapshots viejos
az snapshot list --query "[?timeCreated<'2025-07-27']" | \
  jq -r '.[].id' | \
  xargs -I {} az snapshot delete --ids {}

Comprimir logs y archivos:

bash# Antes de subir a S3, comprimir
tar -czf logs-archive.tar.gz /var/log/app/*.log
aws s3 cp logs-archive.tar.gz s3://my-bucket/archives/

# Savings: logs.txt 1GB → logs.tar.gz 100MB = 90% reducción

Fase 5: Optimización de Bases de Datos

RDS/Azure SQL/Cloud SQL:

1. Rightsizing de instancias

bash# AWS RDS: Cambiar clase de instancia
aws rds modify-db-instance \
  --db-instance-identifier mydb \
  --db-instance-class db.t3.medium \
  --apply-immediately

2. Auto-scaling de storage

bash# Habilitar auto-scaling de storage RDS
aws rds modify-db-instance \
  --db-instance-identifier mydb \
  --max-allocated-storage 1000  # Se expande hasta 1TB según necesidad

3. Aurora Serverless (AWS) para tráfico variable

bashaws rds create-db-cluster \
  --db-cluster-identifier my-aurora-serverless \
  --engine aurora-mysql \
  --engine-mode serverless \
  --scaling-configuration MinCapacity=2,MaxCapacity=16,AutoPause=true

Savings: Aurora Serverless escala a cero en períodos sin actividad; ideal para dev/test ($0 cuando no se usa).

4. Read replicas para reducir carga en master

bashaws rds create-db-instance-read-replica \
  --db-instance-identifier mydb-replica \
  --source-db-instance-identifier mydb

DynamoDB on-demand vs provisioned:

bash# Cambiar a on-demand (pago por request)
aws dynamodb update-table \
  --table-name MyTable \
  --billing-mode PAY_PER_REQUEST

# O provisioned con auto-scaling
aws dynamodb update-table \
  --table-name MyTable \
  --billing-mode PROVISIONED \
  --provisioned-throughput ReadCapacityUnits=5,WriteCapacityUnits=5

Regla: On-demand si tráfico es impredecible; provisioned + auto-scaling si es predecible.

Fase 6: Automatización de Apagado de Recursos

Scheduler para dev/test environments:

AWS Lambda + EventBridge para auto-stop:

pythonimport boto3

ec2 = boto3.client('ec2')

def lambda_handler(event, context):
    # Detener instancias con tag Environment=dev
    instances = ec2.describe_instances(
        Filters=[{'Name': 'tag:Environment', 'Values': ['dev', 'test']}]
    )
    
    instance_ids = []
    for reservation in instances['Reservations']:
        for instance in reservation['Instances']:
            if instance['State']['Name'] == 'running':
                instance_ids.append(instance['InstanceId'])
    
    if instance_ids:
        ec2.stop_instances(InstanceIds=instance_ids)
        print(f'Stopped instances: {instance_ids}')
    
    return {'statusCode': 200, 'body': 'Instances stopped'}

EventBridge rule (ejecutar a las 8pm weekdays):

bashaws events put-rule \
  --name stop-dev-instances \
  --schedule-expression "cron(0 20 ? * MON-FRI *)"

aws events put-targets \
  --rule stop-dev-instances \
  --targets "Id=1,Arn=arn:aws:lambda:us-east-1:123456789:function:StopDevInstances"

Savings esperados: 10 instancias dev t3.medium ($0.0416/h) corriendo 24/7 = $303/mes; con scheduler (solo 8h/día weekdays) = $84/mes (72% reducción).

Azure Automation para auto-shutdown:

bashaz vm auto-shutdown \
  --resource-group myResourceGroup \
  --name myVM \
  --time 1900 \
  --timezone "Eastern Standard Time"

GCP Instance Schedules:

bashgcloud compute resource-policies create instance-schedule dev-schedule \
  --region=us-central1 \
  --vm-start-schedule="0 8 * * 1-5" \
  --vm-stop-schedule="0 18 * * 1-5" \
  --timezone="America/New_York"

Fase 7: Gobernanza y FinOps

Implementar tagging strategy:

Tags obligatorios:

• Environment: production, staging, dev, test
• Team: backend, frontend, data, infra
• Project: project-alpha, project-beta
• Owner: email del responsable
• CostCenter: departamento que paga

AWS Tag Policy:

json{
  "tags": {
    "Environment": {
      "tag_key": "Environment",
      "tag_value": ["production", "staging", "dev", "test"],
      "enforced_for": ["ec2:instance", "rds:db"]
    },
    "Owner": {
      "tag_key": "Owner",
      "enforced_for": ["*"]
    }
  }
}

Aplicar con AWS Organizations:

bashaws organizations enable-policy-type --policy-type TAG_POLICY
aws organizations create-policy \
  --name TaggingPolicy \
  --type TAG_POLICY \
  --content file://tag-policy.json

Presupuestos por equipo:

bash# Budget alerts por tag
aws budgets create-budget \
  --account-id 123456789 \
  --budget file://team-backend-budget.json

Cultura FinOps:

1. Visibilidad: Todos los equipos ven costos de sus recursos en tiempo real
2. Ownership: Cada equipo es responsable de su presupuesto cloud
3. Optimización continua: Revisión trimestral de costos con accionables
4. Incentivos: Bonos por equipos que reducen costos sin afectar KPIs

Herramientas de Optimización Recomendadas

Nativas de proveedores (gratis):

• AWS Cost Explorer + Trusted Advisor
• Azure Cost Management + Advisor
• GCP Cost Management + Recommender

Third-party (freemium/paid):

• CloudHealth (VMware): multi-cloud cost management
• Spot.io: optimización automatizada de instancias
• Kubecost: específico para Kubernetes
• Infracost: estimación de costos en Terraform antes de deploy
• Cloud Custodian: políticas automatizadas de compliance y cost

Checklist de Optimización (implementable en 30 días)

Semana 1: Discovery

•  Habilitar Cost Explorer/Cost Management
•  Identificar top 10 servicios más costosos
•  Auditar recursos idle (EC2, RDS, disks huérfanos)
•  Configurar billing alerts ($1k, $3k, $5k)

Semana 2: Quick Wins

•  Eliminar snapshots >90 días sin uso
•  Eliminar volúmenes/disks no adjuntos
•  Apagar instancias dev/test fuera de horario
•  Mover logs antiguos a storage tier económico

Semana 3: Rightsizing

•  Analizar utilización CPU/RAM últimos 30 días
•  Downsize 5 instancias con utilización <20%
•  Cambiar tipos de instancia mal ajustados
•  Implementar auto-scaling donde falta

Semana 4: Compromisos

•  Calcular ROI de Reserved Instances/Savings Plans
•  Comprar RI/SP para workloads predecibles
•  Migrar batch jobs a Spot/Preemptible
•  Implementar tagging strategy completo

Conclusión: Optimización como Proceso, No Evento

Optimizar costos cloud no es proyecto de una vez; es disciplina continua que debe integrarse en cultura de ingeniería y operaciones. Las tácticas de este artículo pueden reducir tu factura 40-70% en primeros 3-6 meses, pero sin gobernanza estructurada, costos volverán a crecer descontroladamente.

Implementa revisiones trimestrales de costos, automatiza apagado de recursos no productivos, educa a equipos sobre impacto de sus decisiones arquitectónicas en costos y celebra optimizaciones exitosas. El cloud es elástico; tus costos también deberían serlo.

Empieza esta semana: audita tus 5 recursos más costosos, identifica 3 quick wins (eliminar recursos idle, downsize instancias sobreprovisionadas, migrar storage antiguo a tiers económicos) y mide impacto en próxima factura. Optimización de costos cloud es de las pocas iniciativas tech con ROI inmediato y medible en dólares, no en métricas abstractas.