Perguntas frequentes sobre o Amazon Kinesis Data Streams

Um fragmento é uma sequência de registro de dados em um fluxo. Isso serve como uma base de unidade de taxa de transferência do fluxo de dados do Kinesis. Um fragmento suporta 1 MB/segundo e 1.000 registros por segundo para gravação, e 2 MB/segundo para leitura. Os limites do fragmento garantem uma performance previsível, facilitando o projeto e a operação de um fluxo de trabalho de dados altamente confiável. Um produtor coloca registros de dados em fragmentos e um consumidor obtém registros de dados de fragmentos. Os consumidores usam fragmentos para processamento paralelo de dados e para consumir dados na ordem exata em que são armazenados. Se os dados gravados e lidos excederem os limites de fragmentos, as aplicações do produtor e do consumidor receberão aceleradores, que podem ser tratados através de novas tentativas.

Um registro é a unidade de dados armazenada em um stream de dados do Amazon Kinesis. Um registro é composto por um número de sequência, uma chave de partição e um blob de dados. O blob de dados consiste nos dados de interesse que o seu produtor de dados adiciona a um stream de dados. O tamanho máximo de um blob de dados (a carga útil de dados antes da codificação Base64) é de 1 megabyte (MB).

Uma chave de partição é usada para isolar e rotear registros para diferentes fragmentos de um fluxo de dados. Uma chave de partição é especificada por seu produtor de dados ao adicionar dados a um fluxo de dados do Kinesis. Por exemplo, supondo que você tenha um fluxo de dados com dois fragmentos (fragmento 1 e fragmento 2). Você pode configurar seu produtor de dados para usar duas chaves de partição (chave A e chave B) para que todos os registros com chave A sejam colocados no fragmento 1 e todos os registros com chave B sejam colocados no fragmento 2.

Um número de sequência é um identificador exclusivo para cada registro. O número de sequência é atribuído pelo Amazon Kinesis quando um produtor de dados chama as operações PutRecord ou PutRecords para adicionar dados a um fluxo de dados do Amazon Kinesis. Os números de sequência para a mesma chave de partição geralmente aumentam com o tempo; quanto maior for o período de tempo entre as solicitações do PutRecord ou PutRecords, maiores serão os números de sequência.

O modo de capacidade do Kinesis Data Streams determina como a capacidade é gerenciada e como o uso é cobrado por um fluxo de dados. Você pode escolher entre os modos provisionado e sob demanda. No modo provisionado, você especifica o número de fragmentos para o fluxo de dados. A capacidade total de um fluxo de dados é a soma das capacidades de seus fragmentos. Você pode aumentar ou diminuir o número de fragmentos em um fluxo de dados conforme necessário, e você paga pelo número de fragmentos a uma taxa por hora. No modo sob demanda, a AWS gerencia os fragmentos para fornecer uma taxa de transferência necessária. Você paga apenas pela taxa de transferência real utilizada, e o Kinesis Data Streams acomoda automaticamente sua workload à medida que elas sobem ou descem. O Kinesis Data Streams grava e lê APIs, juntamente com recursos opcionais como retenção estendida e distribuição avançada, são suportados em ambos os modos de capacidade.

O modo sob demanda é mais adequado para workloads com padrões de tráfego imprevisíveis e altamente variáveis. Você deve usar este modo se preferir a AWS para gerenciar a capacidade em seu nome ou prefere pagar por taxa de transferência. O modo provisionado é mais adequado para tráfego previsível, onde os requisitos de capacidade são fáceis de prever. Você deve considerar o uso do modo provisionado se quiser ter um controle detalhado sobre como os dados são distribuídos pelos fragmentos. O modo provisionado também é adequado se você quiser fornecer fragmentos adicionais para que a aplicação consumidora possa ter mais taxa de transferência de leitura para acelerar o processamento geral.

Sim. É possível alternar entre o modo sob demanda e provisionado duas vezes por dia. A contagem de fragmentos de seu fluxo de dados permanece a mesma quando você muda do modo provisionado para o modo sob demanda e vice-versa. Com a mudança do modo de provisionado para o modo de capacidade sob demanda, seu fluxo de dados retém qualquer fragmento que tinha antes da transição. Mas a partir deste ponto, o Kinesis Data Streams monitora seu tráfego de dados e escala a contagem de fragmentos deste fluxo de dados sob demanda para cima ou para baixo, dependendo do aumento ou diminuição do tráfego.

É possível adicionar dados a um fluxo de dados do Kinesis por meio de operações PutRecord e PutRecords, da KPL ou do Amazon Kinesis Agent.

A operação PutRecord permite um único registro de dados em uma chamada de API e a operação PutRecords permite vários registros de dados em uma chamada de API. Para obter mais informações, consulte PutRecord e PutRecords.

A KPL é uma biblioteca fácil de usar e altamente configurável que ajuda você a colocar dados em um fluxo de dados do Amazon Kinesis. A KPL apresenta uma interface simples, assíncrona e confiável que ajuda você a atingir rapidamente um alto throughput do produtor com o mínimo de recursos do cliente.

