Optimización de costos cloud: guía completa del programa

Resumen

La optimización de costos cloud es la práctica de reducir el gasto en infraestructura sin degradar el rendimiento ni la confiabilidad de la que dependen tus usuarios. Mezcla palancas técnicas (tipos de instancia, clases de almacenamiento, modelos de compra) con organizativas (etiquetado, chargeback, cultura de ingeniería consciente del costo).

Esta guía es el programa: un proceso de siete pasos que ejecutas de forma continua, más un ejemplo trabajado con números reales. Si quieres primero los comandos y scripts listos para copiar, la receta de optimización de costos tiene los quick wins. Si solo usas AWS, la guía de optimización de costos AWS profundiza en ese proveedor. Para la disciplina organizativa (modelo de madurez, KPIs de equipo, reporting a dirección) mira la guía de FinOps.

Una expectativa realista para una primera pasada: 20–40% de la factura. He visto equipos llegar al tope de ese rango solo programando entornos dev y borrando almacenamiento huérfano, antes de tocar una sola instancia reservada.

Cuándo usarla

Recurre a esta guía cuando:

• Tu factura cloud crece más rápido que tu base de usuarios o tus ingresos
• Tienes recursos sin usar o subutilizados corriendo 24/7
• Nadie puede atribuir el gasto a un equipo; cada revisión de factura se convierte en arqueología
• Estás preparando una revisión o auditoría de presupuesto de infraestructura
• Estás migrando cargas de trabajo y quieres optimizar desde el día uno en lugar de heredar desperdicio

Conceptos clave

Seis palancas producen casi todo el ahorro. Entiéndelas antes de tocar nada:

Concepto	Qué significa	Palanca típica
Right-sizing	Ajustar capacidad del recurso al uso medido	Reducir instancias bajo ~40% de CPU
Capacidad reservada	Compromiso prepagado con descuento	RI de 1–3 años, Savings Plans
Spot/preemptible	Capacidad sobrante vendida con grandes descuentos	Batch, agentes de CI, servicios sin estado
Tiering de almacenamiento	Mover datos fríos a clases más baratas	S3 IA, Glacier, políticas de ciclo de vida
Etiquetado	Marcar recursos con dueño, equipo, entorno	Hace posible el chargeback y la responsabilidad
FinOps	El modelo operativo que hace que se mantenga	Presupuestos, revisiones, KPIs compartidos

Las cinco primeras son técnicas: puedes ejecutarlas esta semana. La última es lo que evita que el ahorro se evapore el próximo trimestre.

El programa de siete pasos

1. Obtén visibilidad del gasto actual

No puedes optimizar lo que no puedes atribuir. Empieza respondiendo tres preguntas: qué servicios cuestan más, qué entornos los impulsan y qué equipos son dueños de ellos.

# AWS Cost Explorer: gasto agrupado por servicio
aws ce get-cost-and-usage \
  --time-period Start=2026-01-01,End=2026-06-01 \
  --granularity MONTHLY \
  --metrics BlendedCost \
  --group-by Type=DIMENSION,Key=SERVICE

# Equivalente en Azure
az costmanagement query \
  --type ActualCost \
  --timeframe MonthToDate \
  --dataset-granularity Daily

Los reportes que de verdad importan:

• Gasto por servicio: normalmente 2–3 servicios cubren el 80% de la factura (cómputo, almacenamiento, transferencia)
• Gasto por entorno: lo no-productivo es casi siempre el 30–50% del gasto total
• Gasto por equipo o centro de costo: imposible sin tags, por eso existe el paso 6
• Reporte de recursos ociosos: volúmenes desasociados, IPs sin asociar, balanceadores olvidados

Para cargas serverless, combina esta revisión con una estimación previa: la plantilla de estimación de costos serverless pone precio a la carga antes del despliegue, así los reportes de Cost Explorer tienen una línea base con la que conciliar.

