Semana 9 · Módulo 9 de 11

Datos, analítica y machine learning: ingesta, transformación y servicios de IA

Aprenderás a diseñar la ingesta (streaming y por lotes), la transformación y la explotación de datos en AWS: Kinesis, Data Firehose, MSK, Glue, Athena, Lake Formation, EMR, Redshift, OpenSearch y Amazon Quick, más los servicios de IA preentrenados y SageMaker AI. Es el task statement 3.5 completo y una fuente constante de preguntas «¿qué servicio encaja?».

Reparto de la semana

Por qué importa

Casi todas las empresas tienen el mismo problema: datos que llegan de muchos sitios (aplicaciones, dispositivos, bases de datos, ficheros de socios) a ritmos distintos y que alguien quiere consultar, cruzar y visualizar. El task statement 3.5, Determine high-performing data ingestion and transformation solutions, pregunta exactamente eso: cómo capturar datos, cómo transformarlos y dónde analizarlos con el rendimiento y el coste adecuados.

El examen no te pedirá escribir código Spark ni SQL complejo. Te dará un escenario («10.000 sensores envían lecturas cada segundo», «los analistas quieren consultar con SQL ficheros CSV en S3 sin gestionar servidores», «hay que convertir los datos a Parquet antes de guardarlos») y te hará elegir el servicio o la combinación correcta. Las palabras clave deciden: real-time, near real-time, replay, ordering, serverless, LEAST operational overhead, ad hoc queries, columnar, fine-grained access.

Además, este módulo cubre los servicios de IA preentrenados (Comprehend, Polly, Rekognition…), que la guía menciona en el task statement 2.2 como ejemplos de servicios gestionados con casos de uso concretos, y Amazon EMR como opción de cómputo (task statement 3.2).

Conceptos base: frecuencia, tamaño y formato

Patrones de ingesta según la frecuencia

Tamaños y velocidades

El temario pide conocer sizes and speeds needed to meet business requirements. En la práctica, antes de elegir servicio haz tres cuentas:

1. Caudal de entrada: registros por segundo × tamaño medio del registro. Ejemplo: 5.000 lecturas/s de 2 KB = 10 MB/s.
2. Caudal de lectura: cuántas aplicaciones leen los mismos datos y a qué velocidad.
3. Volumen acumulado y retención: cuántos días hay que guardar los datos en el sistema de ingesta y cuántos en el almacenamiento final.

Con eso puedes dimensionar un stream (cuántos shards), elegir el modo de capacidad y estimar el coste. Lo verás aplicado en Kinesis Data Streams.

Formatos de fichero, compresión y particionado

• Formatos por filas: CSV, JSON, Avro. Fáciles de producir; para leer una columna hay que leer la fila entera.
• Formatos columnares: Apache Parquet y Apache ORC. Guardan cada columna junta, comprimen muy bien y permiten leer solo las columnas de la consulta. Son la respuesta cuando el enunciado habla de «reducir el coste de Athena», «consultas analíticas más rápidas» o columnar format (también aparece en el task statement 4.3: time series format, columnar format).
• Compresión: GZIP, Snappy, ZSTD… Menos bytes almacenados y escaneados.
• Particionado: organizar los objetos por prefijos tipo dt=2026-09-30/ o pais=es/. Los motores (Athena, Redshift Spectrum, EMR, Glue) leen solo las particiones que cumplen el filtro WHERE.
• Formatos de tabla abiertos: Apache Iceberg (y Hudi o Delta Lake) añaden transacciones, actualizaciones y viajes en el tiempo sobre ficheros Parquet en S3. Athena, Glue, EMR, Redshift y Firehose soportan Iceberg; para el examen basta con saber que existen.

Amazon Kinesis Data Streams

Kinesis Data Streams (KDS) es un servicio de streaming en tiempo real: los productores escriben registros y uno o varios consumidores los leen, en orden, durante el periodo de retención. Piensa en un registro de eventos (log) distribuido, duradero y que se puede releer.

Shards, partition key y orden

