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á. # Privacidade do tráfego entre redes O MemoryDB usa as seguintes técnicas para guardar seus dados e protegê-los contra o acesso não autorizado: + **[MemoryDB e Amazon VPC](vpcs.md)** explica o tipo de grupo de segurança de que você precisa para sua instalação. + **[Endpoints de API e interface da VPC do MemoryDB (AWS PrivateLink)](memorydb-privatelink.md)** permitem estabelecer uma conexão privada entre os endpoints da VPC e de API do MemoryDB. + **[Gerenciamento de identidade e acesso no MemoryDB](iam.md)** para conceder e limitar ações de usuários, grupos e funções. # MemoryDB e Amazon VPC O serviço da Amazon Virtual Private Cloud (Amazon VPC) define uma rede virtual que lembra muito um datacenter tradicional. Ao configurar uma nuvem privada virtual (VPC) com a Amazon VPC, você pode selecionar seu intervalo de endereços IP, criar sub-redes e configurar tabelas de rotas, gateways de rede e configurações de segurança. Você também pode adicionar um cluster à rede virtual e controlar o acesso ao cluster usando os grupos de segurança da Amazon VPC. Esta seção explica como configurar manualmente um cluster do MemoryDB em uma VPC. Essas informações destinam-se a usuários que desejam ter uma compreensão mais profunda de como o MemoryDB e a Amazon VPC funcionam juntos. **Topics** + [Entendendo o MemoryDB e as VPCs](vpcs.mdb.md) + [Padrões de acesso para acessar um cluster do MemoryDB em uma Amazon VPC](memorydb-vpc-accessing.md) + [Criar uma nuvem privada virtual (VPC)](VPCs.creatingVPC.md) # Entendendo o MemoryDB e as VPCs O MemoryDB é totalmente integrado à Amazon VPC. Para usuários do MemoryDB, isso significa o seguinte: + O MemoryDB sempre inicia seu cluster em uma VPC. + Se você for novato na AWS, uma VPC padrão será criada automaticamente para você. + Se você tiver uma VPC padrão e não especificar uma sub-rede quando executar um cluster, este será iniciado na sua Amazon VPC padrão. Para mais informações, consulte [Detecção de suas plataformas compatíveis e se você tem um VPC padrão](https://docs.aws.amazon.com/vpc/latest/userguide/default-vpc.html#detecting-platform). Com a Amazon VPC, você pode criar uma rede virtual na nuvem da AWS que se assemelha muito com um datacenter tradicional. É possível configurar sua VPC, incluindo selecionar o intervalo de endereços IP, criar sub-redes e definir tabelas de rotas, gateways de rede e configurações de segurança. O MemoryDB gerencia atualizações de software, patches, detecção de falhas e recuperação. ## Visão geral do MemoryDB em uma VPC + A VPC é uma parte isolada da nuvem da AWS que recebe seu próprio bloco de endereços IP. + Um gateway da Internet conecta sua VPC diretamente à Internet e fornece acesso a outros recursos da AWS, como o Amazon Simple Storage Service (Amazon S3), que estão em execução fora da sua VPC. + Uma sub-rede do Amazon VPC é um segmento do intervalo de endereços IP de um VPC em que você pode isolar recursos da AWS de acordo com suas necessidades operacionais e de segurança. + Um grupo de segurança do Amazon VPC controla o tráfego de entrada e saída de seus clusters do MemoryDB e instâncias do Amazon EC2. + Você pode ativar um cluster do MemoryDB na sub-rede. Os nós possuem endereços IP privados a partir do intervalo de endereços da sub-rede. + Você também pode ativar instâncias do Amazon EC2 na sub-rede. Cada instância do Amazon EC2 tem um endereço IP privado do intervalo de endereços da sub-rede. A instância do Amazon EC2 pode se conectar a qualquer nó na mesma sub-rede. + Para que uma instância do Amazon EC2 em sua VPC possa ser acessada pela Internet, você precisa atribuir um endereço público estático chamado endereço Elastic IP à instância. ## Pré-requisitos Para criar um cluster do MemoryDB em uma VPC, sua VPC deve atender aos seguintes requisitos: + A VPC deve permitir instâncias do Amazon EC2 não dedicadas. Você não pode usar o MemoryDB em uma VPC que está configurada para a locação de instâncias dedicadas. + Um grupo de sub-redes de cache deve ser definido para a sua VPC. O MemoryDB utiliza esse grupo de sub-redes para selecionar uma sub-rede e endereços IP nessa sub-rede para associar aos seus nós. + Um grupo de segurança deve ser definido para a sua VPC, ou você pode usar o padrão fornecido. + Os blocos CIDR para cada sub-rede devem ser suficientemente grandes para fornecer endereços IP de reposição para o MemoryDB usar durante atividades de manutenção. ## Roteamento e segurança Você pode configurar o roteamento na sua VPC para controlar para onde o tráfego flui (por exemplo, para o gateway da Internet ou o gateway privado virtual). Com um gateway da Internet, sua VPC tem acesso direto a outros recursos da AWS que não estão sendo executados na sua VPC. Se você optar por ter apenas um gateway virtual privado com uma conexão com a rede local da sua organização, poderá rotear seu tráfego vinculado à Internet através da VPN e usar políticas de segurança locais e um firewall para controlar a saída. Nesse caso, você está sujeito a cobranças adicionais de largura de banda ao acessar os recursos da AWS pela Internet. Você pode usar grupos de segurança da Amazon VPC para ajudar a proteger os clusters do MemoryDB e as instâncias do Amazon EC2 na sua Amazon VPC. Os security groups atuam como um firewall no nível da instância e não no nível da sub-rede. **nota** Recomendamos enfaticamente que você use nomes DNS para se conectar aos seus nós, pois o endereço IP subjacente pode mudar com o tempo. ## Documentação da Amazon VPC A Amazon VPC tem seu próprio conjunto de documentação para descrever como criar e usar sua Amazon VPC. A tabela a seguir mostra onde encontrar informações nos guias sobre a Amazon VPC. | Descrição | Documentação | | --- | --- | | Como começar a usar a Amazon VPC | [Conceitos básicos do Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-getting-started.html) | | Como usar a Amazon VPC por meio do Console de gerenciamento da AWS | [Guia do usuário da Amazon VPC](https://docs.aws.amazon.com/vpc/latest/userguide/) | | Descrições completas de todos os comandos da Amazon VPC | [Referência da linha de comando do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/CommandLineReference/) (os comandos da Amazon VPC são encontrados na referência do Amazon EC2) | | Descrições completas das operações da API da Amazon VPC, tipos de dados e erros da Amazon VPC | [Referência da API do Amazon EC2](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/) (as operações da Amazon VPC são encontrados na referência do Amazon EC2) | | Informações para o administrador da rede que precisa configurar o gateway no final de uma conexão VPN IPsec opcional | [O que é a AWS VPN Site-to-Site?](https://docs.aws.amazon.com/vpn/latest/s2svpn/VPC_VPN.html) | Para obter informações mais detalhadas sobre a Amazon Virtual Private Cloud, consulte [Amazon Virtual Private Cloud](https://aws.amazon.com/vpc/). # Padrões de acesso para acessar um cluster do MemoryDB em uma Amazon VPC O MemoryDB oferece suporte aos seguintes cenários para acessar um cluster em uma Amazon VPC: **Contents** + [Acesso a um cluster do MemoryDB quando ele e a instância do Amazon EC2 estão na mesma Amazon VPC](#memorydb-vpc-accessing-same-vpc) + [Acesso a um cluster do MemoryDB quando ele e a instância do Amazon EC2 estão em diferentes Amazon VPCs](#memorydb-vpc-accessing-different-vpc) + [Em Amazon VPCs diferentes na mesma região](#memorydb-vpc-accessing-different-vpc-same-region) + [Uso do Transit Gateway](#memorydb-vpc-accessing-using-transit-gateway) + [Em diferentes Amazon VPCs em regiões diferentes](#memorydb-vpc-accessing-different-vpc-different-region) + [Uso da VPC de trânsito](#memorydb-vpc-accessing-different-vpc-different-region-using-transit-vpc) + [Acessar um cluster do MemoryDB a partir de um aplicativo executado no datacenter de um cliente](#memorydb-vpc-accessing-data-center) + [Usar conectividade de VPN](#memorydb-vpc-accessing-data-center-vpn) + [Usar o Direct Connect](#memorydb-vpc-accessing-data-center-direct-connect) ## Acesso a um cluster do MemoryDB quando ele e a instância do Amazon EC2 estão na mesma Amazon VPC O caso de uso mais comum é quando uma aplicação implantada em uma instância do EC2 precisa se conectar a um cluster na mesma VPC. A maneira mais simples de gerenciar o acesso entre instâncias do EC2 e clusters na mesma VPC é fazer o seguinte: 1. Crie um grupo de segurança de VPC para o seu cluster. Esse grupo de segurança pode ser usado para restringir o acesso aos clusters. Por exemplo, é possível criar uma regra personalizada para esse grupo de segurança que permite o acesso TCP usando a porta atribuída ao cluster quando você o criou e um endereço IP que será usado para acessar o cluster. A porta padrão dos clusters do MemoryDB é `6379`. 1. Crie um grupo de segurança de VPC para suas instâncias do EC2 (servidores Web e de aplicativos). Esse grupo de segurança pode, se necessário, permitir o acesso à instância do EC2 da Internet através da tabela de rotas da VPC. Por exemplo, você pode definir regras nesse grupo de segurança para permitir o acesso TCP à instância do EC2 pela porta 22. 1. Crie regras personalizadas no grupo de segurança para o seu cluster que permitam conexões do grupo de segurança que você criou para suas instâncias do EC2. Isso permitiria que qualquer membro de grupo de segurança acessasse os clusters. **Para criar uma regra em um grupo de segurança de VPC que permita conexões de outro grupo de segurança** 1. Faça login no AWSConsole de Gerenciamento e abra o console da Amazon VPC em [https://console.aws.amazon.com/vpc](https://console.aws.amazon.com/vpc). 1. No painel de navegação esquerdo, escolha **Security Groups**. 1. Selecione ou crie um grupo de segurança que você usará para seus clusters. Em **Regras de entrada**, selecione **Editar regras de entrada** e escolha **Adicionar regra**. Esse grupo de segurança permitirá o acesso a membros de outro grupo de segurança. 1. Em **Tipo**, escolha **Regra TCP personalizada**. 1. Para **Port Range**, especifique a porta que você usou quando criou seu cluster. A porta padrão dos clusters do MemoryDB é `6379`. 1. Na caixa **Source**, comece a digitar o ID do grupo de segurança. Na lista, selecione o grupo de segurança que você usará para o suas instâncias do Amazon EC2. 1. Escolha **Save** quando terminar. ## Acesso a um cluster do MemoryDB quando ele e a instância do Amazon EC2 estão em diferentes Amazon VPCs Quando seu cluster está em uma VPC diferente da instância do EC2 que você está usando para acessá-lo, existem várias maneiras de acessar o cluster. Se o cluster e a instância do EC2 estiverem em VPCs diferentes, mas na mesma região, você poderá usar o emparelhamento de VPCs. Se o cluster e a instância do EC2 estiverem em regiões diferentes, você poderá criar conectividade via VPN entre regiões. **Topics** + [Em Amazon VPCs diferentes na mesma região](#memorydb-vpc-accessing-different-vpc-same-region) + [Em diferentes Amazon VPCs em regiões diferentes](#memorydb-vpc-accessing-different-vpc-different-region)   ### Acesso a um cluster do MemoryDB quando ele e a instância do Amazon EC2 estão em diferentes Amazon VPCs na mesma região *Cluster acessado por uma instância do Amazon EC2 em uma Amazon VPC diferente na mesma região - conexão de emparelhamento de VPCs* Uma conexão de emparelhamento da VPC é uma conexão de redes entre duas VPCs que permite direcionar o tráfego entre elas usando endereços IP privados. Instâncias em qualquer VPC podem se comunicar umas com as outras como se estivessem na mesma rede. Você pode criar uma conexão de emparelhamento de VPCs entre suas próprias Amazon VPCs ou com uma Amazon VPC em outra conta da AWS em uma única região. Para saber mais sobre o emparelhamento de Amazon VPCs, consulte a [documentação da VPC](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/vpc-peering.html). **Para acessar um cluster em uma Amazon VPC diferente por emparelhamento** 1. Certifique-se de que as duas VPCs não tenham um intervalo de IP sobreposto, ou você não poderá compará-las. 1. Emparelhe as duas VPCs. Para obter mais informações, consulte [Criação e aceitação de uma conexão de emparelhamento da Amazon VPC](https://docs.aws.amazon.com/AmazonVPC/latest/PeeringGuide/create-vpc-peering-connection.html). 1. Atualize sua tabela de roteamento. Para obter mais informações, consulte [Atualizar as tabelas de rotas para uma conexão de emparelhamento de VPC](https://docs.aws.amazon.com/AmazonVPC/latest/PeeringGuide/vpc-peering-routing.html) 1. Modifique o grupo de segurança do cluster do MemoryDB para permitir a conexão de entrada do grupo de segurança do aplicativo na VPC emparelhada. Para obter mais informações, consulte a [Referência para security groups de VPC de emparelhamento](https://docs.aws.amazon.com/AmazonVPC/latest/PeeringGuide/vpc-peering-security-groups.html). O acesso a um cluster por meio de uma conexão de emparelhamento implicará custos adicionais de transferência de dados.   #### Uso do Transit Gateway Um Transit Gateway permite anexar VPCs e conexões VPN na mesma região da AWS e rotear tráfego entre elas. Um Transit Gateway funciona em contas da AWS, e você pode usar o Resource Access Manager da AWS para compartilhar o Transit Gateway com outras contas. Depois de compartilhar um gateway de trânsito com outra conta da AWS, o proprietário da conta poderá anexar as VPCs dele ao gateway de trânsito. Um usuário de qualquer uma das contas pode excluir o anexo a qualquer momento. É possível ativar o multicast em um gateway de trânsito e, depois, criar um domínio de multicast do gateway de trânsito que permita ao tráfego de multicast ser enviado da origem de multicast para membros do grupo de multicast em anexos da VPC associados ao domínio. Também é possível criar um anexo da conexão de emparelhamento entre gateways de trânsito em diferentes regiões da AWS. Isso permite que você roteie o tráfego entre os anexos dos gateways de trânsito em regiões diferentes. Para obter mais informações, consulte [Gateways de trânsito](https://docs.aws.amazon.com/vpc/latest/tgw/tgw-transit-gateways.html). ### Acesso a um cluster do MemoryDB quando ele e a instância do Amazon EC2 estão em diferentes Amazon VPCs em regiões diferentes #### Uso da VPC de trânsito Uma alternativa ao uso do emparelhamento de VPC, outra estratégia comum para conectar várias VPCs geograficamente dispersas e redes remotas é criar uma VPC de trânsito que serve como um centro de trânsito de rede global. Uma VPC de trânsito simplifica o gerenciamento da rede e minimiza o número de conexões necessárias para conectar várias VPCs e redes remotas. Esse design pode economizar tempo e esforços e também reduzir custos, uma vez que é implementado praticamente sem as despesas tradicionais de estabelecer uma presença física em um hub de trânsito de colocação ou implantar equipamentos de rede física. *Conexão entre diferentes VPCs em regiões distintas* Depois de estabelecida a Amazon VPC de trânsito, um aplicativo implantado em uma VPC “spoke” em uma região pode se conectar a um cluster do MemoryDB em uma VPC “spoke” de outra região. **Para acessar um cluster em um VPC diferente dentro de uma região da AWS diferente** 1. Implante uma solução de VPC de trânsito. Para obter mais informações, consulte [ Transit Gateway da AWS](https://aws.amazon.com/transit-gateway/). 1. Atualize as tabelas de rotas VPC no aplicativo e as VPCs para rotear o tráfego por meio do Gateway privado virtual (Virtual Private Gateway, VGW) e do dispositivo VPN. No caso do Roteamento dinâmico com o protocolo BGP, suas rotas podem ser propagadas automaticamente. 1. Modifique o grupo de segurança do seu cluster do MemoryDB para permitir a conexão de entrada do intervalo IP de instâncias do aplicativo. Observe que você não poderá fazer referência ao security group do servidor de aplicativos nesse cenário. O acesso a um cluster entre regiões introduzirá latências de rede e custos adicionais de transferência de dados entre regiões. ## Acessar um cluster do MemoryDB a partir de um aplicativo executado no datacenter de um cliente Outro cenário possível é uma arquitetura híbrida em que clientes ou aplicativos no datacenter do cliente podem precisar acessar um cluster do MemoryDB na VPC. Esse cenário também tem suporte, desde que haja conectividade entre a VPC dos clientes e o datacenter via VPN ou Direct Connect. **Topics** + [Usar conectividade de VPN](#memorydb-vpc-accessing-data-center-vpn) + [Usar o Direct Connect](#memorydb-vpc-accessing-data-center-direct-connect)   ### Acessar um cluster do MemoryDB a partir de um aplicativo executado no datacenter de um cliente usando conectividade de VPN *Conectar ao MemoryDB a partir do seu datacenter através de uma VPN* **Para acessar um cluster em uma VPC a partir do aplicativo no local via conexão VPN** 1. Estabeleça a conectividade de VPN adicionando um gateway privado virtual de hardware à sua VPC. Para obter mais informações, consulte o tópico sobre como [Adicionar um gateway privado virtual de hardware à sua VPC](https://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_VPN.html). 1. Atualize a tabela de rotas de VPC para a sub-rede na qual seu cluster do MemoryDB está implantado para permitir o tráfego do seu servidor de aplicativos on-premises. No caso do Roteamento dinâmico com o BGP, suas rotas podem ser propagadas automaticamente. 1. Modifique o grupo de segurança do seu cluster do MemoryDB para permitir a conexão de entrada dos servidores de aplicativos on-premises. Acessar um cluster através de uma conexão VPN introduzirá latências de rede e custos adicionais de transferência de dados.   ### Acessar um cluster do MemoryDB a partir de um aplicativo executado no datacenter de um cliente usando o Direct Connect *Conectar-se ao MemoryDB a partir do seu datacenter via Direct Connect* **Para acessar um cluster do MemoryDB de um aplicativo executado em sua rede usando o Direct Connect** 1. Estabeleça a conectividade Direct Connect. Para obter mais informações, consulte [Conceitos básicos do Direct Connect da AWS](https://docs.aws.amazon.com/directconnect/latest/UserGuide/getting_started.html). 1. Modifique o grupo de segurança do seu cluster do MemoryDB para permitir a conexão de entrada dos servidores de aplicativos on-premises. O acesso a um cluster por meio de uma conexão DX pode introduzir latências de rede e taxas adicionais de transferência de dados. # Criar uma nuvem privada virtual (VPC) Neste exemplo, você cria uma nuvem privada virtual (VPC) com base no serviço Amazon VPC com uma sub-rede privada para cada zona de disponibilidade. ## Criação de uma VPC (console) **Para criar um cluster do MemoryDB em um Amazon Virtual Private Cloud** 1. Faça login no Console de Gerenciamento da AWS e abra o console da Amazon VPC em [https://console.aws.amazon.com/vpc](https://console.aws.amazon.com/vpc/). 1. No painel da VPC, escolha **Criar VPC**. 1. Em **Recursos a serem criados**, escolha **VPC e mais**. 1. Em **Número de zonas de disponibilidade (ZAs)**, escolha o número de zonas de disponibilidade nas quais iniciar suas sub-redes. 1. Em **Número de sub-redes públicas**, escolha o número de sub-redes públicas que você deseja adicionar à sua VPC. 1. Em **Número de sub-redes privadas**, escolha o número de sub-redes públicas que você deseja adicionar à sua VPC. **dica** Anote os identificadores das sub-redes e indique quais são públicas e quais são privadas. Você precisará dessas informações mais tarde quando ativar seus clusters de cache e adicionar uma instância do Amazon EC2 à sua Amazon VPC. 1. Crie um grupo de segurança da Amazon VPC. Você usará esse grupo para seu cluster e sua instância do Amazon EC2. 1. No painel de navegação esquerdo da tela do Console de gerenciamento da AWS, selecione **Grupos de segurança**. 1. Escolha **Criar grupo de segurança**. 1. Digite um nome e uma descrição do seu grupo de segurança nas caixas correspondentes. Para**VPC**, escolha o identificador da sua VPC. 1. Quando estiver satisfeito com as configurações, clique em **Yes, Create**. 1. Defina uma regra de entrada de rede para seu security group. Essa regra permitirá que você se conecte à sua instância do Amazon EC2 usando Secure Shell (SSH). 1. No painel de navegação esquerdo, escolha **Security Groups**. 1. Localize seu security group na lista e escolha-o. 1. Em **Security Group**, escolha a guia **Inbound**. Na caixa **Create a new rule**, escolha **SSH** e depois **Add Rule**. Defina os seguintes valores para a sua nova regra de entrada a fim de permitir o acesso HTTP. + Type: HTTP + Origem: 0.0.0.0.0/0 1. Defina os seguintes valores para a sua nova regra de entrada a fim de permitir o acesso HTTP. + Type: HTTP + Origem: 0.0.0.0.0/0 Escolha **Apply Rule Changes**. Agora você está pronto para criar um [grupo de sub-redes](https://docs.aws.amazon.com/memorydb/latest/devguide/subnetgroups.html) e [criar um cluster](https://docs.aws.amazon.com/memorydb/latest/devguide/getting-started.createcluster.html) em sua VPC. # Sub-redes e grupos de sub-redes Um *grupo de sub-redes* é um conjunto de sub-redes (normalmente privadas) que você pode designar para seus clusters em execução em um ambiente Amazon Virtual Private Cloud (VPC). Ao criar um cluster em uma Amazon VPC, você pode especificar um grupo de sub-redes ou usar o padrão fornecido. O MemoryDB usa esse grupo de sub-redes para escolher uma sub-rede e endereços IP dentro dessa sub-rede para associar aos seus nós. Esta seção aborda como criar e aproveitar sub-redes e grupos de sub-redes para gerenciar o acesso aos recursos do MemoryDB. Para obter mais informações sobre o uso de grupos de sub-redes em um ambiente da Amazon VPC, consulte [Etapa 3: autorizar o acesso ao cluster](getting-started.md#getting-started.authorizeaccess). **IDs de AZs do MemoryDB compatíveis** | Nome da região/região | IDs de AZ compatíveis | | --- | --- | | Região Leste dos EUA (Ohio) `us-east-2` | `use2-az1, use2-az2, use2-az3` | | Região Leste dos EUA (Norte da Virgínia) `us-east-1` | `use1-az1, use1-az2, use1-az4, use1-az5, use1-az6` | | Região Oeste dos EUA (Norte da Califórnia) `us-west-1` | `usw1-az1, usw1-az2, usw1-az3` | | Região Oeste dos EUA (Oregon) `us-west-2` | `usw2-az1, usw2-az2, usw2-az3, usw2-az4` | | Região Canadá (Central) `ca-central-1` | `cac1-az1, cac1-az2, cac1-az4` | | Região Ásia-Pacífico (Hong Kong) `ap-east-1` | `ape1-az1, ape1-az2, ape1-az3` | | Região Ásia-Pacífico (Mumbai) `ap-south-1` | `aps1-az1, aps1-az2, aps1-az3` | | Região Ásia-Pacífico (Tóquio) `ap-northeast-1` | `apne1-az1, apne1-az2, apne1-az4` | | Região Ásia-Pacífico (Seul) `ap-northeast-2` | `apne2-az1, apne2-az2, apne2-az3` | | Região Ásia-Pacífico (Singapura) `ap-southeast-1` | `apse1-az1, apse1-az2, apse1-az3` | | Região Ásia-Pacífico (Sydney) `ap-southeast-2` | apse2-az1, apse2-az2, apse2-az3 | | Região Europa (Frankfurt) `eu-central-1` | `euc1-az1, euc1-az2, euc1-az3` | | Região Europa (Irlanda) `eu-west-1` | `euw1-az1, euw1-az2, euw1-az3` | | Região Europa (Londres) `eu-west-2` | `euw2-az1, euw2-az2, euw2-az3` | | Região Europa (Paris) `eu-west-3` | `euw3-az1, euw3-az2, euw3-az3` | | Região Europa (Estocolmo) `eu-north-1` | `eun1-az1, eun1-az2, eun1-az3 ` | | Região Europa (Milão) `eu-south-1` | `eus1-az1, eus1-az2, eus1-az3 ` | | Região América do Sul (São Paulo) `sa-east-1` | `sae1-az1, sae1-az2, sae1-az3` | | Região China (Pequim) `cn-north-1` | `cnn1-az1, cnn1-az2` | | Região China (Ningxia) `cn-northwest-1` | `cnw1-az1, cnw1-az2, cnw1-az3` | | `us-gov-east-1` | `usge1-az1, usge1-az2, usge1-az3` | | `us-gov-west-1` | `usgw1-az1, usgw1-az2, usgw1-az3` | | Região Europa (Espanha) `eu-south-2` | `eus2-az1, eus2-az2, eus2-az3` | **Topics** + [MemoryDB e IPV6](subnetgroups.ipv6.md) + [Criação de um grupo de sub-redes](subnetgroups.creating.md) + [Criação de um grupo de sub-redes](subnetgroups.modifying.md) + [Visualização de detalhes do grupo de sub-redes](subnetgroups.Viewing.md) + [Exclusão de um grupo de sub-redes](subnetgroups.deleting.md) # MemoryDB e IPV6 É possível criar clusters de pilha dupla e somente IPv6 com os mecanismos Valkey e Redis OSS, fornecendo grupos de sub-redes com pilha dupla e sub-redes somente IPv6. Não é possível alterar o tipo de rede de um cluster existente. Com essa funcionalidade, é possível: + Criar clusters somente IPv4 e de pilha dupla em sub-redes de pilha dupla. + Criar clusters somente IPv6 em sub-redes somente IPv6. + Criar grupos de sub-redes para oferecer suporte a sub-redes somente IPv4, de pilha dupla e somente IPv6. + Modificar os grupos de sub-redes existentes para incluir sub-redes adicionais da VPC subjacente. + Modificar sub-redes existentes em grupos de sub-redes + Adicionar sub-redes somente IPv6 aos grupos de sub-redes configurados para IPv6 + Adicionar sub-redes IPv4 ou de pilha dupla aos grupos de sub-redes configurados para suporte a IPv4 e pilha dupla + Descobrir todos os nós no cluster com endereços IPv4 OU IPv6, por meio de comandos de descoberta de mecanismos para clusters de pilha dupla e IPv6. Esses comandos de descoberta incluem `redis_info`, `redis_cluster` e similares. + Descobrir os endereços IPv4 e IPv6 de todos os nós no cluster, por meio dos comandos de descoberta de DNS para clusters de IPv6 e pilha dupla. # Criação de um grupo de sub-redes Quando você criar um novo grupo de sub-redes, observe o número de endereços IP disponíveis. Se a sub-rede tiver muito poucos endereços IP livres, talvez haja um limite no quanto ao número de nós adicionais que é possível acrescentar ao cluster. Para resolver esse problema, você pode atribuir uma ou mais sub-redes a um grupo de sub-redes para ter um número suficiente de endereços IP na zona de disponibilidade do seu cluster. Depois disso, você pode adicionar mais nós ao seu cluster. Os procedimentos a seguir mostram como criar um grupo de sub-redes chamado `mysubnetgroup` (console), a AWS CLI e a API do MemoryDB. ## Criação de um grupo de sub-redes (console) O procedimento a seguir mostra como criar um grupo de sub-redes (console). **Como criar um grupo de sub-redes (console)** 1. Faça login no Console de gerenciamento da AWS e abra o console do MemoryDB em [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/). 1. No painel de navegação esquerdo, escolha **Subnet Groups**. 1. Selecione **Criar grupo de sub-redes**. 1. Na página **Criar grupo de sub-redes**, faça o seguinte: 1. Na caixa **Nome**, digite um nome para o seu grupo de sub-redes. As restrições de nomenclatura de cluster são as seguintes: + Devem conter 1 a 40 caracteres alfanuméricos ou hifens. + Deve começar com uma letra. + Não podem conter dois hifens consecutivos. + Não podem terminar com um hífen. 1. Na caixa **Descrição**, digite uma descrição para seu grupo de sub-redes. 1. Na caixa **VPC ID** (ID da VPC\$1, escolha a Amazon VPC que você criou. Se você ainda não criou uma, escolha o botão **Criar VPC** e siga as etapas para criar uma. 1. Em **Sub-redes selecionadas**, escolha a Zona de Disponibilidade e o ID da sua sub-rede privada e, em seguida, selecione **Escolher**. 1. Para **Tags**, você pode opcionalmente aplicar tags para pesquisar e filtrar suas sub-redes ou rastrear seus custos da AWS. 1. Quando estiver satisfeito com as configurações, escolha **Criar**. 1. Na mensagem de confirmação exibida, escolha **Fechar**. Seu novo grupo de sub-rede aparece na lista **Grupos de sub-redes** do console do MemoryDB. Na parte inferior da janela, você pode escolher o grupo de sub-redes para ver detalhes, como todas as sub-redes associadas a esse grupo. ## Criação de um grupo de sub-redes (CLI da AWS) No prompt de comando, use o comando `create-subnet-group` para criar um grupo de sub-redes. Para Linux, macOS ou Unix: ``` aws memorydb create-subnet-group \ --subnet-group-name mysubnetgroup \ --description "Testing" \ --subnet-ids subnet-53df9c3a ``` Para Windows: ``` aws memorydb create-subnet-group ^ --subnet-group-name mysubnetgroup ^ --description "Testing" ^ --subnet-ids subnet-53df9c3a ``` Esse comando deve produzir um resultado semelhante ao seguinte: ``` { "SubnetGroup": { "Subnets": [ { "Identifier": "subnet-53df9c3a", "AvailabilityZone": { "Name": "us-east-1a" } } ], "VpcId": "vpc-3cfaef47", "Name": "mysubnetgroup", "ARN": "arn:aws:memorydb:us-east-1:012345678912:subnetgroup/mysubnetgroup", "Description": "Testing" } } ``` Para obter mais informações, consulte o AWS CLI tópico [create-subnet-group](https://docs.aws.amazon.com/cli/latest/reference/memorydb/create-subnet-group.html). ## Criação de um grupo de sub-redes (API do MemoryDB) Usando a API do MemoryDB, chame `CreateSubnetGroup` com os seguintes parâmetros: + `SubnetGroupName=``mysubnetgroup` + `Description=``Testing` + `SubnetIds.member.1=``subnet-53df9c3a` # Criação de um grupo de sub-redes Você pode atualizar a descrição de um grupo de sub-redes ou modificar a lista de IDs de sub-rede associados ao grupo de sub-redes. Você não poderá excluir um ID de sub-rede de um grupo de sub-redes se um cluster estiver usando essa sub-rede atualmente. Os procedimentos a seguir mostram como atualizar um grupo de sub-redes. ## Atualização de grupos de sub-redes (console) **Como atualizar um grupo de sub-redes** 1. Faça login no Console de gerenciamento da AWS e abra o console do MemoryDB em [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/). 1. No painel de navegação esquerdo, escolha **Subnet Groups**. 1. Na lista de grupos de sub-redes, escolha aquele que deseja modificar. 1. Os campos **Nome**, **VPCId** e **Descrição** não são modificáveis. 1. Na seção **sub-redes selecionadas**, clique em **Gerenciar** para fazer alterações nas zonas de disponibilidade necessárias para as sub-redes. Para salvar suas alterações, selecione **Salvar**. ## Atualizando grupos de sub-redes (CLI da AWS) No prompt de comando, use o comando `update-subnet-group` para modificar um grupo de sub-redes. Para Linux, macOS ou Unix: ``` aws memorydb update-subnet-group \ --subnet-group-name mysubnetgroup \ --description "New description" \ --subnet-ids "subnet-42df9c3a" "subnet-48fc21a9" ``` Para Windows: ``` aws memorydb update-subnet-group ^ --subnet-group-name mysubnetgroup ^ --description "New description" ^ --subnet-ids "subnet-42df9c3a" "subnet-48fc21a9" ``` Esse comando deve produzir um resultado semelhante ao seguinte: ``` { "SubnetGroup": { "VpcId": "vpc-73cd3c17", "Description": "New description", "Subnets": [ { "Identifier": "subnet-42dcf93a", "AvailabilityZone": { "Name": "us-east-1a" } }, { "Identifier": "subnet-48fc12a9", "AvailabilityZone": { "Name": "us-east-1a" } } ], "Name": "mysubnetgroup", "ARN": "arn:aws:memorydb:us-east-1:012345678912:subnetgroup/mysubnetgroup", } } ``` Para obter mais informações, consulte o tópico [update-subnet-group](https://docs.aws.amazon.com/cli/latest/reference/memorydb/update-subnet-group.html) da AWS CLI. ## Atualização de grupos de sub-redes (API do MemoryDB) Usando a API do MemoryDB, chame `UpdateSubnetGroup` com os seguintes parâmetros: + `SubnetGroupName=``mysubnetgroup` + Quaisquer outros parâmetros cujos valores você deseja alterar. Este exemplo usa `Description=``New%20description` para alterar a descrição do grupo de sub-redes. **Example** ``` https://memory-db.us-east-1.amazonaws.com/ ?Action=UpdateSubnetGroup &Description=New%20description &SubnetGroupName=mysubnetgroup &SubnetIds.member.1=subnet-42df9c3a &SubnetIds.member.2=subnet-48fc21a9 &SignatureMethod=HmacSHA256 &SignatureVersion=4 &Timestamp=20141201T220302Z &Version=2014-12-01 &X-Amz-Algorithm=Amazon4-HMAC-SHA256 &X-Amz-Credential= &X-Amz-Date=20141201T220302Z &X-Amz-Expires=20141201T220302Z &X-Amz-Signature= &X-Amz-SignedHeaders=Host ``` **nota** Quando você criar um novo grupo de sub-redes, anote o número de endereços IP disponíveis. Se a sub-rede tiver muito poucos endereços IP livres, talvez haja um limite no quanto ao número de nós adicionais que é possível acrescentar ao cluster. Para resolver esse problema, você pode atribuir uma ou mais sub-redes a um grupo de sub-redes para ter um número suficiente de endereços IP na zona de disponibilidade do seu cluster. Depois disso, você pode adicionar mais nós ao seu cluster. # Visualização de detalhes do grupo de sub-redes Os procedimentos a seguir mostram como visualizar detalhes de um grupo de sub-redes. ## Visualizando detalhes de grupos de sub-redes (console) **Visualizar detalhes de um grupo de sub-redes (console)** 1. Faça login no Console de gerenciamento da AWS e abra o console do MemoryDB em [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/). 1. No painel de navegação esquerdo, escolha **Subnet Groups**. 1. Na página **Grupos de sub-redes**, escolha o grupo de sub-redes em **Nome** ou digite o nome do grupo de sub-redes na barra de pesquisa. 1. Na página **Grupos de sub-redes**, escolha o grupo de sub-redes em **Nome** ou digite o nome do grupo de sub-redes na barra de pesquisa. 1. Em **Configurações do grupo de sub-redes**, você pode ver o nome, a descrição, o ID da VPC e o nome do recurso da Amazon (ARN) do grupo de sub-redes. 1. Em **Sub-redes**, você pode visualizar as zonas de disponibilidade, os IDs de sub-rede e os blocos CIDR do grupo de sub-redes 1. Em **Tags**, você pode ver todas as tags associadas ao grupo de sub-redes. ## Visualizando detalhes de grupos de sub-redes (CLI da AWS) No prompt de comando, use o comando `describe-subnet-groups` para visualizar os detalhes de um grupo de sub-redes especificado. Para Linux, macOS ou Unix: ``` aws memorydb describe-subnet-groups \ --subnet-group-name mysubnetgroup ``` Para Windows: ``` aws memorydb describe-subnet-groups ^ --subnet-group-name mysubnetgroup ``` Esse comando deve produzir um resultado semelhante ao seguinte: ``` {   "subnetgroups": [     {       "Subnets": [         {           "Identifier": "subnet-060cae3464095de6e",            "AvailabilityZone": {             "Name": "us-east-1a"           }         },          {           "Identifier": "subnet-049d11d4aa78700c3",            "AvailabilityZone": {             "Name": "us-east-1c"           }         },          {           "Identifier": "subnet-0389d4c4157c1edb4",            "AvailabilityZone": {             "Name": "us-east-1d"           }         }       ],        "VpcId": "vpc-036a8150d4300bcf2",        "Name": "mysubnetgroup",        "ARN": "arn:aws:memorydb:us-east-1:53791xzzz7620:subnetgroup/mysubnetgroup",        "Description": "test"     }   ] } ``` Para ver detalhes sobre todos os grupos de sub-redes, use o mesmo comando, mas sem especificar um nome de grupo de sub-redes. ``` aws memorydb describe-subnet-groups ``` Para obter mais informações, consulte o AWS CLI tópico [describe-subnet-groups](https://docs.aws.amazon.com/cli/latest/reference/memorydb/update-subnet-group.html). ## Visualizando grupos de sub-redes (API do MemoryDB) Usando a API do MemoryDB, chame `DescribeSubnetGroups` com os seguintes parâmetros: `SubnetGroupName=``mysubnetgroup` **Example** ``` https://memory-db.us-east-1.amazonaws.com/ ?Action=UpdateSubnetGroup &Description=New%20description &SubnetGroupName=mysubnetgroup &SubnetIds.member.1=subnet-42df9c3a &SubnetIds.member.2=subnet-48fc21a9 &SignatureMethod=HmacSHA256 &SignatureVersion=4 &Timestamp=20211801T220302Z &Version=2021-01-01 &X-Amz-Algorithm=Amazon4-HMAC-SHA256 &X-Amz-Credential= &X-Amz-Date=20210801T220302Z &X-Amz-Expires=20210801T220302Z &X-Amz-Signature= &X-Amz-SignedHeaders=Host ``` # Exclusão de um grupo de sub-redes Se você decidir que não precisa mais do seu grupo de sub-redes, poderá excluí-lo. Não será possível excluir um grupo de sub-redes se ele estiver sendo usado atualmente por um cluster. Também não é possível excluir um grupo de sub-redes em um cluster com Multi-AZ habilitado se isso deixar esse cluster com menos de duas sub-redes. É necessário primeiro desabilitar o **Multi-AZ** e excluir a sub-rede. Os procedimentos a seguir mostram como excluir um grupo de sub-redes. ## Exclusão de um grupo de sub-redes (console) **Para excluir um grupo de sub-redes** 1. Faça login no Console de gerenciamento da AWS e abra o console do MemoryDB em [https://console.aws.amazon.com/memorydb/](https://console.aws.amazon.com/memorydb/). 1. No painel de navegação esquerdo, escolha **Subnet Groups**. 1. Na lista de grupos de sub-rede, escolha o que você deseja excluir, selecione **Ações** e, em seguida, selecione **Excluir**. **nota** Não é possível excluir um grupo de sub-redes padrão ou que esteja associado a qualquer cluster. 1. A tela de confirmação **Excluir grupos de sub-redes** será exibida. 1. Para excluir o grupo de sub-redes, insira `delete` na caixa de texto de confirmação. Para manter o grupo de sub-redes, escolha **Cancelar**. ## Exclusão de um grupo de sub-redes (CLI da AWS) Usando o AWS CLI, chame o comando **delete-subnet-group** com o seguinte parâmetro: + `--subnet-group-name` *mysubnetgroup* Para Linux, macOS ou Unix: ``` aws memorydb delete-subnet-group \ --subnet-group-name mysubnetgroup ``` Para Windows: ``` aws memorydb delete-subnet-group ^ --subnet-group-name mysubnetgroup ``` Para obter mais informações, consulte o tópico [delete-subnet-group](https://docs.aws.amazon.com/cli/latest/reference/memorydb/delete-subnet-group.html) da AWS CLI. ## Exclusão de um grupo de sub-redes (API do MemoryDB) Usando a API do MemoryDB, chame `DeleteSubnetGroup` com o seguinte parâmetro: + `SubnetGroupName=mysubnetgroup` **Example** ``` https://memory-db.us-east-1.amazonaws.com/ ?Action=DeleteSubnetGroup &SubnetGroupName=mysubnetgroup &SignatureMethod=HmacSHA256 &SignatureVersion=4 &Timestamp=20210801T220302Z &Version=2021-01-01 &X-Amz-Algorithm=Amazon4-HMAC-SHA256 &X-Amz-Credential= &X-Amz-Date=20210801T220302Z &X-Amz-Expires=20210801T220302Z &X-Amz-Signature= &X-Amz-SignedHeaders=Host ``` Este comando não produz saída. Para obter mais informações, consulte o tópico [DeleteSubnetGroup](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DeleteSubnetGroup.html) da API do MemoryDB. # Endpoints de API e interface da VPC do MemoryDB (AWS PrivateLink) É possível estabelecer uma conexão privada entre os endpoints da VPC e de API do Amazon MemoryDB criando um *endpoint de interface da VPC*. Os endpoints de interface são alimentados por [AWS PrivateLink](https://aws.amazon.com/privatelink). AWS PrivateLink permite que você acesse de forma privada as operações da API MemoryDB sem um gateway de internet, dispositivo NAT, conexão VPN ou conexão Direct AWS Connect. As instâncias na VPC não precisam de endereços IP públicos para se comunicar com os endpoints de API do MemoryDB. As instâncias também não precisam de endereços IP públicos para usar qualquer uma das operações de API do MemoryDB disponíveis. O tráfego entre a VPC e o MemoryDB não deixa a rede da Amazon. Cada endpoint de interface é representado por uma ou mais interfaces de rede elástica nas sub-redes. Para obter mais informações sobre interfaces de rede elástica, consulte [Interfaces de rede elástica](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/using-eni.html) no *Guia do usuário do Amazon EC2.* + *Para obter mais informações sobre VPC endpoints, consulte Interface [VPC endpoints () no Guia do usuário AWS PrivateLink da](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html) Amazon VPC.* + Para obter mais informações sobre as operações da API do MemoryDB, consulte [Operações da API do MemoryDB](https://docs.aws.amazon.com/memorydb/latest/APIReference/Welcome.html). Depois de criar uma interface VPC endpoint, se você habilitar nomes de host [DNS privados](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html#vpce-private-dns) para o endpoint, o endpoint MemoryDB padrão (https://memorydb). *Region*.amazonaws.com) resolve para seu VPC endpoint. Se você não habilitar nomes de host DNS privados, o Amazon VPC fornecerá um nome de endpoint DNS que poderá ser usado no seguinte formato: ``` VPC_Endpoint_ID.memorydb.Region.vpce.amazonaws.com ``` Para obter mais informações, consulte [Endpoints da VPC da interface (AWS PrivateLink)](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html) no *Guia do usuário da Amazon VPC*. O MemoryDB oferece suporte a chamadas para todas as suas [ações de API](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_Operations.html) dentro de sua VPC. **nota** Os nomes de host DNS privados podem ser habilitados para apenas um endpoint da VPC na VPC. Se você quiser criar um endpoint da VPC adicional, o nome de host DNS privado deve ser desabilitado para ele. ## Considerações sobre endpoints da VPC do Antes de configurar um endpoint de interface da VPC para os endpoints de API do MemoryDB, verifique as [propriedades e limitações dos endpoints de interface](https://docs.aws.amazon.com/vpc/latest/privatelink/endpoint-services-overview.html) no *Guia do usuário do Amazon VPC*. Todas as operações de API do MemoryDB que são relevantes para gerenciar os recursos do MemoryDB estão disponíveis na VPC usando o AWS PrivateLink. As políticas de endpoint da VPC têm suporte para endpoints da API do MemoryDB. Por padrão, o acesso total às operações de API do MemoryDB é permitido através do endpoint. Para obter mais informações, consulte [Controlar o acesso a serviços com endpoints da VPC](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints-access.html) no *Guia do usuário da Amazon VPC*. ### Criação de uma interface de endpoint da VPC para a API do MemoryDB É possível criar um endpoint da VPC para a API do MemoryDB usando o console do Amazon VPC ou a AWS CLI. Para obter mais informações, consulte [Criar um endpoint de interface](https://docs.aws.amazon.com/vpc/latest/privatelink/create-endpoint-service.html) no *Guia do usuário da Amazon VPC*. Depois de criar um endpoint da interface da VPC, você poderá habilitar nomes de host DNS privados para o endpoint. Quando você fizer isso, o endpoint padrão do MemoryDB (https://memorydb. *Region*.amazonaws.com) resolve para seu VPC endpoint. Para mais informações, consulte [Acessar um serviço por um endpoint de interface](https://docs.aws.amazon.com/vpc/latest/userguide/vpce-interface.html#access-service-though-endpoint) no *Guia do usuário da Amazon VPC*. ### Criação de uma política de endpoint da VPC para a API do MemoryDB da Amazon É possível anexar uma política de endpoint ao seu endpoint da VPC que controla o acesso à API do MemoryDB. A política especifica o seguinte: + A entidade principal que pode realizar ações. + As ações que podem ser realizadas. + Os recursos aos quais as ações podem ser aplicadas. Para mais informações, consulte [Controlar o acesso a serviços com VPC endpoints](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-endpoints-access.html) no *Guia do usuário da Amazon VPC*. **Example Política de endpoint da VPC para ações da API do MemoryDB** Veja a seguir um exemplo de uma política de endpoint para a API do MemoryDB. Quando anexada a um endpoint, essa política concede acesso às ações indicadas da API do MemoryDB para todas as entidades principais em todos os recursos. ``` { "Statement": [{ "Principal": "*", "Effect": "Allow", "Action": [ "memorydb:CreateCluster", "memorydb:UpdateCluster", "memorydb:CreateSnapshot" ], "Resource": "*" }] } ``` **Example Política de VPC endpoint que nega todo o acesso de uma conta especificada AWS** A política de VPC endpoint a seguir nega à AWS conta *123456789012* todo o acesso aos recursos que usam o endpoint. A política permite todas as ações de outras contas. ``` { "Statement": [{ "Action": "*", "Effect": "Allow", "Resource": "*", "Principal": "*" }, { "Action": "*", "Effect": "Deny", "Resource": "*", "Principal": { "AWS": [ "123456789012" ] } } ] } ``` # Vulnerabilidades e exposições comuns (CVE): vulnerabilidades de segurança tratadas no MemoryDB A lista de Vulnerabilidades e exposições comuns (CVE) é uma lista de vulnerabilidades de segurança cibernética publicamente conhecidas. Cada entrada é um link que contém um número de identificação, uma descrição e pelo menos uma referência pública. Encontre nesta página uma lista de vulnerabilidades de segurança que foram tratadas no MemoryDB. Recomendamos que você sempre atualize para as versões mais recentes do MemoryDB para se proteger contra vulnerabilidades conhecidas. O MemoryDB expõe o componente PATCH. As versões do PATCH são para correções de bugs compatíveis com versões anteriores, correções de segurança e alterações não funcionais. Você pode usar a tabela a seguir para verificar se uma versão específica do MemoryDB inclui uma correção para uma vulnerabilidade de segurança específica. Se o cache do MemoryDB estiver pendente de atualização de serviço, ele poderá estar vulnerável a uma das vulnerabilidades de segurança listadas abaixo. Recomendamos aplicar a atualização do serviço. Consulte mais informações sobre as versões compatíveis do mecanismo do MemoryDB e sobre como atualizar em [Versões do mecanismo](engine-versions.md). **nota** Se uma CVE for solucionada em uma versão do MemoryDB, isso significa que ela também estará solucionada em versões mais recentes. Um asterisco (\$1) na tabela a seguir indica que você deve ter a atualização de serviço mais recente aplicada ao cluster do MemoryDB que executa a versão especificada para solucionar a vulnerabilidade de segurança. Consulte mais informações sobre como verificar se você tem a atualização de serviço mais recente aplicada à versão do MemoryDB na qual o cluster está sendo executado em [Gerenciamento das atualizações de serviços](managing-updates.md). | Versão do MemoryDB | CVEs Endereçado | | --- | --- | | Valkey 7.3 e todas as versões anteriores do Valkey Redis OSS 7.1 e todas as versões anteriores do Redis OSS | [CVE-2025-49844](https://www.cve.org/CVERecord?id=CVE-2025-49844)\$1, [CVE-2025-46817](https://www.cve.org/CVERecord?id=CVE-2025-46817)\$1, [CVE-2025-46818](https://www.cve.org/CVERecord?id=CVE-2025-46818)\$1, [CVE-2025-46819](https://www.cve.org/CVERecord?id=CVE-2025-46819)\$1 | | Valkey 7.2 e 7.3 | [CVE-2025-21607](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-21607)\$1, [CVE-2025-21605](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-21605)\$1, [CVE-2024-31449](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-31449)\$1, [CVE-2024-31227](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-31227)\$1, [CVE-2024-31228](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-31228)\$1 | | Vale 7.2.7 | [CVE-2024-51741](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-51741) | | Redis OSS 7.1 e 6.2 | [CVE-2025-21605](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-21605)\$1, [CVE-2024-31449](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-31449)\$1, [CVE-2024-31227](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-31227)\$1, [CVE-2024-31228](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-31228)\$1, [CVE-2023-41056](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-41056) | | Redis OSS 7.0.7 | [CVE-2023-41056](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-41056)\$1 | | Redis OSS 6.2.7 | [CVE-2024-46981](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-46981) | | Redis OSS 6.2.6 | [CVE-2022-24834](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-24834)\$1, [CVE-2022-35977](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-35977)\$1, [CVE-2022-36021](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-36021)\$1, [CVE-2023-22458](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-22458), [CVE-2023-25155](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-25155), [CVE-2023-28856](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-28856) [CVE-2023-45145](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-45145): observe que esse CVE foi abordado no Redis OSS 6.2 e 7.0, mas não no Redis OSS 7.1. | | Redis OSS 6.0.5 | [CVE-2022-24735](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-24735)\$1, [CVE-2022-24736](https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-24736)\$1 |