Resolución de problemas, rendimiento y optimización de costes

El Dominio 3 de DEA-C01 es Operaciones y soporte de datos, 22 % del examen, y sus declaraciones de tarea dicen lo mismo de cuatro maneras distintas: resolver problemas de rendimiento (3.3.4), solucionar problemas y mantener pipelines como AWS Glue y Amazon EMR (3.3.6), analizar registros con servicios de AWS (3.3.8) e implementar mecanismos de desbalance de datos (3.4.5). El coste se sitúa junto a ellos en 2.1.1, elegir servicios de almacenamiento para requisitos específicos de coste y rendimiento, y en 3.2.5, describir los compromisos entre servicios aprovisionados y serverless. Esta lección es la unión de esas competencias: un bucle de triaje repetible, un mapa síntoma→causa→corrección por servicio, y la aritmética que convierte «hazlo más barato» en una respuesta defendible.

En esta lección aprenderás a:

• ejecutar un bucle de triaje de cuatro pasos y una taxonomía de fallos que cubre deriva de esquema, archivos corruptos, OOM, timeout, IAM, throttling, archivos pequeños y codificación, con síntoma→causa→corrección por servicio;
• dimensionar AWS Glue: tipos de DPU y de worker, aritmética de particiones, autoescalado, ejecución flexible, modos de fallo de bookmarks, repartition frente a coalesce, y fusión de archivos pequeños;
• diagnosticar Amazon Redshift: errores de claves de distribución y de ordenación, triaje de desbalance con SVV_TABLE_INFO, VACUUM/ANALYZE automáticos y ATO, WLM y reglas de monitorización de consultas, poda de Spectrum, y lectura de un plan EXPLAIN;
• ajustar Amazon EMR: roles primary/core/task, aritmética de número de nodos, nodos Spot de tareas, HDFS frente a S3, y cuándo EMR Serverless es la respuesta;
• corregir Amazon Kinesis Data Streams: shard caliente frente a clave caliente, rediseño de la clave de partición, alarmas de antigüedad del iterador y los tres modos de capacidad;
• operar AWS Lambda: piscinas de concurrencia, concurrencia reservada frente a provisionada, timeouts, reintentos asíncronos y colas de mensajes muertos;
• aplicar una tabla de palancas de coste por servicio, una tabla de compromisos coste-frente-a-rendimiento y las heurísticas de enunciados MAYOR eficiencia operativa / MENOR coste;
• resolver siete ejemplos resueltos: aritmética de particiones y coste de Glue, triaje de desbalance en Redshift, un ejercicio de EXPLAIN, dimensionado de nodos de EMR, coste de shards de Kinesis, concurrencia y coste de concurrencia de Lambda, y coste de solicitudes de S3;
• leer el recuadro de actualizaciones de octubre de 2026, cuatro casos de estudio de clientes de AWS, y terminar con catorce preguntas estilo examen más tres comprobaciones interactivas.

---

1. El bucle de triaje y la taxonomía de fallos

1.1 Cuatro pasos, en orden

La propia guía de resolución de problemas de AWS lo dice con franqueza: empieza en el registro de errores (Error log) de la ejecución del job, y luego pasa a la pestaña Executors / Spark UI para ver qué executor murió cuándo (guía de resolución de problemas de AWS Glue y consejos de Builder, consultada en octubre de 2026).

1.2 Síntoma → causa → corrección, por servicio

Esta tabla es el núcleo examinable de la Competencia 3.3.4. Cada fila es un modo de fallo de AWS documentado con la corrección que AWS documenta para él (documentación de resolución de problemas de AWS Glue, de diagnóstico de Redshift y de resolución de problemas de EMR/Kinesis/Lambda, consultada en octubre de 2026).

1.3 El árbol de decisión de fallos

1.4 Comprobación interactiva: empareja el síntoma con la corrección

• 📚 ¿Sabías que…? Un job de Glue puede informar SUCCEEDED sin escribir nada: un bookmark que ya ha registrado los archivos de origen los omitirá en la siguiente ejecución, y un prefijo equivocado o una ruta de catálogo muerta se ven idénticos a una partición vacía sana. La propia lista de resolución de problemas de AWS pone por eso «éxito pero sin datos» junto a errores reales: la corrección es una comprobación de marcas de tiempo, no un stack trace (guía de resolución de problemas de AWS Glue, consultada en octubre de 2026).

