SAA-C03

Deep Dive

Practicar ahora
D4 · Optimización de costos

Costos de cómputo: Reserved, Spot y Savings Plans

El 20% del examen (D4) evalúa cómo optimizar costos. Para cómputo, la clave es elegir el modelo de precio correcto según el patrón de uso: On-Demand (flexibilidad), Reserved/Savings Plans (carga constante), Spot (tolerante a interrupciones).

Icon-Architecture/48/Arch_Amazon-EC2_48

Modelos de precio EC2

EC2 tiene 5 modelos de precio. El examen presenta un escenario de uso y tienes que identificar cuál es el más eficiente en costo.

On-Demand

0%Ninguno

Mejor para

Apps nuevas, cargas impredecibles, dev/test cortos, picos ocasionales

No usar cuando

Cargas estables 24/7 — aquí es el más caro

Reserved Instances (1 año)

Hasta 40%1 año

Mejor para

Servidores web, bases de datos de producción con carga constante predecible

No usar cuando

Cargas variables o instancias que podrían no usarse todo el año

Reserved Instances (3 años)

Hasta 72%3 años (All Upfront)

Mejor para

Infraestructura crítica que definitivamente se usará 3 años. DBs, NAT Gateways.

No usar cuando

Si hay incertidumbre sobre la necesidad en 3 años

Savings Plans

Hasta 66% (Compute) / 72% (EC2)1 o 3 años ($/hora)

Mejor para

Organizaciones que quieren flexibilidad de tipo de instancia manteniendo el ahorro de Reserved

No usar cuando

Si necesitas ahorros específicos por instancia (EC2 RI pueden dar más descuento)

Spot Instances

Hasta 90%Ninguno (pero pueden terminarse)

Mejor para

Batch jobs, ML training, data processing, rendering, CI/CD — TOLERANTES A INTERRUPCIONES

No usar cuando

Aplicaciones con estado persistente, bases de datos, apps que no pueden reiniciarse

Icon-Architecture/48/Arch_Amazon-EC2_48

Savings Plans vs Reserved Instances

TipoAplica aFlexibilidadDescuento máximo
Compute Savings PlansEC2 (cualquier familia/región), Lambda, FargateMáxima — cualquier tipo de instancia, región, OSHasta 66%
EC2 Instance Savings PlansEC2 (familia específica en una región)Media — solo la familia/región comprometidaHasta 72%
Standard Reserved InstancesEC2 (tipo, AZ, OS específicos)Baja — tipo fijo, se puede vender en MarketplaceHasta 72%
Convertible Reserved InstancesEC2 (puede cambiar familia/OS)Media — convertible a otras familiasHasta 54%

Recomendación AWS

AWS recomienda Compute Savings Plans para la mayoría de cargas: más flexible que Reserved Instances (aplica automáticamente a EC2, Lambda y Fargate), descuento competitivo, y no te "ancla" a una familia/región específica. Reserved Instances solo conviene cuando necesitas la AZ específica (Capacity Reservation).

Icon-Architecture/48/Arch_Amazon-EC2_48

Estrategias con Spot Instances

Spot Fleet — diversificación de pools

Spot Fleet permite especificar múltiples tipos de instancias y AZs. AWS selecciona el pool con mejor precio/disponibilidad. Si un tipo se agota, lanza de otro pool automáticamente.

lowestPrice strategy

Maximiza el ahorro — elige el pool más barato en cada momento.

diversified strategy

Distribuye en múltiples pools — mejor disponibilidad, menos interrupciones simultáneas.

Spot Instance Interruptions

Cuando AWS necesita la capacidad de vuelta, da 2 minutos de aviso. Tu app debe manejar esto con checkpoints o diseño sin estado.

Prácticas recomendadas:

• Guardar progreso cada pocos minutos (checkpoints a S3)

• Diseñar tareas idempotentes (pueden reiniciarse)

• Usar ASG con EC2 Spot + On-Demand mix

ASG con Spot Mix (recomendado)

ASG con MixedInstancesPolicy: por ej. 20% On-Demand (base garantizada) + 80% Spot (ahorro máximo). Si Spot es interrumpida, el ASG lanza On-Demand temporalmente.

Icon-Architecture/48/Arch_AWS-Compute-Optimizer_48

Rightsizing y Compute Optimizer

Rightsizing = ajustar el tipo/tamaño de instancia al uso real. El error más común: provisionar instancias m5.4xlarge para workloads que usan 10% de CPU — un m5.large es suficiente y 8x más barato.

AWS Compute Optimizer

Analiza 14 días de métricas de CloudWatch y recomienda el tipo de instancia óptimo. Soporta EC2, Auto Scaling Groups, EBS y Lambda.

  • Identifica instancias over-provisioned y under-provisioned
  • Muestra el ahorro estimado al redimensionar
  • Tiene en cuenta patrones de uso (no solo promedio)

Cuándo NO hacer rightsizing

    Picos de tráfico ocasionales

    La instancia pequeña puede saturarse en el pico — usa ASG en su lugar.

    DBs con crecimiento esperado

    Mejor provisionar con margen para no migrar frecuentemente.

    Aplicaciones legacy con licencias

    Algunas licencias son por vCPU — verificar antes de reducir.

Icon-Architecture/48/Arch_Amazon-EC2_48

Optimización de Lambda y Fargate

Lambda — optimización de costos

Ajustar memoria

Lambda asigna CPU proporcional a memoria. Más memoria = más CPU = puede ser más barato si reduce duración.

ARM/Graviton2

Funciones Lambda ARM son ~20% más baratas y 10% más rápidas que x86. Migrar si el código es compatible.

Compute Savings Plans

Savings Plans aplican automáticamente a Lambda — sin configuración adicional necesaria.

Reducir cold starts

Provisioned Concurrency tiene costo fijo — calcular si vale vs. el costo de cold starts en la UX.

Fargate — optimización de costos

Fargate Spot

Fargate Spot = Spot Instances para containers ECS/EKS. Hasta 70% de descuento para tareas tolerantes a interrupciones.

Rightsizing de containers

Definir vCPU y memoria precisamente. No pedir 4 vCPUs para un container que usa 0.5.

Compute Savings Plans

También aplican a Fargate. Compromiso de $/hora reduce costos hasta 50%.

ARM/Graviton2

ECS Fargate soporta ARM — 20% de ahorro para el mismo rendimiento.

¿Entendiste este tema?

Pon a prueba lo que acabas de aprender

Una empresa tiene una flota de 50 instancias m5.4xlarge ejecutando aplicaciones de análisis de logs que procesan datos en lotes durante la noche (6 horas). Los trabajos pueden reiniciarse si se interrumpen. ¿Cuál es la estrategia de costo más efectiva?