Hay dos cosas que los reportes no te dirán directamente: si el gasto es útil, y quién debería ser su dueño. Una factura de $5,000 en un pipeline de datos puede estar perfectamente justificada o ser puro desperdicio según si alguien lee la salida. Esa valoración la necesita el equipo que construyó la carga, y es exactamente por eso que el paso 6 (etiquetado y chargeback) es un prerrequisito para la optimización sostenida y no un extra opcional.

2. Right-size del cómputo

Las instancias sobredimensionadas son el patrón de desperdicio más común. La trampa: los equipos miran el CPU promedio, ven 15%, y concluyen que la instancia está ociosa. Los promedios mienten: un worker de batch que pica al 90% una hora y descansa el resto sigue necesitando ese margen. Mira la utilización p95 en 30 días, no la media.

# Detecta instancias subutilizadas usando p95, no el promedio
import pandas as pd

df = pd.read_csv('instance_metrics.csv')  # 30 días de CloudWatch/Azure Monitor

# p95 bajo 40% de CPU en 30 días = candidata a reducción
candidates = df[df['cpu_p95'] < 40]

for _, row in candidates.iterrows():
    print(f"{row['instance_id']} ({row['instance_type']}): "
          f"p95 CPU {row['cpu_p95']:.1f}% — reduce o termina")

Pautas de right-sizing que aguantan en la práctica:

• Revisa mensualmente; apunta a 40–70% de utilización sostenida, no a un número fijo
• Las familias burstable (AWS serie T, Azure serie B) encajan con cargas irregulares porque acumulan créditos de CPU en los periodos ociosos
• Dev y staging pueden reducirse agresivamente; nadie nota 2 vCPU contra 4 en una caja de pruebas
• Las instancias ARM (AWS Graviton, Azure Ampere) dan 20–40% mejor precio-rendimiento para la mayoría de cargas Linux, pero verifica primero que tus dependencias compilan para ARM

3. Compra capacidad reservada estratégicamente

Cuando el right-sizing estabilice tu línea base, comprométete a ella. Comprar reservas antes del right-sizing congela exactamente el desperdicio que intentabas eliminar.

Tipo de compra	Descuento	Flexibilidad	Mejor para
RI estándar	Hasta 72%	Baja (región + familia específicas)	Bases de producción estables
RI convertible	Hasta 54%	Media (cambiar de familia)	Cargas predecibles pero cambiantes
Savings Plans	Hasta 72%	Alta (cualquier uso en el ámbito)	Cargas mixtas y flexibles

# Matemática del punto de equilibrio (números reales)
# On-demand: $0.192/hora ≈ $140/mes
# RI 1 año, todo por adelantado: ≈ $85/mes
# RI 1 año, pago parcial: ≈ $90/mes
# Punto de equilibrio: 7–8 meses — no compres si la carga muere antes

Reglas que evitan errores caros:

• Solo reserva capacidad que corre >70% del tiempo; una RI sobre una caja ociosa es una pérdida garantizada
• Empieza con pago parcial para preservar el flujo de caja; el pago total ahorra ~5% más
• Prefiere Savings Plans cuando la carga pueda cambiar de forma (otro right-sizing, migración a ARM, cambios de región)
• Revisa la cobertura de reservas trimestralmente: menos del 70% de cobertura significa gasto on-demand desperdiciado, menos del 90% de utilización significa compromiso varado

4. Usa capacidad spot y preemptible

La capacidad interrumpible cambia confiabilidad por descuentos del 60–90%. El truco: el cloud puede reclamarla con ~2 minutos de aviso (AWS) o ~30 segundos (GCP).

# NodePool de Karpenter pidiendo capacidad spot
apiVersion: karpenter.sh/v1beta1
kind: NodePool
metadata:
  name: spot-workloads
spec:
  template:
    spec:
      requirements:
        - key: karpenter.sh/capacity-type
          operator: In
          values: ["spot"]
      nodeClassRef:
        name: default
  limits:
    cpu: 1000
    memory: 1000Gi

Cargas que toleran la interrupción: procesamiento batch, agentes de build de CI, servicios sin estado tras un balanceador, entrenamiento de ML con checkpointing, dev/test. Las que no: bases de datos, colas, cualquier cosa con estado en memoria, servicios singleton.