• Un stream se divide en shards (fragmentos). Cada shard es una secuencia ordenada de registros.
• Cada registro lleva una partition key. AWS la convierte en un hash y decide en qué shard cae. Todos los registros con la misma clave van al mismo shard y conservan el orden.
• Capacidad por shard (modo provisioned, verificado en la documentación de cuotas): escritura hasta 1 MB/s o 1.000 registros/s; lectura hasta 2 MB/s o 2.000 registros/s compartidos por los consumidores estándar (GetRecords, hasta 5 lecturas por segundo por shard).
• Si una clave concentra mucho tráfico aparece un hot shard y errores ProvisionedThroughputExceededException. Solución: claves con más cardinalidad (por ejemplo, idDispositivo en lugar de pais) o más shards.
• Tamaño de registro: la documentación actual admite cargas de hasta 10 MiB por registro (antes base64), pensadas para registros grandes ocasionales. El material antiguo dice 1 MB: si una pregunta vieja lo menciona, recuerda que el límite ha cambiado, pero el diseño correcto para ficheros grandes sigue siendo guardar el objeto en S3 y enviar la referencia.

Modos de capacidad

Puedes cambiar de modo dos veces cada 24 horas por stream. La documentación de 2026 menciona además un modo On-demand Advantage (sin cargo por stream y hora, con un compromiso mínimo de caudal); es una novedad que no esperarías en el examen.

Retención y relectura

La retención por defecto es de 24 horas y se puede ampliar hasta 365 días (8.760 horas) con coste adicional. Durante ese tiempo cualquier consumidor puede releer (replay) desde un punto concreto: por eso KDS encaja cuando hay que reprocesar tras un fallo o añadir un consumidor nuevo que lea el histórico.

Consumidores

• Lambda (mapeo de origen de eventos): procesa lotes de registros por shard. La opción serverless más habitual.
• Kinesis Client Library (KCL) en EC2, ECS o EKS: aplicaciones propias que coordinan la lectura con una tabla de DynamoDB.
• Amazon Data Firehose: puede usar un stream como origen para entregar a S3, Redshift, OpenSearch…
• Amazon Managed Service for Apache Flink: análisis con estado (ventanas, agregaciones, detección de anomalías) sobre el stream. Sustituye a Kinesis Data Analytics for SQL, que llegó a su cierre total el 27/01/2026; no lo elijas aunque aparezca en material antiguo.
• Enhanced fan-out: cada consumidor registrado recibe su propio caudal de lectura por shard (en lugar de compartir los 2 MB/s) con entrega por push (SubscribeToShard). Úsalo con muchos consumidores o cuando la latencia de lectura importa. Hasta 20 consumidores registrados por stream en los modos habituales.

Seguridad

• Acceso con IAM (políticas de identidad) y, si hace falta entre cuentas, políticas basadas en recursos del stream.
• Cifrado en reposo con AWS KMS (clave gestionada por AWS o por ti) y en tránsito con TLS.
• Interface VPC endpoint (AWS PrivateLink) para que productores en subredes privadas escriban sin pasar por Internet ni por NAT.

Dimensionar un stream: ejemplo

Una app de movilidad recibe 3.000 posiciones por segundo de 1 KB (≈3 MB/s) y tres consumidores estándar leen todo.

• Escritura: 3 MB/s → al menos 3 shards (1 MB/s cada uno). Registros: 3.000/s → también 3 shards.
• Lectura: 3 consumidores × 3 MB/s = 9 MB/s → con lectura compartida (2 MB/s por shard) harían falta 5 shards; con enhanced fan-out, cada consumidor tiene su propio caudal y bastan 3.
• Si el tráfico se duplica los viernes y no quieres gestionarlo: on-demand.

Amazon Data Firehose

Amazon Data Firehose (antes Kinesis Data Firehose; renombrado en 2024) es el servicio totalmente gestionado para cargar datos en streaming en un destino. No hay shards que dimensionar ni consumidores que programar: configuras origen, transformación opcional y destino.

Cómo funciona

• Orígenes: Direct PUT (tu aplicación, el agente de Kinesis, CloudWatch Logs, AWS IoT, EventBridge…), un Kinesis Data Stream o un clúster de Amazon MSK.
• Buffering: Firehose acumula datos por tamaño o por intervalo y entrega cuando se cumple lo primero. Para S3, el tamaño va de 1 a 128 MB (5 MB por defecto) y el intervalo de 0 a 900 s (300 s por defecto). Por eso es near real-time: segundos o minutos, no milisegundos.
• Transformación con Lambda: una función recibe lotes, los modifica (limpiar, enriquecer, pasar CSV a JSON) y los devuelve.
• Conversión de formato: convierte JSON a Apache Parquet u ORC antes de escribir en S3. Necesita el esquema en una tabla del AWS Glue Data Catalog. Si la entrada es CSV u otro formato, primero una Lambda la pasa a JSON. Con la conversión activada, el buffer mínimo es de 64 MiB.
• Particionado dinámico: crea prefijos en S3 a partir de campos del propio registro (por ejemplo, cliente=123/), ideal para Athena.
• Compresión (GZIP, Snappy, ZIP…) y cifrado SSE-KMS en S3.
• Copia de seguridad en S3 de los registros originales o de los fallidos.
• Escalado automático: no hay capacidad que gestionar.