O Amazon Kinesis Agent é uma aplicação Java pré-definida que oferece uma maneira fácil de coletar e enviar dados para o fluxo de dados do Amazon Kinesis. Você pode instalar o atendente em ambientes de servidor baseados em Linux, como servidores Web, servidores de log e servidores de banco de dados. O agente monitora determinados arquivos e envia continuamente dados para o stream de dados. Para obter mais informações, consulte Writing with Agents (Gravação com Agentes).

O blob, a chave de partição e o nome do fluxo de dados são parâmetros obrigatórios de uma chamada de PutRecord ou PutRecords. O tamanho do seu blob de dados (antes da codificação Base64) e da chave de partição serão considerados na taxa de transferência de dados do seu fluxo de dados do Amazon Kinesis, que é determinado pelo número de fragmentos no fluxo de dados.

Um consumidor corresponde a uma aplicação que processa todos os dados de um fluxo de dados do Kinesis. Você pode escolher entre tipos de consumidores com distribuição compartilhada e distribuição avançada para ler dados de um fluxo de dados Kinesis. Todos os consumidores que compartilham a distribuição partilham um fragmento de 2 MB/segundo de taxa de transferência de leitura e cinco limites de transações por segundo e exigem o uso da API GetRecords. Um consumidor com distribuição avançada recebe sua própria atribuição de 2 MB/segundo de taxa de transferência de leitura, permitindo que vários consumidores leiam os dados do mesmo fluxo em paralelo, sem contestar a taxa de transferência de leitura com outros consumidores. É necessário usar a API SubscribeToShard com os consumidores com distribuição avançada. Recomendamos o uso de consumidores fanout aprimorados se você desejar adicionar mais de um consumidor ao seu fluxo de dados.

É possível usar serviços gerenciados, como o AWS Lambda, Amazon Managed Service for Apache Flink e AWS Glue, para processar dados armazenados no Kinesis Data Streams. Esses serviços gerenciados cuidam do provisionamento e gerenciamento da infraestrutura subjacente para que você possa se concentrar em criar a lógica para seus negócios. Você também pode transmitir dados armazenados no Kinesis Data Streams para o Amazon S3, Amazon OpenSearch Service, Amazon Redshift, e endpoints HTTP personalizados usando sua integração pré-construída com o Kinesis Data Firehose. É possível também construir aplicações usando o Amazon Kinesis Client Library, uma biblioteca pré-construída, ou a API do Amazon Kinesis Data Streams.

A KCL para Java, Python, Ruby, Node.js e .NET é uma biblioteca criada previamente que ajuda você a desenvolver aplicações do Amazon Kinesis com facilidade para leitura e processamento de dados de um fluxo de dados do Amazon Kinesis.

A KCL lida com questões complexas, como adaptação a alterações no volume do fluxo de dados, balanceamento de carga de dados de streaming, coordenação de serviços distribuídos e processamento de dados com tolerância a falhas. A KCL permite que você se concentre na lógica de negócios durante a criação de aplicativos. Consulte a documentação do Kinesis Data Streams aqui para obter mais detalhes sobre o KCL.

A API SubscribeToShard é uma API de transmissão de alta performance que envia dados de fragmentos para os consumidores em uma conexão persistente sem um ciclo de requisição do cliente. A API SubscribeToShard usa o protocolo HTTP/2 para entregar dados a consumidores registrados sempre que novos dados chegam no fragmento, geralmente num período de 70 milissegundos, oferecendo uma entrega aproximadamente 65% mais rápida do que a da API GetRecords. Os consumidores se beneficiarão de uma entrega mais rápida mesmo quando vários consumidores registrados estiverem lendo do mesmo fragmento.

Distribuição avançada é um recurso opcional para os consumidores do Kinesis Data Streams que apresenta canais de taxa de transferência lógicos de 2 MB/segundo entre consumidores e fragmentos. Isso permite que os clientes escalem a quantidade de consumidores que fazem a leitura de um fluxo de dados paralelamente sem perder a alta performance.

Use a distribuição avançada se você tem, ou espera ter, vários consumidores recuperando dados de um fluxo paralelamente, ou se tem pelo menos um consumidor que exige o uso da API SubscribeToShard para fornecer velocidades de entrega de dados abaixo de 200 milissegundos entre produtores e consumidores.

Os consumidores utilizam a distribuição avançada por meio da obtenção de dados com a API SubscribeToShard. O nome do consumidor registrado é utilizado dentro da API SubscribeToShard, o que leva à utilização do benefício de distribuição avançada proporcionado ao consumidor registrado.

Sim. É possível ter vários consumidores usando a distribuição avançada e outros não usando esse recurso ao mesmo tempo. O uso da distribuição avançada não afeta os limites dos fragmentos para o uso tradicional de GetRecords.

Sim. Para usar a SubscribeToShard, você precisa inscrever seus consumidores para que o registro ative a distribuição avançada. Por padrão, o consumidor utilizará a distribuição avançada automaticamente quando os dados forem recuperados pela SubscribeToShard.

