Optimización de costes AWS: guía práctica para reducir tu factura cloud

Las empresas desperdician un 32% de su gasto en cloud. No es una estimación pesimista: es el dato que publica Flexera en su informe State of the Cloud 2025 tras encuestar a 750 organizaciones. Si tu factura de AWS crece un 20-30% anual sin que el negocio crezca al mismo ritmo, no estás invirtiendo en infraestructura. Estás financiando ineficiencia.

El problema no es AWS. AWS ofrece herramientas suficientes para controlar cada céntimo. El problema es que la mayoría de equipos no las usa, no las configura correctamente, o directamente no sabe que existen. Este artículo recoge las estrategias que funcionan: herramientas nativas, modelos de contratación, optimización por servicio y la disciplina organizativa que separa a las empresas que controlan sus costes de las que los sufren.

Sin teoría abstracta. Con números, ejemplos y acciones concretas que puedes aplicar esta semana.

Las herramientas nativas de AWS para control de costes

AWS ofrece cinco herramientas principales para monitorizar y optimizar costes. Todas están incluidas en la cuenta sin coste adicional (con limitaciones en algunos casos). El primer paso de cualquier optimización es activarlas y configurarlas correctamente.

AWS Cost Explorer: visualización y análisis

Cost Explorer es el punto de partida. Permite visualizar el gasto por servicio, cuenta, región, tag o periodo de tiempo. Sus funciones principales:

• Desglose por servicio: Identifica qué servicios consumen más presupuesto. En la mayoría de cuentas, EC2, RDS y Data Transfer representan el 70-80% de la factura.
• Tendencias mensuales: Compara el gasto mes a mes para detectar crecimientos anómalos antes de que se consoliden.
• Previsiones: Cost Explorer proyecta el gasto del mes actual basándose en el patrón de uso. Si a día 10 ya llevas el 50% del presupuesto, lo verás aquí.
• Filtrado granular: Filtra por cuenta vinculada, servicio, tipo de instancia, zona de disponibilidad o tag.

Configuración esencial: Activa Cost Explorer desde la cuenta de gestión (management account) de tu organización. Si usas AWS Organizations con múltiples cuentas, habilita el acceso consolidado para ver el gasto agregado.

AWS Budgets: alertas proactivas

AWS Budgets permite definir presupuestos mensuales y configurar alertas automáticas cuando el gasto alcanza ciertos umbrales. Es la primera línea de defensa contra facturas inesperadas.

Configuración recomendada:

• Crea un presupuesto mensual general con alertas al 50%, 80% y 100%.
• Crea presupuestos por servicio para los tres servicios que más consumen.
• Configura alertas por email y, si es posible, por Slack o SNS para notificación inmediata.
• Activa las alertas de previsión (forecasted alerts): te avisan si el patrón de gasto actual proyecta superar el presupuesto al final del mes.

AWS Budgets permite crear hasta dos presupuestos gratuitos por cuenta. Los presupuestos adicionales cuestan 0,02 dolares al dia cada uno. Para la mayoría de equipos, dos presupuestos son suficientes para empezar.

AWS Trusted Advisor: recomendaciones automáticas

Trusted Advisor analiza tu cuenta y genera recomendaciones en cinco categorías: costes, rendimiento, seguridad, tolerancia a fallos y limites de servicio. Para optimización de costes, las comprobaciones mas útiles son:

• Instancias EC2 infrautilizadas: Detecta instancias con utilización de CPU inferior al 10% durante 14 días.
• Volúmenes EBS no adjuntos: Identifica volúmenes de almacenamiento huérfanos que siguen generando coste.
• Elastic IPs no asociadas: Cada IP elástica no vinculada a una instancia cuesta 0,005 dolares por hora (3,60 dolares al mes).
• Load balancers inactivos: Detecta balanceadores sin tráfico.
• Savings Plans y Reserved Instances: Sugiere compromisos de ahorro basados en tu uso real.

Limitación: El plan Basic de AWS solo incluye un subconjunto de comprobaciones. Las comprobaciones completas de costes requieren el plan Business Support (desde 100 dolares al mes o el 10% del gasto mensual). Si tu factura mensual supera los 5.000 dolares, el Business Support se paga solo con las recomendaciones que genera.

AWS Compute Optimizer: right-sizing

Compute Optimizer analiza el uso real de tus recursos de compute y recomienda el tipo y tamaño de instancia óptimo. Soporta:

• EC2: Recomienda cambiar de tipo de instancia basándose en CPU, memoria y red.
• EBS: Sugiere el tipo de volumen óptimo (gp3 vs gp2, io1 vs io2).
• Lambda: Recomienda la configuración de memoria óptima para cada función.
• ECS en Fargate: Sugiere la combinación de CPU/memoria correcta para tus tareas.

Dato clave: El 40% de las instancias EC2 están sobredimensionadas, según los propios datos de AWS. Si lanzaste una m5.xlarge porque no sabías cuánta capacidad necesitabas, es probable que una m5.large (la mitad de coste) sea suficiente. Compute Optimizer te da el dato exacto.

Cost Allocation Tags: atribución por equipo y proyecto

Los tags son la base de la visibilidad financiera. Sin tags, sabes cuánto gastas en EC2. Con tags, sabes cuánto gasta cada equipo, cada proyecto y cada entorno en EC2.

Estrategia de tagging recomendada:

Implementación: Activa los tags como Cost Allocation Tags en la consola de Billing. Define una política de tagging obligatoria usando AWS Organizations SCPs (Service Control Policies) para evitar que se lancen recursos sin tags. Los recursos sin etiquetar acaban en un agujero negro contable.

Reserved Instances vs Savings Plans vs Spot: cuándo usar cada uno

La elección del modelo de contratación puede reducir la factura entre un 30% y un 90%, dependiendo de la carga de trabajo. Cada modelo tiene casos de uso específicos y elegir mal puede significar pagar por compromiso sin obtener beneficio.

Reserved Instances: compromiso por servicio específico

Las Reserved Instances (RIs) ofrecen descuento a cambio de un compromiso de uso de 1 o 3 años para un tipo de instancia y región concretos.

• Descuento: 30-40% (1 año, sin pago anticipado) hasta 72% (3 años, todo anticipado).
• Modalidades de pago: Sin pago anticipado, pago parcial anticipado, todo anticipado. A mayor anticipación, mayor descuento.
• Rigidez: Estás comprometido con un tipo de instancia en una región. Si cambias de m5.large a m6i.large, la reserva original no aplica.

Cuándo usar RIs: Para bases de datos RDS o ElastiCache que ejecutas 24/7 sin variación. Son los candidatos ideales porque raramente cambias el tipo de instancia de una base de datos en producción.

Savings Plans: flexibilidad con compromiso de gasto

Los Savings Plans ofrecen descuentos similares a las RIs pero con mayor flexibilidad. En lugar de comprometerte con un tipo de instancia, te comprometes con un gasto mínimo por hora en dolares.

Existen dos tipos:

• Compute Savings Plans: Aplican a cualquier uso de EC2, Fargate y Lambda, independientemente de región, familia de instancia o sistema operativo. Descuento del 20-66%.
• EC2 Instance Savings Plans: Solo EC2, con flexibilidad de tamaño dentro de una familia y región. Descuento del 30-72%.

Cuándo usar Savings Plans: Para cargas de compute generales donde puedes predecir un gasto base estable. Si sabes que vas a gastar al menos 500 dolares al mes en compute, un Savings Plan de 0,68 dolares por hora te ahorra un 30-40% sobre ese base.

Spot Instances: el descuento máximo con condiciones

Las Spot Instances permiten usar capacidad sobrante de AWS con descuentos de hasta el 90% sobre el precio on-demand. A cambio, AWS puede reclamar la instancia con un aviso de 2 minutos.

• Descuento: 60-90% sobre on-demand.
• Riesgo: Interrupción con 2 minutos de aviso.
• Mitigación: Usar Spot Fleet con diversificación de tipos de instancia y zonas de disponibilidad.

Cuándo usar Spot: Pipelines de CI/CD, procesamiento batch, entrenamiento de modelos de machine learning, workers de colas de mensajes, y cualquier carga que pueda interrumpirse y reiniciarse sin perder estado.

On-demand: el precio completo tiene su lugar

On-demand no requiere compromiso y es el modelo más caro. Pero tiene sentido para:

• Entornos de desarrollo y staging que se encienden y apagan.
• Picos de tráfico impredecibles que superan la capacidad reservada.
• Pruebas de nuevas arquitecturas o migraciones.
• Cualquier carga cuyo patrón de uso aún no conoces.

Tabla comparativa

Estrategia combinada: La mayoría de empresas optimizadas usan una combinación. Savings Plans cubren el gasto base estable, Spot para cargas tolerantes a interrupción, y on-demand para el resto. Las RIs quedan reservadas para bases de datos donde el tipo de instancia es predecible a largo plazo.

Optimización por servicio: dónde se esconde el desperdicio

Cada servicio de AWS tiene patrones de desperdicio específicos. Estos son los más comunes y cómo resolverlos.

EC2: instancias sobredimensionadas y zombis