Destinos

Según la documentación actual: Amazon S3, tablas Apache Iceberg, Amazon Redshift (Firehose escribe en S3 y lanza un COPY), Amazon OpenSearch Service y OpenSearch Serverless, puntos de conexión HTTP y una lista larga de terceros (Splunk, Snowflake, Datadog, New Relic, Dynatrace, MongoDB Atlas, Elastic, Sumo Logic…).

Amazon MSK (Managed Streaming for Apache Kafka)

Amazon MSK ejecuta Apache Kafka de código abierto gestionado por AWS: crea los brokers repartidos por AZ, sustituye los que fallan y gestiona los metadatos (ZooKeeper o, en versiones recientes, KRaft).

• MSK Provisioned: eliges número y tipo de brokers (Standard o Express) y el almacenamiento.
• MSK Serverless: sin dimensionar brokers; pagas por uso.
• MSK Connect: ejecuta conectores de Kafka Connect para mover datos desde y hacia otros sistemas.
• MSK Replicator: replica entre clústeres (incluso entre regiones).

Elige MSK cuando el enunciado diga «ya usamos Kafka», «migrar Kafka local sin cambiar el código», «compatibilidad con el ecosistema de Kafka» o conceptos propios de Kafka (topics, partitions, consumer groups). Si no hay dependencia de Kafka y se busca lo más simple, Kinesis suele ser la respuesta.

Tabla de decisión: KDS frente a Firehose, MSK y SQS

Amazon Kinesis Video Streams

Kinesis Video Streams ingiere vídeo en directo (y otros datos serializados en el tiempo: audio, imágenes térmicas, radar) desde millones de dispositivos: cámaras de seguridad, móviles, drones, coches. Almacena el vídeo cifrado durante la retención que configures, lo indexa por tiempo y permite reproducirlo en directo o procesarlo frame a frame o por lotes (por ejemplo, con Amazon Rekognition Video o modelos propios en SageMaker AI). También ofrece WebRTC para comunicación bidireccional de baja latencia.

Señal en el examen: «transmitir vídeo de cámaras a AWS para analizarlo» → Kinesis Video Streams (no Kinesis Data Streams, que es para registros de datos).

Servicios de transferencia de datos en contexto

El temario 3.5 incluye data transfer services with appropriate use cases (for example, AWS DataSync, AWS Storage Gateway). Se explican a fondo en el módulo 03 (almacenamiento) y AWS DMS en el módulo 04; aquí tienes el mapa para decidir la ingesta de datos no streaming:

Seguridad de los puntos de ingesta

El temario pide secure access to ingestion access points. Aplica defensa en profundidad:

1. Identidad: roles de IAM con mínimo privilegio para productores y consumidores (kinesis:PutRecord solo en el stream concreto; firehose:PutRecordBatch solo en su Firehose). Nada de claves de acceso fijas en dispositivos: usa roles, Amazon Cognito para apps móviles o credenciales temporales.
2. Red privada: interface VPC endpoints para Kinesis Data Streams, Firehose, Glue o Athena; gateway endpoint para S3 (gratuito). Así el tráfico no sale a Internet ni paga NAT Gateway.
3. Políticas de recursos: políticas de bucket que solo acepten escrituras desde un VPC endpoint (condición aws:SourceVpce) o desde el rol de Firehose; políticas de recurso en streams para acceso entre cuentas.
4. Cifrado: TLS en tránsito; SSE-KMS en Kinesis, Firehose, S3, Glue Data Catalog, Redshift y OpenSearch.
5. Gobierno del data lake: AWS Lake Formation para permisos por tabla, columna y fila; CloudTrail para auditar quién accede.
6. APIs públicas de ingesta: API Gateway delante de Kinesis o SQS (integración directa de servicio) con autenticación (Cognito, IAM, Lambda authorizer), throttling y AWS WAF.