Um novo fluxo de dados criado no modo sob demanda tem uma cota de 4 MB/segundo e 4.000 registros por segundo para gravações. Por padrão, estes fluxos aumentam a escala na vertical automaticamente até 200 MB/segundo e 200.000 registros por segundo para gravações.

Um fluxo de dados no modo sob demanda acomoda até duas vezes seu pico de taxa de transferência de gravação observado nos últimos 30 dias. À medida que a taxa de transferência de seu fluxo de dados atinge um novo pico, o Kinesis Data Streams escala a capacidade de fluxo automaticamente. Por exemplo, se o fluxo de dados tem uma taxa de transferência que varia de 10 MB/segundo a 40 MB/segundo, o Kinesis Data Streams garantirá que você possa facilmente alcançar o dobro da taxa de transferência de pico de 80 MB/segundo. Posteriormente, se o mesmo fluxo de dados sustentar um novo pico de produção de 50 MB/segundo, o Data Streams garantirá que haja capacidade suficiente para ingerir 100 MB/segundo de taxa de transferência de gravação. Entretanto, você verá exceções "ProvisionedThroughputExceeded" se seu tráfego crescer mais que o dobro do pico anterior dentro de um período de 15 minutos. Você precisa tentar novamente estes pedidos rápidos.

A capacidade de leitura agregada do modo sob demanda aumenta proporcionalmente a taxa de transferência de gravação para garantir que as aplicações consumidoras tenham sempre a taxa de transferência de leitura adequada para processar os dados recebidos em tempo real. Você obtém pelo menos o dobro da taxa de transferência de dados de gravação para ler dados usando a API GetRecords. Recomendamos usar um consumidor com a API GetRecord para que ele tenha espaço suficiente para recuperar, quando a aplicação precisar se recuperar do tempo de inatividade. Para adicionar mais de uma aplicação consumidora, você precisa usar uma distribuição avançada, que suporte adicionar até 20 consumidores a um fluxo de dados usando a API SubscribeToShard, tendo cada um deles uma taxa de transferência dedicado.

A taxa de transferência de um fluxo de dados do Kinesis no modo provisionado é predefinida para escalar sem limites por meio do aumento do número de fragmentos em um fluxo de dados.

É possível aumentar a escala verticalmente de uma capacidade de fluxo de dados do Kinesis no modo provisionado ao dividir os fragmentos existentes usando a API SplitShard. Você pode reduzir a escala verticalmente de uma capacidade ao mesclar dois fragmentos usando a API MergeShard. De forma alternativa, é possível usar a API UpdateShardCount para aumentar (ou diminuir) a escala a capacidade de um fluxo na vertical para uma contagem específica de fragmentos.

A taxa de transferência de um fluxo de dados do Kinesis é determinado pelo número de fragmentos dentro do fluxo de dados. Siga as etapas abaixo para estimar o número inicial de fragmentos que o seu fluxo de dados precisa no modo provisionado. Observe que você pode ajustar de maneira dinâmica o número de fragmentos no seu fluxo de dados por meio da refragmentação.

Estime o tamanho médio do registro gravado no fluxo de dados em kilobytes (KB), arredondando para o 1 KB mais próximo (average_data_size_in_KB).

Estime o número de registros gravados no stream de dados por segundo. (number_of_records_per_second).

Decida o número de aplicações do Amazon Kinesis consumindo dados simultaneamente e independentemente do fluxo de dados (number_of_consumers).

Calcule a largura de banda da gravação de entrada em KB (incoming_write_bandwidth_in_KB), que é igual ao average_data_size_in_KB multiplicado pelo number_of_records_per_second.

Calcule a largura de banda de leitura de saída em KB (outgoing_read_bandwidth_in_KB), que é igual à incoming_write_bandwidth_in_KB multiplicada pelo number_of_consumers.

É possível calcular o número inicial de fragmentos (number_of_shards) necessário para seu fluxo de dados usando a seguinte fórmula: number_of_shards = max (incoming_write_bandwidth_in_KB/1000, outgoing_read_bandwidth_in_KB/2000)

A taxa de transferência de um fluxo de dados do Kinesis é predefinida para escalar sem limites. A cota de fragmento padrão é de 500 fragmentos por fluxo para as seguintes regiões da AWS: Leste dos EUA (Norte da Virgínia), Oeste dos EUA (Oregon) e Europa (Irlanda). Para todas as outras regiões, a cota de fragmento padrão é de 200 fragmentos por fluxo. Você pode solicitar o aumento da cota de fragmentos usando console do AWS Service Quotas.

No modo provisionado, os limites de capacidade de um fluxo de dados do Kinesis são definidos pelo número de fragmentos dentro do fluxo de dados. Os limites podem ser excedidos por taxa de transferência de dados ou número de registros PUT. Enquanto os limites de capacidade forem excedidos, os dados de put serão rejeitados com uma exceção ProvisionedThroughputExceeded. Se isso for devido a um aumento temporário na taxa de dados de entrada do fluxo de dados, uma nova tentativa do produtor de dados poderá levar ao atendimento das solicitações. Se isso for devido a um aumento constante na taxa de dados de entrada do fluxo de dados, você deve aumentar o número de fragmentos dentro do fluxo de dados para fornecer capacidade suficiente para que as chamadas de put de dados sejam sempre com êxito. Nos dois casos, as métricas do Amazon CloudWatch permitem que você saiba da mudança na taxa de dados de entrada do fluxo de dados e da ocorrência de exceções ProvisionedThroughputExceeded.