Problema 1 - Sobredimensionamiento: El 40% de las instancias están sobredimensionadas. Los equipos eligen instancias grandes “por si acaso” y nunca las reducen.

Solución: Revisa Compute Optimizer mensualmente. Si la utilización media de CPU es inferior al 40% y la memoria usada no supera el 50%, reduce un tamaño. Pasa de m5.xlarge a m5.large. El ahorro es del 50% directo.

Problema 2 - Instancias zombi: Instancias de desarrollo, pruebas o demos que nadie apagó. Se quedan ejecutándose durante meses sin que nadie las use.

Solución: Implementa Instance Scheduler o una Lambda programada que apague instancias de desarrollo fuera de horario laboral (18:00-08:00 y fines de semana). Esto reduce el coste de instancias de desarrollo un 65%.

RDS: Multi-AZ innecesario y almacenamiento no optimizado

Problema 1 - Multi-AZ en entornos no productivos: Multi-AZ duplica el coste de la instancia RDS. Tenerlo activado en staging o desarrollo es dinero tirado.

Solución: Limita Multi-AZ exclusivamente a producción. En staging, usa una instancia Single-AZ con snapshots automáticos.

Problema 2 - Almacenamiento provisionado sin usar: Las bases de datos RDS con almacenamiento tipo io1/io2 cobran por IOPS provisionadas, las uses o no.

Solución: Migra a gp3 salvo que necesites consistentemente más de 16.000 IOPS. gp3 ofrece 3.000 IOPS base gratis y cuesta un 20% menos que gp2.

S3: lifecycle policies e intelligent tiering

Problema: Datos que se almacenan en S3 Standard para siempre, aunque nadie los acceda después del primer mes.

S3 ofrece múltiples clases de almacenamiento con costes muy diferentes:

Solución 1 - Lifecycle policies: Configura reglas automáticas para mover objetos entre clases:

• Después de 30 días sin acceso: mover a S3 Infrequent Access.
• Después de 90 días: mover a S3 Glacier Instant Access.
• Después de 365 días: mover a S3 Glacier Deep Archive o eliminar.

Solución 2 - S3 Intelligent-Tiering: Si no conoces los patrones de acceso, activa Intelligent-Tiering. AWS mueve automáticamente los objetos entre clases según el acceso real. Cuesta 0,0025 dolares por cada 1.000 objetos monitorizados al mes, pero el ahorro en almacenamiento compensa con creces en buckets grandes.

Lambda: right-sizing de memoria y concurrencia

Problema 1 - Memoria mal configurada: Lambda cobra por milisegundo de ejecución multiplicado por la memoria asignada. Asignar 1.024 MB a una función que necesita 256 MB cuadruplica el coste.

Solución: Usa AWS Lambda Power Tuning, una herramienta open source que ejecuta tu función con diferentes configuraciones de memoria y te muestra el punto óptimo de coste/rendimiento. En muchos casos, más memoria significa ejecución más rápida, y el coste total puede ser menor con más memoria pero menos tiempo.

Problema 2 - Concurrencia reservada innecesaria: La concurrencia reservada garantiza capacidad pero cobra aunque no la uses.

Solución: Usa Provisioned Concurrency solo para funciones con requisitos estrictos de latencia en cold start. Para el resto, la concurrencia por defecto de Lambda es suficiente.

NAT Gateway: el gasto silencioso

Problema: Cada NAT Gateway cuesta 0,045 dolares por hora (32,40 dolares al mes) más 0,045 dolares por GB procesado. Si tienes un NAT Gateway por zona de disponibilidad en tres AZs, son 97,20 dolares al mes solo por existir, sin contar el tráfico.

Solución: Usa VPC Endpoints para el tráfico hacia servicios de AWS (S3, DynamoDB, SQS, etc.). Un VPC Endpoint Gateway para S3 o DynamoDB es gratuito. Un VPC Endpoint Interface cuesta 0,01 dolares por hora por AZ (7,20 dolares al mes), que es significativamente menos que un NAT Gateway para tráfico de alto volumen hacia servicios AWS.

Data Transfer: los costes ocultos entre AZs y regiones

Problema: El tráfico entre zonas de disponibilidad cuesta 0,01 dolares por GB en cada dirección. El tráfico entre regiones cuesta entre 0,02 y 0,09 dolares por GB. Para aplicaciones que mueven terabytes de datos internamente, estos costes se acumulan.

Solución:

• Minimiza la comunicación cross-AZ. Si dos servicios se comunican intensamente, colócalos en la misma AZ.
• Usa CloudFront para servir contenido estático en lugar de hacerlo directamente desde S3 o EC2. La transferencia desde CloudFront es más barata que desde el origen.
• Comprime los datos antes de transferirlos entre regiones. La compresión gzip o zstd puede reducir el volumen transferido un 70-80%.

