Amazon DEA-C01: Optimización de costos para cargas de trabajo de datos — Guía de estudio

By Laurynas Brazys · 2 August 2026 · #amazon #dea-c01 #certification #exam-prep #study-guide

Forma parte de la Amazon Data Engineer Associate DEA-C01 — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Amazon, o realiza tests cronometrados en ExamRoll.io.

La optimización de costos para las cargas de trabajo de datos asegura que las canalizaciones de almacenamiento, computación y procesamiento de datos entreguen valor sin gastos descontrolados. Los ingenieros de datos deben equilibrar el rendimiento de las consultas, la durabilidad de los datos y la disponibilidad frente a modelos de precios que varían según el servicio y el patrón de uso. Este dominio requiere familiaridad con las clases de almacenamiento y las políticas de ciclo de vida, los controles a nivel de consulta y de clúster, la capacidad spot y reservada, y las ventajas y desventajas entre los modelos sin servidor (serverless) y aprovisionados.

Optimización de costos de almacenamiento en S3

S3 Intelligent-Tiering es la opción predeterminada recomendada para conjuntos de datos con patrones de acceso impredecibles: habilite Intelligent-Tiering a través de la consola o la AWS CLI cuando la frecuencia de acceso a los objetos no se pueda prever de manera fiable. Configure Intelligent-Tiering siendo consciente de la tarifa de monitoreo/automatización correspondiente (hay un pequeño cargo mensual de monitoreo por objeto) y el número mínimo de días adecuado para las transiciones automáticas de nivel (30 días para los niveles de acceso frecuente a poco frecuente). Use etiquetas de objeto y reglas de ciclo de vida para excluir objetos pequeños y de alta solicitud donde las tarifas de monitoreo superarían los ahorros.

Utilice estos patrones operativos para reducir los gastos de S3:

Ejecute S3 Storage Class Analysis (consola > Management > Analytics o

undefined

) para identificar patrones de acceso a nivel de prefijo/etiqueta antes de crear reglas de ciclo de vida.

Convierta grandes conjuntos de datos históricos a clases de archivo (Glacier Flexible Retrieval o Glacier Deep Archive) utilizando transiciones de ciclo de vida; establezca el tiempo de la transición para que coincida con los SLA del negocio y evite recuperaciones Expedited frecuentes.
Consolide muchos objetos pequeños (problema de archivos pequeños) en objetos más grandes (archivos contenedores Parquet) para cargas de trabajo analíticas para reducir los costos por solicitud y por GET.

Criterios de decisión:

Use Intelligent-Tiering para conjuntos de datos impredecibles y de acceso moderado donde el tiempo de recuperación es flexible.
Use Standard-IA o One Zone-IA para datos a los que se accede con poca frecuencia pero que se pueden recuperar rápidamente con recuperaciones predecibles.
Use Glacier Standard/Bulk/Deep Archive para la retención a largo plazo donde las recuperaciones son raras y pueden tolerar una latencia de minutos a horas; prefiera las recuperaciones Bulk/Standard sobre las Expedited para evitar tarifas altas.

Gestión de costos de Athena y Redshift

Los costos de Athena escalan con los bytes escaneados. Aplique controles de grupo de trabajo (consola o

undefined

) para implementar límites de datos escaneados por consulta y presupuestos mensuales por grupo de trabajo; habilite “Enforce workgroup settings” para que las consultas que excedan el límite de datos por consulta fallen en lugar de ejecutarse. Reduzca los bytes escaneados convirtiendo los archivos de origen a formatos columnares comprimidos (Parquet/ORC), particionando por fecha o columnas de filtro comunes, aplicando predicate pushdown y usando CTAS o CREATE TABLE AS para materializar conjuntos de datos optimizados. Utilice la reutilización de resultados de consultas y el aislamiento de cargas de trabajo en grupos de trabajo separados para evitar fugas de costos entre equipos.

