SAA-C03
Deep Dive
Amazon Kinesis es la respuesta cuando el escenario involucra procesar millones de eventos en tiempo real (IoT, click-streams, logs de aplicación, transacciones financieras). SQS FIFO garantiza orden y deduplicación exacta cuando el procesamiento secuencial es crítico. SAA-C03 distingue cuándo usar streaming vs mensajería tradicional.
Contenido
Kinesis Data Streams permite ingestar y procesar flujos de datos en tiempo real a escala masiva. Los datos se dividen entre shards: cada shard acepta 1 MB/s de entrada y 2 MB/s de salida. La capacidad total del stream = número de shards × capacidad por shard.
Shards
Unidad de capacidad. Cada shard = 1 MB/s entrada, 2 MB/s salida. Escala horizontal añadiendo shards.
Retención
24h por defecto, hasta 365 días con Extended Retention. Permite replay de datos históricos.
Partition Key
Determina a qué shard va cada registro. Misma key siempre va al mismo shard — hot partition si no se distribuye bien.
Producers y Consumers
Producers
AWS SDK, Kinesis Producer Library (KPL), Kinesis Agent. KPL agrega registros y reintenta automáticamente.
Consumers
KCL, Lambda, Kinesis Data Analytics, Firehose. Con Enhanced Fan-Out cada consumer obtiene 2 MB/s dedicados por shard.
Consumers disponibles
Kinesis Consumer Library (KCL)
SDK para consumers personalizados. Gestiona checkpointing y balanceo de shards automáticamente.
AWS Lambda
Trigger nativo. Procesa registros en batches. Ideal para pipelines serverless.
Kinesis Data Analytics
SQL / Apache Flink sobre el stream en tiempo real. Sin gestión de infraestructura.
Kinesis Data Firehose
Consume el stream y entrega a destinos gestionados (S3, Redshift, OpenSearch).
Provisioned Mode
Gestión manual de shards. Se paga por shard-hora. Ideal cuando el throughput es predecible.
On-Demand Mode
Escala automáticamente según el tráfico. Se paga por GB procesado. Ideal para cargas variables o impredecibles.
Trampa de examen
Los datos en Kinesis Streams son inmutables — no se pueden borrar manualmente. Solo expiran según la retención configurada (24 h por defecto, hasta 365 días). No confundir con SQS donde los mensajes se eliminan tras el procesamiento.
Firehose es un servicio completamente serverless para cargar datos en destinos gestionados. No requiere gestión de shards ni consumers. A cambio, introduce latencia por buffering: mínimo 60 segundos antes de entregar los datos.
Destinos gestionados
S3, Redshift, OpenSearch Service, Splunk, HTTP endpoints personalizados.
Transformaciones en vuelo
Lambda para transformar/filtrar registros. Conversión automática a Parquet u ORC antes de cargar.
Buffering
Acumula datos antes de entregar. Buffer size: 1–128 MB. Buffer interval: 60–900 segundos.
Diferencia clave con Kinesis Data Streams
Procesamiento en tiempo real. Múltiples consumers leen el mismo stream. Datos persisten (retención configurable). Control total del consumer.
Delivery gestionado a destino. No hay consumers custom. Latencia de 60 s mínimo. Serverless y sin gestión de capacidad.
Trampa de examen
Firehose NO es tiempo real puro. Si el escenario exige procesamiento con latencia menor a 60 segundos, la respuesta es Kinesis Data Streams, no Firehose. Firehose es para carga/ETL, no para reacción instantánea a eventos.
Permite ejecutar consultas SQL sobre streams en tiempo real usando Kinesis Streams o Firehose como fuente. Completamente gestionado — no hay servidores que aprovisionar.
SQL sobre Streams
Consultas con ventanas de tiempo (tumbling windows, sliding windows). Ideal para métricas agregadas en tiempo real: promedio, suma, conteo por ventana temporal.
Managed Apache Flink
Para procesamiento más complejo con Java, Python o Scala. Permite lógica de negocio avanzada que SQL no puede expresar fácilmente.
Casos de uso principales
Detección de anomalías en tiempo real, alertas sobre métricas de negocio, enriquecimiento de streams con datos de referencia.
Fuentes soportadas
Kinesis Data Streams y Kinesis Data Firehose como source. El output puede ir a Streams, Firehose, Lambda u otros destinos.
SQS FIFO garantiza dos propiedades que SQS Standard no puede ofrecer: orden First-In-First-Out exacto y exactly-once processing mediante deduplicación. El trade-off es un throughput máximo más bajo.
Throughput
300 msg/s por defecto. Hasta 3 000 msg/s con batching (grupos de 10 mensajes).
Deduplicación
Message Deduplication ID. Si el mismo ID llega dentro de la ventana de 5 minutos, el duplicado se descarta.
Message Group ID
Agrupa mensajes para procesamiento ordenado por grupo. Distintos grupos se procesan en paralelo por distintos consumers.
SQS Standard vs SQS FIFO
SQS Standard
Throughput casi ilimitado. At-least-once delivery (puede duplicar). Best-effort ordering (no garantizado). Ideal para escala masiva donde el orden no importa.
SQS FIFO
300 msg/s (3 000 con batching). Exactly-once processing. Orden garantizado por Message Group. Nombre del queue debe terminar en .fifo.
Trampa de examen
El nombre del queue FIFO debe terminar en .fifo — sin ese sufijo la creación falla. Además, SQS Standard no se puede convertir a FIFO después de crearlo: hay que crear una nueva cola.
Kinesis Data Streams
Múltiples consumers leen los mismos datos, retención para replay, tiempo real estricto, big data / analytics.
SQS Standard
Desacoplamiento, alta escala, workers compiten por mensajes, orden no importa.
SQS FIFO
Orden garantizado, deduplicación exacta, transacciones financieras, casos con ≤300 msg/s.
Kinesis Firehose
ETL a S3/Redshift, no necesita procesamiento custom, delivery completamente gestionado.
Patrones de keywords en el examen
"Millones de eventos IoT en tiempo real" → Kinesis Data Streams
"Procesar en orden exacto / deduplicación" → SQS FIFO con Message Group ID
"Cargar a S3 / Redshift sin gestión de infraestructura" → Kinesis Firehose
"Múltiples aplicaciones leen los mismos eventos" → Kinesis Streams (fan-out)
"Kinesis Firehose es tiempo real" — falso. Latencia mínima de 60 s por buffering
Hot partition = misma Partition Key para demasiados registros
Distribuir con una key de alta cardinalidad (ej: user_id, device_id). Un shard saturado descarta registros.
Enhanced Fan-Out cuando hay múltiples consumers con latencia baja
Cada consumer registrado obtiene 2 MB/s dedicados por shard. Sin Enhanced Fan-Out todos comparten 2 MB/s total del shard.
Firehose NO puede ser fuente de Kinesis Streams
La dirección es: Streams → Firehose. Firehose puede consumir desde Streams, no al revés.
SQS FIFO: el nombre del queue DEBE terminar en .fifo
Sin ese sufijo la creación falla. También recordar que no hay ordering en SQS Standard — no se puede activar "a posteriori".
Objetos en Kinesis Streams son inmutables
No se pueden borrar manualmente. Solo expiran según la retención configurada (24 h – 365 días).
Visualiza el flujo desde productores hasta consumidores a través de los shards del stream.
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
Una empresa procesa transacciones de pago. Necesitan garantizar que cada transacción se procese exactamente una vez y en el orden en que fue recibida por cuenta de cliente. El volumen es de 100 transacciones/segundo. ¿Qué servicio es el más adecuado?