FinOps: la disciplina que falta en las startups

La optimización de costes no es un proyecto puntual. Es una práctica continua. FinOps (Financial Operations) es la disciplina que estructura esta práctica.

Qué es FinOps y por qué importa

FinOps es la práctica de gestionar el coste cloud como una variable operativa, no como un gasto fijo. En el modelo tradicional de infraestructura, compras servidores y los amortizas. En cloud, cada decisión de ingeniería tiene un impacto directo en la factura. Un deploy mal configurado un viernes puede costar miles de euros el lunes.

La FinOps Foundation define tres principios fundamentales:

1. Los equipos deben ser responsables de su propio gasto cloud. No es solo cosa de finanzas o de infraestructura.
2. Las decisiones se toman en base al valor de negocio del cloud, no solo en base al coste.
3. El cloud es un modelo de gasto variable que debe gestionarse activamente, no pasivamente.

Cultura de responsabilidad compartida

El mayor obstáculo para controlar costes no es técnico. Es organizativo. Si el equipo que provisiona recursos no ve la factura, no tiene incentivos para optimizar.

Implementación práctica:

• Publica dashboards de coste visibles para todos los equipos de ingeniería.
• Incluye el coste cloud en las retrospectivas de sprint.
• Asigna un “FinOps champion” por equipo que revise el gasto semanalmente.
• Establece presupuestos por equipo usando tags y AWS Budgets.

Ciclo FinOps: Inform, Optimize, Operate

El ciclo FinOps consta de tres fases:

Inform: Obtener visibilidad del gasto. Quién gasta, en qué, y por qué. Aquí entran Cost Explorer, tags y dashboards.

Optimize: Actuar sobre las ineficiencias. Right-sizing, Savings Plans, lifecycle policies, eliminación de recursos no usados.

Operate: Mantener la disciplina. Automatizaciones, políticas de gobernanza, alertas y revisiones periódicas.

El error más común es ejecutar un proyecto puntual de optimización (fase Optimize) sin establecer la visibilidad (Inform) ni la operativa continua (Operate). El resultado: los costes bajan temporalmente y vuelven a subir en 3-6 meses.

Métricas clave: unit economics del cloud

El gasto total es una métrica incompleta. Lo relevante es el coste unitario:

• Coste por usuario activo: Si tu SaaS tiene 10.000 usuarios y gastas 3.000 dolares al mes en AWS, tu coste de infraestructura por usuario es 0,30 dolares.
• Coste por transacción: Para plataformas transaccionales, el coste por operación procesada.
• Coste por request: Para APIs, cuánto cuesta servir cada petición.

Estas métricas permiten evaluar si el gasto escala linealmente con el negocio (aceptable) o si crece más rápido que los ingresos (problema).

Caso práctico: de 5.000 a 2.100 dolares al mes

Este caso está basado en un patrón que vemos repetidamente en startups SaaS en fase de crecimiento temprano.

Situación inicial

Startup SaaS B2B con 15.000 usuarios activos mensuales. Infraestructura en AWS con factura mensual de 5.000 dolares y creciendo un 25% trimestral sin que la base de usuarios creciera al mismo ritmo.

Infraestructura antes de la auditoría:

• 4 instancias EC2 m5.xlarge (producción) ejecutándose 24/7
• 2 instancias EC2 m5.large (staging) ejecutándose 24/7
• 1 RDS db.r5.xlarge Multi-AZ (producción)
• 1 RDS db.r5.large Multi-AZ (staging)
• S3 con 2 TB de datos, todo en Standard
• 3 NAT Gateways (uno por AZ)
• Sin Savings Plans ni Reserved Instances
• Sin lifecycle policies en S3
• Sin tags de atribución de costes

Auditoría y diagnóstico

El análisis de Compute Optimizer y Cost Explorer reveló:

1. Las instancias EC2 de producción tenían una utilización media de CPU del 18% y memoria al 35%.
2. Las instancias de staging se ejecutaban 24/7 pero solo se usaban en horario laboral.
3. La base de datos de staging tenía Multi-AZ activado sin necesidad.
4. El 80% de los datos en S3 no se habían accedido en los últimos 90 días.
5. Los NAT Gateways procesaban tráfico hacia S3 y DynamoDB que podía ir por VPC Endpoints.

Acciones ejecutadas

Semana 1 - Quick wins (ahorro: 1.200 dolares al mes):