---

2. Fallos de forma de los datos: deriva, archivos corruptos, codificación

2.1 La deriva de esquema es un problema de versiones, no de análisis

Cuando un equipo aguas abajo añade, elimina o cambia el tipo de una columna, ocurren tres cosas en secuencia: la fuente cambia, la tabla de Glue gana una nueva versión en el Data Catalog, y cada consumidor aguas abajo (crawler, consulta de Athena, esquema externo de Redshift, dataset de QuickSight) hereda el cambio en silencio. El patrón de AWS para ello es: diferir las versiones de la tabla → publicar en un tema SNS → hacer evolucionar al consumidor antes de que lleguen los datos (Blog de Big Data de AWS, «Identify source schema changes using AWS Glue», 2022-09-14).

Dentro del propio job, un DynamicFrame representa «algunas filas tienen esta columna y otras no» como un tipo choice. La reparación documentada es resolveChoice, que o bien convierte (cast), tú nombras el tipo, y los valores no convertibles se vuelven NULL, o bien make_cols (añade una columna anulable). Muy relacionado: el crawler informa «Partitions were not updated» cuando el esquema del DynamicFrame entrante no es idéntico al del catálogo ni un subconjunto de él, y updateBehavior no es UPDATE_IN_DATABASE.

2.2 Registros corruptos: rechazar en voz alta o poner en cuarentena

Las filas CSV mal formadas que «encajan» en el esquema inferido se descartan en silencio. El remedio documentado es errorsAsDynamicFrame(), que divide el frame en un frame bueno y un frame de rechazo, más los recuentos stageThreshold / totalThreshold que hacen fallar el job cuando los rechazados superan un presupuesto. El patrón operativo de la Lección 11 lo completa: escribe los rechazados en un prefijo de cuarentena con _dq_rule, _dq_reason y _run_id, y alerta sobre el recuento. El lector CSV vectorizado es una trampa concreta: no puede manejar multiLine ni contenido multibyte, así que «errores de análisis que solo aparecen en algunas filas» suele significar «usa el lector basado en filas».

2.3 Codificación

Los desajustes de charset se presentan como caracteres corruptos, campos truncados o filas que se parten en la coma equivocada. Fija encoding en las opciones de formato de Glue, evita el lector vectorizado con datos multibyte, y coloca una regla de codificación de DataBrew antes de la carga en lugar de limpiar mojibake en el almacén. La codificación es un contrato origen-destino, y como la deriva de esquema es invisible en los recuentos de filas: que es exactamente por lo que ambas pertenecen a la taxonomía y no a un capítulo aparte de «calidad de datos».

3. Rendimiento de AWS Glue: DPU, workers, bookmarks, archivos pequeños

3.1 Lo que realmente estás pagando

Un DPU = 4 vCPUs de capacidad de cómputo y 16 GB de memoria (documentación de tipos de worker de AWS Glue, consultada en octubre de 2026). Los jobs de Glue 2.0+ se dimensionan con WorkerType + NumberOfWorkers, no existe MaxCapacity en las versiones modernas, y un executor de Spark se ejecuta por nodo worker, en todos los tipos G y R.

Regla de dimensionado de la guía de optimización de Prescriptive Guidance: escala horizontal (más workers) solo «hasta que observes workers inactivos; más allá de eso, añadir más workers aumenta los costes sin mejorar resultados», y escala vertical (tipo más grande) para transformaciones intensivas en memoria, agregaciones con desbalance y planes de driver enormes.

3.2 Aritmética de particiones: la operación que el examen puede pedirte que repitas

Para Glue 3.0+:

Particiones iniciales desde S3: para objetos ≤ 64 MB, cuenta los objetos; para > 64 MB, usa size / 64 MB; el gzip no divisible cuenta como una tarea por objeto: un único .csv.gz de 10 GB es 1 tarea, con independencia de cuántos workers compres. Demasiadas particiones explotan el driver y el planificador de tareas, así que arréglalas con groupFiles, coalesce(N) (sin shuffle completo, más barato que repartition) o el coalescing de AQE de Spark 3.

