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á.
# Segurança do MemoryDB
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 a segurança da nuvem e a 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 que se aplicam ao MemoryDB, consulte [AWS Serviços no escopo do programa de conformidade AWS](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 dos dados, os requisitos da empresa e as leis e os regulamentos aplicáveis
Esta documentação ajuda a entender como aplicar o modelo de responsabilidade compartilhada ao usar o MemoryDB. Ela mostra como configurar o MemoryDB para atender aos objetivos de segurança e conformidade. Você também aprenderá a usar outros AWS serviços que ajudam a monitorar e proteger seus recursos do MemoryDB.
**Topics**
+ [Proteção de dados](data-protection.md)
+ [Gerenciamento de identidade e acesso](iam.md)
+ [Registro em log e monitoramento](monitoring-overview.md)
+ [Validação de compatibilidade](memorydb-compliance.md)
+ [Segurança da infraestrutura](infrastructure-security.md)
+ [
# Privacidade do tráfego entre redes
](Security.traffic.md)
+ [Atualizações de serviço](service-updates.md)
# Proteção de dados no MemoryDB
O modelo de [responsabilidade AWS compartilhada modelo](https://aws.amazon.com/compliance/shared-responsibility-model/) se aplica à proteção de dados em. 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 ou Serviços da AWS usa 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.
# Segurança de dados no MemoryDB
Para ajudar a manter seus dados seguros, o MemoryDB e o Amazon EC2 fornecem mecanismos de proteção contra o acesso não autorizado aos seus dados no servidor.
O MemoryDB também fornece atributos de criptografia para dados em clusters:
+ A criptografia em trânsito criptografa seus dados sempre que eles estão se movendo de um lugar para outro, como entre os nós no seu cluster ou entre seu cluster e o aplicativo.
+ A criptografia em repouso criptografa o log de transações e os dados no disco durante as operações de snapshot.
É possível usar também o [Autenticando usuários com listas de controle de acesso () ACLs](clusters.acls.md) para controlar o acesso do usuário aos seus clusters.
**Topics**
+ [
# Segurança de dados no MemoryDB
](encryption.md)
+ [
# Criptografia em repouso no MemoryDB
](at-rest-encryption.md)
+ [
# Criptografia em trânsito (TLS) do MemoryDB
](in-transit-encryption.md)
+ [
# Autenticando usuários com listas de controle de acesso () ACLs
](clusters.acls.md)
+ [
# Autenticação com o IAM
](auth-iam.md)
# Criptografia em repouso no MemoryDB
Para ajudar a manter seus dados seguros, o MemoryDB e o Amazon S3 oferecem diferentes maneiras de restringir o acesso aos dados nos clusters. Para obter mais informações, consulte [MemoryDB e Amazon VPC](vpcs.md) e [Gerenciamento de identidade e acesso no MemoryDB](iam.md).
A criptografia em repouso do MemoryDB está sempre ativada para aumentar a segurança dos dados por meio da criptografia de dados persistentes. Ele criptografa os seguintes aspectos:
+ Dados no log de transações
+ Disco durante operações de sincronização, snapshot e swap
+ Snapshots armazenados no Amazon S3
O MemoryDB oferece criptografia padrão (gerenciada pelo serviço) em repouso, bem como a capacidade de usar suas próprias chaves raiz simétricas gerenciadas pelo cliente no [Key Management Service (KMS) da AWS](https://docs.aws.amazon.com/kms/latest/developerguide/overview.html).
Os dados armazenados em Solid-State Drives (SSDs – Unidades de estado sólido) em clusters habilitados para classificação de dados em níveis sempre são criptografados por padrão.
Para obter informações sobre criptografia em trânsito, consulte [Criptografia em trânsito (TLS) do MemoryDB](in-transit-encryption.md)
**Topics**
+ [
## Uso de chaves gerenciadas pelo cliente do KMS da AWS
](#using-customer-managed-keys-for-memorydb-security)
+ [
## Consulte também
](#at-rest-encryption-see-also)
## Uso de chaves gerenciadas pelo cliente do KMS da AWS
O MemoryDB oferece suporte a chaves raiz simétricas gerenciadas pelo cliente (chave KMS) para criptografia em repouso. Chaves KMS gerenciadas pelo cliente são chaves de criptografia que você cria, detém e gerencia na sua conta da AWS. Para obter mais informações, consulte [Chaves raiz do cliente](https://docs.aws.amazon.com/kms/latest/developerguide/concepts.html#root_keys) no *Guia do desenvolvedor do serviço de gerenciamento de chaves da AWS.* As chaves devem ser criadas no KMS da AWS antes de poderem ser usadas com o MemoryDB.
Para saber como criar chaves de raiz do KMS da AWS, consulte [Criação de chaves](https://docs.aws.amazon.com/kms/latest/developerguide/create-keys.html) no *Guia do desenvolvedor do serviço de gerenciamento de chaves da AWS*.
O MemoryDB permite a integração com o AWS KMS. Para obter mais informações, consulte [Uso de concessões](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html) no *Guia do desenvolvedor do serviço de gerenciamento de chaves da AWS*. Não é necessária nenhuma ação do cliente para ativar a integração do MemoryDB com o KMS da AWS.
A chave de condição `kms:ViaService` limita o uso de uma chave do KMS AWS para solicitações provenientes de serviços da AWS especificados. Para usar `kms:ViaService` com o MemoryDB, inclua os dois nomes do ViaService no valor da chave de condição: `memorydb.amazon_region.amazonaws.com`. Para obter mais informações, consulte [kms:ViaService](https://docs.aws.amazon.com/kms/latest/developerguide/policy-conditions.html#conditions-kms-via-service).
Você pode usar o [AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-user-guide.html) para rastrear as solicitações que o MemoryDB envia para o AWS Key Management Service em seu nome. Todas as chamadas de API para o AWS Key Management Service relacionadas a chaves gerenciadas pelo cliente têm logs do CloudTrail correspondentes. Você também pode ver as concessões que o MemoryDB cria fazendo a chamada de API do KMS [ListGrants](https://docs.aws.amazon.com/kms/latest/APIReference/API_ListGrants.html).
Quando um cluster é criptografado usando uma chave gerenciada pelo cliente, todos os snapshots do cluster são criptografados da seguinte forma:
+ Os snapshots diários automáticos são criptografados usando a chave gerenciada pelo cliente associada ao cluster.
+ O snapshot final criado quando o cluster é excluído também é criptografado usando a chave gerenciada pelo cliente associada ao cluster.
+ Os snapshots criados manualmente são criptografados por padrão para usar a chave KMS associada ao cluster. Você pode substituir escolhendo outra chave gerenciada pelo cliente.
+ A cópia de um snapshot tem como padrão o uso da chave gerenciada pelo cliente associada ao snapshot de origem. Você pode substituir escolhendo outra chave gerenciada pelo cliente.
**nota**
As chaves gerenciadas pelo cliente não podem ser usadas ao exportar snapshots para o bucket do Amazon S3 selecionado. No entanto, todos os snapshots exportados para o Amazon S3 são criptografados usando a [criptografia do lado do servidor](https://docs.aws.amazon.com/AmazonS3/latest/dev/UsingServerSideEncryption.html). Você pode optar por copiar o arquivo de snapshot para um novo objeto S3 e criptografar usando uma chave KMS gerenciada pelo cliente, copiar o arquivo para outro bucket S3 configurado com criptografia padrão usando uma chave KMS ou alterar uma opção de criptografia no próprio arquivo.
Você também pode usar chaves gerenciadas pelo cliente para criptografar snapshots criados manualmente que não usam chaves gerenciadas pelo cliente para criptografia. Com essa opção, o arquivo de snapshot armazenado no Amazon S3 é criptografado usando uma chave KMS, mesmo que os dados não sejam criptografados no cluster original.
A restauração a partir de um snapshot permite que você escolha entre as opções de criptografia disponíveis, de forma semelhante às opções de criptografia disponíveis ao criar um novo cluster.
+ Se você excluir a chave ou [desativar](https://docs.aws.amazon.com/kms/latest/developerguide/enabling-keys.html) a chave e [revogar as concessões](https://docs.aws.amazon.com/kms/latest/APIReference/API_RevokeGrant.html) para a chave que usou para criptografar um cluster, o cluster se tornará irrecuperável. Em outras palavras, ele não poderá ser modificado nem recuperado depois de uma falha de hardware.AWS O KMS exclui as chaves raiz somente depois de um período de espera de pelo menos sete dias. Depois que a chave for excluída, você poderá usar uma chave gerenciada pelo cliente diferente para criar um snapshot para fins de arquivamento.
+ A rotação automática de chaves preserva as propriedades das chaves raiz do KMS da AWS, de modo que a rotação não afeta sua capacidade de acessar os dados do MemoryDB. Os clusters criptografados do MemoryDB não são compatíveis com a rotação manual de chaves, o que envolve a criação de uma nova chave raiz e a atualização de todas as referências à chave antiga. Para saber mais, consulte [Rotação das chaves raiz do cliente](https://docs.aws.amazon.com/kms/latest/developerguide/rotate-keys.html) no *Guia do desenvolvedor do Key Management Service daAWS*.
+ A criptografia de um cluster do MemoryDB usando a chave KMS requer uma concessão por cluster. Essa concessão é usada durante toda a vida útil do cluster. Além disso, uma concessão por snapshot é usada durante a criação do snapshot. Essa concessão é suspensa quando o snapshot é criado.
+ Para obter mais informações sobre concessões e limites do KMS da AWS, consulte [Cotas](https://docs.aws.amazon.com/kms/latest/developerguide/limits.html) no *Guia do desenvolvedor do Key Management Service da AWS*.
## Consulte também
+ [Criptografia em trânsito (TLS) do MemoryDB](in-transit-encryption.md)
+ [MemoryDB e Amazon VPC](vpcs.md)
+ [Gerenciamento de identidade e acesso no MemoryDB](iam.md)
# Criptografia em trânsito (TLS) do MemoryDB
Para ajudar a manter seus dados seguros, o MemoryDB e o Amazon EC2 fornecem mecanismos de proteção contra o acesso não autorizado aos seus dados no servidor. Ao fornecer a capacidade de criptografia em trânsito, o MemoryDB oferece uma ferramenta que pode ser usada para ajudar a proteger seus dados quando eles estiverem sendo transferidos de um local para outro. Por exemplo, você pode mover dados de um nó primário para um nó de réplica de leitura em um cluster ou entre o cluster e o aplicativo.
**Topics**
+ [
## Visão geral da criptografia em trânsito
](#in-transit-encryption-overview)
+ [
## Consulte também
](#in-transit-encryption-see-also)
## Visão geral da criptografia em trânsito
A criptografia em trânsito do MemoryDB é um recurso que aumenta a segurança dos dados nos pontos mais vulneráveis: quando estão em trânsito de um local para outro.
A criptografia em trânsito do MemoryDB implementa os seguintes atributos:
+ **Conexões criptografadas**: as conexões do servidor e do cliente são criptografadas por Transport Layer Security (TLS).
+ **Replicação criptografada**: os dados em movimento entre um nó primário e nós de réplica são criptografados.
+ **Autenticação do servidor**: os clientes podem autenticar que estão conectados ao servidor certo.
A partir de 20/07/2023, o TLS 1.2 é a versão mínima compatível para clusters novos e existentes. Use este [link](https://aws.amazon.com/blogs/security/tls-1-2-required-for-aws-endpoints/) para saber mais sobre o TLS 1.2 em AWS.
Para obter mais informações sobre como se conectar aos clusters do MemoryDB, consulte [Conectando-se aos nós do MemoryDB usando redis-cli](getting-started.md#connect-tls).
## Consulte também
+ [Criptografia em repouso no MemoryDB](at-rest-encryption.md)
+ [Autenticação de usuários com listas de controle de acesso (ACLs)](https://docs.aws.amazon.com/memorydb/latest/devguide/clusters.acls.html)
+ [MemoryDB e Amazon VPC](vpcs.md)
+ [Gerenciamento de identidade e acesso no MemoryDB](iam.md)
# Autenticando usuários com listas de controle de acesso () ACLs
Você pode autenticar usuários com listas de controle de acesso (ACLs).
ACLs permitem que você controle o acesso ao cluster agrupando usuários. Essas listas de controle de acesso são projetadas como uma maneira de organizar o acesso aos clusters.
Com ACLs, você cria usuários e atribui a eles permissões específicas usando uma string de acesso, conforme descrito na próxima seção. Você atribui os usuários a listas de controle de acesso alinhadas a uma função específica (administradores, recursos humanos) que, em seguida, são implantadas em um ou mais clusters do MemoryDB. Ao fazer isso, você pode estabelecer limites de segurança entre clientes usando o mesmo cluster ou clusters do MemoryDB e impedir que os clientes acessem os dados uns dos outros.
ACLs são projetados para oferecer suporte à introdução da [ACL](https://valkey.io/docs/topics/acl/) no Redis OSS 6. Quando você usa ACLs com seu cluster MemoryDB, há algumas limitações:
+ Não é possível especificar senhas em uma string de acesso. Você define senhas com [CreateUser](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_CreateUser.html)nossas [UpdateUser](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateUser.html)chamadas.
+ Para direitos de usuário, você passa `on` e `off` como parte da string de acesso. Se nenhum deles for especificado na string de acesso, o usuário é atribuído com `off` e não tem direitos de acesso ao cluster.
+ Você não pode usar comandos proibidos. Se você especificar um comando proibido, será emitida uma exceção. Para obter uma lista desses comandos, consulte [Comandos restritos](restrictedcommands.md).
+ Não é possível usar o comando `reset` como parte de uma string de acesso. Você especifica as senhas com parâmetros de API e o MemoryDB gerencia as senhas. Assim, você não pode usar `reset` porque ele removeria todas as senhas de um usuário.
+ O Redis OSS 6 apresenta o comando [ACL LIST](https://valkey.io/commands/acl-list). Esse comando retorna uma lista de usuários junto com as regras da ACL aplicadas a cada usuário. O MemoryDB oferece suporte ao comando `ACL LIST`, mas não inclui suporte para hashes de senha como o Redis OSS faz. Com o MemoryDB, você pode usar a [DescribeUsers](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeUsers.html)operação para obter informações semelhantes, incluindo as regras contidas na string de acesso. No entanto, [DescribeUsers](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeUsers.html)não recupera a senha do usuário.
Outros comandos somente de leitura compatíveis com o MemoryDB incluem [ACL WHOAMI](https://valkey.io/commands/acl-whoami), [ACL USERS](https://valkey.io/commands/acl-users) e [ACL CAT](https://valkey.io/commands/acl-cat). O MemoryDB não oferece suporte a nenhum outro comando ACL baseado em gravação.
O uso ACLs com o MemoryDB é descrito em mais detalhes a seguir.
**Topics**
+ [
## Especificação de permissões usando uma string de acesso
](#access-string)
+ [
## Recursos de pesquisa vetorial
](#access-vss)
+ [
## Aplicação ACLs a um cluster para MemoryDB
](#rbac-using)
## Especificação de permissões usando uma string de acesso
Para especificar permissões para um cluster MemoryDB, você cria uma string de acesso e a atribui a um usuário usando o AWS CLI ou. Console de gerenciamento da AWS
As cadeias de caracteres de acesso são definidas como uma lista de regras delimitadas por espaço que são aplicadas ao usuário. Eles definem quais comandos um usuário pode executar e em quais chaves um usuário pode operar. Para executar um comando, um usuário deve ter acesso ao comando que está sendo executado e todas as chaves que estão sendo acessadas pelo comando. As regras são aplicadas da esquerda para a direita cumulativamente, e uma string mais simples pode ser usada em vez da fornecida se houver redundâncias na string fornecida.
Para obter informações sobre a sintaxe das regras ACL, consulte [ACL](https://valkey.io/topics/acl).
No exemplo a seguir, a string de acesso representa um usuário ativo com acesso a todas as chaves e comandos disponíveis.
`on ~* &* +@all`
A sintaxe da cadeia de acesso é dividida da seguinte forma:
+ `on`: o usuário é um usuário ativo.
+ `~*`: o acesso é dado a todas as chaves disponíveis.
+ `&*`: o acesso é dado a todos os canais pubsub.
+ `+@all`: o acesso é dado a todos os comandos disponíveis.
As configurações anteriores são as menos restritivas. Você pode modificar essas configurações para torná-las mais seguras.
No exemplo a seguir, a string de acesso representa um usuário com acesso restrito ao acesso de leitura em chaves que começam com o keyspace "app::"
`on ~app::* -@all +@read`
Você pode refinar mais essas permissões listando comandos aos quais o usuário tem acesso:
`+command1`: o acesso do usuário aos comandos é limitado a *`command1`*.
`+@category`: o acesso do usuário é limitado a uma categoria de comandos.
Para obter informações sobre como atribuir uma string de acesso a um usuário, consulte [Criação de usuários e listas de controle de acesso com o console e a CLI](#users-management).
Se você estiver migrando uma workload existente para o MemoryDB, poderá recuperar a string de acesso chamando `ACL LIST`, excluindo o usuário e quaisquer hashes de senha.
## Recursos de pesquisa vetorial
Para a [Pesquisa vetorial](vector-search.md), todos os comandos de pesquisa pertencem à categoria `@search`, e as categorias `@read`, `@write`, `@fast` e `@slow` existentes são atualizadas para incluir comandos de pesquisa. Se um usuário não tiver acesso a uma categoria, ele não terá acesso aos comandos dentro dela. Por exemplo, se ele não tiver acesso a `@search`, não poderá executar comandos relacionados a pesquisas.
A tabela a seguir indica o mapeamento de comandos de pesquisa as categorias apropriadas.
| Comandos do VSS | @read | @write | @fast | @slow |
| --- | --- | --- | --- | --- |
| FT.CREATE | | S | S | |
| FT.DROPINDEX | | S | S | |
| FT.LIST | S | | | S |
| FT.INFO | S | | S | |
| FT.SEARCH | S | | | S |
| FT.AGGREGATE | S | | | S |
| FT.PROFILE | S | | | S |
| FT.ALIASADD | | S | S | |
| FT.ALIASDEL | | S | S | |
| FT.ALIASUPDATE | | S | S | |
| FT.\$1ALIASLIST | S | | | S |
| FT.EXPLAIN | S | | S | |
| FT.EXPLAINCLI | S | | S | |
| FT.CONFIG | S | | S | |
## Aplicação ACLs a um cluster para MemoryDB
Para usar o MemoryDB ACLs, siga as seguintes etapas:
1. Crie um ou mais usuários.
1. Crie uma ACL e adicione usuários à lista.
1. Atribua a ACL a um cluster.
Essas etapas estão descritas em detalhes a seguir.
**Topics**
+ [
### Criação de usuários e listas de controle de acesso com o console e a CLI
](#users-management)
+ [
### Gerenciamento de listas de controle de acesso com o console e a CLI
](#user-groups)
+ [
### Atribuição de listas de controle de acesso a clusters
](#users-groups-to-clusterss)
### Criação de usuários e listas de controle de acesso com o console e a CLI
As informações do usuário para ACLs usuários são um nome de usuário e, opcionalmente, uma senha e uma string de acesso. A string de acesso fornece o nível de permissão em chaves e comandos. O nome é exclusivo para o usuário e é passado para o mecanismo.
Verifique se as permissões do usuário fornecidas fazem sentido com a finalidade pretendida da ACL. Por exemplo, se você criar uma ACL chamada `Administrators`, qualquer usuário que você adicionar a esse grupo deve ter sua string de acesso definida para acesso total a chaves e comandos. Para usuários em uma ACL de `e-commerce`, você pode definir suas strings de acesso para somente leitura.
O MemoryDB configura automaticamente um usuário padrão por conta com um nome de usuário `"default"`. Ele não será associado a nenhum cluster, a menos que seja explicitamente adicionado a uma ACL. Você não pode excluir ou modificar esse usuário. Esse usuário destina-se à compatibilidade com o comportamento padrão das versões anteriores do Redis OSS e tem uma string de acesso que permite chamar todos os comandos e acessar todas as chaves.
Uma ACL imutável de “acesso aberto” será criada para cada conta que contém o usuário padrão. Essa é a única ACL da qual o usuário padrão pode se tornar membro. Ao criar um cluster, você deve selecionar uma ACL para associar ao cluster. Embora você tenha a opção de aplicar a ACL de “acesso aberto” com o usuário padrão, é altamente recomendável criar uma ACL com usuários que tenham permissões restritas às suas necessidades comerciais.
Os clusters que não têm o TLS ativado devem usar a ACL de “acesso aberto” para fornecer uma autenticação aberta.
ACLs pode ser criado sem usuários. Uma ACL vazia não teria acesso a um cluster e só pode ser associada a clusters habilitados para TLS.
Ao criar um usuário, você pode configurar até duas senhas. Quando você modifica uma senha, todas as conexões existentes para os clusters são mantidas.
Em particular, esteja ciente dessas restrições de senha de usuário ao usar ACLs o MemoryDB:
+ As senhas devem ter de 16 a 128 caracteres imprimíveis.
+ Os seguintes caracteres não alfanuméricos não são permitidos: `,` `""` `/` `@`.
#### Gerenciamento de usuários com o console e a CLI
##### Criação de usuários (console)
**Para criar usuários no 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 à esquerda, escolha **Usuários**.
1. Escolha **Criar usuário**
1. Na página **Criar usuário**, insira um **Nome**.
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. Em **Senhas**, você pode inserir até duas senhas.
1. Em **String de acesso**, insira uma cadeia de caracteres de acesso. A string de acesso define o nível de permissão para quais chaves e comandos o usuário é permitido.
1. Para **tags**, você pode, opcionalmente, aplicar tags para pesquisar e filtrar seus usuários ou monitorar seus AWS custos.
1. Escolha **Criar**.
##### Criando um usuário usando o AWS CLI
**Para criar um usuário usando a CLI**
+ Use o comando [create-user](https://docs.aws.amazon.com/cli/latest/reference/memorydb/create-user.html) para criar um usuário.
Para Linux, macOS ou Unix:
```
aws memorydb create-user \
--user-name user-name-1 \
--access-string "~objects:* ~items:* ~public:*" \
--authentication-mode \
Passwords="abc",Type=password
```
Para Windows:
```
aws memorydb create-user ^
--user-name user-name-1 ^
--access-string "~objects:* ~items:* ~public:*" ^
--authentication-mode \
Passwords="abc",Type=password
```
##### Modificação de um usuário (console)
**Para modificar usuários no 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 à esquerda, escolha **Usuários**.
1. Escolha o botão de opção ao lado do usuário que você deseja modificar e escolha **Ações**->**Modificar**
1. Se você quiser modificar uma senha, escolha o botão de opção **Modificar senhas**. Observe que, se você tiver duas senhas, deverá inserir as duas ao modificar uma delas.
1. Se você estiver atualizando a string de acesso, insira a nova.
1. Escolha **Modificar**.
##### Modificando um usuário usando AWS CLI
**Para modificar um usuário usando a CLI**
1. Use o comando [update-user](https://docs.aws.amazon.com/cli/latest/reference/memorydb/update-user.html) para modificar um usuário.
1. Quando um usuário é modificado, as listas de controle de acesso associadas ao usuário são atualizadas, juntamente com quaisquer clusters associados à ACL. Todas as conexões existentes são mantidas. Veja os exemplos a seguir.
Para Linux, macOS ou Unix:
```
aws memorydb update-user \
--user-name user-name-1 \
--access-string "~objects:* ~items:* ~public:*"
```
Para Windows:
```
aws memorydb update-user ^
--user-name user-name-1 ^
--access-string "~objects:* ~items:* ~public:*"
```
##### Visualizar detalhes do usuário (console)
**Para visualizar os detalhes do usuário no 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 à esquerda, escolha **Usuários**.
1. Escolha o usuário em **Nome de usuário** ou use a caixa de pesquisa para localizar o usuário.
1. Em **Configurações do usuário**, você pode revisar a string de acesso, a contagem de senhas, o status e o nome do recurso da Amazon (ARN) do usuário.
1. Em **Listas de controle de acesso (ACL)**, você pode revisar a ACL à qual o usuário pertence.
1. Em **Tags**, você pode revisar todas as tags associadas ao usuário.
##### Visualizando detalhes do usuário usando o AWS CLI
Use o comando [describe-users](https://docs.aws.amazon.com/cli/latest/reference/memorydb/describe-users.html) para ver os detalhes de um usuário.
```
aws memorydb describe-users \
--user-name my-user-name
```
##### Exclusão de um usuário (Console)
**Para excluir usuários no 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 à esquerda, escolha **Usuários**.
1. Escolha o botão de opção ao lado do usuário que você deseja modificar e escolha **Ações**->**Excluir**
1. Para confirmar, digite `delete` na caixa de texto de confirmação e, em seguida, selecione **Excluir**.
1. Para cancelar, escolha **Cancelar**.
##### Excluindo um usuário usando o AWS CLI
**Para excluir um usuário usando a CLI**
+ Use o comando [delete-user](https://docs.aws.amazon.com/cli/latest/reference/memorydb/delete-user.html) para excluir um usuário.
A conta é excluída e removida de todas as listas de controle de acesso às quais pertence. Veja um exemplo do a seguir:
Para Linux, macOS ou Unix:
```
aws memorydb delete-user \
--user-name user-name-2
```
Para Windows:
```
aws memorydb delete-user ^
--user-name user-name-2
```
### Gerenciamento de listas de controle de acesso com o console e a CLI
Você pode criar listas de controle de acesso para organizar e controlar o acesso de usuários a um ou mais clusters, conforme mostrado a seguir.
Use o procedimento a seguir para gerenciar as listas de controle de acesso usando o console.
#### Criação de uma lista de controle de acesso (ACL) (console)
**Como criar uma Lista de controle de acesso usando o 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 à esquerda, escolha **Listas de controle de acesso (ACL)**.
1. Escolha **Criar ACL**.
1. Na página **Criar lista de controle de acesso (ACL)**, insira o nome da ACL.
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. Em **Usuários selecionados**, siga um destes procedimentos:
1. Crie um novo usuário selecionando **Criar usuário**
1. Adicione usuários escolhendo **Gerenciar** e, em seguida, selecionando usuários na caixa de diálogo **Gerenciar usuários**, depois selecione **Escolher**.
1. Para **tags**, você pode, opcionalmente, aplicar tags para pesquisar e filtrar ACLs ou rastrear seus AWS custos.
1. Escolha **Criar**.
#### Criando uma Lista de Controle de Acesso (ACL) usando o AWS CLI
Use os procedimentos a seguir para criar uma lista de controle de acesso usando a CLI.
**Para criar uma nova ACL e adicionar um usuário usando a CLI**
+ Use o comando [create-acl](https://docs.aws.amazon.com/cli/latest/reference/memorydb/create-acl.html) para criar uma ACL.
Para Linux, macOS ou Unix:
```
aws memorydb create-acl \
--acl-name "new-acl-1" \
--user-names "user-name-1" "user-name-2"
```
Para Windows:
```
aws memorydb create-acl ^
--acl-name "new-acl-1" ^
--user-names "user-name-1" "user-name-2"
```
#### Modificação de uma lista de controle de acesso (ACL) (console)
**Para modificar uma lista de controle de acesso usando o 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 à esquerda, escolha **Listas de controle de acesso (ACL)**.
1. Escolha a ACL que você deseja modificar e escolha **Modificar**
1. Na página **Modificar**, em **Usuários selecionados**, faça o seguinte:
1. Crie um novo usuário escolhendo **Criar usuário** para adicionar à ACL.
1. Adicione ou remova usuários escolhendo **Gerenciar** e, em seguida, selecionando ou desmarcando usuários na caixa de diálogo **Gerenciar usuários** e depois, selecionando **Escolher**.
1. Na página **Criar lista de controle de acesso (ACL)**, insira o nome da ACL.
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. Em **Usuários selecionados**, siga um destes procedimentos:
1. Crie um novo usuário selecionando **Criar usuário**
1. Adicione usuários escolhendo **Gerenciar** e, em seguida, selecionando usuários na caixa de diálogo **Gerenciar usuários**, depois selecione **Escolher**.
1. Escolha **Modificar** para salvar suas alterações ou **Cancelar** para descartá-las.
#### Modificando uma Lista de Controle de Acesso (ACL) usando o AWS CLI
**Para modificar uma ACL adicionando novos usuários ou removendo membros atuais usando a CLI**
+ Use o comando [update-acl](https://docs.aws.amazon.com/cli/latest/reference/memorydb/update-acl.html) para modificar uma ACL.
Para Linux, macOS ou Unix:
```
aws memorydb update-acl --acl-name new-acl-1 \
--user-names-to-add user-name-3 \
--user-names-to-remove user-name-2
```
Para Windows:
```
aws memorydb update-acl --acl-name new-acl-1 ^
--user-names-to-add user-name-3 ^
--user-names-to-remove user-name-2
```
**nota**
Quaisquer conexões abertas pertencentes a um usuário removido de uma ACL são encerradas por este comando.
#### Visualização de detalhes da Lista de controle de acesso (ACL) (console)
**Para ver os detalhes da ACL no 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 à esquerda, escolha **Listas de controle de acesso (ACL)**.
1. Escolha a ACL sob **nome da ACL** ou use a caixa de pesquisa para localizar a ACL.
1. Em **Usuários**, você pode revisar a lista de usuários associados à ACL.
1. Em **Clusters associados**, você pode revisar o cluster ao qual a ACL pertence.
1. Em **Tags**, você pode revisar todas as tags associadas à ACL.
#### Exibindo listas de controle de acesso (ACL) usando o AWS CLI
Use o comando [describe-acls](https://docs.aws.amazon.com/cli/latest/reference/memorydb/describe-acls.html) para ver detalhes de uma ACL.
```
aws memorydb describe-acls \
--acl-name test-group
```
#### Excluindo uma Lista de controle de acesso (ACL) (console)
**Para excluir uma lista de controle de acesso usando o 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 à esquerda, escolha **Listas de controle de acesso (ACL)**.
1. Escolha a ACL que você deseja modificar e, em seguida, escolha **Excluir**
1. Na página **Excluir**, insira `delete` na caixa de confirmação e escolha **Excluir**; ou **Cancelar** para evitar a exclusão da ACL.
A própria ACL, não os usuários pertencentes ao grupo, é excluída.
#### Excluindo uma Lista de Controle de Acesso (ACL) usando o AWS CLI
**Para excluir uma ACL usando a CLI**
+ Use o comando [delete-acl](https://docs.aws.amazon.com/cli/latest/reference/memorydb/delete-acl.html) para excluir uma ACL.
Para Linux, macOS ou Unix:
```
aws memorydb delete-acl /
--acl-name
```
Para Windows:
```
aws memorydb delete-acl ^
--acl-name
```
Os exemplos anteriores retornam a seguinte resposta.
```
aws memorydb delete-acl --acl-name "new-acl-1"
{
"ACLName": "new-acl-1",
"Status": "deleting",
"EngineVersion": "6.2",
"UserNames": [
"user-name-1",
"user-name-3"
],
"clusters": [],
"ARN":"arn:aws:memorydb:us-east-1:493071037918:acl/new-acl-1"
}
```
### Atribuição de listas de controle de acesso a clusters
Depois de criar uma ACL e adicionar usuários, a etapa final da implementação ACLs é atribuir a ACL a um cluster.
#### Atribuindo listas de controle de acesso a clusters usando o console
Para adicionar uma ACL a um cluster usando o Console de gerenciamento da AWS, consulte[Criação de um cluster do MemoryDB](getting-started.md#clusters.create).
#### Atribuindo listas de controle de acesso a clusters usando o AWS CLI
A AWS CLI operação a seguir cria um cluster com a criptografia em trânsito (TLS) ativada e o **acl-name** parâmetro com o valor`my-acl-name`. Substitua o grupo de sub-redes `subnet-group` por um grupo de sub-redes que exista.
**Principais parâmetros**
+ **--engine-version**: deve ser 6.2.
+ **--tls-enabled**: usado para autenticação e para associar uma ACL.
+ **--acl-name**: esse valor fornece listas de controle de acesso compostas por usuários com permissões de acesso especificadas para o cluster.
Para Linux, macOS ou Unix:
```
aws memorydb create-cluster \
--cluster-name "new-cluster" \
--description "new-cluster" \
--engine-version "6.2" \
--node-type db.r6g.large \
--tls-enabled \
--acl-name "new-acl-1" \
--subnet-group-name "subnet-group"
```
Para Windows:
```
aws memorydb create-cluster ^
--cluster-name "new-cluster" ^
--cluster-description "new-cluster" ^
--engine-version "6.2" ^
--node-type db.r6g.large ^
--tls-enabled ^
--acl-name "new-acl-1" ^
--subnet-group-name "subnet-group"
```
A AWS CLI operação a seguir modifica um cluster com a criptografia em trânsito (TLS) ativada e o **acl-name** parâmetro com o valor. `new-acl-2`
Para Linux, macOS ou Unix:
```
aws memorydb update-cluster \
--cluster-name cluster-1 \
--acl-name "new-acl-2"
```
Para Windows:
```
aws memorydb update-cluster ^
--cluster-name cluster-1 ^
--acl-name "new-acl-2"
```
# Autenticação com o IAM
**Topics**
+ [
## Visão geral do
](#auth-iam-overview)
+ [
## Limitações
](#auth-iam-limits)
+ [
## Configuração
](#auth-iam-setup)
+ [
## Conexão
](#auth-iam-Connecting)
## Visão geral do
Com a autenticação do IAM, você pode autenticar uma conexão com o MemoryDB usando identidades AWS do IAM, quando seu cluster está configurado para usar Valkey ou Redis OSS versão 7 ou superior. Isso possibilita que você fortaleça seu modelo de segurança e simplifique várias tarefas administrativas de segurança. Com a autenticação do IAM, é possível configurar o controle de acesso refinado para cada cluster e usuário individual do MemoryDB e seguir os princípios de permissões de privilégio mínimo. A autenticação do IAM para MemoryDB fornece um token de autenticação do IAM de curta duração em vez de uma senha de usuário do MemoryDB de longa duração no comando `AUTH` ou `HELLO`. Para obter mais informações sobre o token de autenticação do IAM, consulte o [processo de assinatura do Signature versão 4](https://docs.aws.amazon.com//general/latest/gr/signature-version-4.html) no Guia de referência AWS geral e no exemplo de código abaixo.
Você pode usar as identidades do IAM e suas políticas associadas para restringir ainda mais o acesso ao Valkey ou Redis OSS. Você também pode conceder acesso aos usuários de seus provedores de identidade federados diretamente aos clusters do MemoryDB.
Para usar o AWS IAM com o MemoryDB, primeiro você precisa criar um usuário do MemoryDB com o modo de autenticação definido como IAM e, em seguida, criar ou reutilizar uma identidade do IAM. A identidade do IAM precisa de uma política associada para conceder a ação `memorydb:Connect` ao cluster do MemoryDB e ao usuário do MemoryDB. Depois de configurado, você pode criar um token de autenticação do IAM usando AWS as credenciais do usuário ou da função do IAM. Por fim, você precisa fornecer o token de autenticação do IAM de curta duração como uma senha no cliente do Valkey ou Redis OSS ao se conectar ao nó do cluster do MemoryDB. Um cliente com suporte para provedor de credenciais pode gerar automaticamente as credenciais temporárias para cada nova conexão. O MemoryDB executará a autenticação do IAM para solicitações de conexão de usuários do MemoryDB habilitados para o IAM e validará as solicitações de conexão com o IAM.
## Limitações
Ao usar a autenticação do IAM, as seguintes limitações se aplicam:
+ A autenticação do IAM está disponível ao usar o mecanismo Valkey ou Redis OSS versão 7.0 ou posterior.
+ O token de autenticação do IAM é válido por 15 minutos. Para conexões de longa duração, recomendamos usar um cliente do Redis OSS que ofereça suporte a uma interface de provedor de credenciais.
+ Uma conexão autenticada pelo IAM com o MemoryDB será automaticamente desconectada após 12 horas. A conexão pode ser prolongada por 12 horas enviando um comando `AUTH` ou `HELLO` com um novo token de autenticação do IAM.
+ A autenticação do IAM não tem suporte em comandos `MULTI EXEC`.
+ Atualmente, a autenticação do IAM não oferece suporte a todas as chaves de contexto de condição global. Para obter mais informações sobre chaves de contexto de condição global, consulte [Chaves de contexto de condição global da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html) no Guia do usuário do IAM.
## Configuração
Como configurar a autenticação do IAM
1. Criar um cluster
```
aws memorydb create-cluster \
--cluster-name cluster-01 \
--description "MemoryDB IAM auth application"
--node-type db.r6g.large \
--engine-version 7.0 \
--acl-name open-access
```
1. Crie um documento de política de confiança do IAM, conforme mostrado abaixo, para o perfil que permita que sua conta assuma o novo perfil. Salve a política em um arquivo chamado *trust-policy.json*.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": {
"Effect": "Allow",
"Principal": { "AWS": "arn:aws:iam::123456789012:root" },
"Action": "sts:AssumeRole"
}
}
```
------
1. Crie um documento de política do IAM, conforme mostrado abaixo. Salve a política em um arquivo chamado *policy.json*.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect" : "Allow",
"Action" : [
"memorydb:connect"
],
"Resource" : [
"arn:aws:memorydb:us-east-1:123456789012:cluster/cluster-01",
"arn:aws:memorydb:us-east-1:123456789012:user/iam-user-01"
]
}
]
}
```
------
1. Criar um perfil do IAM.
```
aws iam create-role \
--role-name "memorydb-iam-auth-app" \
--assume-role-policy-document file://trust-policy.json
```
1. Crie a política do IAM.
```
aws iam create-policy \
--policy-name "memorydb-allow-all" \
--policy-document file://policy.json
```
1. Anexe a política do IAM à função.
```
aws iam attach-role-policy \
--role-name "memorydb-iam-auth-app" \
--policy-arn "arn:aws:iam::123456789012:policy/memorydb-allow-all"
```
1. Crie um novo usuário habilitado para o IAM.
```
aws memorydb create-user \
--user-name iam-user-01 \
--authentication-mode Type=iam \
--access-string "on ~* +@all"
```
1. Crie uma ACL e inclua o usuário.
```
aws memorydb create-acl \
--acl-name iam-acl-01 \
--user-names iam-user-01
aws memorydb update-cluster \
--cluster-name cluster-01 \
--acl-name iam-acl-01
```
## Conexão
**Conectar com token como senha**
Primeiro, é necessário gerar o token de autenticação do IAM de curta duração usando uma [solicitação pré-assinada do AWS SigV4](https://docs.aws.amazon.com//general/latest/gr/sigv4-signed-request-examples.html). Depois disso, forneça o token de autenticação do IAM como senha ao se conectar a um cluster do MemoryDB, conforme mostrado no exemplo abaixo.
```
String userName = "insert user name"
String clusterName = "insert cluster name"
String region = "insert region"
// Create a default AWS Credentials provider.
// This will look for AWS credentials defined in environment variables or system properties.
AWSCredentialsProvider awsCredentialsProvider = new DefaultAWSCredentialsProviderChain();
// Create an IAM authentication token request and signed it using the AWS credentials.
// The pre-signed request URL is used as an IAM authentication token for MemoryDB.
IAMAuthTokenRequest iamAuthTokenRequest = new IAMAuthTokenRequest(userName, clusterName, region);
String iamAuthToken = iamAuthTokenRequest.toSignedRequestUri(awsCredentialsProvider.getCredentials());
// Construct URL with IAM Auth credentials provider
RedisURI redisURI = RedisURI.builder()
.withHost(host)
.withPort(port)
.withSsl(ssl)
.withAuthentication(userName, iamAuthToken)
.build();
// Create a new Lettuce client
RedisClusterClient client = RedisClusterClient.create(redisURI);
client.connect();
```
Veja abaixo a definição de `IAMAuthTokenRequest`.
```
public class IAMAuthTokenRequest {
private static final HttpMethodName REQUEST_METHOD = HttpMethodName.GET;
private static final String REQUEST_PROTOCOL = "http://";
private static final String PARAM_ACTION = "Action";
private static final String PARAM_USER = "User";
private static final String ACTION_NAME = "connect";
private static final String SERVICE_NAME = "memorydb";
private static final long TOKEN_EXPIRY_SECONDS = 900;
private final String userName;
private final String clusterName;
private final String region;
public IAMAuthTokenRequest(String userName, String clusterName, String region) {
this.userName = userName;
this.clusterName = clusterName;
this.region = region;
}
public String toSignedRequestUri(AWSCredentials credentials) throws URISyntaxException {
Request request = getSignableRequest();
sign(request, credentials);
return new URIBuilder(request.getEndpoint())
.addParameters(toNamedValuePair(request.getParameters()))
.build()
.toString()
.replace(REQUEST_PROTOCOL, "");
}
private Request getSignableRequest() {
Request request = new DefaultRequest<>(SERVICE_NAME);
request.setHttpMethod(REQUEST_METHOD);
request.setEndpoint(getRequestUri());
request.addParameters(PARAM_ACTION, Collections.singletonList(ACTION_NAME));
request.addParameters(PARAM_USER, Collections.singletonList(userName));
return request;
}
private URI getRequestUri() {
return URI.create(String.format("%s%s/", REQUEST_PROTOCOL, clusterName));
}
private void sign(SignableRequest request, AWSCredentials credentials) {
AWS4Signer signer = new AWS4Signer();
signer.setRegionName(region);
signer.setServiceName(SERVICE_NAME);
DateTime dateTime = DateTime.now();
dateTime = dateTime.plus(Duration.standardSeconds(TOKEN_EXPIRY_SECONDS));
signer.presignRequest(request, credentials, dateTime.toDate());
}
private static List toNamedValuePair(Map> in) {
return in.entrySet().stream()
.map(e -> new BasicNameValuePair(e.getKey(), e.getValue().get(0)))
.collect(Collectors.toList());
}
}
```
**Conectar com o provedor de credenciais**
O código abaixo mostra como se autenticar no MemoryDB usando o provedor de credenciais de autenticação do IAM.
```
String userName = "insert user name"
String clusterName = "insert cluster name"
String region = "insert region"
// Create a default AWS Credentials provider.
// This will look for AWS credentials defined in environment variables or system properties.
AWSCredentialsProvider awsCredentialsProvider = new DefaultAWSCredentialsProviderChain();
// Create an IAM authentication token request. Once this request is signed it can be used as an
// IAM authentication token for MemoryDB.
IAMAuthTokenRequest iamAuthTokenRequest = new IAMAuthTokenRequest(userName, clusterName, region);
// Create a credentials provider using IAM credentials.
RedisCredentialsProvider redisCredentialsProvider = new RedisIAMAuthCredentialsProvider(
userName, iamAuthTokenRequest, awsCredentialsProvider);
// Construct URL with IAM Auth credentials provider
RedisURI redisURI = RedisURI.builder()
.withHost(host)
.withPort(port)
.withSsl(ssl)
.withAuthentication(redisCredentialsProvider)
.build();
// Create a new Lettuce cluster client
RedisClusterClient client = RedisClusterClient.create(redisURI);
client.connect();
```
Abaixo está um exemplo de um cliente de cluster Lettuce que envolve um provedor de credenciais para gerar automaticamente credenciais temporárias quando necessário. IAMAuth TokenRequest
```
public class RedisIAMAuthCredentialsProvider implements RedisCredentialsProvider {
private static final long TOKEN_EXPIRY_SECONDS = 900;
private final AWSCredentialsProvider awsCredentialsProvider;
private final String userName;
private final IAMAuthTokenRequest iamAuthTokenRequest;
private final Supplier iamAuthTokenSupplier;
public RedisIAMAuthCredentialsProvider(String userName,
IAMAuthTokenRequest iamAuthTokenRequest,
AWSCredentialsProvider awsCredentialsProvider) {
this.userName = userName;
this.awsCredentialsProvider = awsCredentialsProvider;
this.iamAuthTokenRequest = iamAuthTokenRequest;
this.iamAuthTokenSupplier = Suppliers.memoizeWithExpiration(this::getIamAuthToken, TOKEN_EXPIRY_SECONDS, TimeUnit.SECONDS);
}
@Override
public Mono resolveCredentials() {
return Mono.just(RedisCredentials.just(userName, iamAuthTokenSupplier.get()));
}
private String getIamAuthToken() {
return iamAuthTokenRequest.toSignedRequestUri(awsCredentialsProvider.getCredentials());
}
```
# Gerenciamento de identidade e acesso no MemoryDB
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* (fazer login) e *autorizado* (tem permissões) a usar os recursos do MemoryDB. O IAM é um AWS service (Serviço da AWS) que você pode usar sem custo adicional.
**Topics**
+ [
## Público
](#security_iam_audience)
+ [
## Autenticação com identidades
](#security_iam_authentication)
+ [
## Gerenciar o acesso usando políticas
](#security_iam_access-manage)
+ [
# Como o MemoryDB funciona com o IAM
](security_iam_service-with-iam.md)
+ [
# Exemplos de políticas baseadas em identidade para o MemoryDB
](security_iam_id-based-policy-examples.md)
+ [
# Solucionar problemas de identidade e acesso do MemoryDB
](security_iam_troubleshoot.md)
+ [
## Controle de acesso
](#iam.accesscontrol)
+ [
# Visão geral do gerenciamento de permissões de acesso aos recursos do MemoryDB
](iam.overview.md)
## Público
A forma como você usa AWS Identity and Access Management (IAM) difere com base na sua função:
+ **Usuário do serviço**: solicite permissões ao seu administrador se você não conseguir acessar os atributos (consulte [Solucionar problemas de identidade e acesso do MemoryDB](security_iam_troubleshoot.md)).
+ **Administrador do serviço**: determine o acesso do usuário e envie solicitações de permissão (consulte [Como o MemoryDB funciona com o IAM](security_iam_service-with-iam.md))
+ **Administrador do IAM**: escreva políticas para gerenciar o acesso (consulte [Exemplos de políticas baseadas em identidade para o MemoryDB](security_iam_id-based-policy-examples.md))
## Autenticação com identidades
A autenticação é a forma como você faz login AWS usando suas credenciais de identidade. Você deve estar autenticado como usuário do IAM ou assumindo uma função do IAM. Usuário raiz da conta da AWS
Você pode fazer login como uma identidade federada usando credenciais de uma fonte de identidade como Centro de Identidade do AWS IAM (IAM Identity Center), autenticação de login único ou credenciais. Google/Facebook Para ter mais informações sobre como fazer login, consulte [Como fazer login em sua Conta da AWS](https://docs.aws.amazon.com/signin/latest/userguide/how-to-sign-in.html) no *Guia do usuário do Início de Sessão da AWS *.
Para acesso programático, AWS fornece um SDK e uma CLI para assinar solicitações criptograficamente. Para ter mais informações, consulte [AWS Signature Version 4 para solicitações de API](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_sigv.html) no *Guia do usuário do IAM*.
### Conta da AWS usuário root
Ao criar um Conta da AWS, você começa com uma identidade de login chamada *usuário Conta da AWS raiz* que tem acesso completo a todos Serviços da AWS os recursos. É altamente recomendável não usar o usuário-raiz em tarefas diárias. Consulte as tarefas que exigem credenciais de usuário-raiz em [Tarefas que exigem credenciais de usuário-raiz](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_root-user.html#root-user-tasks) no *Guia do usuário do IAM*.
### Identidade federada
Como prática recomendada, exija que os usuários humanos usem a federação com um provedor de identidade para acessar Serviços da AWS usando credenciais temporárias.
Uma *identidade federada* é um usuário do seu diretório corporativo, provedor de identidade da web ou Directory Service que acessa Serviços da AWS usando credenciais de uma fonte de identidade. As identidades federadas assumem funções que oferecem credenciais temporárias.
Para o gerenciamento de acesso centralizado, recomendamos Centro de Identidade do AWS IAM. Para saber mais, consulte [O que é o IAM Identity Center?](https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html) no *Guia do usuário do Centro de Identidade do AWS IAM *.
### Usuários e grupos do IAM
Um *[usuário do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users.html)* é uma identidade com permissões específicas para uma única pessoa ou aplicação. É recomendável usar credenciais temporárias, em vez de usuários do IAM com credenciais de longo prazo. Para obter mais informações, consulte [Exigir que usuários humanos usem a federação com um provedor de identidade para acessar AWS usando credenciais temporárias](https://docs.aws.amazon.com/IAM/latest/UserGuide/best-practices.html#bp-users-federation-idp) no *Guia do usuário do IAM*.
Um [https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_groups.html) especifica um conjunto de usuários do IAM e facilita o gerenciamento de permissões para grandes conjuntos de usuários. Para ter mais informações, consulte [Casos de uso de usuários do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/gs-identities-iam-users.html) no *Guia do usuário do IAM*.
### Perfis do IAM
Uma *[perfil do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html)* é uma identidade com permissões específicas que oferece credenciais temporárias. Você pode assumir uma função [mudando de um usuário para uma função do IAM (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_use_switch-role-console.html) ou chamando uma operação de AWS API AWS CLI ou. Para saber mais, consulte [Métodos para assumir um perfil](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_manage-assume.html) no *Manual do usuário do IAM*.
Os perfis do IAM são úteis para acesso de usuário federado, permissões de usuário do IAM temporárias, acesso entre contas, acesso entre serviços e aplicações em execução no Amazon EC2. Consulte mais informações em [Acesso a recursos entre contas no IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) no *Guia do usuário do IAM*.
## Gerenciar o acesso usando políticas
Você controla o acesso AWS criando políticas e anexando-as a AWS identidades ou recursos. Uma política define permissões quando associada a uma identidade ou recurso. AWS avalia essas políticas quando um diretor faz uma solicitação. A maioria das políticas é armazenada AWS como documentos JSON. Para ter mais informações sobre documentos de política JSON, consulte [Visão geral das políticas JSON](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#access_policies-json) no *Guia do usuário do IAM*.
Por meio de políticas, os administradores especificam quem tem acesso a que, definindo qual **entidade principal** pode realizar **ações** em quais **recursos** e sob quais **condições**.
Por padrão, usuários e perfis não têm permissões. Um administrador do IAM cria políticas do IAM e as adiciona aos perfis, os quais os usuários podem então assumir. As políticas do IAM definem permissões, independentemente do método usado para realizar a operação.
### Políticas baseadas em identidade
As políticas baseadas em identidade são documentos de políticas de permissão JSON que você anexa a uma identidade (usuário, grupo ou perfil). Essas políticas controlam quais ações as identidades podem realizar, em quais recursos e sob quais condições. Para saber como criar uma política baseada em identidade, consulte [Definir permissões personalizadas do IAM com as políticas gerenciadas pelo cliente](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) no *Guia do Usuário do IAM*.
As políticas baseadas em identidade podem ser políticas *em linha* (incorporadas diretamente em uma única identidade) ou *políticas gerenciadas* (políticas autônomas anexadas a várias identidades). Para saber como escolher entre uma política gerenciada e políticas em linha, consulte [Escolher entre políticas gerenciadas e políticas em linha](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-choosing-managed-or-inline.html) no *Guia do usuário do IAM*.
### Políticas baseadas em recursos
Políticas baseadas em recursos são documentos de políticas JSON que você anexa a um recurso. Entre os exemplos estão *políticas de confiança de perfil* do IAM e *políticas de bucket* do Amazon S3. Em serviços compatíveis com políticas baseadas em recursos, os administradores de serviço podem usá-las para controlar o acesso a um recurso específico. É necessário [especificar uma entidade principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) em uma política baseada em recursos.
Políticas baseadas em recursos são políticas em linha localizadas nesse serviço. Você não pode usar políticas AWS gerenciadas do IAM em uma política baseada em recursos.
### Outros tipos de política
AWS oferece suporte a tipos de políticas adicionais que podem definir o máximo de permissões concedidas por tipos de políticas mais comuns:
+ **Limites de permissões**: definem o número máximo de permissões que uma política baseada em identidade pode conceder a uma entidade do IAM. Para saber mais sobre limites de permissões, consulte [Limites de permissões para identidades do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html) no *Guia do usuário do IAM*.
+ **Políticas de controle de serviço (SCPs)** — Especifique as permissões máximas para uma organização ou unidade organizacional em AWS Organizations. Para saber mais, consulte [Políticas de controle de serviço](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_scps.html) no *Guia do usuário do AWS Organizations *.
+ **Políticas de controle de recursos (RCPs)** — Defina o máximo de permissões disponíveis para recursos em suas contas. Para obter mais informações, consulte [Políticas de controle de recursos (RCPs)](https://docs.aws.amazon.com/organizations/latest/userguide/orgs_manage_policies_rcps.html) no *Guia AWS Organizations do usuário*.
+ **Políticas de sessão**: políticas avançadas transmitidas como um parâmetro durante a criação de uma sessão temporária para um perfil ou um usuário federado. Para saber mais, consulte [Políticas de sessão](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html#policies_session) no *Guia do usuário do IAM*.
### Vários tipos de política
Quando vários tipos de política são aplicáveis a uma solicitação, é mais complicado compreender as permissões resultantes. Para saber como AWS determinar se uma solicitação deve ser permitida quando vários tipos de políticas estão envolvidos, consulte [Lógica de avaliação de políticas](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_evaluation-logic.html) no *Guia do usuário do IAM*.
# Como o MemoryDB funciona com o IAM
Antes de usar o IAM para gerenciar o acesso ao MemoryDB, saiba quais atributos do IAM estão disponíveis para uso com o MemoryDB.
**Recursos do IAM que você pode usar com o MemoryDB**
| Recurso do IAM | Suporte do MemoryDB |
| --- | --- |
| [Políticas baseadas em identidade](#security_iam_service-with-iam-id-based-policies) | Sim |
| [Políticas baseadas em recurso](#security_iam_service-with-iam-resource-based-policies) | Não |
| [Ações de políticas](#security_iam_service-with-iam-id-based-policies-actions) | Sim |
| [Recursos de políticas](#security_iam_service-with-iam-id-based-policies-resources) | Sim |
| [Chaves de condição de políticas](#security_iam_service-with-iam-id-based-policies-conditionkeys) | Sim |
| [ACLs](#security_iam_service-with-iam-acls) | Sim |
| [ABAC (tags em políticas)](#security_iam_service-with-iam-tags) | Sim |
| [Credenciais temporárias](#security_iam_service-with-iam-roles-tempcreds) | Sim |
| [Permissões de entidade principal](#security_iam_service-with-iam-principal-permissions) | Sim |
| [Perfis de serviço](#security_iam_service-with-iam-roles-service) | Sim |
| [Perfis vinculados a serviço](#security_iam_service-with-iam-roles-service-linked) | Sim |
Para ter uma visão de alto nível de como o MemoryDB e outros AWS serviços funcionam com a maioria dos recursos do IAM, consulte [AWS os 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*.
## Políticas do MemoryDB baseadas em identidade
**Compatível com políticas baseadas em identidade:** sim
As políticas baseadas em identidade são documentos de políticas de permissões JSON que podem ser anexados a uma identidade, como usuário do IAM, grupo de usuários ou perfil. Essas políticas controlam quais ações os usuários e perfis podem realizar, em quais recursos e em que condições. Para saber como criar uma política baseada em identidade, consulte [Definir permissões personalizadas do IAM com as políticas gerenciadas pelo cliente](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create.html) no *Guia do Usuário do IAM*.
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. Para saber mais sobre todos os elementos que podem ser usados em uma política JSON, consulte [Referência de elemento 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*.
### Exemplos de políticas baseadas em identidade para o MemoryDB
Para visualizar exemplos de políticas baseadas em identidade do MemoryDB, consulte [Exemplos de políticas baseadas em identidade para o MemoryDB](security_iam_id-based-policy-examples.md).
## Políticas baseadas em recursos no MemoryDB
**Compatibilidade com políticas baseadas em recursos:** não
Políticas baseadas em recursos são documentos de políticas JSON que você anexa a um recurso. São exemplos de políticas baseadas em recursos as *políticas de confiança de perfil* do IAM e as *políticas de bucket* do Amazon S3. Em serviços compatíveis com políticas baseadas em recursos, os administradores de serviço podem usá-las para controlar o acesso a um recurso específico. Para o atributo ao qual a política está anexada, a política define quais ações uma entidade principal especificado pode executar nesse atributo e em que condições. É necessário [especificar uma entidade principal](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_principal.html) em uma política baseada em recursos. Os diretores podem incluir contas, usuários, funções, usuários federados ou. Serviços da AWS
Para permitir o acesso entre contas, é possível especificar uma conta inteira ou as entidades do IAM em outra conta como a entidade principal em uma política baseada em recursos. Consulte mais informações em [Acesso a recursos entre contas no IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) no *Guia do usuário do IAM*.
## Ações de políticas do MemoryDB
**Compatível com ações de políticas:** sim
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.
Para ver uma lista das ações do MemoryDB, consulte [Actions Defined by MemoryDB](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awskeymanagementservice.html#awskeymanagementservice-actions-as-permissions) na *Referência de autorização do serviço*.
As ações de políticas no MemoryDB usam o seguinte prefixo antes da ação:
```
MemoryDB
```
Para especificar várias ações em uma única instrução, separe-as com vírgulas.
```
"Action": [
"MemoryDB:action1",
"MemoryDB: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": "MemoryDB:Describe*"
```
Para visualizar exemplos de políticas baseadas em identidade do MemoryDB, consulte [Exemplos de políticas baseadas em identidade para o MemoryDB](security_iam_id-based-policy-examples.md).
## Recursos de políticas do MemoryDB
**Compatível com recursos de políticas:** sim
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": "*"
```
*Para ver uma lista dos tipos de recursos do MemoryDB e seus ARNs, consulte [Recursos definidos pelo MemoryDB](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awskeymanagementservice.html#awskeymanagementservice-resources-for-iam-policies) na Referência de autorização de serviço.* Para saber com quais ações você pode especificar o ARN de cada recurso, consulte [Actions Defined by MemoryDB](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awskeymanagementservice.html#awskeymanagementservice-actions-as-permissions).
Para visualizar exemplos de políticas baseadas em identidade do MemoryDB, consulte [Exemplos de políticas baseadas em identidade para o MemoryDB](security_iam_id-based-policy-examples.md).
## Chaves de condição de políticas para o MemoryDB
**Compatível com chaves de condição de política específicas de serviço:** sim
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*.
Para visualizar exemplos de políticas baseadas em identidade do MemoryDB, consulte [Exemplos de políticas baseadas em identidade para o MemoryDB](security_iam_id-based-policy-examples.md).
### Uso de chaves de condição
Você pode especificar as condições que determinam como uma política do IAM entra em vigor. No MemoryDB, é possível usar o elemento `Condition` de uma política JSON para comparar chaves no contexto da solicitação com os valores de chave especificados na política. Para obter mais informações, consulte [Elementos da política JSON do IAM: condição](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition.html).
Para ver uma lista de chaves de condição do MemoryDB, consulte [Condition Keys for MemoryDB](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awskeymanagementservice.html#awskeymanagementservice-policy-keys) na *Referência de autorização do serviço*.
Para obter uma lista de todas as chaves de condição globais, consulte [Chaves de contexto de condição global da AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_condition-keys.html).
#### Especificação de condições: uso de chaves de condição
Para implementar um controle refinado, você pode gravar uma política de permissões do IAM que especifique condições para controlar um conjunto de parâmetros individuais em determinadas solicitações. Depois, você pode aplicar a política aos usuários, grupos ou perfis do IAM que você criar usando o console do IAM.
Para aplicar uma condição, adicione as informações da condição à declaração de política do IAM. Por exemplo, para proibir a criação de qualquer cluster do MemoryDB com o TLS desabilitado, você pode especificar a seguinte condição na declaração de política.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"memorydb:CreateCluster"
],
"Resource": [
"*"
],
"Condition": {
"Bool": {
"memorydb:TLSEnabled": "false"
}
}
}
]
}
```
------
Para ter mais informações sobre marcação, consulte [Marcação dos seus recursos do MemoryDB](tagging-resources.md).
Para obter mais informações sobre a utilização de operadores de condição de política, consulte [Permissões da API do MemoryDB: referência de condições, recursos e ações](iam.APIReference.md).
#### Políticas de exemplo: uso de condições para controle de acesso refinado
Esta seção mostra políticas de exemplo para a implementação de um controle de acesso refinado nos parâmetros do MemoryDB listados anteriormente.
1. **memorydb: TLSEnabled** — Especifique que os clusters serão criados somente com o TLS ativado.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"memorydb:CreateCluster"
],
"Resource": [
"arn:aws:memorydb:*:*:parametergroup/*",
"arn:aws:memorydb:*:*:subnetgroup/*",
"arn:aws:memorydb:*:*:acl/*"
]
},
{
"Effect": "Allow",
"Action": [
"memorydb:CreateCluster"
],
"Resource": [
"*"
],
"Condition": {
"Bool": {
"memorydb:TLSEnabled": "true"
}
}
}
]
}
```
------
1. **memorydb:UserAuthenticationMode:** — Especifique que os usuários possam ser criados com um modo de autenticação de tipo específico (IAM, por exemplo).
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"memorydb:Createuser"
],
"Resource": [
"arn:aws:memorydb:*:*:user/*"
],
"Condition": {
"StringEquals": {
"memorydb:UserAuthenticationMode": "iam"
}
}
}
]
}
```
------
Nos casos em que você está definindo políticas baseadas em 'Negar', é recomendável usar a [StringEqualsIgnoreCase](https://docs.aws.amazon.com//IAM/latest/UserGuide/reference_policies_elements_condition_operators.html#Conditions_String)operadora para evitar todas as chamadas com um tipo específico de modo de autenticação de usuário, independentemente do caso.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Deny",
"Action": [
"memorydb:CreateUser"
],
"Resource": "*",
"Condition": {
"StringEqualsIgnoreCase": {
"memorydb:UserAuthenticationMode": "password"
}
}
}
]
}
```
------
## Listas de controle de acesso (ACLs) no MemoryDB
**Suportes ACLs:** Sim
As listas de controle de acesso (ACLs) controlam quais diretores (membros da conta, usuários ou funções) têm permissões para acessar um recurso. ACLs são semelhantes às políticas baseadas em recursos, embora não usem o formato de documento de política JSON.
## Controle de acesso por atributo (ABAC) com o MemoryDB
**Compatível com ABAC (tags em políticas):** sim
O controle de acesso por atributo (ABAC) é uma estratégia de autorização que define permissões com base em atributos chamados de tags. Você pode anexar tags a entidades e AWS recursos do IAM e, em seguida, criar políticas ABAC para permitir operações quando a tag do diretor corresponder à tag no recurso.
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 `aws:ResourceTag/key-name`, `aws:RequestTag/key-name` ou chaves de condição `aws:TagKeys`.
Se um serviço for compatível com as três chaves de condição para cada tipo de recurso, o valor será **Sim** para o serviço. Se um serviço for compatível com as três chaves de condição somente para alguns tipos de recursos, o valor será **Parcial**
Para saber mais sobre o ABAC, consulte [Definir permissões com autorização do ABAC](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction_attribute-based-access-control.html) no *Guia do usuário do IAM*. Para visualizar um tutorial com etapas para configurar o ABAC, consulte [Usar controle de acesso por atributo (ABAC)](https://docs.aws.amazon.com/IAM/latest/UserGuide/tutorial_attribute-based-access-control.html) no *Guia do usuário do IAM*.
## Usar credenciais temporárias com o MemoryDB
**Compatível com credenciais temporárias:** sim
As credenciais temporárias fornecem acesso de curto prazo aos AWS recursos e são criadas automaticamente quando você usa a federação ou troca de funções. AWS recomenda que você gere credenciais temporárias dinamicamente em vez de usar chaves de acesso de longo prazo. Para ter mais informações, consulte [Credenciais de segurança temporárias no IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp.html) e [Serviços da Serviços da AWS que funcionam com o IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html) no *Guia do usuário do IAM*.
## Permissões de entidade principal entre serviços para o MemoryDB
**Compatibilidade com o recurso de encaminhamento de sessões de acesso (FAS):** sim
As sessões de acesso direto (FAS) usam as permissões do principal chamando um AWS service (Serviço da AWS), combinadas com a solicitação AWS service (Serviço da AWS) de fazer solicitações aos serviços posteriores. Para obter detalhes da política ao fazer solicitações de FAS, consulte [Sessões de acesso direto](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_forward_access_sessions.html).
## Perfis de serviço para o MemoryDB
**Compatível com perfis de serviço:** sim
O perfil de serviço é um [perfil do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles.html) que um serviço assume para executar ações em seu nome. Um administrador do IAM pode criar, modificar e excluir um perfil de serviço do IAM. Para saber mais, consulte [Criar um perfil para delegar permissões a um AWS service (Serviço da AWS)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-service.html) no *Guia do Usuário do IAM*.
**Atenção**
Alterar as permissões de um perfil de serviço pode prejudicar a funcionalidade do MemoryDB. Edite os perfis de serviço somente quando o MemoryDB orientar você a fazê-lo.
## Perfis vinculados ao serviço para o MemoryDB
**Compatibilidade com perfis vinculados a serviços:** sim
Uma função vinculada ao serviço é um tipo de função de serviço vinculada a um. AWS service (Serviço da AWS) O serviço pode assumir o perfil de executar uma ação em seu nome. As funções vinculadas ao serviço aparecem em você Conta da AWS e são de propriedade do serviço. Um administrador do IAM pode visualizar, mas não editar as permissões para perfis vinculados ao serviço.
Para obter detalhes sobre como criar ou gerenciar perfis vinculados a serviços, consulte [Serviços da AWS que funcionam com o IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html). Encontre um serviço na tabela que inclua um `Yes` na coluna **Perfil vinculado ao serviço**. Escolha o link **Sim** para visualizar a documentação do perfil vinculado a serviço desse serviço.
# Exemplos de políticas baseadas em identidade para o MemoryDB
Por padrão, usuários e funções não têm permissão para criar ou modificar recursos do MemoryDB. Para conceder permissão aos usuários para executar ações nos recursos que eles precisam, um administrador do IAM pode criar políticas do IAM.
Para aprender a criar uma política baseada em identidade do IAM ao usar esses documentos de política em JSON de exemplo, consulte [Criar políticas do IAM (console)](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html) no *Guia do usuário do IAM*.
*Para obter detalhes sobre ações e tipos de recursos definidos pelo MemoryDB, incluindo o formato do ARNs para cada um dos tipos de recursos, consulte [Ações, recursos e chaves de condição do MemoryDB](https://docs.aws.amazon.com/IAM/latest/UserGuide/list_awskeymanagementservice.html) na Referência de autorização de serviço.*
**Topics**
+ [
## Práticas recomendadas de política
](#security_iam_service-with-iam-policy-best-practices)
+ [
## Como usar o console do MemoryDB
](#security_iam_id-based-policy-examples-console)
+ [
## Permitir que os usuários visualizem suas próprias permissões
](#security_iam_id-based-policy-examples-view-own-permissions)
## Práticas recomendadas de política
As políticas baseadas em identidade determinam se alguém pode criar, acessar ou excluir recursos do MemoryDB 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*.
## Como usar o console do MemoryDB
Para acessar o console do MemoryDB, você deve ter um conjunto mínimo de permissões. Essas permissões devem permitir que você liste e visualize detalhes sobre os recursos do MemoryDB em seu. Conta da AWS Caso crie uma política baseada em identidade mais restritiva que as permissões mínimas necessárias, o console não funcionará como pretendido para entidades (usuários ou perfis) com essa política.
Você não precisa permitir permissões mínimas do console para usuários que estão fazendo chamadas somente para a API AWS CLI ou para a AWS API. Em vez disso, permita o acesso somente a ações que correspondam à operação de API que estiverem tentando executar.
Para garantir que usuários e funções ainda possam usar o console do MemoryDB, anexe também o MemoryDB `ConsoleAccess` ou a política `ReadOnly` AWS gerenciada às entidades. Para obter informações, consulte [Adicionar permissões a um usuário](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) 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": "*"
}
]
}
```
# Solucionar problemas de identidade e acesso do MemoryDB
Use as seguintes informações para ajudar a diagnosticar e corrigir problemas comuns que podem ser encontrados ao trabalhar com o MemoryDB e o IAM.
**Topics**
+ [
## Não tenho autorização para executar uma ação no MemoryDB
](#security_iam_troubleshoot-no-permissions)
+ [
## Não estou autorizado a realizar iam: PassRole
](#security_iam_troubleshoot-passrole)
+ [
## Quero permitir que pessoas fora da minha AWS conta acessem meus recursos do MemoryDB
](#security_iam_troubleshoot-cross-account-access)
## Não tenho autorização para executar uma ação no MemoryDB
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. O administrador é a pessoa que forneceu o seu nome de usuário e senha.
O erro do exemplo a seguir ocorre quando o usuário `mateojackson` tenta usar o console para visualizar detalhes sobre um recurso do `my-example-widget` fictício, mas não tem as permissões fictícias do `MemoryDB:GetWidget`.
```
User: arn:aws:iam::123456789012:user/mateojackson is not authorized to perform: MemoryDB:GetWidget on resource: my-example-widget
```
Neste caso, Mateo pede ao administrador para atualizar suas políticas e permitir o acesso ao recurso `my-example-widget` usando a ação `MemoryDB:GetWidget`.
## Não estou autorizado a realizar iam: PassRole
Se você receber uma mensagem de erro informando que não tem autorização para executar a ação `iam:PassRole`, as suas políticas deverão ser atualizadas para permitir a passagem de um perfil para o ACM.
Alguns Serviços da AWS permitem que você passe uma função existente para esse serviço em vez de criar uma nova função de serviço ou uma função vinculada ao serviço. Para fazer isso, é preciso ter permissões para passar o perfil para o serviço.
O exemplo de erro a seguir ocorre quando uma usuário do IAM chamado `marymajor` tenta usar o console para executar uma ação no MemoryDB. No entanto, a ação exige que o serviço tenha permissões concedidas por um perfil de serviço. Mary não tem permissões para passar o perfil para o serviço.
```
User: arn:aws:iam::123456789012:user/marymajor is not authorized to perform: iam:PassRole
```
Nesse caso, as políticas de Mary devem ser atualizadas para permitir que ela realize a ação `iam:PassRole`.
Se precisar de ajuda, entre em contato com seu AWS administrador. Seu administrador é a pessoa que forneceu suas credenciais de login.
## Quero permitir que pessoas fora da minha AWS conta acessem meus recursos do MemoryDB
É possível criar um perfil que os usuários de outras contas ou pessoas fora da organização podem usar para acessar seus recursos. É possível especificar quem é confiável para assumir o perfil. Para serviços que oferecem suporte a políticas baseadas em recursos ou listas de controle de acesso (ACLs), você pode usar essas políticas para conceder às pessoas acesso aos seus recursos.
Para saber mais, consulte:
+ Para saber se o MemoryDB oferece suporte a esses atributos, consulte [Como o MemoryDB funciona com o IAM](security_iam_service-with-iam.md).
+ Para saber como fornecer acesso aos seus recursos em todos os Contas da AWS que você possui, consulte Como [fornecer acesso a um usuário do IAM em outro Conta da AWS que você possui](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_aws-accounts.html) no *Guia do usuário do IAM*.
+ Para saber como fornecer acesso aos seus recursos a terceiros Contas da AWS, consulte Como [fornecer acesso Contas da AWS a terceiros](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_third-party.html) no *Guia do usuário do IAM*.
+ Para saber como conceder acesso por meio da federação de identidades, consulte [Conceder acesso a usuários autenticados externamente (federação de identidades)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html) no *Guia do usuário do IAM*.
+ Para saber a diferença entre perfis e políticas baseadas em recurso para acesso entre contas, consulte [Acesso a recursos entre contas no IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies-cross-account-resource-access.html) no *Guia do usuário do IAM*.
## Controle de acesso
Você pode ter credenciais válidas para autenticar suas solicitações. No entanto, a menos que tenha permissões, não é possível criar nem acessar os recursos do MemoryDB. Por exemplo, você deve ter permissões para criar um cluster do MemoryDB.
As seções a seguir descrevem como gerenciar permissões para o MemoryDB. Recomendamos que você leia a visão geral primeiro.
+ [Visão geral do gerenciamento de permissões de acesso aos recursos do MemoryDB](iam.overview.md)
+ [Usar políticas baseadas em identidade (políticas do IAM) para o MemoryDB](iam.identitybasedpolicies.md)
# Visão geral do gerenciamento de permissões de acesso aos recursos do MemoryDB
Cada AWS recurso pertence a uma AWS conta, e as permissões para criar ou acessar um recurso são regidas por políticas de permissões. Um administrador de conta pode anexar políticas de permissões a identidades do IAM (ou seja, usuários, grupos e funções). Além disso, o MemoryDB também oferece suporte à anexação de políticas de permissões aos recursos.
**nota**
Um *administrador da conta* (ou usuário administrador) é um usuário com privilégios de administrador. Para obter mais informações, 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*.
Para conceder acesso, adicione as permissões aos seus usuários, grupos ou perfis:
+ Usuários e grupos em Centro de Identidade do AWS IAM:
Crie um conjunto de permissões. Siga as instruções em [Criação de um conjunto de permissões](https://docs.aws.amazon.com//singlesignon/latest/userguide/howtocreatepermissionset.html) no *Guia do usuário do Centro de Identidade do AWS IAM *.
+ Usuários gerenciados no IAM com provedor de identidades:
Crie um perfil para a federação de identidades. Siga as instruções em [Criando um perfil para um provedor de identidades de terceiros (federação)](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-idp.html) no *Guia do Usuário do IAM*.
+ Usuários do IAM:
+ Crie um perfil que seu usuário possa assumir. Siga as instruções em [Criação de um perfil para um usuário do IAM](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_roles_create_for-user.html) no *Guia do usuário do IAM*.
+ (Não recomendado) Vincule uma política diretamente a um usuário ou adicione um usuário a um grupo de usuários. Siga as instruções em [Adição de permissões a um usuário (console)](https://docs.aws.amazon.com//IAM/latest/UserGuide/id_users_change-permissions.html#users_change_permissions-add-console) no *Guia do usuário do IAM*.
**Topics**
+ [
## Recursos e operações do MemoryDB
](#iam.overview.resourcesandoperations)
+ [
## Informações sobre propriedade de recursos
](#access-control-resource-ownership)
+ [
## Gerenciar acesso aos recursos da
](#iam.overview.managingaccess)
+ [
# Usar políticas baseadas em identidade (políticas do IAM) para o MemoryDB
](iam.identitybasedpolicies.md)
+ [
# Permissões em nível de recurso
](iam.resourcelevelpermissions.md)
+ [
# Usar perfis vinculados ao serviço para o MemoryDB
](using-service-linked-roles.md)
+ [
# AWS políticas gerenciadas para MemoryDB
](security-iam-awsmanpol.md)
+ [
# Permissões da API do MemoryDB: referência de condições, recursos e ações
](iam.APIReference.md)
## Recursos e operações do MemoryDB
No MemoryDB, o recurso primário é um *cluster*.
Esses recursos têm nomes de recursos exclusivos da Amazon (ARNs) associados a eles, conforme mostrado a seguir.
**nota**
Para que as permissões de nível de recurso sejam efetivas, o nome do recurso na string ARN deve ser minúsculo.
****
| Tipo de atributo | Formato ARN |
| --- | --- |
| Usuário | arn:aws:memorydb ::usuário/usuário1 *us-east-1:123456789012* |
| Lista de controle de acesso (ACL) | arn: aws:memorydb ::acl/myacl *us-east-1:123456789012* |
| Cluster | arn: aws:memorydb ::cluster/my-cluster *us-east-1:123456789012* |
| Instantâneo | arn:aws:memorydb ::snapshot/my-snapshot *us-east-1:123456789012* |
| Grupo de parâmetros | arn: aws:memorydb ::grupo de parâmetros/*us-east-1:123456789012*my-parameter-group |
| Grupo de sub-redes | arn: aws:memorydb ::subnetgroup/ *us-east-1:123456789012* my-subnet-group |
O MemoryDB fornece um conjunto de operações para trabalhar com recursos do MemoryDB. Para conferir uma lista das operações disponíveis, consulte [Actions](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_Operations.html) do MemoryDB.
## Informações sobre propriedade de recursos
*O proprietário do recurso* é a AWS conta que criou o recurso. Ou seja, o proprietário do recurso é a AWS conta da entidade principal que autentica a solicitação que cria o recurso. Uma *entidade principal* pode ser a conta raiz, um usuário do IAM ou uma perfil do IAM. Os seguintes exemplos mostram como isso funciona:
+ Suponha que você use as credenciais da conta raiz da sua AWS conta para criar um cluster. Nesse caso, sua AWS conta é a proprietária do recurso. No MemoryDB, o recurso é o cluster.
+ Suponha que você crie um usuário do IAM em sua AWS conta e conceda permissões para criar um cluster para esse usuário. Nesse caso, o usuário pode criar um cluster. No entanto, sua AWS conta, à qual o usuário pertence, é proprietária do recurso de cluster.
+ Suponha que você crie uma função do IAM em sua AWS conta com permissões para criar um cluster. Nesse caso, qualquer pessoa que possa assumir a função poderá criar um cluster. Sua AWS conta, à qual a função pertence, é proprietária do recurso de cluster.
## Gerenciar acesso aos recursos da
Uma *política de permissões* descreve quem tem acesso a quê. A seção a seguir explica as opções disponíveis para a criação de políticas de permissões.
**nota**
Esta seção discute o uso do IAM no contexto do MemoryDB. Não são fornecidas informações detalhadas sobre o serviço IAM. Para obter a documentação completa do IAM, consulte [O que é o IAM?](https://docs.aws.amazon.com/IAM/latest/UserGuide/introduction.html) no *Guia do usuário do IAM*. Para obter mais informações sobre a sintaxe e as descrições da política do IAM, consulte a [Referência de políticas do AWS IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies.html) no *Guia do usuário do IAM*.
As políticas anexadas a uma identidade do IAM são conhecidas como políticas *baseadas em identidade* (políticas do IAM). As políticas anexadas a um recurso são chamadas de *políticas baseadas em recursos*.
**Topics**
+ [
### Políticas baseadas em identidade (políticas do IAM)
](#iam.overview.managingaccess.identitybasedpolicies)
+ [
### Especificar elementos da política: ações, efeitos, recursos e entidades principais
](#iam.overview.policyelements)
+ [
### Especificar condições em uma política
](#iam.specifyconditions)
### Políticas baseadas em identidade (políticas do IAM)
É possível anexar políticas a identidades do IAM. Por exemplo, você pode fazer o seguinte:
+ **Anexar uma política de permissões a um usuário ou grupo na sua conta**: um administrador de conta pode usar uma política de permissões associada a determinado usuário para conceder permissões. Nesse caso, as permissões são para o usuário criar um recurso do MemoryDB, como um cluster, um grupo de parâmetros ou um grupo de segurança.
+ **Anexar uma política de permissões a uma função**: você pode anexar uma política de permissões baseada em identidade a um perfil do IAM para conceder permissões entre contas. Por exemplo, o administrador na Conta A pode criar uma função para conceder permissões entre contas a outra AWS conta (por exemplo, Conta B) ou a um AWS serviço da seguinte forma:
1. Um administrador da Conta A cria uma função do IAM e anexa uma política de permissões à função que concede permissões em recursos da Conta A.
1. Um administrador da Conta A anexa uma política de confiança à função identificando a Conta B como a entidade principal, que pode assumir a função.
1. O administrador da Conta B pode então delegar permissões para assumir a função a qualquer usuário na Conta B. Isso permite que os usuários da Conta B criem ou acessem recursos na Conta A. Em alguns casos, talvez você queira conceder permissões a um AWS serviço para assumir a função. Para oferecer suporte a essa abordagem, o principal da política de confiança também pode ser um principal de serviço da AWS .
Para obter mais informações sobre o uso do IAM para delegar permissões, consulte [Gerenciamento de acesso](https://docs.aws.amazon.com/IAM/latest/UserGuide/access.html) no *Guia do usuário do IAM*.
Veja a seguir um exemplo de política que permite que um usuário execute a `DescribeClusters` ação AWS em sua conta. O MemoryDB também suporta a identificação de recursos específicos usando o recurso ARNs para ações de API. Essa abordagem também é chamada de permissões no nível do recurso.
Para obter mais informações sobre como usar políticas baseadas em identidade com o MemoryDB, consulte [Usar políticas baseadas em identidade (políticas do IAM) para o MemoryDB](iam.identitybasedpolicies.md). Para obter mais informações sobre usuários, grupos, funções e permissões, consulte [Identidades (usuários, grupos e funções)](https://docs.aws.amazon.com/IAM/latest/UserGuide/id.html) no *Guia do usuário do IAM*.
### Especificar elementos da política: ações, efeitos, recursos e entidades principais
Para cada recurso do MemoryDB (consulte [Recursos e operações do MemoryDB](#iam.overview.resourcesandoperations)), o serviço define um conjunto de operações de API (consulte [Actions](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_Operations.html)). Para conceder permissões a essas operações da API, o MemoryDB define um conjunto de ações que podem ser especificadas em uma política. Por exemplo, para o recurso de cluster do MemoryDB, as seguintes ações são definidas: `CreateCluster`, `DeleteCluster`, e `DescribeClusters`. A execução de uma operação de API pode exigir permissões para mais de uma ação.
Estes são os elementos de política mais básicos:
+ **Recurso**: em uma política, você usa um Amazon Resource Name (ARN – Nome do recurso da Amazon) para identificar o recurso a que a política se aplica. Para obter mais informações, consulte [Recursos e operações do MemoryDB](#iam.overview.resourcesandoperations).
+ **Ação**: você usa palavras-chave de ação para identificar operações de recursos que deseja permitir ou negar. Por exemplo, dependendo do `Effect` especificado, a permissão `memorydb:CreateCluster` permite ou nega as permissões do usuário para executar a operação `CreateCluster` no MemoryDB.
+ **Efeito**: você especifica o efeito quando o usuário solicita a ação específica, que pode ser permitir ou negar. Se você não conceder (permitir) explicitamente acesso a um recurso, o acesso estará implicitamente negado. Você também pode negar acesso explicitamente a um recurso. Por exemplo, você poderia fazer isso para garantir que um usuário não possa acessar o recurso, mesmo se uma política diferente conceder o acesso.
+ **Entidade principal**: em políticas baseadas em identidade (políticas do IAM), o usuário ao qual a política é anexada é a entidade principal implícita. Para as políticas baseadas em recursos, você especifica quais usuários, contas, serviços ou outras entidades deseja que recebam permissões (isso se aplica somente a políticas baseadas em recursos).
Para saber mais sobre a sintaxe e as descrições de políticas do IAM, consulte a [Referência de políticas do AWS IAM da ](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies.html) no *Guia do usuário do IAM*.
Para conferir uma tabela que mostra todas as ações de API do MemoryDB, consulte [Permissões da API do MemoryDB: referência de condições, recursos e ações](iam.APIReference.md).
### Especificar condições em uma política
Ao conceder permissões, você pode usar a linguagem da política do IAM para especificar as condições de quando uma política deverá entrar em vigor. Por exemplo, é recomendável aplicar uma política somente após uma data específica. Para obter mais informações sobre como especificar condições em uma linguagem de política, consulte [Condition](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements.html#Condition) no *Guia do usuário do IAM*.
# Usar políticas baseadas em identidade (políticas do IAM) para o MemoryDB
Este tópico fornece exemplos de políticas baseadas em identidade em que um administrador de conta pode anexar políticas de permissões a identidades do IAM (ou seja, usuários, grupos e funções).
**Importante**
Recomendamos que você primeiro leia os tópicos que explicam os conceitos básicos e as opções para gerenciar o acesso aos recursos do MemoryDB. Para obter mais informações, consulte [Visão geral do gerenciamento de permissões de acesso aos recursos do MemoryDB](iam.overview.md).
As seções neste tópico abrangem o seguinte:
+ [Permissões necessárias para usar o console do MemoryDB](#iam.identitybasedpolicies.minconpolicies)
+ [Políticas gerenciadas pela AWS(predefinidas) para o MemoryDB](security-iam-awsmanpol.md#iam.identitybasedpolicies.predefinedpolicies)
+ [Exemplos de política gerenciada pelo cliente](#iam.identitybasedpolicies.customermanagedpolicies)
A seguir, um exemplo de uma política de permissões.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Sid": "AllowClusterPermissions",
"Effect": "Allow",
"Action": [
"memorydb:CreateCluster",
"memorydb:DescribeClusters",
"memorydb:UpdateCluster"],
"Resource": "*"
},
{
"Sid": "AllowUserToPassRole",
"Effect": "Allow",
"Action": [ "iam:PassRole" ],
"Resource": "arn:aws:iam::123456789012:role/EC2-roles-for-cluster"
}
]
}
```
------
A política tem duas instruções:
+ A primeira instrução concede permissões para as ações do MemoryDB (`memorydb:CreateCluster`, `memorydb:DescribeClusters`, e `memorydb:UpdateCluster`) em qualquer cluster pertencente à conta.
+ A segunda instrução concede permissões para a ação do IAM (`iam:PassRole`) no nome da função do IAM especificado no final do valor `Resource`.
A política não especifica o elemento `Principal` porque, em uma política baseada em identidade, a entidade principal que obtém as permissões não é especificada. Quando você anexar uma política um usuário, o usuário será a entidade principal implícita. Quando você anexa uma política de permissões a um perfil do IAM, a entidade principal identificada na política de confiança do perfil obtém as permissões.
Para conferir uma tabela que mostra todas as ações da API do MemoryDB e os recursos a que elas se aplicam, consulte [Permissões da API do MemoryDB: referência de condições, recursos e ações](iam.APIReference.md).
## Permissões necessárias para usar o console do MemoryDB
A tabela de referência de permissões lista as operações de API do MemoryDB e mostra as permissões necessárias para cada operação. Para obter mais informações sobre as operações de API do MemoryDB, consulte [Permissões da API do MemoryDB: referência de condições, recursos e ações](iam.APIReference.md).
Para usar o console do MemoryDB, primeiro conceda permissões para ações adicionais, como mostrado na política de permissões a seguir.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Sid": "MinPermsForMemDBConsole",
"Effect": "Allow",
"Action": [
"memorydb:Describe*",
"memorydb:List*",
"ec2:DescribeAvailabilityZones",
"ec2:DescribeVpcs",
"ec2:DescribeAccountAttributes",
"ec2:DescribeSecurityGroups",
"cloudwatch:GetMetricStatistics",
"cloudwatch:DescribeAlarms",
"s3:ListAllMyBuckets",
"sns:ListTopics",
"sns:ListSubscriptions" ],
"Resource": "*"
}
]
}
```
------
O console do MemoryDB precisa dessas permissões adicionais pelas seguintes razões:
+ As permissões para ações do MemoryDB habilitam o console para exibir recursos do MemoryDB na conta.
+ O console precisa de permissões para que as `ec2` ações consultem o Amazon EC2 para que ele possa exibir zonas de disponibilidade VPCs, grupos de segurança e atributos da conta.
+ As permissões para `cloudwatch` ações permitem que o console recupere CloudWatch métricas e alarmes da Amazon e os exiba no console.
+ As permissões para ações do `sns` permitem que o console recupere tópicos e assinaturas do Amazon Simple Notification Service (Amazon SNS) e os exiba no console.
## Exemplos de política gerenciada pelo cliente
Se você não estiver usando uma política padrão e optar por usar uma política gerenciada personalizada, realize uma destas ações: Você deve ter permissões para chamar `iam:createServiceLinkedRole` (para obter mais informações, consulte [Exemplo 4: permitir que um usuário chame a CreateServiceLinkedRole API IAM](#create-service-linked-role-policy)). Ou você deve ter criado uma função vinculada ao serviço do MemoryDB.
Quando combinadas com as permissões mínimas necessárias para usar o console do MemoryDB, as políticas de exemplo nesta seção concedem permissões adicionais. Os exemplos também são relevantes para o AWS SDKs e AWS CLI o. Para obter mais informações sobre quais permissões são necessárias para usar o console do MemoryDB, consulte [Permissões necessárias para usar o console do MemoryDB](#iam.identitybasedpolicies.minconpolicies).
Para obter instruções sobre como configurar usuários e grupos do IAM, consulte [Criação do seu primeiro usuário do IAM e grupo de administradores](https://docs.aws.amazon.com/IAM/latest/UserGuide/getting-started_create-admin-group.html) no *Guia do usuário do IAM*.
**Importante**
Sempre teste suas políticas do IAM completamente antes de usá-las em produção. Algumas ações do MemoryDB que parecem simples podem exigir outras ações para oferecer suporte quando você estiver usando o console do MemoryDB. Por exemplo, `memorydb:CreateCluster` concede permissões para criar clusters de cache do MemoryDB. No entanto, para realizar essa operação, o console do MemoryDB usa várias ações `Describe` e `List` para preencher listas de consoles.
**Topics**
+ [
### Exemplo 1: permitir a um usuário com acesso somente de leitura a recursos do MemoryDB
](#example-allow-list-current-memorydb-resources)
+ [
### Exemplo 2: permitir que um usuário realize tarefas comuns de administrador do sistema do MemoryDB
](#example-allow-specific-memorydb-actions)
+ [
### Exemplo 3: permitir que um usuário acesse todas as ações de API do MemoryDB
](#allow-unrestricted-access)
+ [
### Exemplo 4: permitir que um usuário chame a CreateServiceLinkedRole API IAM
](#create-service-linked-role-policy)
### Exemplo 1: permitir a um usuário com acesso somente de leitura a recursos do MemoryDB
A seguinte política concede permissões a ações do MemoryDB que permitem que um usuário liste recursos. Normalmente, você anexa esse tipo de política de permissões a um grupo de gerentes.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[{
"Sid": "MemDBUnrestricted",
"Effect":"Allow",
"Action": [
"memorydb:Describe*",
"memorydb:List*"],
"Resource":"*"
}
]
}
```
------
### Exemplo 2: permitir que um usuário realize tarefas comuns de administrador do sistema do MemoryDB
As tarefas comuns do administrador do sistema incluem a modificação de clusters de cache, parâmetros e grupo de parâmetros. Um administrador do sistema também pode querer obter informações sobre eventos do MemoryDB. A seguinte política concede permissões de usuário para executar ações do MemoryDB para essas tarefas comuns de administrador de sistema. Normalmente, você anexa esse tipo de política de permissões ao grupo de administradores do sistema.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Sid": "MDBAllowSpecific",
"Effect": "Allow",
"Action": [
"memorydb:UpdateCluster",
"memorydb:DescribeClusters",
"memorydb:DescribeEvents",
"memorydb:UpdateParameterGroup",
"memorydb:DescribeParameterGroups",
"memorydb:DescribeParameters",
"memorydb:ResetParameterGroup"
],
"Resource": "*"
}
]
}
```
------
### Exemplo 3: permitir que um usuário acesse todas as ações de API do MemoryDB
A seguinte política permite que um usuário acesse todas as ações do MemoryDB. Recomendamos que você conceda esse tipo de política de permissões apenas a um usuário administrador.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[{
"Sid": "MDBAllowAll",
"Effect":"Allow",
"Action":[
"memorydb:*" ],
"Resource":"*"
}
]
}
```
------
### Exemplo 4: permitir que um usuário chame a CreateServiceLinkedRole API IAM
A política a seguir permite que o usuário chame a API `CreateServiceLinkedRole` do IAM. Recomendamos conceder esse tipo de política de permissões para o usuário que invoca operações mutativas do MemoryDB.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement":[
{
"Sid":"CreateSLRAllows",
"Effect":"Allow",
"Action":[
"iam:CreateServiceLinkedRole"
],
"Resource":"*",
"Condition":{
"StringLike":{
"iam:AWS ServiceName":"memorydb.amazonaws.com"
}
}
}
]
}
```
------
# Permissões em nível de recurso
Você pode restringir o escopo das permissões especificando recursos em uma política do IAM. Muitas ações de AWS CLI API oferecem suporte a um tipo de recurso que varia de acordo com o comportamento da ação. Cada instrução de política do IAM concede permissão a uma ação realizada em um recurso. Quando a ação não atua em um recurso indicado, ou quando você concede permissão para executar a ação em todos os recursos, o valor do recurso na política é um curinga (\$1). Para muitas ações de API, restrinja os recursos que um usuário pode modificar especificando o Amazon Resource Name (ARN – Nome de recurso da Amazon) de um recurso ou um padrão de ARN correspondente a vários recursos. Para restringir as permissões por recurso especifique o recurso por ARN.
**Formato ARN do recurso MemoryDB**
**nota**
Para que as permissões em nível de recurso sejam efetivas, o nome do recurso na string ARN deve estar em minúsculas.
+ Usuário — arn:aws:memorydb ::user/user1 *us-east-1:123456789012*
+ ACL — arn:aws:memorydb ::acl/my-acl *us-east-1:123456789012*
+ Cluster — arn:aws:memorydb ::cluster/my-cluster *us-east-1:123456789012*
+ Instantâneo — arn:aws:memorydb ::snapshot/my-snapshot *us-east-1:123456789012*
+ Grupo de parâmetros — arn:aws:memorydb ::parametergroup/ *us-east-1:123456789012* my-parameter-group
+ Grupo de sub-rede — arn:aws:memorydb ::subnetgroup/ *us-east-1:123456789012* my-subnet-group
**Topics**
+ [
## Exemplo 1: permitir que um usuário tenha acesso total a tipos de recurso específicos do MemoryDB
](#example-allow-list-current-memorydb-resources-resource)
+ [
## Exemplo 2: negar a um usuário o acesso a um cluster.
](#example-allow-specific-memorydb-actions-resource)
## Exemplo 1: permitir que um usuário tenha acesso total a tipos de recurso específicos do MemoryDB
A seguinte política permite explicitamente o acesso total da `account-id` especificada a todos os recursos do tipo grupo de sub-redes, grupo de segurança e cluster.
```
{
"Sid": "Example1",
"Effect": "Allow",
"Action": "memorydb:*",
"Resource": [
"arn:aws:memorydb:us-east-1:account-id:subnetgroup/*",
"arn:aws:memorydb:us-east-1:account-id:securitygroup/*",
"arn:aws:memorydb:us-east-1:account-id:cluster/*"
]
}
```
## Exemplo 2: negar a um usuário o acesso a um cluster.
O exemplo a seguir nega explicitamente o acesso especificado da `account-id` a um determinado cluster.
```
{
"Sid": "Example2",
"Effect": "Deny",
"Action": "memorydb:*",
"Resource": [
"arn:aws:memorydb:us-east-1:account-id:cluster/name"
]
}
```
# Usar perfis vinculados ao serviço para o MemoryDB
O MemoryDB usa funções vinculadas ao [serviço 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). Uma função vinculada ao serviço é um tipo exclusivo de função do IAM vinculada diretamente a um AWS serviço, como o MemoryDB. Os perfis vinculados ao serviço do MemoryDB são predefinidos pelo MemoryDB. Elas incluem todas as permissões que o serviço exige para chamar os serviços da AWS em nome dos seus clusters.
Um perfil vinculado ao serviço facilita a configuração do MemoryDB, já que você não precisa adicionar as permissões necessárias manualmente. As funções já existem na sua AWS conta, mas estão vinculadas aos casos de uso do MemoryDB e têm permissões predefinidas. Somente o MemoryDB pode assumir esses perfis e somente esses perfis podem usar a política de permissões predefinidas. Você pode excluir os perfis somente depois de primeiro excluir seus recursos relacionados. Isso protege os recursos do MemoryDB, já que não é possível remover por engano as permissões necessárias para acessar os recursos.
Para obter informações sobre outros serviços compatíveis com perfis vinculados a serviços, consulte [Serviços da AWS 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 contenham **Sim** na coluna **Service-Linked Role**. Escolha um **Sim** com um link para visualizar a documentação do perfil vinculado para esse serviço.
**Contents**
+ [Permissões de perfil vinculado ao serviço](#service-linked-role-permissions)
+ [
## Criação de uma função vinculada ao serviço (IAM)
](#create-service-linked-role-iam)
+ [Uso do console do IAM](#create-service-linked-role-iam-console)
+ [Uso da CLI do IAM](#create-service-linked-role-iam-cli)
+ [Uso da API do IAM](#create-service-linked-role-iam-api)
+ [Editar a descrição de uma função vinculada ao serviço](#edit-service-linked-role)
+ [Uso do console do IAM](#edit-service-linked-role-iam-console)
+ [Uso da CLI do IAM](#edit-service-linked-role-iam-cli)
+ [Uso da API do IAM](#edit-service-linked-role-iam-api)
+ [
## Excluir um perfil vinculado ao serviço para o MemoryDB
](#delete-service-linked-role)
+ [
### Limpar uma função vinculada ao serviço
](#service-linked-role-review-before-delete)
+ [
### Exclusão de uma função vinculada ao serviço (console do IAM)
](#delete-service-linked-role-iam-console)
+ [
### Exclusão de uma função vinculada ao serviço (CLI do IAM)
](#delete-service-linked-role-iam-cli)
+ [
### Exclusã de uma função vinculada ao serviço (API do IAM)
](#delete-service-linked-role-iam-api)
## Permissões de perfil vinculado ao serviço para o MemoryDB
O MemoryDB usa a função vinculada ao serviço chamada **AWSServiceRoleForMemoryDB** — Essa política permite que o MemoryDB gerencie AWS recursos em seu nome conforme necessário para gerenciar seus clusters.
A política de permissões de função vinculada ao serviço de AWSService RoleForMemory banco de dados permite que o MemoryDB conclua as seguintes ações nos recursos especificados:
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": "arn:aws-cn:ec2:*:*:network-interface/*",
"Condition": {
"StringEquals": {
"ec2:CreateAction": "CreateNetworkInterface"
},
"ForAllValues:StringEquals": {
"aws:TagKeys": [
"AmazonMemoryDBManaged"
]
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateNetworkInterface"
],
"Resource": [
"arn:aws-cn:ec2:*:*:network-interface/*",
"arn:aws-cn:ec2:*:*:subnet/*",
"arn:aws-cn:ec2:*:*:security-group/*"
]
},
{
"Effect": "Allow",
"Action": [
"ec2:DeleteNetworkInterface",
"ec2:ModifyNetworkInterfaceAttribute"
],
"Resource": "arn:aws-cn:ec2:*:*:network-interface/*",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/AmazonMemoryDBManaged": "true"
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:DeleteNetworkInterface",
"ec2:ModifyNetworkInterfaceAttribute"
],
"Resource": "arn:aws-cn:ec2:*:*:security-group/*"
},
{
"Effect": "Allow",
"Action": [
"ec2:DescribeSecurityGroups",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeAvailabilityZones",
"ec2:DescribeSubnets",
"ec2:DescribeVpcs"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"cloudwatch:PutMetricData"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"cloudwatch:namespace": "AWS/MemoryDB"
}
}
}
]
}
```
------
Para obter mais informações, consulte [AWS política gerenciada: Memória DBService RolePolicy](security-iam-awsmanpol.md#security-iam-awsmanpol-memorydbServiceRolePolicy).
**Para permitir que uma entidade do IAM crie funções vinculadas ao serviço de AWSService RoleForMemory banco de dados**
Adicione a seguinte declaração de política às permissões dessa entidade IAM:
```
{
"Effect": "Allow",
"Action": [
"iam:CreateServiceLinkedRole",
"iam:PutRolePolicy"
],
"Resource": "arn:aws:iam::*:role/aws-service-role/memorydb.amazonaws.com/AWSServiceRoleForMemoryDB*",
"Condition": {"StringLike": {"iam:AWS ServiceName": "memorydb.amazonaws.com"}}
}
```
**Para permitir que uma entidade do IAM exclua funções vinculadas ao serviço de AWSService RoleForMemory banco de dados**
Adicione a seguinte declaração de política às permissões dessa entidade IAM:
```
{
"Effect": "Allow",
"Action": [
"iam:DeleteServiceLinkedRole",
"iam:GetServiceLinkedRoleDeletionStatus"
],
"Resource": "arn:aws:iam::*:role/aws-service-role/memorydb.amazonaws.com/AWSServiceRoleForMemoryDB*",
"Condition": {"StringLike": {"iam:AWS ServiceName": "memorydb.amazonaws.com"}}
}
```
Como alternativa, você pode usar uma política AWS gerenciada para fornecer acesso total ao MemoryDB.
## Criação de uma função vinculada ao serviço (IAM)
Você pode criar uma função vinculada ao serviço usando o console do IAM, a CLI ou a API.
### Criação de uma função vinculada ao serviço (console do IAM)
Você pode usar o console do IAM para criar uma função vinculada ao serviço.
**Para criar uma função vinculada ao serviço (console)**
1. Faça login no Console de gerenciamento da AWS e abra o console do IAM em [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. No painel de navegação esquerdo do console IAM, escolha **Funções**. Em seguida, escolha **Criar nova função**.
1. Em **Selecionar tipo de entidade confiável**, selecione **Serviço da AWS **.
1. Em **Ou selecione um serviço para visualizar seus casos de uso**, escolha **MemoryDB**.
1. Escolha **Próximo: permissões**.
1. Em **Nome da política**, observe que `MemoryDBServiceRolePolicy` é necessário para esta função. Escolha **Próximo: tags**.
1. Observe que não há suporte para as tags para funções vinculadas ao serviço. Escolha **Próximo: análise**.
1. (Opcional) Em **Descrição da função**, edite a descrição para a nova função vinculada ao serviço.
1. Revise a função e escolha **Criar função**.
### Criação de uma função vinculada ao serviço (CLI do IAM)
Você pode usar as operações do IAM do AWS Command Line Interface para criar uma função vinculada ao serviço. Essa função pode incluir a política de confiança e as políticas em linha de que o serviço precisa para assumir a função.
**Para criar uma função vinculada ao serviço (CLI)**
Use a seguinte operação:
```
$ aws iam [create-service-linked-role](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateServiceLinkedRole.html) --aws-service-name memorydb.amazonaws.com
```
### Criação de uma função vinculada ao serviço (API do IAM)
Você pode usar a API do IAM para excluir uma função vinculada ao serviço. Essa função pode conter a política de confiança e as políticas em linha de que o serviço precisa para assumir a função.
**Para criar uma função vinculada ao serviço (API)**
Use a chamada da API [CreateServiceLinkedRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_CreateServiceLinkedRole.html). Na solicitação, especifique o nome do serviço na forma de `memorydb.amazonaws.com`.
## Editar a descrição de um perfil vinculado ao serviço para o MemoryDB
O MemoryDB não permite que você edite a função vinculada ao serviço de AWSService RoleForMemory banco de dados. 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.
### Edição da descrição de uma função vinculada ao serviço (console do IAM)
Também é possível usar o console do IAM para editar a descrição de uma função vinculada ao serviço.
**Para editar a descrição de uma função vinculada ao serviço (console)**
1. No painel de navegação esquerdo do console IAM, escolha **Funções**.
1. Escolha o nome da função a ser modificada.
1. No extremo direito da **Descrição da função**, escolha **Editar**.
1. Insira uma nova descrição na caixa e escolha **Salvar**.
### Edição da descrição de uma função vinculada ao serviço (CLI do IAM)
Você pode usar as operações do IAM do AWS Command Line Interface para editar uma descrição de função vinculada ao serviço.
**Para alterar a descrição de uma função (CLI)**
1. (Opcional) Para ver a descrição atual de uma função, use a operação AWS CLI for IAM`[get-role](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html)`.
**Example**
```
$ aws iam [get-role](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html) --role-name AWSServiceRoleForMemoryDB
```
Use o nome da função, não o nome de recurso da Amazon (ARN), para fazer referência às funções com as operações da CLI. Por exemplo, se uma função tiver o seguinte nome de recurso da Amazon (ARN): `arn:aws:iam::123456789012:role/myrole`, você fará referência à função como **myrole**.
1. Para atualizar a descrição de uma função vinculada ao serviço, use a operação AWS CLI for IAM. `[update-role-description](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateRoleDescription.html)`
Para Linux, macOS ou Unix:
```
$ aws iam [update-role-description](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateRoleDescription.html) \
--role-name AWSServiceRoleForMemoryDB \
--description "new description"
```
Para Windows:
```
$ aws iam [update-role-description](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateRoleDescription.html) ^
--role-name AWSServiceRoleForMemoryDB ^
--description "new description"
```
### Edição da descrição de uma função vinculada ao serviço (API do IAM)
Você pode usar a API do IAM para editar uma descrição de função vinculada ao serviço.
**Para alterar a descrição de uma função (API)**
1. (Opcional) Para visualizar a descrição atual de uma função, use a operação da API do IAM [GetRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html).
**Example**
```
https://iam.amazonaws.com/
?Action=[GetRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html)
&RoleName=AWSServiceRoleForMemoryDB
&Version=2010-05-08
&AUTHPARAMS
```
1. Para atualizar uma descrição de função, use a operação da API do IAM [UpdateRoleDescription](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateRoleDescription.html).
**Example**
```
https://iam.amazonaws.com/
?Action=[UpdateRoleDescription](https://docs.aws.amazon.com/IAM/latest/APIReference/API_UpdateRoleDescription.html)
&RoleName=AWSServiceRoleForMemoryDB
&Version=2010-05-08
&Description="New description"
```
## Excluir um perfil vinculado ao serviço para o MemoryDB
Se você não precisar mais usar um recurso ou serviço que requer um perfil vinculado ao serviço, é recomendável excluí-lo. Dessa forma, você não tem uma entidade não utilizada que não seja monitorada ativamente ou mantida. No entanto, você deve limpar sua função vinculada ao serviço antes de excluí-la.
O MemoryDB não exclui o perfil vinculado ao serviço para você.
### Limpar uma função vinculada ao serviço
Antes de usar o IAM para excluir uma função vinculada a um serviço, primeiro confirme se a função não tem recursos (clusters) associados a ela.
**Para verificar se a função vinculada ao serviço tem uma sessão ativa no console do IAM**
1. Faça login no Console de gerenciamento da AWS e abra o console do IAM em [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. No painel de navegação esquerdo do console IAM, escolha **Funções**. Em seguida, escolha o nome (não a caixa de seleção) da função de AWSService RoleForMemory banco de dados.
1. Na página **Resumo** para a função selecionada, escolha a guia **Consultor de Acesso**.
1. Na guia **Consultor de Acesso**, revise a atividade recente para a função vinculada ao serviço.
**Para excluir recursos do MemoryDB que exigem AWSService RoleForMemory DB (console)**
+ Para excluir um cluster, consulte o seguinte:
+ [Usando o Console de gerenciamento da AWS](getting-started.md#clusters.deleteclusters.viewdetails)
+ [Usando o AWS CLI](getting-started.md#clusters.delete.cli)
+ [Usando a API do MemoryDB](getting-started.md#clusters.delete.api)
### Exclusão de uma função vinculada ao serviço (console do IAM)
É possível usar o console do IAM para excluir uma função vinculada ao serviço.
**Para excluir uma função vinculada ao serviço (console)**
1. Faça login no Console de gerenciamento da AWS e abra o console do IAM em [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/).
1. No painel de navegação esquerdo do console IAM, escolha **Funções**. Selecione a caixa de marcação ao lado do nome da função que você deseja excluir, não o nome ou a linha em si.
1. Em ações de **Função** na parte superior da página, escolha a função **Excluir**.
1. Na página de confirmação, revise os dados do último acesso ao serviço, que mostram quando cada uma das funções selecionadas acessou um AWS serviço pela última vez. Isso ajuda você a confirmar se a função está ativo no momento. Se quiser prosseguir, escolha **Sim, Excluir** para enviar a função vinculada ao serviço para exclusão.
1. Monitore as notificações do console do IAM para progresso da exclusão da função vinculada ao serviço. Como a exclusão da função vinculada ao serviço do IAM é assíncrona, depois de enviar a função para exclusão, a tarefa pode ou não ser bem-sucedida. Se a tarefa obtiver êxito, você poderá escolher **Visualizar Detalhes** ou **Visualizar Recursos** a partir das notificações para saber por que a exclusão falhou.
### Exclusão de uma função vinculada ao serviço (CLI do IAM)
Você pode usar as operações do IAM do AWS Command Line Interface para excluir uma função vinculada ao serviço.
**Para excluir uma função vinculado ao serviço (CLI)**
1. Se você não souber o nome da função vinculada ao serviço que deseja excluir, insira o seguinte comando. Esse comando lista as funções e seus nomes de recursos da Amazon (ARNs) em sua conta.
```
$ aws iam [get-role](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetRole.html) --role-name role-name
```
Use o nome da função, não o nome de recurso da Amazon (ARN), para fazer referência às funções com as operações da CLI. Por exemplo, se uma função tiver o ARN `arn:aws:iam::123456789012:role/myrole`, você fará referência à função como **myrole**.
1. Como uma função vinculada ao serviço não podem ser excluída se estiver sendo usada ou tiver recursos associados, você deverá enviar uma solicitação de exclusão. Essa solicitação poderá ser negada se essas condições não forem atendidas. Você deve capturar o `deletion-task-id` da resposta para verificar o status da tarefa de exclusão. Insira o seguinte para enviar uma solicitação de exclusão de função vinculada ao serviço.
```
$ aws iam [delete-service-linked-role](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteServiceLinkedRole.html) --role-name role-name
```
1. Insita o seguinte para verificar o estado da tarefa de exclusão.
```
$ aws iam [get-service-linked-role-deletion-status](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetServiceLinkedRoleDeletionStatus.html) --deletion-task-id deletion-task-id
```
O status da tarefa de exclusão pode ser `NOT_STARTED`, `IN_PROGRESS`, `SUCCEEDED`, ou `FAILED`. Se a exclusão falhar, a chamada informará o motivo de falha para que você possa solucionar o problema.
### Exclusã de uma função vinculada ao serviço (API do IAM)
É possível usar a API do IAM para excluir uma função vinculada ao serviço.
**Para excluir uma função vinculada ao serviço (API)**
1. Para enviar uma solicitação de exclusão de um roll vinculada ao serviço, chame [DeleteServiceLinkedRole](https://docs.aws.amazon.com/IAM/latest/APIReference/API_DeleteServiceLinkedRole.html). Na solicitação, especifique o nome da função.
Como uma função vinculada ao serviço não podem ser excluída se estiver sendo usada ou tiver recursos associados, você deverá enviar uma solicitação de exclusão. Essa solicitação poderá ser negada se essas condições não forem atendidas. Você deve capturar o `DeletionTaskId` da resposta para verificar o status da tarefa de exclusão.
1. Para verificar o status da exclusão, chame [GetServiceLinkedRoleDeletionStatus](https://docs.aws.amazon.com/IAM/latest/APIReference/API_GetServiceLinkedRoleDeletionStatus.html). Na solicitação, especifique o `DeletionTaskId`.
O status da tarefa de exclusão pode ser `NOT_STARTED`, `IN_PROGRESS`, `SUCCEEDED`, ou `FAILED`. Se a exclusão falhar, a chamada informará o motivo de falha para que você possa solucionar o problema.
# AWS políticas gerenciadas para MemoryDB
Para adicionar permissões a usuários, grupos e funções, é mais fácil usar políticas AWS gerenciadas do que escrever políticas você mesmo. É necessário tempo e experiência para criar [políticas gerenciadas pelo cliente do IAM](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_create-console.html) que fornecem à sua equipe apenas as permissões de que precisam. Para começar rapidamente, você pode usar nossas políticas AWS gerenciadas. Essas políticas abrangem casos de uso comuns e estão disponíveis em sua AWS conta. Para obter mais informações sobre políticas AWS gerenciadas, consulte [políticas AWS gerenciadas](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 os serviços mantêm e atualizam as políticas AWS gerenciadas. Você não pode alterar as permissões nas políticas AWS gerenciadas. Os serviços ocasionalmente acrescentam permissões adicionais a uma política gerenciada pela AWS para oferecer suporte a novos recursos. Esse tipo de atualização afeta todas as identidades (usuários, grupos e funções) em que a política está anexada. É mais provável que os serviços atualizem uma política gerenciada pela AWS quando um novo recurso for iniciado ou novas operações se tornarem disponíveis. Os serviços não removem as permissões de uma política AWS gerenciada, portanto, as atualizações de políticas não violarão suas permissões existentes.
Além disso, AWS oferece suporte a políticas gerenciadas para funções de trabalho que abrangem vários serviços. Por exemplo, a política **ReadOnlyAccess** AWS gerenciada fornece acesso somente de leitura a todos os AWS serviços e recursos. Quando um serviço lança um novo recurso, AWS adiciona permissões somente de leitura para novas operações e recursos. Para obter uma lista e descrições das políticas de perfis de trabalho, consulte [Políticas gerenciadas pela AWS para perfis de trabalho](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html) no *Guia do usuário do IAM*.
## AWS política gerenciada: Memória DBService RolePolicy
Você não pode anexar a política de memória DBService RolePolicy AWS gerenciada às identidades da sua conta. Essa política faz parte da função vinculada ao serviço AWS MemoryDB. Essa função permite que o serviço gerencie interfaces de rede e grupos de segurança em sua conta.
O MemoryDB usa as permissões desta política para gerenciar grupos de segurança e interfaces de rede do EC2. Isso é necessário para gerenciar clusters do MemoryDB.
**Detalhes das permissões**
Esta política inclui as seguintes permissões.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"ec2:CreateTags"
],
"Resource": "arn:aws-cn:ec2:*:*:network-interface/*",
"Condition": {
"StringEquals": {
"ec2:CreateAction": "CreateNetworkInterface"
},
"ForAllValues:StringEquals": {
"aws:TagKeys": [
"AmazonMemoryDBManaged"
]
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:CreateNetworkInterface"
],
"Resource": [
"arn:aws-cn:ec2:*:*:network-interface/*",
"arn:aws-cn:ec2:*:*:subnet/*",
"arn:aws-cn:ec2:*:*:security-group/*"
]
},
{
"Effect": "Allow",
"Action": [
"ec2:DeleteNetworkInterface",
"ec2:ModifyNetworkInterfaceAttribute"
],
"Resource": "arn:aws-cn:ec2:*:*:network-interface/*",
"Condition": {
"StringEquals": {
"ec2:ResourceTag/AmazonMemoryDBManaged": "true"
}
}
},
{
"Effect": "Allow",
"Action": [
"ec2:DeleteNetworkInterface",
"ec2:ModifyNetworkInterfaceAttribute"
],
"Resource": "arn:aws-cn:ec2:*:*:security-group/*"
},
{
"Effect": "Allow",
"Action": [
"ec2:DescribeSecurityGroups",
"ec2:DescribeNetworkInterfaces",
"ec2:DescribeAvailabilityZones",
"ec2:DescribeSubnets",
"ec2:DescribeVpcs"
],
"Resource": "*"
},
{
"Effect": "Allow",
"Action": [
"cloudwatch:PutMetricData"
],
"Resource": "*",
"Condition": {
"StringEquals": {
"cloudwatch:namespace": "AWS/MemoryDB"
}
}
}
]
}
```
------
## Políticas gerenciadas pela AWS(predefinidas) para o MemoryDB
AWS aborda muitos casos de uso comuns fornecendo políticas autônomas do IAM que são criadas e administradas pela AWS. As políticas gerenciadas concedem permissões necessárias para casos de uso comuns, de maneira que você possa evitar a necessidade de investigar quais permissões são necessárias. Para obter mais informações, consulte [Políticas gerenciadas pela AWS](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_managed-vs-inline.html#aws-managed-policies) no *Guia do usuário do IAM*.
As seguintes políticas AWS gerenciadas, que você pode anexar aos usuários em sua conta, são específicas do MemoryDB:
### AmazonMemoryDBReadOnlyAccess
É possível anexar a política `AmazonMemoryDBReadOnlyAccess` às suas identidades do IAM. Esta política concede permissões administrativas que oferecem acesso somente leitura a todos os recursos do MemoryDB.
**AmazonMemoryDBReadOnlyAccess**- Concede acesso somente de leitura aos recursos do MemoryDB.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": [
"memorydb:Describe*",
"memorydb:List*"
],
"Resource": "*"
}]
}
```
------
### AmazonMemoryDBFullAcesso
É possível anexar a política `AmazonMemoryDBFullAccess` às suas identidades do IAM. Essa política concede permissões administrativas que oferecem acesso total a todos os recursos do MemoryDB.
**AmazonMemoryDBFullAcesso** - Concede acesso total aos recursos do MemoryDB.
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "memorydb:*",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws:iam::*:role/aws-service-role/memorydb.amazonaws.com/AWSServiceRoleForMemoryDB",
"Condition": {
"StringLike": {
"iam:AWSServiceName": "memorydb.amazonaws.com"
}
}
}
]
}
```
------
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": "memorydb:*",
"Resource": "*"
},
{
"Effect": "Allow",
"Action": "iam:CreateServiceLinkedRole",
"Resource": "arn:aws-cn:iam::*:role/aws-service-role/memorydb.amazonaws.com/AWSServiceRoleForMemoryDB",
"Condition": {
"StringLike": {
"iam:AWSServiceName": "memorydb.amazonaws.com"
}
}
}
]
}
```
------
Além disso, você pode criar políticas do IAM personalizadas para conceder permissões para ações de API do MemoryDB. Você pode anexar essas políticas personalizadas a usuários ou grupos do IAM que exijam essas permissões.
## Atualizações do MemoryDB para AWS políticas gerenciadas
Veja detalhes sobre as atualizações das políticas AWS gerenciadas do MemoryDB desde que esse serviço começou a rastrear essas alterações. Para receber alertas automáticos sobre alterações feitas nesta página, inscreva-se no feed de RSS na página Document History (Histórico do documento) do MemoryDB.
| Alteração | Descrição | Data |
| --- | --- | --- |
| [AWS política gerenciada: Memória DBService RolePolicy](#security-iam-awsmanpol-memorydbServiceRolePolicy): adicionar uma política | Memory DBService RolePolicy adicionou a permissão para memorydb:. ReplicateMultiRegionClusterData Essa permissão permite que o perfil vinculado ao serviço replique dados para clusters de várias regiões do MemoryDB. | 12/01/2024 |
| [AmazonMemoryDBFullAcesso](#iam.identitybasedpolicies.predefinedpolicies-fullaccess): adicionar uma política | O MemoryDB adicionou novas permissões para descrever e listar recursos compatíveis. Essas permissões são necessárias para que o MemoryDB consulte todos os recursos compatíveis em uma conta. | 10/07/2021 |
| [AmazonMemoryDBReadOnlyAccess](#iam.identitybasedpolicies.predefinedpolicies-readonly): adicionar uma política | O MemoryDB adicionou novas permissões para descrever e listar recursos compatíveis. Essas permissões são necessárias para que o MemoryDB crie aplicações baseadas em conta consultando todos os recursos compatíveis em uma conta. | 10/07/2021 |
| O MemoryDB começou a monitorar alterações | Inicialização do serviço | 19/08/2021 |
# Permissões da API do MemoryDB: referência de condições, recursos e ações
Ao configurar [controle de acesso](iam.md#iam.accesscontrol) e escrever políticas de permissões para anexar a uma política do IAM (baseada em identidade ou em recursos), use a tabela a seguir como referência. A tabela lista cada operação de API do MemoryDB e as ações correspondentes para as quais você pode conceder permissões para execução. Você especifica as ações no campo `Action` da política e um valor de recurso no campo `Resource`da política. Salvo indicação em contrário, o recurso é obrigatório. Alguns campos incluem um recurso obrigatório e recursos opcionais. Quando não há ARN de recurso, o recurso na política é um caractere curinga (\$1).
**nota**
Para especificar uma ação, use o prefixo `memorydb:` seguido do nome da operação da API (por exemplo, `memorydb:DescribeClusters`).
Use as barras de rolagem para ver o restante da tabela.
**API do MemoryDB e permissões necessárias para ações**
| Operações da API do MemoryDB | Permissões obrigatórias (ações de API) | Recursos |
| --- | --- | --- |
| [BatchUpdateCluster](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_BatchUpdateCluster.html) | `memorydb:BatchUpdateCluster` | Cluster |
| [CopySnapshot](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_CopySnapshot.html) | `memorydb:CopySnapshot` `memorydb:TagResource` `s3:GetBucketLocation` `s3:ListAllMyBuckets` | Snapshot (origem, destino) \$1 \$1 |
| [CreateCluster](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_CreateCluster.html) | `memorydb:CreateCluster` `memorydb:TagResource` `s3:GetObject` Se você usar o parâmetro `SnapshotArns`, cada membro da lista `SnapshotArns` exigirá sua própria permissão `s3:GetObject` com o ARN `s3` como seu recurso. | Grupo de parâmetros. (Opcional) Cluster, snapshot, IDs de grupo de segurança e grupo de sub-redes `arn:aws:s3:::my_bucket/snapshot1.rdb` Onde*my\$1bucket*/*snapshot1*é um bucket e um snapshot do S3 a partir dos quais você deseja criar o cluster. |
| [CreateParameterGroup](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_CreateParameterGroup.html) | `memorydb:CreateParameterGroup` `memorydb:TagResource` | Grupo de parâmetros |
| [CreateSubnetGroup](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_CreateSubnetGroup.html) | `memorydb:CreateSubnetGroup` `memorydb:TagResource` | Grupo de sub-redes | \$1 |
| [CreateSnapshot](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_CreateSnapshot.html) | `memorydb:CreateSnapshot` `memorydb:TagResource` | Snapshot, cluster |
| [CreateUser](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_CreateUser.html) | `memorydb:CreateUser` `memorydb:TagResource` | Usuário |
| [CreateACL](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_CreateACL.html) | `memorydb:CreateACL` `memorydb:TagResource` | Lista de controle de acesso (ACL) |
| [UpdateCluster](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateCluster.html) | `memorydb:UpdateCluster` | Cluster |
| [DeleteCluster](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DeleteCluster.html) | `memorydb:DeleteCluster` | Cluster. (Opcional) Snapshot |
| [DeleteParameterGroup](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DeleteParameterGroup.html) | `memorydb:DeleteParameterGroup` | Grupo de parâmetros |
| [DeleteSubnetGroup](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DeleteSubnetGroup.html) | `memorydb:DeleteSubnetGroup` | Grupo de sub-redes |
| [DeleteSnapshot](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DeleteSnapshot.html) | `memorydb:DeleteSnapshot` | Instantâneo |
| [DeleteUser](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DeleteUser.html) | `memorydb:DeleteUser` | Usuário |
| [DeleteACL](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DeleteACL.html) | `memorydb:DeleteACL` | ACL |
| [DescribeClusters](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeClusters.html) | `memorydb:DescribeClusters` | Cluster |
| [DescribeEngineVersions](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeEngineVersions.html) | `memorydb:DescribeEngineVersions` | Nenhum ARN de recurso: \$1 |
| [DescribeParameterGroups](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeParameterGroups.html) | `memorydb:DescribeParameterGroups` | Grupo de parâmetros |
| [DescribeParameters](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeParameters.html) | `memorydb:DescribeParameters` | Grupo de parâmetros |
| [DescribeSubnetGroups](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeSubnetGroups.html) | `memorydb:DescribeSubnetGroups` | Grupo de sub-redes | \$1 |
| [DescribeEvents](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeEvents.html) | `memorydb:DescribeEvents` | Nenhum ARN de recurso: \$1 |
| [DescribeClusters](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeClusters.html) | `memorydb:DescribeClusters` | Cluster |
| [DescribeServiceUpdates](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeServiceUpdates.html) | `memorydb:DescribeServiceUpdates` | Nenhum ARN de recurso: \$1 |
| [DescribeSnapshots](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeSnapshots.html) | `memorydb:DescribeSnapshots` | Instantâneo |
| [DescribeUsers](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeUsers.html) | `memorydb:DescribeUsers` | Usuário |
| [DescreverACLs](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeACLs.html) | `memorydb:DescribeACLs` | ACLs |
| [ListAllowedNodeTypeUpdates](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_ListAllowedNodeTypeUpdates.html) | `memorydb:ListAllowedNodeTypeUpdates` | Cluster |
| [ListTags](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_ListTags.html) | `memorydb:ListTags` | (Opcional) cluster, snapshot |
| [UpdateParameterGroup](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateParameterGroup.html) | `memorydb:UpdateParameterGroup` | Grupo de parâmetros |
| [UpdateSubnetGroup](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateSubnetGroup.html) | `memorydb:UpdateSubnetGroup` | Grupo de sub-redes |
| [UpdateCluster](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateCluster.html) | `memorydb:UpdateCluster` | cluster. (Opcional) Grupo de parâmetros, grupo de segurança |
| [UpdateUser](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateUser.html) | `memorydb:UpdateUser` | Usuário |
| [UpdateACL](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateACL.html) | `memorydb:UpdateACL` | ACL |
| [UntagResource](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UntagResource.html) | `memorydb:UntagResource` | (Opcional) Cluster, snapshot |
| [ResetParameterGroup](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_ResetParameterGroup.html) | `memorydb:ResetParameterGroup` | Grupo de parâmetros |
| [FailoverShard](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_FailoverShard.html) | `memorydb:FailoverShard` | cluster, fragmento |
# Registro em log e monitoramento
O monitoramento é uma parte importante da manutenção da confiabilidade, da disponibilidade e do desempenho do MemoryDB e de outras soluções da AWS. A AWS fornece as seguintes ferramentas de monitoramento para observar o MemoryDB, informar quando algo está errado e tomar medidas automáticas quando apropriado:
+ O *Amazon CloudWatch* monitora os recursos da AWS e as aplicações que você executa na AWS em tempo real. Você pode coletar e rastrear métricas, criar painéis personalizados e definir alarmes que o notificam ou que realizam ações quando uma métrica especificada atinge um limite definido. Por exemplo, você pode fazer o CloudWatch acompanhar o uso da CPU ou outras métricas das instâncias do Amazon EC2 e iniciar automaticamente novas instâncias quando necessário. Para obter mais informações, consulte o [Guia do usuário do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/).
+ O *Amazon CloudWatch Logs* permite monitorar, armazenar e acessar seus arquivos de log das instâncias do Amazon EC2, do CloudTrail e de outras fontes. O CloudWatch Logs pode monitorar informações nos arquivos de log e notificar você quando certos limites forem atingidos. É possível também arquivar seus dados de log em armazenamento resiliente. Para obter mais informações, consulte o [Guia do usuário do Amazon CloudWatch Logs](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/).
+ O *AWS CloudTrail* captura chamadas de API e eventos relacionados feitos por sua conta da AWS ou em nome dela e entrega os arquivos de log a um bucket do Amazon S3 especificado por você. Você pode identificar quais usuários e contas chamaram a AWS, o endereço IP de origem no qual as chamadas foram feitas e quando elas ocorreram. Para obter mais informações, consulte o [Guia do usuário do AWS CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/).
# Monitorar o MemoryDB com o Amazon CloudWatch
Você pode monitorar o MemoryDB usando o CloudWatch, que coleta dados brutos e os processa em métricas legíveis praticamente em tempo real. Essas estatísticas são mantidas por 15 meses, de maneira que você possa acessar informações históricas e ter uma perspectiva melhor de como o aplicativo web ou o serviço está se saindo. Você também pode definir alarmes que observam determinados limites e enviam notificações ou realizam ações quando esses limites são atingidos. Para obter mais informações, consulte o [Guia do usuário do Amazon CloudWatch](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/).
As seções a seguir listam as métricas e dimensões do MemoryDB.
**Topics**
+ [
# Métricas em nível de host
](metrics.HostLevel.md)
+ [
# Métricas para MemoryDB
](metrics.memorydb.md)
+ [
# Quais métricas devo monitorar?
](metrics.whichshouldimonitor.md)
+ [
# Escolher estatísticas e períodos de métricas
](metrics.ChoosingStatisticsAndPeriods.md)
+ [
# Monitoramento das métricas do CloudWatch
](cloudwatchmetrics.md)
# Métricas em nível de host
O namespace `AWS/MemoryDB` inclui as seguintes métricas em nível de host para nós individuais.
**Consulte também**
+ [Métricas para MemoryDB](metrics.memorydb.md)
| Métrica | Descrição | Unidade |
| --- | --- | --- |
| CPUUtilization | A percentagem de utilização da CPU para o host inteiro. Como o Valkey e o Redis OSS são de thread único, recomendamos que você monitore a métrica EngineCPUUtilization, para nós com quatro ou mais vCPUs. | Percentual |
| FreeableMemory | A quantidade de memória livre disponível no host. Esse número é derivado da memória em RAM e dos buffers que o sistema operacional relata como passíveis de liberação. | Bytes |
| NetworkBytesIn | O número de bytes que o host leu da rede. | Bytes |
| NetworkBytesOut | O número de bytes enviados em todas as interfaces de rede pela instância. | Bytes |
| NetworkPacketsIn | O número de pacotes recebidos em todas as interfaces de rede pela instância. Essa métrica identifica o volume de tráfego de entrada em termos do número de pacotes em uma única instância. | Contagem |
| NetworkPacketsOut | O número de pacotes enviados em todas as interfaces de rede pela instância. Essa métrica identifica o volume de tráfego de saída em termos do número de pacotes em uma única instância. | Contagem |
| NetworkBandwidthInAllowanceExceeded | Número de pacotes moldados porque a largura de banda agregada de entrada excedeu o máximo para a instância. | Contagem |
| NetworkConntrackAllowanceExceeded | Número de pacotes moldados porque o monitoramento da conexão excedeu o máximo para a instância e não foi possível estabelecer novas conexões. Isso pode resultar em perda de pacotes para tráfego indo para a instância ou vindo da instância | Contagem |
| NetworkBandwidthOutAllowanceExceeded | Número de pacotes moldados porque a largura de banda agregada de saída excedeu o máximo para a instância. | Contagem |
| NetworkPacketsPerSecondAllowanceExceeded | Número de pacotes moldados porque o valor bidirecional de pacotes por segundo excedeu o máximo para a instância. | Contagem |
| NetworkMaxBytesIn | A intermitência máxima por segundo de bytes recebidos em cada minuto. | Bytes |
| NetworkMaxBytesOut | A intermitência máxima por segundo de bytes transmitidos em cada minuto. | Bytes |
| NetworkMaxPacketsIn | A intermitência máxima por segundo de pacotes recebidos em cada minuto. | Contagem |
| NetworkMaxPacketsOut | A intermitência máxima por segundo de pacotes transmitidos em cada minuto. | Contagem |
| SwapUsage | A quantidade de troca usada no host. | Bytes |
# Métricas para MemoryDB
O namespace `AWS/MemoryDB` inclui as métricas a seguir.
Com exceção de `ReplicationLag`, `EngineCPUUtilization`, `SuccessfulWriteRequestLatency` e `SuccessfulReadRequestLatency` essas métricas são derivadas do comando **info** do Valkey e Redis OSS. Cada métrica é calculada no nível do nó.
Para conferir a documentação completa do comando **INFO**, consulte [INFO](http://valkey.io/commands/info).
**Consulte também:**
+ [Métricas em nível de host](metrics.HostLevel.md)
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/pt_br/memorydb/latest/devguide/metrics.memorydb.html)
A seguir estão agregações de determinados tipos de comandos, derivados de : **info commandstats**. A seção commandstats fornece estatísticas com base no tipo de comando, incluindo o número de chamadas.
Para conferir uma lista completa dos comandos disponíveis, consulte [comandos](https://valkey.io/commands).
| Métrica | Descrição | Unidade |
| --- | --- | --- |
| EvalBasedCmds | O número total de comandos para comandos baseados em avaliação. Deriva da estatística commandstats, somando eval e evalsha. | Contagem |
| GeoSpatialBasedCmds | O número total de comandos para comandos baseados em dados geoespaciais. É derivado da estatística commandstats. Ele é derivado somando todos o tipos de comandos geo: geoadd, geodist, geohash, geopos, georadius, e georadiusbymember. | Contagem |
| GetTypeCmds | O número total de comandos do tipo read-only. É derivado da estatística commandstats, somando todos os comandos do tipo read-only (get, hget, scard, lrange, etc.) | Contagem |
| HashBasedCmds | O número total de comandos baseados em hash. É derivado da estatística commandstats, somando todos os comandos que atuam em um ou mais hashes (hget, hkeys, hvals, hdel, etc.). | Contagem |
| HyperLogLogBasedCmds | O número total de comandos baseados em HyperLogLog. É derivado da estatística commandstats, somando todos os comandos do tipo pf (pfadd, pfcount, pfmerge, etc.). | Contagem |
| JsonBasedCmds | O número total de comandos que são baseados em JSON. Deriva da estatística commandstats, somando todos os comandos que atuam em um ou mais objetos de documento JSON. | Contagem |
| KeyBasedCmds | O número total de comandos baseados em chave. É derivado da estatística commandstats, somando todos os comandos que atuam em uma ou mais chaves em várias estruturas de dados (del, expire, rename, etc.). | Contagem |
| ListBasedCmds | O número total de comandos baseados em lista. É derivado da estatística commandstats, somando todos os comandos que atuam em uma ou mais listas (lindex, lrange, lpush, ltrim, etc.). | Contagem |
| PubSubBasedCmds | O número total de comandos para a funcionalidade pub/sub. Deriva da estatística commandstats, somando todos os comandos usados para a funcionalidade pub/sub: psubscribe, publish, pubsub, punsubscribe, subscribe e unsubscribe. | Contagem |
| SearchBasedCmds | O número total de comandos de pesquisa e índice secundário, incluindo comandos de leitura e gravação. Deriva da estatística commandstats, somando todos os comandos de pesquisa que atuam em índices secundários. | Contagem |
| SearchBasedGetCmds | Número total de comandos somente leitura secundários de índice e pesquisa. Deriva da estatística commandstats, somando todos os comandos get de pesquisa e índice secundário. | Contagem |
| SearchBasedSetCmds | Número total de comandos de gravação secundários de índice e pesquisa. Deriva da estatística commandstats, somando todos os comandos set de pesquisa e índice secundário. | Contagem |
| SearchNumberOfIndexes | Número total de índices. | Contagem |
| SearchNumberOfIndexedKeys | Número total de chaves indexadas. | Contagem |
| SearchTotalIndexSize | Memória (bytes) usada por todos os índices. | Bytes |
| SetBasedCmds | O número total de comandos que são baseados em conjuntos. É derivado da estatística commandstats, somando todos os comandos que atuam em um ou mais conjuntos (scard, sdiff, sadd, sunion, etc.). | Contagem |
| SetTypeCmds | O número total de tipos de comando write. É derivado da estatística commandstats, somando todos os tipos de comando mutative que operam em dados (set, hset, sadd, lpop, etc.) | Contagem |
| SortedSetBasedCmds | O número total de comandos que são classificados com base em conjuntos. É derivado da estatística commandstats, somando todos os comandos que atuam em um ou mais conjuntos classificados (zcount, zrange, zrank, zadd, etc.). | Contagem |
| StringBasedCmds | O número total de comandos baseados em string. É derivado da estatística commandstats, somando todos os comandos que atuam em uma ou mais strings (strlen, setex, setrange, etc.). | Contagem |
| StreamBasedCmds | O número total de comandos que são baseados em fluxo. É derivado da estatística commandstats, somando todos os comandos que atuam em um ou mais tipos de dados de fluxos (xrange, xlen, xadd, xdel, etc.). | Contagem |
# Quais métricas devo monitorar?
As seguintes métricas do CloudWatch oferecem uma boa visão do desempenho do MemoryDB. Na maioria dos casos, recomendamos que você defina alarmes do CloudWatch para essas métricas para poder tomar medidas corretivas antes que problemas de performance ocorram.
**Topics**
+ [
## CPUUtilization
](#metrics-cpu-utilization)
+ [
## EngineCPUUtilization
](#metrics-engine-cpu-utilization)
+ [
## SwapUsage
](#metrics-swap-usage)
+ [
## Evictions
](#metrics-evictions)
+ [
## CurrConnections
](#metrics-curr-connections)
+ [
## Memória
](#metrics-memory)
+ [
## Rede
](#metrics-network)
+ [
## Latência
](#metrics-latency)
+ [
## Replicação
](#metrics-replication)
## CPUUtilization
Essa é uma métrica em nível de host relatada como uma porcentagem. Para obter mais informações, consulte [Métricas em nível de host](metrics.HostLevel.md).
Para tipos de nós menores com 2 vCPUs ou menos, use a métrica `CPUUtilization ` para monitorar a workload.
De modo geral, sugerimos que você defina o limite para 90% da CPU disponível. Como o Valkey e o Redis OSS têm thread único, o valor efetivo do limite deve ser calculado como uma fração da capacidade total do nó. Por exemplo, suponha que você esteja usando um tipo de nó com dois núcleos. Nesse caso, o limite para CPUUtilization seria 90/2 ou 45%. Para saber o número de núcleos (vCPUs) que seu tipo de nó possui, consulte [Precificação do MemoryDB](https://aws.amazon.com/memorydb/pricing/?p=ps).
Você precisará determinar seu próprio limite, com base no número de núcleos no nó que está usando. Se você exceder esse limite e sua workload principal for de solicitações de leitura, escale seu cluster adicionando réplicas de leitura. Se a workload principal for proveniente de solicitações de gravação, recomendamos que você adicione mais fragmentos para distribuir a workload de gravação em mais nós primários.
**dica**
Em vez de usar a métrica ao nível do host `CPUUtilization`, talvez você possa usar a métrica `EngineCPUUtilization`, que informa a porcentagem de uso no núcleo do mecanismo Valkey ou Redis OSS. Para ver se essa métrica está disponível em seus nós e para obter mais informações, consulte [Métricas para MemoryDB](https://docs.aws.amazon.com/memorydb/latest/devguide/metrics.memorydb.html).
Para tipos de nós maiores com 4 vCPUs ou mais, talvez você queira usar a métrica `EngineCPUUtilization`, que informa a porcentagem de uso no núcleo do mecanismo Valkey ou Redis OSS. Para ver se essa métrica está disponível em seus nós e para obter mais informações, consulte [Métricas para MemoryDB](https://docs.aws.amazon.com/memorydb/latest/devguide/metrics.memorydb.html).
## EngineCPUUtilization
Para tipos de nós maiores com 4 vCPUs ou mais, talvez você queira usar a métrica `EngineCPUUtilization`, que informa a porcentagem de uso no núcleo do mecanismo Valkey ou Redis OSS. Para ver se essa métrica está disponível em seus nós e para obter mais informações, consulte [Métricas para MemoryDB](https://docs.aws.amazon.com/memorydb/latest/devguide/metrics.memorydb.html).
## SwapUsage
Esta é uma métrica em nível de host relatada em bytes. Para obter mais informações, consulte [Métricas em nível de host](metrics.HostLevel.md).
Se a métrica `FreeableMemory` do CloudWatch estiver próxima de 0 (ou seja, abaixo de 100 MB), ou se a métrica `SwapUsage` for maior que a métrica `FreeableMemory`, isso poderá indicar que há um nó sob uso intenso da memória.
## Evictions
Essa é uma métrica de mecanismo. Recomendamos que você determine seu próprio limite de alarme para essa métrica com base nas necessidades do seu aplicativo.
## CurrConnections
Essa é uma métrica de mecanismo. Recomendamos que você determine seu próprio limite de alarme para essa métrica com base nas necessidades do seu aplicativo.
Um número crescente de *CurrConnections* pode indicar um problema em seu aplicativo; você precisará investigar o comportamento do aplicativo para resolver esse problema.
## Memória
A memória é um aspecto central do Valkey e do Redis OSS. Compreender a utilização da memória do seu cluster é necessário para evitar a perda de dados e acomodar o crescimento futuro do seu conjunto de dados. Estatísticas sobre a utilização de memória de um nó estão disponíveis na seção de memória do comando [INFO](https://valkey.io/commands/info).
## Rede
Um dos fatores determinantes para a capacidade de largura de banda da rede do cluster é o tipo de nó selecionado. Para obter mais informações sobre a capacidade de rede de seu nó, consulte [Precificação do Amazon MemoryDB](https://aws.amazon.com/memorydb/pricing/).
## Latência
As métricas de latência `SuccessfulWriteRequestLatency` e `SuccessfulReadRequestLatency` medem o tempo total que o mecanismo do MemoryDB para Valkey leva para responder a uma solicitação.
**nota**
Valores inflados para as métricas `SuccessfulWriteRequestLatency` e `SuccessfulReadRequestLatency` podem ocorrer ao usar o pipeline do Valkey com CLIENT REPLY habilitado no cliente do Valkey. A criação de pipeline do Valkey é uma técnica para melhorar o desempenho emitindo vários comandos ao mesmo tempo, sem esperar pela resposta de cada comando individual. Para evitar valores inflados, recomendamos configurar seu cliente do Redis para gerar comandos do pipeline com [CLIENT REPLY OFF](https://valkey.io/commands/client-reply/).
## Replicação
O volume de dados que está sendo replicado é visível através da métrica `ReplicationBytes`. Você pode monitorar o `MaxReplicationThroughput` em relação ao throughput da capacidade de replicação. Recomenda-se adicionar mais fragmentos ao atingir o throughput máximo da capacidade de replicação.
`ReplicationDelayedWriteCommands` também pode indicar se a workload está excedendo o throughput da capacidade máxima de replicação. Para obter mais informações sobre a replicação no MemoryDB, consulte [Entendendo a replicação do MemoryDB](https://docs.aws.amazon.com/memorydb/latest/devguide/replication.html)
# Escolher estatísticas e períodos de métricas
Embora o CloudWatch permita que você escolha qualquer estatística e período para cada métrica, nem todas as combinações são úteis. Por exemplo, as estatísticas Average, Minimum e Maximum para CPUUtilization são úteis, mas a estatística Sum não é.
Todas as amostras do MemoryDB são publicadas por um período de 60 segundos para cada nó individual. Em qualquer período de 60 segundos, uma métrica de nó conterá apenas uma única amostra.
# Monitoramento das métricas do CloudWatch
O MemoryDB e o CloudWatch são integrados para que você possa reunir uma variedade de métricas. Você pode monitorar essas métricas usando o CloudWatch.
**nota**
Os seguintes exemplos requerem ferramentas de linha de comando do CloudWatch. Para mais informações sobre o CloudWatch e para baixar as ferramentas do desenvolvedor, consulte a [página de produto do CloudWatch](https://aws.amazon.com/cloudwatch).
Os procedimentos a seguir mostram como usar o CloudWatch para coletar estatísticas de espaço de armazenamento de um cluster para a última hora.
**nota**
Os valores `StartTime` e `EndTime` fornecidos nos exemplos a seguir são para fins ilustrativos. Verifique se fez a substituição dos valores de hora inicial e final apropriados para seus nós.
Para obter informações sobre os limites do MemoryDB, consulte [limites de serviço daAWS](https://docs.aws.amazon.com/general/latest/gr/aws_service_limits.html#limits_memorydb) para o MemoryDB.
## Monitoramento das métricas do CloudWatch (Console)
**Para reunir estatísticas de utilização da CPU em um cluster**
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. Selecione os nós para os quais você deseja visualizar métricas.
**nota**
Selecionar mais de 20 nós desabilita as métricas de visualização no console.
1. Na página **Clusters** do Management Console da AWS, clique no nome de um ou mais clusters.
A página de detalhes do cluster é exibida.
1. Clique na guia **Nodes** na parte superior da janela.
1. Na guia **Nós** da janela de detalhes, selecione os nós de cache para os quais você deseja visualizar as métricas.
Uma lista das Métricas do CloudWatch disponíveis aparece na parte inferior da janela do console.
1. Clique na métrica **CPU Utilization**.
O console do CloudWatch será aberto, exibindo as métricas selecionadas. Você pode usar as caixas de listagem suspensas **Statistic** e **Period** e a guia **Time Range** para alterar as métricas exibidas.
## Monitoramento das métricas do CloudWatch usando a CLI do CloudWatch
**Para reunir estatísticas de utilização da CPU em um cluster**
+ Use o comando **aws cloudwatch get-metric-statistics** do CloudWatch com os seguintes parâmetros (observe que os horários de início e término são mostrados apenas como exemplos, você precisará substituir seus próprios horários de início e término apropriados):
Para Linux, macOS ou Unix:
```
1. aws cloudwatch get-metric-statistics CPUUtilization \
2. --dimensions=ClusterName=mycluster,NodeId=0002" \
3. --statistics=Average \
4. --namespace="AWS/MemoryDB" \
5. --start-time 2013-07-05T00:00:00 \
6. --end-time 2013-07-06T00:00:00 \
7. --period=60
```
Para Windows:
```
1. mon-get-stats CPUUtilization ^
2. --dimensions=ClusterName=mycluster,NodeId=0002" ^
3. --statistics=Average ^
4. --namespace="AWS/MemoryDB" ^
5. --start-time 2013-07-05T00:00:00 ^
6. --end-time 2013-07-06T00:00:00 ^
7. --period=60
```
## Monitoramento das métricas do CloudWatch usando a API do CloudWatch
**Para reunir estatísticas de utilização da CPU em um cluster**
+ Chame a API do CloudWatch `GetMetricStatistics` com os seguintes parâmetros (observe que os horários de início e término são mostrados apenas como exemplos, você precisará substituir seus próprios horários de início e término apropriados):
+ `Statistics.member.1``=Average`
+ `Namespace``=AWS/MemoryDB`
+ `StartTime``=2013-07-05T00:00:00`
+ `EndTime``=2013-07-06T00:00:00`
+ `Period``=60`
+ `MeasureName``=CPUUtilization`
+ `Dimensions``=ClusterName=mycluster,NodeId=0002`
**Example**
```
1. http://monitoring.amazonaws.com/
2. ?SignatureVersion=4
3. &Action=GetMetricStatistics
4. &Version=2014-12-01
5. &StartTime=2013-07-16T00:00:00
6. &EndTime=2013-07-16T00:02:00
7. &Period=60
8. &Statistics.member.1=Average
9. &Dimensions.member.1="ClusterName=mycluster"
10. &Dimensions.member.2="NodeId=0002"
11. &Namespace=Amazon/memorydb
12. &MeasureName=CPUUtilization
13. &Timestamp=2013-07-07T17%3A48%3A21.746Z
14. &AWS;AccessKeyId=<&AWS; Access Key ID>
15. &Signature=
```
# Monitorar eventos do MemoryDB
Quando ocorrem eventos significativos em um cluster, o MemoryDB envia uma notificação para um tópico específico do Amazon SNS. Exemplos incluem uma falha ao adicionar um nó, êxito ao adicionar um nó, a modificação de um grupo de segurança, e outros. Ao monitorar eventos chave, você pode se manter informado sobre o atual estado dos seus clusters e, dependendo do evento, poderá executar uma ação corretiva.
**Topics**
+ [
# Gerenciamento de notificações do Amazon SNS do MemoryDB
](mdbevents.sns.md)
+ [
# Visualizar eventos do MemoryDB
](mdbevents.viewing.md)
+ [
# Notificações de eventos e o Amazon SNS
](memorydbsns.md)
# Gerenciamento de notificações do Amazon SNS do MemoryDB
Você pode configurar o MemoryDB para enviar notificações sobre eventos importantes do cluster usando o Amazon Simple Notification Service (Amazon SNS). Nestes exemplos, você configurará um cluster com o nome de recurso da Amazon (ARN) de um tópico do Amazon SNS para receber notificações.
**nota**
Esse tópico pressupõe que você tenha se cadastrado no Amazon SNS e configurado e assinado um tópico do Amazon SNS. Para obter informações sobre como fazer isso, consulte o [Guia do desenvolvedor do Amazon Simple Notification Service](https://docs.aws.amazon.com/sns/latest/dg/).
## Adição de um tópico do Amazon SNS
As seções a seguir mostram como adicionar um tópico do Amazon SNS usando o Console da AWS, a AWS CLI, ou a API do MemoryDB.
### Adição de um tópico do Amazon SNS (console)
O procedimento a seguir mostra como adicionar um tópico do Amazon SNS para um cluster.
**nota**
Esse processo também pode ser usado para modificar o tópico do Amazon SNS.
**Para adicionar ou modificar um tópico do Amazon SNS para um cluster (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. Em **Clusters**, escolha o cluster para o qual deseja adicionar ou modificar um ARN de tópico do Amazon SNS.
1. Escolha **Modificar**.
1. Em **Modificar cluster** em **Tópico para notificação do SNS**, escolha o tópico SNS que você deseja adicionar ou escolha **Entrada manual de ARN** e insira o ARN do tópico do Amazon SNS.
1. Escolha **Modificar**.
### Adição de um tópico do Amazon SNS (CLI da AWS)
Para adicionar ou modificar um tópico do Amazon SNS a um cluster, use o comando da AWS CLI `update-cluster`.
O seguinte exemplo de código adiciona um ARN de tópico do Amazon SNS a *my-cluster*.
Para Linux, macOS ou Unix:
```
aws memorydb update-cluster \
--cluster-name my-cluster \
--sns-topic-arn arn:aws:sns:us-east-1:565419523791:memorydbNotifications
```
Para Windows:
```
aws memorydb update-cluster ^
--cluster-name my-cluster ^
--sns-topic-arn arn:aws:sns:us-east-1:565419523791:memorydbNotifications
```
Para obter mais informações, consulte [UpdateCluster](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateCluster.html).
### Adição de um tópico do Amazon SNS (API do MemoryDB)
Para adicionar ou atualizar um tópico do Amazon SNS para um cluster, chame a ação `UpdateCluster` com os seguintes parâmetros:
+ `ClusterName``=my-cluster`
+ `SnsTopicArn``=arn%3Aaws%3Asns%3Aus-east-1%3A565419523791%3AmemorydbNotifications`
Para adicionar ou atualizar um tópico do Amazon SNS para um cluster, chame a ação `UpdateCluster`.
Para obter mais informações, consulte [UpdateCluster](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_UpdateCluster.html).
## Habilitação e desabilitação de notificações do Amazon SNS
Você pode ativar ou desativar notificações para um cluster. Os procedimentos a seguir mostram como desativar notificações do Amazon SNS.
### Habilitação e desabilitação de notificações do Amazon SNS (console)
**Para desabilitar as notificações do Amazon SNS usando o Console de gerenciamento da AWS**
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. Selecione o botão de opções à esquerda do cluster para o qual você deseja modificar a notificação.
1. Escolha **Modificar**.
1. Em **Modify Cluster**, em **Topic for SNS Notification**, escolha *Disable Notifications*.
1. Escolha **Modificar**.
### Habilitação e desabilitação de notificações do Amazon SNS (CLI da AWS)
Para desabilitar notificações do Amazon SNS, use o comando `update-cluster` com os seguintes parâmetros:
Para Linux, macOS ou Unix:
```
aws memorydb update-cluster \
--cluster-name my-cluster \
--sns-topic-status inactive
```
Para Windows:
```
aws memorydb update-cluster ^
--cluster-name my-cluster ^
--sns-topic-status inactive
```
### Habilitação e desabilitação de notificações do Amazon SNS (API do MemoryDB)
Para desabilitar notificações do Amazon SNS, chame a ação `UpdateCluster` com os seguintes parâmetros:
+ `ClusterName``=my-cluster`
+ `SnsTopicStatus``=inactive`
Essa chamada retorna uma saída semelhante à seguinte:
**Example**
```
1. https://memory-db.us-east-1.amazonaws.com/
2. ?Action=UpdateCluster
3. &ClusterName=my-cluster
4. &SnsTopicStatus=inactive
5. &Version=2021-01-01
6. &SignatureVersion=4
7. &SignatureMethod=HmacSHA256
8. &Timestamp=20210801T220302Z
9. &X-Amz-Algorithm=Amazon4-HMAC-SHA256
10. &X-Amz-Date=20210801T220302Z
11. &X-Amz-SignedHeaders=Host
12. &X-Amz-Expires=20210801T220302Z
13. &X-Amz-Credential=
14. &X-Amz-Signature=
```
# Visualizar eventos do MemoryDB
O MemoryDB faz o evento de logs relacionado aos seus clusters, grupos de segurança e grupos de parâmetros. Essas informações incluem a data e a hora do evento, o nome da origem e o tipo de origem do evento, bem como uma descrição do evento. É possível recuperar facilmente eventos do log usando o console do MemoryDB, o comando `describe-events` da AWS CLI ou a ação `DescribeEvents` da API do MemoryDB.
Os procedimentos a seguir mostram como visualizar todos os eventos do MemoryDB das últimas 24 horas (1440 minutos).
## Visualização de eventos do MemoryDB (console)
O procedimento a seguir exibe eventos usando o console do MemoryDB.
**Para visualizar eventos usando o console do MemoryDB**
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 **Events**.
A tela *Eventos* exibe a listagem de todos os eventos disponíveis. Cada linha da lista representa um evento e exibe a origem do evento, o tipo de evento (como cluster, grupo de parâmetros, acl, grupo de segurança ou grupo de sub-rede), a hora GMT do evento e a descrição do evento.
Usando a opção **Filtro**, você pode especificar se deseja ver todos os eventos ou apenas eventos de um tipo específico na lista de eventos.
## Visualizando eventos do MemoryDB (CLI da AWS)
Para gerar uma lista de eventos do MemoryDB usando a AWS CLI, use o comando `describe-events`. Você pode usar parâmetros opcionais para controlar os tipos de eventos listados, o período de tempo dos eventos listados, o número máximo de eventos a serem listados e muito mais.
O código a seguir lista até 40 eventos de cluster.
```
aws memorydb describe-events --source-type cluster --max-results 40
```
O código a seguir lista todos os eventos nas últimas 24 horas (1440 minutos).
```
aws memorydb describe-events --duration 1440
```
A saída do comando `describe-events` é semelhante a esta.
```
{
"Events": [
{
"Date": "2021-03-29T22:17:37.781Z",
"Message": "Added node 0001 in Availability Zone us-east-1a",
"SourceName": "memorydb01",
"SourceType": "cluster"
},
{
"Date": "2021-03-29T22:17:37.769Z",
"Message": "cluster created",
"SourceName": "memorydb01",
"SourceType": "cluster"
}
]
}
```
Para obter mais informações, como os parâmetros disponíveis e os valores de parâmetros permitidos, consulte [https://docs.aws.amazon.com/cli/latest/reference/memorydb/describe-events.html](https://docs.aws.amazon.com/cli/latest/reference/memorydb/describe-events.html).
## Visualizando eventos do MemoryDB (API do MemoryDB)
Para gerar uma lista de eventos do MemoryDB usando a API do MemoryDB, use a ação `DescribeEvents`. Você pode usar parâmetros opcionais para controlar os tipos de eventos listados, o período de tempo dos eventos listados, o número máximo de eventos a serem listados e muito mais.
O código a seguir lista os 40 eventos de cluster mais recentes.
```
https://memory-db.us-east-1.amazonaws.com/
?Action=DescribeEvents
&MaxResults=40
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&SourceType=cluster
&Timestamp=20210802T192317Z
&Version=2021-01-01
&X-Amz-Credential=
```
O código a seguir lista os eventos de cluster nas últimas 24 horas (1440 minutos).
```
https://memory-db.us-east-1.amazonaws.com/
?Action=DescribeEvents
&Duration=1440
&SignatureVersion=4
&SignatureMethod=HmacSHA256
&SourceType=cluster
&Timestamp=20210802T192317Z
&Version=2021-01-01
&X-Amz-Credential=
```
As ações acima devem produzir uma saída semelhante à seguinte.
```
cluster created
cluster
2021-08-02T18:22:18.202Z
my-memorydb-primary
(...output omitted...)
e21c81b4-b9cd-11e3-8a16-7978bb24ffdf
```
Para obter mais informações, como os parâmetros disponíveis e os valores de parâmetros permitidos, consulte [https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeEvents.html](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeEvents.html).
# Notificações de eventos e o Amazon SNS
O MemoryDB pode publicar mensagens usando o Serviço de notificação simples da Amazon (Amazon Simple Notification Service (SNS)) quando houver eventos significativos em um cluster. Esse atributo pode ser usado para atualizar as listas de servidores em máquinas clientes conectadas a endpoints de nó individuais de um cluster.
**nota**
Para obter mais informações sobre o Amazon Simple Notification Service (SNS), incluindo informações sobre preços e links para a documentação do Amazon SNS, consulte a [página do produto Amazon SNS](https://aws.amazon.com/sns).
As notificações são publicadas em um *tópico* do Amazon SNS especificado. Os seguintes são requisitos para notificações:
+ Apenas um tópico pode ser configurado para notificações do MemoryDB.
+ A conta da AWS que possui o tópico do Amazon SNS deve ser a mesma conta que possui o cluster em que as notificações estão habilitadas.
## Eventos do MemoryDB
Os seguintes eventos do MemoryDB acionam notificações do Amazon SNS:
| Nome do evento | Mensagem | Descrição |
| --- | --- | --- |
| MemoryDB:AddNodeComplete | "Modified number of nodes from %d to %d" | Um nó foi adicionado ao cluster e está pronto para uso. |
| MemoryDB:AddNodeFailed devido a endereços IP livres insuficientes | "Failed to modify number of nodes from %d to %d due to insufficient free IP addresses" | Um nó não pôde ser adicionado porque não há endereços IP suficientes disponíveis. |
| MemoryDB:ClusterParametersChanged | "Updated parameter group for the cluster" Em caso de criar, envie também `"Updated to use a ParameterGroup %s"` | Um ou mais parâmetros de cluster foram alterados. |
| MemoryDB:ClusterProvisioningComplete | "Cluster created." | O provisionamento de um cluster está concluído, e os nós no cluster estão prontos para uso. |
| MemoryDB:ClusterProvisioningFailed devido a estado de rede incompatível | "Failed to create cluster due to incompatible network state. %s" | Foi feita uma tentativa de executar um novo cluster em uma nuvem privada virtual (VPC) inexistente. |
| MemoryDB:ClusterRestoreFailed | "Restore from %s failed for node %s. %s" | O MemoryDB não conseguiu preencher o cluster com os dados do snapshot. Isso pode ser devido a um arquivo de snapshot inexistente no Amazon S3 ou permissões incorretas nesse arquivo. Se você descrever o cluster, o status será `restore-failed`. Você precisará excluir o cluster e começar de novo. Para obter mais informações, consulte [Propagação de um novo cluster com um snapshot criado externamente](snapshots-seeding-redis.md). |
| MemoryDB:ClusterScalingComplete | `"Succeeded applying modification to node type to %s."` | Aumento vertical da escala para cluster concluído com sucesso. |
| MemoryDB:ClusterScalingFailed | `"Failed applying modification to node type to %s."` | A operação de aumentar a escala verticalmente no cluster falhou. |
| MemoryDB:NodeReplaceStarted | "Recovering node %s" | O MemoryDB detectou que o host que está executando um nó está degradado ou inacessível e iniciou a substituição do nó. A entrada de DNS para o nó substituído não é alterada. Na maioria dos casos, você não precisa atualizar a lista de servidores para seus clientes quando esse evento ocorre. No entanto, algumas bibliotecas de clientes podem parar de usar o nó mesmo após o MemoryDB ter substituído o nó. Neste caso, o aplicativo deve atualizar a lista de servidores quando esse evento ocorrer. |
| MemoryDB:NodeReplaceComplete | "Finished recovery for node %s" | O MemoryDB detectou que o host que executa um nó está degradado ou inacessível e concluiu a substituição do nó. A entrada de DNS para o nó substituído não é alterada. Na maioria dos casos, você não precisa atualizar a lista de servidores para seus clientes quando esse evento ocorre. No entanto, algumas bibliotecas de clientes podem parar de usar o nó mesmo após o MemoryDB ter substituído o nó. Neste caso, o aplicativo deve atualizar a lista de servidores quando esse evento ocorrer. |
| MemoryDB:CreateClusterComplete | "Cluster created" | O cluster foi criado com sucesso. |
| MemoryDB:CreateClusterFailed | "Failed to create cluster due to unsuccessful creation of its node(s)." e da "Deleting all nodes belonging to this cluster." | O cluster não foi criado. |
| MemoryDB:DeleteClusterComplete | "Cluster deleted." | A exclusão de um cluster e todos os nós associados foi concluída. |
| MemoryDB:FailoverComplete | `"Failover to replica node %s completed"` | O failover para um nó de réplica foi bem-sucedido. |
| MemoryDB:NodeReplacementCanceled | "The replacement of node %s which was scheduled during the maintenance window from start time: %s, end time: %s has been canceled" | Um nó no seu cluster que estava programado para substituição já não está programado para substituição. |
| MemoryDB:NodeReplacementRescheduled | "The replacement in maintenance window for node %s has been re-scheduled from previous start time: %s, previous end time: %s to new start time: %s, new end time: %s" | Um nó no seu cluster previamente programado para substituição foi reprogramado para substituição durante a nova janela descrita na notificação. Para obter informações sobre quais ações você pode realizar, consulte [Substituição de nós](nodes.nodereplacement.md). |
| MemoryDB:NodeReplacementScheduled | "The node %s is scheduled for replacement during the maintenance window from start time: %s to end time: %s" | Um nó no seu cluster está programado para substituição durante a janela descrita na notificação. Para obter informações sobre quais ações você pode realizar, consulte [Substituição de nós](nodes.nodereplacement.md). |
| MemoryDB:RemoveNodeComplete | "Removed node %s" | Um nó foi removido do cluster. |
| MemoryDB:SnapshotComplete | "Snapshot %s succeeded for node %s" | Um snapshot foi concluído com sucesso. |
| MemoryDB:SnapshotFailed | "Snapshot %s failed for node %s" | O snapshot falhou. Consulte os eventos do cluster para obter mais detalhes sobre a causa. Se você descrever o snapshot, consulte [DescribeSnapshots](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeSnapshots.html), o status será `failed`. |
# Registrar em log chamadas de API do MemoryDB com o AWS CloudTrail
O MemoryDB é integrado ao AWS CloudTrail, um serviço que fornece um registro das ações realizadas por um usuário, perfil ou serviço da AWS no MemoryDB. O CloudTrail captura todas as chamadas de API para o MemoryDB como eventos, incluindo as chamadas feitas pelo console do MemoryDB e as chamadas de código para operações de API do MemoryDB. Se você criar uma trilha, poderá habilitar a entrega contínua de eventos do CloudTrail para um bucket do Amazon S3, incluindo eventos do MemoryDB. Se você não configurar uma trilha, ainda poderá visualizar os eventos mais recentes no console do CloudTrail em **Histórico de eventos**. Usando as informações coletadas pelo CloudTrail, é possível determinar a solicitação feita para o MemoryDB, o endereço IP do qual a solicitação foi feita, quem fez a solicitação, quando ela foi feita, além de outros detalhes.
Para saber mais sobre o CloudTrail, consulte o [AWS CloudTrailGuia do usuário](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/).
## Informações do MemoryDB no CloudTrail
O CloudTrail é habilitado em sua conta AWS ao criá-la. Quando ocorre uma atividade no MemoryDB, ela é registrada em um evento do CloudTrail com outros eventos de serviço da AWS em **Histórico de eventos**. É possível visualizar, pesquisar e baixar eventos recentes em sua AWS conta. Para obter mais informações, consulte [Visualização de eventos com o histórico de eventos do CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/view-cloudtrail-events.html).
Para um registro contínuo de eventos em sua conta da AWS, incluindo eventos para o MemoryDB, crie uma trilha. Uma trilha permite que o CloudTrail entregue arquivos de log a um bucket do Amazon S3. Por padrão, ao criar uma trilha no console, ela é aplicada a todas as regiões da . A trilha registra em log eventos de todas as regiões na partição da AWS e entrega os arquivos de log para o bucket do Amazon S3 especificado por você. Além disso, é possível configurar outros AWS serviços para melhor analisar e agir de acordo com dados coletados do evento nos logs CloudTrail. Para obter mais informações, consulte:
+ [Visão Geral para Criar uma Trilha](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-create-and-update-a-trail.html)
+ [Serviços e integrações com suporte no CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-aws-service-specific-topics.html#cloudtrail-aws-service-specific-topics-integrations)
+ [Configurando Notificações Amazon SNS para CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/getting_notifications_top_level.html)
+ [Receber arquivos de log do CloudTrail de várias regiões](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/receive-cloudtrail-log-files-from-multiple-regions.html) e [receber arquivos de log do CloudTrail de várias contas](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-receive-logs-from-multiple-accounts.html)
Todas as ações do MemoryDB são registradas em log pelo CloudTrail. Por exemplo, as chamadas às ações `CreateCluster`, `DescribeClusters` e `UpdateCluster` geram entradas nos arquivos de log do CloudTrail.
Cada entrada de log ou evento contém informações sobre quem gerou a solicitação. As informações de identidade ajudam a determinar:
+ Se a solicitação foi feita com credenciais de usuário-raiz ou usuário do IAM.
+ Se a solicitação foi feita com credenciais de segurança temporárias de uma função ou de um usuário federado.
+ Se a solicitação foi feita por outro AWS serviço.
Para obter mais informações, consulte o [Elemento userIdentity do CloudTrail](https://docs.aws.amazon.com/awscloudtrail/latest/userguide/cloudtrail-event-reference-user-identity.html).
## Noções básicas das entradas do arquivo de log do MemoryDB
Uma trilha é uma configuração que permite a entrega de eventos como arquivos de log a um bucket Amazon S3 especificado. Os arquivos de log CloudTrail contêm uma ou mais entradas de log. Um evento representa uma única solicitação de qualquer origem e inclui informações sobre a ação solicitada, a data e a hora da ação, os parâmetros de solicitação e assim por diante. Os arquivos de log do CloudTrail não são um rastreamento de pilha ordenada das chamadas de API pública. Dessa forma, eles não são exibidos em uma ordem específica.
O exemplo a seguir mostra uma entrada de log do CloudTrail que demonstra a ação `CreateCluster`.
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "IAMUser",
"principalId": "EKIAUAXQT3SWDEXAMPLE",
"arn": "arn:aws:iam::123456789012:user/john",
"accountId": "123456789012",
"accessKeyId": "AKIAIOSFODNN7EXAMPLE",
"userName": "john"
},
"eventTime": "2021-07-10T17:56:46Z",
"eventSource": "memorydb.amazonaws.com",
"eventName": "CreateCluster",
"awsRegion": "us-east-1",
"sourceIPAddress": "192.0.2.01",
"userAgent": "aws-cli/2.2.29 Python/3.9.6 Darwin/19.6.0 source/x86_64 prompt/off command/memorydb.create-cluster",
"requestParameters": {
"clusterName": "memorydb-cluster",
"nodeType": "db.r6g.large",
"subnetGroupName": "memorydb-subnet-group",
"aCLName": "open-access"
},
"responseElements": {
"cluster": {
"name": "memorydb-cluster",
"status": "creating",
"numberOfShards": 1,
"availabilityMode": "MultiAZ",
"clusterEndpoint": {
"port": 6379
},
"nodeType": "db.r6g.large",
"engineVersion": "6.2",
"enginePatchVersion": "6.2.6",
"parameterGroupName": "default.memorydb-redis6",
"parameterGroupStatus": "in-sync",
"subnetGroupName": "memorydb-subnet-group",
"tLSEnabled": true,
"aRN": "arn:aws:memorydb:us-east-1:123456789012:cluster/memorydb-cluster",
"snapshotRetentionLimit": 0,
"maintenanceWindow": "tue:06:30-tue:07:30",
"snapshotWindow": "09:00-10:00",
"aCLName": "open-access",
"dataTiering": "false",
"autoMinorVersionUpgrade": true
}
},
"requestID": "506fc951-9ae2-42bb-872c-98028dc8ed11",
"eventID": "2ecf3dc3-c931-4df0-a2b3-be90b596697e",
"readOnly": false,
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "123456789012",
"eventCategory": "Management"
}
```
O exemplo a seguir mostra uma entrada de log do CloudTrail que demonstra a ação `DescribeClusters`. Observe que, para todas as chamadas Describe e List do MemoryDB (`Describe*` e `List*`), a seção `responseElements` é removida e aparece como `null`.
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "IAMUser",
"principalId": "EKIAUAXQT3SWDEXAMPLE",
"arn": "arn:aws:iam::123456789012:user/john",
"accountId": "123456789012",
"accessKeyId": "AKIAIOSFODNN7EXAMPLE",
"userName": "john"
},
"eventTime": "2021-07-10T18:39:51Z",
"eventSource": "memorydb.amazonaws.com",
"eventName": "DescribeClusters",
"awsRegion": "us-east-1",
"sourceIPAddress": "192.0.2.01",
"userAgent": "aws-cli/2.2.29 Python/3.9.6 Darwin/19.6.0 source/x86_64 prompt/off command/memorydb.describe-clusters",
"requestParameters": {
"maxResults": 50,
"showShardDetails": true
},
"responseElements": null,
"requestID": "5e831993-52bb-494d-9bba-338a117c2389",
"eventID": "32a3dc0a-31c8-4218-b889-1a6310b7dd50",
"readOnly": true,
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "123456789012",
"eventCategory": "Management"
}
```
O exemplo a seguir mostra uma entrada de log do CloudTrail que registra uma ação `UpdateCluster`.
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "IAMUser",
"principalId": "EKIAUAXQT3SWDEXAMPLE",
"arn": "arn:aws:iam::123456789012:user/john",
"accountId": "123456789012",
"accessKeyId": "AKIAIOSFODNN7EXAMPLE",
"userName": "john"
},
"eventTime": "2021-07-10T19:23:20Z",
"eventSource": "memorydb.amazonaws.com",
"eventName": "UpdateCluster",
"awsRegion": "us-east-1",
"sourceIPAddress": "192.0.2.01",
"userAgent": "aws-cli/2.2.29 Python/3.9.6 Darwin/19.6.0 source/x86_64 prompt/off command/memorydb.update-cluster",
"requestParameters": {
"clusterName": "memorydb-cluster",
"snapshotWindow": "04:00-05:00",
"shardConfiguration": {
"shardCount": 2
}
},
"responseElements": {
"cluster": {
"name": "memorydb-cluster",
"status": "updating",
"numberOfShards": 2,
"availabilityMode": "MultiAZ",
"clusterEndpoint": {
"address": "clustercfg.memorydb-cluster.cde8da.memorydb.us-east-1.amazonaws.com",
"port": 6379
},
"nodeType": "db.r6g.large",
"engineVersion": "6.2",
"EnginePatchVersion": "6.2.6",
"parameterGroupName": "default.memorydb-redis6",
"parameterGroupStatus": "in-sync",
"subnetGroupName": "memorydb-subnet-group",
"tLSEnabled": true,
"aRN": "arn:aws:memorydb:us-east-1:123456789012:cluster/memorydb-cluster",
"snapshotRetentionLimit": 0,
"maintenanceWindow": "tue:06:30-tue:07:30",
"snapshotWindow": "04:00-05:00",
"autoMinorVersionUpgrade": true,
"DataTiering": "false"
}
},
"requestID": "dad021ce-d161-4365-8085-574133afab54",
"eventID": "e0120f85-ab7e-4ad4-ae78-43ba15dee3d8",
"readOnly": false,
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "123456789012",
"eventCategory": "Management"
}
```
O exemplo a seguir mostra uma entrada de log do CloudTrail que demonstra a ação `CreateUser`. Observe que, para chamadas do MemoryDB que contêm dados confidenciais, esses dados serão editados no evento correspondente do CloudTrail, conforme mostrado na seção `requestParameters` abaixo.
```
{
"eventVersion": "1.08",
"userIdentity": {
"type": "IAMUser",
"principalId": "EKIAUAXQT3SWDEXAMPLE",
"arn": "arn:aws:iam::123456789012:user/john",
"accountId": "123456789012",
"accessKeyId": "AKIAIOSFODNN7EXAMPLE",
"userName": "john"
},
"eventTime": "2021-07-10T19:56:13Z",
"eventSource": "memorydb.amazonaws.com",
"eventName": "CreateUser",
"awsRegion": "us-east-1",
"sourceIPAddress": "192.0.2.01",
"userAgent": "aws-cli/2.2.29 Python/3.9.6 Darwin/19.6.0 source/x86_64 prompt/off command/memorydb.create-user",
"requestParameters": {
"userName": "memorydb-user",
"authenticationMode": {
"type": "password",
"passwords": [
"HIDDEN_DUE_TO_SECURITY_REASONS"
]
},
"accessString": "~* &* -@all +@read"
},
"responseElements": {
"user": {
"name": "memorydb-user",
"status": "active",
"accessString": "off ~* &* -@all +@read",
"aCLNames": [],
"minimumEngineVersion": "6.2",
"authentication": {
"type": "password",
"passwordCount": 1
},
"aRN": "arn:aws:memorydb:us-east-1:123456789012:user/memorydb-user"
}
},
"requestID": "ae288b5e-80ab-4ff8-989a-5ee5c67cd193",
"eventID": "ed096e3e-16f1-4a23-866c-0baa6ec769f6",
"readOnly": false,
"eventType": "AwsApiCall",
"managementEvent": true,
"recipientAccountId": "123456789012",
"eventCategory": "Management"
}
```
# Validação de conformidade para MemoryDB
Auditores externos avaliam a segurança e a conformidade do MemoryDB como parte de vários programas de conformidade da AWS. Isso inclui:
+ Padrão de Segurança de Dados do Setor de Cartões de Pagamento (PCI DSS). Para obter mais informações, consulte [PCI DSS](https://aws.amazon.com/compliance/pci-dss-level-1-faqs/).
+ Contrato de Parceria Comercial da Lei de Responsabilidade e Portabilidade de Seguro Saúde (HIPAA BAA). Para obter mais informações, consulte [Conformidade com a HIPAA](https://aws.amazon.com/compliance/hipaa-compliance).
+ Controles de Sistema e Organização (SOC) 1, 2 e 3. Para obter mais informações, consulte [SOC](https://aws.amazon.com/compliance/soc-faqs).
+ Programa Federal de Gerenciamento de Riscos e Autorizações (Federal Risk and Authorization Management Program, FedRAMP) Moderado. Para obter mais informações, consulte [FedRAMP](https://aws.amazon.com/compliance/services-in-scope/FedRAMP/).
+ ISO/IEC 27001:2013, 27017:2015, 27018:2019, and ISO/IEC 9001:2015. Para obter mais informações, consulte as [certificações e os serviços ISO e CSA STAR da AWS](https://aws.amazon.com/compliance/iso-certified/).
Para obter uma lista dos serviços da AWS no escopo de programas de conformidade específicos, consulte [Serviços da AWS no escopo por programa de conformidade](https://aws.amazon.com/compliance/services-in-scope/).
É possível baixar relatórios de auditoria de terceiros usando o AWS Artifact. Para obter mais informações, consulte [Baixar relatórios no AWS Artifact](https://docs.aws.amazon.com/artifact/latest/ug/downloading-documents.html).
Sua responsabilidade de conformidade ao usar o MemoryDB é determinada pela confidencialidade de seus dados, pelos objetivos de conformidade de sua empresa e pelas leis e regulamentos aplicáveis. A 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.
+ [Recursos de conformidade da AWS](https://aws.amazon.com/compliance/resources/): essa coleção de manuais e guias pode ser aplicada a seu setor e local.
+ [Avaliação de recursos com regras](https://docs.aws.amazon.com/config/latest/developerguide/evaluate-config.html) no *Guia do desenvolvedor AWS Config*: AWS Config avalia a conformidade das configurações de seus recursos com práticas internas, diretrizes do setor e regulamentos.
+ [AWS Security Hub CSPM](https://docs.aws.amazon.com/securityhub/latest/userguide/what-is-securityhub.html): esse serviço da AWS fornece uma visão abrangente do estado de sua segurança na AWS que ajuda você a verificar sua conformidade com padrões e práticas recomendadas de segurança do setor.
+ [AWS Audit Manager](https://docs.aws.amazon.com/audit-manager/latest/userguide/what-is.html): esse serviço da AWS ajuda a auditar continuamente o uso da AWS para simplificar a forma como você gerencia os riscos e a conformidade com regulamentos e padrões do setor.
# Segurança da infraestrutura no MemoryDB
Como um serviço gerenciado, o MemoryDB é protegido pelos procedimentos de segurança de rede global da AWS descritos no whitepaper [Amazon Web Services: Overview of Security Processes](https://d0.awsstatic.com/whitepapers/Security/AWS_Security_Whitepaper.pdf).
Você usa chamadas de API publicadas na AWS para acessar o MemoryDB por meio da rede. Os clientes devem oferecer suporte a Transport Layer Security (TLS) 1.2 ou posterior. Recomendamos usar o TLS 1.3 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 suporte a 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 você pode 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.
# 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 |
# Atualizações de serviço no MemoryDB
O MemoryDB monitora automaticamente sua frota de clusters e nós para aplicar atualizações de serviço à medida que elas são disponibilizadas. Normalmente, você configura uma janela de manutenção predefinida para que o MemoryDB possa aplicar essas atualizações. No entanto, em alguns casos, você pode achar que essa abordagem é muito rígida e que provavelmente restringirá os fluxos de negócios.
Com [Atualizações de serviço no MemoryDB](#service-updates), é possível controlar quando e quais atualizações são aplicadas. Também é possível monitorar o andamento dessas atualizações dos clusters do MemoryDB selecionados em tempo real.
# Gerenciamento das atualizações de serviços
As atualizações de serviços do MemoryDB são liberadas regularmente. Se você tiver um ou mais clusters qualificados para essas atualizações de serviço, receberá notificações por e-mail, SNS, Personal Health Dashboard (PHD) e CloudWatch eventos da Amazon quando as atualizações forem lançadas. As atualizações também são exibidas na página **Atualizações de serviços** no console do Atualizações de serviços. Usando este painel, é possível visualizar todas as atualizações de serviço e os status em relação à sua frota do MemoryDB.
Você controla quando aplicar uma atualização antes do início da atualização automática. É altamente recomendável que você aplique qualquer atualização do tipo **atualização de segurança** o mais rápido possível para garantir que seu MemoryDB esteja sempre com os patches de segurança atuais. up-to-date
As seguintes seções analisam essas opções em detalhes.
**Topics**
+ [
## Visão geral da manutenção gerenciada e das atualizações de serviço do Amazon MemoryDB
](#managing-updates-maintenance)
## Visão geral da manutenção gerenciada e das atualizações de serviço do Amazon MemoryDB
Atualizamos frequentemente nossa frota do MemoryDB, com patches e upgrades aplicados a instâncias de forma contínua. Fazemos isso de duas formas:
1. Manutenção gerenciada contínua.
1. Atualizações de serviço.
Essas atualizações de serviço e manutenções são necessárias para aplicar upgrades que fortalecem a segurança, a confiabilidade e o desempenho operacional.
A manutenção gerenciada contínua acontece de tempos em tempos e diretamente nas janelas de manutenção, sem exigir nenhuma ação de sua parte. É importante observar que as janelas de manutenção são obrigatórias para todos os clientes e não há opção de não aderir a esse serviço. É altamente recomendável evitar atividades críticas ou importantes durante essas janelas de manutenção estabelecidas. Além disso, esteja ciente de que atualizações críticas não podem ser ignoradas para garantir a segurança e o desempenho ideal do sistema.
As atualizações de serviço oferecem flexibilidade para que você as aplique por conta própria. Elas têm um horário programado e podem ser movidas para a janela de manutenção para serem aplicadas por nós após o vencimento da data prevista.
Você pode gerenciar as atualizações aplicando-as o mais rápido possível ou substituindo os nós, já que as atualizações são aplicadas automaticamente durante a substituição. Não haverá atividade de atualização durante as janelas de manutenção futuras se as atualizações já tiverem sido aplicadas a todos os nós anteriores.
### Atualizações de serviço
[Atualizações de serviço no MemoryDB](service-updates.md) permitem aplicar determinadas atualizações de serviço a seu critério. Essas atualizações podem ser dos seguintes tipos: patches de segurança ou pequenas atualizações de software. Essas atualizações ajudam a fortalecer a segurança, a confiabilidade e o desempenho operacional dos seus clusters.
O valor dessas atualizações de serviço é que é possível controlar quando aplicar a atualização (por exemplo, você pode adiar a aplicação de atualizações de serviço quando há um evento comercial importante que exija disponibilidade 24 horas por dia, 7 dias por semana dos clusters do MemoryDB).
Se você tiver um ou mais clusters qualificados para essas atualizações de serviço, receberá notificações por e-mail, [Amazon SNS](mdbevents.sns.md), Dashboard e eventos [AWS Health da CloudWatch ](https://docs.aws.amazon.com/health/latest/ug/getting-started-health-dashboard.html) [Amazon](monitoring-cloudwatch.md) quando as atualizações forem lançadas. As atualizações também são exibidas na página **Atualizações de serviços** no console do Atualizações de serviços. Usando este painel, é possível visualizar todas as atualizações de serviço e os status em relação à sua frota do MemoryDB.
Você controla quando aplicar uma atualização antes do início da atualização automática. É altamente recomendável que você aplique qualquer atualização do tipo atualização de segurança o mais rápido possível para garantir que seu MemoryDB esteja sempre com os patches de segurança atuais. up-to-date
O cluster pode fazer parte de diferentes atualizações de serviço. A maioria das atualizações não exige que você as aplique separadamente. A aplicação de uma atualização ao cluster marcará as outras atualizações como concluídas, sempre que aplicável. Talvez seja necessário aplicar várias atualizações ao mesmo cluster separadamente caso o status não mude para “concluído” automaticamente.
#### Impacto e tempo de inatividade das atualizações de serviço
Quando você ou o Amazon MemoryDB aplica uma atualização de serviço a um ou mais clusters do MemoryDB, ela é aplicada a no máximo um nó por vez em cada fragmento até que todos os clusters selecionados sejam atualizados. Os nós que estão sendo atualizados apresentarão um tempo de inatividade de alguns segundos, enquanto o restante do cluster continuará fornecendo tráfego.
+ Não haverá alteração na configuração do cluster.
+ Você verá um atraso em suas CloudWatch métricas que se recuperarão o mais rápido possível.
**Como a substituição de um nó afeta a aplicação?** – Para nós do MemoryDB, o processo de substituição foi projetado para garantir durabilidade e disponibilidade. Para clusters de nó único do MemoryDB, este cria dinamicamente uma réplica, restaura os dados de nossos componentes de durabilidade e, depois, faz failover para ela. Para grupos de replicação que consistem em vários nós, o MemoryDB substitui as réplicas existentes e sincroniza os dados de nossos componentes de durabilidade com as novas réplicas. O MemoryDB só é Multi-AZ quando há mais de um nó, portanto, nesse cenário, a substituição do primário aciona um failover em uma réplica de leitura. As substituições planejadas de nós são concluídas enquanto o cluster continua atendendo às solicitações de escrita recebidas. Se houver apenas um nó, o MemoryDB substituirá o primário e, depois, sincronizará os dados de nossos componentes de durabilidade. O nó primário não fica disponível durante esse período, levando a uma interrupção mais longa da gravação.
**Quais práticas recomendadas devo seguir para uma experiência de substituição tranquila e para minimizar a perda de dados?** – No MemoryDB, os dados são altamente duráveis e a perda de dados não é esperada, mesmo em implementações de um único nó. No entanto, é recomendável implementar estratégias Multi-AZ e de backup para minimizar as chances de perda no caso improvável de falha. Para uma experiência de substituição tranquila, tentamos substituir apenas nós suficientes do mesmo cluster por vez para manter o cluster estável. É possível provisionar réplicas primárias e de leitura em diferentes zonas de disponibilidade ativando a Multi-AZ. Nesse caso, quando um nó é substituído, o perfil principal fará failover para uma réplica no fragmento. Esse fragmento agora atenderá ao tráfego e os dados serão restaurados a partir de seus componentes de durabilidade. Se a configuração incluir somente uma réplica primária e uma única por fragmento, recomendamos adicionar outras réplicas antes da aplicação de patches. Isso evitará a redução da disponibilidade durante o processo de aplicação de patches. Recomendamos programar a substituição durante um período com baixo tráfego de gravação de entrada.
**Quais práticas recomendadas de configuração do cliente devo seguir para minimizar a interrupção da aplicação durante a manutenção?** – No MemoryDB, a configuração do modo de cluster está sempre ativada, o que fornece a melhor disponibilidade durante operações gerenciadas ou não gerenciadas. Os endpoints individuais dos nós de réplica podem ser usados para todas as operações de leitura. No MemoryDB, o failover automático está sempre ativado no cluster, o que significa que o nó primário pode mudar. Portanto, a aplicação deve confirmar o perfil do nó e atualizar todos os endpoints de leitura para garantir que você não esteja causando uma carga excessiva no primário. Da mesma forma, evite sobrecarregar as réplicas com solicitações de leitura durante as janelas de manutenção. Uma forma de fazer isso é garantir que você tenha pelo menos duas réplicas de leitura para evitar qualquer interrupção de leitura durante a manutenção.
É importante testar os aplicativos cliente para confirmar se eles estão em conformidade com o protocolo Redis/Valkey Cluster e se as solicitações podem ser redirecionadas entre os nós adequadamente. É aconselhável implementar estratégias de recuo e repetição para evitar sobrecarregar os nós do MemoryDB durante as atividades de manutenção e substituição.
**Reagendamento**: você pode adiar a atualização do serviço alterando a [janela de manutenção](maintenance-window.md). A atualização programada só será aplicada ao cluster se a data programada corresponder à janela de manutenção do cluster. Depois que você alterar a janela de manutenção e a data programada tiver passado, a atualização do serviço será reprogramada para a janela recém-especificada nas semanas seguintes. Você receberá uma nova notificação uma semana antes da nova data.
A segurança em AWS é uma responsabilidade compartilhada. É altamente recomendável aplicar a atualização o quanto antes.
**Optar por não receber atualizações de serviço**: você pode optar por não receber uma atualização de serviço verificando o valor do atributo “Data de início da atualização automática”. Se o valor do atributo “Data de início da atualização automática” de uma atualização de serviço for definido, o MemoryDB agendará a atualização do serviço para todos os clusters restantes para a próxima janela de manutenção, e não será possível optar por não atualizar. Ainda assim, se você aplicar a atualização de serviço aos clusters restantes antes da janela de manutenção, o MemoryDB não reaplicará a atualização do serviço durante a janela de manutenção. Para obter mais informações, consulte [Como aplicar as atualizações de serviço](applying-updates.md).
**Por que as atualizações de serviço não podem ser aplicadas diretamente pelo MemoryDB durante as janelas de manutenção?** – Observe que o objetivo das atualizações de serviço é oferecer flexibilidade sobre quando aplicá-las. Os clusters que não participam dos programas de [conformidade](memorydb-compliance.md) compatíveis com o MemoryDB podem optar por não aplicar essas atualizações ou por aplicá-las com uma frequência reduzida ao longo do ano. No entanto, é recomendável aplicar as atualizações para manter a conformidade com os regulamentos. Isso vale somente quando o atributo “Data de início da atualização automática” de uma atualização de serviço não está atribuído. Para obter mais informações, consulte [Validação de conformidade para MemoryDB](memorydb-compliance.md).
**Como as atualizações aplicadas na janela de manutenção são diferentes das atualizações de serviço?** – As atualizações aplicadas por meio da manutenção gerenciada contínua são programadas diretamente em suas janelas de manutenção, sem a necessidade de nenhuma ação de sua parte. As atualizações de serviço são programadas e permitem que você controle quando deseja aplicá-las pela “Data de início da atualização automática”. Se ainda não forem aplicadas até essa data, o MemoryDB pode agendá-las na sua janela de manutenção.
### Atualizações da manutenção gerenciada contínua
Essas atualizações são obrigatórias e são aplicadas diretamente nas janelas de manutenção sem a necessidade de nenhuma ação de sua parte. Essas atualizações são distintas das oferecidas pelas atualizações de serviço.
#### Tempo de inatividade e impacto da manutenção contínua
**Quanto tempo demora a substituição de um nó?** – A substituição normalmente é concluída em 30 minutos. A substituição pode levar mais tempo em determinadas configurações de instância e padrões de tráfego.
**Como a substituição de um nó afeta a aplicação?** – As atualizações contínuas de manutenção gerenciada são aplicadas da mesma forma que as “atualizações de serviço”, por meio da substituição de nós. Consulte mais detalhes na seção acima Tempo de inatividade e impacto das atualizações de serviço.
**Como gerenciar as substituições de nós por conta própria?** – Você tem a opção de gerenciar essas substituições a qualquer momento antes da janela agendada para a substituição do nó. Se optar por gerenciar a substituição por conta própria, você poderá realizar várias ações, dependendo do seu caso de uso.
+ [Substitua um nó no cluster por um ou mais fragmentos](nodes.nodereplacement.md): você pode usar [backup e restauração](snapshots-restoring.md) ou aumentar e, depois, reduzir a escala horizontalmente para [substituir os nós](cluster-resharding-online.md).
+ [Altere sua janela de manutenção](maintenance-window.md): além disso, você pode alterar a janela de manutenção do cluster. Para alterar sua janela de manutenção para um horário mais conveniente posteriormente, você pode usar a [UpdateCluster API](clusters.modify.md), a [CLI do cluster de atualização](https://docs.aws.amazon.com/cli/latest/reference/memorydb/update-cluster.html) ou clicar em [Modificar](clusters.modify.md) no console de gerenciamento do MemoryDB. Depois de alterar a janela de manutenção, o MemoryDB agendará a manutenção do nó durante a janela que você acabou de especificar.
Para ver isso na prática, digamos que seja quinta-feira, 9/11, às 15h e a próxima janela de manutenção seja sexta-feira, 10/11, às 17h. Aqui estão três cenários:
+ Você altera a janela de manutenção para sexta-feira, às 16h (após a data e hora atual e antes da próxima janela de manutenção programada). O nó será substituído na sexta-feira, 10 de novembro, 16h.
+ Você altera a janela de manutenção para sábado, 16h (após a data e hora atual e a próxima janela de manutenção programada). O nó será substituído no sábado, 11 de novembro, 16h.
+ Você altera a janela de manutenção para quarta-feira, 16h (dia da semana anterior à data e hora atual). O nó será substituído na próxima quarta-feira, 15 de novembro, 16h.
Para obter mais informações, consulte [Gerenciamento da manutenção](maintenance-window.md).
Observe que os nós em diferentes clusters de diferentes regiões podem ser substituídos ao mesmo tempo, desde que a janela de manutenção desses clusters seja a mesma.
**Como posso saber mais sobre as próximas substituições programadas?** - Você deve receber uma notificação de saúde no painel AWS de saúde. Além disso, você pode encontrar o status de diferentes atualizações de serviços com a DescribeServiceUpdates API. Observe que nos esforçamos para notificar proativamente os clientes sobre substituições previsíveis. No entanto, em casos excepcionais, como falhas imprevisíveis, pode haver substituições sem aviso prévio.
**Posso alterar a manutenção programada em um horário mais adequado?** – Sim, você pode adiar a manutenção programada para um horário mais adequado alterando a [janela de manutenção](https://docs.aws.amazon.com/memorydb/latest/APIReference/API_DescribeServiceUpdates.html).
**Por que estão sendo feitas essas substituições de nós?** – Essas substituições são necessárias para aplicar as atualizações obrigatórias de software ao host subjacente. As atualizações ajudam a fortalecer nossa segurança, confiabilidade e desempenho operacional.
**Essas substituições afetam meus nós em várias zonas de disponibilidade e clusters de diferentes regiões ao mesmo tempo?** – As substituições podem ser executadas em várias zonas de disponibilidade ou regiões em paralelo, dependendo da janela de manutenção dos clusters.
# Como aplicar as atualizações de serviço
Será possível começar a aplicar as atualizações de serviços à sua frota desde o momento em que as atualizações tiverem um status **disponível**. As atualizações de serviço são cumulativas. Em outras palavras, qualquer atualização que você ainda não tiver aplicado serão incluídas na sua atualização mais recente.
Se uma atualização de serviço tiver a atualização automática habilitada, será possível optar por não realizar nenhuma ação quando ela estiver disponível. O MemoryDB agendará a aplicação da atualização durante a janela de manutenção dos clusters após a **Data de início da atualização automática**. Você receberá notificações relacionadas a cada etapa da atualização.
**nota**
É possível aplicar somente as atualizações de serviço que tenham um status **disponível** ou **programado**.
Para obter mais informações sobre a análise e a aplicação de qualquer atualização específica ao serviço aos clusters do MemoryDB aplicáveis, consulte [Aplicação de atualizações de serviço usando o console](#applying-updates-console-APIReferenceconsole).
Quando uma nova atualização de serviço está disponível para um ou mais dos seus clusters do MemoryDB, você pode usar o console do MemoryDB, a API ou aplicar AWS CLI a atualização. As seções a seguir explicam as opções que você pode usar para aplicar as atualizações.
## Aplicação de atualizações de serviço usando o console
Para visualizar a lista de atualizações de serviço disponíveis, além de outras informações, acesse a página **Atualizações de serviço** no 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, selecione **Atualizações de serviço**.
Em **Atualizações de serviço**, é possível visualizar o seguinte:
+ **Nome da atualização de serviço**: o nome exclusivo da atualização de serviço
+ **Atualização de serviço**: fornece informações detalhadas sobre a atualização de serviço
+ **Data de início da atualização automática**: se esse atributo for definido, o MemoryDB começará a programar seus clusters para serem atualizados automaticamente nas janelas de manutenção apropriadas após essa data. Você receberá notificações com antecedência sobre a janela exata de manutenção programada, que pode não ser a imediata após a **data de início da atualização automática**. Você ainda pode aplicar a atualização aos seus clusters sempre que quiser. Se o atributo não estiver definido, a atualização do serviço não estará habilitada para atualização automática e o MemoryDB não atualizará seus clusters automaticamente.
Em **Status da atualização do cluster**, é possível visualizar uma lista de clusters nos quais a atualização do serviço não foi aplicada ou acabou de ser aplicada recentemente. Para cada cluster, é possível visualizar o seguinte:
+ **Nome do cluster**: o nome do cluster
+ **Nós atualizados:** a proporção de nós individuais dentro de um cluster específico que foram atualizados ou permanecem disponíveis para a atualização de serviço específica.
+ **Tipo de atualização**: o tipo da atualização de serviço, que é **security-update** (atualização-de-segurança) ou **engine-update** (atualização-de-mecanismo)
+ **Status**: o status da atualização de serviço no cluster, que é um dos seguintes:
+ *disponível*: a atualização está disponível para clusters de requisito.
+ *em andamento*: a atualização está sendo aplicada a esse cluster.
+ *programada*: a data de atualização foi programada.
+ *concluída*: a atualização foi aplicada com êxito. O cluster com status completo será exibido por 7 dias após sua conclusão.
Se você escolheu qualquer um ou todos os clusters com o status **disponível** ou **programado** e, em seguida, escolheu **Aplicar agora**, a atualização começará a ser aplicada nesses clusters.
## Aplicando as atualizações do serviço usando o AWS CLI
Depois de receber a notificação de que há atualizações de serviços disponíveis, você poderá inspecioná-las e aplicá-las usando a AWS CLI:
+ Para recuperar uma descrição das atualizações de serviços disponíveis, execute o seguinte comando:
`aws memorydb describe-service-updates --status available`
Para obter mais informações, consulte [describe-service-updates](https://docs.aws.amazon.com/cli/latest/reference/memorydb/describe-service-updates.html).
+ Para aplicar uma atualização de serviço em uma lista de clusters, execute o seguinte comando:
`aws memorydb batch-update-cluster --service-update ServiceUpdateNameToApply=sample-service-update --cluster-names cluster-1 cluster2`
Para obter mais informações, consulte [batch-update-cluster](https://docs.aws.amazon.com/cli/latest/reference/memorydb/batch-update-cluster.html).