No modo provisionado, os limites de capacidade de um fluxo de dados do Kinesis são definidos pelo número de fragmentos dentro do fluxo de dados. Os limites podem ser excedidos pela taxa de transferência de dados ou pelo número de chamadas de leitura de dados. Enquanto os limites de capacidade forem excedidos, a chamada de leitura de dados será rejeitada com a exceção ProvisionedThroughputExceeded. Se isso ocorrer devido a um aumento temporário da taxa de dados de saída do fluxo de dados, uma nova tentativa da aplicação do Amazon Kinesis poderá levar à conclusão das solicitações. Se isso ocorrer devido a um aumento sustentado da taxa de dados de saída do fluxo de dados, você deve aumentar o número de fragmentos no seu fluxo de dados para disponibilizar capacidade suficiente para que as chamadas de leitura de dados sejam sempre com êxito. Em ambos os casos, as métricas do Amazon CloudWatch permitem que você aprenda sobre a alteração da taxa de dados de saída do fluxo de dados e a ocorrência de exceções ProvisionedThroughputExceeded.

O período de retenção padrão de 24 horas abrange cenários em que atrasos intermitentes no processamento requerem a recuperação dos dados em tempo real. Uma retenção de sete dias possibilita que você reprocesse dados por até sete dias para resolver possíveis perdas de dados subsequentes. A retenção de dados de longo prazo superior a sete dias e com, no máximo, 365 dias possibilita que você reprocesse dados antigos para casos de uso, como testes de algoritmos, preenchimento de armazenamento de dados e auditoria.

Sim. Você pode usar as mesmas APIs getShardIterator, GetRecords e SubscribeToShard para ler dados retidos por mais de 7 dias. Os consumidores podem mover o iterador para o local desejado no fluxo, recuperar o mapa de fragmentos (incluindo aberto e fechado) e ler os registros.

Sim. Há aprimoramentos de APIs ListShards, GetRecords e SubscribeToShard. É possível usar a nova opção de filtragem com o parâmetro TimeStamp disponível na API ListShards para recuperar com eficiência o mapa de fragmentos e melhorar a performance da leitura de dados antigos. O filtro TimeStamp permite que as aplicações descubram e enumerem fragmentos a partir do momento em que você deseja reprocessar os dados e elimina a necessidade de iniciar no trim horizon. GetRecords e SubscribeToShards têm um novo campo, ChildShards, que permitirá que você descubra rapidamente os fragmentos secundários quando uma aplicação terminar de ler dados de um fragmento fechado, em vez de ter que percorrer o mapa de fragmentos novamente. A descoberta rápida de fragmentos faz uso eficiente do consumo de recursos de computação da aplicação para o fluxo de qualquer tamanho, independentemente do período de retenção de dados.

Você deve considerar esses aprimoramentos de API se planeja reter dados por mais tempo e escalar a capacidade de fluxo regularmente. As operações de escalabilidade de fluxo fecham os fragmentos existentes e abrem novos fragmentos secundários. Os dados em todos os fragmentos abertos e fechados são retidos até o final do período de retenção. Portanto, o número total de fragmentos aumenta linearmente com um período de retenção mais longo e várias operações de escalabilidade. Esse aumento no mapa de fragmentos requer o uso de ListShards com filtro TimeStamp e campo ChildShards em GetRecords e a API SubscribeToShard para descoberta eficiente de fragmentos visando a recuperação de dados. Você precisará atualizar a KCL para a versão mais recente (1.x para consumidores padrão e 2.x para consumidores fanout aprimorados) para obter esses recursos.

Sim. Os clientes do Kinesis Data Streams podem usar o AWS Glue Schema Registry, um recurso com tecnologia sem servidor do AWS Glue, por meio da KPL e da KCL ou das APIs do AWS Glue Schema Registry no AWS Java SDK. O Schema Registry está disponível sem custos adicionais. 

Consulte a documentação do usuário do Schema Registry para saber mais e começar a usar.

Há duas maneiras de alterar a taxa de transferência do seu fluxo de dados. Você pode usar a API UpdateShardCount ou o Console de Gerenciamento da AWS para escalar o número de fragmentos em um fluxo de dados ou alterar a taxa de transferência de um fluxo de dados do Amazon Kinesis ajustando o número de fragmentos no fluxo de dados (refragmentação).

Solicitações comuns de escalabilidade devem levar alguns minutos para serem concluídas. Solicitações maiores de escalabilidade devem levar mais tempo do que as menores.

Sim. É possível continuar adicionando e lendo dados de seu fluxo de dados Kinesis enquanto usa UpdateShardCount ou faz a refragmentação para alterar a taxa de transferência do fluxo de dados ou quando o Kinesis Data Streams o faz automaticamente no modo sob demanda.