3.3 Autoescalado, ejecución flexible y AQE

• Autoescalado (--enable-auto-scaling=true, Glue 3.0+, todos los tipos G/R): Glue añade y quita workers por etapa hasta NumberOfWorkers como máximo, y además fija spark.sql.shuffle.partitions y spark.default.parallelism a partir de ese máximo: anúlalos con --conf si tu carga de trabajo es desigual.
• Ejecución flexible (Glue 3.0+, solo G.1X y G.2X, jobs no urgentes): una DPU-hora con descuento a cambio de una hora de inicio variable. El caso de uso documentado es preproducción y rellenos nocturnos.
• AQE está activado por defecto en Glue 4.0; en 3.0 fija spark.sql.adaptive.enabled=true. Coalescea las particiones de shuffle, convierte los sort-merge join en broadcast y maneja el desbalance con skewedPartitionFactor / skewedPartitionThresholdInBytes.
• Escalar horizontalmente no es lineal. El propio ejemplo de métricas resuelto de AWS (10 → 55 DPU reduce a la mitad el tiempo de ejecución, 55 → 100 DPU no añade nada porque los executors quedan inactivos) proviene de una página aplicable solo a Glue 0.9/1.0: toma el método («añade workers solo hasta que estén inactivos»), nunca los minutos absolutos.

3.4 Ejemplo resuelto E1: aritmética de particiones y coste en Glue

3.5 Bookmarks: el modo de fallo más pasado por alto en este examen

AWS documenta siete formas en que un job con bookmarks reprocesa datos: MaxConcurrency > 1, falta de job.init() / job.commit(), falta o renombrado de transformation_ctx, clave primaria JDBC no secuencial, cambio en la hora de última modificación, entrada Spark DataFrame en lugar de DynamicFrame, y cambio de la ruta de origen bajo el mismo contexto. Dos frases cubren la mayoría de ítems de examen:

• «Actualmente los bookmarks de AWS Glue no admiten ejecuciones concurrentes del job y los commits fallarán»: mantén execuciones concurrentes máximas = 1.
• «Si no pasas el parámetro transformation_ctx, los bookmarks de job no se habilitan para un dynamic frame o una tabla usada en el método»: los bookmarks rastrean operaciones de DynamicFrame, y rastrean orígenes, no destinos: un rebobinado o reinicio nunca borra lo que ya se escribió, así que repite la carga en un prefijo de destino nuevo.

3.6 repartition frente a coalesce, y fusión de archivos pequeños

---

4. Amazon Redshift: distribución, desbalance, mantenimiento, planes

4.1 Tres enfermedades, tres tratamientos

Las preguntas de rendimiento de Redshift casi siempre se resuelven en uno de tres problemas a nivel de columna, y cada uno tiene una cura distinta (AWS Redshift Identifying tables with data skew or unsorted rows, consultado en octubre de 2026).

El mantenimiento automático está activado por defecto: el análisis automático se ejecuta en ventanas de carga ligera con analyze_threshold_percent = 10 %, el auto-vacuum de ordenación/borrado se pausa bajo carga alta o bloqueos DDL exclusivos, y la optimización automática de tablas (ATO) aplica claves de ordenación y de distribución a tablas AUTO en horas de haber visto suficientes consultas. Audítalo con SVV_ALTER_TABLE_RECOMMENDATIONS y SVL_AUTO_WORKER_ACTION. Datos clave que el examen reutiliza: las claves de ordenación/distribución explícitas sacan a una tabla de la automatización, y VACUUM omite la fase de ordenación por defecto cuando más del 95 % de las filas ya están ordenadas.

4.2 Ejemplo resuelto E2: triaje de desbalance en cuatro consultas

Después, vuelve a ejecutar EXPLAIN y busca la etiqueta de redistribución que quieres: DS_DIST_NONE / DS_DIST_ALL_NONE.

4.3 Fundamentos de EXPLAIN: lee el plan antes de redimensionar el clúster

