Ingesta en streaming: Kinesis, Amazon MSK y aterrizaje de streams en el lago

Las lecciones 02 a 05 pusieron ficheros, formatos y tablas en Amazon S3. Hasta aquí todo se ha movido por lotes. Esta lección trata de la otra mitad de la ingesta: eventos que llegan de forma continua y deben aterrizar en el lago sin perder su orden, duplicarse en silencio ni costar calladamente más de lo que el equipo de analítica recupera. Al final sabrás dimensionar un stream de Kinesis a partir de un número de registros por segundo, explicar exactamente dónde deja de existir el orden, decidir cuándo una hot key es un problema de la clave de partición y no de capacidad, configurar un buffer de Firehose que se dispare con la condición correcta, y defender un aterrizaje bronze idempotente aunque el pipeline sea at-least-once.

En esta lección:

• enunciarás el contrato del shard: 1 MB/s de escritura y 1,000 registros/s de entrada, 2 MB/s de lectura y 5 transacciones/s de lectura de salida, por shard, en ambos modos de capacidad, y sabrás qué no cambió cuando los registros subieron a 10 MiB;
• elegirás entre Provisioned, On-demand Standard y On-demand Advantage, incluido el suelo de 25 MB/s a nivel de cuenta que hace de Advantage la respuesta errónea en volumen bajo;
• rastrearás una clave de partición a través de MD5 hasta un rango de hash-clave y un shard, y explicarás por qué el orden es una promesa por clave y no de todo el stream;
• detectarás y arreglarás una hot key cuando el auto-escalado de on-demand no pueda ayudarte;
• dimensionarás fan-out compartido frente a enhanced fan-out y pondrás precio a la diferencia;
• trabajarás con el KPL (colección, agregación, limitación de tasa) y el KCL (leases, checkpoints, parentShardId), y conocerás la fecha de fin de soporte del KCL 1.x;
• configurarás Amazon Data Firehose de extremo a extremo: tamaño e intervalo del buffer, lotes de transformación con Lambda, conversión de JSON a Parquet contra un esquema de Glue, límites de dynamic partitioning y prefijos de error;
• aterrizarás datos en streaming con los tres patrones de aterrizaje en bronze y adjuntarás la etiqueta de semántica de entrega correcta a cada flecha;
• ejecutarás el patrón at-least-once hacia MERGE idempotente que hace seguro promover un bronze de ficheros planos;
• enrutarás telemetría de dispositivos a través de reglas de AWS IoT Core, y sabrás para qué sirve Kinesis Data Video Streams;
• compararás Amazon MSK provisioned, MSK Serverless, MSK Connect y las tablas de streaming de MSK, con la aritmética del punto de equilibrio entre brokers y serverless;
• estudiarás dos casos de clientes de AWS (Cisco Webex con MSK, VMware Carbon Black con Kinesis) y un cuadro de actualizaciones de octubre de 2026 con fuentes;
• practicarás con 12 preguntas tipo examen más cuatro comprobaciones interactivas.

---

1. El mapa de servicios: cinco caminos del evento al lago

Cada diseño de streaming en AWS es una composición de las mismas cinco piezas. Confundirlas es el error de arquitectura más común de este espacio, porque dos de ellas parecen tuberías y solo una de ellas es un log que puedes re-ejecutar.

