Módulo 5: Domain 4 Cost Optimized Architectures
3. Task 4.2: cómputo costo-optimizado — Spot, RI y Savings Plans al detalle del examen
Descripción
finops-and-cost-guardrails-guide Módulo 7, lección 5, nombró los tres mecanismos de descuento por compromiso de AWS —Savings Plans, Reserved Instances y Spot Instances— con una honestidad puntual: ningún recurso real de Andes Cargo tiene, hoy, el uso sostenido y predecible que justificaría comprarlos. Esa lección los nombró a nivel de criterio de FinOps y siguió adelante. Esta lección hace exactamente lo que esa honestidad dejó pendiente: expande los tres mecanismos hasta el detalle exacto que una pregunta de examen exige —tabla comparativa completa de compromiso, descuento y riesgo de interrupción—, porque el examen sí pregunta esa comparación con precisión de detalle, incluso si Andes Cargo, hoy, no tiene ningún recurso al que aplicarla.
Conexión con el módulo
Vas a reconocer el mismo criterio de "uso sostenido y predecible" que ya usaste, con números reales, en finops-and-cost-guardrails-guide M7.3 para decidir entre PAY_PER_REQUEST y PROVISIONED en DynamoDB — es, con precisión, el mismo criterio de fondo, aplicado ahora a EC2/Fargate/Lambda. Además, vas a cerrar dos piezas que Task 4.2 nombra explícitamente y que ninguna lección anterior de esta guía tocó: EC2 Hibernation y AWS Outposts.
Los tres mecanismos, al detalle completo que el examen exige
finops-and-cost-guardrails-guide ya te dio la frase de cada uno. Esta tabla es la versión de examen — completa, comparable, con cada columna que una pregunta puede citar:
| Spot Instances | Reserved Instances (RI) | Savings Plans | |
|---|---|---|---|
| Qué comprometes | Nada — capacidad no reservada de AWS | Un tipo de instancia específico, en una región específica | Un monto de gasto en $/hora, sin importar el recurso |
| Descuento típico vs. On-Demand | Hasta 90% (verifica el actual — varía por tipo/región/momento) | Hasta 72% (verifica el actual) | Hasta 72% (verifica el actual) |
| Término de compromiso | Ninguno | 1 o 3 años | 1 o 3 años |
| Riesgo de interrupción | Alto — AWS puede interrumpir con 2 minutos de aviso cuando necesita esa capacidad de vuelta | Ninguno — la capacidad reservada es tuya durante el término | Ninguno — el descuento aplica sin condición de disponibilidad de capacidad |
| Flexibilidad de recurso | Ninguna — capacidad específica del momento | Standard: ninguna (tipo fijo) · Convertible: puedes cambiar de familia | Alta — Compute Savings Plans cubre EC2, Fargate y Lambda sin importar familia/SO/región; EC2 Instance Savings Plans atado a una familia y región, con descuento algo mayor |
| Servicios elegibles | EC2, Fargate, EMR, y otros con capacidad Spot | Principalmente EC2 (RDS/ElastiCache/Redshift tienen su propio modelo de RI, con sus propios descuentos) | EC2, Fargate, Lambda (Compute); SageMaker AI tiene su propio Savings Plan |
| Caso de uso correcto | Cargas tolerantes a interrupción: procesamiento por lotes, renderizado, entrenamiento de modelos interrumpible, colas de trabajo con reintento | Uso sostenido y predecible, tipo de instancia ya conocido y estable en el tiempo | Uso sostenido y predecible, con flexibilidad de arquitectura futura (cambiar de EC2 a Fargate, por ejemplo, sin perder el descuento) |
EL MISMO EJE, TRES PUNTOS
Sin compromiso ────────────────────────────────────────── Compromiso total
│ │
SPOT ON-DEMAND RI / SAVINGS PLANS
(mayor descuento, (sin descuento, (gran descuento,
mayor riesgo) sin riesgo) cero riesgo de
interrupción,
riesgo de pagar por
capacidad no usada)La decisión de examen, resumida en una regla que cubre la inmensa mayoría de preguntas: si el escenario describe una carga tolerante a interrupción (procesamiento por lotes sin urgencia de completarse en un momento exacto, renderizado, un trabajo que puede pausarse y retomarse sin daño), Spot es la respuesta — con el descuento más alto de los tres. Si el escenario describe uso sostenido, predecible, ya conocido (un servidor de aplicación corriendo 24/7 desde hace meses, con el mismo tipo de instancia), la pregunta se reduce a RI vs. Savings Plans: si el escenario menciona flexibilidad futura (posible cambio de familia de instancia, o de EC2 a Fargate/Lambda), Savings Plans gana; si el escenario no menciona ningún plan de cambio y busca el descuento máximo absoluto sobre un tipo de instancia ya decidido, RI Standard gana por un margen pequeño. Si el escenario no da ninguna señal de compromiso de largo plazo, ni de tolerancia a interrupción, On-Demand sigue siendo la respuesta correcta — comprometerse "por si acaso" es, exactamente, el error que finops-and-cost-guardrails-guide M7.5 ya identificó como el más común de los tres.
El criterio de fondo, el mismo que ya usaste con números reales
finops-and-cost-guardrails-guide M7.3 calculó, para Shipments, el punto de cruce exacto entre PAY_PER_REQUEST y PROVISIONED: ~760.000 solicitudes/mes — por debajo de ese volumen, pagar por uso real gana; por encima, comprometerse a capacidad reservada gana. Es el mismo tipo de cálculo, con el mismo criterio de fondo, que decide entre On-Demand y un compromiso de RI/Savings Plans: existe un volumen de uso sostenido a partir del cual el costo fijo del compromiso queda por debajo del costo variable acumulado de pagar por uso real. La diferencia entre DynamoDB y EC2/Fargate/Lambda no es el criterio —es idéntico— es la unidad que se compromete: capacidad de lectura/escritura en un caso, un tipo de instancia o un monto de $/hora en el otro.
La decisión de examen, la trampa más citada de este tema: comprar un compromiso de capacidad antes de tener datos reales de uso sostenido —"para asegurar el descuento"— es, según la misma lógica que M7.3 y M7.5 ya establecieron, sobreaprovisionar. Un escenario que describe una carga nueva, sin historial de tráfico, nunca tiene como respuesta correcta un compromiso de 1 o 3 años comprado de antemano — la respuesta correcta empieza en On-Demand, y el compromiso llega después, con datos medidos.
ALB, NLB y GWLB, revisitados desde el ángulo de costo
Task 4.2 nombra explícitamente "determining an appropriate load balancing strategy" entre sus habilidades. El Módulo 3, lección 3, ya construyó la diferencia técnica completa entre ALB (Capa 7), NLB (Capa 4) y GWLB (Capa 3-Gateway) — esta lección no la repite, agrega solo el ángulo de costo: verificado contra el modelo de precios oficial de Elastic Load Balancing, los tres tipos cobran una tarifa por hora más una tarifa por Load Balancer Capacity Unit (LCU) consumida, con el NLB típicamente al costo por hora más bajo de los tres, dado que opera a un nivel de red más simple (sin inspección de contenido HTTP). La decisión de examen: si el escenario no necesita enrutamiento por contenido HTTP (rutas, encabezados, host-based routing) y solo pide balancear conexiones TCP/UDP puras al menor costo operativo, NLB es, además de la respuesta técnica correcta que ya viste en el Módulo 3, también la más económica de las tres — nunca elijas ALB "por si acaso" cuando el escenario no describe ningún requisito de Capa 7.
EC2 Hibernation: pausar sin perder el estado, sin pagar cómputo
Task 4.2 nombra "scaling strategies (for example, auto scaling, EC2 hibernation)". El Módulo 3, lección 6, ya cubrió los warm pools de un Auto Scaling Group —instancias pre-inicializadas, en estado Stopped o Hibernated, listas para incorporarse sin repetir un arranque en frío—. EC2 Hibernation es, con precisión, el mecanismo que hace posible el estado Hibernated: verificado contra la documentación oficial de AWS, al hibernar una instancia, EC2 guarda el contenido completo de la memoria RAM en el volumen EBS raíz, y detiene la instancia — cuando se reanuda, el sistema operativo y las aplicaciones retoman exactamente donde quedaron, sin el tiempo de arranque en frío de un sistema operativo completo.
La decisión de examen: cuando un escenario describe una instancia con un estado en memoria costoso de reconstruir (una aplicación que precarga un modelo grande, un caché en memoria que tarda minutos en recalentar) y pide pausar el gasto de cómputo sin perder ese estado, EC2 Hibernation es la respuesta — mientras la instancia está hibernada (equivalente a Stopped para efectos de facturación de cómputo), Andes Cargo deja de pagar por las horas de instancia, y solo sigue pagando el almacenamiento EBS del volumen raíz, mucho más barato que el cómputo detenido.
AWS Outposts: la nube, dentro de tu propio centro de datos
Task 4.2 nombra "hybrid compute options (for example, AWS Outposts)". Nombrado aquí, sin profundidad de laboratorio —el mismo patrón que este módulo ya aplicó a Storage Gateway y DataSync en la lección 2—: Outposts es hardware físico de AWS, instalado dentro del centro de datos propio del cliente, que corre los mismos servicios y APIs de AWS (EC2, EBS, ECS/EKS, RDS, entre otros) en un entorno on-premises con baja latencia local o requisitos de residencia de datos que exigen que el cómputo nunca salga del edificio físico. El modelo de costo es distinto al resto de EC2: Outposts se contrata por un término fijo (no hay opción "por hora, sin compromiso"), lo que en la práctica significa que la decisión de costo ya viene empaquetada con un compromiso — el debate no es "Spot vs. RI" dentro de Outposts, es "¿el requisito de residencia de datos o latencia local justifica el costo de un rack físico dedicado, frente a una región de AWS estándar?".
La decisión de examen: cuando un escenario menciona explícitamente datos que por regulación no pueden salir de un país o edificio específico, o una latencia de un solo dígito de milisegundo hacia equipos físicos locales (una línea de producción industrial, un sistema médico en tiempo real), Outposts es la respuesta — nunca para una carga que simplemente "quiere estar cerca del usuario" sin ese requisito explícito de residencia o latencia local extrema, donde una Región de AWS estándar, o CloudFront, resuelve el problema a menor costo.
Errores comunes
Elegir Spot para cualquier escenario que mencione "reducir costo de cómputo", sin verificar la tolerancia a interrupción (el error de fondo de este tema). Qué pasa: alguien, viendo el descuento de hasta 90%, marca Spot en cualquier pregunta sobre optimización de costo de EC2. Cómo detectarlo: si tu respuesta a "reducir el costo de un servidor de producción que atiende tráfico en tiempo real, sin tolerancia a caídas" sigue siendo Spot. Cómo corregirlo: Spot solo es correcto cuando el escenario describe, explícitamente, una carga que puede pausarse, perder trabajo parcial y retomarse sin daño real — un servidor de producción sin esa tolerancia nunca es un candidato correcto para Spot, sin importar cuánto ahorre.
Confundir Reserved Instances con Savings Plans, usándolos como sinónimos (repite el error de vocabulario que finops-and-cost-guardrails-guide M7.5 ya nombró). Qué pasa: alguien responde "RI" cuando el escenario describe explícitamente flexibilidad de cambiar entre EC2 y Fargate, o viceversa. Cómo detectarlo: si tu respuesta no distingue el compromiso de tipo de instancia específico (RI) del compromiso de gasto en dólares, aplicable a varios servicios (Savings Plans). Cómo corregirlo: cuando el escenario menciona explícitamente flexibilidad de arquitectura futura, Savings Plans es la respuesta más ajustada; cuando el escenario es un tipo de instancia fijo, sin planes de cambio, y busca el descuento máximo, RI Standard gana por un margen pequeño.
Recomendar un compromiso de 1 o 3 años para una carga sin historial de tráfico (repite el error de "comprar por si acaso" de finops-and-cost-guardrails-guide M7.5, ahora como trampa de examen explícita). Qué pasa: alguien recomienda Savings Plans o RI para una aplicación que el escenario describe como recién lanzada, sin datos de uso todavía. Cómo detectarlo: si el escenario no menciona ningún historial de uso sostenido y tu respuesta sigue siendo un compromiso de largo plazo. Cómo corregirlo: sin datos reales de uso sostenido, la respuesta correcta es On-Demand — el compromiso llega después, cuando el patrón de tráfico ya es un dato medido, no una expectativa.
❓ Pregunta de práctica — Dominio 4 (Cost-Optimized) — Task 4.2
Escenario: PagoFacil, una fintech de pagos, procesa el cierre contable de fin de mes con un trabajo de tres días completos sobre un clúster de instancias EC2 dedicadas exclusivamente a esa tarea. El trabajo se divide en miles de unidades pequeñas e independientes; si una unidad se interrumpe a la mitad, se reintenta automáticamente sin pérdida de datos ni corrupción del resultado final. El equipo financiero solo necesita que el cierre completo esté listo antes del quinto día hábil del mes siguiente — no hay ninguna urgencia de que cada unidad individual termine en un momento exacto.
Pregunta: ¿Cuál estrategia de compra de EC2 es la más económica para este trabajo, dado el margen de tiempo y la tolerancia a interrupción descritos?
A. Reserved Instances Standard, con un término de 1 año. B. Spot Instances, con las miles de unidades del trabajo distribuidas entre ellas. C. Compute Savings Plans, con un término de 3 años. D. On-Demand Instances, sin ningún descuento por compromiso.
✅ Respuesta correcta: B
Por qué es correcta: el escenario describe, con precisión textual, exactamente la definición del caso de uso correcto de Spot Instances: una carga dividida en unidades pequeñas e independientes, tolerante a interrupción sin pérdida de datos (reintento automático), y sin urgencia de que una unidad específica termine en un momento exacto — solo el resultado agregado, con varios días de margen. Spot ofrece el descuento más alto de los tres mecanismos (hasta 90% frente a On-Demand, verifica el actual), exactamente el ahorro que el escenario puede aprovechar sin ningún costo operativo real, porque la interrupción ya está resuelta por el diseño del propio trabajo.
Por qué las demás fallan:
- A y C: tanto Reserved Instances como Savings Plans exigen un compromiso de 1 o 3 años de gasto sostenido — el escenario describe un trabajo que corre tres días al mes, no una carga continua las 24 horas; comprometerse a pagar por capacidad reservada durante un año completo para usarla solo unos días cada mes desperdicia la mayor parte del compromiso, el mismo error de "comprar por si acaso" que esta lección ya identificó.
- D: On-Demand no aprovecha ningún descuento, a pesar de que el escenario describe exactamente el tipo de carga —tolerante a interrupción, sin urgencia de tiempo exacto— donde Spot ofrece el mayor ahorro posible sin ningún riesgo real, dado que el trabajo ya está diseñado para absorber interrupciones sin pérdida de datos.
Resumen y siguiente paso
En esta lección expandiste Spot, Reserved Instances y Savings Plans —nombrados a nivel de criterio en finops-and-cost-guardrails-guide M7.5— hasta la tabla comparativa completa que el examen exige: compromiso, descuento, riesgo de interrupción, flexibilidad de recurso. Confirmaste que el criterio de decisión es el mismo que ya usaste con números reales en DynamoDB (M7.3): uso sostenido y predecible, medido, nunca supuesto. Y cerraste tres piezas nuevas del task statement: ALB/NLB/GWLB desde el ángulo de costo, EC2 Hibernation, y AWS Outposts.
Antes de avanzar deberías poder nombrar, sin dudar, qué compromete cada uno de los tres mecanismos de descuento, y explicar en una frase cuándo Savings Plans gana sobre Reserved Instances.
La lección 4 abre Task 4.3 — bases de datos costo-optimizadas, con el punto de cruce de ~760.000 solicitudes/mes de DynamoDB como el ancla numérica de toda la lección.
Recursos
- AWS Certification — SAA-C03 Domain 4: Design Cost-Optimized Architectures — fuente oficial de Task 4.2, citada en esta lección.
- AWS Savings Plans — fuente oficial del descuento de hasta 72% y las dos variantes (Compute/EC2 Instance), verifica el porcentaje vigente.
- Amazon EC2 Reserved Instances y Amazon EC2 Spot Instances — referencia oficial de Standard/Convertible RI y el mecanismo de interrupción con dos minutos de aviso.
- Amazon EC2 — Hibernate your instance — fuente oficial del mecanismo de hibernación citado en esta lección.
- AWS Outposts — fuente oficial del modelo híbrido citado en esta lección.
finops-and-cost-guardrails-guide, Módulo 7, lecciones 3 y 5 — el punto de cruce de ~760.000 solicitudes/mes de DynamoDB y el nombramiento original de Spot/RI/Savings Plans que esta lección expande.aws-saa-certification-guide, Módulo 3, lección 3 — la diferencia técnica completa entre ALB/NLB/GWLB que esta lección revisita solo desde el ángulo de costo.