Etiquetas de redistribución: DS_DIST_NONE y DS_DIST_ALL_NONE son buenas; DS_BCAST_INNER es correcto para una dimensión pequeña y no es automáticamente malo; DS_DIST_INNER / DS_DIST_OUTER son costosas; DS_DIST_ALL_INNER serializa la ejecución en una sola rebanada; DS_DIST_BOTH es la peor. Si el planificador elige una dirección de join que parece errónea, la causa documentada son estadísticas obsoletas: ejecuta ANALYZE.

4.4 Ejemplo resuelto E3: el plan que la propia AWS usa en formación

Dos lecciones examinables: el nombre del operador te dice la estrategia, la estimación de coste te dice si importó, y ninguno de los dos requiere un clúster más grande (AWS Prescriptive Guidance, «Evaluating the query plan», consultada en octubre de 2026).

4.5 Gestión de carga de trabajo, escalado de concurrencia y Spectrum

• WLM: el valor por defecto es 1 cola con 5 consultas concurrentes. WLM automático crea hasta 8 colas (clases de servicio 100 to 107) cada una con una priority (NORMAL por defecto; CRITICAL es solo para superusuarios). WLM manual permite concurrencia 1 to 50 por cola, 50 slots en total, con un porcentaje de memoria por cola.

• Reglas de monitorización de consultas (QMR) se ejecutan cada 10 s. Severidad de la acción: log < hop (solo WLM manual, y solo para consultas CTAS/solo lectura) < abort (nunca detiene COPY, ALTER, ANALYZE ni VACUUM) < change priority (solo WLM automático). Plantillas que memorizar: desbordamiento query_temp_blocks_to_disk > 100000 bloques (100 GB) y desbalance de E/S io_skew > 1.30.

• Los timeouts de WLM cubren solo la fase de ejecución: las esperas de cola, bloqueo, compilación y hop quedan fuera de ellos.

• Escalado de concurrencia enruta las consultas que se desbordan a clústeres transitorios en lugar de encolarlas, por cola (auto/off), con 1 hora gratis por cada 24 horas y max_concurrency_scaling_clusters de 1 to 10. Alivia el encolamiento, no la presión de memoria por consulta.

• Spectrum factura 5,00 USD por TB escaneado (mínimo de 10 MB por consulta, en octubre de 2026), así que la poda es una palanca de coste tanto como de velocidad: particiona por predicados sobre los que filtras de verdad, usa Parquet/ORC para la eliminación de columnas, mantén archivos de ≥ 64 MB, y fija TABLE PROPERTIES (numRows = n) porque Redshift nunca analiza tablas externas y en caso contrario asume que la tabla externa es la más grande del plan. Verifica con SVL_S3PARTITION (assigned_partitions vs qualified_partitions), SVL_S3QUERY_SUMMARY (s3_scanned_*) y los marcadores de EXPLAIN (S3 Seq Scan, Partition Loop). DISTINCT y ORDER BY nunca se empujan hacia abajo.

• 📚 ¿Sabías que…? Una tabla de Redshift puede estar 86 % desordenada y solo mejorar un 5 %: vacuum_sort_benefit existe precisamente para que no pagues un VACUUM que no cambia nada, y por defecto VACUUM omite por completo la fase de ordenación por encima del 95 % de filas ordenadas. Por eso «ejecutar VACUUM tras cada carga» es un distractor, no una buena práctica (documentación de vaciado de AWS Redshift, consultada en octubre de 2026).

---

5. Amazon EMR: dimensionado, nodos Spot de tareas, HDFS frente a S3

5.1 Tres roles de nodo, tres decisiones de compra

La propia regla de AWS: «Use Spot Instances on task nodes. The task nodes process data but do not hold persistent data in Hadoop Distributed File System (HDFS). If task nodes shut down… no data is lost.» (Usa instancias Spot en los nodos de tareas. Los nodos de tareas procesan datos pero no conservan datos persistentes en el sistema de archivos distribuido Hadoop (HDFS). Si los nodos de tareas se apagan… no se pierden datos.) Todo-Spot es solo para jobs transitorios que toleran pérdidas. Ten en cuenta el comportamiento asimétrico de Spot: las instancias task-Spot se lanzan a medida que hay capacidad disponible, mientras que core-Spot espera a todas las instancias solicitadas antes de lanzarse, y la reclamación de Spot permite unos 20 s de desmantelamiento elegante (spark.decommissioning.timeout.threshold, EMR ≥ 5.11.0).