O console de gerenciamento do Amazon Kinesis Data Streams exibe as principais métricas operacionais e de performance, como o throughput de entrada e de saída de dados de seus fluxo de dados do Kinesis. O Kinesis Data Streams também se integra ao Amazon CloudWatch para que você possa coletar, visualizar e analisar as métricas do CloudWatch para os fluxos de dados e fragmentos desses fluxos de dados. Para obter mais informações sobre as métricas do Kinesis Data Streams, consulte Monitoring Amazon Kinesis Data Streams with Amazon CloudWatch (Monitoramento do Amazon Kinesis Data Streams com Amazon CloudWatch).

Observe que todas as métricas em nível de fluxos são gratuitas. Todas as métricas de nível de fragmento habilitadas são cobradas de acordo com os preços do Amazon CloudWatch.

O Kinesis Data Streams se integra ao AWS Identity and Access Management (IAM), um serviço que ajuda você a controlar com segurança o acesso aos serviços e recursos da AWS para seus usuários. Por exemplo, é possível criar uma política que permite que somente um usuário ou grupo específico adicione dados ao seu fluxo de dados. Você também pode anexar uma política baseada em recursos ao seu fluxo de dados ou consumidor registrado para controlar o acesso no nível do recurso. Para obter mais informações sobre o gerenciamento de acesso e o controle do fluxo de dados, consulte Controlling Access to Amazon Kinesis Data Streams Resources using IAM (Controle do acesso aos recursos do Amazon Kinesis Data Streams usando o IAM).

Você pode usar a política baseada em funções ou recursos do IAM para compartilhar o acesso com outra conta. Para compartilhar o acesso com uma função do AWS Lambda entre contas, anexe uma política baseada em recursos ao seu fluxo de dados ou consumidor para conceder acesso ao perfil de execução da função do Lambda. Veja mais em Como usar o AWS Lambda com o Amazon Kinesis.

O Kinesis Data Streams se integra ao Amazon CloudTrail, um serviço que registra as chamadas de APIs da AWS para sua conta e disponibiliza arquivos de log para você. Para obter mais informações sobre o log de chamada de API e uma lista das operações compatíveis com as APIs do Amazon Kinesis, consulte Logging Amazon Kinesis API calls Using Amazon CloudTrail (Registro em log de chamadas de API do Amazon Kinesis usando o Amazon CloudTrail).

O Amazon Kinesis Data Streams permite atribuir etiquetas a fluxos de dados do Kinesis a fim de facilitar o gerenciamento de recursos e custos. Uma etiqueta é um rótulo definido pelo usuário, especificado como um par chave-valor, que ajuda a organizar recursos da AWS. Por exemplo, é possível etiquetar seus fluxos de dados por centros de custos para categorizar e rastrear os custos do Kinesis Data Streams com base nos centros de custos. Para obter mais informações sobre marcações do Amazon Kinesis Data Streams, consulte Tagging Your Amazon Kinesis Data Streams (Marcação do Amazon Kinesis Data Streams).

Como padrão o Amazon Kinesis é seguro. Apenas os proprietários da conta e do fluxo de dados têm acesso aos recursos do Kinesis criados por eles. O Kinesis oferece suporte à autenticação do usuário para controlar o acesso aos dados. É possível usar as políticas do IAM para conceder permissões seletivamente a usuários e grupos de usuários. Você pode inserir e extrair dados com segurança do Kinesis por meio de endpoints SSL usando o protocolo HTTPS. Se precisar de segurança extra, você pode usar a criptografia do lado do servidor com as chaves do AWS Key Management Service (AWS KMS) para criptografar dados armazenados em seu fluxo de dados. O AWS KMS permite que você use chaves do KMS geradas pela AWS para criptografia ou, se preferir, há a possibilidade de trazer sua própria chave do KMS para o AWS KMS. Por fim, é possível usar suas próprias bibliotecas de criptografia para criptografar dados do lado do cliente antes de colocá-los no Kinesis.

Sim. Você pode acessar de modo privado as APIs do Kinesis Data Streams de uma Amazon VPC criando endpoints da VPC. Com os endpoints da VPC, o roteamento entre a VPC e o Kinesis Data Streams é processado pela rede da AWS sem a necessidade de um gateway da internet, um gateway NAT ou uma conexão VPN. A geração mais recente de endpoints da VPC usada pelo Kinesis Data Streams é desenvolvida pelo AWS PrivateLink, uma tecnologia que habilita conectividade privada entre serviços da AWS usando interfaces de rede elástica (ENI) com IPs privados em suas VPCs. Para saber mais sobre o PrivateLink, acesse a documentação do PrivateLink.

Sim, e há duas opções para fazer isso. Você pode usar a criptografia no lado do servidor, que é um recurso totalmente gerenciado que criptografa e descriptografa automaticamente dados inseridos e extraídos de um fluxo de dados. Ou gravar dados criptografados em um fluxo de dados ao realizar a criptografia e a descriptografia do cliente.