El data lake en Amazon S3

Un data lake guarda todos los datos (estructurados y no estructurados) en su formato original, en un almacenamiento barato y escalable, y separa el almacenamiento del cómputo: varios motores (Athena, EMR, Redshift Spectrum, Glue, SageMaker AI) leen los mismos ficheros. En AWS, el almacenamiento es Amazon S3, el catálogo es AWS Glue Data Catalog y el gobierno lo pone AWS Lake Formation.

Organización típica por zonas (prefijos o buckets):

• raw / bronze: datos tal como llegan (JSON, CSV, logs). Inmutables; sirven para reprocesar.
• processed / silver: limpios, tipados y en Parquet, particionados.
• curated / gold: agregados listos para negocio (tablas de hechos, KPI).

Buenas prácticas: cifrado por defecto con SSE-KMS, Block Public Access, versionado en la zona raw, ciclo de vida hacia clases más baratas (S3 Standard-IA, Glacier) para datos antiguos, S3 Intelligent-Tiering si el patrón de acceso es desconocido, y separación de cuentas o buckets por zona.

flowchart LR
  subgraph Ingesta
    A["Apps y dispositivos"] --> KDS["Kinesis Data Streams"]
    KDS --> FH["Data Firehose (Parquet)"]
    B["Bases de datos"] --> DMS["AWS DMS"]
    C["Ficheros on-premises"] --> DS["AWS DataSync"]
  end
  subgraph LAKE["Data lake en S3"]
    RAW["raw (JSON/CSV)"]
    PROC["processed (Parquet particionado)"]
    CUR["curated (agregados)"]
  end
  FH --> PROC
  DMS --> RAW
  DS --> RAW
  RAW --> GLUE["Glue ETL / crawlers"]
  GLUE --> PROC
  PROC --> GLUE2["Glue / EMR"]
  GLUE2 --> CUR
  CAT["Glue Data Catalog + Lake Formation"] -.-> PROC
  CAT -.-> CUR
  PROC --> ATH["Athena"]
  CUR --> RS["Redshift / Spectrum"]
  ATH --> Q["Amazon Quick"]
  RS --> Q

AWS Glue

AWS Glue es el servicio serverless de integración de datos: descubre, cataloga, limpia, transforma y mueve datos. Sus piezas clave:

• AWS Glue Data Catalog: el metastore central (compatible con Hive) con bases de datos, tablas, esquemas y particiones. Lo usan Athena, EMR, Redshift Spectrum, Lake Formation y Firehose (para la conversión de formato). Es la respuesta a «catálogo central de metadatos del data lake».
• Crawlers: recorren S3 (y bases de datos JDBC, DynamoDB…), infieren el esquema y crean o actualizan tablas y particiones en el Data Catalog. Se programan o se lanzan por eventos.
• ETL jobs: trabajos Apache Spark serverless (por lotes o streaming ETL desde Kinesis o Kafka) o scripts Python shell para tareas ligeras. Se pagan por DPU-hora (Data Processing Unit) y solo mientras se ejecutan. Los trabajos con el motor Ray están en mantenimiento desde el 31/03/2026 (no admiten clientes nuevos).
• Glue Studio: editor visual que genera el código del job.
• Job bookmarks: recuerdan qué datos ya se procesaron para hacer cargas incrementales.
• Triggers y workflows: encadenan crawlers y jobs (programados, bajo demanda o por eventos).
• AWS Glue DataBrew: preparación de datos visual y sin código (limpiar, normalizar, perfilar) para analistas. Señal: «analistas sin conocimientos de programación deben limpiar y normalizar datos».
• Glue Data Quality: reglas de calidad sobre los datos.
• FindMatches y detección de datos sensibles: deduplicación con ML y localización de PII en el pipeline.

Transformar CSV a Parquet con Glue es el ejemplo de manual del temario (transforming data between formats, for example, .csv to .parquet): un crawler cataloga el CSV, un job lo lee, cambia tipos, particiona y escribe Parquet en la zona processed, y otro crawler (o el propio job) actualiza el catálogo.

Amazon Athena