5.2 Ejemplo resuelto E4: recuento de nodos y capacidad de HDFS

HDFS frente a S3 para el examen: S3/EMRFS es duradero, desacoplado, sobrevive a la terminación del clúster y cuesta menos por GB → es el valor por defecto del pipeline; HDFS es más rápido para el shuffle intermedio pero consume el presupuesto de replicación y muere con el clúster. En EMR, la ejecución adaptativa de consultas está activada por defecto (5.30+) con coalescing de particiones de shuffle (tamaño consultivo 64 MB, minPartitionNum 25, initialPartitionNum 1000), poda dinámica de particiones (5.26+), y spark.default.parallelism = 2 × cores de YARN.

5.3 EMR Serverless: la opción sin dimensionado

EMR Serverless factura por vCPU-hora y GB-hora más almacenamiento GB-hora, 0,052624 USD/vCPU-hora, 0,0057785 USD/GB-hora, 0,000111 USD/almacenamiento GB-hora (en octubre de 2026), y los workers se autoescalan entre el mínimo y el máximo del job, de modo que la decisión de dimensionado desaparece. Es la elección natural para jobs intermitentes de Spark/Hive donde un clúster quedaría inactivo.

---

6. Amazon Kinesis Data Streams: shards calientes, antigüedad del iterador, modos de capacidad

6.1 Shard caliente frente a clave caliente: la distinción más probada

Los límites por shard son 1 MB/s de escritura y 1.000 registros/s, 2 MB/s y 2.000 registros/s de lectura, y 5 TPS de lectura; un solo registro puede ser de 10 MiB y PutRecords acepta hasta 500 registros / 10 MiB por llamada (límites de AWS Kinesis, consultados en octubre de 2026).

• Shard caliente = muchas claves que caen de forma desigual → divide el shard (UpdateShardCount / SplitShard en modo aprovisionado) o deja que el modo bajo demanda lo divida.
• Clave caliente = una clave que supera el límite de un shard → rediseña la clave de partición (sufijo UUID o compuesto) o, si necesitas orden/localidad por clave, conserva la clave y acepta el techo.
• Añadir shards no corrige una clave caliente: todos los registros de una clave hacen hash a un solo shard, para siempre. Y el modo bajo demanda «no detecta ni aísla las claves hash que provocan una mayor porción del tráfico entrante hacia un shard concreto»: documentado explícitamente, y por eso es una respuesta errónea favorita.

6.2 La antigüedad del iterador es una advertencia de pérdida de datos, no solo retraso

GetRecords.IteratorAgeMilliseconds (stream) / IteratorAgeMilliseconds (shard) mide el retraso del consumidor; 0 significa que está completamente al día. La advertencia de AWS: «If an iterator's age passes 50% of the retention period (by default, 24 hours, configurable up to 7 days), there is risk for data loss due to record expiration.» (Si la antigüedad de un iterador supera el 50 % del período de retención (por defecto 24 horas, configurable hasta 7 días), existe riesgo de pérdida de datos por expiración de registros.) Así que alarma sobre el máximo al 50 % de la retención, y corrige con: más shards, ParallelizationFactor de Lambda (1 to 10 por shard; el orden aun se conserva por clave de partición), una ventana de batching de hasta 5 min / 6 MB, enhanced fan-out (un dedicado de 2 MB/s por consumidor por shard), o simplemente un consumidor más rápido.

6.3 Tres modos de capacidad, no dos

Los cambios de modo se limitan a 2 cada 24 horas móviles. EFO cuesta 0,015 USD por consumidor-shard-hora más por GB, y admite 20 consumidores registrados por stream (Standard) o 50 (Advantage); con menos de unos 3 consumidores, las lecturas compartidas son la opción más barata.