Diseña para el desalojo, no esperes que no ocurra: reparte entre 5+ familias de instancias y 2–3 AZs (los pools de capacidad son por familia por AZ, así que la diversidad es lo que de verdad reduce la frecuencia de interrupciones), mantén una base on-demand para las réplicas críticas, y maneja bien el aviso de interrupción. En AWS el aviso llega como warning de dos minutos vía metadata de instancia y EventBridge; los autoscalers de Kubernetes y los node groups gestionados lo traducen en un drain. Una carga que hace checkpoint de su progreso (o es lo bastante idempotente para simplemente reintentar) trata el desalojo como una ralentización, no como un fallo. Una carga que muere a mitad de trabajo y pierde estado convierte el 70% de descuento en un incidente de confiabilidad.

5. Optimiza almacenamiento y transferencia de datos

El almacenamiento crece en silencio: es la línea que nadie revisa hasta que es la segunda más grande de la factura.

Estrategia	Qué hace	Ahorro típico
Tiering	Datos fríos → clases más baratas	50–80% en objetos fríos
Compresión	Payloads más pequeños almacenados	60–90% en logs/backups
Deduplicación	Sin copias redundantes	30–50% en backups
Políticas de ciclo de vida	Transición/borrado automático por antigüedad	Configura y olvida
Right-size de volúmenes	Reducir discos sobreaprovisionados	20–40%

// Ciclo de vida S3: archiva logs a tiers más baratos automáticamente
{
  "Rules": [{
    "ID": "LogArchive",
    "Status": "Enabled",
    "Filter": { "Prefix": "logs/" },
    "Transitions": [
      { "Days": 30, "StorageClass": "STANDARD_IA" },
      { "Days": 90, "StorageClass": "GLACIER" }
    ],
    "Expiration": { "Days": 365 }
  }]
}

No olvides la transferencia de datos: tráfico cross-AZ (~$0.01/GB en cada dirección), cross-region ($0.02–0.09/GB) y tarifas de procesamiento de NAT Gateway superan a menudo los costos de cómputo de microservicios parlanchines. Co-ubicar en la misma AZ y usar VPC endpoints para S3/DynamoDB elimina líneas enteras de la factura.

6. Fuerza etiquetado y chargeback

La visibilidad sin propiedad se degrada. Los tags son cómo “la factura” se convierte en “la factura del equipo X”, y el comportamiento cambia rápido cuando el gasto lleva nombre.

Tags obligatorios a forzar:

• Environment: production, staging, development
• CostCenter: equipo o departamento que paga
• Owner: contacto humano del recurso
• Project: aplicación o proyecto al que pertenece
• AutoShutdown: sí/no para recursos no productivos

# Encuentra recursos sin etiquetar antes de que lo haga finanzas
aws resourcegroupstaggingapi get-resources \
  --resources-per-page 100 | \
  jq '.ResourceTagMappingList[] | select(.Tags | length == 0) | .ResourceARN'

# Verifica que una política de etiquetado se propagó de verdad
aws resourcegroupstaggingapi get-resources \
  --tag-filters Key=Environment,Values=development \
  --resource-type-filters ec2:instance

El enforcement gana a los recordatorios: bloquea la creación de recursos sin tags con SCPs en AWS Organizations (o Azure Policy), y haz los tags obligatorios en los módulos de Terraform: una variable required_tags sin default hace fallar el plan antes de que el recurso exista. Etiquetar a posteriori los recursos ya creados es la parte tediosa; etiqueta en masa con la Resource Groups Tagging API y espera que la primera pasada se pierda casos límite como recursos creados a mano desde la consola.

Una vez forzado el etiquetado, la plantilla de asignación de costos lo convierte en cifras por equipo: reglas de reparto de costos compartidos, formato de reporte mensual y gestión de disputas.

7. Monitoriza continuamente, alerta pronto

La optimización de costos no es un proyecto trimestral; es un problema de monitorización. El objetivo es cazar la deriva cuando es una anomalía de $50, no una factura de $5,000.

Alerta	Umbral	Respuesta
Anomalía de gasto diario	>20% sobre la media de 30 días	Investigar el mismo día
Umbral de presupuesto	80% del presupuesto mensual	Notificar al equipo dueño
Crecimiento de recursos	Nuevos recursos >$500/día	Requerir aprobación
Recursos ociosos	<5% CPU durante 7 días	Auto-etiquetar para revisión

Vale la pena activar la detección nativa de anomalías (AWS Cost Anomaly Detection, equivalentes en GCP y Azure), ya que captura la clase de incidente “alguien dejó una p3.16xlarge corriendo el fin de semana” que las alertas por umbral se pierden. Combínala con una cadencia de revisión ligera: vistazo semanal a los que más se mueven, reporte mensual por equipo, auditoría trimestral de capacidad reservada.

Ejemplo trabajado: una startup recorta $2,800/mes (35%)

Una startup de cinco servicios en AWS quemando $8K/mes, con el encargo de recortar 40% sin impacto a usuarios.

Fase 1, inventario: la distribución del gasto antes de tocar nada.

Servicio	Costo/mes	% del total	Etiquetado
EC2 (8 instancias)	$3,200	40%	Parcial
RDS PostgreSQL	$1,500	19%	Sí
ElastiCache	$800	10%	No
S3 (10TB)	$600	8%	Sí
ALB + NAT	$500	6%	No
Lambda	$400	5%	Sí
Otros	$1,000	12%	No

Fase 2, acciones priorizadas (por impacto, no por esfuerzo):

1. Right-size EC2: 4 instancias bajo 20% de p95 CPU reducidas, 2 bajo 10% terminadas → $1,200/mes
2. Instancias reservadas: 3 instancias always-on a RI de 1 año con ~40% dto → $600/mes
3. Ciclo de vida S3: objetos >30d a IA, >90d a Glacier → $300/mes
4. Spot para batch: 2 workers de procesamiento a spot con ~70% dto → $400/mes
5. Optimización NAT: acceso a S3 movido a VPC endpoint → $200/mes
6. Memoria Lambda: 1GB → 512MB tras medir la duración → $100/mes

Fase 3, total: $2,800/mes (35%). No llegaron al 40%, logrado con cero cambios visibles para el usuario.

Fase 4, gobernanza para que se mantenga: tags obligatorios (team, env, project, cost-center), alertas de presupuesto al 80% y 100%, reporte semanal de costos por equipo, revisión trimestral de RI.

Lecciones que se generalizan: la visibilidad va primero (la mitad del ahorro era invisible antes del inventario), el right-sizing es la victoria más rápida, RI solo para cargas always-on demostradas, las políticas de ciclo de vida son configura-y-olvida, y la gobernanza es lo que evita el regreso del gasto.

Igual de instructivo es lo que no tocaron: ElastiCache ($800) quedó intacto porque el caché estaba en el camino caliente de su endpoint más usado; optimizarlo habría sido un riesgo de rendimiento por quizá $150/mes. La factura de RDS ya era una instancia reservada bien dimensionada. Buena optimización de costos es también saber qué líneas ya están bien; perseguir el último 10% de una línea de $500 mientras ignoras una de $3,000 es cómo los programas pierden credibilidad.

Un despliegue realista de 90 días

No intentes ejecutar los siete pasos en la semana uno. La secuencia importa porque cada paso alimenta al siguiente:

• Semanas 1–2: visibilidad y tags. Activa los reportes de costos, despliega la política de etiquetado, corre el barrido de recursos ociosos. Resultado: una línea base y un desglose por servicio.
• Semanas 3–4: quick wins. Right-size de los candidatos obvios, programa los entornos dev, borra los huérfanos confirmados. Esto solo suele dar 15–25% y financia la credibilidad del programa.
• Mes 2: compromisos y spot. Con una línea base limpia, compra Savings Plans para el suelo estable y migra las cargas adecuadas a spot.
• Mes 3: gobernanza. Presupuestos y alertas de anomalías activos, reportes por equipo circulando, revisión trimestral en el calendario.

Saltarse la línea base e ir directo a los compromisos es el modo de fallo clásico: acabas con un Savings Plan dimensionado para el desperdicio que estabas a punto de eliminar.

Espera rendimientos decrecientes tras el primer ciclo. La primera pasada cosecha el desperdicio fácil; la segunda encuentra ítems más pequeños y difíciles, como re-arquitectura de transferencia de datos o costo unitario por request. Es normal. Lo que mantiene vivo el programa no es otro barrido heroico sino el aburrido bucle trimestral: re-baseline, ajustar la cobertura de compromisos, re-correr el barrido de ociosos y reportar la tendencia a quien sea dueño del presupuesto.

Lo que funciona

• Optimiza continuamente, no anualmente. Las revisiones mensuales cazan la deriva; las anuales solo la encuentran.
• Ataca primero el gasto más grande. Cómputo, luego almacenamiento, luego red. El orden de Pareto se cumple.
• Involucra a ingeniería pronto. La mayoría del ahorro requiere cambios de código o arquitectura, no solo ajustes de facturación.
• Mide el ahorro real. Rastrea reducciones efectivas contra la línea base, no recomendaciones proyectadas.
• Nunca cambies confiabilidad por ahorro marginal. Un 10% de ahorro que duplica tu tasa de incidentes sale caro.
• Automatiza el enforcement. Policy-as-code para tags, apagados y reglas de ciclo de vida gana a documentos de proceso que nadie lee.

Errores comunes

• Reservar antes del right-sizing. Las RI solo ahorran sobre capacidad que de verdad mantienes; comprométete después de la limpieza, no antes.
• Ignorar la transferencia de datos. Cross-AZ, egress y tarifas de NAT superan con regularidad los costos de cómputo que acaparan toda la atención.
• Sobreaprovisionar almacenamiento. Los volúmenes se crean al tamaño máximo y nunca se reducen; las facturas de EBS crecen para siempre.
• Descuidar los entornos dev. Dev/test consume rutinariamente 30–50% del gasto mientras producción recibe todo el escrutinio.
• Optimizar sin línea base. Si no puedes mostrar números de antes/después, el ahorro es inverificable y el programa pierde patrocinio.
• Limpiezas de una sola vez. Borrar recursos ociosos una vez, sin ciclo de revisión, garantiza que el desperdicio vuelva.

Variantes por proveedor

• AWS: Savings Plans, instancias Graviton, S3 Intelligent-Tiering, Cost Anomaly Detection, spot con Karpenter
• Azure: Hybrid Benefit (reusa licencias Windows/SQL), Reserved VM Instances, Spot VMs, recomendaciones de Azure Advisor
• GCP: Committed Use Discounts, VMs preemptibles/spot, Sustained Use Discounts (automáticos: los recibes gratis)
• Multi-cloud: compara precios unitarios por tipo de carga; el precio de egress difiere lo bastante como para cambiar decisiones de arquitectura

Conclusión

La optimización de costos cloud es una disciplina, no un proyecto. Los siete pasos de esta guía (visibilidad, right-sizing, compromisos, spot, almacenamiento, etiquetado, monitorización) funcionan como un bucle, no como una lista. Empieza con el inventario, toma las victorias rápidas (right-size, programación, borrar huérfanos) y luego construye la gobernanza que mantiene el ahorro.

La medida honesta de un programa que funciona no es una factura reducida; es que la siguiente factura también sea menor, y la de después también. Los equipos que lo logran tratan el costo como tratan la confiabilidad: una métrica con dueño, una cadencia de revisión y alertas cuando se desvía. Todo lo de esta guía está al servicio de ese ritmo operativo.

Ver también

• Receta de optimización de costos — los quick wins ejecutables (scripts, Terraform, alertas)
• Guía de FinOps — la disciplina organizativa y el modelo de madurez
• Guía completa de optimización de costos AWS — profundidad específica de AWS
• FinOps Foundation — las fases del framework y el canon de la comunidad
• Pilar de optimización de costos de AWS Well-Architected — el checklist canónico de AWS
• Repositorio companion — analizador de right-sizing y plantilla de inventario