Geralmente, os clientes escolhem a criptografia no lado do servidor em vez de a criptografia do lado do cliente por uma das seguintes razões:

• É difícil aplicar a criptografia do lado do cliente
• Eles desejam uma segunda camada de segurança além da criptografia do lado do cliente.
• É difícil implementar os esquemas de gerenciamento de chaves do cliente.

A criptografia no lado do servidor do Kinesis Data Streams criptografa automaticamente dados usando uma chave do AWS KMS, especificada pelo usuário antes de eles serem gravados na camada de armazenamento do fluxo de dados, e descriptografa os dados depois que forem recuperados do armazenamento. A criptografia impossibilita gravações e torna o payload e a chave de partição ilegíveis, a menos que o usuário que está gravando ou lendo por meio do fluxo de dados tenha a permissão para usar a chave selecionada para a criptografia no fluxo de dados. Como resultado, a criptografia no lado do servidor torna fácil cumprir os requisitos internos de segurança e conformidade que regem os seus dados.

Com a criptografia no lado do servidor, os aplicativos do lado do cliente (produtores e consumidores) não precisam estar cientes da criptografia, não precisam gerenciar chaves KMS nem operações criptográficas. Além disso, os seus dados serão criptografados quando estiverem em repouso e em movimento no serviço Kinesis Data Streams. Todas as chaves KMS usadas pelo recurso de criptografia no lado do servidor são fornecidas pelo AWS KMS. O AWS KMS facilita o uso de uma chave do KMS para Kinesis gerenciada pela AWS (um método de criptografia "1-clique"), sua própria chave gerenciada pelo cliente do AWS KMS ou uma chave do KMS importada por você para fazer a criptografia.

Sim e você pode encontrá-lo no guia de documentação do usuário.

Possivelmente. Dependerá da chave usada para fazer a criptografia e das permissões que regem o acesso à chave.

• Se você usar a chave do KMS para Kinesis gerenciada pela AWS (alias de chave = aws/kinesis), suas aplicações não sofrerão impacto pela habilitação nem pela desabilitação da criptografia usando essa chave.
• Se você usar uma chave KMS diferente, como uma chave personalizada do AWS KMS ou uma que tenha sido importada para o serviço AWS KMS, e se os produtores e os consumidores de um stream de dados não tiverem permissão para utilizar a chave do KMS usada para criptografia, as suas solicitações PUT e GET consequentemente falharão. Antes de usar a criptografia no lado do servidor será necessário configurar as políticas de chave do AWS KMS para permitir a criptografia e a descriptografia das mensagens. Para obter exemplos e mais informações sobre as permissões do AWS KMS, consulte AWS KMS API Permissions: Actions and Resources Reference (Permissões de API do AWS KMS: Referência de Ações e Recursos) no Guia do desenvolvedor do AWS Key Management Service ou as instruções sobre permissões contidas na documentação do usuário da criptografia do lado do servidor do Kinesis Data Streams.

Sim. No entanto, se você estiver usando a chave do KMS para Kinesis gerenciada pela AWS e não tiver ultrapassado os custos de uso de APIs do KMS do nível gratuito da AWS, o uso da criptografia no lado do servidor não será cobrado. Veja a seguir a descrição dos custos por recurso:

Chaves:

A chave do KMS gerenciada pela AWS para o Kinesis (alias = “aws/kinesis”) é gratuita.
As chaves do KMS gerenciadas pelo cliente estão sujeitas aos custos de chave do KMS. Saiba mais.

Uso das APIs do KMS:

Os custos de uso de APIs se aplicam a cada chave do KMS, inclusive os personalizados. O Kinesis Data Streams chama o KMS aproximadamente a cada 5 minutos quando ocorre a mudança na chave de dados. Em um período de 30 dias, o custo total de chamadas de API ao KMS iniciadas por um fluxo de dados do Kinesis deve ser inferior a alguns dólares. Note que esse custo aumenta com o número de credenciais de usuários usados pelos produtores e consumidores de dados, pois cada credencial de usuário exige uma chamada de API única ao AWS KMS. Quando você usa uma função do IAM para autenticação, cada função de chamada assumida resultará em credenciais de usuário únicas. Pode ser necessário armazenar em cache as credenciais de usuário retornadas peala função de chamada assumida para reduzir os custos do KMS.

A criptografia do lado do servidor do Kinesis Data Streams está disponível na região da AWS GovCloud e em todas as regiões públicas, exceto na região China (Pequim).

Todas essas operações podem ser concluídas usando o Console de Gerenciamento da AWS ou o AWS SDK. Para saber mais, consulte o guia de conceitos básicos da criptografia do lado do servidor do Kinesis Data Streams.

O Kinesis Data Streams usa o algoritmo AES-GCM 256 para criptografia.

Não. Apenas os novos dados gravados no fluxo de dados serão criptografados (ou permanecerão descriptografados) pela nova aplicação da criptografia.

A criptografia no lado do servidor codifica o payload da mensagem junto com a chave de partição, o que é especificado pelos aplicativos do produtor do stream de dados.