Las decisiones de costos de Redshift dependen de la previsibilidad de la carga de trabajo y las opciones de almacenamiento. Para un uso de computación de data warehouse estable y predecible, adquiera Reserved Nodes (plazos de uno o tres años, opciones de pago parcial/total por adelantado) para asegurar descuentos en comparación con el modelo bajo demanda (on-demand). Para cargas de trabajo variables:

Use Redshift Serverless o nodos RA3 con almacenamiento administrado para desacoplar la computación y el almacenamiento.
Use el escalado de concurrencia con moderación (incurre en cargos adicionales pero proporciona escalado automático) y monitoree los créditos.

Aspectos destacados de la comparación:

Reserved Nodes: ideal para clústeres de estado estable y a largo plazo; requiere compromiso pero ofrece un descuento significativo.
On-demand: flexible para proyectos impredecibles o a corto plazo; costo por hora más alto.
Serverless/RA3 con Spectrum: traslade el almacenamiento a S3 y pague por la computación cuando esté activa para evitar grandes compromisos reservados.

Estrategias de costos para Glue y EMR

AWS Glue proporciona ETL sin servidor (serverless) con múltiples palancas de costo. Para trabajos por lotes (batch) que no son sensibles a la latencia, use la ejecución flexible de Glue (trabajos Glue Flex), que puede reducir el costo hasta en un ~34% en comparación con la ejecución estándar de Glue. Configure los parámetros del trabajo de Glue en Glue Studio o la CLI (

undefined

) para seleccionar el tipo de worker y el máximo de DPUs, establezca un límite máximo de DPU sensato para evitar el autoescalado ilimitado y use marcadores de trabajo (job bookmarks) para evitar el reprocesamiento completo. Para cargas de trabajo interactivas o sensibles a la latencia, elija los tipos de worker (Standard/G.1X/G.2X) y ajuste el paralelismo de manera responsable.

La reducción de costos en EMR se basa en el uso de Spot Instances para los nodos de tarea (task nodes) mientras se mantienen los nodos maestros y principales (master and core nodes) como On-Demand (configure flotas de instancias o grupos de instancias en la consola o mediante

undefined

). Use Spot solo para los nodos de tarea, seleccione la estrategia de asignación optimizada para la capacidad (capacity-optimized) y establezca un precio máximo/de oferta apropiado si usa Spot con licitación. Proteja el estado del clúster y la resiliencia del trabajo mediante:

Almacenar datos persistentes en S3 (use EMRFS) en lugar de HDFS cuando se usan nodos de tarea Spot.
Usar reintentos automáticos y flujos de trabajo basados en pasos para manejar las interrupciones de Spot.
Emplear EMR Managed Scaling para dimensionar correctamente los clústeres; monitoree las políticas de escalado para evitar la oscilación.

Criterios de decisión:

Use Glue Flex para ETL de baja prioridad y sensible a los costos con tolerancia a un inicio más prolongado; limite el máximo de DPUs.
Use EMR con nodos de tarea Spot para grandes procesamientos transitorios (p. ej., lotes nocturnos), pero mantenga los nodos maestro/principal como On-Demand o use Instance Fleets con asignación mixta.

Capacidad reservada y Savings Plans para servicios de datos

La capacidad reservada y los Savings Plans se aplican de manera diferente entre los servicios de datos. Para los servicios basados en EC2 (EMR, HBase autogestionado, Hadoop personalizado), utiliza EC2 Savings Plans o Instancias reservadas para cubrir el gasto de computación; selecciona opciones regionales o zonales según las necesidades de movilidad. Redshift admite la compra de nodos reservados para clústeres aprovisionados con el fin de reducir los costos por hora en cargas de trabajo de data warehouse predecibles. Los servicios sin servidor (serverless) como Glue y Athena no tienen reservas de recursos; en su lugar, optimiza mediante la programación de cargas de trabajo y cambios en el formato de datos.

Guía práctica de compra:

