As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.
# Principais recursos e conceitos do Amazon MSK
Os clusters do Amazon MSK Provisioned oferecem uma ampla variedade de recursos e capacidades para ajudar a otimizar o desempenho do seu cluster e atender às suas necessidades de streaming. Os tópicos abaixo descrevem essas funcionalidades em detalhes.
+ A [Console de gerenciamento da AWS](https://console.aws.amazon.com/msk)
+ A [Referência de API do Amazon MSK](https://docs.aws.amazon.com/msk/1.0/apireference)
+ A [Referência de comandos da CLI do Amazon MSK](https://docs.aws.amazon.com/cli/latest/reference/kafka/index.html)
**Topics**
+ [Tipos de agentes do Amazon MSK](broker-instance-types.md)
+ [Tamanhos dos agentes do Amazon MSK](broker-instance-sizes.md)
+ [Gerenciamento de armazenamento para agentes Standard](msk-storage-management.md)
+ [Configurações do Amazon MSK Provisioned](msk-configuration.md)
+ [Rebalanceamento inteligente para clusters](intelligent-rebalancing.md)
+ [Aplicação de patches em clusters do MSK Provisioned](patching-impact.md)
+ [Agente offline e failover do cliente](troubleshooting-offlinebroker-clientfailover.md)
+ [Segurança no Amazon MSK](security.md)
+ [Registro em log do Amazon MSK](msk-logging.md)
+ [Gerenciamento de metadados](metadata-management.md)
+ [Operações do tópico](msk-topic-operations-information.md)
+ [Recursos do Amazon MSK](resources.md)
+ [Versões do Apache Kafka](kafka-versions.md)
+ [Solução de problemas para o cluster do Amazon MSK](troubleshooting.md)
# Tipos de agentes do Amazon MSK
O MSK Provisioned oferece dois tipos principais de agentes: Standard e Express. Os corretores padrão oferecem a maior flexibilidade para configurar seus clusters, enquanto os corretores Express oferecem mais elasticidade, rendimento, resiliência e ease-of-use para executar aplicativos de streaming de alto desempenho.
Consulte os seguintes tópicos e saiba mais sobre cada oferta. A tabela a seguir também destaca a comparação dos principais recursos entre os agentes Standard e Express.
| Recurso | Agente Standard | Agente Express |
| --- | --- | --- |
| [Gerenciamento de armazenamento](msk-storage-management.md) | Gerenciado pelo cliente (os recursos incluem armazenamento EBS, armazenamento em camadas, throughput de armazenamento provisionado, ajuste de escala automático, alertas de capacidade de armazenamento) | Totalmente gerenciado pelo MSK |
| [Instâncias suportadas](broker-instance-sizes.md) | T3, 5M, M7g | M7g |
| [Considerações sobre dimensionamento e escalabilidade](bestpractices-intro.md) | Throughput, conexões, partições, armazenamento | Throughput, conexões, partições |
| [Escalabilidade do agente](msk-update-broker-count.md) | Escalabilidade horizontal e vertical | Escalabilidade horizontal e vertical |
| [Versões do Kafka](kafka-versions.md) | Consulte [Versões do Apache Kafka](kafka-versions.md) | Começa na versão 3.6 |
| [Configuração do Apache Kafka](msk-configuration.md) | Mais configurável | Principalmente o MSK gerenciado com maior resiliência |
| [Segurança](security.md) | Criptografia, Private/Public acesso, autenticação e autorização - IAM, SASL/SCRAM, mTLS, texto simples, Kafka ACLs | Criptografia, Private/Public acesso, autenticação e autorização - IAM, SASL/SCRAM, mTLS, texto simples, Kafka ACLs |
| [Monitoramento](monitoring.md) | CloudWatch, Monitoramento aberto | CloudWatch, Monitoramento aberto |
**nota**
Não é possível alterar um cluster do MSK Provisioned do tipo de agente Standard para o tipo de agente Express trocando o tipo de agente por meio da API do MSK. Você precisará criar um novo cluster com o tipo de agente desejado (Standard ou Express).
**Topics**
+ [Agentes do Amazon MSK Standard](msk-broker-types-standard.md)
+ [Agentes Express do Amazon MSK](msk-broker-types-express.md)
# Agentes do Amazon MSK Standard
Os agentes Standard do MSK Provisioned oferecem a maior flexibilidade para configurar o desempenho do seu cluster. Você pode escolher entre uma ampla variedade de configurações de cluster para obter as características de disponibilidade, durabilidade, throughput e latência necessárias para suas aplicações. Você também pode provisionar a capacidade de armazenamento e aumentá-la conforme necessário. O Amazon MSK cuida da manutenção do hardware dos agentes Standard e dos recursos de armazenamento conectados, reparando automaticamente os problemas de hardware que possam surgir. Você pode consultar mais detalhes neste documento sobre vários tópicos relacionados aos agentes padrão, como [gerenciamento](msk-storage-management.md), [configurações](msk-configuration-standard.md) e [manutenção de armazenamento](patching-impact.md#patching-standard-brokers).
# Agentes Express do Amazon MSK
Os agentes Express do MSK Provisioned tornam o Apache Kafka mais simples de gerenciar, mais econômico para executar em grande escala e mais elástico graças à baixa latência que você espera. Os corretores incluem pay-as-you-go armazenamento que se expande automaticamente e não requer dimensionamento, provisionamento ou monitoramento proativo. Dependendo do tamanho da instância selecionada, cada nó do agente pode fornecer até 3 vezes mais throughput por agente, escalar até 20 vezes mais rápido e se recuperar 90% mais rápido em comparação com os agentes Standard do Apache Kafka. Os agentes Express são pré-configurados com os padrões de melhores práticas do Amazon MSK e impõem cotas de throughput do cliente para minimizar a contenção de recursos entre os clientes e as operações em segundo plano do Kafka.
Aqui estão alguns dos principais fatores e recursos a serem considerados ao usar agentes Express.
+ **Sem gerenciamento de armazenamento**: os agentes Express eliminam a necessidade de [provisionar ou gerenciar recursos de armazenamento](msk-storage-management.md). Você obtém armazenamento elástico pay-as-you-go, virtualmente ilimitado e totalmente gerenciado. Para casos de uso de throughput alto, não é preciso considerar as interações entre instâncias de computação, volumes de armazenamento nem sobre os gargalos de throughput associados. Esses recursos simplificam o gerenciamento de clusters e eliminam a sobrecarga operacional do gerenciamento de armazenamento.
+ **Escalonamento mais rápido**: os agentes Express permitem escalar clusters e mova partições até 20 vezes mais rápido do que os agentes Standard. Esse recurso é crucial quando você precisa aumentar a escala horizontalmente do cluster para processar picos de carga futuros ou reduzir a escala do cluster para diminuir os custos. Consulte as seções sobre como [expandir seu cluster](msk-update-broker-count.md), [remover agentes](msk-remove-broker.md), [reatribuir partições](msk-update-broker-type.md) e [configurar LinkedIn o Cruise Control para rebalanceamento para](cruise-control.md) obter mais detalhes sobre como escalar seu cluster.
+ **Maior throughput**: os agentes Express oferecem até 3 vezes mais throughput por agente do que os agentes Standard. Por exemplo, você pode gravar com segurança dados de até 500 MBps com cada agente Express de tamanho m7g.16xlarge, em comparação com 153,8 MBps no agente padrão equivalente (ambos os números pressupõem alocação de largura de banda suficiente para operações em segundo plano, como replicação e rebalanceamento).
+ **Configurado para alta resiliência**: os agentes Express oferecem automaticamente várias melhores práticas para melhorar a resiliência do seu cluster. Isso inclui barreiras em configurações críticas do Apache Kafka, cotas de throughput e reservas de capacidade para operações em segundo plano e manutenção não planejada. Esses recursos tornam mais seguro e fácil executar aplicações do Apache Kafka em grande escala. Confira mais detalhes nas seções [Configurações do agente Express](msk-configuration-express.md) e [Cota de agentes Express do Amazon MSK](limits.md#msk-express-quota).
+ **Sem janelas de manutenção**: agentes Express não precisam de janelas de manutenção. O Amazon MSK atualiza contínua e automaticamente o hardware do seu cluster. Consulte [Aplicação de patches para agentes Express](https://docs.aws.amazon.com/msk/latest/developerguide/patching-impact.html#patching-express-brokers) para saber mais.
## Informações adicionais sobre agentes Express
+ Os corretores Express trabalham com o Apache Kafka APIs, mas ainda não oferecem suporte total à API. KStreams
+ Os corretores expressos estão disponíveis apenas em uma AZs configuração 3.
+ Os agentes Express estão disponíveis somente em determinados tamanhos de instância. Consulte os [preços do Amazon MSK](https://aws.amazon.com/msk/pricing/) para ver a lista atualizada.
+ Os corretores Express são compatíveis com as seguintes versões do Apache Kafka: 3.6, 3.8 e 3.9.
+ Os corretores expressos podem ser criados com o KRaft modo a partir da versão 3.9 do Apache Kafka.
**Confira esses blogs**
Para saber mais informações sobre os agentes MSK Express e ver um exemplo real de agentes Express em uso, leia os seguintes blogs:
[Apresentando os agentes Express do Amazon MSK que oferecem alto throughput e escalabilidade mais rápida para clusters Kafka](https://aws.amazon.com/blogs/aws/introducing-express-brokers-for-amazon-msk-to-deliver-high-throughput-and-faster-scaling-for-your-kafka-clusters/)
[Agentes Express do Amazon MSK: escalabilidade Kafka turbinada com desempenho até 20 vezes mais rápido](https://aws.amazon.com/blogs/big-data/express-brokers-for-amazon-msk-turbo-charged-kafka-scaling-with-up-to-20-times-faster-performance/)
Este blog demonstra como os agentes Express:
Fornece throughput mais rápido, escalabilidade acelerada e melhor tempo de recuperação de falhas
Elimine as complexidades do gerenciamento do armazenamento
# Tamanhos dos agentes do Amazon MSK
Ao criar um cluster do Amazon MSK Provisioned, você especifica o tamanho que deseja que os agentes tenham. Dependendo do [tipo do agente](broker-instance-types.md), o Amazon MSK é compatível com os seguintes tamanhos de agentes.
**Tamanhos dos agentes Standard**
+ kafka.t3.small
+ kafka.m5.large, kafka.m5.xlarge, kafka.m5.2xlarge, kafka.m5.4xlarge, kafka.m5.8xlarge, kafka.m5.12xlarge, kafka.m5.16xlarge, kafka.m5.24xlarge
+ kafka.m7g.large, kafka.m7g.xlarge, kafka.m7g.2xlarge, kafka.m7g.4xlarge, kafka.m7g.8xlarge, kafka.m7g.12xlarge, kafka.m7g.16xlarge
**Tamanhos dos agentes Express**
+ express.m7g.large, express.m7g.xlarge, express.m7g.2xlarge, express.m7g.4xlarge, express.m7g.8xlarge, express.m7g.12xlarge, express.m7g.16xlarge
**nota**
Alguns tamanhos de corretores podem não estar disponíveis em determinadas AWS regiões. Consulte as tabelas de preços atualizadas das instâncias de agentes na [página de preços do Amazon MSK](https://aws.amazon.com/msk/pricing/) para acessar a lista mais recente de instâncias disponíveis por região.
## Outras observações sobre os tamanhos dos agentes
+ Os corretores M7g usam processadores AWS Graviton (processadores personalizados baseados em ARM criados pela Amazon Web Services). Os agentes M7g oferecem melhor performance de preço em relação a instâncias M5 comparáveis. Os agentes M7g consomem menos energia do que instâncias M5 comparáveis.
+ O Amazon MSK é compatível com agentes M7g em clusters do MSK Provisioned executando as versões 2.8.2, 3.3.2 e superiores do Kafka.
+ Os agentes M7g e M5 têm performance de throughput de linha de base superior aos agentes T3 e são recomendados para workloads de produção. Os agentes M7g e M5 também podem ter mais partições por agente do que os agentes T3. Use os agentes M7g e M5 se você estiver executando workloads de nível de produção maiores ou se exigir um número maior de partições. Para saber mais sobre os tamanhos de instância M7g e M5, consulte Instâncias de uso [ EC2 geral da Amazon](https://aws.amazon.com/ec2/instance-types/).
+ Os agentes T3 têm a capacidade de usar créditos de CPU para impulsionar temporariamente o desempenho. Use agentes T3 para desenvolvimento de baixo custo, se você estiver testando cargas de trabalho de streaming pequenas a médias ou se tiver cargas de trabalho de streaming com baixo throughput que apresentem picos temporários no throughput. Recomendamos que você faça um proof-of-concept teste para determinar se os corretores T3 são suficientes para produção ou carga de trabalho crítica. Para saber mais sobre os tamanhos de corretores T3, consulte Instâncias [ EC2 T3 da Amazon](https://aws.amazon.com/ec2/instance-types/t3/).
Para obter mais informações sobre como escolher tamanhos de agentes, consulte [Melhores práticas para agentes Standard e Express](bestpractices-intro.md).
# Gerenciamento de armazenamento para agentes Standard
O Amazon MSK fornece recursos para ajudar você no gerenciamento do armazenamento em clusters do MSK.
**nota**
Com os [agentes Express](msk-broker-types-express.md), não é necessário provisionar ou gerenciar nenhum recurso de armazenamento usado com seus dados. Isso simplifica o gerenciamento de clusters e elimina uma das causas comuns de problemas operacionais com clusters do Apache Kafka. Você também gasta menos, pois não precisa provisionar a capacidade de armazenamento ociosa e paga apenas pelo que usa.
**Tipo de agente Standard**
Com [agentes Standard](msk-broker-types-standard.md), você pode escolher entre diversas opções e recursos de armazenamento. O Amazon MSK fornece recursos para ajudar você no gerenciamento do armazenamento em clusters do MSK.
Para acessar informações sobre o gerenciamento de throughput, consulte [Provisionar o throughput do armazenamento para agentes Standard em um cluster do Amazon MSK](msk-provision-throughput.md).
**Topics**
+ [Armazenamento em camadas para agentes Standard](msk-tiered-storage.md)
+ [Aumentar a escala verticalmente do armazenamento do agente Standard do Amazon MSK](msk-update-storage.md)
+ [Gerenciar o throughput do armazenamento para agentes Standard em um cluster do Amazon MSK](msk-provision-throughput-management.md)
# Armazenamento em camadas para agentes Standard
O armazenamento em camadas é um nível de armazenamento de baixo custo para o Amazon MSK que se expande para armazenamento praticamente ilimitado, tornando econômica a criação de aplicações de streaming de dados.
Você pode criar um cluster Amazon MSK configurado com armazenamento em camadas que equilibra desempenho e custo. O Amazon MSK armazena dados de streaming no nível de armazenamento primário com desempenho otimizado até atingir os limites de retenção de tópico Apache Kafka. Em seguida, o Amazon MSK move automaticamente os dados para o novo nível de armazenamento de baixo custo.
Quando sua aplicação começa a ler dados do armazenamento em camadas, você pode esperar um aumento na latência de leitura nos primeiros bytes. Ao começar a ler os dados restantes sequencialmente do nível de baixo custo, você pode esperar latências semelhantes às do nível de armazenamento primário. Você não precisa provisionar nenhum armazenamento para o armazenamento em camadas de baixo custo nem gerenciar a infraestrutura. É possível armazenar qualquer quantidade de dados e pagar somente pelo que for usado. Esse recurso é compatível com o APIs apresentado no [KIP-405: Kafka](https://cwiki.apache.org/confluence/display/KAFKA/KIP-405%3A+Kafka+Tiered+Storage) Tiered Storage.
Para obter informações sobre dimensionamento, monitoramento e otimização do seu cluster com armazenamento em camadas do MSK, consulte [Melhores práticas para executar workloads de produção usando o armazenamento em camadas do Amazon MSK](https://aws.amazon.com/blogs/big-data/best-practices-for-running-production-workloads-using-amazon-msk-tiered-storage/).
Veja alguns dos recursos do armazenamento em camadas:
+ Você pode escalar para armazenamento praticamente ilimitado. Você não precisa adivinhar como escalar sua infraestrutura do Apache Kafka.
+ Você pode reter dados por mais tempo em seus tópicos do Apache Kafka ou aumentar seu armazenamento de tópicos, sem a necessidade de aumentar o número de agentes.
+ Ele fornece um buffer de segurança de maior duração para lidar com atrasos inesperados no processamento.
+ Você pode reprocessar dados antigos em sua ordem de produção exata com seu código de processamento de stream existente e o Kafka APIs.
+ As partições se reequilibram mais rapidamente porque os dados no armazenamento secundário não exigem replicação em discos de agentes.
+ Os dados entre os agentes e o armazenamento em camadas se movem dentro da VPC e não trafegam pela Internet.
+ Uma máquina cliente pode usar o mesmo processo para se conectar a novos clusters com armazenamento em camadas ativado, assim como para se conectar a um cluster sem o armazenamento em camadas ativado. Consulte [Criar uma máquina cliente](https://docs.aws.amazon.com/msk/latest/developerguide/create-client-machine.html).
## Requisitos de armazenamento em camadas de clusters do Amazon MSK
+ Você deve usar a versão 3.0.0 ou superior do cliente Apache Kafka para criar um novo tópico com o armazenamento em camadas ativado. Para fazer a transição de um tópico existente para o armazenamento em camadas, você pode reconfigurar uma máquina cliente que use uma versão do cliente Kafka anterior à 3.0.0 (a versão mínima suportada do Apache Kafka é 2.8.2.) para habilitar o armazenamento em camadas. Consulte [Etapa 4: criar um tópico no cluster do Amazon MSK](create-topic.md).
+ O cluster do Amazon MSK com armazenamento em camadas habilitado deve usar a versão 3.6.0 ou superior ou 2.8.2.tiered.
## Restrições e limitações do armazenamento em camadas para clusters do Amazon MSK
O armazenamento em camadas tem as seguintes restrições e limitações:
+ Certifique-se de que os clientes não estejam configurados como `read_committed` ao lerem de remote\$1tier no Amazon MSK, a menos que a aplicação esteja usando ativamente o recurso de transações.
+ O armazenamento hierárquico não está disponível nas regiões AWS GovCloud (EUA).
+ O armazenamento em camadas é aplicado apenas aos clusters do modo provisionado.
+ O armazenamento em camadas não é compatível com o tamanho de agente t3.small.
+ O período mínimo de retenção em armazenamento de baixo custo é de 3 dias. Não há período mínimo de retenção para o armazenamento primário.
+ O armazenamento em camadas não oferece suporte a vários diretórios de log em um agente (recursos relacionados ao JBOD).
+ O armazenamento em camadas não é compatível com tópicos compactados. Certifique-se de que todos os tópicos com armazenamento em camadas ativado tenham a configuração cleanup.policy somente como “EXCLUIR”.
+ O cluster de armazenamento em camadas não é compatível com a alteração da política log.cleanup.policy de um tópico após sua criação.
+ O armazenamento em camadas pode ser desabilitado para tópicos individuais, mas não para o cluster inteiro. Depois de desabilitado, o armazenamento em camadas não pode ser reabilitado para um tópico.
+ Se você usar a versão 2.8.2.tiered do Amazon MSK, poderá migrar apenas para outra versão do Apache Kafka compatível com armazenamento em camadas. Se você não quiser continuar a usar uma versão compatível com armazenamento em camadas, crie um cluster do MSK e migre os dados para ele.
+ A kafka-log-dirs ferramenta não pode relatar o tamanho dos dados de armazenamento em camadas. A ferramenta relata somente o tamanho dos segmentos de log no armazenamento primário.
Para obter informações sobre configurações e restrições padrão que você deve considerar ao configurar o armazenamento em camadas no nível de tópico, consulte [Diretrizes para a configuração de armazenamento em camadas no nível de tópico do Amazon MSK](msk-guidelines-tiered-storage-topic-level-config.md).
# Como os segmentos de logs são copiados para o armazenamento em camadas para um tópico do Amazon MSK
Quando você habilita o armazenamento em camadas para um tópico novo ou existente, o Apache Kafka copia segmentos de log fechados do armazenamento primário para o armazenamento em camadas.
+ O Apache Kafka copia somente segmentos de log fechados. Ele copia todas as mensagens do segmento de log para o armazenamento em camadas.
+ Os segmentos ativos não estão qualificados para o armazenamento em camadas. O tamanho do segmento de log (segment.bytes) ou o tempo de rolagem do segmento (segment.ms) controla a taxa de fechamento do segmento e a taxa com a qual o Apache Kafka os copia para o armazenamento em camadas.
As configurações de retenção para um tópico com o armazenamento em camadas habilitado são diferentes das configurações para um tópico sem o armazenamento em camadas habilitado. As regras a seguir controlam a retenção de mensagens em tópicos com o armazenamento em camadas habilitado:
+ Você define a retenção no Apache Kafka com duas configurações: log.retention.ms (tempo) e log.retention.bytes (tamanho). Essas configurações determinam a duração total e o tamanho dos dados que o Apache Kafka retém no cluster. Independentemente de você habilitar ou não o modo de armazenamento em camadas, defina essas configurações no nível do cluster. Você pode substituir as configurações no nível do tópico pelas configurações do tópico.
+ Ao habilitar o armazenamento em camadas, você também pode especificar por quanto tempo o nível primário de armazenamento de alto desempenho armazena os dados. Por exemplo, se um tópico tiver uma configuração de retenção geral (log.retention.ms) de 7 dias e retenção local (local.retention.ms) de 12 horas, o armazenamento primário do cluster vai reter os dados somente nas primeiras 12 horas. O nível de armazenamento de baixo custo retém os dados por 7 dias completos.
+ As configurações usuais de retenção se aplicam ao log completo. Isso inclui suas partes primárias e em camadas.
+ As configurações local.retention.ms ou local.retention.bytes controlam a retenção de mensagens no armazenamento primário. O Apache Kafka copia segmentos de log fechados para o armazenamento hierárquico assim que eles fecham (com base em segment.bytes ou segment.ms), independentemente das configurações locais de retenção. Depois que os segmentos são copiados para o armazenamento hierárquico, eles permanecem no armazenamento primário até que os limites local.retention.ms ou local.retention.bytes sejam atingidos. Nesse ponto, os dados são excluídos do armazenamento primário, mas permanecem disponíveis no armazenamento hierárquico. Isso permite que você mantenha dados recentes no armazenamento primário de alto desempenho para acesso rápido, enquanto os dados mais antigos são servidos pelo armazenamento hierárquico de baixo custo.
+ Quando o Apache Kafka copia uma mensagem em um segmento de log para o armazenamento em camadas, ele remove a mensagem do cluster com base nas configurações retention.ms ou retention.bytes.
## Exemplo de cenário de armazenamento em camadas do Amazon MSK
Esse cenário ilustra como um tópico existente que tem mensagens no armazenamento primário se comporta quando o armazenamento em camadas está habilitado. Você habilita o armazenamento em camadas neste tópico ao definir remote.storage.enable como `true`. Neste exemplo, retention.ms está definido como 5 dias e local.retention.ms está definido como 2 dias. Veja a seguir a sequência de eventos quando um segmento expira.
**Tempo T0: antes de você habilitar o armazenamento em camadas.**
Antes de você habilitar o armazenamento em camadas para este tópico, há dois segmentos de log. Um dos segmentos está ativo para uma partição 0 de tópico existente.
![\[Tempo T0: antes de você habilitar o armazenamento em camadas.\]](http://docs.aws.amazon.com/pt_br/msk/latest/developerguide/images/tiered-storage-segments-1.png)
**Tempo T1 (< 2 dias): armazenamento em camadas habilitado. Segmento 0 copiado para o armazenamento em camadas.**
Depois de habilitar o armazenamento em camadas para este tópico, o Apache Kafka copia o segmento de log fechado 0 para o armazenamento em camadas assim que ele é fechado. O segmento fecha com base nas configurações segment.bytes ou segment.ms, não com base nas configurações de retenção. O Apache Kafka também mantém uma cópia no armazenamento primário. O segmento 1 ativo ainda não está qualificado para cópia para armazenamento hierárquico porque ainda está ativo e não foi fechado. Neste cronograma, o Amazon MSK ainda não aplica nenhuma das configurações de retenção para nenhuma das mensagens no segmento 0 e no segmento 1. (local.retenção). bytes/ms, retention.ms/bytes)
![\[Tempo T1 (< 2 dias): armazenamento em camadas habilitado. Segmento 0 copiado para o armazenamento em camadas.\]](http://docs.aws.amazon.com/pt_br/msk/latest/developerguide/images/tiered-storage-segments-2.png)
**Tempo T2: retenção local em vigor.**
Após 2 dias, o limite de retenção local é atingido para o segmento 0. A configuração de local.retention.ms como 2 dias determina isso. O segmento 0 agora foi excluído do armazenamento primário, mas permanece disponível no armazenamento hierárquico. Observe que o segmento 0 já foi copiado para o armazenamento hierárquico no Horário T1 quando foi fechado, não no Tempo T2 quando a retenção local expirou. O segmento 1 ativo ainda não está qualificado para exclusão nem para cópia para armazenamento hierárquico porque ainda está ativo.
![\[Tempo T2: retenção local em vigor.\]](http://docs.aws.amazon.com/pt_br/msk/latest/developerguide/images/tiered-storage-segments-3.png)
**Tempo T3: retenção geral em vigor.**
Após 5 dias, as configurações de retenção entram em vigor e o Kafka limpa o segmento 0 de log e as mensagens associadas do armazenamento em camadas. O segmento 1 ainda não está qualificado para expiração nem para cópia para armazenamento em camadas porque está ativo. O segmento 1 ainda não está fechado, portanto não é elegível para a rolagem de segmentos.
![\[Tempo T3: retenção geral em vigor.\]](http://docs.aws.amazon.com/pt_br/msk/latest/developerguide/images/tiered-storage-segments-4.png)
# Crie um cluster Amazon MSK com armazenamento hierárquico com o Console de gerenciamento da AWS
Este processo descreve como criar um cluster com armazenamento em camadas do Amazon MSK usando o Console de gerenciamento da AWS.
1. Abra o console do Amazon MSK em [https://console.aws.amazon.com/msk/](https://console.aws.amazon.com/msk/).
1. Selecione **Criar cluster**.
1. Escolha **Criação personalizada** para armazenamento em camadas.
1. Especifique um nome para o cluster.
1. No **Tipo de cluster**, selecione **Provisionado**.
1. Escolha uma versão do Amazon Kafka com suporte para armazenamento em camadas a fim de que o Amazon MSK a use para criar o cluster.
1. Especifique um tamanho de agente diferente de **kafka.t3.small**.
1. Selecione o número de agentes que deseja que o Amazon MSK crie em cada zona de disponibilidade. O mínimo é de 1 agente por zona de disponibilidade e o máximo é de 30 agentes por cluster.
1. Especifique o número de zonas pelas quais os agentes estão distribuídos.
1. Especifique o número de agentes do Apache Kafka que estão implantados por zona.
1. Selecione **Opções de armazenamento**. Isso inclui **Armazenamento em camadas e armazenamento do EBS** para habilitar o modo de armazenamento em camadas.
1. Siga as etapas restantes no assistente de criação de cluster. Quando concluído, o **Armazenamento em camadas e o armazenamento do EBS** aparecerão como o modo de armazenamento de cluster na visualização **Revisar e criar**.
1. Selecione **Create cluster** (Criar cluster).
# Crie um cluster Amazon MSK com armazenamento hierárquico com o AWS CLI
Para habilitar o armazenamento em camadas em um cluster, crie o cluster com a versão correta do Apache Kafka e o atributo para armazenamento em camadas. Siga o exemplo de código abaixo. Além disso, conclua as etapas da próxima seção para [Crie um tópico do Kafka com o armazenamento em camadas ativado com o AWS CLI](#msk-create-topic-tiered-storage-cli).
Consulte [create-cluster](https://docs.aws.amazon.com//cli/latest/reference/kafka/create-cluster.html) para obter uma lista completa dos atributos compatíveis com a criação de clusters.
```
aws kafka create-cluster \
—cluster-name "MessagingCluster" \
—broker-node-group-info file://brokernodegroupinfo.json \
—number-of-broker-nodes 3 \
--kafka-version "3.6.0" \
--storage-mode "TIERED"
```
## Crie um tópico do Kafka com o armazenamento em camadas ativado com o AWS CLI
Para concluir o processo iniciado ao criar um cluster com o armazenamento em camadas habilitado, crie também um tópico com o armazenamento em camadas habilitado com os atributos no exemplo de código adiante. Os atributos específicos para armazenamento em camadas são os seguintes:
+ `local.retention.ms` (p. ex., 10 minutos) para configurações de retenção com base no tempo ou `local.retention.bytes` para limites de tamanho de segmentos de log.
+ `remote.storage.enable` definido como `true` para habilitar o armazenamento em camadas.
A configuração a seguir usa local.retention.ms, mas você pode substituir esse atributo por local.retention.bytes. Esse atributo controla a quantidade de tempo que pode decorrer ou o número de bytes que o Apache Kafka pode copiar antes que o Apache Kafka copie os dados do armazenamento primário para o armazenamento em camadas. Consulte [Configuração no nível de tópico](https://docs.aws.amazon.com//msk/latest/developerguide/msk-configuration-properties.html#msk-topic-confinguration) para obter mais detalhes sobre os atributos de configuração compatíveis.
**nota**
Você deve usar o cliente Apache Kafka versão 3.0.0 ou superior. Essas versões são compatíveis com uma configuração chamada `remote.storage.enable` somente nas versões do cliente do `kafka-topics.sh`. Para habilitar o armazenamento em camadas em um tópico existente usando uma versão anterior do Apache Kafka, consulte a seção [Habilitar o armazenamento em camadas em um tópico existente do Amazon MSK](msk-enable-disable-topic-tiered-storage-cli.md#msk-enable-topic-tiered-storage-cli).
```
bin/kafka-topics.sh --create --bootstrap-server $bs --replication-factor 2 --partitions 6 --topic MSKTutorialTopic --config remote.storage.enable=true --config local.retention.ms=100000 --config retention.ms=604800000 --config segment.bytes=134217728
```
# Habilitar e desabilitar o armazenamento em camadas em um tópico existente do Amazon MSK
Estas seções abordam como habilitar e desabilitar o armazenamento em camadas em um tópico que você já criou. Para criar um novo cluster e um tópico com o armazenamento em camadas habilitado, consulte [Criação de um cluster com armazenamento em camadas usando o Console de gerenciamento da AWS](https://docs.aws.amazon.com//msk/latest/developerguide/msk-create-cluster-tiered-storage-console).
## Habilitar o armazenamento em camadas em um tópico existente do Amazon MSK
Para habilitar armazenamento em camadas em um tópico existente, use a sintaxe de comando `alter` no seguinte exemplo. Quando você habilita o armazenamento em camadas em um tópico existente, você não está restrito a uma determinada versão do cliente Apache Kafka.
```
bin/kafka-configs.sh --bootstrap-server $bsrv --alter --entity-type topics --entity-name msk-ts-topic --add-config 'remote.storage.enable=true, local.retention.ms=604800000, retention.ms=15550000000'
```
## Desabilitar o armazenamento em camadas em um tópico existente do Amazon MSK
Para desabilitar o armazenamento em camadas em um tópico existente, use a sintaxe de comando `alter` na mesma ordem em que você habilita o armazenamento em camadas.
```
bin/kafka-configs.sh --bootstrap-server $bs --alter --entity-type topics --entity-name MSKTutorialTopic --add-config 'remote.log.msk.disable.policy=Delete, remote.storage.enable=false'
```
**nota**
Ao desabilitar o armazenamento em camadas, você exclui completamente os dados do tópico no armazenamento em camadas. O Apache Kafka retém os dados do armazenamento primário, mas ainda aplica as regras de retenção primária com base em `local.retention.ms`. Após desabilitar o armazenamento em camadas em um tópico, não será possível habilitá-lo novamente. Se quiser desabilitar o armazenamento em camadas em um tópico existente, você não estará restrito a uma determinada versão do cliente Apache Kafka.
# Habilite o armazenamento hierárquico em um cluster Amazon MSK existente usando a CLI AWS
**nota**
Você só pode habilitar o armazenamento em camadas se log.cleanup.policy do seu cluster estiver definido como `delete`, pois tópicos compactados não são compatíveis com o armazenamento em camadas. Posteriormente, você poderá configurar log.cleanup.policy de um tópico individual para `compact` se o armazenamento em camadas não estiver habilitado nesse tópico específico. Consulte [Configuração no nível de tópico](https://docs.aws.amazon.com//msk/latest/developerguide/msk-configuration-properties.html#msk-topic-confinguration) para obter mais detalhes sobre os atributos de configuração compatíveis.
1. **Atualizar a versão do Kafka**: as versões de cluster não são números inteiros simples. Para encontrar a versão atual do cluster, use a `DescribeCluster` operação ou o comando da `describe-cluster` AWS CLI. Uma versão de exemplo é `KTVPDKIKX0DER`.
```
aws kafka update-cluster-kafka-version --cluster-arn ClusterArn --current-version Current-Cluster-Version --target-kafka-version 3.6.0
```
1. Edite o modo de armazenamento do cluster. O exemplo de código a seguir mostra a edição do modo de armazenamento do cluster para `TIERED` usando a API [https://docs.aws.amazon.com/cli/latest/reference/kafka/update-storage.html](https://docs.aws.amazon.com/cli/latest/reference/kafka/update-storage.html).
```
aws kafka update-storage --current-version Current-Cluster-Version --cluster-arn Cluster-arn --storage-mode TIERED
```
# Atualizar o armazenamento em camadas em um cluster existente do Amazon MSK usando o console
Este processo descreve como atualizar um cluster com armazenamento em camadas do Amazon MSK usando o Console de gerenciamento da AWS.
Certifique-se de que a versão atual do Apache Kafka do seu cluster do MSK seja 2.8.2.tiered. Consulte [Atualização da versão do Apache Kafka](https://docs.aws.amazon.com/msk/latest/developerguide/version-upgrades.html) se precisar atualizar seu cluster do MSK para a versão 2.8.2.tiered.
**nota**
Você só pode habilitar o armazenamento em camadas se log.cleanup.policy do seu cluster estiver definido como `delete`, pois tópicos compactados não são compatíveis com o armazenamento em camadas. Posteriormente, você poderá configurar log.cleanup.policy de um tópico individual para `compact` se o armazenamento em camadas não estiver habilitado nesse tópico específico. Consulte [Configuração no nível de tópico](https://docs.aws.amazon.com//msk/latest/developerguide/msk-configuration-properties.html#msk-topic-confinguration) para obter mais detalhes sobre os atributos de configuração compatíveis.
1. Abra o console do Amazon MSK em [https://console.aws.amazon.com/msk/](https://console.aws.amazon.com/msk/).
1. Acesse a página de resumo do cluster e escolha **Propriedades**.
1. Acesse a seção **Armazenamento** e escolha **Editar modo de armazenamento do cluster**.
1. Escolha **Armazenamento em camadas e armazenamento do EBS** e **Salvar as alterações**.
# Aumentar a escala verticalmente do armazenamento do agente Standard do Amazon MSK
É possível aumentar a quantidade de armazenamento do EBS por agente. Você não pode reduzir o armazenamento.
Os volumes de armazenamento permanecem disponíveis durante essa operação de expansão.
**Importante**
Quando o armazenamento for escalado para um cluster do MSK, o armazenamento adicional será disponibilizado imediatamente. No entanto, o cluster requer um período de resfriamento após cada evento de escalabilidade de armazenamento. O Amazon MSK usa esse período de resfriamento para otimizar o cluster antes que ele possa ser escalado novamente. Dependendo do tamanho e da utilização do armazenamento do cluster e do tráfego, esse período pode variar de um mínimo de 6 horas a mais de 24 horas. Isso é aplicável tanto para eventos de escalonamento automático quanto para escalabilidade manual usando a [UpdateBrokerStorage](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-nodes-storage.html#UpdateBrokerStorage)operação. Para obter informações sobre como dimensionar corretamente seu armazenamento, consulte [Melhores práticas para agentes Standard](bestpractices.md).
Você pode usar o armazenamento em camadas para aumentar a escala verticalmente até quantidades ilimitadas de armazenamento para seu agente. Consulte [Armazenamento em camadas para agentes Standard](msk-tiered-storage.md).
**Topics**
+ [Escalabilidade automática para clusters do Amazon MSK](msk-autoexpand.md)
+ [Dimensionamento manual para agentes Standard](manually-expand-storage.md)
# Escalabilidade automática para clusters do Amazon MSK
Para expandir automaticamente o armazenamento do seu cluster em resposta ao aumento do uso, você pode configurar uma política de ajuste de escala automático de aplicações para o Amazon MSK. Em uma política de ajuste de escala automático, você define a utilização do disco de destino e a capacidade máxima de escalabilidade.
Antes de usar a escalabilidade automática para o Amazon MSK, você deve avaliar o seguinte:
+
**Importante**
Uma ação de escalabilidade de armazenamento só pode ocorrer uma vez a cada 6 horas.
Recomendamos que você comece com um volume de armazenamento do tamanho certo para suas demandas de armazenamento. Para obter orientação sobre o dimensionamento correto do seu cluster, consulte [Dimensione seu cluster adequadamente: número de agentes Standard por cluster](bestpractices.md#brokers-per-cluster).
+ O Amazon MSK não reduz o armazenamento em cluster em resposta à redução do uso. O Amazon MSK não é compatível com a redução do tamanho dos volumes de armazenamento. Se precisar reduzir o tamanho do armazenamento em cluster, você deverá migrar seu cluster existente para um cluster com armazenamento menor. Para obter informações sobre a migração de um cluster, consulte [Migrar para um cluster do MSK](migration.md).
+ O Amazon MSK não é compatível com a redução horizontal automática da escala nas regiões Ásia-Pacífico (Osaka), África (Cidade do Cabo) e Ásia-Pacífico (Malásia).
+ Quando você associa uma política de auto-scaling ao seu cluster, o Amazon EC2 Auto Scaling cria automaticamente um alarme da Amazon para rastreamento de alvos. CloudWatch Se você excluir um cluster com uma política de auto-scaling, CloudWatch esse alarme persistirá. Para excluir o CloudWatch alarme, você deve remover uma política de auto-scaling de um cluster antes de excluir o cluster. Para saber mais sobre o monitoramento de destino, consulte [Políticas de escalabilidade de monitoramento de destino para o Amazon EC2 Auto Scaling](https://docs.aws.amazon.com/autoscaling/ec2/userguide/as-scaling-target-tracking.html) no *Guia do usuário do Amazon EC2 Auto Scaling*.
**Topics**
+ [Detalhes da política de ajuste de escala automático para o Amazon MSK](msk-autoexpand-details.md)
+ [Configurar a escalabilidade automática para o cluster do Amazon MSK](msk-autoexpand-setup.md)
# Detalhes da política de ajuste de escala automático para o Amazon MSK
Sua política de ajuste de escala automático define a seguinte métrica predefinida para seu cluster:
+ **Meta de utilização de armazenamento**: o limite de utilização de armazenamento usado pelo Amazon MSK para acionar uma operação de ajuste de escala automático. Você pode definir a meta de utilização entre 10% e 80% da capacidade de armazenamento atual. Recomendamos que você defina a meta de utilização do armazenamento entre 50% e 60%.
+ **Capacidade máxima de armazenamento**: o limite máximo de escalabilidade que o Amazon MSK pode definir para o armazenamento do seu agente. Você pode definir a capacidade máxima de armazenamento em até 16 TiB por agente. Para obter mais informações, consulte [Cota do Amazon MSK](limits.md).
Quando o Amazon MSK detecta que sua métrica `Maximum Disk Utilization` é igual ou maior que a configuração `Storage Utilization Target`, ele aumenta sua capacidade de armazenamento em um valor igual ao maior de 2 números: 10 GiB ou 10% do armazenamento atual. Por exemplo, se você tiver 1.000 GiB, esse valor será de 100 GiB. O serviço verifica a utilização do armazenamento a cada minuto. Outras operações de escalabilidade continuam aumentando o armazenamento em uma quantidade igual ao maior de 2 números: 10 GiB ou 10% do armazenamento atual.
Para determinar se ocorreram operações de auto-escalonamento, use a operação. [ ListClusterOperations](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-operations.html#ListClusterOperations)
# Configurar a escalabilidade automática para o cluster do Amazon MSK
Você pode usar o console do Amazon MSK, a API do Amazon MSK ou implementar CloudFormation a escalabilidade automática para armazenamento. CloudFormation o suporte está disponível por meio de [Application Auto Scaling](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-applicationautoscaling-scalabletarget.html).
**nota**
Você não pode implementar o escalabilidade automática ao criar um cluster. Primeiro, você deve criar o cluster e, em seguida, criar e habilitar uma política de ajuste de escala automático para ele. No entanto, você pode criar a política enquanto o serviço Amazon MSK cria seu cluster.
**Topics**
+ [Configure a escalabilidade automática usando o Amazon MSK Console de gerenciamento da AWS](msk-autoexpand-setup-console.md)
+ [Configurar o ajuste de escala automático usando a CLI](msk-autoexpand-setup-cli.md)
+ [Configurar a escalabilidade automática para o Amazon MSK usando a API](msk-autoexpand-setup-api.md)
# Configure a escalabilidade automática usando o Amazon MSK Console de gerenciamento da AWS
Este processo descreve como usar o console do Amazon MSK para implementar a escalabilidade automática para armazenamento.
1. Faça login no Console de gerenciamento da AWS e abra o console Amazon MSK em [https://console.aws.amazon.com/msk/casa? region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/).
1. Na lista de clusters, escolha seu cluster. Isso levará você a uma página com os detalhes sobre o cluster.
1. Na seção **Ajuste de escala automático para armazenamento**, escolha **Configurar**.
1. Crie e dê um nome a uma política de ajuste de escala automático. Especifique a meta de utilização do armazenamento, a capacidade máxima de armazenamento e a métrica de destino.
1. Selecione `Save changes`.
Quando você salvas e habilitar a nova política, ela ficará ativa para o cluster. Em seguida, o Amazon MSK expande o armazenamento do cluster quando a meta de utilização do armazenamento é atingida.
# Configurar o ajuste de escala automático usando a CLI
Este processo descreve como usar a CLI do Amazon MSK para implementar a escalabilidade automática para armazenamento.
1. Use o [ RegisterScalableTarget](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/#available-commands)comando para registrar um destino de utilização de armazenamento.
1. Use o [ PutScalingPolicy](https://docs.aws.amazon.com/cli/latest/reference/application-autoscaling/#available-commands)comando para criar uma política de expansão automática.
# Configurar a escalabilidade automática para o Amazon MSK usando a API
Este processo descreve como usar a API do Amazon MSK para implementar a escalabilidade automática para armazenamento.
1. Use a [ RegisterScalableTarget](https://docs.aws.amazon.com/autoscaling/application/APIReference/API_RegisterScalableTarget.html)API para registrar uma meta de utilização de armazenamento.
1. Use a [ PutScalingPolicy](https://docs.aws.amazon.com/autoscaling/application/APIReference/API_PutScalingPolicy.html)API para criar uma política de expansão automática.
# Dimensionamento manual para agentes Standard
Para aumentar o armazenamento, aguarde que o cluster esteja no estado `ACTIVE`. O escalonamento de armazenamento tem um período de resfriamento de pelo menos 6 horas entre os eventos. Embora a operação disponibilize armazenamento adicional imediatamente, o serviço realiza otimizações em seu cluster que podem levar até 24 horas ou mais. A duração dessas otimizações é proporcional ao tamanho do seu armazenamento.
## Ampliando o armazenamento do corretor usando o Console de gerenciamento da AWS
1. Abra o console do Amazon MSK em [https://console.aws.amazon.com/msk/](https://console.aws.amazon.com/msk/).
1. Escolha o cluster do MSK para o qual deseja atualizar o armazenamento do agente.
1. Na seção **Armazenamento**, escolha **Editar**.
1. Especifique o volume de armazenamento desejado. Só é possível aumentar a quantidade de armazenamento, não é possível reduzi-la.
1. Escolha **Salvar alterações**.
## Ampliando o armazenamento do corretor usando o AWS CLI
Execute o comando a seguir, substituindo *ClusterArn* pelo nome do recurso da Amazon (ARN) que você obteve quando criou o cluster. Se você não tiver o ARN do cluster, poderá encontrá-lo listando todos os clusters. Para obter mais informações, consulte [Listar clusters do Amazon MSK](msk-list-clusters.md).
Substitua *Current-Cluster-Version* pela versão atual do cluster.
**Importante**
As versões de cluster não são inteiros simples. Para encontrar a versão atual do cluster, use a [DescribeCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster)operação ou o comando [AWS CLI describe-cluster](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/kafka/describe-cluster.html). Uma versão de exemplo é `KTVPDKIKX0DER`.
O *Target-Volume-in-GiB* parâmetro representa a quantidade de armazenamento que você deseja que cada corretor tenha. Só é possível atualizar o armazenamento de todos os agentes. Não é possível especificar agentes individuais dos quais atualizar o armazenamento. O valor especificado *Target-Volume-in-GiB* deve ser um número inteiro maior que 100 GiB. O armazenamento por agente após a operação de atualização não pode exceder 16384 GiB.
```
aws kafka update-broker-storage --cluster-arn ClusterArn --current-version Current-Cluster-Version --target-broker-ebs-volume-info '{"KafkaBrokerNodeId": "All", "VolumeSizeGB": Target-Volume-in-GiB}'
```
## Aumentar a escala verticalmente do armazenamento do agente usando a API
Para atualizar o armazenamento de um broker usando a API, consulte [UpdateBrokerStorage](https://docs.aws.amazon.com//msk/1.0/apireference/clusters-clusterarn-nodes-storage.html#UpdateBrokerStorage).
# Gerenciar o throughput do armazenamento para agentes Standard em um cluster do Amazon MSK
Para obter informações sobre como provisionar o throughput usando o console, a CLI e a API do Amazon MSK, consulte [Provisionar o throughput do armazenamento para agentes Standard em um cluster do Amazon MSK](msk-provision-throughput.md).
**Topics**
+ [Configurações de throughput máximo e gargalos de throughput de agentes do Amazon MSK](#throughput-bottlenecks)
+ [Avalie o throughput de armazenamento de um cluster do Amazon MSK](#throughput-metrics)
+ [Valores de atualização de configuração para armazenamento provisionado em um cluster do Amazon MSK](#provisioned-throughput-config)
+ [Provisionar o throughput do armazenamento para agentes Standard em um cluster do Amazon MSK](msk-provision-throughput.md)
## Configurações de throughput máximo e gargalos de throughput de agentes do Amazon MSK
Há várias causas de gargalos no throughput do agente: throughput de volume, throughput de rede do Amazon EC2 para o Amazon EBS e throughput de saída do Amazon EC2. Você pode ativar o throughput do armazenamento provisionado para ajustar o throughput do volume. No entanto, as limitações de throughput do agente podem ser causadas pelo throughput de rede do Amazon EC2 para o Amazon EBS e pelo throughput de saída do Amazon EC2.
O throughput de saída do Amazon EC2 é afetado pelo número de grupos de consumidores e consumidores por grupo de consumidores. Além disso, tanto o throughput de rede do Amazon EC2 para o Amazon EBS quanto o throughput de saída do Amazon EC2 são maiores para tamanhos maiores de agentes.
Para volumes com tamanhos de 10 GiB ou mais, você pode provisionar um throughput de armazenamento de 250 MiB por segundo ou mais. O valor de 250 MiB por segundo é o padrão. Para provisionar o throughput de armazenamento, você deve escolher o tamanho de agente kafka.m5.4xlarge ou maior (ou kafka.m7g.2xlarge ou maior), e você pode especificar o throughput máximo conforme apresentado na tabela a seguir.
****
| tamanho do agente | Throughput máximo de armazenamento (MiB/segundo) |
| --- | --- |
| kafka.m5.4xlarge | 593 |
| kafka.m5.8xlarge | 850 |
| kafka.m5.12xlarge | 1000 |
| kafka.m5.16xlarge | 1000 |
| kafka.m5.24xlarge | 1000 |
| kafka.m7g.2xlarge | 312,5 |
| kafka.m7g.4xlarge | 625 |
| kafka.m7g.8xlarge | 1000 |
| kafka.m7g.12xlarge | 1000 |
| kafka.m7g.16xlarge | 1000 |
## Avalie o throughput de armazenamento de um cluster do Amazon MSK
Você pode usar as métricas `VolumeReadBytes` e `VolumeWriteBytes` para medir o throughput médio de armazenamento de um cluster. A soma dessas duas métricas fornece o throughput médio de armazenamento em bytes. Para obter o throughput médio de armazenamento de um cluster, defina essas duas métricas como SUM e o período como 1 minuto e então aplique a fórmula a seguir.
```
Average storage throughput in MiB/s = (Sum(VolumeReadBytes) + Sum(VolumeWriteBytes)) / (60 * 1024 * 1024)
```
Para obter mais informações sobre as métricas `VolumeReadBytes` e `VolumeWriteBytes`, consulte [Monitoramento no nível `PER_BROKER`](metrics-details.md#broker-metrics).
## Valores de atualização de configuração para armazenamento provisionado em um cluster do Amazon MSK
Você pode atualizar sua configuração do Amazon MSK antes ou depois de ativar o throughput provisionado. No entanto, você não verá o throughput desejado até realizar estas duas ações: atualizar o parâmetro de configuração `num.replica.fetchers` e ativar o throughput provisionado.
Na configuração padrão do Amazon MSK, `num.replica.fetchers` tem um valor de 2. Para atualizar seu `num.replica.fetchers`, você pode usar os valores sugeridos na tabela a seguir. Estes valores são para fins de orientação. Recomendamos ajustar os valores com base no seu caso de uso.
****
| tamanho do agente | num.replica.fetchers |
| --- | --- |
| kafka.m5.4xlarge | 4 |
| kafka.m5.8xlarge | 8 |
| kafka.m5.12xlarge | 14 |
| kafka.m5.16xlarge | 16 |
| kafka.m5.24xlarge | 16 |
Sua configuração atualizada pode não entrar em vigor por até 24 horas e isso pode levar mais tempo quando um volume de origem não for totalmente utilizado. No entanto, o desempenho do volume de transição é, no mínimo, igual ao desempenho dos volumes de armazenamento de origem durante o período de migração. Um volume de 1 TiB totalmente utilizado normalmente leva aproximadamente 6 horas para migrar para uma configuração atualizada.
# Provisionar o throughput do armazenamento para agentes Standard em um cluster do Amazon MSK
Os agentes do Amazon MSK mantêm os dados em volumes de armazenamento. I/O O armazenamento é consumido quando os produtores gravam no cluster, quando os dados são replicados entre corretores e quando os consumidores leem dados que não estão na memória. O throughput de armazenamento em volume é a taxa na qual os dados podem ser gravados e lidos em um volume de armazenamento. O throughput de armazenamento provisionado é a capacidade de especificar essa taxa para os agentes em seu cluster.
Você pode especificar a taxa de throughput provisionado em MiB por segundo para clusters cujos agentes sejam do tamanho `kafka.m5.4xlarge` ou maiores e se o volume de armazenamento for de 10 GiB ou mais. É possível especificar o throughput provisionado durante a criação do cluster. Você também pode ativar ou desativar o throughput provisionado para um cluster que esteja no estado `ACTIVE`.
Para acessar informações sobre o gerenciamento de throughput, consulte [Gerenciar o throughput do armazenamento para agentes Standard em um cluster do Amazon MSK](msk-provision-throughput-management.md).
**Topics**
+ [Provisione a taxa de transferência de armazenamento em cluster do Amazon MSK usando o Console de gerenciamento da AWS](#provisioned-throughput-console)
+ [Provisione a taxa de transferência de armazenamento em cluster do Amazon MSK usando o AWS CLI](#provisioned-throughput-cli)
+ [Provisionar o throughput de armazenamento ao criar um cluster do Amazon MSK usando a API](#provisioned-throughput-api)
## Provisione a taxa de transferência de armazenamento em cluster do Amazon MSK usando o Console de gerenciamento da AWS
Esse processo mostra um exemplo de como você pode usar o Console de gerenciamento da AWS para criar um cluster Amazon MSK com a taxa de transferência provisionada ativada.
1. Faça login no Console de gerenciamento da AWS e abra o console Amazon MSK em [https://console.aws.amazon.com/msk/casa? region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/).
1. Selecione **Criar cluster**.
1. Escolha **Criação personalizada**.
1. Especifique um nome para o cluster.
1. Na seção **Armazenamento**, escolha **Habilitar**.
1. Escolha um valor para o throughput de armazenamento por agente.
1. Selecione uma VPC, as zonas e sub-redes, além dos grupos de segurança.
1. Escolha **Próximo**.
1. Na parte inferior da etapa **Segurança**, escolha **Avançar**.
1. Na parte inferior da etapa **Monitoramento e tags**, escolha **Avançar**.
1. Revise as configurações do cluster e escolha **Criar cluster**.
## Provisione a taxa de transferência de armazenamento em cluster do Amazon MSK usando o AWS CLI
Esse processo mostra um exemplo de como você pode usar o AWS CLI para criar um cluster com a taxa de transferência provisionada ativada.
1. Copie e cole o JSON a seguir em um arquivo. Substitua os espaços reservados do ID da sub-rede IDs e do grupo de segurança pelos valores da sua conta. Nomeie e salve o arquivo como `cluster-creation.json`.
```
{
"Provisioned": {
"BrokerNodeGroupInfo":{
"InstanceType":"kafka.m5.4xlarge",
"ClientSubnets":[
"Subnet-1-ID",
"Subnet-2-ID"
],
"SecurityGroups":[
"Security-Group-ID"
],
"StorageInfo": {
"EbsStorageInfo": {
"VolumeSize": 10,
"ProvisionedThroughput": {
"Enabled": true,
"VolumeThroughput": 250
}
}
}
},
"EncryptionInfo": {
"EncryptionInTransit": {
"InCluster": false,
"ClientBroker": "PLAINTEXT"
}
},
"KafkaVersion":"2.8.1",
"NumberOfBrokerNodes": 2
},
"ClusterName": "provisioned-throughput-example"
}
```
1. Execute o AWS CLI comando a seguir no diretório em que você salvou o arquivo JSON na etapa anterior.
```
aws kafka create-cluster-v2 --cli-input-json file://cluster-creation.json
```
## Provisionar o throughput de armazenamento ao criar um cluster do Amazon MSK usando a API
[Para configurar a taxa de transferência de armazenamento provisionado ao criar um cluster, use a V2. CreateCluster](https://docs.aws.amazon.com/MSK/2.0/APIReference/v2-clusters.html#CreateClusterV2)
# Configurações do Amazon MSK Provisioned
O Amazon MSK fornece configurações padrão para agentes, tópicos e nós de metadados. Você também pode criar configurações personalizadas e usá-las para criar novos clusters do MSK ou atualizar clusters existentes. Uma configuração do MSK consiste em um conjunto de propriedades e seus valores correspondentes. Dependendo do tipo de agente que você usa em seu cluster, há um conjunto diferente de padrões de configuração e um conjunto diferente de configurações que você pode modificar. Consulte as seções abaixo para obter mais detalhes sobre como configurar seus agentes Standard e Express.
**Topics**
+ [Configurações do agente Standard](msk-configuration-standard.md)
+ [Configurações do agente Express](msk-configuration-express.md)
+ [Operações de configuração do agente](msk-configuration-operations.md)
# Configurações do agente Standard
Esta seção descreve as propriedades de configuração para agentes Standard.
**Topics**
+ [Configurações personalizadas do Amazon MSK](msk-configuration-properties.md)
+ [Configuração padrão do Amazon MSK](msk-default-configuration.md)
+ [Diretrizes para a configuração de armazenamento em camadas no nível de tópico do Amazon MSK](msk-guidelines-tiered-storage-topic-level-config.md)
# Configurações personalizadas do Amazon MSK
É possível usar o Amazon MSK para criar uma configuração personalizada do MSK na qual você define as seguintes propriedades de configuração do Apache Kafka. As propriedades que você não define explicitamente obtêm os valores que têm em [Configuração padrão do Amazon MSK](msk-default-configuration.md). Para obter mais informações sobre as propriedades da configuração, consulte [Configuração do Apache Kafka](https://kafka.apache.org/documentation/#configuration).
| Name (Nome) | Description |
| --- | --- |
| allow.everyone.if.no.acl.found | Se você quiser definir essa propriedade comofalse, primeiro certifique-se de definir o Apache Kafka ACLs para seu cluster. Se você definir essa propriedade como false e não definir primeiro o Apache Kafka ACLs, perderá o acesso ao cluster. Se isso acontecer, é possível atualizar a configuração novamente e definir essa propriedade como true para recuperar o acesso ao cluster. |
| auto.create.topics.enable | Habilita a criação automática de tópicos no servidor. |
| compression.type | O tipo de compactação final de um determinado tópico. Você pode definir essa propriedade para os codecs de compactação padrão (gzip, snappy, lz4 e zstd). Além disso, também aceita uncompressed. Esse valor é equivalente a nenhuma compactação. Se você definir o valor como producer, isso significa reter o codec de compactação original definido pelo produtor. |
| connections.max.idle.ms | O tempo limite de conexões ociosas em milissegundos. Os threads do processador de soquete do servidor fecham as conexões que estiverem ociosas há mais tempo que o que o valor definido para essa propriedade. |
| default.replication.factor | O fator de replicação padrão para tópicos criados automaticamente. |
| delete.topic.enable | Habilita a operação de exclusão de tópico. Se desativar essa configuração, você não poderá excluir um tópico por meio da ferramenta de administração. |
| group.initial.rebalance.delay.ms | O período que o coordenador do grupo espera que mais consumidores de dados ingressem em um novo grupo antes de executar a primeira operação de rebalanceamento. Um atraso mais longo significa potencialmente menos rebalanceamentos, mas aumenta o tempo até o início do processamento. |
| group.max.session.timeout.ms | Tempo limite máximo de sessão para consumidores registrados. Tempos limite mais longos permitem que os consumidores tenham mais tempo para processar mensagens entre pulsações ao custo de mais tempo para detectar falhas. |
| group.min.session.timeout.ms | Tempo limite mínimo de sessão para consumidores registrados. Tempos limite mais curtos resultam em detecção mais rápida de falhas ao custo de pulsações mais frequentes do consumidor. Isso pode sobrecarregar os recursos do agente. |
| leader.imbalance.per.broker.percentage | A proporção de desequilíbrio de líder permitida por agente. O controlador aciona um balanceamento de líder caso ele ultrapasse esse valor por agente. Esse valor é especificado em porcentagem. |
| log.cleaner.delete.retention.ms | Período de tempo que você deseja que o Apache Kafka mantenha registros excluídos. O valor mínimo é 0. |
| log.cleaner.min.cleanable.ratio | Essa propriedade de configuração pode ter valores entre 0 e 1. Esse valor determina a frequência na qual o compactador de logs tenta limpar o log (se a compactação de logs estiver habilitada). Por padrão, o Apache Kafka evita limpar um log se mais de 50% do log tiver sido compactado. Essa proporção limita o espaço máximo que o log desperdiça com duplicatas (em 50%, isso significa que até 50% do log pode ser de duplicatas). Uma proporção maior significa menos limpezas mais eficientes, mas também mais espaço desperdiçado no log. |
| log.cleanup.policy | A política de limpeza padrão para segmentos além da janela de retenção. Uma lista de políticas válidas separadas por vírgulas. As políticas válidas são delete e compact. Para clusters habilitados para armazenamento em camadas, a política válida é somente delete. |
| log.flush.interval.messages | O número de mensagens acumuladas em uma partição de log antes que as mensagens sejam liberadas para o disco. |
| log.flush.interval.ms | O período máximo em milissegundos no qual uma mensagem em qualquer tópico permanece na memória antes de ser liberada para o disco. Se você não definir esse valor, o sistema usará o valor em log.flush.scheduler.interval.ms. O valor mínimo é 0. |
| log.message.timestamp.difference.max.ms | Essa configuração foi descontinuada no Kafka 3.6.0. Duas configurações, log.message.timestamp.before.max.ms e log.message.timestamp.after.max.ms, foram adicionadas. A diferença máxima de tempo entre o carimbo de data/hora em que um agente recebe uma mensagem e o carimbo de data/hora especificado na mensagem. Se log.message.timestamp.type=CreateTime, uma mensagem será rejeitada se a diferença no timestamp exceder esse limite. Essa configuração será ignorada se log.message.timestamp.type=. LogAppendTime |
| log.message.timestamp.type | Especifica se o carimbo de data/hora na mensagem é o horário de criação da mensagem ou da adição no log. Os valores permitidos são CreateTime e LogAppendTime. |
| log.retention.bytes | Tamanho máximo do log antes de ser excluído. |
| log.retention.hours | Número de horas para manter um arquivo de log antes de excluí-lo, terciário à propriedade log.retention.ms. |
| log.retention.minutes | Número de minutos para manter um arquivo de log antes de excluí-lo, secundário à propriedade log.retention.ms. Se você não definir esse valor, o sistema usará o valor de log.retention.hours. |
| log.retention.ms | Número de milissegundos para manter um arquivo de log antes de excluí-lo (em milissegundos). Se não for definido, o valor de log.retention.minutes será usado. |
| log.roll.ms | Tempo máximo para que um novo segmento de log seja implantado (em milissegundos). Se você não definir essa propriedade, o sistema usará o valor de log.roll.hours. O valor mínimo possível para essa propriedade é 1. |
| log.segment.bytes | Tamanho máximo de um único arquivo de log. |
| max.incremental.fetch.session.cache.slots | Número máximo de sessões de busca incrementais mantidas. |
| message.max.bytes | O maior tamanho de lote de registros que o Kafka permite. Se você aumentar esse valor e houver consumidores anteriores à versão 0.10.2, também será necessário aumentar o tamanho de busca dos consumidores para que eles possam buscar lotes de registros desse tamanho. O formato de mensagem mais recente sempre agrupa as mensagens em lotes visando eficiência. As versões anteriores de formato de mensagem não agrupam em lotes os registros não compactados, e, nesse caso, esse limite é aplicável somente a um único registro. É possível definir esse valor por tópico com a configuração max.message.bytes de nível do tópico. |
| min.insync.replicas | Quando um produtor define acks como `"all"` (ou `"-1"`), o valor em min.insync.replicas especifica o número mínimo de réplicas que devem confirmar uma gravação para que a gravação seja considerada bem-sucedida. Se esse mínimo não puder ser atingido, o produtor cria uma exceção ( NotEnoughReplicas ou NotEnoughReplicasAfterAppend). Você pode usar valores em min.insync.replicas e acks para forçar maiores garantias de durabilidade. Por exemplo, você poderia criar um tópico com um fator de replicação de 3, definir min.insync.replicas como 2 e produzir com acks de `"all"`. Isso garante que o produtor gere uma exceção se a maioria das réplicas não receber uma gravação. |
| num.io.threads | O número de threads que o servidor usa para processar solicitações, que podem incluir E/S de disco. |
| num.network.threads | O número de threads que o servidor usa para receber solicitações da rede e enviar respostas para ela. |
| num.partitions | Número padrão de partições de log por tópico. |
| num.recovery.threads.per.data.dir | O número de threads por diretório de dados a ser usado para recuperar logs na inicialização e para liberá-los no desligamento. |
| num.replica.fetchers | O número de threads de busca usados para replicar mensagens de um agente de origem. Se você aumentar esse valor, poderá aumentar o grau de I/O paralelismo no corretor seguidor. |
| offsets.retention.minutes | Depois que um grupo de consumidores perde todos os consumidores (isto é, torna-se vazio), seus deslocamentos são mantidos durante esse período de retenção antes de serem descartados. Para consumidores autônomos (ou seja, que usam atribuição manual), os deslocamentos expiram depois da última confirmação somada a esse período de retenção. |
| offsets.topic.replication.factor | O fator de replicação do tópico de deslocamento. Defina esse valor mais alto para garantir a disponibilidade. A criação do tópico interno falha até que o tamanho do cluster atenda a esse requisito de fator de replicação. |
| replica.fetch.max.bytes | O número de bytes de mensagens para tentar buscar para cada partição. Esse não é um máximo absoluto. Se o primeiro lote de registros na primeira partição não vazia da busca for maior que esse valor, o lote de registros será retornado para garantir o progresso. As propriedades message.max.bytes (configuração do agente) ou max.message.bytes (configuração do tópico) definem o tamanho máximo do lote de registros aceito pelo agente. |
| replica.fetch.response.max.bytes | O número máximo de bytes esperado para toda a resposta de busca. Os registros são buscados em lotes e, se o primeiro lote de registros na primeira partição não vazia da busca for maior que esse valor, o lote de registros ainda será retornado para garantir o progresso. Esse não é um máximo absoluto. As propriedades message.max.bytes (configuração do agente) ou max.message.bytes (configuração do tópico) especificam o tamanho máximo do lote de registros aceito pelo agente. |
| replica.lag.time.max.ms | Se um seguidor não enviou nenhuma solicitação de busca ou se não consumiu até o deslocamento final do log do líder por pelo menos esse número de milissegundos, o líder remove o seguidor do ISR.MinValue: 10000MaxValue = 30000 |
| replica.selector.class | O nome da classe totalmente qualificado que implementa. ReplicaSelector O agente usa esse valor para encontrar a réplica de leitura preferencial. Se estiver usando a versão 2.4.1 ou mais recente do Apache Kafka e quiser permitir que os clientes busquem da réplica mais próxima, defina essa propriedade como org.apache.kafka.common.replica.RackAwareReplicaSelector. Para obter mais informações, consulte [Apache Kafka versão 2.4.1 (use 2.4.1.1 alternativamente)](supported-kafka-versions.md#2.4.1). |
| replica.socket.receive.buffer.bytes | O buffer de recebimento do soquete para solicitações de rede. |
| socket.receive.buffer.bytes | O buffer SO\$1RCVBUF dos soquetes do servidor de soquetes. O valor mínimo que você pode definir para essa propriedade é -1. Se o valor for -1, o Amazon MSK usará o sistema operacional padrão. |
| socket.request.max.bytes | O número máximo de bytes em uma solicitação de soquete. |
| socket.send.buffer.bytes | O buffer SO\$1SNDBUF dos soquetes do servidor de soquetes. O valor mínimo que você pode definir para essa propriedade é -1. Se o valor for -1, o Amazon MSK usará o sistema operacional padrão. |
| transaction.max.timeout.ms | Tempo limite máximo para transações. Se o tempo de transação solicitado de um cliente exceder esse valor, o corretor retornará um erro em InitProducerIdRequest. Isso impede que um cliente use um tempo limite muito grande e pode impedir que os consumidores leiam os tópicos incluídos na transação. |
| transaction.state.log.min.isr | A configuração de min.insync.replicas substituída para o tópico de transação. |
| transaction.state.log.replication.factor | O fator de replicação do tópico de transação. Defina essa propriedade com um valor maior para aumentar a disponibilidade. A criação do tópico interno falha até que o tamanho do cluster atenda a esse requisito de fator de replicação. |
| transactional.id.expiration.ms | O tempo em milissegundos que o coordenador da transação deve aguardar para receber qualquer atualização do status da transação atual antes que o coordenador expire sua ID transacional. Essa configuração também influencia a expiração do ID do produtor porque faz com que o produtor IDs expire quando esse tempo decorre após a última gravação com o ID do produtor fornecido. O produtor IDs pode expirar mais cedo se a última gravação do ID do produtor for excluída devido às configurações de retenção do tópico. O valor mínimo para essa propriedade é de 1 milissegundo. |
| unclean.leader.election.enable | Indica se as réplicas que não estão no conjunto ISR devem atuar como líderes em último recurso, mesmo que isso possa resultar em perda de dados. |
| zookeeper.connection.timeout.ms | ZooKeeper clusters de modos. Tempo máximo que o cliente espera para estabelecer uma conexão. ZooKeeper Se você não definir esse valor, o sistema usará o valor de zookeeper.session.timeout.ms. MinValue = 6000 MaxValue (inclusive) = 18000 Recomenda-se que você defina esse valor como 10.000 em T3.small para evitar o tempo de inatividade do cluster. |
| zookeeper.session.timeout.ms | ZooKeeper clusters de modos. O tempo limite da ZooKeeper sessão do Apache em milissegundos. MinValue = 6000 MaxValue (inclusive) = 18000 |
Para saber como criar uma configuração personalizada do MSK, listar todas as configurações ou descrevê-las, consulte [Operações de configuração do agente](msk-configuration-operations.md). Para criar um cluster do MSK com uma configuração personalizada do MSK ou para atualizar um cluster com uma nova configuração personalizada, consulte [Principais recursos e conceitos do Amazon MSK](operations.md).
Quando você atualiza o cluster existente do MSK com uma configuração personalizada do MSK, o Amazon MSK faz reinicializações contínuas quando necessário, empregando as práticas recomendadas para minimizar o tempo de inatividade do cliente. Por exemplo, depois que o Amazon MSK reinicia cada agente, o Amazon MSK tenta deixar o agente recuperar os dados que possam ter sido perdidos pelo agente durante a atualização da configuração antes de avançar para o próximo agente.
## Configuração dinâmica do Amazon MSK
Além das propriedades de configuração fornecidas pelo Amazon MSK, você pode definir dinamicamente as propriedades de configuração em nível de cluster e de agente que não exigem uma reinicialização do agente. É possível definir dinamicamente algumas propriedades de configuração. Trata-se das propriedades que não estão marcadas como somente leitura na tabela em [Configurações do agente](https://kafka.apache.org/documentation/#brokerconfigs) na documentação do Apache Kafka. Para obter informações sobre a configuração dinâmica e comandos de exemplo, consulte [Atualização das configurações do agente](https://kafka.apache.org/documentation/#dynamicbrokerconfigs) na documentação do Apache Kafka.
**nota**
É possível definir a propriedade `advertised.listeners`, mas não a propriedade `listeners`.
## Configuração no nível de tópico do Amazon MSK
Você pode usar os comandos do Apache Kafka para definir ou modificar propriedades de configuração em nível de tópico para tópicos novos e existentes. Para obter mais informações sobre as propriedades de configuração no nível de tópico e exemplos sobre como defini-las, consulte [Configurações no nível de tópico](https://kafka.apache.org/documentation/#topicconfigs) na documentação do Apache Kafka.
# Configuração padrão do Amazon MSK
Quando você cria um cluster do MSK sem especificar uma configuração personalizada do MSK, o Amazon MSK cria e usa uma configuração padrão com os valores apresentados na tabela a seguir. Para propriedades que não estejam nessa tabela, o Amazon MSK usará os padrões associados à sua versão do Apache Kafka. Para obter uma lista desses valores padrão, consulte [Configuração do Apache Kafka](https://kafka.apache.org/documentation/#configuration).
| Name (Nome) | Description | Valor padrão para cluster de armazenamento sem camadas | Valor padrão para cluster de armazenamento em camadas |
| --- | --- | --- | --- |
| allow.everyone.if.no.acl.found | Se nenhum padrão de recurso corresponder a um recurso específico, o recurso não tem nenhum associado ACLs. Nesse caso, se você definir essa propriedade como true, todos os usuários terão acesso ao recurso, não apenas os superusuários. | true | true |
| auto.create.topics.enable | Habilita a criação automática de um tópico no servidor. | false | false |
| auto.leader.rebalance.enable | Habilita o equilíbrio de líderes automáticos. Se necessário, um thread em segundo plano verifica e inicia o balanceamento do líder em intervalos regulares. | true | true |
| default.replication.factor | Fatores de replicação padrão para tópicos criados automaticamente. | O valor é 3 para clusters em 3 zonas de disponibilidade e 2 para clusters em 2 zonas de disponibilidade. | O valor é 3 para clusters em 3 zonas de disponibilidade e 2 para clusters em 2 zonas de disponibilidade. |
| local.retention.bytes | O tamanho máximo dos segmentos de log locais de uma partição antes que ela exclua os segmentos antigos. Se você não definir esse valor, o sistema usará o valor de log.retention.bytes. O valor efetivo sempre deve ser menor que ou igual ao valor de log.retention.bytes. O valor padrão de -2 indica que não há limite para a retenção local. Isso corresponde à configuração de -1 para retention.ms/bytes. As propriedades local.retention.ms e local.retention.bytes são semelhantes a log.retention, pois são usadas para determinar por quanto tempo os segmentos de log devem permanecer no armazenamento local. As configurações existentes de log.retention.\$1 são configurações de retenção para a partição do tópico. Isso inclui armazenamento local e remoto. Valores válidos: números inteiros em [-2; \$1Inf] | -2 para ilimitado | -2 para ilimitado |
| local.retention.ms | O número de milissegundos para a retenção do segmento de log local antes da exclusão. Se você não definir esse valor, o Amazon MSK usará o valor de log.retention.ms. O valor efetivo sempre deve ser menor que ou igual ao valor de log.retention.bytes. O valor padrão de -2 indica que não há limite para a retenção local. Isso corresponde à configuração de -1 para retention.ms/bytes.Os valores de local.retention.ms e local.retention.bytes são semelhantes a log.retention. O MSK usa essa configuração para determinar por quanto tempo os segmentos de log devem permanecer no armazenamento local. As configurações existentes de log.retention.\$1 são configurações de retenção para a partição do tópico. Isso inclui armazenamento local e remoto. Os valores válidos são números inteiros maiores que 0. | -2 para ilimitado | -2 para ilimitado |
| log.message.timestamp.difference.max.ms | Essa configuração foi descontinuada no Kafka 3.6.0. Duas configurações, log.message.timestamp.before.max.ms e log.message.timestamp.after.max.ms, foram adicionadas. A diferença máxima permitida entre o timestamp em que um agente recebe uma mensagem e o timestamp especificado na mensagem. Se log.message.timestamp.type=CreateTime, uma mensagem será rejeitada se a diferença no timestamp exceder esse limite. Essa configuração será ignorada se log.message.timestamp.type=. LogAppendTime Para evitar a repetição desnecessária e frequente de logs, a diferença máxima permitida para o carimbo de data/hora não deve ser maior que log.retention.ms. | 9223372036854775807 | 86400000 para Kafka 2.8.2.tiered e Kafka 3.7.x em camadas. |
| log.segment.bytes | O tamanho máximo de um único arquivo de log. | 1073741824 | 134217728 |
| min.insync.replicas | Quando um produtor define o valor de confirmações (as confirmações que o produtor receber o agente do Kafka) como `"all"` (ou `"-1"`), o valor em min.insync.replicas especifica o número mínimo de réplicas que devem confirmar uma gravação para que a gravação seja considerada bem-sucedida. Se esse valor não atingir esse mínimo, o produtor gera uma exceção ( NotEnoughReplicas ou NotEnoughReplicasAfterAppend). Quando você usar os valores em min.insync.replicas e acks juntos, será possível forçar maiores garantias de durabilidade. Por exemplo, você poderia criar um tópico com um fator de replicação de 3, definir min.insync.replicas como 2 e produzir com acks de `"all"`. Isso garante que o produtor gere uma exceção se a maioria das réplicas não receber uma gravação. | O valor é 2 para clusters em 3 zonas de disponibilidade e 1 para clusters em 2 zonas de disponibilidade. | O valor é 2 para clusters em 3 zonas de disponibilidade e 1 para clusters em 2 zonas de disponibilidade. |
| num.io.threads | O número de threads que o servidor usa para produzir solicitações, que podem incluir E/S de disco. | 8 | max (8, vCPUs) onde v CPUs depende do tamanho da instância do broker |
| num.network.threads | O número de threads que o servidor usa para receber solicitações da rede e enviar respostas para a rede. | 5 | max (5, vCPUs /2) onde v CPUs depende do tamanho da instância do broker |
| num.partitions | Número padrão de partições de log por tópico. | 1 | 1 |
| num.replica.fetchers | Número de segmentos de busca usados para replicar mensagens de um corretor de origem. Se você aumentar esse valor, poderá aumentar o grau de I/O paralelismo no corretor seguidor. | 2 | max (2, vCPUs /4) onde v CPUs depende do tamanho da instância do broker |
| remote.log.msk.disable.policy | Usado com remote.storage.enable para desabilitar o armazenamento em camadas. Defina essa política como Excluir para indicar que os dados no armazenamento em camadas são excluídos quando você definir remote.storage.enable como falso. | N/D | Nenhum |
| remote.log.reader.threads | O tamanho do pool de threads do leitor de logs remoto. Usado no agendamento de tarefas para buscar dados do armazenamento remoto. | N/D | max (10, v CPUs \$1 0,67) onde v CPUs depende do tamanho da instância do broker |
| remote.storage.enable | Se definido como verdadeiro, habilita o armazenamento em camadas (remoto) para um tópico. Desabilita o armazenamento em camadas no nível de tópico se definido como falso e se remote.log.msk.disable.policy estiver definido como Excluir. Ao desabilitar o armazenamento em camadas, você exclui dados do armazenamento remoto. Ao desabilitar o armazenamento em camadas para um tópico, não será possível habilitá-lo novamente. | false | false |
| replica.lag.time.max.ms | Se um seguidor não enviou nenhuma solicitação de busca ou se não consumiu até o deslocamento final do log do líder por pelo menos esse número de milissegundos, o líder remove o seguidor do ISR. | 30000 | 30000 |
| retention.ms | Campo obrigatório. O tempo mínimo é de 3 dias. Não há padrão porque a configuração é obrigatória. O Amazon MSK usa o valor retention.ms com local.retention.ms para determinar quando os dados são movidos do armazenamento local para o armazenamento em camadas. O valor local.retention.ms especifica quando mover dados do armazenamento local para o armazenamento em camadas. O valor retention.ms especifica quando remover dados do armazenamento em camadas (ou seja, remoção do cluster). Valores válidos: números inteiros em [-1; \$1Inf] | Mínimo de 259.200.000 milissegundos (3 dias). Use -1 para retenção infinita. | Mínimo de 259.200.000 milissegundos (3 dias). Use -1 para retenção infinita. |
| socket.receive.buffer.bytes | O buffer SO\$1RCVBUF dos soquetes do servidor de soquetes. Se o valor for -1, o sistema operacional padrão será usado. | 102400 | 102400 |
| socket.request.max.bytes | Número máximo de bytes em uma solicitação de soquete. | 104857600 | 104857600 |
| socket.send.buffer.bytes | O buffer SO\$1SNDBUF dos soquetes do servidor de soquetes. Se o valor for -1, o sistema operacional padrão será usado. | 102400 | 102400 |
| unclean.leader.election.enable | Indica se você deseja que as réplicas que não estão no conjunto ISR devem atuar como líderes em último recurso, mesmo que isso possa resultar em perda de dados. | verdadeiro | false |
| zookeeper.session.timeout.ms | O tempo limite da ZooKeeper sessão do Apache em milissegundos. | 18000 | 18000 |
| zookeeper.set.acl | O cliente definido a ser usado com segurança ACLs. | false | false |
Para obter informações sobre como especificar valores para uma configuração personalizada, consulte [Configurações personalizadas do Amazon MSK](msk-configuration-properties.md).
# Diretrizes para a configuração de armazenamento em camadas no nível de tópico do Amazon MSK
Veja a seguir as configurações e limitações padrão quando você configura o armazenamento em camadas no nível de tópico.
+ O Amazon MSK não é compatível com tamanhos menores de segmentos de log para tópicos com o armazenamento em camadas ativado. Se você quiser criar um segmento, há um tamanho mínimo de segmento de log de 48 MiB ou um tempo mínimo de rolagem do segmento de 10 minutos. Esses valores são mapeados para as propriedades segment.bytes e segment.ms.
+ O valor de local.retention. ms/bytes can't equal or exceed the retention.ms/bytes. Essa é a configuração de retenção de armazenamento em camadas.
+ O valor padrão para local.retention. ms/bytes is -2. This means that the retention.ms value is used for local.retention.ms/bytes. Nesse caso, os dados permanecem no armazenamento local e no armazenamento em camadas (uma cópia em cada) e expiram juntos. Para essa opção, uma cópia dos dados locais é mantida no armazenamento remoto. Nesse caso, os dados lidos do tráfego de consumo vêm do armazenamento local.
+ O valor padrão para retention.ms é de 7 dias. Não há limite de tamanho padrão para retention.bytes.
+ O valor mínimo para retention.ms/bytes é -1. Isso significa retenção infinita.
+ O valor mínimo para local.retention. ms/bytes is -2. This means infinite retention for local storage. It matches with the retention.ms/bytesdefinindo como -1.
+ A configuração retention.ms no nível de tópico é obrigatória para tópicos com armazenamento em camadas ativado. O mínimo de retention.ms é de 3 dias.
Para obter mais informações sobre restrições de armazenamento em camadas, consulte [Restrições e limitações do armazenamento em camadas para clusters do Amazon MSK](msk-tiered-storage.md#msk-tiered-storage-constraints).
# Configurações do agente Express
O Apache Kafka tem centenas de configurações de agente que você pode usar para ajustar o desempenho do seu cluster do MSK Provisioned. Definir valores errôneos ou abaixo do ideal pode afetar a confiabilidade e o desempenho do cluster. Os agentes Express melhoram a disponibilidade e a durabilidade de seus clusters do MSK Provisioned com a definição de valores ideais para configurações críticas, protegendo-os de configurações incorretas comuns. Há três categorias de configurações com base no acesso de leitura e gravação: configurações de [leitura/gravação (editável)](msk-configuration-express-read-write.md), [somente leitura](msk-configuration-express-read-only.md) e configurações sem leitura/gravação. Algumas configurações ainda usam o valor padrão do Apache Kafka com a versão do Apache Kafka que o cluster está executando. Elas são marcadas como Padrão do Apache Kafka.
**Topics**
+ [Configurações personalizadas do agente Express do MSK (acesso de leitura/gravação)](msk-configuration-express-read-write.md)
+ [Configurações somente leitura do agente Express](msk-configuration-express-read-only.md)
# Configurações personalizadas do agente Express do MSK (acesso de leitura/gravação)
Você pode atualizar as configurações do read/write broker usando o [recurso de configuração de atualização](msk-update-cluster-config.md) do Amazon MSK ou usando a API do Apache Kafka. AlterConfig As configurações do agente do Apache Kafka são estáticas ou dinâmicas. As configurações estáticas exigem a reinicialização do agente para que a configuração seja aplicada, enquanto as configurações dinâmicas não precisam da reinicialização do agente. Para obter mais informações sobre propriedades de configuração e modos de atualização, consulte [Atualização das configurações do agente.](https://kafka.apache.org/documentation/#dynamicbrokerconfigs)
**Topics**
+ [Configurações estáticas em agentes Express do MSK](#msk-configuration-express-static-configuration)
+ [Configurações dinâmicas em agentes Express](#msk-configuration-express-dynamic-configuration)
+ [Configurações em nível de tópico em agentes Express](#msk-configuration-express-topic-configuration)
## Configurações estáticas em agentes Express do MSK
É possível usar o Amazon MSK para criar uma configuração personalizada do MSK na qual você define as propriedades a seguir. O Amazon MSK define e gerencia todas as outras propriedades que você não configurou. Você pode criar e atualizar arquivos de configuração estáticos no console do MSK ou por meio do [comando de configurações](msk-configuration-operations-create.md).
| Propriedade | Description | Valor padrão |
| --- | --- | --- |
| allow.everyone.if.no.acl.found | Se você quiser definir essa propriedade como false, primeiro certifique-se de definir o Apache Kafka ACLs para seu cluster. Se você definir essa propriedade como false e não definir primeiro o Apache Kafka ACLs, perderá o acesso ao cluster. Caso isso ocorra, é possível atualizar novamente a configuração e definir essa propriedade como verdadeira para recuperar o acesso ao cluster. | true |
| auto.create.topics.enable | Habilita a criação automática de um tópico no servidor. | false |
| compression.type | Especifica o tipo de compactação final de um determinado tópico. Essa configuração aceita os codecs de compactação padrão: gzip, snappy, lz4, zstd. Essa configuração também aceita `uncompressed`, que equivale a nenhuma compressão; e `producer`, que significa manter o codec de compactação original definido pelo produtor. | Padrão do Apache Kafka |
| connections.max.idle.ms | O tempo limite de conexões ociosas em milissegundos. Os threads do processador de soquete do servidor fecham as conexões que estiverem ociosas há mais tempo que o que o valor definido para essa propriedade. | Padrão do Apache Kafka |
| delete.topic.enable | Habilita a operação de exclusão de tópico. Se desativar essa configuração, você não poderá excluir um tópico por meio da ferramenta de administração. | Padrão do Apache Kafka |
| group.initial.rebalance.delay.ms | O período que o coordenador do grupo espera que mais consumidores de dados ingressem em um novo grupo antes de executar a primeira operação de rebalanceamento. Um atraso mais longo significa potencialmente menos rebalanceamentos, mas aumenta o tempo até o início do processamento. | Padrão do Apache Kafka |
| group.max.session.timeout.ms | Tempo limite máximo de sessão para consumidores registrados. Tempos limite mais longos permitem que os consumidores tenham mais tempo para processar mensagens entre pulsações ao custo de mais tempo para detectar falhas. | Padrão do Apache Kafka |
| leader.imbalance.per.broker.percentage | A proporção de desequilíbrio de líder permitida por agente. O controlador aciona um balanceamento de líder caso ele ultrapasse esse valor por agente. Esse valor é especificado em porcentagem. | Padrão do Apache Kafka |
| log.cleanup.policy | A política de limpeza padrão para segmentos além da janela de retenção. Uma lista de políticas válidas separadas por vírgulas. As políticas válidas são delete e compact. Para clusters habilitados para armazenamento em camadas, a política válida é somente delete. | Padrão do Apache Kafka |
| log.message.timestamp.after.max.ms | A diferença de data e hora permitida entre o timestamp da mensagem e o timestamp do agente. O carimbo de data e hora da mensagem pode ser posterior ou igual ao carimbo do agente, com a diferença máxima permitida determinada pelo valor definido nessa configuração. Se for `log.message.timestamp.type=CreateTime`, a mensagem será rejeitada se a diferença nos carimbos de data/hora exceder esse limite especificado. Essa configuração será ignorada se for `log.message.timestamp.type=LogAppendTime`. | 86400000 (24 \$1 60 \$1 60 \$1 1000 ms, ou seja, 1 dia) |
| log.message.timestamp.before.max.ms | A diferença de data e hora permitida entre os carimbos de data e hora do agente e da mensagem. O carimbo de data e hora da mensagem pode ser anterior ou igual ao carimbo do agente, com a diferença máxima permitida determinada pelo valor definido nessa configuração. Se for `log.message.timestamp.type=CreateTime`, a mensagem será rejeitada se a diferença nos carimbos de data/hora exceder esse limite especificado. Essa configuração será ignorada se for `log.message.timestamp.type=LogAppendTime`. | 86400000 (24 \$1 60 \$1 60 \$1 1000 ms, ou seja, 1 dia) |
| log.message.timestamp.type | Especifica se o carimbo de data/hora na mensagem é o horário de criação da mensagem ou da adição no log. Os valores permitidos são CreateTime e LogAppendTime. | Padrão do Apache Kafka |
| log.retention.bytes | Tamanho máximo do log antes de ser excluído. | Padrão do Apache Kafka |
| log.retention.ms | Número de milissegundos para manter um arquivo de log antes de excluí-lo. | Padrão do Apache Kafka |
| max.connections.per.ip | O número máximo de conexões permitido para cada endereço IP. Pode ser definido como 0 se houver substituições configuradas usando a propriedade max.connections.per.ip.overrides. Novas conexões do endereço IP serão descartadas se o limite for atingido. | Padrão do Apache Kafka |
| max.incremental.fetch.session.cache.slots | Número máximo de sessões de busca incrementais mantidas. | Padrão do Apache Kafka |
| message.max.bytes | O maior tamanho de lote de registros que o Kafka permite. Se você aumentar esse valor e houver consumidores anteriores à versão 0.10.2, também será necessário aumentar o tamanho de busca dos consumidores para que eles possam buscar lotes de registros desse tamanho. O formato de mensagem mais recente sempre agrupa as mensagens em lotes visando eficiência. As versões anteriores de formato de mensagem não agrupam em lotes os registros não compactados, e, nesse caso, esse limite é aplicável somente a um único registro. É possível definir esse valor por tópico com a configuração `max.message.bytes` de nível do tópico. | Padrão do Apache Kafka |
| num.partitions | Número padrão de partições de log por tópico. | 1 |
| offsets.retention.minutes | Depois que um grupo de consumidores perde todos os consumidores (isto é, torna-se vazio), seus deslocamentos são mantidos durante esse período de retenção antes de serem descartados. Para consumidores autônomos (ou seja, que usam atribuição manual), os deslocamentos expiram depois da última confirmação somada a esse período de retenção. | Padrão do Apache Kafka |
| replica.fetch.max.bytes | O número de bytes de mensagens para tentar buscar para cada partição. Esse não é um máximo absoluto. Se o primeiro lote de registros na primeira partição não vazia da busca for maior que esse valor, o lote de registros será retornado para garantir o progresso. As propriedades message.max.bytes (configuração do agente) ou max.message.bytes (configuração do tópico) definem o tamanho máximo do lote de registros aceito pelo agente. | Padrão do Apache Kafka |
| replica.selector.class | O nome da classe totalmente qualificado que implementa. ReplicaSelector O agente usa esse valor para encontrar a réplica de leitura preferencial. Se quiser permitir que os clientes busquem na réplica mais próxima, defina essa propriedade como `org.apache.kafka.common.replica.RackAwareReplicaSelector`. | Padrão do Apache Kafka |
| socket.receive.buffer.bytes | O buffer SO\$1RCVBUF dos soquetes do servidor de soquetes. Se o valor for -1, o sistema operacional padrão será usado. | 102400 |
| socket.request.max.bytes | Número máximo de bytes em uma solicitação de soquete. | 104857600 |
| socket.send.buffer.bytes | O buffer SO\$1SNDBUF dos soquetes do servidor de soquetes. Se o valor for -1, o sistema operacional padrão será usado. | 102400 |
| transaction.max.timeout.ms | Tempo limite máximo para transações. Se o tempo de transação solicitado de um cliente exceder esse valor, o corretor retornará um erro em InitProducerIdRequest. Isso impede que um cliente use um tempo limite muito grande e pode impedir que os consumidores leiam os tópicos incluídos na transação. | Padrão do Apache Kafka |
| transactional.id.expiration.ms | O tempo em milissegundos que o coordenador da transação deve aguardar para receber qualquer atualização do status da transação atual antes que o coordenador expire sua ID transacional. Essa configuração também influencia a expiração do ID do produtor porque faz com que IDs o produtor expire quando esse tempo decorre após a última gravação com o ID do produtor fornecido. O produtor IDs pode expirar mais cedo se a última gravação do ID do produtor for excluída devido às configurações de retenção do tópico. O valor mínimo para essa propriedade é de 1 milissegundo. | Padrão do Apache Kafka |
## Configurações dinâmicas em agentes Express
Você pode usar a AlterConfig API Apache Kafka ou a ferramenta Kafka-configs.sh para editar as seguintes configurações dinâmicas. O Amazon MSK define e gerencia todas as outras propriedades que você não configurou. Você pode definir dinamicamente as propriedades de configuração em nível de cluster e de agente que não exigem a reinicialização do agente.
| Propriedade | Description | Valor padrão |
| --- | --- | --- |
| advertised.listeners | Receptores a serem publicados para os clientes usarem, se forem diferentes da propriedade de configuração `listeners`. Em ambientes de IaaS, pode precisar ser diferente da interface à qual o agente se vincula. Se isso não for definido, será usado o valor para receptores. Ao contrário dos receptores, não é válido anunciar o meta-endereço 0.0.0.0. E diferente de `listeners`, pode haver portas duplicadas nessa propriedade, de forma que um receptor possa ser configurado para anunciar o endereço de outro receptor. Isso pode ser útil em alguns casos em que balanceadores de carga externos forem usados. Essa propriedade é definida em um nível por agente. | nulo |
| compression.type | O tipo de compactação final de um determinado tópico. Você pode definir essa propriedade para os codecs de compactação padrão (`gzip`, `snappy`, `lz4` e `zstd`). Além disso, também aceita `uncompressed`. Esse valor é equivalente a nenhuma compactação. Se você definir o valor como `producer`, isso significa reter o codec de compactação original definido pelo produtor. | Padrão do Apache Kafka |
| log.cleaner.delete.retention.ms | A duração do período de retenção de marcadores de exclusão a excluir em tópicos de logs compactados. Essa configuração também fornece um limite no tempo em que um consumidor deve concluir uma leitura se começar do deslocamento 0 para garantir que obtenha um instantâneo válido do estágio final. Caso contrário, os marcadores de exclusão a excluir podem ser coletados antes que concluam a digitalização. | 86400000 (24 \$1 60 \$1 60 \$1 1000 ms, ou seja, 1 dia), Padrão do Apache Kafka |
| log.cleaner.min.compaction.lag.ms | O tempo mínimo que uma mensagem permanecerá descompactada no log. Essa configuração é aplicável somente para logs que estejam compactados. | 0, Padrão do Apache Kafka |
| log.cleaner.max.compaction.lag.ms | O tempo máximo que uma mensagem permanecerá inelegível para compactação no log. Essa configuração é aplicável somente para logs que estejam compactados. Essa configuração estaria limitada a um intervalo de [7 dias, Long.Max]. | 9223372036854775807, Padrão do Apache Kafka |
| log.cleanup.policy | A política de limpeza padrão para segmentos além da janela de retenção. Uma lista de políticas válidas separadas por vírgulas. As políticas válidas são `delete` e `compact`. Para clusters habilitados para armazenamento em camadas, a política válida é somente `delete`. | Padrão do Apache Kafka |
| log.message.timestamp.after.max.ms | A diferença de data e hora permitida entre o timestamp da mensagem e o timestamp do agente. O carimbo de data e hora da mensagem pode ser posterior ou igual ao carimbo do agente, com a diferença máxima permitida determinada pelo valor definido nessa configuração. Se for `log.message.timestamp.type=CreateTime`, a mensagem será rejeitada se a diferença nos carimbos de data/hora exceder esse limite especificado. Essa configuração será ignorada se for `log.message.timestamp.type=LogAppendTime`. | 86400000 (24 \$1 60 \$1 60 \$1 1000 ms, ou seja, 1 dia) |
| log.message.timestamp.before.max.ms | A diferença de data e hora permitida entre os carimbos de data e hora do agente e da mensagem. O carimbo de data e hora da mensagem pode ser anterior ou igual ao carimbo do agente, com a diferença máxima permitida determinada pelo valor definido nessa configuração. Se for `log.message.timestamp.type=CreateTime`, a mensagem será rejeitada se a diferença nos carimbos de data/hora exceder esse limite especificado. Essa configuração será ignorada se for `log.message.timestamp.type=LogAppendTime`. | 86400000 (24 \$1 60 \$1 60 \$1 1000 ms, ou seja, 1 dia) |
| log.message.timestamp.type | Especifica se o carimbo de data/hora na mensagem é o horário de criação da mensagem ou da adição no log. Os valores permitidos são `CreateTime` e `LogAppendTime`. | Padrão do Apache Kafka |
| log.retention.bytes | Tamanho máximo do log antes de ser excluído. | Padrão do Apache Kafka |
| log.retention.ms | Número de milissegundos para manter um arquivo de log antes de excluí-lo. | Padrão do Apache Kafka |
| max.connection.creation.rate | A taxa máxima de criação de conexão permitida no agente a qualquer momento. | Padrão do Apache Kafka |
| max.connections | O número máximo de conexões permitido no agente a qualquer momento. Esse limite é aplicado além de quaisquer limites por IP configurados usando `max.connections.per.ip`. | Padrão do Apache Kafka |
| max.connections.per.ip | O número máximo de conexões permitido para cada endereço IP. Pode ser definido como `0` se houver substituições configuradas usando a propriedade max.connections.per.ip.overrides. Novas conexões do endereço IP serão descartadas se o limite for atingido. | Padrão do Apache Kafka |
| max.connections.per.ip.overrides | Uma lista separada por vírgula de nomes por IP ou host substitui o número máximo padrão de conexões. Um exemplo de valor é `hostName:100,127.0.0.1:200` | Padrão do Apache Kafka |
| message.max.bytes | O maior tamanho de lote de registros que o Kafka permite. Se você aumentar esse valor e houver consumidores anteriores à versão 0.10.2, também será necessário aumentar o tamanho de busca dos consumidores para que eles possam buscar lotes de registros desse tamanho. O formato de mensagem mais recente sempre agrupa as mensagens em lotes visando eficiência. As versões anteriores de formato de mensagem não agrupam em lotes os registros não compactados, e, nesse caso, esse limite é aplicável somente a um único registro. É possível definir esse valor por tópico com a configuração `max.message.bytes` de nível do tópico. | Padrão do Apache Kafka |
| producer.id.expiration.ms | O tempo em ms que um líder de partição de tópico esperará antes de expirar o produtor IDs. IDs O produtor não expirará enquanto uma transação associada a ele ainda estiver em andamento. Observe que o produtor IDs pode expirar mais cedo se a última gravação do ID do produtor for excluída devido às configurações de retenção do tópico. Definir esse valor igual ou maior que `delivery.timeout.ms` pode ajudar a evitar a expiração durante novas tentativas e a proteger contra a duplicação de mensagens, mas o padrão deve ser razoável para a maioria dos casos de uso. | Padrão do Apache Kafka |
## Configurações em nível de tópico em agentes Express
Você pode usar os comandos do Apache Kafka para definir ou modificar propriedades de configuração em nível de tópico para tópicos novos e existentes. Se você não puder fornecer nenhuma configuração em nível de tópico, o Amazon MSK usará o agente padrão. Assim como nas configurações em nível de agente, o Amazon MSK protege algumas das propriedades de configuração em nível de tópico contra alterações. Os exemplos incluem fator de replicação `min.insync.replicas` e `unclean.leader.election.enable`. Se você tentar criar um tópico com um valor de fator de replicação diferente de `3`, por padrão o Amazon MSK criará o tópico com um fator de replicação de `3`. Para obter mais informações sobre as propriedades de configuração no nível de tópico e exemplos sobre como defini-las, consulte [Configurações no nível de tópico](https://kafka.apache.org/documentation/#topicconfigs) na documentação do Apache Kafka.
| Propriedade | Description |
| --- | --- |
| cleanup.policy | Essa configuração designa a política de retenção a ser usada em segmentos de log. A política de “exclusão” (que é a padrão) descartará segmentos antigos quando seu tempo de retenção ou limite de tamanho for atingido. A política “compacta” permitirá a compactação de logs retendo o valor mais recente de cada chave. Também é possível especificar ambas as políticas em uma lista separada por virgulas (por exemplo, “excluir, compactar”). Nesse caso, os segmentos antigos serão descartados de acordo com a configuração de tamanho e tempo de retenção, enquanto os segmentos retidos serão compactados. A compactação em agentes Express é acionada depois que os dados em uma partição atingem 256 MB. |
| compression.type | Especifica o tipo de compactação final de um determinado tópico. Essa configuração aceita os codecs de compressão padrão (`gzip`, `snappy`, `lz4`, `zstd`). Também aceita `uncompressed`, que equivale a nenhuma compressão, e `producer`, que significa manter o codec de compactação original definido pelo produtor. |
| delete.retention.ms | A duração do período de retenção de marcadores de exclusão a excluir em tópicos de logs compactados. Essa configuração também fornece um limite no tempo em que um consumidor deve concluir uma leitura se começar do deslocamento 0 para garantir que obtenha um instantâneo válido do estágio final. Caso contrário, os marcadores de exclusão a excluir podem ser coletados antes que concluam a digitalização. O valor padrão para essa configuração é 86400000 (24 \$1 60 \$1 60 \$1 1000 ms, ou seja, 1 dia), Padrão do Apache Kafka |
| max.message.bytes | O maior tamanho de lote de logs permitido pelo Kafka (após a compactação, se a compactação estiver ativada). Se ele for aumentado e houver consumidores mais antigos que `0.10.2`, o tamanho de busca dos consumidores também deverá ser aumentado para que possam buscar lotes de logs desse tamanho. Na versão mais recente do formato de mensagem, os registros são sempre agrupados em lotes para obter eficiência. Nas versões anteriores do formato de mensagem, os registros não compactados não são agrupados em lotes, e, nesse caso, esse limite se aplica apenas a um único registro. Pode ser definido por tópico com o nível de tópico `max.message.bytes config`. |
| message.timestamp.after.max.ms | Essa configuração define a diferença permitida entre os carimbos de data e hora da mensagem e do agente. O carimbo de data e hora da mensagem pode ser posterior ou igual ao carimbo do agente, com a diferença máxima permitida determinada pelo valor definido nessa configuração. Se for `message.timestamp.type=CreateTime`, a mensagem será rejeitada se a diferença nos carimbos de data/hora exceder esse limite especificado. Essa configuração será ignorada se for `message.timestamp.type=LogAppendTime`. |
| message.timestamp.before.max.ms | Essa configuração define a diferença de data e hora permitida entre os carimbos de data e hora do agente e da mensagem. O carimbo de data e hora da mensagem pode ser anterior ou igual ao carimbo do agente, com a diferença máxima permitida determinada pelo valor definido nessa configuração. Se for `message.timestamp.type=CreateTime`, a mensagem será rejeitada se a diferença nos carimbos de data/hora exceder esse limite especificado. Essa configuração será ignorada se for `message.timestamp.type=LogAppendTime`. |
| message.timestamp.type | Especifica se o carimbo de data e hora da mensagem é a hora da criação da mensagem ou a hora do acréscimo no log. O valor pode ser `CreateTime` ou `LogAppendTime` |
| min.compaction.lag.ms | O tempo mínimo que uma mensagem permanecerá descompactada no log. Essa configuração é aplicável somente para logs que estejam compactados. O valor padrão para essa configuração é 0, Padrão do Apache Kafka |
| max.compaction.lag.ms | O tempo máximo que uma mensagem permanecerá inelegível para compactação no log. Essa configuração é aplicável somente para logs que estejam compactados. Essa configuração estaria limitada a um intervalo de [7 dias, Long.Max]. O valor padrão para essa configuração é 9223372036854775807, Padrão do Apache Kafka. |
| retention.bytes | Essa configuração controla o tamanho máximo que uma partição (que consiste em segmentos de log) pode crescer antes de descartarmos segmentos de log antigos para liberar espaço se estivermos usando a política de retenção de “exclusão”. Por padrão, não há limite de tamanho, apenas um limite de tempo. Como esse limite é imposto no nível da partição, multiplique-o pelo número de partições para calcular a retenção do tópico em bytes. Além disso, `retention.bytes configuration` opera independentemente das configurações `segment.ms` e `segment.bytes`. Ele também aciona a rolagem de um novo segmento se `retention.bytes` estiver configurado como zero. |
| retention.ms | Essa configuração controla o tempo máximo de retenção de um log antes de descartarmos segmentos de log antigos para liberar espaço se estivermos usando a política de retenção de “exclusão”. Representa um SLA sobre a rapidez com que os consumidores devem ler seus dados. Se estiver definido como `-1`, nenhum limite de tempo será aplicado. E a configuração `retention.ms` opera independentemente das configurações `segment.ms` e `segment.bytes`. Ele também aciona a rolagem de um novo segmento se a condição `retention.ms` for atendida. |
# Configurações somente leitura do agente Express
O Amazon MSK define os valores dessas configurações e as protege contra alterações que possam afetar a disponibilidade do seu cluster. Esses valores podem mudar dependendo da versão do Apache Kafka em execução no cluster, portanto, lembre-se de verificar os valores do seu cluster específico.
A tabela a seguir lista as configurações somente leitura para agentes Express.
| Propriedade | Description | Valor expresso do agente |
| --- | --- | --- |
| broker.id | O ID do agente desse servidor. | 1,2,3... |
| broker.rack | Prateleira do agente. Isso será usado na atribuição de replicação com reconhecimento de rack para tolerância a falhas. Exemplos: `RACK1`, `us-east-1d` | ID AZ ou ID de sub-rede |
| default.replication.factor | Fatores de replicação padrão para todos os tópicos. | 3 |
| fetch.max.bytes | O número máximo de bytes que retornaremos para uma solicitação de busca. | Padrão do Apache Kafka |
| group.max.size | O número máximo de consumidores que um único grupo de consumidores pode acomodar. | Padrão do Apache Kafka |
| inter.broker.listener.name | Nome do receptor usado para comunicação entre agentes. | REPLICATION\$1SECURE ou REPLICATION |
| inter.broker.protocol.version | Especifica qual versão do protocolo entre agentes é usada. | Padrão do Apache Kafka |
| Receptores | Lista de ouvintes - Lista separada por vírgulas dos nomes dos URIs ouvintes e os nomes dos ouvintes. É possível definir advertised.listeners property, mas não a propriedade listeners. | MSK-generated |
| log.message.format.version | Especifique a versão do formato da mensagem que o agente usará para anexar mensagens aos logs. | Padrão do Apache Kafka |
| min.insync.replicas | Quando um produtor define acks como `all` (ou `-1`), o valor em `min.insync.replicas` especifica o número mínimo de réplicas que devem confirmar que uma gravação foi considerada bem-sucedida. Se não for possível atender a esse mínimo, o produtor criará uma exceção (`NotEnoughReplicas` ou `NotEnoughReplicasAfterAppend`). Você pode usar o valor de acks de seu produtor para forçar garantias de durabilidade maiores. Ao definir acks como “todos”. Isso garante que o produtor gere uma exceção se a maioria das réplicas não receber uma gravação. | 2 |
| num.io.threads | Número de threads que o servidor usa para produzir solicitações que podem incluir E/S de discos. (m7g.large, 8), (m7g.xlarge, 8), (m7g.2xlarge, 16), (m7g.4xlarge, 32), (m7g.8xlarge, 64), (m7g.12xlarge, 96), (m7g.16xlarge, 128) | Com base no tipo de instância. =Math.max (8, 2\$1 v) CPUs |
| num.network.threads | O número de threads que o servidor usa para receber solicitações da rede e enviar respostas para a rede. (m7g.large, 8), (m7g.xlarge, 8), (m7g.2xlarge, 8), (m7g.4xlarge, 16), (m7g.8xlarge, 32), (m7g.12xlarge, 48), (m7g.16xlarge, 64) | Com base no tipo de instância. =Math.max (8, v) CPUs |
| replica.fetch.response.max.bytes | O número máximo de bytes esperado para toda a resposta de busca. Os registros são buscados em lotes e, se o primeiro lote de registros na primeira partição não vazia da busca for maior que esse valor, o lote de registros ainda será retornado para garantir o progresso. Esse não é um máximo absoluto. As propriedades message.max.bytes (configuração do agente) ou max.message.bytes (configuração do tópico) especificam o tamanho máximo do lote de logs aceito pelo agente. | Padrão do Apache Kafka |
| request.timeout.ms | A configuração controla o período máximo de espera do cliente pela resposta de uma solicitação. Se a resposta não for recebida antes que o tempo limite termine, o cliente reenviará a solicitação, se necessário, ou a solicitação falhará se as novas tentativas forem esgotadas. | Padrão do Apache Kafka |
| transaction.state.log.min.isr | A configuração min.insync.replicas substituída no tópico de transação. | 2 |
| transaction.state.log.replication.factor | O fator de replicação do tópico de transação. | Padrão do Apache Kafka |
| unclean.leader.election.enable | Permite que as réplicas que não estão no conjunto ISR atuem como líderes em último recurso, mesmo que isso possa resultar em perda de dados. | FALSE |
# Operações de configuração do agente
As configurações do agente do Apache Kafka são estáticas ou dinâmicas. As configurações estáticas exigem a reinicialização do agente para que sejam aplicadas. As configurações dinâmicas não precisam ser reiniciadas pelo agente para que sejam atualizadas. Para obter mais informações sobre as propriedades de configuração e modos de atualização, consulte Configuração do Apache Kafka.
Este tópico descreve como criar configurações personalizadas do MSK e como executar operações nelas. Para obter informações sobre como usar configurações do MSK para criar ou atualizar clusters, consulte [Principais recursos e conceitos do Amazon MSK](operations.md).
**Topics**
+ [Criar uma configuração](msk-configuration-operations-create.md)
+ [Atualizar configuração](msk-configuration-operations-update.md)
+ [Excluir configuração](msk-configuration-operations-delete.md)
+ [Obter metadados de configuração](msk-configuration-operations-describe.md)
+ [Obter detalhes sobre uma revisão de configuração](msk-configuration-operations-describe-revision.md)
+ [Listar as configurações em sua conta para a região atual](msk-configuration-operations-list.md)
+ [Estados das configurações do Amazon MSK](msk-configuration-states.md)
# Criar uma configuração
Este processo descreve como criar configurações personalizadas do Amazon MSK e como executar operações nelas.
1. Crie um arquivo para especificar as propriedades de configuração que você deseja definir e os valores que deseja atribuir a elas. Veja a seguir o conteúdo de um arquivo de configuração de exemplo.
```
auto.create.topics.enable = true
log.roll.ms = 604800000
```
1. Execute o AWS CLI comando a seguir e *config-file-path* substitua pelo caminho para o arquivo em que você salvou sua configuração na etapa anterior.
**nota**
O nome que você escolher para sua configuração deve corresponder ao seguinte regex: "^[0-9A-Za-z][0-9A-Za-z-]\$10,\$1\$1".
```
aws kafka create-configuration --name "ExampleConfigurationName" --description "Example configuration description." --kafka-versions "1.1.1" --server-properties fileb://config-file-path
```
Veja a seguir um exemplo de uma resposta bem-sucedida após a execução desse comando.
```
{
"Arn": "arn:aws:kafka:us-east-1:123456789012:configuration/SomeTest/abcdabcd-1234-abcd-1234-abcd123e8e8e-1",
"CreationTime": "2019-05-21T19:37:40.626Z",
"LatestRevision": {
"CreationTime": "2019-05-21T19:37:40.626Z",
"Description": "Example configuration description.",
"Revision": 1
},
"Name": "ExampleConfigurationName"
}
```
1. O comando anterior retorna um nome do recurso da Amazon (ARN) para sua nova configuração. Salve esse ARN porque você precisará dele ao se referir a essa configuração em outros comandos. Se você perder o ARN da configuração, poderá listar todas as configurações da sua conta para encontrá-lo novamente.
# Atualizar configuração
Este processo descreve como atualizar uma configuração personalizada do Amazon MSK.
1. Crie um arquivo para especificar as propriedades de configuração que você deseja atualizar e os valores que deseja atribuir a elas. Veja a seguir o conteúdo de um arquivo de configuração de exemplo.
```
auto.create.topics.enable = true
min.insync.replicas = 2
```
1. Execute o AWS CLI comando a seguir e *config-file-path* substitua pelo caminho para o arquivo em que você salvou sua configuração na etapa anterior.
*configuration-arn*Substitua pelo ARN que você obteve ao criar a configuração. Se você não tiver salvado o ARN ao criar a configuração, poderá usar o comando `list-configurations` para listar todas as configurações em sua conta. A configuração que você deseja ver na lista aparecerá na resposta. O ARN da configuração também aparece nessa lista.
```
aws kafka update-configuration --arn configuration-arn --description "Example configuration revision description." --server-properties fileb://config-file-path
```
1. Veja a seguir um exemplo de uma resposta bem-sucedida após a execução desse comando.
```
{
"Arn": "arn:aws:kafka:us-east-1:123456789012:configuration/SomeTest/abcdabcd-1234-abcd-1234-abcd123e8e8e-1",
"LatestRevision": {
"CreationTime": "2020-08-27T19:37:40.626Z",
"Description": "Example configuration revision description.",
"Revision": 2
}
}
```
# Excluir configuração
O procedimento a seguir mostra como excluir uma configuração que não esteja anexada a um cluster. Não é possível excluir uma configuração anexada a um cluster.
1. Para executar esse exemplo, *configuration-arn* substitua pelo ARN obtido ao criar a configuração. Se você não tiver salvado o ARN ao criar a configuração, poderá usar o comando `list-configurations` para listar todas as configurações em sua conta. A configuração que você deseja ver na lista aparecerá na resposta. O ARN da configuração também aparece nessa lista.
```
aws kafka delete-configuration --arn configuration-arn
```
1. Veja a seguir um exemplo de uma resposta bem-sucedida após a execução desse comando.
```
{
"arn": " arn:aws:kafka:us-east-1:123456789012:configuration/SomeTest/abcdabcd-1234-abcd-1234-abcd123e8e8e-1",
"state": "DELETING"
}
```
# Obter metadados de configuração
O procedimento a seguir mostra como descrever uma configuração do Amazon MSK para obter metadados sobre ela.
1. O seguinte comando retornará metadados sobre a configuração. Para obter uma descrição detalhada da configuração, execute o `describe-configuration-revision`.
Para executar esse exemplo, *configuration-arn* substitua pelo ARN obtido ao criar a configuração. Se você não tiver salvado o ARN ao criar a configuração, poderá usar o comando `list-configurations` para listar todas as configurações em sua conta. A configuração que você deseja ver na lista aparecerá na resposta. O ARN da configuração também aparece nessa lista.
```
aws kafka describe-configuration --arn configuration-arn
```
1. Veja a seguir um exemplo de uma resposta bem-sucedida após a execução desse comando.
```
{
"Arn": "arn:aws:kafka:us-east-1:123456789012:configuration/SomeTest/abcdabcd-abcd-1234-abcd-abcd123e8e8e-1",
"CreationTime": "2019-05-21T00:54:23.591Z",
"Description": "Example configuration description.",
"KafkaVersions": [
"1.1.1"
],
"LatestRevision": {
"CreationTime": "2019-05-21T00:54:23.591Z",
"Description": "Example configuration description.",
"Revision": 1
},
"Name": "SomeTest"
}
```
# Obter detalhes sobre uma revisão de configuração
Este processo fornece uma descrição detalhada da revisão da configuração do Amazon MSK.
Se você usar o comando `describe-configuration` para descrever uma configuração do MSK, verá os metadados da configuração. Para obter uma descrição da configuração, use o comando `describe-configuration-revision`.
+ Execute o comando a seguir e *configuration-arn* substitua pelo ARN obtido ao criar a configuração. Se você não tiver salvado o ARN ao criar a configuração, poderá usar o comando `list-configurations` para listar todas as configurações em sua conta. A configuração que você deseja ver na lista aparecerá na resposta. O ARN da configuração também aparece nessa lista.
```
aws kafka describe-configuration-revision --arn configuration-arn --revision 1
```
Veja a seguir um exemplo de uma resposta bem-sucedida após a execução desse comando.
```
{
"Arn": "arn:aws:kafka:us-east-1:123456789012:configuration/SomeTest/abcdabcd-abcd-1234-abcd-abcd123e8e8e-1",
"CreationTime": "2019-05-21T00:54:23.591Z",
"Description": "Example configuration description.",
"Revision": 1,
"ServerProperties": "YXV0by5jcmVhdGUudG9waWNzLmVuYWJsZSA9IHRydWUKCgp6b29rZWVwZXIuY29ubmVjdGlvbi50aW1lb3V0Lm1zID0gMTAwMAoKCmxvZy5yb2xsLm1zID0gNjA0ODAwMDAw"
}
```
O valor de `ServerProperties` é codificado em base64. Se você usar um decodificador em base64 (por exemplo, https://www.base64decode.org/) para decodificá-lo manualmente, obterá o conteúdo do arquivo de configuração original usado para criar a configuração personalizada. Nesse caso, você obtém o seguinte:
```
auto.create.topics.enable = true
log.roll.ms = 604800000
```
# Listar as configurações em sua conta para a região atual
Esse processo descreve como listar todas as configurações do Amazon MSK em sua conta para a região atual AWS .
+ Execute o comando a seguir.
```
aws kafka list-configurations
```
Veja a seguir um exemplo de uma resposta bem-sucedida após a execução desse comando.
```
{
"Configurations": [
{
"Arn": "arn:aws:kafka:us-east-1:123456789012:configuration/SomeTest/abcdabcd-abcd-1234-abcd-abcd123e8e8e-1",
"CreationTime": "2019-05-21T00:54:23.591Z",
"Description": "Example configuration description.",
"KafkaVersions": [
"1.1.1"
],
"LatestRevision": {
"CreationTime": "2019-05-21T00:54:23.591Z",
"Description": "Example configuration description.",
"Revision": 1
},
"Name": "SomeTest"
},
{
"Arn": "arn:aws:kafka:us-east-1:123456789012:configuration/SomeTest/abcdabcd-1234-abcd-1234-abcd123e8e8e-1",
"CreationTime": "2019-05-03T23:08:29.446Z",
"Description": "Example configuration description.",
"KafkaVersions": [
"1.1.1"
],
"LatestRevision": {
"CreationTime": "2019-05-03T23:08:29.446Z",
"Description": "Example configuration description.",
"Revision": 1
},
"Name": "ExampleConfigurationName"
}
]
}
```
# Estados das configurações do Amazon MSK
Uma configuração do Amazon MSK pode estar em um dos seguintes estados. Para realizar uma operação em uma configuração, a configuração deve estar no estado `ACTIVE` ou `DELETE_FAILED`:
+ `ACTIVE`
+ `DELETING`
+ `DELETE_FAILED`
# Rebalanceamento inteligente para clusters
O Amazon MSK fornece rebalanceamento inteligente para todos os novos clusters provisionados pelo MSK com corretores Express. Esse recurso gerencia automaticamente a distribuição de partições e as operações de escalabilidade de clusters, eliminando a necessidade de ferramentas de terceiros. O rebalanceamento inteligente reequilibra automaticamente as partições quando você aumenta ou diminui a escala dos clusters. Ele também monitora continuamente a integridade do seu cluster em busca de desequilíbrio ou sobrecarga de recursos e redistribui a carga de trabalho.
O rebalanceamento inteligente fornece operações de escalabilidade rápidas que são concluídas em 30 minutos e não afetam a disponibilidade do cluster durante o escalonamento. Ele é ativado por padrão para todos os novos clusters provisionados baseados no MSK Express e funciona com o limite máximo de partição recomendado de 20.000 partições por agente. Além disso, esse recurso está disponível sem custo adicional e não requer nenhuma configuração.
A partir de 20 de novembro de 2025, o Intelligent Rebalancing está disponível em todas as AWS regiões onde os corretores do Amazon MSK Express são suportados.
**Topics**
+ [Como funciona o rebalanceamento inteligente](#how-intelligent-rebalancing-works)
+ [Monitorando métricas inteligentes de rebalanceamento](#intelligent-rebalancing-metrics)
+ [Considerações para usar o rebalanceamento inteligente](#intelligent-rebalancing-considerations)
+ [Aumentando e diminuindo a escala dos clusters do Amazon MSK com uma única operação](intelligent-rebalancing-scaling-clusters.md)
+ [Rebalanceamento em estado estável para clusters Amazon MSK](intelligent-rebalancing-self-balancing-paritions.md)
## Como funciona o rebalanceamento inteligente
O rebalanceamento inteligente é ativado por padrão para todos os novos clusters provisionados pela MSK com corretores Express. Ele inclui suporte para as seguintes situações:
+ **Aumentar e reduzir a escala**: permite adicionar ou remover corretores aos seus clusters baseados no MSK Express com um único clique. Depois de especificar os agentes a serem adicionados ou removidos, o rebalanceamento inteligente redistribui automaticamente as partições na nova configuração do cluster com base nas melhores práticas internas. AWS
+ **Rebalanceamento em estado estacionário**: em estado estacionário, esse recurso monitora continuamente a integridade do seu cluster e reequilibra automaticamente as partições quando:
+ A utilização de recursos se torna distorcida entre os corretores.
+ Os corretores ficam superprovisionados ou subutilizados.
+ Novos corretores são adicionados ou corretores existentes são removidos.
**nota**
Se o rebalanceamento inteligente estiver ativado, você não poderá usar ferramentas de terceiros, como o Cruise Control, para rebalancear partições. Primeiro, você deve pausar o rebalanceamento inteligente para usar a API de reatribuição de partições fornecida por essas ferramentas de terceiros.
Você pode usar esse recurso no console do Amazon MSK. Você também pode usar esse recurso usando AWS CLI o Amazon MSK APIs ou AWS SDK e. AWS CloudFormation Para obter mais informações, consulte [Escalando clusters do Amazon MSK](intelligent-rebalancing-scaling-clusters.md) e [Reequilíbrio em estado estacionário](intelligent-rebalancing-self-balancing-paritions.md).
## Monitorando métricas inteligentes de rebalanceamento
Você pode monitorar o status das operações de rebalanceamento inteligente em andamento e históricas usando as seguintes métricas da Amazon CloudWatch :
+ `RebalanceInProgress`: essa métrica é publicada a cada minuto com um valor de 1 quando o rebalanceamento está em andamento e 0 caso contrário.
+ `UnderProvisioned`: indica que um cluster está subprovisionado no momento e que nenhum rebalanceamento de partição pode ser executado. Você precisa adicionar mais corretores ou ampliar o tipo de instância do seu cluster.
Para obter informações sobre o monitoramento de um cluster provisionado pelo MSK, consulte e. [](monitoring.md) [](cloudwatch-metrics.md)
## Considerações para usar o rebalanceamento inteligente
+ O suporte para rebalanceamento inteligente está disponível somente para novos clusters provisionados pela MSK com corretores Express.
+ Para reatribuição automática de partições, o suporte máximo para até 20.000 partições por corretor está disponível.
+ Você não pode usar ferramentas de reatribuição de partições APIs ou de rebalanceamento de terceiros quando o rebalanceamento inteligente está ativado. Para usar essas ferramentas APIs ou ferramentas de terceiros, você deve primeiro pausar o rebalanceamento inteligente do seu cluster baseado no MSK Express.
# Aumentando e diminuindo a escala dos clusters do Amazon MSK com uma única operação
Com o rebalanceamento inteligente, você pode escalar seus clusters para cima ou para baixo editando a contagem de agentes em seus clusters em uma única ação. Você pode fazer isso no console do Amazon MSK ou usando o AWS CLI Amazon MSK APIs ou AWS SDK e. AWS CloudFormation Quando você altera a contagem de corretores, o Amazon MSK faz o seguinte:
+ Distribui partições automaticamente para novos corretores.
+ Move as partições dos corretores que estão sendo removidos.
À medida que você aumenta e diminui a escala de seus clusters, a disponibilidade dos clusters para que os clientes produzam e consumam dados permanece inalterada.
**Topics**
------
#### [ Scaling clusters using Console de gerenciamento da AWS ]
1. Abra o console Amazon MSK em [https://console.aws.amazon.com/msk/casa? region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/).
1. Na página **Clusters**, escolha um cluster baseado no Express recém-criado. Para obter informações sobre a criação de um cluster provisionado baseado no Express, consulte. [Etapa 1: criar um cluster do MSK Provisioned](create-cluster.md)
1. Na lista suspensa **Ações**, escolha **Editar número de** corretores.
1. Na página **Editar número de corretores por zona**, faça o seguinte:
+ Para adicionar mais corretores ao seu cluster, escolha **Adicionar corretores a cada zona de disponibilidade** e, em seguida, insira o número de corretores que você deseja adicionar.
+ Para remover agentes do seu cluster, escolha **Remover um agente de cada zona de disponibilidade**.
1. Escolha **Salvar alterações**.
------
#### [ Scaling clusters using AWS CLI ]
Você pode escalar seus clusters para cima ou para baixo editando a contagem de corretores. Para fazer isso no AWS CLI, use o [update-broker-count](https://docs.aws.amazon.com/cli/latest/reference/kafka/update-broker-count.html)comando, conforme mostrado no exemplo a seguir. Nesse comando, especifique o número de corretores que você deseja em seu cluster no `target-broker-count` parâmetro.
```
aws msk update-broker-count --cluster-arn arn:aws:kafka:us-east-1:123456789012:cluster/myCluster/abcd1234-5678-90ef-ghij-klmnopqrstuv-1 --current-version ABCDEF1GHIJK0L --target-broker-count 6
```
------
#### [ Scaling clusters using AWS SDK ]
Você pode aumentar ou diminuir seus clusters editando programaticamente a contagem de corretores. Para fazer isso usando o AWS SDK, use a [UpdateBrokerCount](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-nodes-count.html#UpdateBrokerCount)API, conforme mostrado no exemplo a seguir. Para o `TargetNumberOfBrokerNodes` parâmetro, especifique o número de corretores que você deseja em seu cluster.
```
update_broker_count_response = client.update_broker_count(
ClusterArn='arn:aws:kafka:us-east-1:123456789012:cluster/myCluster/abcd1234-5678-90ef-ghij-klmnopqrstuv-1',
CurrentVersion='ABCDEF1GHIJK0L',
TargetNumberOfBrokerNodes=6
)
```
------
# Rebalanceamento em estado estável para clusters Amazon MSK
O rebalanceamento em estado estacionário faz parte do recurso de rebalanceamento inteligente, que é ativado por padrão para todos os novos clusters provisionados pela MSK com corretores Express. Conforme você aumenta ou diminui a escala de seus clusters, o Amazon MSK gerencia automaticamente o gerenciamento de partições distribuindo partições para novos agentes e movendo partições de corretores que devem ser removidos. Para garantir a distribuição ideal da carga de trabalho entre os corretores, o rebalanceamento inteligente usa as melhores práticas do Amazon MSK para determinar limites para iniciar automaticamente o rebalanceamento de seus corretores.
Você pode pausar e retomar o reequilíbrio em estado estacionário quando necessário. O rebalanceamento em estado estável monitora continuamente seu cluster e faz o seguinte:
+ Monitora o uso de recursos do corretor (CPU, rede, armazenamento).
+ Ajusta o posicionamento da partição automaticamente sem nenhum impacto na disponibilidade dos dados.
+ Conclui as operações de rebalanceamento até 180 vezes mais rápido para corretores Express em comparação com corretores Standard.
+ Mantém o desempenho do cluster.
**Topics**
------
#### [ Pause and resume steady state rebalancing in Console de gerenciamento da AWS ]
1. Abra o console Amazon MSK em [https://console.aws.amazon.com/msk/casa? region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/).
1. Na página **Clusters**, escolha um cluster baseado no Express. Para obter informações sobre a criação de um cluster provisionado baseado no Express, consulte. [Etapa 1: criar um cluster do MSK Provisioned](create-cluster.md)
1. **Na página de detalhes do cluster, verifique se o status do **rebalanceamento inteligente** é Ativo.** Se o rebalanceamento inteligente não estiver disponível ou o status for **Pausado**, crie um novo cluster baseado no Express.
1. Na lista suspensa **Ações**, escolha **Editar rebalanceamento inteligente**.
1. Na página **Editar rebalanceamento inteligente**, faça o seguinte:
1. Escolha **Pausado**.
1. Escolha **Salvar alterações**.
------
#### [ Pause and resume steady state rebalancing using AWS CLI ]
Para definir o status de rebalanceamento de um cluster para **ACTIVE** usar o AWS CLI, use o comando [update-rebalancing](https://docs.aws.amazon.com/cli/latest/reference/kafka/update-rebalancing.html), conforme mostrado no exemplo a seguir. Nesse comando, especifique o status com o `rebalancing` parâmetro.
```
aws msk update-rebalancing --cluster-arn arn:aws:kafka:us-east-1:123456789012:cluster/myCluster/abcd1234-5678-90ef-ghij-klmnopqrstuv-1 --current-version ABCDEF1GHIJK0L --rebalancing "{\"Rebalancing\":{\"Status\":\"ACTIVE\"}}"
```
------
#### [ Pause and resume steady state rebalancing using AWS SDK ]
Você também pode definir o status de rebalanceamento de um cluster usando a [UpdateRebalancingRequest](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-rebalancing.html#UpdateRebalancing)API para modificar programaticamente a contagem de agentes. Os exemplos a seguir mostram como definir o status de rebalanceamento como e. **ACTIVE** **PAUSED**
```
final UpdateRebalancingRequest updateRebalancingRequest = new UpdateRebalancingRequest()
.withClusterArn(arn:aws:kafka:us-east-1:123456789012:cluster/myCluster/abcd1234-5678-90ef-ghij-klmnopqrstuv-1)
.withCurrentVersion(ABCDEF1GHIJK0L)
.withRebalancing(new Rebalancing().withStatus("ACTIVE"));
```
```
final UpdateRebalancingRequest updateRebalancingRequest = new UpdateRebalancingRequest()
.withClusterArn(arn:aws:kafka:us-east-1:123456789012:cluster/myCluster/abcd1234-5678-90ef-ghij-klmnopqrstuv-1)
.withCurrentVersion(ABCDEF1GHIJK0L)
.withRebalancing(new Rebalancing().withStatus("PAUSED"));
```
------
# Aplicação de patches em clusters do MSK Provisioned
Periodicamente, o Amazon MSK atualiza o software dos agentes de seu cluster. A manutenção inclui atualizações planejadas ou reparos não planejados. A manutenção planejada inclui atualizações do sistema operacional, de segurança e outras atualizações de software necessárias para manter a integridade, a segurança e o desempenho do seu cluster. Realizamos manutenções não planejadas para resolver a degradação repentina da infraestrutura. Realizamos manutenção em agentes Standard e Express, mas as experiências são diferentes.
## Aplicação de patches em agentes Standard
As atualizações de agentes Standard não terão impacto nas gravações e leituras de aplicações se você seguir as [práticas recomendadas](bestpractices.md).
O Amazon MSK usa atualizações contínuas de software para manter a alta disponibilidade dos clusters. Durante esse processo, os agentes são reiniciados um de cada vez e o Kafka transfere automaticamente a liderança para outro agente on-line. Quando você visualiza as operações de cluster no Console de gerenciamento da AWS ou por meio do `DescribeClusterOperation` e `ListClusterOperations` APIs, essas operações de manutenção aparecem com um tipo de operação de`SECURITY_PATCHING`. Os clientes Kafka têm mecanismos integrados para detectar automaticamente a mudança na liderança das partições e continuar gravando e lendo dados em um cluster do MSK. Siga [Práticas recomendadas para clientes Apache Kafka](bestpractices-kafka-client.md) para que seu cluster funcione sem problemas em todos os momentos, inclusive durante a aplicação de patches.
Depois que um agente fica offline, é normal ver erros transitórios de desconexão nos clientes. Você também observará por um breve período (até dois minutos, normalmente menos) alguns picos na latência de leitura e gravação de p99 (normalmente milissegundos altos, até aproximadamente dois segundos). Esses picos são esperados e são causados pela reconexão do cliente com um novo agente líder. Isso não afeta a produção ou o consumo e será resolvido após a reconexão. Para obter mais informações, consulte [Agente offline e failover do cliente](https://docs.aws.amazon.com/msk/latest/developerguide/troubleshooting-offlinebroker-clientfailover.html).
Você também observará um aumento na métrica `UnderReplicatedPartitions`, o que é esperado, pois as partições do agente que foi desligado não estão mais replicando dados. Isso não afeta as gravações e leituras das aplicações, pois as réplicas dessas partições hospedadas em outros agentes agora atendem às solicitações.
Após a atualização do software, quando o agente volta a ficar on-line, ele precisa “se atualizar” sobre as mensagens produzidas enquanto estava offline. Durante essa atualização, você também poderá observar um aumento no uso do throughput do volume e da CPU. Isso não deverá ter impacto nas gravações e leituras no cluster se você tiver recursos suficientes de CPU, memória, rede e volume nos agentes.
## Aplicação de patches em agentes Express
Não há janelas de manutenção para agentes Express. O Amazon MSK atualiza automaticamente seu cluster de forma contínua e distribuída por tempo, o que significa que você pode esperar reinicializações ocasionais e únicas de agentes ao longo do mês. Isso garante que você não precise fazer planos ou acomodações em torno de janelas únicas de manutenção em todo o cluster. Como sempre, o tráfego permanecerá ininterrupto durante a reinicialização do agente, pois a liderança mudará para outros agentes que continuarão atendendo às solicitações. Quando você visualiza as operações de cluster no Console de gerenciamento da AWS ou por meio do `DescribeClusterOperation` e `ListClusterOperations` APIs, essas operações de manutenção aparecem com um tipo de operação de`BROKER_UPDATE`.
Os agentes Express já estão com as configurações de melhores práticas e barreiras de proteção que tornam seu cluster resiliente às mudanças de carga que podem ocorrer durante a manutenção. O Amazon MSK define cotas de throughput em seus agentes Express para mitigar o impacto da sobrecarga do seu cluster, o que poderia causar problemas durante a reinicialização do agente. Essas melhorias eliminam a necessidade de notificações antecipadas, planejamento e janelas de manutenção quando você usa agentes Express.
Os agentes Express sempre replicam seus dados de três maneiras para que seus clientes façam o failover automaticamente durante as reinicializações. Você não precisa se preocupar com a indisponibilidade dos tópicos devido ao fator de replicação definido como 1 ou 2. E o catch up de um agente Express reiniciado é mais rápido do que em agentes Standard. A velocidade de aplicação de patches mais rápida nos agentes Express significa que haverá uma interrupção mínima no planejamento de qualquer atividade do ambiente de gerenciamento que você possa ter programado para seu cluster.
Como acontece com todas as aplicações Apache Kafka, ainda há um contrato cliente-servidor compartilhado para clientes que se conectam aos agentes Express. Ainda é fundamental configurar seus clientes para lidar com o failover na liderança entre agentes. Siga [Práticas recomendadas para clientes Apache Kafka](bestpractices-kafka-client.md) para que seu cluster funcione sem problemas em todos os momentos, inclusive durante a aplicação de patches. Depois que um agente reinicia, é normal ver erros de desconexão [ transitórios nos clientes](troubleshooting-offlinebroker-clientfailover.md). Isso não afetará sua produção e consumo, pois os agentes seguidores assumirão a liderança da partição. Seus clientes do Apache Kafka farão automaticamente o failover e começarão a enviar solicitações aos novos agentes líderes.
# Agente offline e failover do cliente
O Kafka permite um agente offline. Um único agente offline em um cluster íntegro e balanceado seguindo as práticas recomendadas não terá impacto nem causará falhas na produção ou no consumo. Isso ocorre porque outro agente assumirá a liderança da partição e a biblioteca do cliente Kafka fará o failover automaticamente e começará a enviar solicitações aos novos agentes líderes.
**Contrato entre servidores e clientes**
Isso resulta em um contrato compartilhado entre a biblioteca do cliente e o comportamento do servidor. O servidor deve atribuir com êxito um ou mais novos líderes e o cliente deve mudar de agente para enviar solicitações aos novos líderes em tempo hábil.
O Kafka usa exceções para controlar esse fluxo:
**Um exemplo de procedimento**
1. O agente A entra em um estado offline.
1. O cliente Kafka recebe uma exceção (normalmente uma desconexão de rede ou not\$1leader\$1for\$1partition).
1. Essas exceções acionam o cliente Kafka para que atualize os metadados para ter ciência dos líderes mais recentes.
1. O cliente Kafka retoma o envio de solicitações aos novos líderes de partições em outros agentes.
Esse processo normalmente leva menos de dois segundos com o cliente Java fornecido e as configurações padrão. Os erros do lado do cliente são redundantes e repetitivos, mas não são motivo de preocupação, conforme indicado pelo nível “WARN”.
**Exemplo: exceção 1**
`10:05:25.306 [kafka-producer-network-thread | producer-1] WARN o.a.k.c.producer.internals.Sender - [Producer clientId=producer-1] Got error produce response with correlation id 864845 on topic-partition msk-test-topic-1-0, retrying (2147483646 attempts left). Error: NETWORK_EXCEPTION. Error Message: Disconnected from node 2`
**Exemplo: exceção 2**
`10:05:25.306 [kafka-producer-network-thread | producer-1] WARN o.a.k.c.producer.internals.Sender - [Producer clientId=producer-1] Received invalid metadata error in produce request on partition msk-test-topic-1-41 due to org.apache.kafka.common.errors.NotLeaderOrFollowerException: For requests intended only for the leader, this error indicates that the broker is not the current leader. For requests intended for any replica, this error indicates that the broker is not a replica of the topic partition.. Going to request metadata update now"`
Os clientes Kafka resolverão automaticamente esses erros, normalmente em um segundo e, no máximo, três segundos. Isso se apresenta como produce/consume latência de p99 nas métricas do lado do cliente (normalmente altos milissegundos na década de 100). Um período maior do que isso normalmente indica um problema com a configuração do cliente ou com a carga do controlador do servidor. Consulte a seção de solução de problemas.
Um failover com êxito pode ser verificado ao conferir o aumento das métricas `BytesInPerSec` e `LeaderCount` e o aumento de outros agentes, o que prova que o tráfego e a liderança se moveram conforme o esperado. Você também observará um aumento na métrica `UnderReplicatedPartitions`, o que é esperado quando as réplicas estão offline com o agente de desligamento.
**Solução de problemas**
O fluxo acima pode ser interrompido pela quebra do contrato cliente-servidor. Os motivos mais comuns para o problema incluem:
+ Configuração incorreta ou uso incorreto das bibliotecas do cliente Kafka.
+ Comportamentos padrão inesperados e bugs com bibliotecas de clientes terceiros.
+ Controlador sobrecarregado, resultando em uma atribuição mais lenta do líder de partição.
+ Um novo controlador está sendo escolhido, resultando em uma atribuição mais lenta do líder de partição.
Para garantir um comportamento correto para lidar com failover de liderança, recomendamos:
+ As [práticas recomendadas](https://docs.aws.amazon.com/msk/latest/developerguide/bestpractices.html) do servidor devem ser seguidas para garantir que o agente controlador seja escalado adequadamente para evitar a demora na atribuição de liderança.
+ As bibliotecas do cliente devem ter as novas tentativas habilitadas para garantir que o cliente trate o failover.
+ As bibliotecas de cliente devem ter retry.backoff.ms configurado (padrão 100) para evitar tempestades. connection/request
+ As bibliotecas do cliente devem definir request.timeout.ms e delivery.timeout.ms com valores em linha com o SLA das aplicações. Valores mais altos resultarão em um failover mais lento para determinados tipos de falha.
+ As bibliotecas do cliente devem garantir que bootstrap.servers contenha pelo menos três agentes aleatórios para evitar um impacto na disponibilidade na descoberta inicial.
+ Algumas bibliotecas de clientes têm um nível inferior ao de outras e esperam que o próprio desenvolvedor da aplicação implemente a lógica de repetição e o tratamento de exceções. Consulte a documentação específica da biblioteca do cliente para ver um exemplo de uso e certifique-se de que a reconnect/retry lógica correta seja seguida.
+ Recomendamos monitorar a latência do lado do cliente quanto a produtos, à contagem com êxito de solicitações e à contagem de erros que não podem ser repetidos.
+ Observamos que as bibliotecas mais antigas golang e ruby de terceiros permanecem redundantes durante todo o período offline do agente, apesar de as solicitações de produção e consumo não serem afetadas. Recomendamos que você sempre monitore as métricas em nível corporativo, além de solicitar métricas de êxito e erros, para determinar se há impacto real versus ruído nos logs.
+ Os clientes não devem alertar sobre exceções transitórias de network/not\$1leader, pois elas são normais, não impactam e são esperadas como parte do protocolo kafka.
+ Os clientes não devem se alarmar, UnderReplicatedPartitions pois são normais, não impactantes e esperados durante um único corretor off-line.
# Segurança no Amazon MSK
A segurança na nuvem AWS é a maior prioridade. Como AWS cliente, você se beneficia de uma arquitetura de data center e rede criada para atender aos requisitos das organizações mais sensíveis à segurança.
A segurança é uma responsabilidade compartilhada entre você AWS e você. O [Modelo de Responsabilidade Compartilhada](https://aws.amazon.com/compliance/shared-responsibility-model/) descreve isso como segurança *da* nuvem e segurança *na* nuvem:
+ **Segurança da nuvem** — AWS é responsável por proteger a infraestrutura que executa AWS os serviços na AWS nuvem. AWS também fornece serviços que você pode usar com segurança. Auditores terceirizados testam e verificam regularmente a eficácia de nossa segurança como parte dos Programas de Conformidade Programas de [AWS](https://aws.amazon.com/compliance/programs/) de . Para saber mais sobre os programas de conformidade aplicáveis ao Amazon Managed Streaming for Apache Kafka, consulte [Serviços da Amazon Web Services no escopo por programa de conformidade](https://aws.amazon.com/compliance/services-in-scope/).
+ **Segurança na nuvem** — Sua responsabilidade é determinada pelo AWS serviço que você usa. Você também é responsável por outros fatores, incluindo a confidencialidade de seus dados, os requisitos da sua empresa e as leis e normas aplicáveis.
Esta documentação ajuda você a entender como aplicar o modelo de responsabilidade compartilhada ao usar o Amazon MSK. Os tópicos a seguir mostram como configurar o Amazon MSK para atender aos seus objetivos de segurança e compatibilidade. Saiba também como usar outros serviços da Amazon Web Services que ajudam você a monitorar e proteger seus recursos do Amazon MSK.
**Topics**
+ [Proteção de dados no Amazon Managed Streaming for Apache Kafka](data-protection.md)
+ [Autenticação e autorização para Amazon MSK APIs](security-iam.md)
+ [Autenticação e autorização para o Apache Kafka APIs](kafka_apis_iam.md)
+ [Alterar o grupo de segurança do cluster no Amazon MSK](change-security-group.md)
+ [Controle o acesso aos ZooKeeper nós do Apache em seu cluster Amazon MSK](zookeeper-security.md)
+ [Validação de conformidade do Amazon Managed Streaming for Apache Kafka](MSK-compliance.md)
+ [Resiliência no Amazon Managed Streaming for Apache Kafka](disaster-recovery-resiliency.md)
+ [Segurança de infraestrutura no Amazon Managed Streaming for Apache Kafka](infrastructure-security.md)
# Proteção de dados no Amazon Managed Streaming for Apache Kafka
O modelo de [responsabilidade AWS compartilhada O modelo](https://aws.amazon.com/compliance/shared-responsibility-model/) se aplica à proteção de dados no Amazon Managed Streaming for Apache Kafka. Conforme descrito neste modelo, AWS é responsável por proteger a infraestrutura global que executa todos os Nuvem AWS. Você é responsável por manter o controle sobre o conteúdo hospedado nessa infraestrutura. Você também é responsável pelas tarefas de configuração e gerenciamento de segurança dos Serviços da AWS que usa. Para saber mais sobre a privacidade de dados, consulte as [Data Privacy FAQ](https://aws.amazon.com/compliance/data-privacy-faq/). Para saber mais sobre a proteção de dados na Europa, consulte a postagem do blog [AWS Shared Responsibility Model and RGPD](https://aws.amazon.com/blogs/security/the-aws-shared-responsibility-model-and-gdpr/) no *Blog de segurança da AWS *.
Para fins de proteção de dados, recomendamos que você proteja Conta da AWS as credenciais e configure usuários individuais com Centro de Identidade do AWS IAM ou AWS Identity and Access Management (IAM). Dessa maneira, cada usuário receberá apenas as permissões necessárias para cumprir suas obrigações de trabalho. Recomendamos também que você proteja seus dados das seguintes formas:
+ Use uma autenticação multifator (MFA) com cada conta.
+ Use SSL/TLS para se comunicar com AWS os recursos. Exigimos TLS 1.2 e recomendamos TLS 1.3.
+ Configure a API e o registro de atividades do usuário com AWS CloudTrail. Para obter informações sobre o uso de CloudTrail trilhas para capturar AWS atividades, consulte Como [trabalhar com CloudTrail trilhas](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-trails.html) no *Guia AWS CloudTrail do usuário*.
+ Use soluções de AWS criptografia, juntamente com todos os controles de segurança padrão Serviços da AWS.
+ Use serviços gerenciados de segurança avançada, como o Amazon Macie, que ajuda a localizar e proteger dados sensíveis armazenados no Amazon S3.
+ Se você precisar de módulos criptográficos validados pelo FIPS 140-3 ao acessar AWS por meio de uma interface de linha de comando ou de uma API, use um endpoint FIPS. Para saber mais sobre os endpoints FIPS disponíveis, consulte [Federal Information Processing Standard (FIPS) 140-3](https://aws.amazon.com/compliance/fips/).
É altamente recomendável que nunca sejam colocadas informações confidenciais ou sensíveis, como endereços de e-mail de clientes, em tags ou campos de formato livre, como um campo **Nome**. Isso inclui quando você trabalha com o Amazon MSK ou outro Serviços da AWS usando o console, a API ou AWS SDKs. AWS CLI Quaisquer dados inseridos em tags ou em campos de texto de formato livre usados para nomes podem ser usados para logs de faturamento ou de diagnóstico. Se você fornecer um URL para um servidor externo, é fortemente recomendável que não sejam incluídas informações de credenciais no URL para validar a solicitação nesse servidor.
**Topics**
+ [Criptografia do Amazon MSK](msk-encryption.md)
+ [Conceitos básicos sobre criptografia do Amazon MSK](msk-working-with-encryption.md)
+ [Use o Amazon MSK APIs com endpoints de interface VPC](privatelink-vpc-endpoints.md)
# Criptografia do Amazon MSK
O Amazon MSK fornece opções de criptografia de dados que você pode usar para atender a requisitos rigorosos de gerenciamento de dados. É necessário renovar a cada 13 meses os certificados que o Amazon MSK usa para criptografia. O Amazon MSK renova automaticamente esses certificados para todos os clusters. Os clusters de agentes Express permanecem no estado `ACTIVE` quando o Amazon MSK inicia a operação de atualização de certificado. Para clusters de agentes Standard, o Amazon MSK define o estado do cluster como `MAINTENANCE` quando inicia a operação de atualização de certificado. Quando a atualização é concluída, o estado é definido novamente como `ACTIVE`. Enquanto um cluster está na operação de atualização de certificado, você pode continuar a produzir e consumir dados, mas não pode executar nenhuma operação de atualização nele.
## Criptografia do Amazon MSK em repouso
O Amazon MSK se integra ao [AWS Key Management Service](https://docs.aws.amazon.com/kms/latest/developerguide/) (KMS) para oferecer uma criptografia transparente no lado do servidor. O Amazon MSK sempre criptografa seus dados em repouso. Ao criar um cluster do MSK, você pode especificar a AWS KMS key que deseja que o Amazon MSK use para criptografar seus dados em repouso. Se você não especificar uma chave do KMS, o Amazon MSK criará uma [Chave gerenciada pela AWS](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#aws-managed-cmk) para você e a usará em seu nome. Para ter mais informações sobre as chaves do KMS, consulte [AWS KMS keys](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#kms_keys) no *Guia do desenvolvedor do AWS Key Management Service *.
## Criptografia do Amazon MSK em trânsito
O Amazon MSK usa TLS 1.2. Por padrão, ele criptografa os dados em trânsito entre os agentes do seu cluster do MSK. É possível substituir esse padrão no momento de criação do cluster.
Para a comunicação entre clientes e agentes, é necessário especificar uma destas três configurações:
+ Permitir somente dados criptografados por TLS. Essa é a configuração padrão.
+ Permitir dados não criptografados e dados criptografados por TLS.
+ Permitir apenas dados não criptografados.
Os corretores do Amazon MSK usam certificados públicos AWS Certificate Manager . Portanto, qualquer armazenamento confiável que confie no Amazon Trust Services também confia nos agentes do Amazon MSK.
Embora seja altamente recomendável habilitar a criptografia em trânsito, isso pode acrescentar sobrecarga à CPU e alguns milissegundos de latência. Contudo, a maioria dos casos de uso não é afetada por essas diferenças, e a magnitude do impacto depende da configuração do cluster, dos clientes e do perfil de uso.
# Conceitos básicos sobre criptografia do Amazon MSK
Ao criar um cluster do MSK, você pode especificar configurações de criptografia no formato JSON. Veja um exemplo do a seguir:
```
{
"EncryptionAtRest": {
"DataVolumeKMSKeyId": "arn:aws:kms:us-east-1:123456789012:key/abcdabcd-1234-abcd-1234-abcd123e8e8e"
},
"EncryptionInTransit": {
"InCluster": true,
"ClientBroker": "TLS"
}
}
```
Para `DataVolumeKMSKeyId`, é possível especificar uma [chave gerenciada pelo cliente](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#customer-cmk) ou a Chave gerenciada pela AWS para o MSK na sua conta (`alias/aws/kafka`). Se você não especificar`EncryptionAtRest`, o Amazon MSK ainda criptografa seus dados em repouso sob o. Chave gerenciada pela AWS Para determinar qual chave o cluster está usando, envie uma solicitação `GET` ou invoque a operação de API `DescribeCluster`.
Para `EncryptionInTransit`, o valor padrão de `InCluster` é verdadeiro, mas será possível defini-lo como falso se não quiser que o Amazon MSK criptografe seus dados conforme eles passam pelos agentes.
Para especificar o modo de criptografia para dados em trânsito entre clientes e agentes, defina `ClientBroker` como um dos três valores: `TLS`, `TLS_PLAINTEXT` ou `PLAINTEXT`.
**Topics**
+ [Especificar as configurações de criptografia ao criar um cluster do Amazon MSK](msk-working-with-encryption-cluster-create.md)
+ [Testar a criptografia TLS do Amazon MSK](msk-working-with-encryption-test-tls.md)
# Especificar as configurações de criptografia ao criar um cluster do Amazon MSK
Este processo descreve como especificar as configurações de criptografia ao criar um cluster do Amazon MSK.
**Especificar as configurações de criptografia ao criar um cluster**
1. Salve o conteúdo do exemplo anterior em um arquivo e dê ao arquivo qualquer nome que desejar. Por exemplo, nomeie-o como `encryption-settings.json`.
1. Execute o comando `create-cluster` e use a opção `encryption-info` para apontar para o arquivo onde você salvou a configuração JSON. Veja um exemplo do a seguir: *\$1YOUR MSK VERSION\$1*Substitua por uma versão que corresponda à versão do cliente Apache Kafka. Para obter informações sobre como encontrar a versão de cluster do MSK, consulte [Determinação da versão do cluster do MSK](create-topic.md#find-msk-cluster-version). Esteja ciente de que usar uma versão do cliente Apache Kafka que não seja igual à sua versão de cluster do MSK pode resultar em corrupção, perda e tempo de inatividade dos dados do Apache Kafka.
```
aws kafka create-cluster --cluster-name "ExampleClusterName" --broker-node-group-info file://brokernodegroupinfo.json --encryption-info file://encryptioninfo.json --kafka-version "{YOUR MSK VERSION}" --number-of-broker-nodes 3
```
Veja a seguir um exemplo de uma resposta bem-sucedida após a execução desse comando.
```
{
"ClusterArn": "arn:aws:kafka:us-east-1:123456789012:cluster/SecondTLSTest/abcdabcd-1234-abcd-1234-abcd123e8e8e",
"ClusterName": "ExampleClusterName",
"State": "CREATING"
}
```
# Testar a criptografia TLS do Amazon MSK
Este processo descreve como testar a criptografia TLS no Amazon MSK.
**Como testar a criptografia por TLS**
1. Crie uma máquina de cliente seguindo as orientações em [Etapa 3: criar uma máquina cliente](create-client-machine.md).
1. Instale o Apache Kafka na máquina de cliente.
1. Neste exemplo, o armazenamento confiável da JVM para se comunicar com o cluster do MSK. Para fazer isso, crie primeiramente uma pasta chamada `/tmp` na máquina cliente. Depois, acesse a pasta `bin` da instalação do Apache Kafka e execute o comando a seguir. (Seu caminho da JVM pode ser diferente.)
```
cp /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.201.b09-0.amzn2.x86_64/jre/lib/security/cacerts /tmp/kafka.client.truststore.jks
```
1. Enquanto ainda estiver na pasta `bin` da instalação do Apache Kafka na máquina cliente, crie um arquivo de texto chamado `client.properties` com o conteúdo a seguir.
```
security.protocol=SSL
ssl.truststore.location=/tmp/kafka.client.truststore.jks
```
1. Execute o comando a seguir em uma máquina que tenha o AWS CLI instalado, *clusterARN* substituindo-o pelo ARN do seu cluster.
```
aws kafka get-bootstrap-brokers --cluster-arn clusterARN
```
Um resultado bem-sucedido tem a aparência a seguir. Salve este resultado porque você precisará dele na próxima etapa.
```
{
"BootstrapBrokerStringTls": "a-1.example.g7oein.c2.kafka.us-east-1.amazonaws.com:0123,a-3.example.g7oein.c2.kafka.us-east-1.amazonaws.com:0123,a-2.example.g7oein.c2.kafka.us-east-1.amazonaws.com:0123"
}
```
1. Execute o comando a seguir, *BootstrapBrokerStringTls* substituindo-o por um dos endpoints do broker que você obteve na etapa anterior.
```
/bin/kafka-console-producer.sh --broker-list BootstrapBrokerStringTls --producer.config client.properties --topic TLSTestTopic
```
1. Abra uma nova janela de comando e conecte-se à mesma máquina cliente. Depois, execute o comando a seguir para criar um consumidor de console.
```
/bin/kafka-console-consumer.sh --bootstrap-server BootstrapBrokerStringTls --consumer.config client.properties --topic TLSTestTopic
```
1. Na janela do produtor, digite uma mensagem de texto seguida de um retorno e procure a mesma mensagem na janela do consumidor. O Amazon MSK criptografou essa mensagem em trânsito.
Para obter mais informações sobre como configurar clientes do Apache Kafka para trabalhar com dados criptografados, consulte [Configurar clientes do Kafka](https://kafka.apache.org/documentation/#security_configclients).
# Use o Amazon MSK APIs com endpoints de interface VPC
Você pode usar uma interface VPC Endpoint, alimentada por AWS PrivateLink, para evitar que o tráfego entre sua Amazon VPC e Amazon MSK saia APIs da rede Amazon. Os VPC Endpoints de interface não exigem um gateway de internet, dispositivo NAT, conexão VPN ou conexão Direct AWS Connect. [AWS PrivateLink](https://docs.aws.amazon.com/vpc/latest/privatelink/what-is-privatelink.html)é uma AWS tecnologia que permite a comunicação privada entre AWS serviços usando uma interface de rede elástica com privacidade IPs em sua Amazon VPC. Para obter mais informações, consulte [Amazon Virtual Private Cloud](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html) e [Interface VPC Endpoints](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint) ().AWS PrivateLink
Seus aplicativos podem se conectar ao Amazon MSK Provisioned e ao MSK Connect usando. APIs AWS PrivateLink Para iniciar, crie um endpoint da VPC de interface para que o tráfego da API do Amazon MSK fluindo dos recursos de e para os seus recursos do Amazon VPC comece a fluir através do endpoint da VPC de interface. Os endpoints da VPC de interface habilitada para FIPS estão disponíveis para as regiões dos EUA. Para obter mais informações, consulte [Criar um endpoint de interface](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint).
Usando esse recurso, seus clientes do Apache Kafka podem buscar dinamicamente as cadeias de conexão para se conectar aos recursos do MSK Provisioned ou do MSK Connect sem percorrer a Internet para recuperar as cadeias de conexão.
Ao criar um endpoint da VPC de interface, escolha um dos seguintes endpoints de nome de serviço:
**Para o MSK Provisioned:**
+ Os seguintes endpoints de nome de serviço não são mais compatíveis com novas conexões:
+ com.amazonaws.region.kafka
+ com.amazonaws.region.kafka-fips (habilitado para FIPS)
+ O serviço de endpoint Dualstack que suporta ambos IPv4 e o tráfego são: IPv6
+ aws.api.region.kafka-api
+ aws.api.region. kafka-api-fips (Habilitado para FIPS)
Para configurar os endpoints de pilha dupla, você deve seguir as diretrizes de endpoints de pilha [dupla](https://docs.aws.amazon.com/sdkref/latest/guide/feature-endpoints.html) e FIPS.
Em que “region” é o nome da sua região. Escolha esse nome de serviço para trabalhar com o MSK APIs Provisioned compatível. Para obter mais informações, consulte [Operações na referência https://docs.aws.amazon.com/msk/](https://docs.aws.amazon.com/msk/1.0/apireference/operations.html) *1.0/api/*.
**Para o MSK Connect:**
+ com.amazonaws.region.kafkaconnect
Em que “region” é o nome da sua região. Escolha esse nome de serviço para trabalhar com o MSK Connect APIs compatível. Para obter mais informações, consulte [Ações](https://docs.aws.amazon.com/MSKC/latest/mskc/API_Operations.html) na *Referência de API do Amazon Connect*.
*Para obter mais informações, incluindo step-by-step instruções para criar um endpoint VPC de interface, consulte [Criação de um endpoint de interface no Guia](https://docs.aws.amazon.com/vpc/latest/privatelink/create-interface-endpoint.html#create-interface-endpoint).AWS PrivateLink *
## Controle o acesso aos VPC endpoints para Amazon MSK Provisioned ou MSK Connect APIs
As políticas de endpoint da VPC permitem que você controle o acesso anexando uma política a um endpoint da VPC ou usando campos adicionais em uma política anexada a um usuário, perfil ou grupo do IAM para restringir o acesso para ocorrer somente por meio do endpoint da VPC especificado. Use o exemplo de política apropriado para definir as permissões de acesso para o serviço do MSK Provisioned ou do MSK Connect.
Se você não associar uma política ao criar um endpoint, a Amazon VPC associará uma política padrão que permita o acesso total ao serviço. Uma política de endpoint não substitui as políticas do IAM nem as políticas fundamentadas na identidade e específicas do serviço. É uma política separada para controlar o acesso do endpoint ao serviço especificado.
Para obter mais informações, consulte [Controlar o acesso a serviços com endpoints da VPC](https://docs.aws.amazon.com/vpc/latest/privatelink/vpc-endpoints-access.html) no *Guia do AWS PrivateLink *.
------
#### [ MSK Provisioned — VPC policy example ]
**Acesso somente leitura.**
Esse exemplo de política pode ser anexado a um endpoint da VPC. (Para obter mais informações, consulte Como controlar o acesso aos recursos da Amazon VPC). Ele restringe as ações a somente listar e a descrever operações por meio do endpoint da VPC ao qual está anexado.
```
{
"Statement": [
{
"Sid": "MSKReadOnly",
"Principal": "*",
"Action": [
"kafka:List*",
"kafka:Describe*"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
```
**MSK Provisioned — exemplo de política de endpoint da VPC**
Restringir acesso a um cluster específico do MSK
Esse exemplo de política pode ser anexado a um endpoint da VPC. Ele restringe o acesso a cluster específico do Kafka por meio do endpoint da VPC ao qual está anexado.
```
{
"Statement": [
{
"Sid": "AccessToSpecificCluster",
"Principal": "*",
"Action": "kafka:*",
"Effect": "Allow",
"Resource": "arn:aws:kafka:us-east-1:123456789012:cluster/MyCluster"
}
]
}
```
------
#### [ MSK Connect — VPC endpoint policy example ]
**Listar conectores e criar um conector**
Veja a seguir um exemplo de política de endpoint para o MSK Connect. Essa política permite que a função especificada liste conectores e crie um conector.
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "MSKConnectPermissions",
"Effect": "Allow",
"Action": [
"kafkaconnect:ListConnectors",
"kafkaconnect:CreateConnector"
],
"Resource": "*",
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:role/MyMSKConnectExecutionRole"
]
}
}
]
}
```
**MSK Connect: exemplo de política de endpoint da VPC**
Permite somente solicitações de um endereço IP específico na VPC especificada
O exemplo a seguir mostra uma política que só permite a efetivação de solicitações provenientes de um endereço IP especificado na VPC estabelecida. Solicitações de outros endereços IP não são aceitas.
```
{
"Statement": [
{
"Action": "kafkaconnect:*",
"Effect": "Allow",
"Principal": "*",
"Resource": "*",
"Condition": {
"IpAddress": {
"aws:VpcSourceIp": "192.0.2.123"
},
"StringEquals": {
"aws:SourceVpc": "vpc-555555555555"
}
}
}
]
}
```
------
# Autenticação e autorização para Amazon MSK APIs
AWS Identity and Access Management (IAM) é uma ferramenta AWS service (Serviço da AWS) que ajuda o administrador a controlar com segurança o acesso aos AWS recursos. Os administradores do IAM controlam quem pode ser *autenticado* (conectado) e *autorizado* (ter permissões) para utilizar os recursos do Amazon MSK. O IAM é um AWS service (Serviço da AWS) que você pode usar sem custo adicional.
**Topics**
+ [Como o Amazon MSK funciona com o IAM](security_iam_service-with-iam.md)
+ [Exemplos de política baseada em identidade do Amazon MSK](security_iam_id-based-policy-examples.md)
+ [Perfis vinculados ao serviço para o Amazon MSK](using-service-linked-roles.md)
+ [AWS políticas gerenciadas para o Amazon MSK](security-iam-awsmanpol.md)
+ [Solução de problemas de identidade e acesso do Amazon MKS](security_iam_troubleshoot.md)
# Como o Amazon MSK funciona com o IAM
Antes de usar o IAM para gerenciar o acesso ao Amazon MSK, você deve entender quais recursos do IAM estão disponíveis para uso com o Amazon MSK. Para obter uma visão de alto nível de como o Amazon MSK e outros AWS serviços funcionam com o IAM, consulte [AWS Serviços que funcionam com o IAM no Guia do](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) *usuário do IAM*.
**Topics**
+ [Políticas baseadas em identidade do Amazon MSK](security_iam_service-with-iam-id-based-policies.md)
+ [Políticas baseadas em recurso do Amazon MSK](security_iam_service-with-iam-resource-based-policies.md)
+ [Autorização baseada em tags do Amazon MSK](security_iam_service-with-iam-tags.md)
+ [Perfis do IAM para o Amazon MSK](security_iam_service-with-iam-roles.md)
# Políticas baseadas em identidade do Amazon MSK
Com as políticas baseadas em identidade do IAM, é possível especificar ações e recursos permitidos ou negados, assim como as condições sob as quais as ações são permitidas ou negadas. O Amazon MSK é compatível com ações, chaves de condição e recursos específicos. Para conhecer todos os elementos usados em uma política JSON, consulte [Referência de elementos de política JSON do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html) no *Guia do usuário do IAM*.
## Ações para políticas baseadas em identidade do Amazon MSK
Os administradores podem usar políticas AWS JSON para especificar quem tem acesso ao quê. Ou seja, qual **entidade principal** pode executar **ações** em quais **recursos** e em que **condições**.
O elemento `Action` de uma política JSON descreve as ações que podem ser usadas para permitir ou negar acesso em uma política. Incluem ações em uma política para conceder permissões para executar a operação associada.
As ações de política no Amazon MSK usam o seguinte prefixo antes da ação: `kafka:`. Por exemplo, para conceder permissão a alguém para descrever um cluster do MSK com a operação de API `DescribeCluster` do Amazon MSK, inclua a ação `kafka:DescribeCluster` na política. As instruções de política devem incluir um elemento `Action` ou `NotAction`. O Amazon MSK define seu próprio conjunto de ações que descrevem as tarefas que você pode executar com esse serviço.
Observe que as ações de política para o tópico MSK APIs usam o `kafka-cluster` prefixo antes da ação, consulte o. [Semântica das ações e recursos da política de autorização do IAM](kafka-actions.md)
Para especificar várias ações em uma única instrução, separe-as com vírgulas, como segue:
```
"Action": ["kafka:action1", "kafka:action2"]
```
Você também pode especificar várias ações usando caracteres curinga (\$1). Por exemplo, para especificar todas as ações que começam com a palavra `Describe`, inclua a seguinte ação:
```
"Action": "kafka:Describe*"
```
Para ver uma lista de ações do Amazon MSK, consulte [Ações, recursos e chaves de condição do Amazon Managed Streaming for Apache Kafka](https://docs.aws.amazon.com/service-authorization/latest/reference/list_amazonmanagedstreamingforapachekafka.html) no *Guia do usuário do IAM*.
## Recursos para políticas baseadas em identidade do Amazon MSK
Os administradores podem usar políticas AWS JSON para especificar quem tem acesso ao quê. Ou seja, qual **entidade principal** pode executar **ações** em quais **recursos** e em que **condições**.
O elemento de política JSON `Resource` especifica o objeto ou os objetos aos quais a ação se aplica. Como prática recomendada, especifique um recurso usando seu [nome do recurso da Amazon (ARN)](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference-arns.html). Para ações que não oferecem compatibilidade com permissões em nível de recurso, use um curinga (\$1) para indicar que a instrução se aplica a todos os recursos.
```
"Resource": "*"
```
O recurso de instância do Amazon MSK tem o seguinte ARN:
```
arn:${Partition}:kafka:${Region}:${Account}:cluster/${ClusterName}/${UUID}
```
Para obter mais informações sobre o formato de ARNs, consulte [Amazon Resource Names (ARNs) e AWS Service Namespaces](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html).
Por exemplo, para especificar a instância `CustomerMessages` na instrução, use o seguinte ARN:
```
"Resource": "arn:aws:kafka:us-east-1:123456789012:cluster/CustomerMessages/abcd1234-abcd-dcba-4321-a1b2abcd9f9f-2"
```
Para especificar todas as instâncias que pertencem a uma conta específica, use o caractere curinga (\$1):
```
"Resource": "arn:aws:kafka:us-east-1:123456789012:cluster/*"
```
Algumas ações do Amazon MSK, como as usadas para a criação de recursos, não podem ser executadas em um recurso específico. Nesses casos, é necessário utilizar o caractere curinga (\$1).
```
"Resource": "*"
```
Para especificar vários recursos em uma única instrução, separe-os ARNs com vírgulas.
```
"Resource": ["resource1", "resource2"]
```
*Para ver uma lista dos tipos de recursos do Amazon MSK e seus ARNs, consulte [Resources Defined by Amazon Managed Streaming for Apache](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonmanagedstreamingforkafka.html#amazonmanagedstreamingforkafka-resources-for-iam-policies) Kafka no Guia do usuário do IAM.* Para saber com quais ações você pode especificar o ARN de cada recurso, consulte [Ações definidas pelo Amazon Managed Streaming for Apache Kafka](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonmanagedstreamingforkafka.html#amazonmanagedstreamingforkafka-actions-as-permissions).
## Chaves de condição para políticas baseadas em identidade do Amazon MSK
Os administradores podem usar políticas AWS JSON para especificar quem tem acesso ao quê. Ou seja, qual **entidade principal** pode executar **ações** em quais **recursos** e em que **condições**.
O elemento `Condition` especifica quando as instruções são executadas com base em critérios definidos. É possível criar expressões condicionais que usem [agentes de condição](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html), como “igual a” ou “menor que”, para fazer a condição da política corresponder aos valores na solicitação. Para ver todas as chaves de condição AWS globais, consulte as [chaves de contexto de condição AWS global](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) no *Guia do usuário do IAM*.
O Amazon MSK define seu próprio conjunto de chaves de condição e também é compatível com o uso de algumas chaves de condição globais. Para ver todas as chaves de condição AWS globais, consulte [Chaves de contexto de condição AWS global](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) no *Guia do usuário do IAM*.
Para ver uma lista das chaves de condição do Amazon MSK, consulte [Chaves de condição para o Amazon Managed Streaming for Apache Kafka](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonmanagedstreamingforkafka.html#amazonmanagedstreamingforkafka-policy-keys) no *Guia do usuário do IAM*. Para saber com quais ações e recursos você pode usar uma chave de condição, consulte [Ações definidas pelo Amazon Managed Streaming for Apache Kafka](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_amazonmanagedstreamingforkafka.html#amazonmanagedstreamingforkafka-actions-as-permissions).
## Exemplos de políticas baseadas em identidade do Amazon MSK
Para visualizar exemplos de políticas baseadas em identidade do Amazon MSK, consulte [Exemplos de política baseada em identidade do Amazon MSK](security_iam_id-based-policy-examples.md).
# Políticas baseadas em recurso do Amazon MSK
O Amazon MSK é compatível com uma política de cluster (também conhecida como política baseada em recurso) para uso com clusters do Amazon MSK. Você pode usar uma política de cluster para definir quais entidades principais do IAM têm permissões entre contas para configurar a conectividade privada com seu cluster do Amazon MSK. Quando usada com a autenticação de cliente do IAM, você também pode usar a política de cluster para definir de modo granular as permissões do plano de dados do Kafka para os clientes conectados.
O tamanho máximo aceito para uma política de cluster é de 20 KB.
Para ver um exemplo de como configurar uma política de cluster, consulte [Etapa 2: anexar uma política de cluster ao cluster do MSK](mvpc-cluster-owner-action-policy.md).
# Autorização baseada em tags do Amazon MSK
É possível anexar tags a clusters do Amazon MSK. Para controlar o acesso baseado em tags, forneça informações sobre as tags no [elemento de condição](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) de uma política usando as `kafka:ResourceTag/key-name`, `aws:RequestTag/key-name` ou chaves de condição `aws:TagKeys`. Para obter informações sobre a atribuição de tags a recursos do Amazon MSK, consulte [Marcar um cluster do Amazon MSK](msk-tagging.md).
Você só pode controlar o acesso ao cluster com a ajuda de tags. Para definir tags para grupos de consumidores e tópicos, você precisa adicionar uma declaração separada em suas políticas sem tags.
Para visualizar um exemplo de política baseada em identidades a fim de limitar o acesso a um cluster baseado nas tags desse cluster, consulte [Como acessar clusters do Amazon MSK com base em tags](security_iam_id-based-policy-examples-view-widget-tags.md).
Você pode usar condições em sua política baseada em identidade para controlar o acesso aos recursos do Amazon MSK com base em tags. O exemplo a seguir mostra como você pode criar uma política que permita que o usuário descreva o cluster, obtenha seus agentes de bootstrap, liste seus nós de agente, atualize-o e exclua-o. No entanto, essa política concede a permissão somente se a tag de cluster `Owner` tiver o valor do `username` do usuário. A segunda declaração na política a seguir permite acesso aos tópicos do cluster. A primeira declaração desta política não autoriza acesso a nenhum tópico.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AccessClusterIfOwner",
"Effect": "Allow",
"Action": [
"kafka:Describe*",
"kafka:Get*",
"kafka:List*",
"kafka:Update*",
"kafka:Delete*"
],
"Resource": "arn:aws:kafka:us-east-1:123456789012:cluster/*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/Owner": "${aws:username}"
}
}
},
{
"Effect": "Allow",
"Action": [
"kafka-cluster:*Topic*",
"kafka-cluster:WriteData",
"kafka-cluster:ReadData"
],
"Resource": [
"arn:aws:kafka:us-east-1:123456789012:topic/*"
]
}
]
}
```
------
# Perfis do IAM para o Amazon MSK
Um [perfil do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) é uma entidade dentro da sua conta da Amazon Web Services que tem permissões específicas.
## Usar credenciais temporárias com o Amazon MSK
É possível usar credenciais temporárias para fazer login com federação, assumir um perfil do IAM ou assumir um perfil entre contas. Você obtém credenciais de segurança temporárias chamando operações de AWS STS API, como [AssumeRole](https://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRole.html)ou [GetFederationToken](https://docs.aws.amazon.com/STS/latest/APIReference/API_GetFederationToken.html).
A Amazon MSK é compatível com o uso de credenciais temporárias.
## Perfis vinculados ao serviço
Os [perfis vinculados a serviço](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role) permitem que os serviços da Amazon Web Services acessem recursos em outros serviços para concluir uma ação em seu nome. Os perfis vinculados a serviço aparecem em sua conta do IAM e são de propriedade do serviço. Um administrador do pode visualizar, mas não pode editar as permissões para funções vinculadas ao serviço.
O Amazon ECS MSK é compatível com perfis vinculados a serviço. Para obter detalhes sobre como criar ou gerenciar perfis vinculados a serviço do Amazon MSK, consulte [Perfis vinculados ao serviço para o Amazon MSK](using-service-linked-roles.md).
# Exemplos de política baseada em identidade do Amazon MSK
Por padrão, usuários e perfis do IAM não têm permissão para executar ações de API do Amazon MSK. Um administrador deve criar as políticas do IAM que concedam aos usuários e aos perfis permissões para executar operações de API específicas nos recursos especificados que precisam. O administrador deve anexar essas políticas aos usuários ou grupos do IAM que exigem essas permissões.
Para saber como criar uma política baseada em identidade do IAM usando esses exemplos de documentos de política JSON, consulte [Criar políticas na guia JSON](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html#access_policies_create-json-editor) no *Guia do usuário do IAM*.
**Topics**
+ [Práticas recomendadas de política](security_iam_service-with-iam-policy-best-practices.md)
+ [Permitir que os usuários visualizem suas próprias permissões](security_iam_id-based-policy-examples-view-own-permissions.md)
+ [Acessar um cluster do Amazon MSK](security_iam_id-based-policy-examples-access-one-cluster.md)
+ [Como acessar clusters do Amazon MSK com base em tags](security_iam_id-based-policy-examples-view-widget-tags.md)
# Práticas recomendadas de política
As políticas baseadas em identidade determinam se alguém pode criar, acessar ou excluir recursos do Amazon MSK em sua conta. Essas ações podem incorrer em custos para sua Conta da AWS. Ao criar ou editar políticas baseadas em identidade, siga estas diretrizes e recomendações:
+ **Comece com as políticas AWS gerenciadas e avance para as permissões de privilégios mínimos — Para começar a conceder permissões** aos seus usuários e cargas de trabalho, use as *políticas AWS gerenciadas* que concedem permissões para muitos casos de uso comuns. Eles estão disponíveis no seu Conta da AWS. Recomendamos que você reduza ainda mais as permissões definindo políticas gerenciadas pelo AWS cliente que sejam específicas para seus casos de uso. Para saber mais, consulte [Políticas gerenciadas pela AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) ou [Políticas gerenciadas pela AWS para funções de trabalho](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) no *Guia do usuário do IAM*.
+ **Aplique permissões de privilégio mínimo**: ao definir permissões com as políticas do IAM, conceda apenas as permissões necessárias para executar uma tarefa. Você faz isso definindo as ações que podem ser executadas em recursos específicos sob condições específicas, também conhecidas como *permissões de privilégio mínimo*. Para saber mais sobre como usar o IAM para aplicar permissões, consulte [Políticas e permissões no IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) no *Guia do usuário do IAM*.
+ **Use condições nas políticas do IAM para restringir ainda mais o acesso**: é possível adicionar uma condição às políticas para limitar o acesso a ações e recursos. Por exemplo, é possível escrever uma condição de política para especificar que todas as solicitações devem ser enviadas usando SSL. Você também pode usar condições para conceder acesso às ações de serviço se elas forem usadas por meio de uma ação específica AWS service (Serviço da AWS), como CloudFormation. Para saber mais, consulte [Elementos da política JSON do IAM: condição](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) no *Guia do usuário do IAM*.
+ **Use o IAM Access Analyzer para validar suas políticas do IAM a fim de garantir permissões seguras e funcionais**: o IAM Access Analyzer valida as políticas novas e existentes para que elas sigam a linguagem de política do IAM (JSON) e as práticas recomendadas do IAM. O IAM Access Analyzer oferece mais de cem verificações de política e recomendações práticas para ajudar a criar políticas seguras e funcionais. Para saber mais, consulte [Validação de políticas do IAM Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/access-analyzer-policy-validation.html) no *Guia do Usuário do IAM*.
+ **Exigir autenticação multifator (MFA**) — Se você tiver um cenário que exija usuários do IAM ou um usuário root, ative Conta da AWS a MFA para obter segurança adicional. Para exigir MFA quando as operações de API forem chamadas, adicione condições de MFA às suas políticas. Para saber mais, consulte [Configuração de acesso à API protegido por MFA](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_mfa_configure-api-require.html) no *Guia do Usuário do IAM*.
Para saber mais sobre as práticas recomendadas do IAM, consulte [Práticas recomendadas de segurança no IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html) no *Guia do usuário do IAM*.
# Permitir que os usuários visualizem suas próprias permissões
Este exemplo mostra como criar uma política que permita que os usuários do IAM visualizem as políticas gerenciadas e em linha anexadas a sua identidade de usuário. Essa política inclui permissões para concluir essa ação no console ou programaticamente usando a API AWS CLI ou AWS .
```
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "ViewOwnUserInfo",
"Effect": "Allow",
"Action": [
"iam:GetUserPolicy",
"iam:ListGroupsForUser",
"iam:ListAttachedUserPolicies",
"iam:ListUserPolicies",
"iam:GetUser"
],
"Resource": ["arn:aws:iam::*:user/${aws:username}"]
},
{
"Sid": "NavigateInConsole",
"Effect": "Allow",
"Action": [
"iam:GetGroupPolicy",
"iam:GetPolicyVersion",
"iam:GetPolicy",
"iam:ListAttachedGroupPolicies",
"iam:ListGroupPolicies",
"iam:ListPolicyVersions",
"iam:ListPolicies",
"iam:ListUsers"
],
"Resource": "*"
}
]
}
```
# Acessar um cluster do Amazon MSK
Neste exemplo, você vai permitir que um usuário do IAM na sua conta da Amazon Web Services acesse um dos seus cluster, `purchaseQueriesCluster`. Esta política permite que o usuário descreva o cluster, obtenha seus agentes de bootstrap, liste seus nós de agente e o atualize.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"UpdateCluster",
"Effect":"Allow",
"Action":[
"kafka:Describe*",
"kafka:Get*",
"kafka:List*",
"kafka:Update*"
],
"Resource":"arn:aws:kafka:us-east-1:012345678012:cluster/purchaseQueriesCluster/abcdefab-1234-abcd-5678-cdef0123ab01-2"
}
]
}
```
------
# Como acessar clusters do Amazon MSK com base em tags
Você pode usar condições em sua política baseada em identidade para controlar o acesso aos recursos do Amazon MSK com base em tags. Este exemplo mostra como você pode criar uma política que permita que o usuário descreva o cluster, obtenha seus agentes de bootstrap, liste seus nós de agente, atualize-o e exclua-o. No entanto, a permissão será concedida somente se a tag de cluster `Owner` tiver o valor do nome desse usuário.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "AccessClusterIfOwner",
"Effect": "Allow",
"Action": [
"kafka:Describe*",
"kafka:Get*",
"kafka:List*",
"kafka:Update*",
"kafka:Delete*"
],
"Resource": "arn:aws:kafka:us-east-1:012345678012:cluster/*",
"Condition": {
"StringEquals": {
"aws:ResourceTag/Owner": "${aws:username}"
}
}
}
]
}
```
------
É possível anexar essa política aos usuários do IAM na sua conta. Se um usuário chamado `richard-roe` tentar atualizar um cluster do MSK, o cluster deverá estar marcado como `Owner=richard-roe` ou `owner=richard-roe`. Caso contrário, ele terá o acesso negado. A chave da tag de condição `Owner` corresponde a `Owner` e a `owner` porque os nomes das chaves de condição não fazem distinção entre maiúsculas e minúsculas. Para obter mais informações, consulte [IAM JSON Policy Elements: Condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html) (Elementos da política JSON do IAM: Condição) no *Guia do usuário do IAM*.
# Perfis vinculados ao serviço para o Amazon MSK
O Amazon MSK usa funções [vinculadas a serviços AWS Identity and Access Management](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#iam-term-service-linked-role) (IAM). Um perfil vinculado a serviço é um tipo especial de perfil do IAM vinculado diretamente ao Amazon MSK. As funções vinculadas ao serviço são predefinidas pelo Amazon MSK e incluem todas as permissões que o serviço exige para chamar outros AWS serviços em seu nome.
Um perfil vinculado a serviço facilita a configuração do Amazon MSK porque você não precisa adicionar as permissões necessárias manualmente. O Amazon MSK define as permissões dos perfis vinculados a serviço. A menos que definido de outra forma, somente o Amazon MSK pode assumir seus perfis. As permissões definidas incluem a política de confiança e a política de permissões, que não pode ser anexada a nenhuma outra entidade do IAM.
Para obter informações sobre outros serviços compatíveis com perfis vinculados a serviço, consulte [Serviços da Amazon Web Services compatíveis com o IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) e procure os serviços que exibem **Sim** na coluna **Perfil vinculado a serviço**. Escolha um **Sim** com um link para visualizar a documentação do perfil vinculado para esse serviço.
**Topics**
+ [Permissões de perfil vinculado ao serviço](slr-permissions.md)
+ [Criar um perfil vinculado ao serviço](create-slr.md)
+ [Editar um perfil vinculado ao serviço](edit-slr.md)
+ [Regiões suportadas por perfis vinculados a serviço do](slr-regions.md)
# Permissões de perfil vinculado a serviço para o Amazon MSK
O Amazon MSK usa o perfil vinculado a serviço chamado **AWSServiceRoleForKafka**. O Amazon MSK usa esse perfil para acessar seus recursos e realizar operações como:
+ `*NetworkInterface`: criar e gerenciar interfaces de rede na conta do cliente que tornem os agentes de cluster acessíveis aos clientes na VPC do cliente.
+ `*VpcEndpoints`— gerencie endpoints de VPC na conta do cliente que tornam os agentes de cluster acessíveis aos clientes que usam a VPC do cliente. AWS PrivateLink O Amazon MSK usa permissões para `DescribeVpcEndpoints`, `ModifyVpcEndpoint` e `DeleteVpcEndpoints`.
+ `secretsmanager`— gerencie as credenciais do cliente com AWS Secrets Manager.
+ `GetCertificateAuthorityCertificate`: recuperar o certificado para sua autoridade de certificação privada.
+ `*Ipv6Addresses`— atribua e cancele a atribuição de IPv6 endereços às interfaces de rede na conta do cliente para permitir a IPv6 conectividade dos clusters MSK.
+ `ModifyNetworkInterfaceAttribute`— modifique os atributos da interface de rede na conta do cliente para definir IPv6 as configurações de conectividade do cluster MSK.
Essa função vinculada ao serviço é anexada à seguinte política gerenciada: `KafkaServiceRolePolicy`. Para obter atualizações dessa política, consulte [KafkaServiceRolePolicy](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/KafkaServiceRolePolicy.html).
O perfil vinculado ao serviço AWSServiceRoleForKafka confia nos seguintes serviços para aceitar o perfil:
+ `kafka.amazonaws.com`
A política de permissões do perfil permite que o Amazon MSK execute as seguintes ações nos recursos.
Você deve configurar permissões para que uma entidade do IAM (por exemplo, um usuário, grupo ou função) crie, edite ou exclua um perfil vinculado a serviço. Para saber mais, consulte [Permissões de Função Vinculadas ao Serviço](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#service-linked-role-permissions) no *Guia do Usuário do IAM*.
# Criar um perfil vinculado ao serviço para o Amazon MSK
Não é necessário criar uma função vinculada ao serviço manualmente. Quando você cria um cluster do Amazon MSK na Console de gerenciamento da AWS, na ou na AWS API AWS CLI, o Amazon MSK cria a função vinculada ao serviço para você.
Se excluir esse perfil vinculado ao serviço e precisar criá-lo novamente, será possível usar esse mesmo processo para recriar o perfil em sua conta. Quando você cria um cluster do Amazon MSK, o Amazon MSK cria um perfil vinculado a serviço para você novamente.
# Editar um perfil vinculado ao serviço para o Amazon MSK
O Amazon MSK não permite que você edite o perfil vinculado a serviço do AWSServiceRoleForKafka. Depois que criar um perfil vinculado ao serviço, você não poderá alterar o nome do perfil, pois várias entidades podem fazer referência a ele. No entanto, será possível editar a descrição do perfil usando o IAM. Para saber mais, consulte [Editar uma função vinculada a serviço](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html#edit-service-linked-role) no *Guia do usuário do IAM*.
# Regiões compatíveis com perfis vinculados a serviço do Amazon MSK
O Amazon MSK é compatível com perfis vinculados a serviço em todas as regiões nas quais o serviço esteja disponível. Para mais informações, consulte [Regiões e endpoints da AWS](https://docs.aws.amazon.com/general/latest/gr/rande.html).
# AWS políticas gerenciadas para o Amazon MSK
Uma política AWS gerenciada é uma política autônoma criada e administrada por AWS. AWS as políticas gerenciadas são projetadas para fornecer permissões para muitos casos de uso comuns, para que você possa começar a atribuir permissões a usuários, grupos e funções.
Lembre-se de que as políticas AWS gerenciadas podem não conceder permissões de privilégio mínimo para seus casos de uso específicos porque elas estão disponíveis para uso de todos os AWS clientes. Recomendamos que você reduza ainda mais as permissões definindo as [ políticas gerenciadas pelo cliente](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#customer-managed-policies) que são específicas para seus casos de uso.
Você não pode alterar as permissões definidas nas políticas AWS gerenciadas. Se AWS atualizar as permissões definidas em uma política AWS gerenciada, a atualização afetará todas as identidades principais (usuários, grupos e funções) às quais a política está anexada. AWS é mais provável que atualize uma política AWS gerenciada quando uma nova AWS service (Serviço da AWS) é lançada ou novas operações de API são disponibilizadas para serviços existentes.
Para saber mais, consulte [AWS Políticas gerenciadas pela ](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) no *Guia do usuário do IAM*.
# AWS política gerenciada: Amazon MSKFull Access
Essa política concede permissões administrativas que permitem que a entidade principal tenha acesso total a todas as ações do Amazon MSK. As permissões nessa política são agrupadas da seguinte forma:
+ As permissões do Amazon MSK permitem todas as ações do Amazon MSK.
+ **Permissões do `Amazon EC2`**: nesta política são necessárias para validar os recursos passados em uma solicitação de API. Isso serve para garantir que o Amazon MSK seja capaz de usar adequadamente os recursos com um cluster. O restante das permissões do Amazon EC2 nesta política permitem que o Amazon MSK crie AWS os recursos necessários para possibilitar a conexão com seus clusters.
+ **Permissões do `AWS KMS`**: são usadas durante as chamadas de API para validar os recursos transmitidos em uma solicitação. Elas são necessárias para que o Amazon MSK consiga usar a chave transmitida com o cluster do Amazon MSK.
+ **Permissões do `CloudWatch Logs, Amazon S3, and Amazon Data Firehose`**: são necessárias para que o Amazon MSK possa garantir que os destinos de entrega de logs sejam acessíveis e válidos para o uso de logs do agente.
+ **Permissões do `IAM`**: são necessárias para que o Amazon MSK possa criar uma perfil vinculado ao serviço na conta e para permitir que você passe um perfil de execução de serviço para o Amazon MSK.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"kafka:*",
"ec2:DescribeSubnets",
"ec2:DescribeVpcs",
"ec2:DescribeSecurityGroups",
"ec2:DescribeRouteTables",
"ec2:DescribeVpcEndpoints",
"ec2:DescribeVpcAttribute",
"kms:DescribeKey",
"kms:CreateGrant",
"logs:CreateLogDelivery",
"logs:GetLogDelivery",
"logs:UpdateLogDelivery",
"logs:DeleteLogDelivery",
"logs:ListLogDeliveries",
"logs:PutResourcePolicy",
"logs:DescribeResourcePolicies",
"logs:DescribeLogGroups",
"S3:GetBucketPolicy",
"firehose:TagDeliveryStream"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateVpcEndpoint"
],
"Resource": [
"arn:*:ec2:*:*:vpc/*",
"arn:*:ec2:*:*:subnet/*",
"arn:*:ec2:*:*:security-group/*"
]
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateVpcEndpoint"
],
"Resource": [
"arn:*:ec2:*:*:vpc-endpoint/*"
],
"Condition": {
"StringEquals": {
"aws:RequestTag/AWSMSKManaged": "true"
},
"StringLike": {
"aws:RequestTag/ClusterArn": "*"
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": "arn:*:ec2:*:*:vpc-endpoint/*",
"Condition": {
"StringEquals": {
"ec2:CreateAction": "CreateVpcEndpoint"
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:DeleteVpcEndpoints"
],
"Resource": "arn:*:ec2:*:*:vpc-endpoint/*",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/AWSMSKManaged": "true"
},
"StringLike": {
"ec2:ResourceTag/ClusterArn": "*"
}
}
},
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "*",
"Condition": {
"StringEquals": {
"iam:PassedToService": "kafka.amazonaws.com"
}
}
},
{
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws:iam::*:role/aws-service-role/kafka.amazonaws.com/AWSServiceRoleForKafka*",
"Condition": {
"StringLike": {
"iam:AWSServiceName": "kafka.amazonaws.com"
}
}
},
{
"Effect": "Allow",
"Action": [
"iam:AttachRolePolicy",
"iam:PutRolePolicy"
],
"Resource": "arn:aws:iam::*:role/aws-service-role/kafka.amazonaws.com/AWSServiceRoleForKafka*"
},
{
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws:iam::*:role/aws-service-role/delivery.logs.amazonaws.com/AWSServiceRoleForLogDelivery*",
"Condition": {
"StringLike": {
"iam:AWSServiceName": "delivery.logs.amazonaws.com"
}
}
}
]
}
```
------
# AWS política gerenciada: Amazon MSKRead OnlyAccess
Essa política concede permissões de acesso somente leitura que permitem que os usuários visualizem informações no Amazon MSK. As entidades principais com essa política anexada não podem fazer nenhuma atualização ou excluir recursos existentes, nem criar novos recursos do Amazon MSK. Por exemplo, entidades principais com essas permissões podem visualizar a lista de clusters e configurações associadas à conta, mas não podem alterar a configuração ou as definições de nenhum cluster. As permissões nessa política são agrupadas da seguinte forma:
+ **Permissões do `Amazon MSK`**: permitem que você liste os recursos do Amazon MSK, descreva-os e obtenha informações sobre eles.
+ **`Amazon EC2`permissões** — são usadas para descrever a Amazon VPC, sub-redes, grupos de segurança e ENIs que estão associados a um cluster.
+ **Permissão do `AWS KMS`**: é usada para descrever a chave associada ao cluster.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"kafka:Describe*",
"kafka:List*",
"kafka:Get*",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeSecurityGroups",
"ec2:DescribeSubnets",
"ec2:DescribeVpcs",
"kms:DescribeKey"
],
"Effect": "Allow",
"Resource": "*"
}
]
}
```
------
# AWS política gerenciada: KafkaServiceRolePolicy
Você não pode se vincular KafkaServiceRolePolicy às suas entidades do IAM. Essa política é anexada a um perfil vinculado a serviço que permite que o Amazon MSK realize ações como gerenciar endpoints da VPC (conectores) em clusters do MSK, gerenciar interfaces de rede e gerenciar credenciais de cluster com o AWS Secrets Manager. Para obter mais informações, consulte [Perfis vinculados ao serviço para o Amazon MSK](using-service-linked-roles.md).
A tabela a seguir descreve as atualizações da política KafkaServiceRolePolicy gerenciada desde que o Amazon MSK começou a rastrear as alterações.
| Alteração | Descrição | Data |
| --- | --- | --- |
| [IPv6 suporte de conectividade adicionado a KafkaServiceRolePolicy](#security-iam-awsmanpol-KafkaServiceRolePolicy) — Atualização de uma política existente | O Amazon MSK adicionou permissões para KafkaServiceRolePolicy habilitar a IPv6 conectividade para clusters MSK. Essas permissões permitem que a Amazon MSK atribua e cancele a atribuição de IPv6 endereços às interfaces de rede e modifique os atributos da interface de rede na conta do cliente. | 17 de novembro de 2025 |
| [KafkaServiceRolePolicy](#security-iam-awsmanpol-KafkaServiceRolePolicy) – atualização para uma política existente | O Amazon MSK adicionou permissões para compatibilidade com conectividade privada multi-VPC. | 8 de março de 2023 |
| O Amazon MSK passou a monitorar alterações | A Amazon MSK começou a monitorar as alterações na política KafkaServiceRolePolicy gerenciada. | 8 de março de 2023 |
# AWS política gerenciada: AWSMSKReplicator ExecutionRole
A política `AWSMSKReplicatorExecutionRole` concede permissões ao Replicador do Amazon MSK para replicar dados entre clusters do MSK. As permissões nessa política são agrupadas da seguinte forma:
+ **`cluster`**: concede ao Replicador do Amazon MSK permissões para se conectar ao cluster usando a autenticação do IAM. Também concede permissões para descrever e alterar o cluster.
+ **`topic`**: concede ao Replicador do Amazon MSK permissões para descrever, criar e alterar um tópico e alterar a configuração dinâmica dele.
+ **`consumer group`**: concede ao Replicador do Amazon MSK permissões para descrever e alterar grupos de consumidores, ler e gravar datas de um cluster do MSK e excluir tópicos internos criados pelo replicador.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "ClusterPermissions",
"Effect": "Allow",
"Action": [
"kafka-cluster:Connect",
"kafka-cluster:DescribeCluster",
"kafka-cluster:AlterCluster",
"kafka-cluster:DescribeTopic",
"kafka-cluster:CreateTopic",
"kafka-cluster:AlterTopic",
"kafka-cluster:WriteData",
"kafka-cluster:ReadData",
"kafka-cluster:AlterGroup",
"kafka-cluster:DescribeGroup",
"kafka-cluster:DescribeTopicDynamicConfiguration",
"kafka-cluster:AlterTopicDynamicConfiguration",
"kafka-cluster:WriteDataIdempotently"
],
"Resource": [
"arn:aws:kafka:*:*:cluster/*"
]
},
{
"Sid": "TopicPermissions",
"Effect": "Allow",
"Action": [
"kafka-cluster:DescribeTopic",
"kafka-cluster:CreateTopic",
"kafka-cluster:AlterTopic",
"kafka-cluster:WriteData",
"kafka-cluster:ReadData",
"kafka-cluster:DescribeTopicDynamicConfiguration",
"kafka-cluster:AlterTopicDynamicConfiguration",
"kafka-cluster:AlterCluster"
],
"Resource": [
"arn:aws:kafka:*:*:topic/*/*"
]
},
{
"Sid": "GroupPermissions",
"Effect": "Allow",
"Action": [
"kafka-cluster:AlterGroup",
"kafka-cluster:DescribeGroup"
],
"Resource": [
"arn:aws:kafka:*:*:group/*/*"
]
}
]
}
```
------
# Atualizações do Amazon MSK para políticas AWS gerenciadas
Veja detalhes sobre as atualizações das políticas AWS gerenciadas do Amazon MSK desde que esse serviço começou a rastrear essas alterações.
| Alteração | Descrição | Data |
| --- | --- | --- |
| [WriteDataIdempotently permissão adicionada a AWSMSKReplicator ExecutionRole](security-iam-awsmanpol-AWSMSKReplicatorExecutionRole.md) — Atualização de uma política existente | O Amazon MSK adicionou WriteDataIdempotently permissão à AWSMSKReplicator ExecutionRole política para oferecer suporte à replicação de dados entre clusters MSK. | 12 de março de 2024 |
| [AWSMSKReplicatorExecutionRole](security-iam-awsmanpol-AWSMSKReplicatorExecutionRole.md) – Nova política | O Amazon MSK adicionou uma AWSMSKReplicator ExecutionRole política para dar suporte ao Amazon MSK Replicator. | 4 de dezembro de 2023 |
| [Amazon MSKFull Access](security-iam-awsmanpol-AmazonMSKFullAccess.md) — Atualização de uma política existente | O Amazon MSK adicionou permissões para compatibilidade com o replicador do Amazon MSK. | 28 de setembro de 2023 |
| [KafkaServiceRolePolicy](security-iam-awsmanpol-KafkaServiceRolePolicy.md) – atualização para uma política existente | O Amazon MSK adicionou permissões para compatibilidade com conectividade privada multi-VPC. | 8 de março de 2023 |
| [Amazon MSKFull Access](security-iam-awsmanpol-AmazonMSKFullAccess.md) — Atualização de uma política existente | O Amazon MSK adicionou novas permissões do Amazon EC2 para possibilitar a conexão a um cluster. | 30 de novembro de 2021 |
| [Amazon MSKFull Access](security-iam-awsmanpol-AmazonMSKFullAccess.md) — Atualização de uma política existente | O Amazon MSK adicionou uma nova permissão para permitir a descrição das tabelas de rotas do Amazon EC2. | 19 de novembro de 2021 |
| O Amazon MSK passou a monitorar alterações | A Amazon MSK começou a monitorar as mudanças em suas políticas AWS gerenciadas. | 19 de novembro de 2021 |
# Solução de problemas de identidade e acesso do Amazon MKS
Use as informações a seguir para ajudar a diagnosticar e corrigir problemas comuns que você pode encontrar ao trabalhar com o Amazon MSK e o IAM.
**Topics**
+ [Não tenho autorização para executar uma ação no Amazon MSK](#security_iam_troubleshoot-no-permissions)
## Não tenho autorização para executar uma ação no Amazon MSK
Se isso Console de gerenciamento da AWS indicar que você não está autorizado a realizar uma ação, entre em contato com o administrador para obter ajuda. Caso seu administrador seja a pessoa que forneceu suas credenciais de início de sessão.
O exemplo de erro a seguir ocorre quando o usuário do IAM `mateojackson` tenta usar o console para excluir um cluster, mas não tem permissões `kafka:DeleteCluster`.
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: kafka:DeleteCluster on resource: purchaseQueriesCluster
```
Neste caso, Mateo pede ao administrador para atualizar suas políticas para permitir a ele o acesso ao recurso `purchaseQueriesCluster` usando a ação `kafka:DeleteCluster`.
# Autenticação e autorização para o Apache Kafka APIs
É possível usar o IAM para autenticar clientes e permitir ou proibir ações do Apache Kafka. Como alternativa, você pode usar o TLS ou SASL/SCRAM para autenticar clientes e o Apache Kafka ACLs para permitir ou negar ações.
Para obter informações sobre como controlar quem pode realizar [operações do Amazon MSK](https://docs.aws.amazon.com/msk/1.0/apireference/operations.html) em seu cluster, consulte [Autenticação e autorização para Amazon MSK APIs](security-iam.md).
**Topics**
+ [Controle de acesso do IAM](iam-access-control.md)
+ [Autenticação mútua de cliente TLS para o Amazon MSK](msk-authentication.md)
+ [Autenticação de credenciais de login com Secrets Manager AWS](msk-password.md)
+ [Apache Kafka ACLs](msk-acls.md)
# Controle de acesso do IAM
O controle de acesso do IAM para o Amazon MSK permite que você gerencie a autenticação e a autorização para seu cluster do MSK. Isso elimina a necessidade de usar um mecanismo para autenticação e outro para autorização. Por exemplo, quando um cliente tenta gravar em seu cluster, o Amazon MSK usa o IAM para verificar se esse cliente é uma identidade autenticada e também se ele está autorizado a produzir para seu cluster.
O controle de acesso do IAM funciona para clientes Java e não Java, incluindo clientes Kafka escritos em Python, Go e .NET. JavaScript O controle de acesso do IAM para clientes não Java está disponível para clusters do MSK com o Kafka versão 2.7.1 ou posterior.
Para viabilizar o controle de acesso do IAM, o Amazon MSK faz pequenas modificações no código-fonte do Apache Kafka. Essas modificações não causarão uma diferença perceptível na sua experiência com o Apache Kafka. O Amazon MSK registra eventos de acesso para que você possa auditá-los.
Você pode invocar o Apache Kafka ACL APIs para um cluster MSK que usa o controle de acesso do IAM. No entanto, o Apache Kafka não ACLs tem efeito na autorização de identidades do IAM. Você deve usar políticas do IAM para controlar o acesso de identidades do IAM.
**Considerações importantes**
Ao usar o controle de acesso do IAM com o cluster do MSK, lembre das importantes considerações a seguir:
O controle de acesso do IAM não se aplica aos ZooKeeper nós do Apache. Para obter informações sobre como você pode controlar o acesso a esses nós, consulte [Controle o acesso aos ZooKeeper nós do Apache em seu cluster Amazon MSK](zookeeper-security.md).
A configuração `allow.everyone.if.no.acl.found` do Apache Kafka não tem efeito se seu cluster usar o controle de acesso do IAM.
Você pode invocar o Apache Kafka ACL APIs para um cluster MSK que usa o controle de acesso do IAM. No entanto, o Apache Kafka não ACLs tem efeito na autorização de identidades do IAM. Você deve usar políticas do IAM para controlar o acesso de identidades do IAM.
# Funcionamento do controle de acesso do IAM para o Amazon MSK
Para usar o controle de acesso do IAM para o Amazon MSK, execute as etapas a seguir, descritas em mais detalhes nestes tópicos:
+ [Criar um cluster do Amazon MSK que use o controle de acesso do IAM](create-iam-access-control-cluster-in-console.md)
+ [Configurar clientes para controle de acesso do IAM](configure-clients-for-iam-access-control.md)
+ [Criar políticas de autorização para o perfil do IAM](create-iam-access-control-policies.md)
+ [Obter os agente de bootstrap para controle de acesso do IAM](get-bootstrap-brokers-for-iam.md)
# Criar um cluster do Amazon MSK que use o controle de acesso do IAM
Esta seção explica como você pode usar a Console de gerenciamento da AWS API ou a AWS CLI para criar um cluster Amazon MSK que usa o controle de acesso do IAM. Para obter informações sobre como ativar o controle de acesso do IAM para um cluster existente, consulte [Atualizar as configurações de segurança de um cluster do Amazon MSK](msk-update-security.md).
**Use o Console de gerenciamento da AWS para criar um cluster que usa o controle de acesso do IAM**
1. Abra o console do Amazon MSK em [https://console.aws.amazon.com/msk/](https://console.aws.amazon.com/msk/).
1. Selecione **Criar cluster**.
1. Escolha **Criar cluster com configurações personalizadas**.
1. Na seção **Autenticação**, escolha **Controle de acesso do IAM**.
1. Preencha o restante do fluxo de trabalho para criar um cluster.
**Use a API ou a AWS CLI para criar um cluster que usa o controle de acesso do IAM**
+ Para criar um cluster com o controle de acesso IAM ativado, use a [CreateCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters.html#CreateCluster)API ou o comando da CLI [create-cluster](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/kafka/create-cluster.html) e passe o seguinte JSON para o parâmetro:. `ClientAuthentication` `"ClientAuthentication": { "Sasl": { "Iam": { "Enabled": true } }`
# Configurar clientes para controle de acesso do IAM
Para permitir que os clientes se comuniquem com um cluster do MSK que use o controle de acesso do IAM, você pode usar um dos seguintes mecanismos:
+ Configuração de cliente não Java usando mecanismo SASL\$1OAUTHBEARER
+ Configuração do cliente Java usando SASL\$1OAUTHBEARER mecanismo ou AWS\$1MSK\$1IAM mecanismo
## Use o SASL\$1OAUTHBEARER mecanismo para configurar o IAM
1. Edite o arquivo de configuração client.properties usando o exemplo do cliente do Python Kafka abaixo. As alterações das configurações são semelhantes em outros idiomas.
```
from kafka import KafkaProducer
from kafka.errors import KafkaError
from kafka.sasl.oauth import AbstractTokenProvider
import socket
import time
from aws_msk_iam_sasl_signer import MSKAuthTokenProvider
class MSKTokenProvider():
def token(self):
token, _ = MSKAuthTokenProvider.generate_auth_token('')
return token
tp = MSKTokenProvider()
producer = KafkaProducer(
bootstrap_servers='',
security_protocol='SASL_SSL',
sasl_mechanism='OAUTHBEARER',
sasl_oauth_token_provider=tp,
client_id=socket.gethostname(),
)
topic = ""
while True:
try:
inp=input(">")
producer.send(topic, inp.encode())
producer.flush()
print("Produced!")
except Exception:
print("Failed to send message:", e)
producer.close()
```
1. Baixe a biblioteca auxiliar para o idioma de configuração escolhido e siga as instruções na seção *Conceitos básicos* na página inicial desta biblioteca de idiomas.
+ JavaScript: [https://github.com/aws/aws-msk-iam-sasl-signer-js \$1getting -iniciado](https://github.com/aws/aws-msk-iam-sasl-signer-js#getting-started)
+ Python: [https://github.com/aws/aws-msk-iam-sasl-signer-python \$1get -started](https://github.com/aws/aws-msk-iam-sasl-signer-python#get-started)
+ Go: [https://github.com/aws/aws-msk-iam-sasl-signer-go](https://github.com/aws/aws-msk-iam-sasl-signer-go#getting-started) \$1getting -started
+ .NET: [https://github.com/aws/aws-msk-iam-sasl-signer-net](https://github.com/aws/aws-msk-iam-sasl-signer-net#getting-started) \$1getting -iniciado
+ JAVA: o SASL\$1OAUTHBEARER suporte para Java está disponível por meio do arquivo [https://github.com/aws/aws-msk-iam-auth/releases](https://github.com/aws/aws-msk-iam-auth/releases)jar
## Use o AWS\$1MSK\$1IAM mecanismo personalizado do MSK para configurar o IAM
1. Adicione o seguinte ao arquivo `client.properties`. **Substitua pelo caminho totalmente qualificado para o arquivo de armazenamento confiável no cliente.
**nota**
Se você não quiser usar um certificado específico, poderá remover `ssl.truststore.location=` do seu arquivo `client.properties`. Se você não especificar um valor para `ssl.truststore.location`, o processo Java usará o certificado padrão.
```
ssl.truststore.location=
security.protocol=SASL_SSL
sasl.mechanism=AWS_MSK_IAM
sasl.jaas.config=software.amazon.msk.auth.iam.IAMLoginModule required;
sasl.client.callback.handler.class=software.amazon.msk.auth.iam.IAMClientCallbackHandler
```
Para usar um perfil nomeado que você criou para AWS credenciais, inclua `awsProfileName="your profile name";` no arquivo de configuração do cliente. Para obter informações sobre perfis nomeados, consulte [Perfis nomeados](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-profiles.html) na AWS CLI documentação.
1. Baixe o arquivo [aws-msk-iam-auth](https://github.com/aws/aws-msk-iam-auth/releases)JAR estável mais recente e coloque-o no caminho da classe. Se você usa o Maven, adicione a seguinte dependência, ajustando o número da versão conforme necessário:
```
software.amazon.msk
aws-msk-iam-auth
1.0.0
```
O plug-in do cliente do Amazon MSK é de código aberto sob a licença do Apache 2.0.
# Criar políticas de autorização para o perfil do IAM
Anexe uma política de autorização ao perfil do IAM correspondente ao cliente. Em uma política de autorização, você especifica quais ações permitir ou proibir para o perfil. Se seu cliente estiver em uma instância do Amazon EC2, associe a política de autorização ao perfil do IAM para essa instância do Amazon EC2. Como alternativa, você pode configurar seu cliente para usar um perfil nomeado e, em seguida, associar a política de autorização ao perfil desse perfil nomeado. [Configurar clientes para controle de acesso do IAM](configure-clients-for-iam-access-control.md) descreve como configurar um cliente para usar um perfil nomeado.
Para obter informações sobre como criar uma política do IAM, consulte [Criar políticas do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html).
Veja a seguir um exemplo de política de autorização para um cluster chamado MyTestCluster. Para entender a semântica dos elementos `Action` e `Resource`, consulte [Semântica das ações e recursos da política de autorização do IAM](kafka-actions.md).
**Importante**
As alterações que você faz em uma política do IAM são refletidas no IAM APIs e AWS CLI imediatamente. No entanto, a implementação da alteração da política pode levar um tempo considerável. Na maioria dos casos, as mudanças na política entram em vigor em menos de um minuto. Às vezes, as condições da rede podem aumentar o atraso.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kafka-cluster:Connect",
"kafka-cluster:AlterCluster",
"kafka-cluster:DescribeCluster"
],
"Resource": [
"arn:aws:kafka:us-east-1:111122223333:cluster/MyTestCluster/abcd1234-0123-abcd-5678-1234abcd-1"
]
},
{
"Effect": "Allow",
"Action": [
"kafka-cluster:*Topic*",
"kafka-cluster:WriteData",
"kafka-cluster:ReadData"
],
"Resource": [
"arn:aws:kafka:us-east-1:123456789012:topic/MyTestCluster/*"
]
},
{
"Effect": "Allow",
"Action": [
"kafka-cluster:AlterGroup",
"kafka-cluster:DescribeGroup"
],
"Resource": [
"arn:aws:kafka:us-east-1:123456789012:group/MyTestCluster/*"
]
}
]
}
```
------
Para saber como criar uma política com elementos de ação que correspondam aos casos de uso comuns do Apache Kafka, como produzir e consumir dados, consulte [Casos de uso comuns para a política de autorização de clientes](iam-access-control-use-cases.md).
[Para as versões 2.8.0 e superiores do Kafka, a **WriteDataIdempotently**permissão está obsoleta (KIP-679).](https://cwiki.apache.org/confluence/display/KAFKA/KIP-679%3A+Producer+will+enable+the+strongest+delivery+guarantee+by+default) `enable.idempotence = true` é usado por padrão. Portanto, para as versões 2.8.0 e superiores do Kafka, o IAM não oferece a mesma funcionalidade do Kafka. ACLs Não é possível atribuir `WriteDataIdempotently` a um tópico fornecendo apenas acesso `WriteData` a esse tópico. Isso não afeta o caso quando `WriteData` é fornecido para **TODOS** os tópicos. Nesse caso, `WriteDataIdempotently` é permitido. Isso se deve às diferenças na implementação da lógica do IAM e na forma como os Kafka ACLs são implementados. E escrever em um tópico de forma idempotente também requer acesso a `transactional-ids`.
Para contornar a questão, recomendamos o uso de uma política semelhante à política abaixo.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"kafka-cluster:Connect",
"kafka-cluster:AlterCluster",
"kafka-cluster:DescribeCluster",
"kafka-cluster:WriteDataIdempotently"
],
"Resource": [
"arn:aws:kafka:us-east-1:123456789012:cluster/MyTestCluster/abcd1234-0123-abcd-5678-1234abcd-1"
]
},
{
"Effect": "Allow",
"Action": [
"kafka-cluster:*Topic*",
"kafka-cluster:WriteData",
"kafka-cluster:ReadData"
],
"Resource": [
"arn:aws:kafka:us-east-1:123456789012:topic/MyTestCluster/abcd1234-0123-abcd-5678-1234abcd-1/TestTopic",
"arn:aws:kafka:us-east-1:123456789012:transactional-id/MyTestCluster/abcd1234-0123-abcd-5678-1234abcd-1/*"
]
}
]
}
```
------
Nesse caso, `WriteData` permite gravações em `TestTopic`, enquanto `WriteDataIdempotently` permite gravações idempotentes no cluster. Essa política também adiciona acesso aos recursos `transactional-id` que serão necessários.
Como `WriteDataIdempotently` é uma permissão no nível do cluster, você não pode usá-la no nível do tópico. Se `WriteDataIdempotently` estiver restrita ao nível do tópico, essa política não funcionará.
# Obter os agente de bootstrap para controle de acesso do IAM
Consulte [Obter os agentes de bootstrap para um cluster do Amazon MSK](msk-get-bootstrap-brokers.md).
# Semântica das ações e recursos da política de autorização do IAM
**nota**
Para clusters que executam o Apache Kafka versão 3.8 ou posterior, o controle de acesso do IAM é compatível com a WriteTxnMarkers API para encerrar transações. Para clusters que executam versões do Kafka anteriores à 3.8, o controle de acesso do IAM não oferece suporte a ações internas de cluster, incluindo. WriteTxnMarkers Para essas versões anteriores, para encerrar transações, use a autenticação SCRAM ou mTLS com a autenticação apropriada ACLs em vez da autenticação IAM.
Esta seção explica a semântica dos elementos de ação e recurso que você pode usar em uma política de autorização do IAM. Para visualizar um exemplo de política, consulte [Criar políticas de autorização para o perfil do IAM](create-iam-access-control-policies.md).
## Ações da política de autorização
A tabela a seguir lista as ações que você pode incluir em uma política de autorização ao usar o controle de acesso do IAM para o Amazon MSK. Ao incluir uma ação da coluna *Ação* da tabela em sua política de autorização, você também deve incluir as ações correspondentes da coluna *Ações obrigatórias*.
| Ação | Description | Ações necessárias | Recursos necessários | Aplicável a clusters com a tecnologia sem servidor |
| --- | --- | --- | --- | --- |
| kafka-cluster:Connect | Concede permissão para se conectar e se autenticar no cluster. | Nenhum | cluster | Sim |
| kafka-cluster:DescribeCluster | Concede permissão para descrever vários aspectos do cluster, equivalente à ACL DESCRIBE CLUSTER do Apache Kafka. | `kafka-cluster:Connect` | cluster | Sim |
| kafka-cluster:AlterCluster | Concede permissão para alterar vários aspectos do cluster, equivalente à ACL ALTER CLUSTER do Apache Kafka. | `kafka-cluster:Connect` `kafka-cluster:DescribeCluster` | cluster | Não |
| kafka-cluster:DescribeClusterDynamicConfiguration | Concede permissão para descrever a configuração dinâmica de um cluster, equivalente à ACL DESCRIBE\$1CONFIGS CLUSTER do Apache Kafka. | `kafka-cluster:Connect` | cluster | Não |
| kafka-cluster:AlterClusterDynamicConfiguration | Concede permissão para alterar a configuração dinâmica de um cluster, equivalente à ACL ALTER\$1CONFIGS CLUSTER do Apache Kafka. | `kafka-cluster:Connect` `kafka-cluster:DescribeClusterDynamicConfiguration` | cluster | Não |
| kafka-cluster:WriteDataIdempotently | Concede permissão para gravar dados em um cluster de modo idempotente, equivalente à ACL IDEMPOTENT\$1WRITE CLUSTER do Apache Kafka. | `kafka-cluster:Connect` `kafka-cluster:WriteData` | cluster | Sim |
| kafka-cluster:CreateTopic | Concede permissão para criar tópicos em um cluster, equivalente à CREATE ACL do Apache Kafka. CLUSTER/TOPIC | `kafka-cluster:Connect` | tópico | Sim |
| kafka-cluster:DescribeTopic | Concede permissão para descrever os tópicos de um cluster, equivalente à ACL DESCRIBE TOPIC do Apache Kafka. | `kafka-cluster:Connect` | tópico | Sim |
| kafka-cluster:AlterTopic | Concede permissão para alterar os tópicos de um cluster, equivalente à ACL ALTER TOPIC do Apache Kafka. | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` | tópico | Sim |
| kafka-cluster:DeleteTopic | Concede permissão para excluir tópicos de um cluster, equivalente à ACL DELETE TOPIC do Apache Kafka. | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` | tópico | Sim |
| kafka-cluster:DescribeTopicDynamicConfiguration | Concede permissão para descrever a configuração dinâmica dos tópicos de um cluster, equivalente à ACL DESCRIBE\$1CONFIGS TOPIC do Apache Kafka. | `kafka-cluster:Connect` | tópico | Sim |
| kafka-cluster:AlterTopicDynamicConfiguration | Concede permissão para alterar a configuração dinâmica dos tópicos de um cluster, equivalente à ACL ALTER\$1CONFIGS TOPIC do Apache Kafka. | `kafka-cluster:Connect` `kafka-cluster:DescribeTopicDynamicConfiguration` | tópico | Sim |
| kafka-cluster:ReadData | Concede permissão para ler dados dos tópicos de um cluster, equivalente à ACL READ TOPIC do Apache Kafka. | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:AlterGroup` | tópico | Sim |
| kafka-cluster:WriteData | Concede permissão para gravar dados em tópicos de um cluster, equivalente a WRITE TOPIC ACL do Apache Kafka. | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` | tópico | Sim |
| kafka-cluster:DescribeGroup | Concede permissão para descrever os grupos de um cluster, equivalente à ACL DESCRIBE GROUP do Apache Kafka. | `kafka-cluster:Connect` | grupo | Sim |
| kafka-cluster:AlterGroup | Concede permissão para entrar em grupos de um cluster, equivalente à ACL READ GROUP do Apache Kafka. | `kafka-cluster:Connect` `kafka-cluster:DescribeGroup` | grupo | Sim |
| kafka-cluster:DeleteGroup | Concede permissão para excluir grupos de um cluster, equivalente à ACL DELETE GROUP do Apache Kafka. | `kafka-cluster:Connect` `kafka-cluster:DescribeGroup` | grupo | Sim |
| kafka-cluster:DescribeTransactionalId | Concede permissão para descrever transações IDs em um cluster, equivalente à ACL DESCRIBE TRANSACTIONAL\$1ID do Apache Kafka. | `kafka-cluster:Connect` | transactional-id | Sim |
| kafka-cluster:AlterTransactionalId | Concede permissão para alterar a transação IDs em um cluster, equivalente à ACL WRITE TRANSACTIONAL\$1ID do Apache Kafka. | `kafka-cluster:Connect` `kafka-cluster:DescribeTransactionalId` `kafka-cluster:WriteData` | transactional-id | Sim |
Você pode usar o curinga asterisco (\$1) quantas vezes quiser em uma ação após o sinal de dois pontos. Veja os exemplos a seguir.
+ `kafka-cluster:*Topic` corresponde a `kafka-cluster:CreateTopic`, `kafka-cluster:DescribeTopic`, `kafka-cluster:AlterTopic` e `kafka-cluster:DeleteTopic`. Isso não inclui `kafka-cluster:DescribeTopicDynamicConfiguration` ou `kafka-cluster:AlterTopicDynamicConfiguration`.
+ `kafka-cluster:*` corresponde a todas as permissões.
## Recursos da política de autorização
A tabela a seguir mostra os quatro tipos de recurso que você pode usar em uma política de autorização ao usar o controle de acesso do IAM para o Amazon MSK. Você pode obter o Amazon Resource Name (ARN) do cluster no Console de gerenciamento da AWS ou usando a [DescribeCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster)API ou o comando [AWS CLI describe-cluster](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/kafka/describe-cluster.html). Em seguida, você pode usar o ARN do cluster para criar ID de tópico, grupo e transação. ARNs Para especificar um recurso em uma política de autorização, use o ARN desse recurso.
| Recurso | Formato ARN |
| --- | --- |
| Cluster | arn:aws:kafka: ::cluster//regionaccount-idcluster-namecluster-uuid |
| Tópico | ar:aws:kafka: ::topic///regionaccount-idcluster-namecluster-uuidtopic-name |
| Group (Grupo) | arn:aws:kafka: ::group///regionaccount-idcluster-namecluster-uuidgroup-name |
| ID transacional | arn:aws:kafka: ::transactional-id///regionaccount-idcluster-namecluster-uuidtransactional-id |
Você pode usar o curinga asterisco (\$1) quantas vezes quiser em qualquer lugar na parte do ARN que vem depois de `:cluster/`, `:topic/`, `:group/` e `:transactional-id/`. Veja a seguir alguns exemplos de como usar o curinga asterisco (\$1) para se referir a vários recursos:
+ `arn:aws:kafka:us-east-1:0123456789012:topic/MyTestCluster/*`: todos os tópicos em qualquer cluster nomeado MyTestCluster, independentemente do UUID do cluster.
+ `arn:aws:kafka:us-east-1:0123456789012:topic/MyTestCluster/abcd1234-0123-abcd-5678-1234abcd-1/*_test`: todos os tópicos cujo nome termina com “\$1test” no cluster cujo nome é MyTestCluster e cujo UUID é abcd1234-0123-abcd-5678-1234abcd-1.
+ `arn:aws:kafka:us-east-1:0123456789012:transactional-id/MyTestCluster/*/5555abcd-1111-abcd-1234-abcd1234-1`: todas as transações cuja ID transacional é 5555abcd-1111-abcd-1234-abcd1234-1, em todas as encarnações de um cluster nomeado em sua conta. MyTestCluster Isso significa que, se você criar um cluster chamado MyTestCluster, excluí-lo e criar outro cluster com o mesmo nome, poderá usar esse ARN de recurso para representar a mesma ID de transação nos dois clusters. No entanto, o cluster excluído não estará acessível.
# Casos de uso comuns para a política de autorização de clientes
A primeira coluna na tabela a seguir mostra alguns casos de uso comuns. Para autorizar um cliente a executar um determinado caso de uso, inclua as ações necessárias para esse caso de uso na política de autorização do cliente e defina `Effect` como `Allow`.
Para obter informações sobre todas as ações que fazem parte do controle de acesso do IAM para o Amazon MSK, consulte [Semântica das ações e recursos da política de autorização do IAM](kafka-actions.md).
**nota**
As ações são negadas por padrão. Você deve permitir explicitamente todas as ações que deseja autorizar o cliente a executar.
****
| Caso de uso | Ações necessárias |
| --- | --- |
| Administrador | `kafka-cluster:*` |
| Criar um tópico | `kafka-cluster:Connect` `kafka-cluster:CreateTopic` |
| Produzir dados | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:WriteData` |
| Consumir dados | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:DescribeGroup` `kafka-cluster:AlterGroup` `kafka-cluster:ReadData` |
| Produzir dados de modo idempotente | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:WriteData` `kafka-cluster:WriteDataIdempotently` |
| Produzir dados de modo transacional | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:WriteData` `kafka-cluster:DescribeTransactionalId` `kafka-cluster:AlterTransactionalId` |
| Descrever a configuração de um cluster | `kafka-cluster:Connect` `kafka-cluster:DescribeClusterDynamicConfiguration` |
| Atualizar a configuração de um cluster | `kafka-cluster:Connect` `kafka-cluster:DescribeClusterDynamicConfiguration` `kafka-cluster:AlterClusterDynamicConfiguration` |
| Descrever a configuração de um tópico | `kafka-cluster:Connect` `kafka-cluster:DescribeTopicDynamicConfiguration` |
| Atualizar a configuração de um tópico | `kafka-cluster:Connect` `kafka-cluster:DescribeTopicDynamicConfiguration` `kafka-cluster:AlterTopicDynamicConfiguration` |
| Alterar um tópico | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:AlterTopic` |
# Autenticação mútua de cliente TLS para o Amazon MSK
Você pode habilitar a autenticação do cliente com TLS para conexões das aplicações aos agentes do Amazon MSK. Para usar a autenticação do cliente, é necessário ter um CA privada da AWS. Eles CA privada da AWS podem estar no Conta da AWS mesmo cluster ou em uma conta diferente. Para obter informações sobre CA privada da AWS s, consulte [Criando e gerenciando um CA privada da AWS](https://docs.aws.amazon.com/acm-pca/latest/userguide/create-CA.html).
O Amazon MSK não oferece suporte a listas de revogação de certificados (). CRLs Para controlar o acesso aos tópicos do cluster ou bloquear certificados comprometidos, use o Apache Kafka ACLs e grupos de segurança. AWS Para obter informações sobre como usar o Apache Kafka ACLs, consulte. [Apache Kafka ACLs](msk-acls.md)
**Topics**
+ [Criar um cluster do Amazon MSK compatível com a autenticação de cliente](msk-authentication-cluster.md)
+ [Configurar um cliente para usar a autenticação](msk-authentication-client.md)
+ [Produzir e consumir mensagens usando autenticação](msk-authentication-messages.md)
# Criar um cluster do Amazon MSK compatível com a autenticação de cliente
Este procedimento mostra como habilitar a autenticação do cliente usando um CA privada da AWS.
**nota**
É altamente recomendável usar o independente CA privada da AWS para cada cluster MSK ao usar o TLS mútuo para controlar o acesso. Isso garantirá que os certificados TLS assinados por sejam autenticados PCAs apenas com um único cluster MSK.
1. Crie um arquivo denominado `clientauthinfo.json` com os conteúdos a seguir. *Private-CA-ARN*Substitua pelo ARN do seu PCA.
```
{
"Tls": {
"CertificateAuthorityArnList": ["Private-CA-ARN"]
}
}
```
1. Crie um arquivo chamado `brokernodegroupinfo.json`, conforme descrito em [Crie um cluster Amazon MSK provisionado usando o AWS CLI](create-cluster-cli.md).
1. A autenticação de cliente exige que você também ative a criptografia em trânsito entre clientes e agentes. Crie um arquivo denominado `encryptioninfo.json` com os conteúdos a seguir. *KMS-Key-ARN*Substitua pelo ARN da sua chave KMS. É possível definir `ClientBroker` como `TLS` ou `TLS_PLAINTEXT`.
```
{
"EncryptionAtRest": {
"DataVolumeKMSKeyId": "KMS-Key-ARN"
},
"EncryptionInTransit": {
"InCluster": true,
"ClientBroker": "TLS"
}
}
```
Para obter mais informações sobre criptografia, consulte [Criptografia do Amazon MSK](msk-encryption.md).
1. Em uma máquina em que você tenha o AWS CLI instalado, execute o comando a seguir para criar um cluster com a autenticação e a criptografia em trânsito habilitadas. Salve o ARN do cluster fornecido na resposta.
```
aws kafka create-cluster --cluster-name "AuthenticationTest" --broker-node-group-info file://brokernodegroupinfo.json --encryption-info file://encryptioninfo.json --client-authentication file://clientauthinfo.json --kafka-version "{YOUR KAFKA VERSION}" --number-of-broker-nodes 3
```
# Configurar um cliente para usar a autenticação
Este processo descreve como configurar uma instância do Amazon EC2 para ser usada como cliente para autenticação.
Este processo descreve como produzir e consumir mensagens usando a autenticação criando uma máquina cliente, criando um tópico e definindo as configurações de segurança necessárias.
1. Crie uma instância do Amazon EC2 para ser usada como uma máquina cliente. Para simplificar, crie essa instância na mesma VPC usada para o cluster. Consulte [Etapa 3: criar uma máquina cliente](create-client-machine.md) para obter um exemplo de como criar uma máquina de cliente.
1. Criar um tópico. Para obter um exemplo, consulte as instruções em [Etapa 4: criar um tópico no cluster do Amazon MSK](create-topic.md).
1. Em uma máquina em que você tem o AWS CLI instalado, execute o comando a seguir para obter os corretores de bootstrap do cluster. *Cluster-ARN*Substitua pelo ARN do seu cluster.
```
aws kafka get-bootstrap-brokers --cluster-arn Cluster-ARN
```
Salve a string associada ao `BootstrapBrokerStringTls` na resposta.
1. Na máquina de cliente, execute o comando a seguir para usar o armazenamento de confiança da JVM para criar o armazenamento de confiança do cliente. Se o caminho da JVM for diferente, ajuste o comando de acordo.
```
cp /usr/lib/jvm/java-1.8.0-openjdk-1.8.0.201.b09-0.amzn2.x86_64/jre/lib/security/cacerts kafka.client.truststore.jks
```
1. Na máquina de cliente, execute o comando a seguir para criar uma chave privada para o cliente. Substitua *Distinguished-Name**Example-Alias*,*Your-Store-Pass*,, e *Your-Key-Pass* por cordas de sua escolha.
```
keytool -genkey -keystore kafka.client.keystore.jks -validity 300 -storepass Your-Store-Pass -keypass Your-Key-Pass -dname "CN=Distinguished-Name" -alias Example-Alias -storetype pkcs12 -keyalg rsa
```
1. Na máquina de cliente, execute o comando a seguir para criar uma solicitação de certificado com a chave privada criada na etapa anterior.
```
keytool -keystore kafka.client.keystore.jks -certreq -file client-cert-sign-request -alias Example-Alias -storepass Your-Store-Pass -keypass Your-Key-Pass
```
1. Abra o arquivo `client-cert-sign-request` e verifique se ele começa com `-----BEGIN CERTIFICATE REQUEST-----` e termina com `-----END CERTIFICATE REQUEST-----`. Se ele começar com `-----BEGIN NEW CERTIFICATE REQUEST-----`, exclua a palavra `NEW` (e o espaço único que vem após) do começo e do final do arquivo.
1. Em uma máquina em que você tenha o AWS CLI instalado, execute o comando a seguir para assinar sua solicitação de certificado. *Private-CA-ARN*Substitua pelo ARN do seu PCA. Será possível alterar o valor de validade se quiser. Aqui usamos 300 como exemplo.
```
aws acm-pca issue-certificate --certificate-authority-arn Private-CA-ARN --csr fileb://client-cert-sign-request --signing-algorithm "SHA256WITHRSA" --validity Value=300,Type="DAYS"
```
Salve o ARN do certificado fornecido na resposta.
**nota**
Para recuperar seu certificado de cliente, use o comando `acm-pca get-certificate` e especifique o ARN do certificado. Para obter mais informações, consulte [get-certificate](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/acm-pca/get-certificate.html) na *Referência de comandos da AWS CLI *.
1. Execute o comando a seguir para obter o certificado CA privada da AWS assinado para você. *Certificate-ARN*Substitua pelo ARN obtido da resposta ao comando anterior.
```
aws acm-pca get-certificate --certificate-authority-arn Private-CA-ARN --certificate-arn Certificate-ARN
```
1. Do resultado JSON obtido com a execução do comando anterior, copie as strings associadas a `Certificate` e `CertificateChain`. Cole essas duas sequências em um novo arquivo chamado signed-certificate-from-acm. Cole a string associada a `Certificate` primeiro, seguida pela string associada a `CertificateChain`. Substitua os caracteres `\n` por novas linhas. Veja a seguir a estrutura do arquivo depois que você colar o certificado e a cadeia de certificados nele.
```
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
...
-----END CERTIFICATE-----
```
1. Execute o comando a seguir na máquina cliente para adicionar esse certificado ao repositório de chaves para poder apresentá-lo ao falar com os agentes do MSK.
```
keytool -keystore kafka.client.keystore.jks -import -file signed-certificate-from-acm -alias Example-Alias -storepass Your-Store-Pass -keypass Your-Key-Pass
```
1. Crie um arquivo denominado `client.properties` com os conteúdos a seguir. Ajuste os locais do armazenamento de confiança e do repositório de chaves usando os caminhos onde salvou `kafka.client.truststore.jks`. Substitua os espaços reservados por sua versão do cliente Kafka. *\$1YOUR KAFKA VERSION\$1*
```
security.protocol=SSL
ssl.truststore.location=/tmp/kafka_2.12-{YOUR KAFKA VERSION}/kafka.client.truststore.jks
ssl.keystore.location=/tmp/kafka_2.12-{YOUR KAFKA VERSION}/kafka.client.keystore.jks
ssl.keystore.password=Your-Store-Pass
ssl.key.password=Your-Key-Pass
```
# Produzir e consumir mensagens usando autenticação
Este processo descreve como produzir e consumir mensagens usando a autenticação.
1. Execute o comando a seguir para criar um tópico. O arquivo chamado `client.properties` é o que você criou no procedimento anterior.
```
/bin/kafka-topics.sh --create --bootstrap-server BootstrapBroker-String --replication-factor 3 --partitions 1 --topic ExampleTopic --command-config client.properties
```
1. Execute o comando a seguir para iniciar um produtor de console. O arquivo chamado `client.properties` é o que você criou no procedimento anterior.
```
/bin/kafka-console-producer.sh --bootstrap-server BootstrapBroker-String --topic ExampleTopic --producer.config client.properties
```
1. Em uma nova janela de comando na máquina de cliente, execute o comando a seguir para iniciar um consumidor de console.
```
/bin/kafka-console-consumer.sh --bootstrap-server BootstrapBroker-String --topic ExampleTopic --consumer.config client.properties
```
1. Digite mensagens na janela do produtor e observe-as aparecerem na janela do consumidor.
# Autenticação de credenciais de login com Secrets Manager AWS
Você pode controlar o acesso aos seus clusters do Amazon MSK usando credenciais de login que são armazenadas e protegidas usando o Secrets Manager. AWS Armazenar as credenciais de usuário no Secrets Manager reduz a sobrecarga da autenticação do cluster, como auditoria, atualização e rodízio de credenciais. O Secrets Manager também permite que você compartilhe credenciais de usuário entre clusters.
Depois que você associar um segredo a um cluster do MSK, o MSK sincronizará periodicamente os dados da credencial.
**Topics**
+ [Como a autenticação de credenciais de acesso funciona](msk-password-howitworks.md)
+ [Configurar a SASL/SCRAM autenticação para um cluster Amazon MSK](msk-password-tutorial.md)
+ [Trabalhar com usuários](msk-password-users.md)
+ [Limitações ao usar segredos do SCRAM](msk-password-limitations.md)
# Como a autenticação de credenciais de acesso funciona
A autenticação de credenciais de login para o Amazon MSK usa a autenticação SASL/SCRAM (Simple Authentication and Security Layer/Salted Challenge Response Mechanism). Para configurar a autenticação de credenciais de acesso para um cluster, você cria um recurso secreto no [AWS Secrets Manager](https://docs.aws.amazon.com//secretsmanager/?id=docs_gateway) e associa as credenciais de acesso a esse segredo.
O SASL/SCRAM está definido no [RFC 5802](https://tools.ietf.org/html/rfc5802). O SCRAM usa algoritmos de hash protegidos e não transmite credenciais em texto simples entre o cliente e o servidor.
**nota**
Quando você configura a SASL/SCRAM autenticação para seu cluster, o Amazon MSK ativa a criptografia TLS para todo o tráfego entre clientes e agentes.
# Configurar a SASL/SCRAM autenticação para um cluster Amazon MSK
Para configurar um segredo no AWS Secrets Manager, siga o tutorial [Criando e recuperando um segredo](https://docs.aws.amazon.com/secretsmanager/latest/userguide/tutorials_basic.html) no [Guia do usuário do AWS Secrets Manager](https://docs.aws.amazon.com/secretsmanager/latest/userguide/intro.html).
Observe os seguintes requisitos ao criar um segredo para um cluster do Amazon MSK:
+ Escolha **Outros tipos de segredos (p. ex., chave de API)** para o tipo de segredo.
+ O nome do segredo deve começar com o prefixo **AmazonMSK\$1**.
+ Você deve usar uma AWS KMS chave personalizada existente ou criar uma nova AWS KMS chave personalizada para seu segredo. O Secrets Manager usa a AWS KMS chave padrão para um segredo por padrão.
**Importante**
Um segredo criado com a AWS KMS chave padrão não pode ser usado com um cluster Amazon MSK.
+ Seus dados de credencial de acesso devem estar no formato a seguir para que seja possível inserir pares de valor/chave usando a opção **Texto simples**.
```
{
"username": "alice",
"password": "alice-secret"
}
```
+ Registre o valor do ARN (nome do recurso da Amazon) do seu segredo.
+
**Importante**
Você não pode associar um segredo do Secrets Manager a um cluster que exceda os limites descritos em [Dimensione seu cluster adequadamente: número de partições por agente Standard](bestpractices.md#partitions-per-broker).
+ Se você usar o AWS CLI para criar o segredo, especifique um ID de chave ou ARN para o `kms-key-id` parâmetro. Não especifique um alias.
+ Para associar o segredo ao seu cluster, use o console Amazon MSK ou a [ BatchAssociateScramSecret](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-scram-secrets.html#BatchAssociateScramSecret)operação.
**Importante**
Quando você associa um segredo a um cluster, o Amazon MSK anexa uma política de recursos ao segredo, permitindo que seu cluster acesse e leia os valores secretos que você definiu. Você não deve modificar essa política de recursos. Isso pode impedir que seu cluster acesse seu segredo. Se você fizer alguma alteração na política de recursos de segredos e/ou na chave KMS usada para criptografia secreta, certifique-se de associar novamente os segredos ao seu cluster do MSK. Isso garantirá que seu cluster conseguirá continuar a acessar seu segredo.
O exemplo de entrada JSON a seguir para a operação `BatchAssociateScramSecret` associa um segredo a um cluster:
```
{
"clusterArn" : "arn:aws:kafka:us-west-2:0123456789019:cluster/SalesCluster/abcd1234-abcd-cafe-abab-9876543210ab-4",
"secretArnList": [
"arn:aws:secretsmanager:us-west-2:0123456789019:secret:AmazonMSK_MyClusterSecret"
]
}
```
# Como estabelecer conexão com o seu cluster usando credenciais de acesso
Após criar um segredo e associá-lo ao cluster, você poderá conectar o cliente ao cluster. O procedimento a seguir demonstra como conectar um cliente a um cluster que usa SASL/SCRAM autenticação. Também mostra como produzir e consumir a partir de um tópico de exemplo.
**Topics**
+ [Conectando um cliente ao cluster usando SASL/SCRAM autenticação](#w2aab9c13c29c17c13c11b9b7)
+ [Solução de problemas de conexão](#msk-password-tutorial-connect-troubleshooting)
## Conectando um cliente ao cluster usando SASL/SCRAM autenticação
1. Execute o comando a seguir em uma máquina que tenha sido AWS CLI instalada. *clusterARN*Substitua pelo ARN do seu cluster.
```
aws kafka get-bootstrap-brokers --cluster-arn clusterARN
```
No JSON resultante deste comando, salve o valor associado à string `BootstrapBrokerStringSaslScram`. Você usará esse valor em etapas subsequentes.
1. Em sua máquina cliente, crie um arquivo de configuração JAAS contendo as credenciais de usuário armazenadas em seu segredo. Por exemplo, para o usuário **alice**, crie um arquivo chamado `users_jaas.conf` com o conteúdo a seguir.
```
KafkaClient {
org.apache.kafka.common.security.scram.ScramLoginModule required
username="alice"
password="alice-secret";
};
```
1. Use o comando a seguir para exportar seu arquivo de configuração JAAS como um parâmetro de ambiente `KAFKA_OPTS`.
```
export KAFKA_OPTS=-Djava.security.auth.login.config=/users_jaas.conf
```
1. Crie um arquivo chamado `kafka.client.truststore.jks` em um diretório `/tmp`.
1. (Opcional) Use o comando a seguir para copiar o arquivo de armazenamento de chaves do JDK da sua pasta de `cacerts` do JVM para o arquivo `kafka.client.truststore.jks` que você criou na etapa anterior. *JDKFolder*Substitua pelo nome da pasta JDK na sua instância. Por exemplo, sua pasta do JDK pode ter o nome `java-1.8.0-openjdk-1.8.0.201.b09-0.amzn2.x86_64`.
```
cp /usr/lib/jvm/JDKFolder/lib/security/cacerts /tmp/kafka.client.truststore.jks
```
1. No diretório `bin` da instalação do Apache Kafka, crie um arquivo de propriedades do cliente chamado `client_sasl.properties` com o conteúdo a seguir. Esse arquivo define o mecanismo e o protocolo SASL.
```
security.protocol=SASL_SSL
sasl.mechanism=SCRAM-SHA-512
```
1. Para criar um tópico de exemplo, execute o comando a seguir. *BootstrapBrokerStringSaslScram*Substitua pela string do bootstrap broker que você obteve na etapa 1 deste tópico.
```
/bin/kafka-topics.sh --create --bootstrap-server BootstrapBrokerStringSaslScram --command-config /client_sasl.properties --replication-factor 3 --partitions 1 --topic ExampleTopicName
```
1. Para produzir o tópico de exemplo que você criou, execute o seguinte comando em sua máquina cliente. *BootstrapBrokerStringSaslScram*Substitua pela string do bootstrap broker que você recuperou na etapa 1 deste tópico.
```
/bin/kafka-console-producer.sh --broker-list BootstrapBrokerStringSaslScram --topic ExampleTopicName --producer.config client_sasl.properties
```
1. Para consumir do tópico que você criou, execute o comando a seguir em sua máquina cliente. *BootstrapBrokerStringSaslScram*Substitua pela string do bootstrap broker que você obteve na etapa 1 deste tópico.
```
/bin/kafka-console-consumer.sh --bootstrap-server BootstrapBrokerStringSaslScram --topic ExampleTopicName --from-beginning --consumer.config client_sasl.properties
```
## Solução de problemas de conexão
Ao executar comandos do cliente do Kafka, você pode encontrar erros de memória da pilha de Java, especialmente ao trabalhar com tópicos ou conjuntos de dados grandes. Esses erros ocorrem porque as ferramentas do Kafka são executadas como aplicações Java com configurações de memória padrão que podem ser insuficientes para sua workload.
Para resolver erros de `Out of Memory Java Heap`, você pode aumentar o tamanho da pilha de Java modificando a variável de ambiente `KAFKA_OPTS` para incluir configurações de memória.
O exemplo a seguir define o tamanho máximo da pilha como 1 GB (`-Xmx1G`). Você pode ajustar esse valor com base na memória e nos requisitos disponíveis do sistema.
```
export KAFKA_OPTS="-Djava.security.auth.login.config=/users_jaas.conf -Xmx1G"
```
Para consumir tópicos extensos, considere usar parâmetros baseados em tempo ou em deslocamento em vez de `--from-beginning` para limitar o uso de memória:
```
/bin/kafka-console-consumer.sh --bootstrap-server BootstrapBrokerStringSaslScram --topic ExampleTopicName --max-messages 1000 --consumer.config client_sasl.properties
```
# Trabalhar com usuários
**Criação de usuários**: você cria usuários como pares de valor/chave em seu segredo. Ao usar a opção **Texto simples** no console do Secrets Manager, você deve especificar os dados da credencial de login no formato a seguir.
```
{
"username": "alice",
"password": "alice-secret"
}
```
**Revogando o acesso do usuário:** para revogar as credenciais de um usuário para acessar um cluster, recomendamos que primeiro você remova ou force uma ACL no cluster e depois desassocie o segredo. Isso se dá pelo seguinte:
+ A remoção de um usuário não fecha as conexões existentes.
+ A propagação de alterações em seu segredo levam até 10 minutos.
Para obter informações sobre como usar uma ACL com o Amazon MSK, consulte [Apache Kafka ACLs](msk-acls.md).
Para clusters usando o ZooKeeper modo, recomendamos que você restrinja o acesso aos seus ZooKeeper nós para evitar que os usuários ACLs modifiquem. Para obter mais informações, consulte [Controle o acesso aos ZooKeeper nós do Apache em seu cluster Amazon MSK](zookeeper-security.md).
# Limitações ao usar segredos do SCRAM
Observe as seguintes limitações ao usar segredos SCRAM:
+ O Amazon MSK só é compatível com a autenticação SCRAM-SHA-512.
+ Um cluster do Amazon MSK pode ter até 1.000 usuários.
+ Você deve usar um AWS KMS key com seu segredo. Você não pode usar um segredo que use a chave de criptografia padrão do Secrets Manager com o Amazon MSK. Para obter informações sobre a criação de uma chave do KMS, consulte [Criação de chaves do KMS de criptografia simétrica](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html#create-symmetric-cmk).
+ Não é possível usar uma chave assimétrica do KMS com o Secrets Manager.
+ Você pode associar até 10 segredos a um cluster por vez usando a [ BatchAssociateScramSecret](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-scram-secrets.html#BatchAssociateScramSecret)operação.
+ O nome dos segredos associados a um cluster do Amazon MSK deve ter o prefixo **AmazonMSK\$1**.
+ Os segredos associados a um cluster do Amazon MSK devem estar na mesma conta e AWS região da Amazon Web Services do cluster.
# Apache Kafka ACLs
O Apache Kafka tem um autorizador conectável e vem com uma implementação autorizadora. out-of-box O Amazon MSK habilita esse autorizador no arquivo `server.properties` dos agentes.
O Apache Kafka ACLs tem o formato “Principal P é [Permitida/Negada] Operação O do Host H em qualquer recurso R correspondente a RP”. ResourcePattern Se RP não corresponder a um recurso específico R, então R não tem nenhum associado e ACLs, portanto, ninguém além de superusuários tem permissão para acessar R. Para alterar esse comportamento do Apache Kafka, você define a propriedade como verdadeira. `allow.everyone.if.no.acl.found` O Amazon MSK a define como true por padrão. Isso significa que, com os clusters do Amazon MSK, se você não definir ACLs explicitamente um recurso, todos os principais poderão acessar esse recurso. Se você ACLs ativar um recurso, somente os diretores autorizados poderão acessá-lo. Se você quiser restringir o acesso a um tópico e autorizar um cliente usando a autenticação mútua TLS, adicione ACLs usando a CLI autorizadora do Apache Kafka. Para obter mais informações sobre adição, remoção e listagem ACLs, consulte Interface de [linha de comando de autorização do Kafka](https://cwiki.apache.org/confluence/display/KAFKA/Kafka+Authorization+Command+Line+Interface).
Como o Amazon MSK configura os agentes como superusuários, eles podem acessar todos os tópicos. Isso ajuda os agentes a replicar mensagens da partição primária, quer a `allow.everyone.if.no.acl.found` propriedade esteja definida ou não para a configuração do cluster.
**Como adicionar ou remover o acesso de leitura e gravação a um tópico**
1. Adicione seus corretores à tabela da ACL para permitir que eles leiam todos os tópicos existentes ACLs . Para conceder acesso de leitura a um tópico para os seus agentes, execute o comando a seguir em uma máquina cliente capaz de se comunicar com o cluster do MSK.
*Distinguished-Name*Substitua pelo DNS de qualquer um dos corretores de bootstrap do seu cluster e, em seguida, substitua a string antes do primeiro ponto nesse nome distinto por um asterisco (). `*` Por exemplo, se um dos corretores de bootstrap do seu cluster tiver o DNS`b-6.mytestcluster.67281x.c4.kafka.us-east-1.amazonaws.com`, *Distinguished-Name* substitua o comando a seguir por. `*.mytestcluster.67281x.c4.kafka.us-east-1.amazonaws.com` Para ver informações sobre como obter os agentes de bootstrap, consulte [Obter os agentes de bootstrap para um cluster do Amazon MSK](msk-get-bootstrap-brokers.md).
```
/bin/kafka-acls.sh --bootstrap-server BootstrapServerString --add --allow-principal "User:CN=Distinguished-Name" --operation Read --group=* --topic Topic-Name
```
1. Para conceder acesso de leitura a uma aplicação cliente, execute o comando a seguir na máquina de cliente. Se você usa a autenticação TLS mútua, use a mesma usada *Distinguished-Name* quando criou a chave privada.
```
/bin/kafka-acls.sh --bootstrap-server BootstrapServerString --add --allow-principal "User:CN=Distinguished-Name" --operation Read --group=* --topic Topic-Name
```
Para remover o acesso de leitura, é possível executar o mesmo comando, substituindo `--add` por `--remove`.
1. Para conceder acesso de gravação a um tópico, execute o comando a seguir na máquina de cliente. Se você usa a autenticação TLS mútua, use a mesma usada *Distinguished-Name* quando criou a chave privada.
```
/bin/kafka-acls.sh --bootstrap-server BootstrapServerString --add --allow-principal "User:CN=Distinguished-Name" --operation Write --topic Topic-Name
```
Para remover o acesso de gravação, é possível executar o mesmo comando, substituindo `--add` por `--remove`.
# Alterar o grupo de segurança do cluster no Amazon MSK
Esta página explica como alterar o grupo de segurança de um cluster existente do MSK. Talvez seja necessário alterar o grupo de segurança de um cluster para fornecer acesso a um determinado conjunto de usuários ou limitar o acesso ao cluster. Para obter mais informações sobre grupos de segurança, consulte [Grupos de segurança para sua VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) no Guia do usuário da Amazon VPC.
1. Use a [ListNodes](https://docs.amazonaws.cn/en_us/msk/1.0/apireference/clusters-clusterarn-nodes.html#ListNodes)API ou o comando [list-nodes](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/kafka/list-nodes.html) no AWS CLI para obter uma lista dos corretores em seu cluster. Os resultados dessa operação incluem as interfaces IDs de rede elástica (ENIs) associadas aos corretores.
1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon EC2 em. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)
1. Usando a lista suspensa no canto superior direito da tela, selecione a região na qual o cluster está implantado.
1. No painel esquerdo, em **Rede e Segurança**, escolha **Interfaces de rede**.
1. Selecione a primeira ENI que você obteve na primeira etapa. Escolha o menu **Ações** na parte superior da tela e escolha **Alterar grupos de segurança**. Atribua o novo grupo de segurança a essa ENI. Repita essa etapa para cada uma das ENIs que você obteve na primeira etapa.
**nota**
As alterações que você fizer no grupo de segurança de um cluster usando o console do Amazon EC2 não serão refletidas no console do MSK em **Configurações de rede**.
1. Configure as regras do novo grupo de segurança para garantir que seus clientes tenham acesso aos agentes. Para obter informações sobre como configurar regras de grupo de segurança, consulte [Adicionar, remover e atualizar regras](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html?shortFooter=true#AddRemoveRules) no guia do usuário da Amazon VPC.
**Importante**
Se você alterar o grupo de segurança associado aos agentes de um cluster e depois adicionar novos agentes a esse cluster, o Amazon MSK associará os novos agentes ao grupo de segurança original que estava associado ao cluster quando o cluster foi criado. No entanto, para que um cluster funcione corretamente, todos os seus agentes devem estar associados ao mesmo grupo de segurança. Portanto, se você adicionar novos corretores após alterar o grupo de segurança, deverá seguir novamente o procedimento anterior e atualizar o ENIs dos novos corretores.
# Controle o acesso aos ZooKeeper nós do Apache em seu cluster Amazon MSK
Por motivos de segurança, você pode limitar o acesso aos ZooKeeper nós do Apache que fazem parte do seu cluster Amazon MSK. Para limitar o acesso aos nós, é possível atribuir um grupo de segurança separado para eles. Depois, é possível decidir quem tem acesso a esse grupo de segurança.
**Importante**
Esta seção não se aplica a clusters em execução no KRaft modo. Consulte [KRaft modo](metadata-management.md#kraft-intro).
**Topics**
+ [Para colocar seus ZooKeeper nós Apache em um grupo de segurança separado](zookeeper-security-group.md)
+ [Usando a segurança TLS com o Apache ZooKeeper](zookeeper-security-tls.md)
# Para colocar seus ZooKeeper nós Apache em um grupo de segurança separado
Para limitar o acesso aos ZooKeeper nós do Apache, você pode atribuir um grupo de segurança separado a eles. Você pode escolher quem tem acesso a esse novo grupo de segurança definindo as regras dele.
1. Obtenha a string de ZooKeeper conexão do Apache para seu cluster. Para saber como, consulte [ZooKeeper modo](metadata-management.md#msk-get-connection-string). A string de conexão contém os nomes DNS dos seus nós do Apache ZooKeeper .
1. Use uma ferramenta como `host` ou `ping` para converter os nomes de DNS obtidos na etapa anterior para endereços IP. Salve esses endereços IP porque você precisará deles posteriormente neste procedimento.
1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon EC2 em. [https://console.aws.amazon.com/ec2/](https://console.aws.amazon.com/ec2/)
1. No painel de navegação, em **NETWORK & SECURITY (REDE E SEGURANÇA)**, selecione **Network Interfaces (Interfaces de rede)**.
1. No campo de pesquisa acima da tabela de interfaces de rede, digite o nome do cluster e digite return. Isso limita o número de interfaces de rede que aparecem na tabela às interfaces associadas ao cluster.
1. Marque a caixa de seleção no início da linha que corresponde à primeira interface de rede na lista.
1. No painel de detalhes na parte inferior da página, procure o ** IPv4 IP privado primário**. Se esse endereço IP corresponder a um dos endereços IP que você obteve na primeira etapa desse procedimento, isso significa que essa interface de rede está atribuída a um ZooKeeper nó Apache que faz parte do seu cluster. Caso contrário, desmarque a caixa de seleção ao lado dessa interface de rede e selecione a próxima interface de rede na lista. A ordem em que você seleciona as interfaces de rede não importa. Nas próximas etapas, você executará as mesmas operações em todas as interfaces de rede atribuídas aos ZooKeeper nós do Apache, uma por uma.
1. Ao selecionar uma interface de rede que corresponde a um ZooKeeper nó do Apache, escolha o menu **Ações** na parte superior da página e escolha **Alterar grupos de segurança**. Atribua um novo grupo de segurança a essa interface de rede. Para obter informações sobre como criar grupos de segurança, consulte [Criar um grupo de segurança](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html?shortFooter=true#CreatingSecurityGroups) na documentação da Amazon VPC.
1. Repita a etapa anterior para atribuir o mesmo novo grupo de segurança a todas as interfaces de rede associadas aos ZooKeeper nós Apache do seu cluster.
1. Agora é possível escolher quem tem acesso a esse novo grupo de segurança. Para obter informações sobre como configurar regras de grupo de segurança, consulte [Adicionar, remover e atualizar regras](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html?shortFooter=true#AddRemoveRules) na documentação da Amazon VPC.
# Usando a segurança TLS com o Apache ZooKeeper
Você pode usar a segurança TLS para criptografia em trânsito entre seus clientes e seus nós Apache ZooKeeper . Para implementar a segurança TLS com seus ZooKeeper nós Apache, faça o seguinte:
+ Os clusters devem usar o Apache Kafka versão 2.5.1 ou posterior para usar a segurança TLS com o Apache. ZooKeeper
+ Habilite a segurança TLS ao criar ou configurar seu cluster. Clusters criados com o Apache Kafka versão 2.5.1 ou posterior com TLS ativado usam automaticamente a segurança TLS com endpoints Apache. ZooKeeper Para obter mais informações sobre a configuração da segurança TLS, consulte [Conceitos básicos sobre criptografia do Amazon MSK](msk-working-with-encryption.md).
+ Recupere os ZooKeeper endpoints TLS Apache usando a operação. [DescribeCluster ](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster)
+ Crie um arquivo de ZooKeeper configuração do Apache para uso com as [https://kafka.apache.org/documentation/#security_authz_cli](https://kafka.apache.org/documentation/#security_authz_cli)ferramentas `kafka-configs.sh` e ou com o ZooKeeper shell. Com cada ferramenta, você usa o `--zk-tls-config-file` parâmetro para especificar sua ZooKeeper configuração do Apache.
O exemplo a seguir mostra um arquivo de ZooKeeper configuração típico do Apache:
```
zookeeper.ssl.client.enable=true
zookeeper.clientCnxnSocket=org.apache.zookeeper.ClientCnxnSocketNetty
zookeeper.ssl.keystore.location=kafka.jks
zookeeper.ssl.keystore.password=test1234
zookeeper.ssl.truststore.location=truststore.jks
zookeeper.ssl.truststore.password=test1234
```
+ Para outros comandos (como`kafka-topics`), você deve usar a variável de `KAFKA_OPTS` ambiente para configurar ZooKeeper os parâmetros do Apache. O exemplo a seguir mostra como configurar a variável de `KAFKA_OPTS` ambiente para passar ZooKeeper parâmetros do Apache para outros comandos:
```
export KAFKA_OPTS="
-Dzookeeper.clientCnxnSocket=org.apache.zookeeper.ClientCnxnSocketNetty
-Dzookeeper.client.secure=true
-Dzookeeper.ssl.trustStore.location=/home/ec2-user/kafka.client.truststore.jks
-Dzookeeper.ssl.trustStore.password=changeit"
```
Após configurar a variável de ambiente `KAFKA_OPTS`, você pode usar os comandos da CLI normalmente. O exemplo a seguir cria um tópico do Apache Kafka usando a ZooKeeper configuração do Apache a partir da variável de ambiente: `KAFKA_OPTS`
```
/bin/kafka-topics.sh --create --zookeeper ZooKeeperTLSConnectString --replication-factor 3 --partitions 1 --topic AWSKafkaTutorialTopic
```
**nota**
Os nomes dos parâmetros que você usa no seu arquivo de ZooKeeper configuração do Apache e aqueles que você usa na sua variável de `KAFKA_OPTS` ambiente não são consistentes. Preste atenção nos nomes que você usa com quais parâmetros no arquivo de configuração e na variável de ambiente `KAFKA_OPTS`.
Para obter mais informações sobre como acessar seus ZooKeeper nós Apache com TLS, consulte [KIP-515: Habilitar o cliente ZK para usar a](https://cwiki.apache.org/confluence/display/KAFKA/KIP-515%3A+Enable+ZK+client+to+use+the+new+TLS+supported+authentication) nova autenticação compatível com TLS.
# Validação de conformidade do Amazon Managed Streaming for Apache Kafka
Auditores terceirizados avaliam a segurança e a conformidade do Amazon Managed Streaming for Apache Kafka como parte de programas de conformidade da AWS . Eles incluem PCI e HIPAA BAA.
Para obter uma lista de AWS serviços no escopo de programas de conformidade específicos, consulte [Amazon Services in Scope by Compliance Program](https://aws.amazon.com/compliance/services-in-scope/) . Para obter informações gerais, consulte Programas de [AWS conformidade Programas AWS](https://aws.amazon.com/compliance/programs/) de .
Você pode baixar relatórios de auditoria de terceiros usando AWS Artifact. Para obter mais informações, consulte [Baixar relatórios em AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html) .
Sua responsabilidade de conformidade ao usar o Amazon MSK é determinada pela confidencialidade dos seus dados, pelos objetivos de conformidade da sua empresa e pelas leis e regulamentações aplicáveis. AWS fornece os seguintes recursos para ajudar na conformidade:
+ [Guias de início rápido de segurança e compatibilidade](https://aws.amazon.com/quickstart/?awsf.quickstart-homepage-filter=categories%23security-identity-compliance): esses guias de implantação abordam as considerações de arquitetura e fornecem etapas para implantação de ambientes de linha de base focados em compatibilidade e segurança na AWS.
+ Documento técnico [sobre arquitetura para segurança e conformidade com a HIPAA — Este whitepaper](https://docs.aws.amazon.com/whitepapers/latest/architecting-hipaa-security-and-compliance-on-aws/architecting-hipaa-security-and-compliance-on-aws.html) descreve como as empresas podem usar para criar aplicativos compatíveis com a HIPAA. AWS
+ AWS Recursos de [https://aws.amazon.com/compliance/resources/](https://aws.amazon.com/compliance/resources/) de conformidade — Essa coleção de pastas de trabalho e guias pode ser aplicada ao seu setor e local.
+ [Avaliação de recursos com regras](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) no *Guia do AWS Config desenvolvedor* — O AWS Config serviço avalia o quão bem suas configurações de recursos estão em conformidade com as práticas internas, as diretrizes e os regulamentos do setor.
+ [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html)— Esse AWS serviço fornece uma visão abrangente do seu estado de segurança interno, AWS que ajuda você a verificar sua conformidade com os padrões e as melhores práticas do setor de segurança.
# Resiliência no Amazon Managed Streaming for Apache Kafka
A infraestrutura AWS global é construída em torno de AWS regiões e zonas de disponibilidade. AWS As regiões fornecem várias zonas de disponibilidade fisicamente separadas e isoladas, conectadas a redes de baixa latência, alta taxa de transferência e alta redundância. Com as zonas de disponibilidade, é possível projetar e operar aplicações e bancos de dados que automaticamente executam o failover entre as zonas sem interrupção. As zonas de disponibilidade são altamente disponíveis, tolerantes a falhas e escaláveis que uma ou várias infraestruturas de data center tradicionais.
Para obter mais informações sobre AWS regiões e zonas de disponibilidade, consulte [Infraestrutura AWS global](https://aws.amazon.com/about-aws/global-infrastructure/).
# Segurança de infraestrutura no Amazon Managed Streaming for Apache Kafka
Como um serviço gerenciado, o Amazon Managed Streaming for Apache Kafka é protegido AWS pelos procedimentos globais de segurança de rede descritos no whitepaper [Amazon Web Services:](https://d0.awsstatic.com/whitepapers/Security/AWS_Security_Whitepaper.pdf) Visão geral dos processos de segurança.
Você usa chamadas de API AWS publicadas para acessar o Amazon MSK pela rede. Os clientes devem oferecer suporte a Transport Layer Security (TLS) 1.0 ou posterior. Recomendamos TLS 1.2 ou posterior. Os clientes também devem ter compatibilidade com conjuntos de criptografia com perfect forward secrecy (PFS) como Ephemeral Diffie-Hellman (DHE) ou Ephemeral Elliptic Curve Diffie-Hellman (ECDHE). A maioria dos sistemas modernos como Java 7 e versões posteriores oferece compatibilidade com esses modos.
Além disso, as solicitações devem ser assinadas usando um ID da chave de acesso e uma chave de acesso secreta associada a uma entidade principal do IAM. Ou é possível usar o [AWS Security Token Service](https://docs.aws.amazon.com/STS/latest/APIReference/Welcome.html) (AWS STS) para gerar credenciais de segurança temporárias para assinar solicitações.
# Registro em log do Amazon MSK
Você pode entregar registros do agente Apache Kafka para um ou mais dos seguintes tipos de destino: Amazon CloudWatch Logs, Amazon S3, Amazon Data Firehose. Você também pode registrar chamadas de API do Amazon MSK com AWS CloudTrail.
**nota**
Os registros do corretor estão disponíveis nas corretoras MSK Standard e Express.
## Logs do agente
Os logs de agente permitem solucionar problemas de aplicações do Apache Kafka e analisar as comunicações delas com o seu cluster do MSK. Você pode configurar seu cluster MSK novo ou existente para fornecer registros de agente em nível de informação a um ou mais dos seguintes tipos de recursos de destino: um grupo de CloudWatch registros, um bucket do S3, um stream de entrega do Firehose. Por meio do Firehose, você pode então entregar os dados de registro do seu stream de entrega para OpenSearch o Service.
Você deve criar um recurso de destino antes de configurar seu cluster para entregar registros do agente a esse recurso. O Amazon MSK não cria esses recursos de destino para você se eles ainda não existirem. Para obter informações sobre esses três tipos de recursos de destino e como criá-los, consulte a seguinte documentação:
+ [ CloudWatch Registros da Amazon](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/WhatIsCloudWatchLogs.html)
+ [Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/dev/Welcome.html)
+ [Amazon Data Firehose](https://docs.aws.amazon.com/firehose/latest/dev/what-is-this-service.html)
### Permissões obrigatórias
Para configurar um destino para os logs de agente do Amazon MSK, a identidade do IAM que você usa para as ações do Amazon MSK deve ter as permissões descritas na política [AWS política gerenciada: Amazon MSKFull Access](security-iam-awsmanpol-AmazonMSKFullAccess.md).
Para transmitir logs de agente para um bucket do S3, também é necessário ter a permissão `s3:PutBucketPolicy`. Para obter informações sobre as políticas de bucket do S3, consulte [Como adiciono uma política de bucket do S3?](https://docs.aws.amazon.com/AmazonS3/latest/user-guide/add-bucket-policy.html) no Guia do usuário do Amazon S3. Para obter informações sobre as políticas do IAM em geral, consulte [Gerenciamento de acesso](https://docs.aws.amazon.com/IAM/latest/UserGuide/access.html) no Guia do usuário do IAM.
### Política de chave obrigatória do KMS para uso com buckets de SSE-KMS
Se você habilitou a criptografia do lado do servidor para seu bucket do S3 usando chaves AWS KMS gerenciadas (SSE-KMS) com uma chave gerenciada pelo cliente, adicione o seguinte à política de chaves da sua chave KMS para que o Amazon MSK possa gravar arquivos de agente no bucket.
```
{
"Sid": "Allow Amazon MSK to use the key.",
"Effect": "Allow",
"Principal": {
"Service": [
"delivery.logs.amazonaws.com"
]
},
"Action": [
"kms:Encrypt",
"kms:Decrypt",
"kms:ReEncrypt*",
"kms:GenerateDataKey*",
"kms:DescribeKey"
],
"Resource": "*"
}
```
### Configure os registros do broker usando o Console de gerenciamento da AWS
Se estiver criando um cluster, procure o cabeçalho **Broker log delivery (Entrega de log de agente)** na seção **Monitoring (Monitoramento)**. É possível especificar os destinos aos quais deseja que o Amazon MSK entregue os logs de agente.
Para um cluster existente, escolha o cluster na lista de clusters e selecione a guia **Propriedades**. Role para baixo até a seção **Entrega de logs** e escolha o botão **Editar**. É possível especificar os destinos aos quais deseja que o Amazon MSK entregue os logs de agente.
### Configure os registros do broker usando o AWS CLI
Quando você usar o comando `create-cluster` ou `update-monitoring`, poderá especificar o parâmetro `logging-info` opcionalmente e passar uma estrutura JSON para ele como o exemplo a seguir. Nesse JSON, todos os três tipos de destino são opcionais.
**nota**
Você deve definir a tag `LogDeliveryEnabled` como `true` nos fluxos do Firehose para configurar a entrega de logs. A função vinculada ao serviço AWS criada para CloudWatch registros usa essa tag para conceder permissão para todos os streams de entrega do Firehose. Se você remover essa tag, a função vinculada ao serviço não poderá entregar logs ao stream do Firehose. Para ver um exemplo de uma política do IAM que mostra as permissões que a função vinculada ao serviço inclui, consulte [Funções do IAM usadas para permissões de recursos no Guia CloudWatch ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-infrastructure-V2-Firehose.html) *do usuário da Amazon*.
```
{
"BrokerLogs": {
"S3": {
"Bucket": "amzn-s3-demo-bucket",
"Prefix": "ExamplePrefix",
"Enabled": true
},
"Firehose": {
"DeliveryStream": "ExampleDeliveryStreamName",
"Enabled": true
},
"CloudWatchLogs": {
"Enabled": true,
"LogGroup": "ExampleLogGroupName"
}
}
}
```
### Configurar logs de agentes usando a API
Você pode especificar a `loggingInfo` estrutura opcional no JSON que você passa para as [UpdateMonitoring](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-monitoring.html#UpdateMonitoring)operações [CreateCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters.html#CreateCluster)ou.
**nota**
Por padrão, quando o registro em log do agente estiver habilitado, o Amazon MSK registrará os logs no nível de `INFO` nos destinos especificados. [No entanto, para corretores Standard, os usuários do Apache Kafka 2.4.X e versões posteriores podem definir dinamicamente o nível de log do broker para qualquer um dos níveis de log log4j.](https://logging.apache.org/log4j/1.2/apidocs/org/apache/log4j/Level.html) Para obter informações sobre como definir dinamicamente o nível de log do agente, consulte [KIP-412: estender a API Admin para oferecer suporte aos níveis dinâmicos de log do aplicativo](https://cwiki.apache.org/confluence/display/KAFKA/KIP-412%3A+Extend+Admin+API+to+support+dynamic+application+log+levels). Se você definir dinamicamente o nível de log como `DEBUG` ou `TRACE`, recomendamos usar o Amazon S3 ou o Firehose como o destino de logs. Se você usar CloudWatch Logs como um destino de log e ativar `DEBUG` ou `TRACE` nivelar dinamicamente o registro, o Amazon MSK poderá fornecer continuamente uma amostra de registros. Isso pode afetar significativamente o desempenho do agente e só deve ser usado quando o nível de log `INFO` não for suficientemente detalhado para determinar a causa raiz de um problema.
# Registre chamadas de API com AWS CloudTrail
**nota**
AWS CloudTrail os registros estão disponíveis para o Amazon MSK somente quando você usa[Controle de acesso do IAM](iam-access-control.md).
O Amazon MSK é integrado com AWS CloudTrail, um serviço que fornece um registro das ações realizadas por um usuário, função ou AWS serviço no Amazon MSK. CloudTrail captura chamadas de API como eventos. As chamadas capturadas incluem as chamadas do console do Amazon MSK e as chamadas de código para as operações da API do Amazon MSK. Ele também captura ações do Apache Kafka, como criar e alterar tópicos e grupos.
Se você criar uma trilha, poderá habilitar a entrega contínua de CloudTrail eventos para um bucket do Amazon S3, incluindo eventos para o Amazon MSK. Se você não configurar uma trilha, ainda poderá ver os eventos mais recentes no CloudTrail console no **Histórico de eventos**. Usando as informações coletadas por CloudTrail, você pode determinar a solicitação que foi feita para a Amazon MSK ou a ação do Apache Kafka, o endereço IP do qual a solicitação foi feita, quem fez a solicitação, quando ela foi feita e detalhes adicionais.
Para saber mais CloudTrail, inclusive como configurá-lo e ativá-lo, consulte o [Guia AWS CloudTrail do usuário](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/).
## Informações do Amazon MSK em CloudTrail
CloudTrail é ativado na sua conta da Amazon Web Services quando você cria a conta. Quando a atividade de evento suportada ocorre em um cluster MSK, essa atividade é registrada em um CloudTrail evento junto com outros eventos de AWS serviço no **histórico** de eventos. Você pode visualizar, pesquisar e baixar os eventos recentes em sua conta da Amazon Web Services. Para obter mais informações, consulte [Visualizar eventos com o histórico de eventos do CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html).
Para obter um registro contínuo dos eventos na sua conta da Amazon Web Services, incluindo os eventos do Amazon MSK, crie uma trilha. Uma *trilha* permite CloudTrail entregar arquivos de log para um bucket do Amazon S3. Por padrão, quando uma trilha é criada no console, a mesma é aplicada a todas as regiões da . A trilha registra logs de eventos de todas as Regiões na AWS divisória e entrega os arquivos do log para o bucket Amazon S3 especificado. Além disso, você pode configurar outros serviços da Amazon para analisar e agir com base nos dados de eventos coletados nos CloudTrail registros. Para saber mais, consulte:
+ [Visão Geral para Criar uma Trilha](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html)
+ [CloudTrail Serviços e integrações compatíveis](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-aws-service-specific-topics.html#cloudtrail-aws-service-specific-topics-integrations)
+ [Configurando notificações do Amazon SNS para CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/getting_notifications_top_level.html)
+ [Recebendo arquivos de CloudTrail log de várias regiões](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/receive-cloudtrail-log-files-from-multiple-regions.html) e [recebendo arquivos de CloudTrail log de várias contas](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-receive-logs-from-multiple-accounts.html)
O Amazon MSK registra todas as [operações do Amazon MSK](https://docs.aws.amazon.com/MSK/2.0/APIReference/operations.html) como eventos em arquivos de CloudTrail log. Além disso, ele registra as seguintes ações do Apache Kafka.
+ cluster de kafka: DescribeClusterDynamicConfiguration
+ cluster de kafka: AlterClusterDynamicConfiguration
+ cluster de kafka: CreateTopic
+ cluster de kafka: DescribeTopicDynamicConfiguration
+ cluster de kafka: AlterTopic
+ cluster de kafka: AlterTopicDynamicConfiguration
+ cluster de kafka: DeleteTopic
Cada entrada de log ou evento contém informações sobre quem gerou a solicitação. As informações de identidade ajudam a determinar o seguinte:
+ Se a solicitação foi feita com credenciais de usuário root ou AWS Identity and Access Management (IAM).
+ Se a solicitação foi feita com credenciais de segurança temporárias de um perfil ou de um usuário federado.
+ Se a solicitação foi feita por outro AWS serviço.
Para obter mais informações, consulte [Elemento userIdentity do CloudTrail ](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-user-identity.html).
## Exemplo: entradas de arquivo de log do Amazon MSK
Uma trilha é uma configuração que permite a entrega de eventos como arquivos de log para um bucket do Amazon S3 que você especificar. CloudTrail os arquivos de log contêm uma ou mais entradas de log. Um evento representa uma única solicitação de qualquer fonte e inclui informações sobre a ação solicitada, a data e a hora da ação, os parâmetros da solicitação e assim por diante. CloudTrail os arquivos de log não são um rastreamento de pilha ordenado das chamadas públicas da API e das ações do Apache Kafka, portanto, eles não aparecem em nenhuma ordem específica.
O exemplo a seguir mostra entradas de CloudTrail registro que demonstram as ações do `DeleteCluster` Amazon MSK `DescribeCluster` e do Amazon.
```
{
"Records": [
{
"eventVersion": "1.05",
"userIdentity": {
"type": "IAMUser",
"principalId": "ABCDEF0123456789ABCDE",
"arn": "arn:aws:iam::012345678901:user/Joe",
"accountId": "012345678901",
"accessKeyId": "AIDACKCEVSQ6C2EXAMPLE",
"userName": "Joe"
},
"eventTime": "2018-12-12T02:29:24Z",
"eventSource": "kafka.amazonaws.com",
"eventName": "DescribeCluster",
"awsRegion": "us-east-1",
"sourceIPAddress": "192.0.2.0",
"userAgent": "aws-cli/1.14.67 Python/3.6.0 Windows/10 botocore/1.9.20",
"requestParameters": {
"clusterArn": "arn%3Aaws%3Akafka%3Aus-east-1%3A012345678901%3Acluster%2Fexamplecluster%2F01234567-abcd-0123-abcd-abcd0123efa-2"
},
"responseElements": null,
"requestID": "bd83f636-fdb5-abcd-0123-157e2fbf2bde",
"eventID": "60052aba-0123-4511-bcde-3e18dbd42aa4",
"readOnly": true,
"eventType": "AwsApiCall",
"recipientAccountId": "012345678901"
},
{
"eventVersion": "1.05",
"userIdentity": {
"type": "IAMUser",
"principalId": "ABCDEF0123456789ABCDE",
"arn": "arn:aws:iam::012345678901:user/Joe",
"accountId": "012345678901",
"accessKeyId": "AIDACKCEVSQ6C2EXAMPLE",
"userName": "Joe"
},
"eventTime": "2018-12-12T02:29:40Z",
"eventSource": "kafka.amazonaws.com",
"eventName": "DeleteCluster",
"awsRegion": "us-east-1",
"sourceIPAddress": "192.0.2.0",
"userAgent": "aws-cli/1.14.67 Python/3.6.0 Windows/10 botocore/1.9.20",
"requestParameters": {
"clusterArn": "arn%3Aaws%3Akafka%3Aus-east-1%3A012345678901%3Acluster%2Fexamplecluster%2F01234567-abcd-0123-abcd-abcd0123efa-2"
},
"responseElements": {
"clusterArn": "arn:aws:kafka:us-east-1:012345678901:cluster/examplecluster/01234567-abcd-0123-abcd-abcd0123efa-2",
"state": "DELETING"
},
"requestID": "c6bfb3f7-abcd-0123-afa5-293519897703",
"eventID": "8a7f1fcf-0123-abcd-9bdb-1ebf0663a75c",
"readOnly": false,
"eventType": "AwsApiCall",
"recipientAccountId": "012345678901"
}
]
}
```
O exemplo a seguir mostra uma entrada de CloudTrail registro que demonstra a `kafka-cluster:CreateTopic` ação.
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "IAMUser",
"principalId": "ABCDEFGH1IJKLMN2P34Q5",
"arn": "arn:aws:iam::111122223333:user/Admin",
"accountId": "111122223333",
"accessKeyId": "CDEFAB1C2UUUUU3AB4TT",
"userName": "Admin"
},
"eventTime": "2021-03-01T12:51:19Z",
"eventSource": "kafka-cluster.amazonaws.com",
"eventName": "CreateTopic",
"awsRegion": "us-east-1",
"sourceIPAddress": "198.51.100.0/24",
"userAgent": "aws-msk-iam-auth/unknown-version/aws-internal/3 aws-sdk-java/1.11.970 Linux/4.14.214-160.339.amzn2.x86_64 OpenJDK_64-Bit_Server_VM/25.272-b10 java/1.8.0_272 scala/2.12.8 vendor/Red_Hat,_Inc.",
"requestParameters": {
"kafkaAPI": "CreateTopics",
"resourceARN": "arn:aws:kafka:us-east-1:111122223333:topic/IamAuthCluster/3ebafd8e-dae9-440d-85db-4ef52679674d-1/Topic9"
},
"responseElements": null,
"requestID": "e7c5e49f-6aac-4c9a-a1d1-c2c46599f5e4",
"eventID": "be1f93fd-4f14-4634-ab02-b5a79cb833d2",
"readOnly": false,
"eventType": "AwsApiCall",
"managementEvent": true,
"eventCategory": "Management",
"recipientAccountId": "111122223333"
}
```
# Gerenciamento de metadados
O Amazon MSK oferece suporte ao Apache ZooKeeper ou aos modos de gerenciamento de KRaft metadados.
A partir do Apache Kafka versão 3.7.x no Amazon MSK, você pode criar clusters que KRaft usam o modo em vez do modo. ZooKeeper KRaftclusters baseados em controladores no Kafka para gerenciar metadados.
**Topics**
+ [ZooKeeper modo](#msk-get-connection-string)
+ [KRaft modo](#kraft-intro)
## ZooKeeper modo
O [Apache ZooKeeper](https://zookeeper.apache.org/) é “um serviço centralizado para manter informações de configuração, nomear, fornecer sincronização distribuída e fornecer serviços de grupo. Todos esses tipos de serviços são usados de alguma forma por aplicações distribuídas”, incluindo o Apache Kafka.
Se seu cluster estiver usando o ZooKeeper modo, você pode usar as etapas abaixo para obter a string de ZooKeeper conexão do Apache. No entanto, recomendamos que você use `BootstrapServerString` para se conectar ao cluster e realizar operações administrativas, pois o sinalizador `--zookeeper` foi descontinuado no Kafka 2.5 e foi removido do Kafka 3.0.
### Obtendo a string de ZooKeeper conexão do Apache usando o Console de gerenciamento da AWS
1. Abra o console do Amazon MSK em [https://console.aws.amazon.com/msk/](https://console.aws.amazon.com/msk/).
1. A tabela mostra todos os clusters da região atual nesta conta. Escolha o nome de um cluster para visualizar sua descrição.
1. Na página **Resumo do cluster**, escolha **Exibir informações do cliente**. Isso mostra os corretores de bootstrap, bem como a string de conexão do Apache ZooKeeper .
### Obtendo a string de ZooKeeper conexão do Apache usando o AWS CLI
1. Se não souber o nome de recurso da Amazon (ARN) do cluster, você poderá encontrá-lo listando todos os clusters em sua conta. Para obter mais informações, consulte [Listar clusters do Amazon MSK](msk-list-clusters.md).
1. Para obter a cadeia de ZooKeeper conexão do Apache, junto com outras informações sobre seu cluster, execute o comando a seguir, *ClusterArn* substituindo-o pelo ARN do seu cluster.
```
aws kafka describe-cluster --cluster-arn ClusterArn
```
A saída desse comando `describe-cluster` é semelhante ao seguinte JSON de exemplo.
```
{
"ClusterInfo": {
"BrokerNodeGroupInfo": {
"BrokerAZDistribution": "DEFAULT",
"ClientSubnets": [
"subnet-0123456789abcdef0",
"subnet-2468013579abcdef1",
"subnet-1357902468abcdef2"
],
"InstanceType": "kafka.m5.large",
"StorageInfo": {
"EbsStorageInfo": {
"VolumeSize": 1000
}
}
},
"ClusterArn": "arn:aws:kafka:us-east-1:111122223333:cluster/testcluster/12345678-abcd-4567-2345-abcdef123456-2",
"ClusterName": "testcluster",
"CreationTime": "2018-12-02T17:38:36.75Z",
"CurrentBrokerSoftwareInfo": {
"KafkaVersion": "2.2.1"
},
"CurrentVersion": "K13V1IB3VIYZZH",
"EncryptionInfo": {
"EncryptionAtRest": {
"DataVolumeKMSKeyId": "arn:aws:kms:us-east-1:555555555555:key/12345678-abcd-2345-ef01-abcdef123456"
}
},
"EnhancedMonitoring": "DEFAULT",
"NumberOfBrokerNodes": 3,
"State": "ACTIVE",
"ZookeeperConnectString": "10.0.1.101:2018,10.0.2.101:2018,10.0.3.101:2018"
}
}
```
O JSON de exemplo anterior mostra a chave `ZookeeperConnectString` na saída do comando `describe-cluster`. Copie o valor correspondente a essa chave e salve-o para quando precisar criar um tópico no cluster.
**Importante**
Seu cluster Amazon MSK deve estar no `ACTIVE` estado para que você possa obter a cadeia de ZooKeeper conexão Apache. Quando um cluster ainda está no estado `CREATING`, a saída do comando `describe-cluster` não inclui a `ZookeeperConnectString`. Se esse for o caso, aguarde alguns minutos e execute `describe-cluster` novamente após o cluster atingir o estado `ACTIVE`.
### Obtendo a string de ZooKeeper conexão do Apache usando a API
Para obter a string de ZooKeeper conexão do Apache usando a API, consulte [DescribeCluster](https://docs.aws.amazon.com//msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster).
## KRaft modo
O Amazon MSK introduziu o suporte para KRaft (Apache Kafka Raft) na versão 3.7.x do Kafka. A comunidade Apache Kafka foi desenvolvida KRaft para substituir o Apache no gerenciamento de metadados nos clusters do [Apache ZooKeeper](#msk-get-connection-string) Kafka. No KRaft modo, os metadados do cluster são propagados dentro de um grupo de controladores Kafka, que fazem parte do cluster Kafka, em vez de entre nós. ZooKeeper KRaftos controladores estão incluídos sem custo adicional para você e não exigem configuração ou gerenciamento adicionais de sua parte. Consulte [KIP-500](https://cwiki.apache.org/confluence/display/KAFKA/KIP-500%3A+Replace+ZooKeeper+with+a+Self-Managed+Metadata+Quorum) para obter mais informações sobre. KRaft
Aqui estão alguns pontos a serem observados sobre o KRaft modo no MSK:
+ KRaft o modo só está disponível para novos clusters. Não é possível alternar entre os modos de metadados depois que o cluster é criado.
+ No console do MSK, você pode criar um cluster baseado em Kraft escolhendo a versão 3.7.x do Kafka e marcando a caixa de seleção na janela de criação do cluster. KRaft
+ Para criar um cluster no KRaft modo usando a API [https://docs.aws.amazon.com/msk/1.0/apireference/clusters.html#CreateCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters.html#CreateCluster)ou [https://docs.aws.amazon.com/MSK/2.0/APIReference/v2-clusters.html#CreateClusterV2](https://docs.aws.amazon.com/MSK/2.0/APIReference/v2-clusters.html#CreateClusterV2)as operações do MSK, você deve usar `3.7.x.kraft` como versão. Use `3.7.x` como versão para criar um cluster no ZooKeeper modo.
+ O número de partições por broker é o mesmo em clusters ZooKeeper baseados em KRaft e baseados. No entanto, KRaft permite que você hospede mais partições por cluster provisionando [mais agentes](https://docs.aws.amazon.com/msk/latest/developerguide/limits.html) em um cluster.
+ Não são necessárias alterações de API para usar o KRaft modo no Amazon MSK. No entanto, se os clientes ainda usarem a string de conexão `--zookeeper` atualmente, você deverá atualizá-los para usar a string de conexão `--bootstrap-server` para se conectar ao cluster. Observe que o sinalizador `--zookeeper` foi descontinuado no Apache Kafka versão 2.5 e foi removido a partir do Kafka versão 3.0. Portanto, recomendamos que você use as versões recentes do cliente Apache Kafka e a string de conexão `--bootstrap-server` para todas as conexões com o cluster.
+ ZooKeeper O modo continua disponível para todas as versões lançadas, nas quais o zookeeper também é suportado pelo Apache Kafka. Consulte [Versões compatíveis do Apache Kafka](supported-kafka-versions.md) para obter detalhes sobre o fim do suporte às versões do Apache Kafka e futuras atualizações.
+ Você deve verificar se todas as ferramentas que você usa são capazes de usar o Kafka Admin APIs sem ZooKeeper conexões. Consulte [Use o LinkedIn Cruise Control para Apache Kafka com o Amazon MSK](cruise-control.md) para conferir as etapas atualizadas para conectar o cluster ao Cruise Control. O Cruise Control também tem instruções para [executar o Cruise Control sem ZooKeeper](https://github.com/linkedin/cruise-control/wiki/Run-without-ZooKeeper).
+ Você não precisa acessar os KRaft controladores do seu cluster diretamente para nenhuma ação administrativa. No entanto, se você estiver usando o monitoramento aberto para coletar métricas, também precisará dos endpoints de DNS dos controladores para coletar algumas métricas não relacionadas ao controlador sobre o cluster. Você pode obter esses endpoints de DNS no console do MSK ou usando a operação da [ListNodes](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-nodes.html#ListNodes)API. Consulte as etapas atualizadas [Monitore um cluster do MSK Provisioned com o Prometheus](open-monitoring.md) para configurar o monitoramento aberto para clusters KRaft baseados.
+ Não há [CloudWatch métricas](https://docs.aws.amazon.com/msk/latest/developerguide/metrics-details.html) adicionais que você precise monitorar para clusters de KRaft modos em vez de clusters ZooKeeper de modos. O MSK gerencia os KRaft controladores usados em seus clusters.
+ Você pode continuar gerenciando ACLs usando clusters no KRaft modo usando a cadeia de `--bootstrap-server` conexão. Você não deve usar a cadeia de `--zookeeper` conexão para gerenciar ACLs. Consulte [Apache Kafka ACLs](msk-acls.md).
+ No KRaft modo, os metadados do seu cluster são armazenados em KRaft controladores dentro do Kafka e não em nós externos. ZooKeeper Portanto, você não precisa controlar o acesso aos nós do controlador separadamente, [como você faz com ZooKeeper os nós](https://docs.aws.amazon.com/msk/latest/developerguide/zookeeper-security.html).
# Operações do tópico
Você pode usar o Amazon MSK APIs para gerenciar tópicos em seu cluster provisionado pelo MSK sem a necessidade de configurar e manter clientes administrativos do Kafka. Com eles APIs, você pode definir ou ler as propriedades do tópico, como fator de replicação e contagem de partições, junto com as definições de configuração, como políticas de retenção e limpeza. Você pode gerenciar programaticamente os tópicos do Kafka usando suas interfaces familiares, incluindo CLI AWS , e. AWS SDKs AWS CloudFormation Elas também APIs são integradas ao console do Amazon MSK, reunindo todas as operações temáticas em um só lugar. Agora você pode criar ou atualizar tópicos com apenas alguns cliques usando padrões guiados e, ao mesmo tempo, obter visibilidade abrangente das configurações de tópicos, informações em nível de partição e métricas.
**Importante**
Essas respostas da API de tópicos refletem dados que são atualizados aproximadamente a cada minuto. Para obter o estado mais atual do tópico após fazer alterações, aguarde aproximadamente um minuto antes de consultar.
## Requisitos para usar o tópico APIs
+ Seu cluster deve ser um cluster provisionado pelo MSK. Eles não APIs estão disponíveis para clusters MSK Serverless.
+ Seu cluster deve estar executando o Apache Kafka versão 3.6.0 ou posterior. Para obter mais informações sobre as versões compatíveis, consulte[Versões compatíveis do Apache Kafka](supported-kafka-versions.md).
+ Seu cluster deve estar no `ACTIVE` estado. Para obter mais informações sobre estados de cluster, consulte [Entenda os estados do cluster do MSK Provisioned](msk-cluster-states.md).
+ Você deve ter as permissões apropriadas do IAM. Para obter mais informações, consulte [Permissões do IAM para operações de tópicos APIs](#topic-operations-permissions).
## Permissões do IAM para operações de tópicos APIs
Para chamá-los APIs, você deve ter as permissões apropriadas do IAM. A tabela a seguir lista as permissões necessárias para cada API.
**Permissões necessárias para operações de tópicos APIs**
| solicitações de | Permissões obrigatórias | Recurso |
| --- | --- | --- |
| ListTopics | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` | ARN do cluster, ARN do tópico |
| DescribeTopic | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:DescribeTopicDynamicConfiguration` | ARN do cluster, ARN do tópico |
| DescribeTopicPartitions | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:DescribeTopicDynamicConfiguration` | ARN do cluster, ARN do tópico |
| CreateTopic | `kafka-cluster:Connect` `kafka-cluster:CreateTopic` | ARN do cluster, ARN do tópico |
| DeleteTopic | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:DeleteTopic` | ARN do cluster, ARN do tópico |
| UpdateTopic | `kafka-cluster:Connect` `kafka-cluster:DescribeTopic` `kafka-cluster:AlterTopic` `kafka-cluster:AlterTopicDynamicConfiguration` | ARN do cluster, ARN do tópico |
**nota**
Para`kafka-cluster:Connect`, especifique o ARN do cluster na sua política do IAM. Para todas as outras ações, especifique o ARN do tópico em sua política do IAM.
**nota**
Para`ListTopics`, você pode usar um caractere curinga (\$1) para corresponder a todos os tópicos em um cluster. Por exemplo: `arn:aws:kafka:us-east-1:123456789012:topic/my-cluster/abcd1234-abcd-dcba-4321-a1b2abcd9f9f-2/*`.
Para obter mais informações sobre o controle de acesso do IAM para o Amazon MSK, consulte[Controle de acesso do IAM](iam-access-control.md).
**Topics**
+ [Requisitos para usar o tópico APIs](#topic-operations-requirements)
+ [Permissões do IAM para operações de tópicos APIs](#topic-operations-permissions)
+ [Listar tópicos em um cluster Amazon MSK](msk-list-topics.md)
+ [Obtenha informações detalhadas sobre um tópico](msk-describe-topic.md)
+ [Exibir informações de partição de um tópico](msk-describe-topic-partitions.md)
+ [Crie tópicos em um cluster Amazon MSK](msk-create-topic.md)
+ [Atualizar um tópico em um cluster do Amazon MSK](msk-update-topic.md)
+ [Excluir um tópico em um cluster do Amazon MSK](msk-delete-topic.md)
# Listar tópicos em um cluster Amazon MSK
Você pode listar todos os tópicos em seu cluster provisionado pelo MSK para visualizar metadados básicos, como contagens de partições e fatores de replicação. Isso é útil para monitorar os tópicos do seu cluster, realizar verificações de inventário ou identificar tópicos para uma investigação mais aprofundada.
**nota**
A `ListTopics` API fornece metadados básicos de tópicos. Para obter informações detalhadas sobre um tópico específico, incluindo seu status e configuração atuais, use a `DescribeTopic` API. Para obter mais informações, consulte [Obtenha informações detalhadas sobre um tópico](msk-describe-topic.md).
**nota**
Essa resposta da API reflete dados que são atualizados aproximadamente a cada minuto. Para obter o estado mais atual do tópico após fazer alterações, aguarde aproximadamente um minuto antes de consultar.
**Topics**
+ [Listar tópicos usando o Console de gerenciamento da AWS](list-topics-console.md)
+ [Listar tópicos usando o AWS CLI](list-topics-cli.md)
+ [Listar tópicos usando a API](list-topics-api.md)
# Listar tópicos usando o Console de gerenciamento da AWS
1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon MSK em [https://console.aws.amazon.com/msk/casa? region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/).
1. Na lista de clusters, escolha o nome do cluster para o qual você deseja listar tópicos.
1. Na página de detalhes do cluster, escolha a guia **Tópicos**.
1. A tabela mostra todos os tópicos do cluster, incluindo o nome do tópico, o número de partições, o fator de replicação e a contagem de out-of-sync réplicas.
# Listar tópicos usando o AWS CLI
Execute o comando a seguir, *ClusterArn* substituindo-o pelo Amazon Resource Name (ARN) do seu cluster. Se você não tiver o ARN do cluster, poderá encontrá-lo listando todos os clusters. Para obter mais informações, consulte [Listar clusters do Amazon MSK](msk-list-clusters.md).
```
aws kafka list-topics --cluster-arn ClusterArn
```
A saída desse comando é semelhante ao seguinte JSON de exemplo.
```
{
"topics": [
{
"topicArn": "arn:aws:kafka:us-east-1:123456789012:topic/MyCluster/abcd1234-abcd-dcba-4321-a1b2abcd9f9f-2/MyTopic",
"topicName": "MyTopic",
"partitionCount": 3,
"replicationFactor": 3,
"outOfSyncReplicaCount": 0
},
{
"topicArn": "arn:aws:kafka:us-east-1:123456789012:topic/MyCluster/abcd1234-abcd-dcba-4321-a1b2abcd9f9f-2/AnotherTopic",
"topicName": "AnotherTopic",
"partitionCount": 6,
"replicationFactor": 3,
"outOfSyncReplicaCount": 1
}
]
}
```
## Como paginar resultados
Se seu cluster tiver muitos tópicos, você poderá usar a paginação para recuperar os resultados em lotes menores. Use o `--max-results` parâmetro para especificar o número máximo de tópicos a serem retornados e use o `--next-token` parâmetro para recuperar a próxima página de resultados.
```
aws kafka list-topics --cluster-arn ClusterArn --max-results 10
```
Se houver mais resultados disponíveis, a resposta incluirá um `nextToken` valor. Use esse token para recuperar a próxima página de resultados.
```
aws kafka list-topics --cluster-arn ClusterArn --max-results 10 --next-token NextToken
```
## Filtrando tópicos por nome
Você pode filtrar a lista de tópicos especificando um prefixo usando o `--topic-name-filter` parâmetro. Isso retorna somente tópicos cujos nomes começam com o prefixo especificado.
```
aws kafka list-topics --cluster-arn ClusterArn --topic-name-filter "prod-"
```
Esse comando retorna somente tópicos cujos nomes começam com`prod-`, como `prod-orders` ou`prod-inventory`.
# Listar tópicos usando a API
Para listar tópicos usando a API, consulte [ListTopics](https://docs.aws.amazon.com//msk/1.0/apireference/v1-clusters-clusterarn-topics.html#ListTopics).
# Obtenha informações detalhadas sobre um tópico
Você pode recuperar informações detalhadas sobre um tópico específico em seu cluster provisionado MSK, incluindo seu status atual, contagem de partições, fator de replicação e configuração. Isso é útil para solucionar problemas, validar as configurações do tópico ou monitorar o status do tópico durante as operações.
**nota**
Essa resposta da API reflete dados que são atualizados aproximadamente a cada minuto. Para obter o estado mais atual do tópico após fazer alterações, aguarde aproximadamente um minuto antes de consultar.
**Topics**
+ [Descreva um tópico usando o Console de gerenciamento da AWS](describe-topic-console.md)
+ [Descreva um tópico usando o AWS CLI](describe-topic-cli.md)
+ [Descreva um tópico usando a API](describe-topic-api.md)
# Descreva um tópico usando o Console de gerenciamento da AWS
1. Faça login no Console de gerenciamento da AWS e abra o console Amazon MSK em [https://console.aws.amazon.com/msk/casa? region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/).
1. Na lista de clusters, escolha o nome do cluster que contém o tópico que você deseja descrever.
1. Na página de detalhes do cluster, escolha a guia **Tópicos**.
1. Na lista de tópicos, escolha o nome do tópico que você deseja visualizar.
1. A página de detalhes do tópico mostra informações sobre o tópico, incluindo seu status, contagem de partições, fator de replicação e definições de configuração.
# Descreva um tópico usando o AWS CLI
Execute o comando a seguir, *ClusterArn* substituindo-o pelo Amazon Resource Name (ARN) do seu cluster e *TopicName* pelo nome do tópico que você deseja descrever.
```
aws kafka describe-topic --cluster-arn ClusterArn --topic-name TopicName
```
A saída desse comando é semelhante ao seguinte JSON de exemplo.
```
{
"topicArn": "arn:aws:kafka:us-east-1:123456789012:topic/MyCluster/abcd1234-abcd-dcba-4321-a1b2abcd9f9f-2/MyTopic",
"topicName": "MyTopic",
"partitionCount": 3,
"replicationFactor": 3,
"configs": "Y29tcHJlc3Npb24udHlwZT1wcm9kdWNlcgpyZXRlbnRpb24ubXM9NjA0ODAwMDAw",
"status": "ACTIVE"
}
```
## Entendendo o status do tópico
O `status` campo indica o estado atual do tópico. A tabela a seguir descreve os possíveis valores de status.
**Valores de status do tópico**
| Status | Description |
| --- | --- |
| CRIANDO | O tópico está sendo criado. |
| ATIVO | O tópico está ativo e pronto para uso. |
| ATUALIZANDO | A configuração do tópico está sendo atualizada. |
| EXCLUINDO | O tópico está sendo excluído. |
## Entendendo as configurações de tópicos
O `configs` campo contém as propriedades de configuração do Kafka do tópico, codificadas no formato Base64. Para visualizar a configuração em um formato legível, você precisa decodificar a string Base64.
O exemplo a seguir mostra como decodificar a configuração usando o `base64` comando no Linux ou no macOS.
```
echo "Y29tcHJlc3Npb24udHlwZT1wcm9kdWNlcgpyZXRlbnRpb24ubXM9NjA0ODAwMDAw" | base64 --decode
```
A saída decodificada mostra as propriedades de configuração do tópico no formato de valor-chave.
```
compression.type=producer
retention.ms=604800000
```
Para obter mais informações sobre propriedades de configuração em nível de tópico, consulte. [Configuração no nível de tópico do Amazon MSK](msk-configuration-properties.md#msk-topic-confinguration)
# Descreva um tópico usando a API
Para descrever um tópico usando a API, consulte [DescribeTopic](https://docs.aws.amazon.com//msk/1.0/apireference/v1-clusters-clusterarn-topics-topicname.html#DescribeTopic).
# Exibir informações de partição de um tópico
Você pode recuperar informações detalhadas sobre as partições de um tópico específico em seu cluster provisionado pelo MSK. Essas informações incluem o número da partição, o agente líder, os agentes de réplica e as réplicas em sincronização (ISR). Isso é útil para monitorar a distribuição de partições, identificar partições sub-replicadas ou solucionar problemas de replicação.
**nota**
Essa resposta da API reflete dados que são atualizados aproximadamente a cada minuto. Para obter o estado mais atual do tópico após fazer alterações, aguarde aproximadamente um minuto antes de consultar.
**Topics**
+ [Visualize as informações da partição usando o Console de gerenciamento da AWS](describe-topic-partitions-console.md)
+ [Visualize as informações da partição usando o AWS CLI](describe-topic-partitions-cli.md)
+ [Visualize as informações da partição usando a API](describe-topic-partitions-api.md)
# Visualize as informações da partição usando o Console de gerenciamento da AWS
1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon MSK em [https://console.aws.amazon.com/msk/casa? region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/).
1. Na lista de clusters, escolha o nome do cluster que contém o tópico.
1. Na página de detalhes do cluster, escolha a guia **Tópicos**.
1. Na lista de tópicos, escolha o nome do tópico para o qual você deseja visualizar as informações da partição.
1. Na página de detalhes do tópico, as informações da partição são exibidas, mostrando o número da partição, o agente líder, as réplicas e as réplicas sincronizadas de cada partição.
# Visualize as informações da partição usando o AWS CLI
Execute o comando a seguir, *ClusterArn* substituindo-o pelo Amazon Resource Name (ARN) do seu cluster e *TopicName* pelo nome do tópico.
```
aws kafka describe-topic-partitions --cluster-arn ClusterArn --topic-name TopicName
```
A saída desse comando é semelhante ao seguinte JSON de exemplo.
```
{
"partitions": [
{
"partition": 0,
"leader": 1,
"replicas": [1, 2, 3],
"isr": [1, 2, 3]
},
{
"partition": 1,
"leader": 2,
"replicas": [2, 3, 1],
"isr": [2, 3, 1]
},
{
"partition": 2,
"leader": 3,
"replicas": [3, 1, 2],
"isr": [3, 1]
}
]
}
```
## Compreendendo as informações de partição
A resposta inclui as seguintes informações para cada partição:
+ **partição** — O número da partição. As partições são numeradas a partir de 0.
+ **líder** — O ID do corretor do líder dessa partição. O líder lida com todas as solicitações de leitura e gravação da partição.
+ **réplicas** — A lista de corretores IDs que têm réplicas dessa partição. Isso inclui tanto a sincronização quanto as out-of-sync réplicas.
+ **isr** — A lista de corretores IDs que são réplicas sincronizadas. Essas réplicas são totalmente identificadas pelo líder e podem assumir o cargo de líder, se necessário.
No exemplo acima, a partição 2 tem uma out-of-sync réplica. A `replicas` lista inclui o corretor 2, mas a `isr` lista não. Isso indica que o broker 2 não está totalmente familiarizado com o líder dessa partição.
## Como paginar resultados
Se o seu tópico tiver muitas partições, você poderá usar a paginação para recuperar os resultados em lotes menores. Use o `--max-results` parâmetro para especificar o número máximo de partições a serem retornadas e use o `--next-token` parâmetro para recuperar a próxima página de resultados.
```
aws kafka describe-topic-partitions --cluster-arn ClusterArn --topic-name TopicName --max-results 10
```
Se houver mais resultados disponíveis, a resposta incluirá um `nextToken` valor. Use esse token para recuperar a próxima página de resultados.
```
aws kafka describe-topic-partitions --cluster-arn ClusterArn --topic-name TopicName --max-results 10 --next-token NextToken
```
## Casos de uso comuns
A visualização das informações da partição é útil para vários cenários:
+ **Identificação de partições sub-replicadas** — Compare as `isr` listas `replicas` e para identificar partições em que algumas réplicas não estão sincronizadas. Isso pode indicar problemas de desempenho ou problemas do corretor.
+ **Monitoramento da distribuição de partições** — Verifique se os líderes de partição estão distribuídos uniformemente entre os corretores para garantir uma carga balanceada.
+ **Solução de problemas de replicação** — identifique quais corretores estão tendo problemas para acompanhar a replicação examinando a lista de ISR.
+ **Planejando o rebalanceamento de partições** — Use essas informações para entender o layout atual da partição antes de realizar operações de rebalanceamento.
# Visualize as informações da partição usando a API
Para ver as informações da partição usando a API, consulte [DescribeTopicPartitions](https://docs.aws.amazon.com//msk/1.0/apireference/v1-clusters-clusterarn-topics-topicname-partitions.html#DescribeTopicPartitions).
# Crie tópicos em um cluster Amazon MSK
Você pode criar tópicos em seu cluster provisionado pelo MSK usando essa API diretamente sem configurar nenhum Kafka personalizado. AdminClient Ao criar um tópico, você especifica o nome do tópico, a contagem de partições, o fator de replicação e, opcionalmente, as configurações do tópico.
**Topics**
+ [Crie tópicos usando o Console de gerenciamento da AWS](create-topic-console.md)
+ [Crie um tópico usando o AWS CLI](create-topic-cli.md)
+ [Crie um tópico usando a API](create-topic-api.md)
# Crie tópicos usando o Console de gerenciamento da AWS
1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon MSK em [https://console.aws.amazon.com/msk/casa? region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/).
1. Na lista de clusters, escolha o nome do cluster em que você deseja criar os tópicos.
1. Na página de detalhes do cluster, escolha a guia **Tópicos**.
1. Escolha **Criar tópico**.
1. Insira o nome do tópico, a contagem de partições e o fator de replicação. Opcionalmente, adicione configurações. Você pode criar vários tópicos ao mesmo tempo.
1. Escolha **Criar tópico**.
# Crie um tópico usando o AWS CLI
Execute o comando a seguir, *ClusterArn* substituindo-o pelo Amazon Resource Name (ARN) do seu cluster. Se você não tiver o ARN do cluster, poderá encontrá-lo listando todos os clusters. Para obter mais informações, consulte [Listar clusters do Amazon MSK](msk-list-clusters.md).
```
aws kafka create-topic --cluster-arn ClusterArn --topic-name MyTopic --partition-count 3 --replication-factor 3
```
A saída desse comando é semelhante ao seguinte JSON de exemplo.
```
{
"topicArn": "arn:aws:kafka:us-east-1:123456789012:topic/MyCluster/abcd1234-abcd-dcba-4321-a1b2abcd9f9f-2/MyTopic",
"topicName": "MyTopic",
"status": "CREATING"
}
```
# Crie um tópico usando a API
Para criar um tópico usando a API, consulte [CreateTopic](https://docs.aws.amazon.com//msk/1.0/apireference/v1-clusters-clusterarn-topics.html#CreateTopic).
# Atualizar um tópico em um cluster do Amazon MSK
Atualize a contagem de partições ou as configurações em nível de tópico para um tópico existente. Essa operação modifica o tópico sem exigir recreação.
**nota**
Você pode atualizar a contagem de partições ou as configurações do tópico em uma única chamada de API, mas não em ambas simultaneamente. Para atualizar os dois, faça chamadas de API separadas.
**Topics**
+ [Atualizar um tópico usando o Console de gerenciamento da AWS](update-topic-console.md)
+ [Atualizar um tópico usando o AWS CLI](update-topic-cli.md)
+ [Atualizar um tópico usando a API](update-topic-api.md)
# Atualizar um tópico usando o Console de gerenciamento da AWS
1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon MSK em [https://console.aws.amazon.com/msk/casa? region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/).
1. Na lista de clusters, escolha o nome do cluster que contém o tópico que você deseja atualizar.
1. Na página de detalhes do cluster, escolha a guia **Tópicos**.
1. Selecione o tópico que você deseja atualizar e escolha **Editar configurações de partição** ou **Editar configurações** em **Ações**.
1. Atualize a contagem de partições ou as configurações conforme necessário.
1. Escolha **Salvar**.
# Atualizar um tópico usando o AWS CLI
Execute o comando a seguir, *ClusterArn* substituindo-o pelo Amazon Resource Name (ARN) do seu cluster e *TopicName* pelo nome do tópico que você deseja atualizar.
```
aws kafka update-topic --cluster-arn ClusterArn --topic-name TopicName --partition-count 6
```
A saída desse comando é semelhante ao seguinte JSON de exemplo.
```
{
"topicArn": "arn:aws:kafka:us-east-1:123456789012:topic/MyCluster/abcd1234-abcd-dcba-4321-a1b2abcd9f9f-2/MyTopic",
"topicName": "MyTopic",
"status": "UPDATING"
}
```
# Atualizar um tópico usando a API
Para atualizar um tópico usando a API, consulte [UpdateTopic](https://docs.aws.amazon.com//msk/1.0/apireference/v1-clusters-clusterarn-topics-topicname.html#UpdateTopic).
# Excluir um tópico em um cluster do Amazon MSK
A exclusão de um tópico remove permanentemente todos os seus dados, metadados e informações de partição. Esta operação não pode ser desfeita.
**Topics**
+ [Exclua um tópico usando o Console de gerenciamento da AWS](delete-topic-console.md)
+ [Exclua um tópico usando o AWS CLI](delete-topic-cli.md)
+ [Excluir um tópico usando a API](delete-topic-api.md)
# Exclua um tópico usando o Console de gerenciamento da AWS
1. Faça login no Console de gerenciamento da AWS e abra o console do Amazon MSK em [https://console.aws.amazon.com/msk/casa? region=us-east-1\$1/home/](https://console.aws.amazon.com/msk/home?region=us-east-1#/home/).
1. Na lista de clusters, escolha o nome do cluster que contém o tópico que você deseja excluir.
1. Na página de detalhes do cluster, escolha a guia **Tópicos**.
1. Selecione os tópicos que você deseja excluir e escolha **Excluir** das **ações**.
1. Confirme a exclusão e escolha **Excluir**.
# Exclua um tópico usando o AWS CLI
Execute o comando a seguir, *ClusterArn* substituindo-o pelo Amazon Resource Name (ARN) do seu cluster e *TopicName* pelo nome do tópico que você deseja excluir.
```
aws kafka delete-topic --cluster-arn ClusterArn --topic-name TopicName
```
A saída desse comando é semelhante ao seguinte JSON de exemplo.
```
{
"topicArn": "arn:aws:kafka:us-east-1:123456789012:topic/MyCluster/abcd1234-abcd-dcba-4321-a1b2abcd9f9f-2/MyTopic",
"topicName": "MyTopic",
"status": "DELETING"
}
```
# Excluir um tópico usando a API
Para excluir um tópico usando a API, consulte [DeleteTopic](https://docs.aws.amazon.com//msk/1.0/apireference/v1-clusters-clusterarn-topics-topicname.html#DeleteTopic).
# Recursos do Amazon MSK
Dependendo do contexto, o termo *recursos* tem dois significados no Amazon MSK. No contexto de APIs um recurso, há uma estrutura na qual você pode invocar uma operação. Para obter uma lista desses recursos e das operações que você pode invocar neles, consulte [Recursos](https://docs.aws.amazon.com/msk/1.0/apireference/resources.html) na Referência de API do Amazon MSK. No contexto do [Controle de acesso do IAM](iam-access-control.md), um recurso é uma entidade à qual você pode permitir ou proibir o acesso, conforme definido na seção [Recursos da política de autorização](kafka-actions.md#msk-iam-resources).
# Versões do Apache Kafka
Ao criar um cluster do Amazon MSK, você especifica qual versão do Apache Kafka deseja que ele tenha. Também é possível atualizar a versão do Apache Kafka de um cluster existente. Os tópicos do capítulo ajudam você a entender as linhas do tempo do suporte à versão Kafka e as sugestões de práticas recomendadas.
**Topics**
+ [Versões compatíveis do Apache Kafka](supported-kafka-versions.md)
+ [Suporte à versão do Amazon MSK](version-support.md)
# Versões compatíveis do Apache Kafka
O Amazon Managed Streaming for Apache Kafka (Amazon MSK) é compatível com as seguintes versões do Apache Kafka e do Amazon MSK. A comunidade do Apache Kafka fornece aproximadamente 12 meses de suporte para uma versão após sua data de lançamento. Para obter mais detalhes, consulte a [política de EOL (fim da vida útil) do Apache Kafka](https://cwiki.apache.org/confluence/display/KAFKA/Time+Based+Release+Plan#TimeBasedReleasePlan-WhatIsOurEOLPolicy?).
A tabela a seguir lista as versões do Apache Kafka compatíveis com o Amazon MSK.
| Versão Apache Kafka | Data de lançamento do MSK | Data do fim do suporte |
| --- | --- | --- |
| [1.1.1](https://archive.apache.org/dist/kafka/1.1.1/RELEASE_NOTES.html) | -- | 2024-06-05 |
| [2.1.0](https://archive.apache.org/dist/kafka/2.1.0/RELEASE_NOTES.html) | -- | 2024-06-05 |
| [2.2.1](https://archive.apache.org/dist/kafka/2.2.1/RELEASE_NOTES.html) | 31-07-2019 | 2024-06-08 |
| [2.3.1](https://archive.apache.org/dist/kafka/2.3.1/RELEASE_NOTES.html) | 19-12-2019 | 2024-06-08 |
| [2.4.1](https://archive.apache.org/dist/kafka/2.4.1/RELEASE_NOTES.html) | 02-04-2020 | 2024-06-08 |
| [2.4.1.1](https://archive.apache.org/dist/kafka/2.4.1/RELEASE_NOTES.html) | 2020-09-09 | 2024-06-08 |
| [2.5.1](https://archive.apache.org/dist/kafka/2.5.1/RELEASE_NOTES.html) | 2020-09-30 | 2024-06-08 |
| [2.6.0](https://archive.apache.org/dist/kafka/2.6.0/RELEASE_NOTES.html) | 2020-10-21 | 2024-09-11 |
| [2.6.1](https://archive.apache.org/dist/kafka/2.6.1/RELEASE_NOTES.html) | 2021-01-19 | 2024-09-11 |
| [2.6.2](https://archive.apache.org/dist/kafka/2.6.2/RELEASE_NOTES.html) | 2021-04-29 | 2024-09-11 |
| [2.6.3](https://archive.apache.org/dist/kafka/2.6.3/RELEASE_NOTES.html) | 2021-12-21 | 2024-09-11 |
| [2.7.0](https://archive.apache.org/dist/kafka/2.7.0/RELEASE_NOTES.html) | 2020-12-29 | 2024-09-11 |
| [2.7.1](https://archive.apache.org/dist/kafka/2.7.1/RELEASE_NOTES.html) | 2021-05-25 | 2024-09-11 |
| [2.7.2](https://archive.apache.org/dist/kafka/2.7.2/RELEASE_NOTES.html) | 2021-12-21 | 2024-09-11 |
| [2.8.0](https://archive.apache.org/dist/kafka/2.8.0/RELEASE_NOTES.html) | 2021-05-19 | 2024-09-11 |
| [2.8.1](https://archive.apache.org/dist/kafka/2.8.1/RELEASE_NOTES.html) | 28/10/2022 | 2024-09-11 |
| [2,8.2-tiered](https://archive.apache.org/dist/kafka/2.8.2/RELEASE_NOTES.html) | 28/10/2022 | 2025-01-14 |
| [3.1.1](https://archive.apache.org/dist/kafka/3.1.1/RELEASE_NOTES.html) | 2022-06-22 | 2024-09-11 |
| [3.2.0](https://archive.apache.org/dist/kafka/3.2.0/RELEASE_NOTES.html) | 2022-06-22 | 2024-09-11 |
| [3.3.1](https://archive.apache.org/dist/kafka/3.3.1/RELEASE_NOTES.html) | 2022-10-26 | 2024-09-11 |
| [3.3.2](https://archive.apache.org/dist/kafka/3.3.2/RELEASE_NOTES.html) | 2023-03-02 | 2024-09-11 |
| [3.4.0](https://archive.apache.org/dist/kafka/3.4.0/RELEASE_NOTES.html) | 2023-05-04 | 2025-08-04 |
| [3.5.1](https://archive.apache.org/dist/kafka/3.5.1/RELEASE_NOTES.html) | 2023-09-26 | 23/10/2025- |
| [3.6.0](https://archive.apache.org/dist/kafka/3.6.0/RELEASE_NOTES.html) | 2023-11-16 | 2026-06-01 |
| [3.7.x](https://archive.apache.org/dist/kafka/3.7.0/RELEASE_NOTES.html) | 2024-05-29 | -- |
| [3,8.x](https://downloads.apache.org/kafka/3.8.0/RELEASE_NOTES.html) | 2025-02-20 | -- |
| [3.9.x (recomendado](https://downloads.apache.org/kafka/3.9.0/RELEASE_NOTES.html)) | 2025-04-21 | -- |
| [4.0.x](https://downloads.apache.org/kafka/4.0.0/RELEASE_NOTES.html) | 2025-05-16 | -- |
| [4.1.x](https://downloads.apache.org/kafka/4.1.0/RELEASE_NOTES.html) | 2025-10-15 | -- |
Para obter mais informações sobre a política de compatibilidade de versão do Amazon EKS, consulte [Política de suporte à versão do Amazon MSK](version-support.md#version-support-policy).
## Amazon MSK versão 4.1.x
Agora o Amazon Managed Streaming for Apache Kafka (Amazon MSK) é compatível com o Apache Kafka versão 4.1, que introduz Filas como um recurso de pré-visualização, um novo protocolo de Rebalanceamento de fluxos em acesso antecipado e Réplicas de Líderes Elegíveis (ELR). Além desses recursos, o Apache Kafka versão 4.1 inclui várias correções de erros e melhorias.
Um dos principais destaques do Kafka 4.1 é a introdução de Filas como um recurso de pré-visualização. Você pode usar vários consumidores para processar mensagens das mesmas partições de tópicos, melhorando o paralelismo e a taxa de transferência de cargas de trabalho que precisam de entrega de mensagens. point-to-point O novo Protocolo de rebalanceamento de fluxos se baseia no protocolo de rebalanceamento do consumidor do Kafka 4.0, estendendo os recursos de coordenação do agente ao Kafka Streams para otimizar a atribuição e o rebalanceamento de tarefas. E agora o ELR está habilitado por padrão para fortalecer a disponibilidade.
Para obter uma lista completa de melhorias e correções de erros, consulte as [Notas de lançamento do Apache Kafka para a versão 4.1](https://downloads.apache.org/kafka/4.1.0/RELEASE_NOTES.html).
Para começar a usar o Apache Kafka 4.1 no Amazon MSK, escolha a versão 4.1.x ao criar um novo cluster por meio do, ou. Console de gerenciamento da AWS AWS CLI AWS SDKs Você também pode atualizar os clusters existentes provisionados pelo MSK com uma atualização contínua no local. O Amazon MSK orquestra as reinicializações de agentes para manter a disponibilidade e proteger seus dados durante a atualização. O suporte à versão 4.1 do Kafka está disponível em todos os lugares onde o Regiões da AWS Amazon MSK é oferecido.
## Amazon MSK versão 4.0.x
Agora o Amazon Managed Streaming for Apache Kafka (Amazon MSK) é compatível com o Apache Kafka versão 4.0. Essa versão traz os mais recentes avanços em gerenciamento e desempenho de clusters para o MSK Provisioned. O Kafka 4.0 introduz um novo protocolo de rebalanceamento do consumidor, agora disponível para o público geral, que ajuda a garantir rebalanceamentos de grupos mais suaves e rápidos. Além disso, o Kafka 4.0 exige que corretores e ferramentas usem o Java 17, fornecendo segurança e desempenho aprimorados, incluindo várias correções de bugs e melhorias e descontinuando o gerenciamento de metadados via Apache. ZooKeeper
Para obter uma lista completa de melhorias e correções de erros, consulte as [Notas de lançamento do Apache Kafka para a versão 4.0](https://downloads.apache.org/kafka/4.0.0/RELEASE_NOTES.html).
## Amazon MSK versão 3.9.x (recomendado)
Agora o Amazon Managed Streaming for Apache Kafka (Amazon MSK) é compatível com o Apache Kafka versão 3.9. Essa versão aprimora a funcionalidade de armazenamento em camadas, permitindo reter dados em camadas ao desativar o armazenamento em camadas no nível do tópico. As aplicações de consumo podem ler dados do histórico a partir do deslocamento remoto de início de logs (Rx – recepção) enquanto mantêm deslocamentos contínuos de logs nos armazenamentos local e remoto.
A versão 3.9 é a última versão a oferecer suporte aos sistemas de gerenciamento de KRaft metadados ZooKeeper e aos sistemas de gerenciamento de metadados. O Amazon MSK fornecerá suporte estendido para a versão 3.9 por no mínimo dois anos a partir da data de lançamento.
Para obter a lista completa de melhorias e correções de erros, consulte as [Notas de lançamento do Apache Kafka versão 3.9.x](https://downloads.apache.org/kafka/3.9.0/RELEASE_NOTES.html).
## Amazon MSK versão 3.8.x
Agora o Amazon Managed Streaming for Apache Kafka (Amazon MSK) é compatível com o Apache Kafka versão 3.8. Agora você pode criar novos clusters usando a versão 3.8 com o KRAFT ou o ZooKeeper modo para gerenciamento de metadados ou atualizar seus clusters ZooKeeper baseados existentes para usar a versão 3.8. O Apache Kafka versão 3.8 também inclui várias correções de erros e novos recursos que melhoram o desempenho. Os principais recursos novos incluem suporte para a configuração do nível de compressão. Assim você pode otimizar ainda mais seu desempenho ao usar tipos de compactação como lz4, zstd e gzip, permitindo a alteração do nível de compactação padrão.
Para obter a lista completa de melhorias e correções de erros, consulte as [Notas de lançamento do Apache Kafka versão 3.8.x](https://downloads.apache.org/kafka/3.8.0/RELEASE_NOTES.html).
## Apache Kafka versão 3.7.x (com armazenamento em camadas pronto para produção)
O Apache Kafka versão 3.7.x no MSK inclui compatibilidade com o Apache Kafka versão 3.7.0. Você pode criar clusters ou atualizar clusters existentes para usar a nova versão 3.7.x. Com essa mudança no nome da versão, você não precisa mais adotar versões mais recentes de correção de patches, como a 3.7.1, quando forem lançadas pela comunidade do Apache Kafka. O Amazon MSK atualizará automaticamente a versão 3.7.x para ser compatível com as futuras versões de patch assim que elas estiverem disponíveis. Isso permite que você se beneficie da segurança e das correções de erros disponíveis nas versões de correção de patches sem acionar uma atualização de versão. Essas versões de correção de patches lançadas pelo Apache Kafka não quebram a compatibilidade de versões e você pode se beneficiar das novas versões de correção de patches sem se preocupar com erros de leitura ou gravação nas aplicações clientes. Certifique-se de que suas ferramentas de automação de infraestrutura, como CloudFormation, estejam atualizadas para considerar essa alteração na nomenclatura da versão.
O Amazon MSK agora oferece suporte ao KRaft modo (Apache Kafka Raft) no Apache Kafka versão 3.7.x. No Amazon MSK, assim como ZooKeeper nos nós, KRaft os controladores são incluídos sem custo adicional para você e não exigem configuração ou gerenciamento adicionais de sua parte. Agora você pode criar clusters em qualquer KRaft modo ou ZooKeeper modo no Apache Kafka versão 3.7.x. No modo KRaft, você pode adicionar até 60 agentes para hospedar mais partições por cluster, sem solicitar um aumento de limite, em comparação com a cota de 30 agentes em clusters baseados no Zookeeper. Para saber mais KRaft sobre o MSK, consulte[KRaft modo](metadata-management.md#kraft-intro).
A versão 3.7.x do Apache Kafka também inclui várias correções de erros e novos recursos que melhoram a performance. As principais melhorias incluem otimizações de descoberta de líderes para clientes e opções de otimização de liberação de segmentos de logs. Para obter uma lista completa de melhorias e correções de erros, consulte as notas de lançamento do Apache Kafka para [3.7.0](https://archive.apache.org/dist/kafka/3.7.0/RELEASE_NOTES.html).
## Apache Kafka versão 3.6.0 (com armazenamento em camadas pronto para produção)
Para obter informações sobre a versão 3.6.0 (com armazenamento em camadas pronto para produção) do Apache Kafka, consulte as [notas de versão](https://archive.apache.org/dist/kafka/3.6.0/RELEASE_NOTES.html) no site de downloads do Apache Kafka.
Para fins de estabilidade, o Amazon MSK continuará usando e gerenciando o Zookeeper para gerenciamento de quórum nesta versão.
## Amazon MSK versão 3.5.1
O Amazon Managed Streaming for Apache Kafka (Amazon MSK) agora é compatível com a versão 3.5.1 do Apache Kafka para clusters novos e existentes. A versão 3.5.1 do Apache Kafka também inclui várias correções de erros e novos recursos que melhoram a performance. Os principais recursos incluem a introdução de uma nova atribuição de partições com reconhecimento de rack para consumidores. O Amazon MSK continuará a usar e gerenciar o Zookeeper para gerenciamento de quórum nesta versão. Para obter uma lista completa de melhorias e correções de erros, consulte as notas de lançamento do Apache Kafka para 3.5.1.
Para obter informações sobre a versão 3.5.1 do Apache Kafka, consulte as [notas de versão](https://archive.apache.org/dist/kafka/3.5.1/RELEASE_NOTES.html) no site de downloads do Apache Kafka.
## Amazon MSK versão 3.4.0
O Amazon Managed Streaming for Apache Kafka (Amazon MSK) agora é compatível com a versão 3.4.0 do Apache Kafka para clusters novos e existentes. A versão 3.4.0 do Apache Kafka também inclui várias correções de erros e novos recursos que melhoram a performance. Os principais recursos incluem uma correção para melhorar a estabilidade da busca na réplica mais próxima. O Amazon MSK continuará a usar e gerenciar o Zookeeper para gerenciamento de quórum nesta versão. Para obter uma lista completa de melhorias e correções de erros, consulte as notas de lançamento do Apache Kafka para 3.4.0.
Para obter informações sobre a versão 3.4.0 do Apache Kafka, consulte as [notas de versão](https://archive.apache.org/dist/kafka/3.4.0/RELEASE_NOTES.html) no site de downloads do Apache Kafka.
## Amazon MSK versão 3.3.2
O Amazon Managed Streaming for Apache Kafka (Amazon MSK) agora é compatível com a versão 3.3.2 do Apache Kafka para clusters novos e existentes. A versão 3.3.2 do Apache Kafka também inclui várias correções de erros e novos recursos que melhoram a performance. Os principais recursos incluem uma correção para melhorar a estabilidade da busca na réplica mais próxima. O Amazon MSK continuará a usar e gerenciar o Zookeeper para gerenciamento de quórum nesta versão. Para obter uma lista completa de melhorias e correções de erros, consulte as notas de lançamento do Apache Kafka para 3.3.2.
Para obter informações sobre a versão 3.3.2 do Apache Kafka, consulte as [notas de versão](https://archive.apache.org/dist/kafka/3.3.2/RELEASE_NOTES.html) no site de downloads do Apache Kafka.
## Amazon MSK versão 3.3.1
O Amazon Managed Streaming for Apache Kafka (Amazon MSK) agora é compatível com a versão 3.3.1 do Apache Kafka para clusters novos e existentes. A versão 3.3.1 do Apache Kafka também inclui várias correções de erros e novos recursos que melhoram a performance. Alguns dos principais recursos incluem aprimoramentos nas métricas e no particionador. Para fins de estabilidade, o Amazon MSK continuará usando e gerenciando o Zookeeper para gerenciamento de quórum nesta versão. Para obter uma lista completa de melhorias e correções de erros, consulte as notas de lançamento do Apache Kafka para 3.3.1.
Para obter informações sobre a versão 3.3.1 do Apache Kafka, consulte as [notas de versão](https://archive.apache.org/dist/kafka/3.3.1/RELEASE_NOTES.html) no site de downloads do Apache Kafka.
## Amazon MSK versão 3.1.1
O Amazon Managed Streaming for Apache Kafka (Amazon MSK) agora é compatível com a versões 3.1.1 e 3.2.0 do Apache Kafka para clusters novos e existentes. As versões 3.1.1 e 3.2.0 do Apache Kafka também incluem várias correções de erros e novos recursos que melhoram a performance. Alguns dos principais recursos incluem aprimoramentos nas métricas e no uso do tópico. IDs O MSK continuará a usar e gerenciar o Zookeeper para gerenciamento de quórum nesta versão para fins de estabilidade. Para obter uma lista completa de melhorias e correções de erros, consulte as notas de lançamento do Apache Kafka para 3.1.1 e 3.2.0.
Para obter informações sobre as versões 3.1.1 e 3.2.0 do Apache Kafka, consulte as [notas de lançamento da versão 3.2.0](https://archive.apache.org/dist/kafka/3.2.0/RELEASE_NOTES.html) e as [notas de lançamento da versão 3.1.1](https://archive.apache.org/dist/kafka/3.1.1/RELEASE_NOTES.html) no site de downloads do Apache Kafka.
## Armazenamento em camadas do Amazon MSK versão 2.8.2.tiered
Essa versão é uma versão exclusiva do Amazon MSK do Apache Kafka versão 2.8.2, sendo compatível com clientes Apache Kafka de código aberto.
[A versão 2.8.2.tiered contém a funcionalidade de armazenamento em camadas que é compatível com a APIs introduzida no KIP-405 para Apache Kafka.](https://cwiki.apache.org/confluence/display/KAFKA/KIP-405%3A+Kafka+Tiered+Storage) Para obter mais informações sobre o recurso de armazenamento em camadas do Amazon MSK, consulte [Armazenamento em camadas para agentes Standard](msk-tiered-storage.md).
## Apache Kafka versão 2.5.1
A versão 2.5.1 do Apache Kafka inclui várias correções de erros e novos recursos, incluindo criptografia em trânsito para clientes Apache e de administração. ZooKeeper O Amazon MSK fornece ZooKeeper endpoints TLS, que você pode consultar com a operação. [DescribeCluster ](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster)
A saída da [ DescribeCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster)operação inclui o `ZookeeperConnectStringTls` nó, que lista os endpoints do TLS zookeeper.
O exemplo a seguir mostra o nó `ZookeeperConnectStringTls` da resposta para a operação `DescribeCluster`:
```
"ZookeeperConnectStringTls": "z-3.awskafkatutorialc.abcd123.c3.kafka.us-east-1.amazonaws.com:2182,z-2.awskafkatutorialc.abcd123.c3.kafka.us-east-1.amazonaws.com:2182,z-1.awskafkatutorialc.abcd123.c3.kafka.us-east-1.amazonaws.com:2182"
```
Para obter informações sobre o uso da criptografia TLS com o zookeeper, consulte [Usando a segurança TLS com o Apache ZooKeeper](zookeeper-security-tls.md).
Para obter mais informações sobre a versão 2.5.1 do Apache Kafka, consulte as [notas de versão](https://archive.apache.org/dist/kafka/2.5.1/RELEASE_NOTES.html) no site de downloads do Apache Kafka.
## Correção de bugs do Amazon MSK versão 2.4.1.1
Essa versão é uma versão de correção de bugs do Apache Kafka versão 2.4.1 exclusiva do Amazon MSK. Essa versão de correção de bugs contém uma correção para o [KAFKA-9752](https://issues.apache.org/jira/browse/KAFKA-9752), um problema raro que faz com que grupos de consumidores façam o rebalanceamento contínuo e permaneçam no estado `PreparingRebalance`. Esse problema afeta clusters que executam as versões 2.3.1 e 2.4.1. Essa versão contém uma correção produzida pela comunidade que está disponível na versão 2.5.0 do Apache Kafka.
**nota**
Os clusters do Amazon MSK que executam a versão 2.4.1.1 são compatíveis com qualquer cliente Apache Kafka compatível com o Apache Kafka versão 2.4.1.
Recomendamos que você use a correção de bugs do MSK versão 2.4.1.1 para novos clusters do Amazon MSK se preferir usar o Apache Kafka 2.4.1. É possível atualizar os clusters existentes que executam o Apache Kafka versão 2.4.1 para essa versão a fim de incorporar essa correção. Para obter informações sobre como atualizar um cluster existente, consulte [Atualizar a versão do Apache Kafka](version-upgrades.md).
Para contornar esse problema sem atualizar o cluster para a versão 2.4.1.1, consulte a seção [Grupo de consumidores preso no estado `PreparingRebalance`](troubleshooting.md#consumer-group-rebalance) do guia [Solução de problemas para o cluster do Amazon MSK](troubleshooting.md).
## Apache Kafka versão 2.4.1 (use 2.4.1.1 alternativamente)
**nota**
Você não pode mais criar um cluster do MSK com o Apache Kafka versão 2.4.1. Em vez disso, você pode usar a versão [Correção de bugs do Amazon MSK versão 2.4.1.1](#2.4.1.1) com clientes compatíveis com o Apache Kafka versão 2.4.1. E se você já tiver um cluster do MSK com o Apache Kafka versão 2.4.1, recomendamos que você o atualize para usar o Apache Kafka versão 2.4.1.1.
O KIP-392 é uma das principais propostas de melhoria do Kafka incluídas na versão 2.4.1 do Apache Kafka. Essa melhoria permite que os consumidores busquem a partir da réplica mais próxima. Para usar esse recurso, defina `client.rack` nas propriedades do consumidor como o ID da zona de disponibilidade do consumidor. Um exemplo de ID AZ é `use1-az1`. O Amazon MSK define `broker.rack` as zonas IDs de disponibilidade dos corretores. Também é necessário definir a propriedade de configuração `replica.selector.class` como `org.apache.kafka.common.replica.RackAwareReplicaSelector`, que é uma implementação de reconhecimento de rack fornecida pelo Apache Kafka.
Quando você usa esta versão do Apache Kafka, as métricas no nível de monitoramento `PER_TOPIC_PER_BROKER` aparecem somente após os valores se tornarem diferentes de zero pela primeira vez. Para obter mais informações sobre isso, consulte [Monitoramento no nível `PER_TOPIC_PER_BROKER`](metrics-details.md#broker-topic-metrics).
Para obter informações sobre como encontrar a Zona de Disponibilidade IDs, consulte [AZ IDs for Your Resource](https://docs.aws.amazon.com/ram/latest/userguide/working-with-az-ids.html) no guia AWS Resource Access Manager do usuário.
Para obter informações sobre como definir propriedades de configuração, consulte [Configurações do Amazon MSK Provisioned](msk-configuration.md).
Para obter mais informações sobre o KIP-392, consulte [Permitir que os consumidores busquem a partir da réplica mais próxima](https://cwiki.apache.org/confluence/display/KAFKA/KIP-392:+Allow+consumers+to+fetch+from+closest+replica) nas páginas do Confluence.
Para obter mais informações sobre a versão 2.4.1 do Apache Kafka, consulte as [notas de release](https://archive.apache.org/dist/kafka/2.4.1/RELEASE_NOTES.html) no site de downloads do Apache Kafka.
# Suporte à versão do Amazon MSK
Este tópico descreve a [Política de suporte à versão do Amazon MSK](#version-support-policy) e o procedimento para [Atualizar a versão do Apache Kafka](version-upgrades.md). Se você estiver atualizando sua versão do Kafka, siga as práticas recomendadas descritas em [Práticas recomendadas para upgrades de versão](version-upgrades-best-practices.md).
**Topics**
+ [Política de suporte à versão do Amazon MSK](#version-support-policy)
+ [Atualizar a versão do Apache Kafka](version-upgrades.md)
+ [Práticas recomendadas para upgrades de versão](version-upgrades-best-practices.md)
## Política de suporte à versão do Amazon MSK
Esta seção descreve a política de suporte para as versões do Kafka compatíveis com o Amazon MSK.
+ Todas as versões do Kafka são compatíveis até atingirem a data do fim do suporte. Para obter detalhes sobre as datas de fim do suporte, consulte [Versões compatíveis do Apache Kafka](supported-kafka-versions.md). Atualize o cluster do MSK para a versão recomendada do Kafka ou superior antes da data do fim do suporte. Para obter detalhes sobre como atualizar sua versão do Apache Kafka, consulte [Atualizar a versão do Apache Kafka](version-upgrades.md). Um cluster usando uma versão do Kafka após a data do fim do suporte é atualizado automaticamente para a versão recomendada do Kafka. As atualizações automáticas podem ocorrer a qualquer momento após a data de fim do suporte. Você não receberá nenhuma notificação antes da atualização.
+ O MSK descontinuará gradualmente o suporte para clusters recém-criados que usam versões do Kafka com datas de fim de suporte publicadas.
# Atualizar a versão do Apache Kafka
É possível atualizar um cluster do MSK existente para uma versão mais recente do Apache Kafka. Antes de atualizar a versão do Kafka do seu cluster, verifique se a versão do software no lado do cliente é compatível com os recursos da nova versão do Kafka.
Para obter informações sobre como tornar um cluster altamente disponível durante uma atualização, consulte [Criar clusters altamente disponíveis](bestpractices.md#ensure-high-availability).
**Atualize a versão do Apache Kafka usando o Console de gerenciamento da AWS**
1. Abra o console do Amazon MSK em [https://console.aws.amazon.com/msk/](https://console.aws.amazon.com/msk/).
1. Na barra de navegação, escolha a região na qual você criou seu cluster do MSK.
1. Selecione o cluster do MSK que deseja atualizar.
1. Na guia **Propriedades**, escolha **Atualizar** na seção **Versão do Apache Kafka**.
1. Na seção **Versão do Apache Kafka**, faça o seguinte:
1. Na lista suspensa *Escolher versão do Apache Kafka*, escolha a versão de destino que você deseja atualizar. Para este exemplo, selecione **3.9.x**.
1. (Opcional) Escolha **Exibir compatibilidade de versão** para verificar a compatibilidade entre a versão atual do cluster e as versões de atualização disponíveis. Em seguida, selecione **Escolher** para continuar.
**nota**
O Amazon MSK oferece suporte a atualizações no local para a maioria das versões do Apache Kafka. No entanto, ao fazer o upgrade de uma versão ZooKeeper baseada no Kafka para uma versão KRaft baseada, você deve criar um novo cluster. Em seguida, copie seus dados para o novo cluster e troque os clientes para o novo cluster.
1. (Opcional) Marque a caixa de seleção **Atualizar configuração do cluster** para aplicar as atualizações de configuração compatíveis com a nova versão. Isso habilita os recursos e as melhorias da nova versão.
É possível ignorar esta etapa se for necessário manter suas configurações personalizadas existentes.
**nota**
As atualizações do lado do servidor não atualizam automaticamente as aplicações de clientes.
Para manter a estabilidade do cluster, não há suporte a downgrades de versão.
1. Escolha **Atualizar** para iniciar o processo.
**Atualize a versão do Apache Kafka usando o AWS CLI**
1. Execute o comando a seguir, substituindo *ClusterArn* pelo nome do recurso da Amazon (ARN) que você obteve quando criou o cluster. Se você não tiver o ARN do cluster, poderá encontrá-lo listando todos os clusters. Para obter mais informações, consulte [Listar clusters do Amazon MSK](msk-list-clusters.md).
```
aws kafka get-compatible-kafka-versions --cluster-arn ClusterArn
```
A saída desse comando inclui uma lista das versões do Apache Kafka para as quais você pode atualizar o cluster. Ela se parece com o exemplo a seguir.
```
{
"CompatibleKafkaVersions": [
{
"SourceVersion": "2.2.1",
"TargetVersions": [
"2.3.1",
"2.4.1",
"2.4.1.1",
"2.5.1"
]
}
]
}
```
1. Execute o comando a seguir, substituindo *ClusterArn* pelo nome do recurso da Amazon (ARN) que você obteve quando criou o cluster. Se você não tiver o ARN do cluster, poderá encontrá-lo listando todos os clusters. Para obter mais informações, consulte [Listar clusters do Amazon MSK](msk-list-clusters.md).
Substitua *Current-Cluster-Version* pela versão atual do cluster. Pois *TargetVersion* você pode especificar qualquer uma das versões de destino a partir da saída do comando anterior.
**Importante**
As versões de cluster não são inteiros simples. Para encontrar a versão atual do cluster, use a [DescribeCluster](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn.html#DescribeCluster)operação ou o comando [AWS CLI describe-cluster](https://awscli.amazonaws.com/v2/documentation/api/latest/reference/kafka/describe-cluster.html). Uma versão de exemplo é `KTVPDKIKX0DER`.
```
aws kafka update-cluster-kafka-version --cluster-arn ClusterArn --current-version Current-Cluster-Version --target-kafka-version TargetVersion
```
A saída do comando anterior é semelhante ao JSON a seguir.
```
{
"ClusterArn": "arn:aws:kafka:us-east-1:012345678012:cluster/exampleClusterName/abcdefab-1234-abcd-5678-cdef0123ab01-2",
"ClusterOperationArn": "arn:aws:kafka:us-east-1:012345678012:cluster-operation/exampleClusterName/abcdefab-1234-abcd-5678-cdef0123ab01-2/0123abcd-abcd-4f7f-1234-9876543210ef"
}
```
1. Para obter o resultado da `update-cluster-kafka-version` operação, execute o comando a seguir, *ClusterOperationArn* substituindo-o pelo ARN obtido na saída do `update-cluster-kafka-version` comando.
```
aws kafka describe-cluster-operation --cluster-operation-arn ClusterOperationArn
```
A saída desse comando `describe-cluster-operation` é semelhante ao seguinte JSON de exemplo.
```
{
"ClusterOperationInfo": {
"ClientRequestId": "62cd41d2-1206-4ebf-85a8-dbb2ba0fe259",
"ClusterArn": "arn:aws:kafka:us-east-1:012345678012:cluster/exampleClusterName/abcdefab-1234-abcd-5678-cdef0123ab01-2",
"CreationTime": "2021-03-11T20:34:59.648000+00:00",
"OperationArn": "arn:aws:kafka:us-east-1:012345678012:cluster-operation/exampleClusterName/abcdefab-1234-abcd-5678-cdef0123ab01-2/0123abcd-abcd-4f7f-1234-9876543210ef",
"OperationState": "UPDATE_IN_PROGRESS",
"OperationSteps": [
{
"StepInfo": {
"StepStatus": "IN_PROGRESS"
},
"StepName": "INITIALIZE_UPDATE"
},
{
"StepInfo": {
"StepStatus": "PENDING"
},
"StepName": "UPDATE_APACHE_KAFKA_BINARIES"
},
{
"StepInfo": {
"StepStatus": "PENDING"
},
"StepName": "FINALIZE_UPDATE"
}
],
"OperationType": "UPDATE_CLUSTER_KAFKA_VERSION",
"SourceClusterInfo": {
"KafkaVersion": "2.4.1"
},
"TargetClusterInfo": {
"KafkaVersion": "2.6.1"
}
}
}
```
Se `OperationState` tiver o valor `UPDATE_IN_PROGRESS`, aguarde um pouco e execute o comando `describe-cluster-operation` novamente. Quando a operação for concluída, o valor de `OperationState` será transformado em `UPDATE_COMPLETE`. Como o tempo necessário para que o Amazon MSK conclua a operação varia, talvez seja necessário verificar repetidamente até que a operação seja concluída.
**Atualizar a versão do Apache Kafka usando a API**
1. Invoque a [GetCompatibleKafkaVersions](https://docs.aws.amazon.com//msk/1.0/apireference/compatible-kafka-versions.html#GetCompatibleKafkaVersions)operação para obter uma lista das versões do Apache Kafka para as quais você pode atualizar o cluster.
1. Invoque a [UpdateClusterKafkaVersion](https://docs.aws.amazon.com//msk/1.0/apireference/clusters-clusterarn-version.html#UpdateClusterKafkaVersion)operação para atualizar o cluster para uma das versões compatíveis do Apache Kafka.
# Práticas recomendadas para upgrades de versão
Para garantir a continuidade do cliente durante a atualização contínua que é realizada como parte do processo de atualização da versão do Kafka, revise a configuração dos clientes e os tópicos do Apache Kafka da seguinte forma:
+ Defina o fator de replicação (RF) do tópico para um valor mínimo de `2` para clusters de duas AZs e um valor mínimo de `3` para clusters de três AZs. Um valor de RF de `2` pode levar a partições offline durante a aplicação de patches.
+ Defina o mínimo de réplicas sincronizadas (minISR) com um valor máximo de 1 a menos do que seu Fator de Replicação (RF), que é `miniISR = (RF) - 1`. Isso garante que o conjunto de réplicas de partições possa tolerar que uma réplica fique offline ou seja sub-replicada.
+ Configure os clientes para usar várias strings de conexão de agentes. Ter vários corretores na cadeia de conexão de um cliente permite o failover se um corretor específico que dá suporte ao cliente I/O começar a ser corrigido. Para obter informações sobre como obter uma string de conexão com vários agentes, consulte [Obter os agentes de bootstrap para um cluster do Amazon MSK](https://docs.aws.amazon.com//msk/latest/developerguide/msk-get-bootstrap-brokers.html).
+ Recomendamos que você atualize os clientes de conexão para a versão recomendada ou superior para se beneficiar dos recursos disponíveis na nova versão. As atualizações do cliente não estão sujeitas às datas de fim da vida útil (EOL) da versão Kafka do cluster do MSK e não precisam ser concluídas até a data de EOL. O Apache Kafka fornece uma [política bidirecional de compatibilidade de clientes](https://kafka.apache.org/protocol#protocol_compatibility) que permite que clientes mais antigos trabalhem com clusters mais novos, e vice-versa.
+ Os clientes Kafka que usam as versões 3.x.x provavelmente virão com os seguintes padrões: `acks=all` e `enable.idempotence=true`. `acks=all` é diferente do padrão anterior de `acks=1` e fornece durabilidade extra ao garantir que todas as réplicas sincronizadas reconheçam a solicitação de produção. Da mesma forma, o padrão para `enable.idempotence` era anteriormente `false`. A alteração para `enable.idempotence=true` como o padrão reduz a probabilidade de mensagens duplicadas. Essas alterações são consideradas configurações de práticas recomendadas e podem introduzir uma pequena quantidade de latência adicional que está dentro dos parâmetros normais de performance.
+ Use a versão recomendada do Kafka ao criar clusters do MSK. Usar a versão recomendada do Kafka permite que você se beneficie dos recursos mais recentes do Kafka e do MSK.
# Solução de problemas para o cluster do Amazon MSK
As informações a seguir podem ajudar você a solucionar problemas que possam surgir com seu cluster do Amazon MSK. Você também pode publicar seu problema no [AWS re:Post](https://repost.aws/). Para a solução de problemas do Replicador do Amazon MSK, consulte [Solucionar problemas do Replicador do MSK](msk-replicator-troubleshooting.md).
**Topics**
+ [A substituição do volume causa a saturação do disco devido à sobrecarga de replicação](#replication-overload-disk-saturation)
+ [Grupo de consumidores preso no estado `PreparingRebalance`](#consumer-group-rebalance)
+ [Erro ao entregar os registros do corretor para o Amazon CloudWatch Logs](#cw-broker-logs-error)
+ [Nenhum grupo de segurança padrão](#troubleshooting-shared-vpc)
+ [O cluster parece estar preso no estado CRIANDO](#troubleshooting-cluster-stuck)
+ [O estado do cluster é alterado de CRIANDO para COM FALHA](#troubleshooting-cluster-failed)
+ [O estado do cluster está ATIVO, mas os produtores não conseguem enviar dados ou os consumidores não conseguem receber dados](#troubleshooting-nodata)
+ [AWS CLI não reconhece o Amazon MSK](#troubleshooting-nocli)
+ [As partições ficam offline ou as réplicas estão fora de sincronia](#troubleshooting-offlinepartition-outofsyncreplicas)
+ [O espaço em disco está acabando](#troubleshooting-lowdiskspace)
+ [A memória está baixa](#troubleshooting-lowmemory)
+ [O produtor recebe NotLeaderForPartitionException](#troubleshooting-NotLeaderForPartitionException)
+ [Número de partições com replicação insuficiente (URP) maior que zero](#troubleshooting-urp)
+ [O cluster tem tópicos chamados \$1\$1amazon\$1msk\$1canary e \$1\$1amazon\$1msk\$1canary\$1state](#amazon_msk_canary)
+ [Falha na replicação de partições](#partition_replication_fails)
+ [Não é possível acessar o cluster que está com o acesso público ativado](#public-access-issues)
+ [Não é possível acessar o cluster por meio de IPv6 bootstrap](#dualstack-issues)
+ [Não é possível acessar o cluster de dentro AWS: problemas de rede](#networking-trouble)
+ [Falha na autenticação: muitas conexões](#troubleshoot-too-many-connects)
+ [Falha na autenticação: sessão muito curta](#troubleshoot-session-too-short)
+ [MSK com tecnologia sem servidor: falha na criação do cluster](#troubleshoot-serverless-create-cluster-failure)
+ [Não é possível atualizar KafkaVersionsList na configuração do MSK](#troubleshoot-kafkaversionslist-cfn-update-failure)
## A substituição do volume causa a saturação do disco devido à sobrecarga de replicação
Durante uma falha de hardware de volume não planejada, o Amazon MSK pode substituir o volume por uma nova instância. O Kafka preenche novamente o novo volume replicando partições de outros agentes no cluster. Depois que as partições são replicadas e recuperadas, elas se qualificam para associação de liderança e réplica em sincronia (ISR).
**Problema**
Em um agente se recuperando da substituição de volume, algumas partições de tamanhos variados podem voltar a ficar on-line antes de outras. Isso pode ser problemático, pois essas partições podem estar fornecendo tráfego do mesmo agente que ainda está recuperando (replicando) outras partições. Às vezes, esse tráfego de replicação pode saturar os limites de throughput do volume subjacente, que são de 250 MiB por segundo no caso padrão. Quando essa saturação ocorre, todas as partições que já estão atualizadas serão afetadas, resultando em latência em todo o cluster para qualquer agente que compartilhe a ISR com essas partições atualizadas (não apenas partições líderes devido a acks remotos `acks=all`). Esse problema é mais comum em clusters maiores que têm um número maior de partições que variam em tamanho.
**Recomendação**
+ Para melhorar a I/O postura de replicação, certifique-se de que [as configurações de thread de melhores práticas](https://docs.aws.amazon.com/msk/latest/developerguide/bestpractices.html#optimize-broker-threads) estejam em vigor.
+ Para reduzir a probabilidade de saturação do volume subjacente, habilite o armazenamento provisionado com um throughput mais alto. Um valor mínimo de taxa de transferência de 500 MiB/s é recomendado para casos de replicação de alta taxa de transferência, mas o valor real necessário variará de acordo com a taxa de transferência e o caso de uso. [Provisionar o throughput do armazenamento para agentes Standard em um cluster do Amazon MSK](msk-provision-throughput.md).
+ Para minimizar a pressão de replicação, reduza `num.replica.fetchers` para o valor padrão de `2`.
## Grupo de consumidores preso no estado `PreparingRebalance`
Se um ou mais de seus grupos de consumidores estiverem presos em um estado perpétuo de rebalanceamento, a causa disso pode ser o problema [KAFKA-9752](https://issues.apache.org/jira/browse/KAFKA-9752) do Apache Kafka, que afeta as versões 2.3.1 e 2.4.1 do Apache Kafka.
Para solucionar esse problema, recomendamos que você atualize seu cluster para a versão [Correção de bugs do Amazon MSK versão 2.4.1.1](supported-kafka-versions.md#2.4.1.1), que contém uma correção para esse problema. Para obter informações sobre a atualização de um cluster existente para a versão 2.4.1.1 de correção de bugs do Amazon MSK, consulte [Atualizar a versão do Apache Kafka](version-upgrades.md).
As soluções alternativas para resolver esse problema sem atualizar o cluster para a versão 2.4.1.1 de correção de bugs do Amazon MSK são definir os clientes do Kafka para usar [Protocolo de associação estática](#consumer-group-rebalance-static) ou [Identificar e reiniciar](#consumer-group-rebalance-reboot) o nó do agente de coordenação do grupo de consumidores que está preso.
### Implementação de protocolo de associação estática
Para implementar o protocolo de associação estática em seus clientes, faça o seguinte:
1. Defina a propriedade `group.instance.id` da sua configuração [Consumidores do Kafka](https://kafka.apache.org/26/javadoc/index.html?org/apache/kafka/clients/consumer/KafkaConsumer.html) como uma string estática que identifica o consumidor no grupo.
1. Certifique-se de que outras instâncias da configuração sejam atualizadas para usar a string estática.
1. Implante as mudanças em seus consumidores do Kafka.
O uso do Protocolo de associação estática é mais eficaz se o tempo limite da sessão na configuração do cliente for definido para uma duração que permita ao consumidor se recuperar sem acionar prematuramente um rebalanceamento do grupo de consumidores. Por exemplo, se sua aplicação consumidora conseguir tolerar 5 minutos de indisponibilidade, um valor razoável para o tempo limite da sessão seria 4 minutos em vez do valor padrão de 10 segundos.
**nota**
O uso do protocolo de associação estática simplesmente reduz a probabilidade de se deparar com esse problema. Você ainda poderá se deparar com esse problema mesmo ao usar o protocolo de associação estática.
### Como reinicializar o nó do agente de coordenação
Para reinicializar o nó agente de coordenação, faça o seguinte:
1. Identifique o coordenador do grupo usando o comando `kafka-consumer-groups.sh`.
1. Reinicie o coordenador do grupo de consumidores bloqueados usando a ação [ RebootBroker](https://docs.aws.amazon.com/msk/1.0/apireference/clusters-clusterarn-reboot-broker.html#RebootBroker)da API.
## Erro ao entregar os registros do corretor para o Amazon CloudWatch Logs
Ao tentar configurar seu cluster para enviar registros do agente para a Amazon CloudWatch Logs, você pode obter uma das duas exceções.
Se você receber uma exceção `InvalidInput.LengthOfCloudWatchResourcePolicyLimitExceeded`, tente novamente, mas use grupos de log que começam com `/aws/vendedlogs/`. Para obter mais informações, consulte [Habilitar o registro em log de determinados serviços da Amazon Web Services](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AWS-logs-and-resource-policy.html).
Se você receber uma `InvalidInput.NumberOfCloudWatchResourcePoliciesLimitExceeded` exceção, escolha uma política existente do Amazon CloudWatch Logs em sua conta e acrescente o seguinte JSON a ela.
```
{"Sid":"AWSLogDeliveryWrite","Effect":"Allow","Principal":{"Service":"delivery.logs.amazonaws.com"},"Action":["logs:CreateLogStream","logs:PutLogEvents"],"Resource":["*"]}
```
Se você tentar anexar o JSON acima a uma política existente, mas receber um erro informando que você atingiu o tamanho máximo da política escolhida, tente anexar o JSON a outra de suas políticas do Amazon Logs. CloudWatch Depois de acrescentar o JSON a uma política existente, tente novamente configurar a entrega de registros do corretor para o Amazon Logs. CloudWatch
## Nenhum grupo de segurança padrão
Se você tentar criar um cluster e obter um erro indicando que não há grupo de segurança padrão, talvez esteja usando uma VPC que foi compartilhada com você. Peça para o administrador conceder permissão para descrever os grupos de segurança nesta VPC e tente novamente. Para obter um exemplo de uma política que permita esta ação, consulte [Amazon EC2: permite o gerenciamento de grupos de segurança do EC2 associados a uma VPC específica de forma programática e no console](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_examples_ec2_securitygroups-vpc.html).
## O cluster parece estar preso no estado CRIANDO
Às vezes a criação do cluster pode levar até 30 minutos. Aguarde 30 minutos e verifique o estado do cluster novamente.
## O estado do cluster é alterado de CRIANDO para COM FALHA
Tente criar o cluster novamente.
## O estado do cluster está ATIVO, mas os produtores não conseguem enviar dados ou os consumidores não conseguem receber dados
+ Se a criação do cluster tiver êxito (o estado do cluster será `ACTIVE`), mas não será possível enviar nem receber dados. Certifique-se de que os aplicativos produtor e consumidor tenham acesso ao cluster. Para obter mais informações, consulte as diretrizes no [Etapa 3: criar uma máquina cliente](create-client-machine.md).
+ Caso os produtores e os consumidores tenham acesso ao cluster, mas ainda assim enfrentem problemas ao gerar e consumir dados, a causa pode ser [KAFKA-7697](https://issues.apache.org/jira/browse/KAFKA-7697), que afeta o Apache Kafka versão 2.1.0 e pode levar a um deadlock em um ou mais agentes. Considere migrar para o Apache Kafka 2.2.1, que não é afetado por este bug. Para obter informações sobre como migrar, consulte [Migrar workloads do Kafka para um cluster do Amazon MSK](migration.md).
## AWS CLI não reconhece o Amazon MSK
Se você o tiver AWS CLI instalado, mas ele não reconhecer os comandos do Amazon MSK, atualize-o AWS CLI para a versão mais recente. Para obter instruções detalhadas sobre como atualizar o AWS CLI, consulte [Instalando AWS Command Line Interface](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html) o. Para obter informações sobre como usar os comandos AWS CLI para executar o Amazon MSK, consulte[Principais recursos e conceitos do Amazon MSK](operations.md).
## As partições ficam offline ou as réplicas estão fora de sincronia
Estes podem ser sintomas de pouco espaço em disco. Consulte [O espaço em disco está acabando](#troubleshooting-lowdiskspace).
## O espaço em disco está acabando
Consulte as melhores práticas para gerenciar o espaço em disco: [Monitorar o espaço em disco](bestpractices.md#bestpractices-monitor-disk-space) e [Ajustar os parâmetros de retenção de dados](bestpractices.md#bestpractices-retention-period).
## A memória está baixa
Caso a métrica `MemoryUsed` esteja alta ou a `MemoryFree` esteja baixa, isso não significa que existe um problema. O Apache Kafka foi desenvolvido para usar o máximo de memória possível, que é gerenciada de forma ideal.
## O produtor recebe NotLeaderForPartitionException
Geralmente, isto é um erro transitório. Defina o parâmetro de configuração de `retries` do produtor com um valor mais alto que o atual.
## Número de partições com replicação insuficiente (URP) maior que zero
A `UnderReplicatedPartitions` é uma métrica importante e deve ser monitorada. Em um cluster MSK íntegro, essa métrica tem o valor igual a 0. Se for maior que zero, isso pode ocorrer por um dos motivos a seguir.
+ Se `UnderReplicatedPartitions` estiver apresentando picos, o problema pode ser que o cluster não foi provisionado no tamanho correto para tratar o tráfego de entrada e saída. Consulte [Melhores práticas para agentes Standard](bestpractices.md).
+ Se `UnderReplicatedPartitions` for consistentemente maior que 0, inclusive durante períodos de baixo tráfego, o problema pode ser que você tenha definido restrições ACLs que não concedem acesso ao tópico aos corretores. Para replicar partições, os agentes devem estar autorizados a READ (ler) e DESCRIBE (descrever) os tópicos. DESCRIBE é concedido por padrão com a autorização READ. Para obter informações sobre configuração ACLs, consulte [Autorização e ACLs](https://kafka.apache.org/documentation/#security_authz) na documentação do Apache Kafka.
## O cluster tem tópicos chamados \$1\$1amazon\$1msk\$1canary e \$1\$1amazon\$1msk\$1canary\$1state
Você pode ver que seu cluster do MSK tem um tópico com o nome `__amazon_msk_canary` e outro com o nome `__amazon_msk_canary_state`. Trata-se de tópicos internos que o Amazon MSK cria e usa para métricas de integridade e diagnóstico do cluster. Esses tópicos têm um tamanho insignificante e não podem ser excluídos.
## Falha na replicação de partições
Certifique-se de que você não tenha definido ACLs CLUSTER\$1ACTIONS.
## Não é possível acessar o cluster que está com o acesso público ativado
Siga as etapas abaixo se o seu cluster estiver com o acesso público ativado, mas você ainda não conseguir acessá-lo pela Internet:
1. Certifique-se de que as regras de entrada do grupo de segurança do cluster tenham permissão para seu endereço IP e a porta do cluster. Para obter uma lista dos números de portas do cluster, consulte [Informações de porta](port-info.md). Certifique-se também de que as regras de saída do grupo de segurança permitam comunicações de saída. Para ter mais informações sobre grupos de segurança e suas regras de entrada e saída, consulte [Grupos de segurança para sua VPC](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html) no Guia do usuário da Amazon VPC.
1. Certifique-se de que seu endereço IP e a porta do cluster tenham permissão nas regras de entrada da ACL da rede VPC do cluster. Ao contrário dos grupos de segurança, ACLs as redes não têm estado. Isso significa que você deve configurar as regras de entrada e saída. Nas regras de saída, permita que todo o tráfego (intervalo de portas: 0-65535) chegue ao seu endereço IP. Para obter mais informações, consulte [Adicionar e excluir regras](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-network-acls.html#Rules) no Guia do usuário da Amazon VPC.
1. Verifique se você está usando a string bootstrap-brokers de acesso público para acessar o cluster. Um cluster do MSK com acesso público ativado tem duas strings distintas de agentes de inicialização, uma para acesso público e outra para acesso interno diretamente da AWS. Para obter mais informações, consulte [Obtenha os corretores de bootstrap usando o Console de gerenciamento da AWS](get-bootstrap-console.md).
## Não é possível acessar o cluster por meio de IPv6 bootstrap
Se você estiver tendo problemas para se conectar a um cluster usando as strings de IPv6 bootstrap fornecidas, siga estas etapas:
1. Certifique-se de que seu cliente tenha endereços IPv4 e IPv6 atribuídos. Seu aplicativo cliente deve estar sendo executado em uma sub-rede que tenha o endereçamento IPv4 e IPv6 habilitado e configurado corretamente. Verifique se sua VPC tem um bloco CIDR IPv4 e um bloco CIDR IPv6 associado, confirme se sua sub-rede tem endereços IPv4 e IPv6 ativados e verifique se sua instância EC2 ou ambiente de cliente tem endereços e endereços atribuídos. IPv4 IPv6 Para obter mais informações, consulte o [endereçamento IP para você VPCs e suas sub-redes no Guia](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-ip-addressing.html) do usuário da Amazon VPC.
1. Certifique-se de que as IPv6 portas relevantes estejam presentes nas regras de entrada e saída do grupo de segurança. Adicione regras de entrada para permitir o tráfego nas portas do cluster a partir de seus IPv6 endereços e configure as regras de saída para permitir IPv6 o tráfego. Para obter números de porta específicos, consulte [Informações sobre portas](https://docs.aws.amazon.com/msk/latest/developerguide/port-info.html) na documentação do MSK. Lembre-se de atualizar ambas IPv4 as IPv6 regras se estiver executando no modo de pilha dupla. Para ter mais informações sobre grupos de segurança e suas regras de entrada e saída, consulte [Grupos de segurança para sua VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-security-groups.html) no Guia do usuário da Amazon VPC.
1. Verifique se a configuração da propriedade da JVM está correta para IPv6 suporte. Em seu aplicativo cliente, `java.net.preferIPv6Addresses` defina como `true` e `java.net.preferIPv4Stack` para`false`. Essas configurações podem ser definidas como propriedades do sistema ou argumentos da JVM. Reinicie seu aplicativo depois de fazer essas alterações para que elas entrem em vigor.
## Não é possível acessar o cluster de dentro AWS: problemas de rede
Se você tiver uma aplicação do Apache Kafka que não consiga se comunicar com êxito com um cluster do MSK, comece executando o teste de conectividade a seguir.
1. Use qualquer um dos métodos descritos em [Obter os agentes de bootstrap para um cluster do Amazon MSK](msk-get-bootstrap-brokers.md) para obter os endereços dos agentes de bootstrap.
1. No comando a seguir, *bootstrap-broker* substitua por um dos endereços do broker que você obteve na etapa anterior. *port-number*Substitua por 9094 se o cluster estiver configurado para usar a autenticação TLS. Se o cluster não usar a autenticação TLS, *port-number* substitua por 9092. Execute o comando usando a máquina cliente.
```
telnet bootstrap-broker port-number
```
Em que o número da porta será:
+ 9094 se o cluster estiver configurado para usar a autenticação TLS.
+ 9092 se o cluster não usar a autenticação TLS.
+ Um número de porta diferente será necessário se o acesso público estiver habilitado.
Execute o comando usando a máquina cliente.
1. Repita o comando anterior para todos os agentes de bootstrap.
Se a máquina cliente é capaz de acessar os agentes, isso significa que não há problemas de conectividade. Nesse caso, execute o comando a seguir para verificar se o cliente do Apache Kafka está configurado corretamente. Para obter*bootstrap-brokers*, use qualquer um dos métodos descritos em[Obter os agentes de bootstrap para um cluster do Amazon MSK](msk-get-bootstrap-brokers.md). *topic*Substitua pelo nome do seu tópico.
```
/bin/kafka-console-producer.sh --broker-list bootstrap-brokers --producer.config client.properties --topic topic
```
Se o comando anterior for bem-sucedido, isso indica que o cliente está configurado corretamente. Se você ainda não consegue produzir e consumir de um aplicativo, depure o problema no nível do aplicativo.
Se a máquina cliente não consegue acessar os agentes, consulte as subseções a seguir para obter orientações baseadas na configuração da máquina cliente.
### Cliente do Amazon EC2 e cluster do MSK na mesma VPC
Se a máquina cliente estiver na mesma VPC que o cluster do MSK, verifique se o grupo de segurança do cluster tem uma regra de entrada que aceite tráfego do grupo de segurança da máquina cliente. Para obter informações sobre como configurar essas regras, consulte [Regras do grupo de segurança](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_SecurityGroups.html#SecurityGroupRules). Para obter um exemplo de como acessar um cluster de uma instância do Amazon EC2 que esteja na mesma VPC do cluster, consulte [Conceitos básicos sobre como usar o Amazon MSK](getting-started.md).
### Cliente Amazon EC2 e cluster MSK em diferentes VPCs
Se a máquina cliente e o cluster estiverem em duas partes diferentes VPCs, verifique o seguinte:
+ Os dois VPCs são examinados.
+ O status da conexão de emparelhamento está ativo.
+ As tabelas de rotas dos dois VPCs estão configuradas corretamente.
Para obter informações sobre o emparelhamento de VPC, consulte [Trabalhar com conexões de emparelhamento de VPC](https://docs.aws.amazon.com/vpc/latest/peering/working-with-vpc-peering.html).
### Cliente on-premises
No caso de um cliente local configurado para se conectar ao cluster MSK usando Site-to-Site VPN, verifique o seguinte:
+ O status da conexão VPN é `UP`. Para obter informações sobre como verificar o status da conexão VPN, consulte [Como verificar o status atual do meu túnel VPN?](https://aws.amazon.com/premiumsupport/knowledge-center/check-vpn-tunnel-status/).
+ A tabela de rotas da VPC do cluster contém a rota para um CIDR on-premises, cujo destino tem o formato `Virtual private gateway(vgw-xxxxxxxx)`.
+ O grupo de segurança do cluster do MSK permite tráfego na porta 2181, na porta 9092 (se o cluster aceitar tráfego em texto simples) e na porta 9094 (se o cluster aceitar tráfego com criptografia TLS).
Para obter mais orientações sobre Site-to-Site VPN solução de problemas, consulte [Solução de problemas do Client VPN](https://docs.aws.amazon.com/vpn/latest/clientvpn-admin/troubleshooting.html).
### Direct Connect
Se o cliente usar Direct Connect, consulte [Solução de problemas Direct Connect](https://docs.aws.amazon.com/directconnect/latest/UserGuide/Troubleshooting.html).
Se as orientações para a solução de problemas anteriores não resolverem a situação, certifique-se de que nenhum firewall esteja bloqueando o tráfego de rede. Para depuração adicional, use ferramentas como `tcpdump` e `Wireshark` para analisar o tráfego e garantir que ele esteja alcançando o cluster do MSK.
## Falha na autenticação: muitas conexões
O erro `Failed authentication ... Too many connects` indica que um agente está se protegendo porque um ou mais clientes do IAM estão tentando se conectar a ele em um ritmo agressivo. Para ajudar os agentes a aceitarem uma taxa maior de novas conexões do IAM, você pode aumentar o parâmetro de configuração [https://kafka.apache.org/documentation/#producerconfigs_reconnect.backoff.ms](https://kafka.apache.org/documentation/#producerconfigs_reconnect.backoff.ms).
Para saber mais sobre os limites de taxa para novas conexões por agente, consulte a página [Cota do Amazon MSK](limits.md).
## Falha na autenticação: sessão muito curta
O erro `Failed authentication ... Session too short` ocorre quando seu cliente tenta se conectar a um cluster usando credenciais do IAM que estão prestes a expirar. Certifique-se de verificar como suas credenciais do IAM têm sido atualizadas. Provavelmente as credenciais estão sendo substituídas muito perto da expiração da sessão, o que causa problemas no servidor e falhas de autenticação.
## MSK com tecnologia sem servidor: falha na criação do cluster
Se você tentar criar um cluster do MSK com a tecnologia sem servidor e o fluxo de trabalho falhar, talvez você não tenha permissão para criar um endpoint da VPC. Verifique se o administrador concedeu permissão para você criar um endpoint da VPC permitindo a ação `ec2:CreateVpcEndpoint`.
Para obter uma lista completa das permissões necessárias para realizar todas as ações do Amazon MSK, consulte [AWS política gerenciada: Amazon MSKFull Access](security-iam-awsmanpol-AmazonMSKFullAccess.md).
## Não é possível atualizar KafkaVersionsList na configuração do MSK
Quando você atualiza a [KafkaVersionsList](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-msk-configuration.html#cfn-msk-configuration-kafkaversionslist)propriedade no [AWS::MSK::Configuration](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-msk-configuration.html)recurso, a atualização falha com o seguinte erro.
```
Resource of type 'AWS::MSK::Configuration' with identifier '' already exists.
```
Ao atualizar a `KafkaVersionsList` propriedade, AWS CloudFormation recria uma nova configuração com a propriedade atualizada antes de excluir a configuração antiga. A atualização da CloudFormation pilha falha porque a nova configuração usa o mesmo nome da configuração existente. Essa atualização requer uma [substituição de recurso](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/using-cfn-updating-stacks-update-behaviors.html#update-replacement). Para atualizar `KafkaVersionsList` com êxito, você também deve atualizar a propriedade [Nome](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-msk-configuration.html#cfn-msk-configuration-name) na mesma operação.
Além disso, se sua configuração estiver vinculada a qualquer cluster criado usando o Console de gerenciamento da AWS ou AWS CLI, adicione o seguinte ao seu recurso de configuração para evitar [tentativas malsucedidas de exclusão de recursos](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/troubleshooting.html#troubleshooting-errors-resource-removed-not-deleted).
```
UpdateReplacePolicy: Retain
```
Depois que a atualização for bem-sucedida, acesse o console do Amazon MSK e exclua a configuração antiga. Para obter informações sobre configurações do MSK, consulte [Configurações do Amazon MSK Provisioned](msk-configuration.md).