• 📚 ¿Sabías que…? La antigüedad del iterador es una de las pocas métricas de AWS donde «mayor» puede significar pérdida de datos permanente en lugar de «más lento»: una vez que un registro supera la ventana de retención se ha ido, y ninguna cantidad de escalado lo recupera. Por eso la recomendación de AWS es una alarma al 50 % del período de retención, no al 100 % (documentación de monitorización de AWS Kinesis, consultada en octubre de 2026).

6.4 Ejemplo resuelto E5: coste de shards y la factura de unidades de payload

---

7. AWS Lambda: concurrencia, timeouts, arranques en frío, reintentos

7.1 La piscina de concurrencia

El valor por defecto de la cuenta es de 1.000 ejecuciones concurrentes por Región; una función escala hasta 1.000 entornos por cada 10 segundos, y el techo de invocaciones por segundo es de unas 10 × la cuota de concurrencia. Por encima de la cuota, las invocaciones se limitan con 429.

La concurrencia reservada y la provisionada cuentan ambas contra la piscina de la cuenta, y provisionada ≤ reservada para la misma función. Application Auto Scaling apunta a un 70 % de utilización (escala hacia fuera por encima de 70, hacia dentro por debajo de 63), y la propia guía de AWS es que los pipelines asíncronos de procesamiento de datos normalmente no necesitan concurrencia provisionada.

7.2 Timeouts y reintentos

Sube memoria y timeout juntos: la CPU es proporcional a la memoria, así que un «timeout» es frecuentemente una función con dimensionamiento insuficiente. Los reintentos asíncronos no corrigen un dimensionamiento erróneo: solo lo ocultan hasta que se llena la DLQ:

• Sincrónicos: el invocador ve el error; los reintentos siguen la política del invocador.
• Asincrónicos: Lambda encola y luego reintenta 2 veces (tras 1 minuto, después 2 minutos) para errores de función; para el throttling (429) y los errores de sistema (serie 500) el evento vuelve a la cola y se reintenta durante hasta 6 horas, con backoff desde 1 s hasta 5 min. Después lo recibe la cola de mensajes muertos (SQS estándar o SNS estándar únicamente: nunca FIFO) o el destino en caso de fallo; un destino en caso de fallo lleva además el payload de respuesta.
• Stream (mapeo de origen de eventos): reintenta hasta que se active bisect_batch_on_error, maximum_record_age o retry_attempts, y después el destino en caso de fallo. Para Kinesis, ParallelizationFactor 1 to 10 aumenta la paralelismo por shard manteniendo el orden por clave de partición.

7.3 Ejemplo resuelto E6: concurrencia, reservada frente a provisionada

---

8. Palancas de coste por servicio

8.1 La dimensión facturable, y luego la palanca

Nunca nombres una palanca sin nombrar la dimensión que reduce (páginas de precios de AWS Glue, Redshift, EMR, Kinesis, Lambda y S3, en octubre de 2026).

8.2 Ejemplo resuelto E7: los archivos pequeños cuestan el doble

• 📚 ¿Sabías que…? La mitad de almacenamiento de la factura lleva veinte años bajando mientras la de solicitudes no: la retrospectiva de S3 de AWS (2026-03-13) sitúa la reducción de precio desde el lanzamiento de 2006 en unos 85 % y afirma que los clientes han ahorrado más de 6.000 millones de USD usando S3 Intelligent-Tiering en lugar de S3 Standard. Por eso esta lección sigue dividiendo S3 en palancas de clase de almacenamiento y de solicitudes: automatizar la clase mueve un número grande, fusionar objetos mueve el otro (entrada «Twenty years of Amazon S3» de AWS, consultada en octubre de 2026).

---

9. Coste frente a rendimiento: la tabla de compromisos y las heurísticas de enunciado

9.1 El compromiso que el examen realmente pregunta

9.2 Dónde se sitúa cada servicio

9.3 Las dos heurísticas de enunciado (derivadas del comportamiento documentado por AWS, no de un documento de AWS)