Compra Nodos reservados de Redshift para cargas de trabajo de data warehouse estables con utilización conocida (evalúa plazos de 1 o 3 años y opciones de pago total/parcial/sin pago por adelantado).
Usa EC2 Savings Plans para cubrir el gasto predecible de EMR/EC2 entre diferentes familias de instancias; los Savings Plans proporcionan flexibilidad si la familia de instancias o la región cambian.
No compres reservas para servicios sin servidor; en su lugar, optimiza los patrones de uso, la programación y la disposición de los datos.

Errores comunes y criterios de decisión

Athena escanea la tabla completa sin particionamiento — particiona siempre las tablas grandes de series temporales por fecha u otras columnas de alta cardinalidad y filtradas con frecuencia, y conviértelas a Parquet/ORC para minimizar los bytes escaneados.
El autoescalado de DPU de Glue puede sobreaprovisionar — establece un límite máximo de DPU en la configuración del trabajo (consola o

undefined

) y elige los tipos de worker apropiados para mantener los costos predecibles.

Tarifas de recuperación de S3 Glacier — evita la recuperación acelerada (Expedited) a menos que sea crítica para el negocio; planifica recuperaciones estándar (Standard) o masivas (Bulk) y establece transiciones de ciclo de vida con SLAs realistas.
Los nodos maestros y principales (core) de EMR no deben usar Spot — configura los nodos maestros/principales como On-Demand y asigna Spot solo a los nodos de tarea (task) donde el estado de HDFS se evite o se replique.
Muchos objetos pequeños en S3 inflan los costos de solicitud y ralentizan los análisis — compacta archivos pequeños en archivos columnares más grandes durante la ingesta.
La dependencia excesiva del escalado de concurrencia o del autoescalado no gestionado puede aumentar los cargos por hora — monitorea las métricas de escalado, establece límites y usa capacidad reservada cuando las cargas de trabajo sean predecibles.

Problema práctico: Reducción de costos del ETL nocturno de Acme Analytics

Acme Analytics ejecuta un ETL nocturno y análisis ad-hoc diarios; el gasto mensual en la nube se ha disparado debido al creciente almacenamiento de datos crudos en S3 y a las horas de Redshift bajo demanda (on-demand). La empresa necesita una reducción del 35% sin afectar los SLAs nocturnos.

Ejecuta un Análisis de clases de almacenamiento de S3 (Storage Class Analysis) y reglas de ciclo de vida para mover los archivos crudos fríos de más de 90 días a Glacier Flexible Retrieval (planifica recuperaciones masivas (Bulk)/estándar (Standard)).
Convierte los CSV crudos a formato Parquet particionado y comprimido, y compacta los archivos pequeños; almacena los conjuntos de datos optimizados bajo prefijos separados para Athena/Redshift Spectrum.
Crea grupos de trabajo (workgroups) de Athena con límites de datos escaneados por consulta y fuerza la configuración del grupo de trabajo; habilita la reutilización de resultados de consulta y establece un presupuesto mensual por grupo de trabajo.
Migra el ETL por lotes a trabajos Glue Flex para transformaciones no urgentes, establece límites máximos de DPU y prográmalos durante horas de menor actividad; conserva una flota estándar de Glue más pequeña para trabajos urgentes.
Dimensiona correctamente (Right-size) Redshift: compra Nodos reservados de 1 año para la computación base estable, mueve los datos históricos a S3 y usa Spectrum para consultas poco frecuentes, y habilita el escalado de concurrencia solo con monitoreo.

Justificación: La estrategia combina la optimización del formato de datos y del ciclo de vida (reduciendo los costos de almacenamiento y escaneo), la ejecución sin servidor de menor costo para trabajos flexibles (Glue Flex), la gobernanza de consultas (grupos de trabajo de Athena) y la capacidad reservada para computación sostenida para maximizar los descuentos, preservando al mismo tiempo la disponibilidad y el rendimiento.

← Monitoreo y resolución de problemas de pipelines de datos · Todos los dominios · Calidad →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →