AWS SAA-C03/07 - Desacoplamento e Integração2 min
Kinesis
Responda com suas palavras antes de ler o resto da nota.
- Que problema isso resolve?
- Quando usar / quando NÃO usar?
- Qual o principal trade-off (custo, latência, operação)?
- Que sinal no enunciado aponta pra isso?
- Com o que isso é confundido na prova?
Conceito
Família para streaming — dado contínuo, em ordem, potencialmente lido por vários consumidores.
| Serviço | O que faz |
|---|---|
| Data Streams | Stream bruto com shards, retenção e replay |
| Data Firehose | Entrega near real-time em destino, serverless, sem replay |
| Managed Service for Apache Flink | Processa e agrega o stream com SQL/Flink |
| Video Streams | Ingestão de vídeo |
Data Streams
- Capacidade por shard: 1 MB/s ou 1.000 registros/s de entrada, 2 MB/s de saída
- Retenção: 24 h (padrão) até 365 dias → permite replay
- Partition key distribui os registros entre shards e garante ordem dentro do shard
- Modos: Provisioned (você gerencia shards) e On-Demand (escala sozinha)
- Enhanced Fan-Out dá 2 MB/s dedicados por consumidor, em vez de compartilhar
Data Firehose
- Totalmente serverless, sem shard pra gerenciar
- Destinos: S3, Redshift, OpenSearch, Splunk e endpoints HTTP
- Buffer por tamanho ou por tempo (mínimo ~60 s) → é near real-time, não real time
- Transforma com Lambda e converte pra Parquet/ORC no caminho
- Não tem retenção nem replay: entrega e descarta
Kinesis vs SQS
| Kinesis Data Streams | SQS | |
|---|---|---|
| Modelo | Stream com log persistente | Fila |
| Consumidores | Vários lendo o mesmo dado | Um por mensagem |
| Replay | Sim | Não |
| Ordem | Por shard | Só FIFO |
| Depois de ler | Continua lá até expirar | Sumiu |
Trade-offs
Data Streams dá controle, replay e múltiplos consumidores — ao custo de gerenciar shards e calcular capacidade (ProvisionedThroughputExceeded quando a partition key concentra). Firehose elimina toda essa gestão e cobra a latência de buffer e a impossibilidade de reprocessar.
Regra: se alguém pode precisar ler o dado de novo ou se vários sistemas consomem o mesmo stream, é Data Streams. Se é só "jogar no S3/Redshift sem manter código", é Firehose.
Sinais de prova
- "Múltiplas aplicações processando o mesmo stream" → Data Streams
- "Reprocessar os dados de ontem" → Data Streams (Firehose não tem replay)
- "Entregar logs no S3 sem gerenciar infra" → Firehose
- "Converter para Parquet no caminho pro data lake" → Firehose + transformação
- "Agregação em janela de tempo sobre o stream" → Managed Service for Apache Flink
- "
ProvisionedThroughputExceeded" → mais shards ou partition key mal distribuída - "Real time de verdade (ms)" → Data Streams; near real time → Firehose
Relacionado
Parte de 07 - MOC Desacoplamento e Integração · Documentação AWS