• 📚 ¿Sabías que…? El nombre Firehose que tienes delante es cosmético pero carga peso en el material antiguo: AWS renombró Amazon Kinesis Data Firehose a Amazon Data Firehose el 9 de febrero de 2024, y declara que «no hay otros cambios, incluidos los endpoints del servicio, las APIs, la Interfaz de Línea de Comandos de AWS (AWS CLI), las políticas de acceso de AWS Identity and Access Management (IAM) y las métricas de Amazon CloudWatch» (AWS What's New, 2024-02-09; historial de documentos de Firehose, consultado 2026-10). Así que las acciones de IAM siguen siendo firehose:*, y un blog antiguo que diga «Kinesis Data Firehose» está describiendo exactamente el mismo servicio que estás configurando hoy.

---

2. Kinesis Data Streams: el contrato del shard

2.1 Un número lo gobierna todo

Un shard es «una secuencia de registros de datos identificada de forma única en un stream» y «una unidad de throughput base de un data stream de Kinesis.» El contrato, idéntico en los modos de capacidad provisioned y on-demand, es:

Dos cosas son ciertas a la vez y los estudiantes suelen colapsarlas en una: los bytes y el recuento de registros son topes independientes. Un stream de registros de 400 bytes choca contra el muro de 1,000 registros/s con solo 0.38 MB/s, así que los registros por segundo limitan mucho antes que los bytes. A la inversa, registros de 2 KB a 1,000/s usan solo 2 MB/s del presupuesto de lectura pero exactamente todo el ritmo de escritura en registros.

El cambio de tamaño de registro de 2025 es la trampa de esta sección. El 28 de octubre de 2025 AWS elevó el tamaño máximo de registro «hasta 10MiB: un aumento por diez respecto al límite anterior» y duplicó el techo de la petición PutRecords a 10 MiB, declarando a la vez con claridad que «los límites de throughput individuales por shard de 1MiB/s para escrituras y 2MiB/s para lecturas siguen sin cambios»: los registros grandes «hacen ráfagas temporalmente hasta 10MiB/s, promediando al final a 1MiB por segundo.» AWS recomienda mantener los registros grandes en «1-2% de tu recuento total de registros para un rendimiento óptimo.» La página de conceptos todavía conserva la frase más antigua de que el «blob de datos puede ser de hasta 1 MB» (consultada 2026-10); la página de límites y el anuncio de octubre de 2025 son los hechos actuales.

• 📚 ¿Sabías que…? PutRecords es deliberadamente no atómico: el AWS Big Data Blog registra que «PutRecords siempre devuelve un resultado 200, aunque algunos registros dentro del lote hayan fallado» y que «el fallo de un solo registro no detiene el procesamiento de los registros posteriores.» Así que un 200 OK de PutRecords significa la petición fue aceptada, no tu lote aterrizó, debes inspeccionar FailedRecordCount y los valores de ErrorCode por registro. En un solo host, un bucle crudo de PutRecord midió unos 5,500 RPS frente a unos 76,000 RPS con PutRecords en lote a través del KPL, «unas 800 veces mayor» (AWS Big Data Blog, 2015-08-07).

2.2 Modos de capacidad: tres formas, un contrato

Reglas prácticas que salen de esa tabla:

• Puedes cambiar de modo dos veces cada 24 horas por stream: un paramétrico de seguridad, no un interruptor libre. Diseña el cambio como un evento, no como un bucle.
• On-demand no es «sin límites». Un stream on-demand nuevo empieza en 4/8 MB/s, las Regiones no emblemáticas se quedan en 200/400 MB/s, y, lo importante, on-demand «se adapta automáticamente para manejar patrones de distribución de datos desiguales salvo que una única clave de partición supere el throughput de 1 MB/s y el límite de 1000 registros por segundo de un shard.»
• Advantage es más barato por GB pero tiene un suelo. El anuncio es explícito: la cuenta «se compromete a streamear con al menos 25 MiB/s de uso de ingesta de datos y 25 MiB/s de uso de recuperación de datos», a cambio de datos ingeridos con un precio 60% menor, recuperación 60% menor, recuperación de enhanced fan-out 68% menor y retención extendida 77% menor (AWS Big Data Blog, 2025-11-03). Un stream de desarrollo de 0.5 MB/s pagará por 25 MB/s que no usa.

2.3 Retención: de la ventana de replay al archivo a largo plazo

La retención por defecto es 24 horas, y es el mínimo; IncreaseStreamRetentionPeriod acepta hasta 8,760 horas (365 días). Tres tramos de coste hay detrás de esa perilla:

El replay es la razón de ser de la retención: Kinesis «proporciona el orden de los registros, así como la capacidad de leer y/o re-ejecutar los registros en el mismo orden para múltiples aplicaciones de Amazon Kinesis.» Una ventana de 24 horas significa que un bug de un consumidor descubierto a las 09:00 puede repararse y re-procesarse desde las 09:00 del día anterior, y nada más. Si tu aterrizaje bronze en S3 es la copia duradera (lección 05), la retención del stream es un presupuesto de re-procesamiento, no tu estrategia de copia de seguridad.

---

3. Claves de partición, orden y shards calientes

3.1 El camino que recorre realmente un registro

El productor suministra una clave de partición: «Las claves de partición son cadenas Unicode, con un límite de longitud máxima de 256 caracteres para cada clave.» AWS entonces usa «una función hash MD5 … para mapear las claves de partición a valores enteros de 128 bits y para mapear los registros de datos asociados a shards usando los rangos de hash-clave de los shards.» Todos los registros que comparten una clave aterrizan en el mismo shard, y por eso «la Kinesis Client Library (KCL) entrega todos los registros de una clave de partición dada al mismo procesador de registros.»

El orden, enunciado con precisión, tiene exactamente tres alcances y ni más ni menos:

1. Dentro de un shard: «los registros que Kinesis Data Streams recibe a través de una llamada GetRecords están estrictamente ordenados por número de secuencia.»
2. Dentro de una clave de partición: la clave siempre se mapea a un shard, así que el orden local a la clave sobrevive.
3. Mismo cliente, misma clave, opt-in: SequenceNumberForOrdering «garantiza números de secuencia estrictamente crecientes, para puts del mismo cliente y hacia la misma clave de partición … Si este parámetro no se fija, los registros se ordenan de forma gruesa según el tiempo de llegada.»

No hay orden de todo el stream, y PutRecords ni siquiera ordena dentro de su propio lote. Si tu MERGE aguas abajo asume una secuencia global, has diseñado una garantía que el servicio no proporciona.

3.2 Ejemplo resuelto E1, los registros/s limitan primero: dimensionado y coste

Escenario (en octubre de 2026): 2,500 registros/s a 400 bytes de media, constante 24x7, US East (N. Virginia).

Fíjate en las dos reglas de redondeo que hacen sorprendentes las facturas de streaming: la entrada de datos de Kinesis redondea cada registro hacia arriba al KB siguiente («si tus registros de datos son de 4.5 KB cada uno, Kinesis Data Streams contará cada registro como 5 KB»), mientras el medidor provisioned de PUT factura en unidades de payload de 25 KB. Un pipeline de registros de 900 bytes se factura como 1 KB por registro en on-demand y como una unidad por registro en provisioned, y son los registros/s los que dimensionan tus shards de cualquier manera.

3.3 Ejemplo resuelto E2: la hot key que el auto-escalado no puede arreglar

Escenario: una única clave tenant_id = acme envía 1,500 registros/s de 80 bytes.

Los propios remedios de AWS: «usa la operación de split-shard … Si no se necesita localidad u orden basado en la clave de partición actual, cambia el esquema de la clave de partición para aumentar su distribución. Si la aplicación productora está excediendo el límite de throughput de un shard debido a una única clave de partición (problema de hot key), cambia el esquema de la clave de partición.» Los productores avanzados pueden saltarse el mapeo MD5 con ExplicitHashKey para colocar una clave de forma deliberada: útil para drenar un shard caliente, peligroso si lo usas para maquillar un diseño de clave que debería cambiar.

• 📚 ¿Sabías que…? Una heurística útil de producción viene de la plataforma antifraude de Chime Financial: la descripción de AWS de su stack de streaming indica «aterrizamos en una correspondencia 1:1 entre Kinesis Shard y núcleo de vCPU» mientras ingerían «más de 1 millón de eventos por segundo» con latencia extremo a extremo de «menos de 15 segundos» (AWS Big Data Blog, 2023-09-19). Trátala como la regla práctica de dimensionado de workers de un solo equipo para una flota de KCL, no como una cuota del servicio: el número de workers debe seguir siendo al menos el número de shards para el paralelismo, y cada lease vive en DynamoDB.

---

4. Fan-out: lecturas compartidas frente a enhanced fan-out

Un stream solo es útil si varios consumidores pueden leerlo. Kinesis te da dos mecanismos con economías genuinamente distintas.

La frase de la FAQ que importa: «los consumidores de fan-out compartido comparten todos los 2 MB/segundo de throughput de lectura de un shard y los límites de cinco transacciones por segundo … Un consumidor de enhanced fan-out recibe su propia asignación de 2 MB/segundo de throughput de lectura.» Añade un segundo consumidor por sondeo y la tasa efectiva de lectura de cada uno se reduce a la mitad: el síntoma de producción clásico de que «añadir un consumidor lo ralentizó todo».

4.1 Ejemplo resuelto E3: dimensionado del fan-out y la factura de EFO

Escenario: un stream de 4 shards con tres lectores: (a) un sondeador Lambda usando la ruta compartida, (b) una aplicación Flink que necesita baja latencia, (c) Firehose leyendo de Kinesis Data Streams.

El comportamiento de la propia FAQ de Firehose es lo que fuerza la decisión: «Firehose llama a GetRecords() de Kinesis Data Streams una vez cada segundo por cada shard de Kinesis.» Si Firehose es tu sink, asume que el pool compartido ya está ocupado.

---

5. Productores y consumidores: KPL, KCL y la tabla de leases

5.1 KPL: colección, agregación, limitación de tasa

La Kinesis Producer Library se ejecuta como «un proceso separado, y se comunica con tu proceso de usuario padre usando IPC», y hace cuatro trabajos: reintentos automáticos, colección (agrupar muchos registros en peticiones PutRecords), agregación (empaquetar muchos registros de usuario en un registro de Kinesis) y limitación de tasa por shard con un cubo de tokens «por defecto … fijado un 50 por ciento por encima del límite real del shard.» También publica métricas de CloudWatch en tu nombre y añade latencia hasta RecordMaxBufferedTime.

Ejemplo resuelto E4: la agregación derrota el tope de registros/s.

El propio ejemplo de AWS coincide: «Con la agregación de KPL, puedes empaquetar 1,000 registros en solo 10 registros de Kinesis Data Streams, reduciendo el RPS a 10 (con 50 KB cada uno)», y «El límite de registros por segundo de Kinesis Data Streams limita a los clientes con registros menores de 1 KB.»

La portabilidad es el impuesto. Según la matriz de uso de AWS, un productor en cualquier lenguaje distinto de Java no puede usar el KPL, y un productor KPL de Java que alimenta a un consumidor no-Java debe desactivar la agregación: de lo contrario el consumidor tiene que des-agregar registros que nunca esperó. El PutRecords crudo es portable; la gestión de lotes, el manejo de fallos parciales, los reintentos y el backoff son tuyos.

5.2 KCL: leases, checkpoints y parentShardId

La Kinesis Client Library se compila en tu consumidor y te da:

• Leases: «cada shard está vinculado a un solo worker mediante un lease en cualquier momento dado», rastreado en una tabla de leases de DynamoDB. KCL 3.x crea tres tablas por defecto (lease, métricas de workers, estado del coordinador); desde KCL 3.5 el formato de tabla única consolida todos los metadatos en la tabla de leases.
• Checkpointing: «el proceso de almacenar de forma persistente la posición del último registro procesado con éxito en un shard», guardado en esa tabla de leases. Reinicia desde el checkpoint, no desde «ahora».
• parentShardId: «se usa para asegurar que el shard padre esté procesado por completo antes de que empiece el procesamiento en los shards hijos. Esto asegura que los registros se procesen en el mismo orden en que se pusieron en el stream.» Este es el único mecanismo que conserva el orden a través de un evento de reshard.

Dos fechas importan aquí. KCL 1.x llegó a fin de soporte el 30 de enero de 2026, y la guía de AWS es «migra tus aplicaciones KCL que usan la versión 1.x a la última versión de KCL»; para esta lección esa fecha ya pasó, así que cualquier consumidor 1.x está corriendo con tiempo prestado. Y KCL no es infraestructura gratis: las tablas de DynamoDB (se recomienda capacidad on-demand) y las métricas de CloudWatch viajan con él, y que el número de workers sea ≥ al número de shards es un requisito de paralelismo, no una preferencia de ajuste.

---

6. Amazon Data Firehose: un servicio de entrega, no un procesador

6.1 El pipeline, etapa por etapa

Firehose es «un servicio totalmente gestionado para entregar datos de streaming en tiempo real hacia destinos como Amazon Simple Storage Service (Amazon S3), Amazon Redshift, Amazon OpenSearch Service, Amazon OpenSearch Serverless, Splunk, Apache Iceberg Tables y cualquier endpoint HTTP personalizado.» Sus etapas, en orden:

1. Origen: PUT directo, Kinesis Data Streams, Amazon MSK, CloudWatch Logs, EventBridge, IoT, WAF, Network Firewall, HTTP.
2. Buffer: «Amazon Data Firehose acumula los datos de streaming entrantes hasta un cierto tamaño o durante un cierto período de tiempo antes de entregarlos a los destinos»; la condición que se cumpla primero dispara la entrega.
3. Transformación con Lambda (opcional): invocación por lote, payload limitado a 6 MB de forma síncrona, invocación de hasta 5 minutos, 3 reintentos por defecto (configurable 0 to 300).
4. Conversión de formato de registro (opcional): JSON a Parquet u ORC usando un esquema en el AWS Glue Data Catalog (deserializador, esquema, serializador).
5. Dynamic partitioning (opcional): claves basadas en JQ hacia prefijos de S3, hasta 500 particiones activas (ampliable a 2,500).
6. Destino, S3, tablas Iceberg, Redshift (vía S3 + COPY), OpenSearch, Splunk, Snowflake, HTTP, más prefijos de error y de backup.

6.2 Ejemplo resuelto E5: qué condición de buffer se dispara primero

Pistas de buffering para un destino S3: tamaño 1 to 128 MB (por defecto 5), intervalo 0 to 900 s (por defecto 300).

Tres modificadores cambian la aritmética:

• La conversión de formato eleva el suelo. Con la conversión activada «no puedes fijar SizeInMBs a un valor menor que 64», y «el valor se convierte en 128 cuando la habilitas.»
• El dynamic partitioning cuesta latencia. «Firehose usa buffering multietapa internamente. Por lo tanto, el retardo extremo a extremo de un lote de registros puede ser 1.5 veces el tiempo de pista de buffering configurado», y el buffering a cero no está disponible con la función.
• El buffering por debajo de 60 segundos cambia la factura de S3. «Firehose usa upload multiparte para el destino S3 cuando configuras un intervalo de tiempo de buffer menor de 60 segundos … verás un cierto aumento en los costes de la API PUT de S3.»

• 📚 ¿Sabías que…? La página de cuotas de Firehose contiene calladamente el argumento de escalado para Kinesis como origen: el PUT directo a Firehose está limitado (en us-east-1/us-west-2/eu-west-1) a «500,000 registros/segundo, 2,000 peticiones/segundo y 5 MiB/segundo», pero «cuando Kinesis Data Streams está configurado como fuente de datos, esta cuota no se aplica, y Amazon Data Firehose escala hacia arriba y hacia abajo sin límite.» Y como Firehose lee «una vez cada segundo por cada shard de Kinesis», los dos servicios comparten tu dimensionado de shards: más shards significa más lecturas de Firehose en paralelo, no solo más capacidad de escritura.

---

7. Aterrizaje en el lago con Firehose

7.1 Lo que Firehose promete realmente

Las semánticas de entrega difieren por destino, y esta es la zona más mal citada de toda la lección:

La consecuencia de diseño: cualquier cosa que aterrice como ficheros planos en un prefijo bronze es at-least-once. Los duplicados no son un bug que puedas configurar fuera: son el contrato. Haces que la tabla sea correcta aguas abajo (sección 9.3), no que la entrega sea perfecta.

7.2 Ejemplo resuelto E6: una factura de Firehose para un aterrizaje de JSON a Parquet en el lago

Escenario: 100 registros/s x 3 KB, JSON convertido a Parquet, entregado a S3, US East (N. Virginia), 30 días.

El punto didáctico es la forma de la factura, no los céntimos: la ingesta es la palanca más pequeña cuando activas funciones. La conversión y el dynamic partitioning juntos más que duplican los $35.84 base, y cada uno de ellos es una función que elegiste a cambio de Parquet consultable en prefijos particionados en lugar de un montón de JSON. Fíjate también en las tarifas dependientes del origen: un origen de Kinesis Data Streams factura $0.029/GB, un origen de Amazon MSK factura $0.055/GB sin el redondeo a 5 KB, los logs cedidos $0.13/GB, un destino Iceberg (origen Kinesis) $0.045/GB, y la entrega por VPC $0.01/GB más $0.01 por AZ-hora.

7.3 Data delivery de Kinesis y tablas de streaming (sin necesitar Firehose)

En octubre de 2026 un stream de Kinesis puede aterrizar en el lago sin Firehose en absoluto. El data delivery soporta «dos tipos de destino: tablas de streaming sobre Apache Iceberg y buckets de Amazon S3 de propósito general», con «compactación inteligente integrada [que] elimina la proliferación de ficheros pequeños.» Requisitos y precios:

Los resultados declarados por AWS para las tablas de streaming: «reducir los costes de entrega de datos hacia S3 Tables hasta un 50% frente a alternativas autogestionadas y reducir los costes de consulta aguas abajo hasta un 30% a través de la compactación inteligente integrada», con datos «consultables en minutos de ser publicados en tu stream.» El modo provisioned no soporta el data delivery ni las tablas de streaming en absoluto: un hecho que elimina al modo provisioned de la consideración para este patrón.

---

8. Reglas de AWS IoT Core y Kinesis Data Video Streams

8.1 MQTT, regla, acción, lago

AWS IoT Core es la entrada para la telemetría de dispositivos. Una regla evalúa un mensaje MQTT con AWS IoT SQL e invoca una o más acciones. La lista de acciones documentada incluye kinesis (Kinesis Data Streams), firehose, s3, timestream, lambda, sqs, sns, dynamodb, kafka (Apache Kafka), stepFunctions, openSearch, republish, cloudWatch, location, influxDB e iotSiteWise.

La acción de Kinesis toma tres parámetros que debes acertar: el stream, el partitionKey, «generalmente compuesto por una expresión (por ejemplo, ${topic()} o ${timestamp()})», y el roleArn, «un rol IAM que AWS IoT puede asumir para realizar la operación kinesis:PutRecord.» Elegir ${topic()} significa que todos los mensajes de un mismo topic MQTT hashean a un shard: elegante para el orden, un generador de hot keys a volumen. Elegir una clave a nivel de dispositivo o de evento reparte la carga y pierde el orden por topic.

Un control de coste merece memorizarse: «también puedes usar la función Basic Ingest para enviar de forma segura los datos del dispositivo a los servicios de AWS listados anteriormente, sin incurrir en costes de mensajería. La función Basic Ingest optimiza el flujo de datos eliminando el broker de mensajes publicar/suscribir de la ruta de ingesta.» Si los datos nunca necesitan fan-out MQTT, no pagues por el salto del broker.

8.2 Kinesis Data Video Streams: el carril de medios, brevemente

Amazon Kinesis Video Streams transporta «medios desde dispositivos conectados hacia AWS para almacenamiento, analítica, machine learning (ML), reproducción y otro procesamiento», con reproducción gestionada HLS y DASH, WebRTC para streaming bidireccional de ultrabaja latencia, e integraciones con Rekognition Video y SageMaker. Es la respuesta correcta para cámaras, audio y binarios serializados en el tiempo: no para registros de eventos JSON.

Precios en US East (en octubre de 2026): $0.0085/GB ingerido, $0.0085/GB consumido (consumo HLS $0.0119/GB), almacenamiento $0.023/GB-mes en el tramo caliente; WebRTC añade $0.03 al mes por canal de señalización activo, $2.25 por millón de mensajes de señalización y $0.12 por mil minutos de streaming TURN. Un tramo de almacenamiento en caliente (función fechada el 26 de noviembre de 2025) ofrece ingesta a $0.0100 por 1,000 fragmentos persistidos y almacenamiento a $0.0125/GB-mes con una retención mínima de 30 días: el equivalente en vídeo del ajuste de retención del stream de Kinesis.

• 📚 ¿Sabías que…? La regla de IoT más barata suele ser la que borras. Las reglas con comodines pueden coincidir con la mayoría de los mensajes, y cada acción asume un rol IAM y factura el servicio de destino: así que una única regla amplia con fan-out a Kinesis y Firehose y S3 son tres facturas para un mensaje. Diseña el SQL de la regla con la misma estrechez con la que diseñarías un índice de base de datos, y recurre a Basic Ingest cuando el broker no aporta nada.

---

9. Amazon MSK: Kafka gestionado, y de un stream a una tabla

9.1 Provisioned frente a Serverless

La propia guía de AWS sobre tamaño de brokers: «los brokers M7g usan procesadores AWS Graviton … los brokers M7g ofrecen mejor relación precio-rendimiento que instancias M5 comparables» y «los brokers M7g y M5 se recomiendan para cargas de trabajo de producción.» La lógica del punto de equilibrio es el ejercicio: provisioned tiene un suelo fijo (las horas correspondientes a tres brokers, más un almacenamiento que pagas llegue o no el tráfico), mientras serverless mide particiones y bytes, así que un stream constante de alto volumen puede costar más en Serverless que en brokers provisionados, y el techo de ingreso de 200 MBps es una parada seca, no una advertencia.

Ejemplo resuelto E8: la forma del punto de equilibrio (ejemplos publicados por AWS, en octubre de 2026).

9.2 MSK Connect y sinks de stream a lago

MSK Connect «hace fácil para los desarrolladores streamear datos hacia y desde sus clústeres de Apache Kafka … usa las versiones 2.7.1 o 3.7.x de Kafka Connect», puede «desplegar conectores desarrollados por terceros como Debezium … o desplegar un conector existente sin cambios de código», y «los conectores se escalan automáticamente para ajustarse a los cambios en la carga, y solo pagas por los recursos que usas», con reinicios automáticos de tareas y PrivateLink para conectividad privada.

Los caminos de sink que importan para este curso:

• Sink S3 (conector de Confluent en MSK Connect): "connector.class": "io.confluent.connect.s3.S3SinkConnector", con "flush.size": "1" controlando el tamaño del objeto y la capacidad provisionada expresada como mcuCount / workerCount.
• Sink Iceberg: la receta real de lago CDC publicada por AWS es MSK Connect + Iceberg Kafka Connect (AWS Big Data Blog, 2026-02-03), donde el iceberg.control.commit.interval-ms del conector fija cada cuánto los offsets del stream se convierten en instantáneas de tabla.
• Firehose con MSK como origen: ruta de consola: «como origen, elige Amazon MSK. Como destino, elige Apache Iceberg Tables.» Fíjate en el precio: la ingesta con origen MSK es $0.055/GB frente a $0.029/GB con un origen de Kinesis.
• Tablas de streaming de MSK, topics de Kafka materializados como Iceberg en S3 Tables: «los brokers Express de Amazon MSK escriben tus registros como ficheros de datos Apache Parquet y los hacen commit en la tabla», escalando hasta «10 GBps de throughput de entrega» a $10.00 por TB entregado, con frescura configurada entre 5 y 15 minutos, un bucket de cola de mensajes muertos obligatorio y la advertencia explícita de que «un Channel no hace backfill de datos producidos previamente, solo se entregan los datos producidos después de la habilitación.»

Para el trabajo de laboratorio, el MSK Data Generator de awslabs es un conector origen de Kafka Connect (genkp.<topic>.with para la clave de partición, genv.<field>.with para los valores) desplegable en MSK Connect o en un contenedor de ECS: el equivalente en streaming de un script de siembra.

9.3 Ejemplo resuelto E7: de bronze at-least-once a silver idempotente

Escenario: Firehose entregó una ventana de 10 minutos de ficheros de JSON a Parquet en s3://lake/bronze/events/dt=2026-10-11/hr=09/, y un reintento duplicó 1,412 de ellos. Promueve a una tabla silver de Iceberg.

Reglas que viajan con este patrón: el MERGE de Iceberg acepta solo un registro de origen por fila de destino: deduplica primero, siempre; y el control s.event_ts > t.event_ts convierte un evento re-entregado más antiguo en un no-op en lugar de un downgrade. La alternativa es saltarse por completo los ficheros planos y usar un destino exactly-once (Firehose hacia Iceberg, o tablas de streaming), donde la coordinación de escritura maneja los duplicados por ti.

El libro mayor de semántica, enunciado una vez y nunca difuminado:

• Ficheros planos en bronze = at-least-once. Planifica dedup (id de evento determinista más ventana de commit) o un MERGE sobre un id sustituto con un timestamp de origen monótonamente creciente.
• El exactly-once documentado existe, pero acotado: el destino Iceberg de Firehose («Firehose garantiza la entrega exactly-once hacia tablas Iceberg»), las tablas de streaming de Kinesis («semántica de entrega exactly-once en todos los shards») y el procesamiento exactly-once de Flink.
• El «exactly-once» de una diapositiva de un proveedor no es la misma afirmación que el «exactly-once de la documentación.» Pregunta cuál es el destino, cuál el catálogo y qué ocurre con un timeout de entrega.

---

10. Elegir: la matriz de decisión

---

Actualizaciones de 2026 (en octubre de 2026)

---

Casos Reales

Caso A, Cisco Webex: 12 clústeres MSK y la guardia que recuperas

Cisco (plataforma de observabilidad de Webex). El caso de AWS describe un estate de Kafka autogestionado para el stack de observabilidad/ELK cuya carga operativa recaía en un equipo que sobre-dimensionaba «instancias de un solo tamaño» mientras las caídas afectaban a miles de usuarios internos. La propia migración se acotó con honestidad: «el equipo de observabilidad pasó 5 meses ingenierizando la migración desde Kafka autogestionado hacia Amazon MSK y luego implementó el nuevo stack en 6 semanas.»

El estado estable publicado es la cifra que vuelve concreta la sección de MSK de esta lección: «el sistema entero está compuesto por 12 clústeres de Amazon MSK con un total de 66 brokers. El sistema maneja sin problemas una carga de trabajo diaria de 147 TB de datos y más de 100,000 millones de mensajes.» Efectos aguas abajo: «más de 4,000 desarrolladores, managers y miembros del equipo de Webex … se han beneficiado», y «se redujo el tiempo de transporte de datos desde el backend hasta el usuario, de modo que los tiempos de recuperación están por debajo de 10 segundos.» El resumen de AWS del resultado: «Cisco ha reducido su sobrecarga operativa a prácticamente cero con ahorro de costes y menos caídas del servicio.» Robert Labrie, manager de observabilidad en Webex: «Ejecutamos un stack de observabilidad federado globalmente a escala, y simplemente funciona.»

Ángulo de la lección: Kafka gestionado convierte un problema de personal en un problema de capacidad. El protocolo, los clientes y el ecosistema de Connect se quedaron; lo que desapareció fue el cuidado de los brokers, y la línea de los 5 meses de migración es el precio honesto de ese intercambio. 66 brokers en 12 clústeres es también la escala a la cual la aritmética de broker-horas de la sección 9.1 deja de ser una curiosidad de hoja de cálculo.

Cifras reportadas por el cliente en una página de caso de AWS (sin fecha, consultada 2026-10-11); no es un compromiso de AWS.

Caso B, VMware Carbon Black: 1 PB al día y la elasticidad de shards como palanca de coste

VMware Carbon Black (seguridad de endpoints). De la página de clientes de Kinesis Data Streams de AWS: «VMware Carbon Black analiza más de un billón de eventos cada día … Ahora procesan 1 PB de datos de streaming al día con menores costes operativos y de infraestructura.» La arquitectura ingiere desde «millones de dispositivos edge distribuidos» hacia Amazon Kinesis Data Streams, con analítica en tiempo real en milisegundos.

La cita que explica por qué Kinesis en lugar de una flota de brokers es de Stoyan Dimkov, Staff Engineer y Software Architect: «cuando los datos de clientes individuales aumentan o disminuyen, podemos usar la elasticidad de Amazon Kinesis Data Streams para escalar el cómputo hacia arriba o hacia abajo y procesar los datos de forma fiable mientras gestionamos eficazmente nuestro coste.»

Ángulo de la lección: a 1 PB/día el número interesante no es el número de shards: es que la elasticidad por carga de trabajo de cada cliente es el modelo de coste. Dimensionar ese stream es la aritmética de E1 a escala (1 PB/día es aproximadamente 11.6 MB/s de media antes de réplicas, que on-demand absorbe sin una hoja de cálculo de shards), y las oscilaciones de volumen por cliente son exactamente lo que hace dolorosa la planificación de shards provisioned.

Cifras reportadas por el cliente en una página de cliente del producto de AWS (sin fecha, consultada 2026-10-11); no es un compromiso de AWS.

Caso C, TrueCar: programa la eliminación, no el ajuste del motor

TrueCar (mercado de automóviles). En la misma página de clientes de Kinesis de AWS: «al adoptar una estrategia de datos de streaming con Amazon Kinesis Data Streams, TrueCar ha mejorado la velocidad hasta el insight del analítica de clickstream 48 veces, automatizado su proceso de extracción, transformación y carga (ETL) y mejorado la observabilidad de sus métricas.» 48x es una historia de latencia, no de throughput: el horario del ETL por lotes era el cuello de botella, y el stream lo eliminó.

Cifras reportadas por el cliente en una página de cliente del producto de AWS (sin fecha, consultada 2026-10-11); no es un compromiso de AWS.

---

Preguntas de Práctica (Practice Questions)