Amazon Athena es un motor SQL serverless (basado en Trino/Presto) que consulta directamente ficheros en S3 usando el Glue Data Catalog. No hay clúster: pagas por datos escaneados. Según la página de precios (consultada el 30/09/2026), el precio de referencia de las consultas SQL es de unos 5 USD por TB escaneado (estimación; comprueba tu región en https://aws.amazon.com/athena/pricing/). También existe capacidad aprovisionada (Capacity Reservations, por DPU-hora) para cargas constantes.

Cómo reducir coste y tiempo de consulta:

• Parquet/ORC en lugar de CSV/JSON: se leen solo las columnas pedidas.
• Compresión.
• Particionado y filtros WHERE por la columna de partición; partition projection para no tener que registrar millones de particiones en el catálogo.
• Ficheros ni muy pequeños ni gigantes (evita miles de ficheros de pocos KB).
• CTAS (CREATE TABLE AS SELECT) e INSERT INTO para convertir una tabla CSV en Parquet particionado sin salir de Athena: otra forma de transformar formatos.
• Workgroups para separar equipos, fijar la ubicación de resultados y poner límites de datos escaneados por consulta o por grupo (control de costes).

Otras capacidades: federated queries (conectores ejecutados en Lambda para consultar DynamoDB, RDS, Redshift, CloudWatch Logs… junto con S3), consultas sobre tablas Iceberg, Athena para Apache Spark y consultas a logs de AWS (CloudTrail, ALB, VPC Flow Logs, CloudFront) almacenados en S3.

AWS Lake Formation

AWS Lake Formation centraliza el gobierno y la seguridad del data lake sobre S3 y el Glue Data Catalog. Añade su propio modelo de permisos, tipo base de datos (GRANT/REVOKE), por encima de IAM.

• Permisos finos: a nivel de base de datos, tabla, columna, fila y celda (con data filters). Por ejemplo, el equipo de marketing ve la tabla de clientes sin las columnas de DNI ni teléfono y solo las filas de España.
• LF-Tags (tag-based access control): etiquetas sobre bases de datos, tablas y columnas; das permisos por etiqueta (confidencialidad=alta) en lugar de recurso a recurso. Escala a miles de tablas.
• Integración: los permisos se aplican en Athena, Redshift Spectrum, EMR (Spark), Glue ETL y Amazon Quick.
• Compartición entre cuentas (y con AWS Organizations) sin copiar datos.
• Ingesta desde bases de datos (MySQL, PostgreSQL, SQL Server, MariaDB, Oracle en RDS o EC2, o JDBC) al data lake.
• Auditoría con CloudTrail de quién accedió a qué datos.
• Hybrid access mode: activar Lake Formation poco a poco, conviviendo con permisos IAM y de S3.

Nota de estado: las Governed Tables de Lake Formation se cerraron el 31/12/2024; para tablas transaccionales hoy se usa Apache Iceberg.

Amazon EMR

Amazon EMR (antes Elastic MapReduce) ejecuta frameworks de big data de código abierto: Apache Spark, Hadoop, Hive, Presto/Trino, HBase, Flink… Es la respuesta cuando hay que procesar volúmenes muy grandes con control sobre el framework, reutilizar código Spark/Hadoop existente o ajustar configuraciones.

Opciones de despliegue

Tipos de nodo (EMR on EC2)

• Primary (antes master): gestiona el clúster (YARN ResourceManager, HDFS NameNode). Puedes tener tres para alta disponibilidad.
• Core: ejecutan tareas y almacenan datos en HDFS. Perderlos puede perder datos: con Spot, cuidado.
• Task: solo cómputo, sin HDFS. Candidatos ideales a Spot: si AWS los reclama no se pierden datos.

Patrón de coste clásico: clúster transitorio que arranca, procesa leyendo y escribiendo en S3 (EMRFS) en lugar de HDFS, y se apaga; nodos primary y core On-Demand, task en Spot. Para clústeres permanentes, managed scaling y Reserved Instances o Savings Plans.

¿Glue, EMR o Lambda?

Amazon Redshift (analítica)

Amazon Redshift es el data warehouse de AWS: base de datos columnar con procesamiento masivamente paralelo (MPP) para consultas analíticas (OLAP) sobre TB o PB. El módulo 04 lo presenta como base de datos; aquí nos interesa su papel analítico.

• Arquitectura: un leader node recibe las consultas y planifica; los compute nodes las ejecutan en paralelo.
• Tipos de nodo: RA3 (y los nuevos RG, basados en Graviton) con managed storage: almacenamiento en SSD local más S3, de modo que escalas cómputo y almacenamiento por separado y pagas solo el almacenamiento usado. DC2 guarda los datos en SSD local (recomendado solo para conjuntos pequeños). Los DS2 ya no existen.
• Redshift Serverless: sin clúster; capacidad en RPU que escala sola y pago por uso. Ideal para cargas intermitentes o impredecibles.
• Redshift Spectrum: consulta datos en S3 sin cargarlos, con tablas externas del Glue Data Catalog (y permisos de Lake Formation). Permite hacer joins entre tablas locales de Redshift y el data lake.
• Carga: COPY desde S3 (paralelo, la forma recomendada), Firehose, AWS DMS, integraciones zero-ETL desde bases de datos como Aurora.
• Otras capacidades: concurrency scaling (capacidad extra para picos de usuarios), data sharing entre clústeres y cuentas sin copiar datos, snapshots automáticos y copia de snapshots entre regiones, pausa y reanudación del clúster (solo pagas almacenamiento mientras está en pausa), nodos reservados para cargas estables.

Athena, Redshift o Redshift Spectrum

Amazon OpenSearch Service

Amazon OpenSearch Service ofrece clústeres gestionados de OpenSearch (bifurcación de Elasticsearch) y OpenSearch Dashboards. Casos de uso:

• Búsqueda de texto completo en catálogos, documentos o webs (relevancia, autocompletado, facetas).
• Análisis de logs y observabilidad casi en tiempo real (ingesta con Firehose u OpenSearch Ingestion).
• Búsqueda vectorial para aplicaciones de IA.

Puede desplegarse como dominio gestionado (eliges instancias, nodos maestros dedicados, varias AZ, almacenamiento UltraWarm y en frío para datos antiguos) o como OpenSearch Serverless (colecciones que escalan solas). Sustituye a Amazon CloudSearch, que está en mantenimiento desde 2024.

Señal: «buscar por palabras clave en millones de documentos», «análisis interactivo de logs con paneles» → OpenSearch. «Consultas SQL analíticas sobre el data lake» → Athena/Redshift.

Amazon Quick (antes Amazon QuickSight)

La guía oficial ya llama al servicio Amazon Quick. Historia del nombre: Amazon QuickSight se integró el 09/10/2025 en Amazon Quick Suite y hoy la documentación habla de Amazon Quick; la parte de business intelligence se denomina Amazon Quick Sight. En el examen puedes verlo con cualquiera de esos nombres.

Qué hace (lo que importa para el SAA):

• BI serverless: paneles (dashboards) interactivos y análisis para usuarios de negocio, sin servidores que gestionar.
• Fuentes: Athena, Redshift, S3, RDS/Aurora, OpenSearch, ficheros, SaaS y bases de datos locales.
• SPICE: motor en memoria que importa los datos para consultas rápidas y para no cargar la fuente con cada visualización.
• Seguridad: seguridad a nivel de fila, integración con Lake Formation, acceso privado a fuentes en VPC.
• Analítica embebida en tus aplicaciones y preguntas en lenguaje natural (capacidades de IA generativa, en constante cambio).

Señal: «paneles para directivos», «visualizar los resultados de Athena o Redshift», business intelligence, dashboards for business users → Amazon Quick.

Estrategias de visualización

AWS Data Exchange

AWS Data Exchange permite encontrar, suscribirse y usar datos de terceros (y compartir los tuyos) de forma gobernada: datos financieros, meteorológicos, de mercado, sanitarios… Los datos se entregan como ficheros en S3, acceso directo a buckets de S3, APIs, datashares de Redshift o permisos de Lake Formation (en preview). También da acceso a los conjuntos públicos del programa Open Data on AWS.

Señal: «incorporar datos de un proveedor externo al data lake sin montar un proceso de intercambio de ficheros» o «suscribirse a conjuntos de datos de terceros» → Data Exchange.

Amazon Elastic Transcoder (retirado)

Amazon Elastic Transcoder convertía vídeo almacenado en S3 a otros formatos y resoluciones (para móviles, web, TV). Sigue en la lista in-scope de la guía, pero llegó a su cierre total el 13/11/2025. Su sustituto real es AWS Elemental MediaConvert, que la guía marca como out of scope.

Cómo tratarlo en el examen: si una pregunta pide «convertir vídeos subidos a S3 a varios formatos para distintos dispositivos con un servicio gestionado», la opción que encaja con el temario es Elastic Transcoder (normalmente disparado por un evento de S3 o una Lambda). Sabe que en la realidad hoy usarías MediaConvert. No confundas la transcodificación (vídeo almacenado) con Kinesis Video Streams (vídeo en directo) ni con Amazon Transcribe (audio a texto).

Arquitecturas de referencia

Streaming en tiempo casi real (clickstream o IoT)

flowchart LR
  P["Web, móvil, sensores"] --> APIGW["API Gateway o SDK"]
  APIGW --> KDS["Kinesis Data Streams"]
  KDS --> L["Lambda: alertas en tiempo real"]
  KDS --> FL["Managed Service for Apache Flink: ventanas y agregados"]
  KDS --> FH["Data Firehose: Parquet + particionado"]
  L --> SNS["SNS / DynamoDB"]
  FH --> S3["S3 data lake"]
  S3 --> ATH["Athena"]
  ATH --> Q["Amazon Quick"]
  FH -.->|copia de logs| OS["OpenSearch: búsqueda y paneles"]

Claves: un único stream con varios consumidores independientes; lo urgente se procesa en segundos (Lambda o Flink) y todo se archiva barato en S3 en formato columnar para análisis posterior.

ETL por lotes (nocturno)

flowchart LR
  ONP["Servidor de ficheros local"] --> DS["DataSync programado"]
  DB["Base de datos OLTP"] --> DMS["AWS DMS"]
  DS --> RAW["S3 raw (CSV)"]
  DMS --> RAW
  EB["EventBridge Scheduler"] --> SF["Step Functions"]
  SF --> CR["Glue crawler"]
  SF --> JOB["Glue job Spark: CSV a Parquet"]
  RAW --> JOB
  JOB --> PROC["S3 processed (Parquet)"]
  PROC --> RS["Redshift COPY / Spectrum"]
  RS --> Q["Amazon Quick"]

Claves: orquestación con Step Functions o workflows de Glue, cargas incrementales con job bookmarks, catálogo actualizado por crawlers y almacenamiento separado del cómputo.

Data lake gobernado y multicuenta

Una cuenta central de datos con los buckets de S3, el Glue Data Catalog y Lake Formation; las cuentas de consumo (analítica, ML, BI) reciben permisos por LF-Tags o compartición entre cuentas, y consultan con Athena, Redshift Spectrum o EMR sin copiar datos. Toda la actividad queda en CloudTrail.

Servicios de IA y machine learning

AWS ofrece servicios de IA preentrenados: los llamas por API, sin entrenar modelos ni saber de ML. La guía los usa como ejemplo de AWS managed services with appropriate use cases (task 2.2) y el examen los pregunta como «¿qué servicio resuelve esta tarea?».

Qué servicio para qué tarea

Combinaciones típicas (el examen adora encadenarlas):

• Llamadas de clientes → Transcribe → Comprehend (sentimiento) → S3 y Athena/Quick.
• Documentos escaneados → Textract → Comprehend (entidades, PII) → OpenSearch para buscarlos.
• Chat multilingüe → Translate → Lex.
• Vídeo en directo → Kinesis Video Streams → Rekognition Video.
• Texto → Translate → Polly para generar audio en otro idioma.

Estado real (septiembre de 2026): algunas funciones concretas están en mantenimiento (por ejemplo, topic modeling y event detection de Comprehend, o los streaming events de Rekognition desde el 31/03/2026), pero los servicios en sí siguen activos y los casos de uso de la tabla son válidos.

¿SageMaker AI o un servicio preentrenado?

Amazon SageMaker AI (antes Amazon SageMaker) es la plataforma para el ciclo completo de ML: preparar datos, entrenar (con algoritmos integrados o frameworks como PyTorch y TensorFlow), ajustar hiperparámetros, desplegar endpoints de inferencia (en tiempo real, serverless, asíncronos o por lotes) y gestionar modelos (MLOps). SageMaker Canvas ofrece ML sin código para analistas.

Varias subfunciones de SageMaker AI (Ground Truth, Clarify, Debugger, Model Monitor…) están en mantenimiento desde el 30/06/2026; para el SAA basta con los casos de uso generales. Amazon Bedrock (modelos fundacionales de IA generativa) no aparece en la lista de servicios del examen.

Trampas típicas del examen

• Firehose no es tiempo real estricto ni permite relectura. «Procesar cada evento en menos de un segundo con varios consumidores» → Kinesis Data Streams.
• Kinesis Data Streams no carga solo en S3. Necesitas un consumidor (Firehose, Lambda, KCL). Si la pregunta solo quiere «llevar los datos a S3 con el mínimo esfuerzo», Firehose directamente.
• SQS frente a Kinesis: SQS reparte trabajos entre workers y borra el mensaje al procesarlo; Kinesis conserva el flujo ordenado para varios consumidores y relecturas.
• Hot shard: errores de throughput con poco tráfico total → mala partition key, no falta de memoria en los consumidores.
• Convertir a Parquet: Firehose (en streaming) o Glue/Athena CTAS (por lotes). Firehose necesita la tabla en el Glue Data Catalog y solo convierte desde JSON.
• Athena caro → formato columnar, compresión y particiones. Añadir workgroups con límites de escaneo controla el gasto, pero no lo optimiza.
• Permisos por columna o fila → Lake Formation, no políticas de bucket.
• Catálogo de metadatos compartido por Athena, EMR y Redshift Spectrum → Glue Data Catalog (no DynamoDB ni RDS).
• EMR y Spot: nodos task en Spot sí; core con cuidado (HDFS); para no perder datos, guarda en S3.
• Redshift no es OLTP. Y para «consultar datos en S3 desde Redshift sin cargarlos» → Spectrum.
• OpenSearch para búsqueda de texto y logs; Quick para BI; Grafana para métricas operativas.
• Kinesis Video Streams (vídeo en directo) ≠ Elastic Transcoder (conversión de ficheros de vídeo, retirado) ≠ Transcribe (audio a texto) ≠ Translate (texto a texto).
• Textract extrae texto de documentos; Rekognition también detecta texto, pero en imágenes y escenas, no formularios ni tablas.
• Servicio preentrenado antes que SageMaker AI cuando la tarea es genérica y se pide el menor esfuerzo.
• Nombres nuevos: Data Firehose (Kinesis Data Firehose), Amazon Quick (QuickSight), SageMaker AI (SageMaker), Managed Service for Apache Flink (Kinesis Data Analytics).

Resumen

• Clasifica la ingesta por frecuencia: lotes (DataSync, DMS, Glue), near real-time (Firehose) y tiempo real (Kinesis Data Streams, MSK).
• Kinesis Data Streams: shards de 1 MB/s de escritura y 2 MB/s de lectura, orden por partition key, retención de 24 h a 365 días, on-demand o provisioned, enhanced fan-out para muchos consumidores.
• Data Firehose: entrega gestionada con buffering, Lambda, conversión JSON→Parquet/ORC con el Glue Data Catalog, particionado dinámico y destinos como S3, Redshift, OpenSearch o HTTP.
• MSK cuando hay Kafka; SQS para desacoplar trabajos.
• Data lake: S3 + Glue Data Catalog + Lake Formation; zonas raw/processed/curated; Parquet, compresión y particiones.
• Glue para ETL serverless (crawlers, jobs, DataBrew); Athena para SQL serverless pagando por TB escaneado; EMR para big data con frameworks abiertos (task nodes en Spot, EMR Serverless sin clúster).
• Redshift para data warehouse (RA3/RG, Serverless, Spectrum); OpenSearch para búsqueda y logs; Amazon Quick para BI; Data Exchange para datos de terceros.
• Servicios de IA: Comprehend (texto), Lex (chatbots), Polly (texto a voz), Rekognition (imagen/vídeo), Textract (documentos), Transcribe (voz a texto), Translate (traducción); SageMaker AI para modelos propios.

Cobertura del temario

Task 3.5: Determine high-performing data ingestion and transformation solutions

Puntos de otros task statements tratados aquí

Practica lo aprendido

Documentación oficial para ampliar

• Amazon Kinesis Data Streams – Quotas and limits
• Amazon Data Firehose – Configure buffering hints
• Amazon Data Firehose – Convert input data format
• What is Amazon MSK?
• What is AWS Glue?
• What is AWS Lake Formation?
• Amazon Athena pricing
• Amazon EMR – primary, core and task nodes
• Amazon Redshift provisioned clusters
• Amazon Redshift Spectrum
• What is AWS Data Exchange?
• AWS services in full shutdown (Elastic Transcoder, Kinesis Data Analytics for SQL)