• Right-sizing EC2 producción: de m5.xlarge a m5.large (utilización sube al 35%, todavía holgada). Ahorro: 540 dolares.
• Apagar staging fuera de horario laboral con Instance Scheduler. Ahorro: 320 dolares.
• Desactivar Multi-AZ en RDS de staging. Ahorro: 340 dolares.

Semana 2 - Almacenamiento (ahorro: 650 dolares al mes):

• Lifecycle policies en S3: mover a Infrequent Access tras 30 días, a Glacier Instant tras 90. Ahorro: 450 dolares.
• Migrar volúmenes EBS de gp2 a gp3. Ahorro: 120 dolares.
• Eliminar 3 snapshots de EBS obsoletos. Ahorro: 80 dolares.

Semana 3 - Red y compromisos (ahorro: 1.050 dolares al mes):

• VPC Endpoints para S3 y DynamoDB, eliminando un NAT Gateway. Ahorro: 150 dolares.
• Compute Savings Plan de 1 año para el gasto base estable. Ahorro: 900 dolares.

Resultado

Reducción del 61% en la factura mensual. El proceso completo tomó 3 semanas. El Savings Plan de 1 año se justificó con el historial de 6 meses de uso estable verificado en Cost Explorer.

Los 5 quick wins que puedes aplicar hoy

Si solo tienes una hora, ejecuta estos cinco pasos en orden:

1. Configura AWS Budgets con alertas al 50%, 80% y 100%. Tardas 5 minutos. Es la primera defensa contra facturas inesperadas.

2. Revisa las recomendaciones de Compute Optimizer para EC2. Identifica instancias sobredimensionadas y reduce un tamaño. El ahorro medio es del 30-50% por instancia.

3. Busca instancias zombi en Cost Explorer. Filtra por instancias EC2 con utilización de CPU inferior al 5% en los últimos 14 días. Apágalas o termínalas.

4. Activa S3 Lifecycle Policies en todos los buckets de producción. Mueve datos sin acceso reciente a clases de almacenamiento más baratas automáticamente.

5. Revisa tus Elastic IPs y volúmenes EBS no adjuntos en Trusted Advisor. Cada recurso huérfano es dinero que se pierde cada hora sin producir valor.

Checklist de optimización mensual

Ejecuta esta revisión el primer lunes de cada mes. Dedicar 2 horas mensuales a esta checklist puede ahorrarte miles de euros al trimestre.

1. Revisar Cost Explorer: comparar gasto del mes anterior con el presupuesto y con el mes anterior al ese.
2. Verificar alertas de AWS Budgets: asegurar que los umbrales siguen siendo relevantes.
3. Ejecutar las recomendaciones de Compute Optimizer pendientes.
4. Comprobar Trusted Advisor: actuar sobre las recomendaciones de costes nuevas.
5. Revisar instancias EC2 con utilización media de CPU inferior al 20%.
6. Verificar que todos los recursos nuevos del mes tienen tags de coste asignados.
7. Revisar el gasto en Data Transfer y buscar optimizaciones de red.
8. Evaluar si el uso estable actual justifica aumentar el compromiso de Savings Plans.
9. Comprobar que las lifecycle policies de S3 se están ejecutando correctamente.
10. Actualizar los dashboards de unit economics (coste por usuario, por transacción).

Conclusión

La optimización de costes en AWS no es un evento. Es una práctica. Las empresas que controlan su factura cloud no lo hacen porque tengan herramientas especiales o equipos dedicados de FinOps. Lo hacen porque han integrado la visibilidad de costes en su cultura de ingeniería: etiquetan recursos, revisan métricas mensualmente, eligen modelos de contratación adecuados y eliminan el desperdicio de forma sistemática.

Los números hablan por sí solos: right-sizing, Savings Plans, lifecycle policies y VPC endpoints pueden reducir una factura típica entre un 40% y un 60%. No requiere reescribir arquitecturas ni migrar de proveedor. Requiere disciplina, visibilidad y las herramientas correctas, que AWS ya te proporciona.

Si tu factura de AWS crece más rápido que tu negocio y no sabes por dónde empezar, en NERVICO realizamos auditorías de infraestructura cloud gratuitas donde analizamos tu cuenta, identificamos las fuentes de desperdicio y te entregamos un plan de acción priorizado con el ahorro estimado por cada acción.

Fuentes:

1. AWS Cost Optimization - Well-Architected Framework - Amazon Web Services
2. State of the Cloud Report 2025: 32% of cloud spend wasted - Flexera
3. AWS Pricing: Savings Plans - Amazon Web Services
4. FinOps Foundation: What is FinOps - FinOps Foundation
5. AWS Compute Optimizer - Amazon Web Services
6. AWS Cost Management Tools - Amazon Web Services