• «MAYOR eficiencia operativa» ⇒ elige la opción sin planificación de capacidad y sin clúster que dimensionar: AWS Glue (workers gestionados, autoescalado), EMR Serverless, Redshift Serverless, Kinesis bajo demanda, Lambda: después vuelve a leer el enunciado buscando una restricción que lo anule (HDFS, control de claves calientes, ciclo de trabajo estable 24/7).
• «MENOR coste» (estable 24/7) ⇒ elige la opción aprovisionada o con compromiso: shards aprovisionados, un clúster de Redshift sobre Serverless, cómputo On-Demand/comprometido, menos DPU-horas, S3 por escalones de ciclo de vida. Una opción serverless que pase 20 horas al día inactiva rara vez es la más barata.
• «MÁS RÁPIDO de implementar» ⇒ un cambio de configuración gestionado (WLM, autoescalado, una alarma, una clave de ordenación) le gana a una refactorización de código: salvo que la causa raíz del enunciado sea el código (un predicado de join ausente, un transformation_ctx faltante).
• Lee siempre primero las restricciones: estable vs con picos, SLA vs rendimiento, aislamiento vs latencia. La heurística es el desempate, no la premisa.

9.4 Comprobación interactiva: rellena los números que el examen reutiliza

9.5 Comprobación interactiva: ordena la decisión de coste

---

Actualizaciones de 2026 (en octubre de 2026)

• 📚 ¿Sabías que…? Los recortes de precio mueven respuestas de examen: Glue 6.0 (−30 %), S3 Express One Zone (almacenamiento −31 %, PUT −55 %, GET −85 %, 2025-04-10) y Kinesis bajo demanda Advantage cambiaron todos la columna de «más barato», pero las dimensiones (DPU-hora, shard-hora, GB-s, bytes escaneados) no han cambiado. Aprende la dimensión y reverifica la tarifa (páginas de precios de AWS, consultadas en octubre de 2026).

---

Casos Reales

AWS publica cómo se ve esta lección en producción. Cada cifra de abajo es declarada por el cliente o por AWS y no auditada, con la fuente nombrada para que puedas comprobarla: el punto examinable es el patrón (qué palanca se movió, y en qué dirección), no el porcentaje de marketing.

Caso A, Amazon Customer Service: buen dimensionado de un almacén

Léelo como Competencia 3.3.4 más 2.1.1 en una sola historia: el rendimiento y el coste se movieron juntos, porque RA3 separa el almacenamiento gestionado del cómputo, así que dejas de pagar por disco local que solo rellenabas con datos fríos. La versión distractora de esta historia afirma que el coste bajó porque se compró un descuento: en el estudio de caso no aparece ningún descuento.

Caso B, Paytm: una palanca de coste por fases en EMR

«Migrar a instancias basadas en AWS Graviton es una inversión a largo plazo y será beneficiosa en términos de coste total de propiedad (TCO).»: Parakh Aggarwal, Director de Cloud Excellence y FinOps (estudio de caso de AWS, consultado en octubre de 2026)

El patrón examinable es la distancia entre el precio de lista y el ahorro realizado: una palanca solo vale sus puntos cuando has medido la carga de trabajo, y la línea temporal (2022 → 2024) muestra por qué «cámbialo todo esta noche» nunca es la respuesta en este examen.

Caso C, GE Aerospace: un ODS heredado reconstruido sobre Redshift

«Estábamos viendo consultas que antes tardaban una hora y media tardar 7 minutos con Amazon Redshift.»: Bejoy John, Senior Director of Data Analytics (estudio de caso de AWS, consultado en octubre de 2026)

Léelo como Competencia 3.3.4 (resolver problemas de rendimiento) más 2.1.1 (dimensionado coste/rendimiento): la victoria vino del diseño, el plan y la generación de nodos, no de un descuento comprado. Dos hábitos de examen que practicar aquí: los >500.000 USD son la propia estimación de GE, así que nunca lo generalices a tu carga de trabajo; y una migración de 9 meses con una PoC primero es lo contrario del distractor «arréglalo esta noche».

Caso D, Edmunds.com: tres palancas, una factura

«La motivación principal es que ya no estoy atado a un tipo de instancia o Región concretos.»: Emil Ndreu, Executive Director of Cloud and Security Operations (estudio de caso de AWS, consultado en octubre de 2026)

