Modelo mental
Si SQS es un buzón y SNS un altavoz, Kinesis es un cuaderno. Los registros se escriben en orden, se quedan escritos, y cualquiera puede volver atrás y releer desde donde quiera.
Esa es la diferencia de fondo con una cola, y de ella salen todas las demás:
| SQS | Kinesis | |
|---|---|---|
| Leer | consume | no consume |
| Varios consumidores | se reparten el trabajo | cada uno lee todo |
| Volver atrás | imposible | mover el iterador |
| Retención máxima | 14 días | 365 días |
| Orden | best-effort (estándar) | garantizado por shard |
| Escalar | añadir consumidores | añadir shards |
Un consumidor de Kinesis no borra nada: lleva su propia posición en el stream. Por eso pueden convivir varios sin coordinarse, y por eso reprocesar seis meses de eventos es mover un puntero y no un proyecto.
El shard es donde vive todo
La capacidad no se pide: se compra en shards. Cada uno admite 1 MB/s o 1 000 registros por segundo de escritura y 2 MB/s de lectura, y esos 2 MB se reparten entre todos los consumidores estándar de ese shard. Tres consumidores compitiendo por el mismo shard no tienen 2 MB/s cada uno: tienen 2 MB/s entre los tres.
De ahí sale enhanced fan-out: un consumidor registrado obtiene sus propios 2 MB/s y recibe los datos empujados en vez de sondearlos. Cuestan aparte y hay un tope de 20 por stream, pero es la respuesta cuando varios consumidores se estorban.
Y el shard es también donde vive el orden. Los registros con la misma partition key caen en el mismo shard y se leen en el orden en que se escribieron. Entre shards distintos no hay ninguna garantía. Elegir la partition key es, literalmente, elegir qué cosas están ordenadas entre sí — y trae consigo el mismo problema de particiones calientes que en DynamoDB.
Cómo te factura
Dos modelos, y elegir mal es caro en las dos direcciones:
| Modo | Cómo se paga |
|---|---|
| Aprovisionado | por shard-hora, se use o no, más peticiones |
| On-demand | por GB ingerido y recuperado, más una tarifa por stream-hora |
| Retención extendida | aparte, y sube con los días |
| Enhanced fan-out | por consumidor-shard-hora y por GB recuperado |
La forma de la factura es lo que hay que entender: el modo aprovisionado cobra por capacidad reservada, no por uso. Un stream con diez shards a las tres de la madrugada cuesta lo mismo que a mediodía. Es barato si el tráfico es constante y caro si es irregular.
On-demand escala solo, pero parte de 4 MB/s de escritura y sube según el tráfico. Si tu carga llega de golpe desde cero, los primeros minutos pueden estrangularse mientras escala.
Dos costes que aparecen tarde: la retención extendida se paga por cada día por encima de las 24 horas —guardar un año no es gratis— y el enhanced fan-out se factura por consumidor y por shard, así que multiplica.
Cuándo NO usarlo
- Es una cola de tareas. Si lo que quieres es repartir trabajo entre obreros, SQS es más simple, más barato y no te obliga a gestionar shards ni posiciones.
- Fan-out sencillo a unos pocos destinos. SNS entrega a servicios gestionados sin coste de entrega y sin que gestiones nada.
- El tráfico es irregular y bajo. Un shard aprovisionado cuesta lo mismo vacío que lleno. Con picos aislados, on-demand o directamente una cola.
- No necesitas orden ni releer. Son las dos cosas por las que se paga la complejidad de Kinesis. Sin ellas, estás pagando de más.
- Quieres enrutado por contenido. Kinesis entrega todo a todos los consumidores del shard; filtrar es trabajo del consumidor. Eso es EventBridge.
Errores comunes
Tratarlo como una cola. Es el error conceptual: en Kinesis leer no borra, no hay visibility timeout, no hay DLQ nativa y no hay “mensaje procesado”. El progreso lo lleva el consumidor y hay que guardarlo en algún sitio.
Una partition key con poca cardinalidad. pais o tipo concentran todo en
unos pocos shards. Es el mismo problema que la partición caliente de DynamoDB, y
la solución también es la misma: repartir la clave.
Suponer 2 MB/s por consumidor. Ese es el techo del shard, repartido entre todos los consumidores estándar. El tercer consumidor no ralentiza un poco a los otros dos: se lleva un tercio.
Ignorar el IteratorAge. Es la métrica que dice cuánto se ha quedado atrás
tu consumidor. Si crece, estás perdiendo terreno, y cuando supere la retención
empezarás a perder registros sin ningún error.
Dejar caducar el shard iterator. Caduca a los 5 minutos. Un consumidor
que tarda más entre llamadas se encuentra un ExpiredIteratorException que no
explica gran cosa.
Cambiar de modo a la ligera. Solo se puede alternar entre on-demand y aprovisionado dos veces cada 24 horas. No es una palanca para ir probando.
Fuentes
Throughput por shard, tamaño de registro, retención mínima y máxima, límites de
GetRecords y PutRecords, transacciones de lectura por shard, consumidores
registrados, cuotas de shards y de throughput on-demand por región, cambios de
modo y caducidad del shard iterator:
Quotas and limits — Amazon Kinesis Data Streams.
Retención de DynamoDB Streams usada en la comparación:
Core components of Amazon DynamoDB.
Retención de SQS:
Amazon SQS message quotas.
Los modelos de precio proceden de la página de precios de AWS, que se renderiza
dinámicamente y no pudo citarse literalmente.