A criptografia no lado do servidor é um recurso específico de stream.

Sim. Ao usar o Console de Gerenciamento da AWS ou o AWS SDK, é possível escolher uma nova chave do KMS para aplicar a um fluxo de dados específico.

Não. No momento, o Kinesis Data Streams não está disponível no nível gratuito da AWS. O nível gratuito da AWS é um programa que oferece testes gratuito para um grupo de Serviços da AWS. Para obter mais detalhes sobre o nível gratuito da AWS, consulte a seção AWS Free Tier (Nível gratuito da AWS).

O SLA do Kinesis Data Streams garante uma porcentagem de tempo de atividade mensal de, no mínimo, 99,9% para o Kinesis Data Streams.

Você se qualifica para um crédito do SLA para o Kinesis Data Streams, de acordo com o SLA do Kinesis Data Streams, se mais de uma zona de disponibilidade na qual você estiver executando uma tarefa, dentro da mesma região, tiver uma porcentagem de tempo de atividade mensal inferior a 99,9% durante qualquer ciclo de faturamento mensal.

Para obter detalhes completos sobre todos os termos e condições do SLA, bem como detalhes sobre como enviar uma reivindicação, consulte a seção Amazon Kinesis Data Streams SLA.

O Kinesis Data Streams usa uma precificação simplificada de preço conforme o uso. Não há custos antecipados ou taxas mínimas e você paga somente pelos recursos que usar. O Kinesis Data Streams tem dois modos de capacidade, sob demanda e provisionado, e ambos têm opções de faturamento específicas.

No modo de capacidade sob demanda, não é necessário especificar a taxa de transferência de leitura e gravação que você espera que a aplicação tenha. Neste modo, o preço se baseia no volume de dados ingeridos e recuperados, juntamente com uma cobrança por hora para cada fluxo de dados na conta. Há cobranças adicionais por recursos opcionais: retenção de dados estendida (mais que as 24 horas iniciais e dentro dos primeiros 7 dias), retenção de dados de longo período de vigência (mais que 7 dias e até 1 ano) e distribuição avançada. Para obter mais informações sobre os custos do Amazon Kinesis Data Streams, consulte a Amazon Kinesis Data Streams Pricing (Definição de preço do Amazon Kinesis Data Streams).

No modo de capacidade provisionada, você especifica o número de fragmentos necessário para sua aplicação com base na taxa de solicitações de gravação e leitura. Um fragmento é uma unidade de capacidade que fornece uma taxa de transferência de 1 MB/segundo para gravações e 2 MB/segundo para leituras. Para cada fragmento, é cobrada uma taxa por hora. Você também paga por registros gravados em seu fluxo de dados Kinesis. Você inclui custos adicionais quando utiliza recursos opcionais, como retenção estendida e distribuição avançada.

As duas dimensões principais e três dimensões opcionais no modo de provisionamento do Kinesis Data Streams são as seguintes:

• Custo por hora de fragmentos, que é determinado pelo número de fragmentos em seu fluxo de dados do Amazon Kinesis.
• Custo da unidade de carga PUT, que é determinado pelo número de unidades de carga útil de 25 KB que os produtores de dados adicionam ao seu fluxo de dados.

Opcional:

• A retenção de dados prolongada é um custo opcional determinado pelo número de horas de estilhaços geradas pelo seu stream de dados. Quando a retenção de dados prolongada estiver ativada, você pagará a taxa de retenção prolongada para cada estilhaço do stream.
• A retenção de dados de longo período de vigência é um custo opcional com duas dimensões de custo: armazenamento de dados de longo período de vigência e recuperação de dados de longo período de vigência. O armazenamento de dados de longo período de vigência reflete o número de GB/meses de dados armazenados por um período superior a 7 dias e até 365 dias. A recuperação de dados de longo período de vigência reflete o número de GBs de dados recuperados que foram armazenados por mais de 7 dias.
• A distribuição avançada é um custo opcional com duas dimensões de custo: horas de consumidor-fragmento e recuperações de dados. As horas de consumidor-estilhaço refletem a quantidade de estilhaços em um stream multiplicada pela quantidade de consumidores usando a distribuição aprimorada. As recuperações de dados são determinadas pela quantidade de GBs entregues aos consumidores usando a distribuição avançada.

Para obter mais informações sobre os custos do Amazon Kinesis Data Streams, consulte a Amazon Kinesis Data Streams Pricing (Definição de preço do Amazon Kinesis Data Streams).

A hora consumidor-fragmento é calculada pela multiplicação do número de consumidores de fluxo registrados pelo número de fragmentos no fluxo. Você pagará somente pela porção pro rata da hora em que o consumidor estava registrado para usar a distribuição avançada. Por exemplo, se uma hora consumidor-fragmento custar USD 0,015 para um fluxo de dados de 10 fragmentos, esse consumidor poderá ler 10 fragmentos usando a distribuição avançada e, portanto, incluirá a cobrança de 0,15 USD por hora (1 consumidor * 10 fragmentos * 0,015 USD por hora consumidor-fragmento). Se houver dois consumidores registrados para a distribuição avançada simultaneamente, a cobrança total da hora consumidor-fragmento será 0,30 USD por hora (2 consumidores * 10 fragmentos * 0,015 USD).