Haz la aritmética que AWS no publica: 100.000 USD en 11 meses ≈ 9.091 USD al mes, pero AWS nunca desglosa esa cifra entre Spot, Savings Plans y Fargate Spot: así que cualquier opción que afirme «los Savings Plans solos ahorraron X %» no tiene respaldo en la fuente. La distinción examinable es el tipo de palanca: un Savings Plans es un descuento por compromiso (los Compute SP no se atan a un tipo de instancia o Región), Spot es capacidad interrumpible para trabajo tolerante a fallos (AWS cita hasta un 90 % de descuento sobre On-Demand), y ninguno de los dos es el cambio de silicio Graviton del Caso B.

• 📚 ¿Sabías que…? Las cuatro historias evitan la trampa que esta lección repite: ninguno de estos clientes «lo hizo más barato» comprando un compromiso sobre un sistema sobredimensionado. Uno redimensionó, otro cambió de plataforma, otro reconstruyó primero el plan y el diseño, otro apiló dos palancas de capacidad, y todos midieron primero. El porcentaje publicado por AWS es siempre su carga de trabajo, nunca una garantía para la tuya (estudios de caso de AWS y Blog de Big Data, consultados en octubre de 2026).
• 📚 ¿Sabías que…? Tres palancas se parecen en una factura y son respuestas de examen distintas: Savings Plans = descuento por compromiso (los Compute SP no se atan a un tipo de instancia o Región), Spot = capacidad interrumpible que debes poder perder (AWS cita hasta un 90 % de descuento sobre On-Demand), y Graviton = silicio distinto con un precio de lista más bajo. Los distractores de DEA-C01 intercambian rutinariamente dos de los tres: nombra la dimensión que cambia cada uno antes de elegir (Precios de AWS y estudios de caso, consultados en octubre de 2026).

---

Preguntas de Práctica (Practice Questions)

Veredicto comparativo: cómo se compara este tema el día del examen

• Frente a otra nube: DEA-C01 prueba solo servicios de AWS: nada te pide comparar las DPU-horas de Glue con la estructura de precios del clúster de un competidor. Responde con un servicio de AWS, un umbral publicado por AWS (desbalance 4,00, omisión de VACUUM al 95 %, 1 MB/s por shard, 1.000 concurrentes de Lambda) o una tarifa publicada por AWS en octubre de 2026; cualquier opción que gire hacia un benchmark de terceros no verificado queda fuera de alcance por construcción.
• Frente a herramientas autogestionadas / on-premises: la respuesta de AWS siempre es gestionado y medido sobre personalizado y manual: el VACUUM/ANALYZE automático y el ATO le ganan a un VACUUM por cron, el autoescalado de Glue le gana a un clúster ajustado a mano, las cuotas de concurrencia de Lambda le ganan a un trabajador de cola autoalojado. Una opción que describa a ti manteniendo la maquinaria es el distractor, no la ventaja.
• Frente a otro servicio de AWS: elige por la dimensión facturable, no por prestigio: Glue para Spark ETL gestionado (DPU-hora), Redshift para SQL a escala (node/RPU-hora + bytes escaneados), EMR cuando necesitas control a nivel de clúster (EC2 + tarifa de EMR), EMR Serverless/Glue cuando el dimensionado es el riesgo, Kinesis para streaming (shard-hora o GB), Lambda para pegamento de eventos (solicitudes + GB-s). «Serverless» gana el enunciado operativo; «aprovisionado» gana el enunciado de coste en estado estable.
• Frente a un proceso manual y humano: el recorte de coste de ~55 % de Amazon Customer Service con paneles un 47 % más rápidos y el ahorro por fases del 30 to 35 % en EMR de Paytm (ambos declarados por el cliente, consultados en octubre de 2026) muestran por qué el examen prefiere una palanca automatizada y medida: los humanos no encuentran el desbalance, el plan o el worker inactivo: lo hace un umbral, una métrica o una alarma. Trata cada porcentaje publicado como «lo logró el cliente», nunca como «lo garantiza AWS».