O Kinesis Data Streams e o Amazon MSK são plataformas populares de streaming de dados que ajudam você a desenvolver as próprias workloads de streaming que processam dados para necessidades especializadas. Ambos os serviços são escaláveis, seguros e altamente disponíveis. Os dois serviços podem ser implantados para executar casos de uso de streaming, como análises na Web e de log em tempo real, personalização de experiências do cliente, arquiteturas orientadas a eventos, análise de IoT e detecção de fraudes em tempo real. Ao escolher entre os dois, é importante considerar seu caso de uso e seus requisitos específicos. Confira alguns fatores a serem considerados:

Familiaridade

•  Se você for iniciante em tecnologias de streaming, use o Kinesis Data Streams.
• Se você tiver aplicações existentes em execução no Apache Kafka, use o MSK. O MSK possui um programa de migração existente para o Kafka (KMP) e um guia de migração para facilitar a experiência de migração.

Preferência por código aberto

• Se você preferir usar tecnologias de código aberto, recomendamos usar o MSK. Tanto o MSK quanto o MSK Connect são totalmente compatíveis com o Apache Kafka e o Kafka Connect de código aberto, respectivamente.

O Kinesis Data Streams possibilita o processamento de streaming de big data em tempo real. Ele fornece ordenação de registros, bem como a capacidade de ler e/ou reproduzir registros na mesma ordem para várias aplicações do Amazon Kinesis. A Amazon Kinesis Client Library (KCL) disponibiliza todos os registros de uma determinada chave de partição para o mesmo processador de registros, facilitando a criação de várias aplicações de leitura do mesmo fluxo de dados do Kinesis (por exemplo, para realizar contagem, agregação e filtragem). O Amazon Simple Queue Service (Amazon SQS) disponibiliza uma fila hospedada confiável e altamente escalável para armazenar mensagens enquanto elas trafegam entre computadores. O Amazon SQS permite mover dados facilmente entre componentes de aplicativo distribuídos e ajuda a criar aplicativos nos quais as mensagens são processadas de forma independente (com semântica de confirmação/falha no nível da mensagem), como fluxos de trabalho automatizados.

Recomendamos o Kinesis Data Streams para casos de uso com requisitos semelhantes aos seguintes:

• Roteamento de registros relacionados para o mesmo processador de registros (como na transmissão do MapReduce). Por exemplo, contagem e agregação são mais simples quando todos os registros para uma determinada chave são encaminhados para o mesmo processador de registro.
• Classificação de registros. Por exemplo, você quer transferir dados de registro do host do aplicativo para o host de processamento/arquivamento enquanto mantém a ordem das declarações de registro.
• Capacidade de vários aplicativos consumirem o mesmo stream simultaneamente.  Por exemplo, você tem uma aplicação que atualiza um painel em tempo real e outro que arquiva dados no Amazon Redshift. Você quer que os dois aplicativos consumam dados do mesmo stream de forma simultânea e independente.
• Capacidade de consumir registros na mesma ordem algumas horas depois. Por exemplo, você tem uma aplicação de faturamento e uma aplicação de auditoria que é executada algumas horas depois da aplicação de faturamento. O Kinesis Data Streams armazena dados por até 365 dias, você pode executar a aplicação de auditoria até 365 dias depois da aplicação de faturamento.

Recomendamos o Amazon SQS para casos de uso com requisitos semelhantes a:

• Semântica de sistema de mensagens (como confirmação/falha em nível de mensagem) e tempo de espera de visibilidade.  Por exemplo, você tem uma fila de itens de trabalho e quer monitorar a conclusão com êxito de cada item de forma independente. O Amazon SQS monitora a confirmação/falha, para que a aplicação não precise manter um ponto de verificação/cursor persistente. O Amazon SQS excluirá as mensagens de confirmação e enviará novamente mensagens de falha depois de um tempo de espera de visibilidade configurado.
• Atraso de mensagem individual.  Por exemplo, você tem uma fila de trabalhos e precisa programar trabalhos individuais com um atraso. Com o Amazon SQS, você pode configurar mensagens individuais para atrasarem até 15 minutos.
• Aumento dinâmico da simultaneidade/taxa de transferência em tempo de leitura.  Por exemplo, você tem uma fila de trabalho e quer adicionar mais leitores até que o backlog seja eliminado. Com o Amazon Kinesis Data Streams, é possível aumentar a escala na vertical até um número suficiente de fragmentos (observe, no entanto, que você precisará provisionar fragmentos suficientes com antecedência).
• Use a capacidade do Amazon SQS de escalar de forma transparente. Por exemplo, seu buffer solicita e a carga muda como resultado de picos de carga ocasionais ou do crescimento natural de suas atividades. Como cada solicitação armazenada em buffer pode ser processada independentemente, o Amazon SQS pode escalar de forma transparente para tratar a carga sem fornecer instruções de você.