Perguntas frequentes do Amazon ElastiCache

O ElastiCache sem servidor é uma opção que permite começar a usar um cache em menos de um minuto sem provisionamento de infraestrutura ou planejamento de capacidade. O ElastiCache sem servidor elimina a necessidade de um demorado planejamento de capacidade ao monitorar continuamente a computação, a memória e a utilização da rede de um cache, para que ele possa escalar instantaneamente para atender à demanda sem tempo de inatividade ou degradação da performance. O ElastiCache sem servidor replica automaticamente os dados em várias zonas de disponibilidade (AZs) e fornece aos clientes um contrato de nível de serviço (SLA) com 99,99% de disponibilidade para cada cache. Com o ElastiCache sem servidor, você paga apenas pelos dados que armazena e pelos recursos computacionais que sua aplicação usa. Para começar, crie um cache do ElastiCache Sem Servidor em apenas algumas etapas especificando um nome de cache usando o console, o kit de desenvolvimento do ElastiCache (SDK) ou a AWS Command Line Interface (AWS CLI).

Você pode mover uma workload existente do ElastiCache alterando o endpoint do Valkey, Memcached ou Redis OSS para seu novo endpoint de cache do ElastiCache sem servidor em sua aplicação. Você pode migrar dados existentes do ElastiCache para o ElastiCache sem servidor especificando a localização do Amazon Simple Storage Service (Amazon S3) de um arquivo de backup. Visite nossa documentação do ElastiCache sem servidor para saber mais sobre a migração das suas workloads.

O ElastiCache Serverless é compatível com Valkey 7.2, Memcached versão 1.6.21 e Redis OSS versão 7.0 e superior.

O ElastiCache sem servidor monitora continuamente a memória, a computação e a utilização da rede do seu cache para escalar instantaneamente. O ElastiCache sem servidor é escalável sem tempo de inatividade ou degradação da performance da aplicação, permitindo que o cache aumente a escala verticalmente e inicie a expansão em paralelo, para atender aos requisitos da aplicação na hora certa. Acesse nossa documentação do ElastiCache sem servidor para saber mais sobre escalabilidade.

O ElastiCache sem Servidor armazena automaticamente dados de forma redundante em várias zonas de disponibilidade (AZs) e fornece um Acordo de Nível de Serviço (SLA) com disponibilidade de 99,99% para todos os workloads.

Com o ElastiCache sem servidor, você paga apenas pelos dados que armazena e pela computação que sua aplicação usa. Consulte a página de preços do ElastiCache para saber mais.

Os nós reservados ou instâncias reservadas (IRs) oferecem um desconto significativo sobre o uso sob demanda quando você aceita um compromisso com período de um ou três anos. Com os nós reservados, é possível fazer um pagamento único e adiantado para criar uma reserva de um ou três anos para executar seu cache em uma região específica, além de receber um desconto significativo sobre a cobrança de uso por hora vigente. Existem três tipos de nós reservados: sem pagamento adiantado, pagamento adiantado parcial e pagamento adiantado integral. Esses tipos permitem estabelecer um equilíbrio entre o valor que você paga adiantado e seu preço por hora efetivo.

Os nós reservados oferecem um desconto que se aplica ao uso sob demanda do ElastiCache. O ElastiCache sem servidor não é compatível com nós reservados.

Você pode comprar até 300 nós reservados. Se você quiser executar mais de 300 nós, preencha o formulário de solicitação de nós do ElastiCache.

Compre uma reserva de nó da mesma categoria de nó e da mesma região do nó que você estiver executando no momento e que deseja reservar. Se a compra da reserva for bem-sucedida, o ElastiCache aplicará automaticamente a nova cobrança de uso por hora ao seu nó atual.

As mudanças de preço associadas a um nó reservado são ativadas depois que a solicitação for recebida e enquanto a autorização de pagamento é processada. Você pode acompanhar o status de sua reserva na página AWS Account Activity ou utilizando a API DescribeReservedCacheNodes. Se o pagamento único não for autorizado com sucesso até o período da próxima fatura, o preço descontado não terá efeito.

Quando o período da sua reserva expirar, o nó reservado será alterado para a taxa de uso por hora sob demanda apropriada para a categoria e a região do seu nó.

As APIs do ElastiCache para criar, modificar e excluir nós não fazem distinção entre nós sob demanda e nós reservados para que você possa utilizar ambos sem problemas. Ao calcular sua fatura, nosso sistema aplicará automaticamente suas reservas para que todos os nós qualificados sejam cobrados com a taxa por hora mais econômica de nó de cache reservado.

Cada nó reservado está associado a uma região específica, que é determinada por toda a duração da reserva e não pode ser alterada. Contudo, cada reserva pode ser usada em qualquer uma das zonas de disponibilidade encontradas dentro da região associada.

Não. Não é possível cancelar a reserva de nós, e o pagamento único (se for o caso) não é reembolsável. Você continuará a pagar por hora durante o período de vigência do nó reservado, independentemente da utilização.

Quando você compra um nó reservado com a opção de pagamento adiantado integral, paga por todo o período de vigência do nó reservado em um único pagamento adiantado. Você pode optar por não pagar nada adiantado escolhendo a opção sem pagamento adiantado. O valor total do nó reservado sem pagamento adiantado é distribuído por todas as horas do período de vigência, e você receberá a cobrança por hora do período, independentemente do uso. A opção de pagamento adiantado parcial é híbrido das opções de pagamento adiantado integral e sem pagamento adiantado. Você faz um pequeno pagamento adiantado e é cobrada uma taxa baixa por cada hora do período de vigência, independentemente do uso.

Sim, os nós reservados do ElastiCache oferecem flexibilidade de tamanho em uma família de instâncias (ou família de nós) e na região da AWS. Isso significa que a taxa de nós reservados existentes com desconto será aplicada automaticamente ao uso de todos os tamanhos na mesma família de nós.

O ElastiCache permite configurar a criptografia de dados em repouso usando o AWS Key Management Service (AWS KMS), a criptografia de dados em trânsito usando o Transport Layer Security (TLS), a autenticação usando o AWS Identity and Access Management (IAM) e o controle de acesso à rede com grupos de segurança do Amazon Elastic Compute Cloud (Amazon EC2).

Quando não está usando a Amazon Virtual Private Cloud (Amazon VPC), o ElastiCache permite que você controle o acesso aos seus caches por meio de grupos de segurança de rede. Um grupo de segurança funciona como um firewall, controlando o acesso de rede ao cache. Como padrão, o acesso de rede é desativado para os seus caches. Se você quiser que as aplicações acessem seu cache, habilite explicitamente o acesso de hosts em grupos de segurança do Amazon EC2 específicos.

Você também pode controlar o acesso aos seus recursos do ElastiCache usando a autenticação do IAM. Para mais informações, consulte a documentação de autenticação com o IAM.

O ElastiCache oferece suporte a programas de conformidade como SOC 1, SOC 2, SOC 3, ISO, MTCS, C5, PCI DSS, HIPAA e FedRAMP. Acesse Serviços da AWS no escopo pelo programa de conformidade para ver uma lista atualizada dos programas de conformidade aceitos no momento.

Sim. O programa de conformidade com o PCI da AWS inclui o ElastiCache como um serviço em conformidade com o PCI. Para saber mais, veja os recursos a seguir:

• Conformidade com o ElastiCache
• Página de conformidade com o PCI da AWS

Para ver a lista atual dos programas de conformidade para os quais o ElastiCache está no escopo, consulte Serviços da AWS no escopo pelo programa de conformidade.

Sim, o ElastiCache é um serviço qualificado para a HIPAA e está coberto pelo Business Associate Addendum (BAA – Adendo de associado comercial) da AWS. Isso significa que você pode usar o ElastiCache como ajuda para processar, manter e armazenar informações de saúde protegidas (PHI) e como base para aplicações de saúde.

Não existe custo adicional para usar os recursos de conformidade.

Se você assinou um Business Associate Agreement (BAA – Acordo de associado comercial) com a AWS, poderá usar o ElastiCache para criar aplicações que armazenam e processam HI sob a HIPAA. Se você não tiver um BAA, ou tiver outras dúvidas sobre o uso da AWS para suas aplicações, entre em contato conosco para obter mais informações. 

O programa de conformidade com o FedRAMP da AWS inclui o ElastiCache como um serviço autorizado pelo FedRAMP. Clientes do governo dos EUA e seus parceiros agora podem usar a versão mais recente do ElastiCache para processar e armazenar seus sistemas, dados e workloads de missão crítica e de alto impacto do FedRAMP nas regiões AWS GovCloud (Leste dos EUA) e AWS GovCloud (Oeste dos EUA) e com impacto de nível moderado nas regiões Leste dos EUA (Ohio), Leste dos EUA (Norte da Virgínia), Oeste dos EUA (Norte da Califórnia) e Oeste dos EUA (Oregon).

Para saber mais, veja os recursos a seguir:

• Conformidade com o ElastiCache
• Compatibilidade da AWS com o FedRAMP

Para ver a lista atual dos programas de conformidade para os quais o ElastiCache está no escopo, consulte Serviços da AWS no escopo pelo programa de conformidade.

Há vários benefícios de performance.

O ElastiCache fornece threads de E/S aprimorados que oferecem melhorias significativas no throughput e na latência em escala por meio de multiplexação, descarregamento da camada de apresentação e muito mais. Os threads de E/S aprimorados melhoram a performance usando mais núcleos para processar E/S e se ajustar dinamicamente à workload. O ElastiCache melhora o throughput de clusters habilitados para TLS ao transferir a criptografia para os mesmos threads de E/S aprimorados. Isso permite que o ElastiCache for Valkey ofereça até 100% mais throughput e 50% menos latência P99 do que o ElastiCache versão 7.0 para Redis OSS. Você pode obter mais de um milhão de solicitações por segundo por nó, ou 500 milhões de solicitações por segundo por cluster, em nós r7g.4xlarge ou maiores.

Além disso, a versão 8.0 do ElastiCache para Valkey oferece mais eficiência de memória para clusters baseados em nós com o Modo Cluster mediante o uso de 32 bytes a menos de memória por chave em comparação com a versão 7.2 do ElastiCache para Valkey e a versão 7.1 para Redis OSS. A configuração sem servidor melhorou o desempenho durante o ajuste de escala para 5 milhões de solicitações por segundo por cache em minutos, até 5 vezes mais rápido que o Valkey 7.2, com latência de leitura de microssegundos.

O ElastiCache fornece dois conjuntos diferentes de métricas para medir a utilização da CPU do seu cache, dependendo da sua opção de implantação de cache. Ao usar o ElastiCache sem servidor, você pode monitorar a utilização da CPU com a métrica de Unidades de processamento do ElastiCache (ECPU). O número de ECPUs consumidas por suas solicitações depende do tempo gasto pela vCPU e da quantidade de dados transferidos. Cada leitura e gravação, como os comandos GET e SET do Valkey ou os comandos get e set do Memcached, exigem 1 ECPU para cada quilobyte (KB) de dados transferidos. Alguns comandos que operam em estruturas de dados na memória podem consumir mais tempo de vCPU do que um comando GET ou SET. O ElastiCache calcula o número de ECPUs consumidas com base no tempo de vCPU gasto pelo comando em comparação com uma linha de base do tempo de vCPU gasto por um comando SET ou GET. Se seu comando consumir mais tempo de vCPU e transferir mais dados do que a linha de base de 1 ECPU, o ElastiCache calculará as ECPUs necessárias com base na maior das duas dimensões.

Ao projetar seu próprio cluster, é possível monitorar EngineCPUUtilization e CPUUtilization. A métrica CPUUtilization mede o uso de CPU para a instância (nó) e a métrica EngineCPUUtilization mede o uso no nível de processo do mecanismo. Ambas as métricas, EngineCPUUtilization e CPUUtilization, são necessárias porque o principal processo do mecanismo é single threaded e usa apenas uma CPU entre os vários núcleos de CPU disponíveis em uma instância. Portanto, a métrica CPUUtilization não fornece visibilidade precisa das taxas de uso de CPU no nível de processo. Recomendamos que você use conjuntamente as métricas EngineCPUUtilization e CPUUtilization para ter um entendimento detalhado da utilização da CPU para seus clusters do Valkey.

Ambos os conjuntos de métricas estão disponíveis em todas as regiões da AWS, e você pode acessar essas métricas usando o Amazon CloudWatch ou no console. Além disso, recomendamos que você acesse a documentação para saber mais sobre métricas úteis para monitoramento de performance.

As réplicas de leitura têm duas finalidades:

• Tratamento de falhas
• Escalabilidade de leitura

Quando você executa um cache com uma réplica de leitura, o nó primário atende a solicitações de gravações e leituras. A réplica serve exclusivamente para tráfego de leitura e também está disponível como um modo de espera aquecido caso o sistema primário fique danificado.

Com o ElastiCache sem servidor, as réplicas de leitura são mantidas automaticamente pelo serviço. Ao criar seu próprio cache, há vários cenários em que a implantação de uma ou mais réplicas de leitura para um determinado nó primário pode fazer sentido. Razões comuns para implementar uma réplica de leitura incluem:

• Escalabilidade além da capacidade computacional ou de E/S de um único nó primário para cargas de trabalho com muita leitura: esse excesso de tráfego de leitura pode ser direcionado para uma ou mais réplicas de leitura.
• Servindo tráfego de leitura enquanto o primário está indisponível: se o seu nó primário não puder aceitar solicitações de E/S (por exemplo, devido à suspensão de E/S para backups ou manutenção agendada), você poderá direcionar o tráfego de leitura para suas réplicas de leitura. Para esse caso de uso, lembre-se de que os dados na réplica de leitura podem estar desatualizados, já que a instância principal está indisponível. A réplica de leitura também pode ser usada no preparo para reiniciar um nó principal com falha.

Cenários de proteção de dados: a hipótese improvável de falha do nó primário ou da indisponibilidade da zona de disponibilidade onde reside o nó primário, você pode promover uma réplica de leitura em uma outra zona de disponibilidade para que ela se torne o novo nó primário.

Você pode se conectar a uma réplica de leitura da mesma forma que se conectaria a um nó de cache primário. Se você tem várias réplicas de leitura, seu aplicativo terá de determinar como o tráfego de leitura será distribuído entre elas. Veja aqui mais detalhes:

• Clusters do Valkey ou Redis OSS (modo de cluster desabilitado), use os endpoints de nós individuais para operações de leitura. (Na API/CLI, eles são chamados de endpoints de leitura.)
• Os clusters do Valkey ou Redis OSS (modo de cluster ativado) usam o endpoint de configuração do cluster para todas as operações. Você ainda pode ler a partir de endpoints de nós individuais. (Na API e na CLI, eles são chamados de endpoints de leitura.)

O ElastiCache permite criar até 5 (cinco) réplicas de leitura para um determinado nó de cache primário.

Caso ocorra um failover, todas as réplicas de leitura associadas e disponíveis devem automaticamente retomar a replicação após a conclusão do failover (recebendo atualizações da réplica de leitura recém-promovida).

As atualizações para um nó de cache primário serão automaticamente replicadas a qualquer réplica de leitura associada. Contudo, com a tecnologia de replicação assíncrona do Valkey ou Redis OSS, uma réplica de leitura pode ficar defasada em relação a seu nó de cache primário por vários motivos. Os principais motivos incluem:

• O volume de E/S de gravação para o nó de cache primário excede a taxa na qual as alterações podem ser aplicadas à réplica de leitura.
• Partições de rede ou latência entre o nó de cache primário e uma réplica de leitura.

As réplicas de leitura estão sujeitas aos pontos fortes e fracos da replicação do Valkey ou Redis OSS. Se você está usando réplicas de leitura, deve estar ciente do potencial de defasagem entre uma réplica de leitura e seu nó de cache primário, ou “inconsistência”. O ElastiCache emite uma métrica para ajudar você a entender a inconsistência.

Uma réplica de leitura é cobrada como um nó de cache padrão e com as mesmas taxas. Assim como um nó de cache padrão, a taxa por “hora de nó de cache” de uma réplica de leitura é determinada pela classe do nó de cache da réplica de leitura: visite a página de preços do ElastiCache para obter o preço atualizado. Você não será cobrado pela transferência de dados que ocorrer na replicação de dados entre seu nó de cache principal e a réplica de leitura. A cobrança por uma réplica de leitura será iniciada assim que a réplica de leitura for criada com êxito (quando o status for listado como ativo). A réplica de leitura continuará sendo cobrada com taxas por hora de nó de cache do ElastiCache padrão, até que você emita um comando para excluí-la.

O failover iniciado é compatível com o ElastiCache, para que você possa retomar as operações de cache o mais rápido possível. Ao ocorrer um failover, o ElastiCache inverte o registro DNS do seu nó de cache para apontar para a réplica de leitura, que, por sua vez, é promovida e se torna o novo nó primário. Aconselhamos a seguir as práticas recomendadas e implementar a repetição da conexão do nó de cache na camada de aplicação. Normalmente, do início ao fim, as etapas de um a cinco abaixo são concluídas em seis minutos.

Estes são eventos de failover automático, listados na ordem de ocorrência:

1. Mensagem do grupo de replicação: API Test Failover chamou pelo grupo de nós <node-group-id>
2. Mensagem do cluster de cache: failover do nó primário <primary-node-id> para o nó de réplica <node-id> concluído
3. Mensagem do grupo de replicação: failover do nó primário <primary-node-id> para o nó de réplica <node-id> concluído
4. Mensagem do cluster de cache: recuperando nós de cache <node-id>
5. Mensagem do cluster de cache: recuperação dos nós de cache <node-id> concluída

Não. A réplica de leitura só pode ser provisionada em uma zona de disponibilidade igual ou diferente da mesma região do nó de cache primário. No entanto, é possível usar o Datastore global para trabalhar com replicação totalmente gerenciada, rápida, confiável e focada em segurança entre as regiões da AWS. Com esse atributo, é possível criar cluster de réplica de leitura entre regiões para que o ElastiCache habilite leituras de baixa latência e recuperação de desastres entre as regiões da AWS.

Sim. É possível adicionar ou remover réplicas de leitura em um ou mais fragmentos em um ambiente de cluster. O cluster permanece online e atende a solicitações de E/S durante essa operação.

O Multi-AZ é um atributo que permite que você execute em uma configuração com maior disponibilidade ao projetar seu próprio cache do ElastiCache. Todos os caches do ElastiCache sem servidor são executados automaticamente em uma configuração Multi-AZ. Um grupo de replicação do ElastiCache consiste em um primário e até cinco réplicas de leitura. Se o Multi-AZ for habilitado, então pelo menos uma réplica de leitura será exigida por nó primário. Durante determinados tipos de manutenção planejada, ou no improvável caso de uma falha no nó do ElastiCache ou na zona de disponibilidade, o ElastiCache detectará automaticamente a falha de um principal, selecionará uma réplica de leitura e a promoverá a novo principal. O ElastiCache também propaga as alterações de DNS da réplica de leitura promovida. Assim, se o seu aplicativo gravar no endpoint do nó primário, nenhuma alteração de endpoint será necessária.

Os principais benefícios da execução do ElastiCache no modo Multi-AZ são maior disponibilidade e menor necessidade de administração. Quando o ElastiCache é executado em uma configuração Multi-AZ, seus caches se tornam elegíveis para o SLA de disponibilidade de 99,99%. Se uma falha de nó primário do ElastiCache ocorrer, o impacto na capacidade de ler e gravar no primário será limitado ao tempo necessário para a conclusão do failover automático. Quando o Multi-AZ é habilitado, o failover do nó do ElastiCache é automático e não exige administração.

Você pode usar o Multi-AZ se utiliza o ElastiCache e tem um grupo de replicação consistindo em um nó primário e uma ou mais réplicas de leitura. Se o nó primário falhar, o ElastiCache detectará automaticamente a falha, selecionará uma das réplicas de leitura disponíveis e a promoverá a novo primário. O ElastiCache propagará as alterações de DNS da réplica promovida. Portanto, o seu aplicativo poderá continuar a gravar no endpoint primário. Além disso, o ElastiCache ativará um novo nó para substituir a réplica de leitura promovida na mesma zona de disponibilidade do principal que apresentou falha. Caso a falha do nó primário tenha sido motivada por uma falha temporária na zona de disponibilidade, a nova réplica será iniciada assim que a zona de disponibilidade for recuperada.

Sim. Observe que o posicionamento do primário e das réplicas na mesma zona de disponibilidade não tornará o grupo de replicação do ElastiCache resiliente a uma falha na zona de disponibilidade.

O ElastiCache executará um failover para uma réplica de leitura caso ocorra um dos seguintes eventos:

• Perda de disponibilidade no AZ da primária
• Perda de conectividade de rede para principal
• Falha de unidade computacional na principal

Se houver mais de uma réplica de leitura, será promovida a que tiver a menor diferença de replicação assíncrona em relação ao nó primário.

Sim, o ElastiCache criará um evento para informá-lo da ocorrência de um failover automático. Você pode usar a API DescribeEvents para retornar informações sobre eventos relacionados ao seu nó do ElastiCache, ou selecionar a seção Events no console de gerenciamento do ElastiCache.

As AZs são projetadas para fornecer conectividade de rede de baixa latência para outras AZs na mesma região. Você pode considerar a definição da arquitetura da sua aplicação e de outros recursos da AWS com redundância em várias zonas de disponibilidade para que a aplicação seja resiliente no caso de uma falha de zona de disponibilidade.

Para obter mais informações sobre o Multi-AZ, consulte a documentação do ElastiCache.

O recurso de backup e restauração permite criar snapshots dos seus caches do ElastiCache for Redis. O ElastiCache armazena os snapshots, permitindo que o usuário os utilize para restaurar caches. Atualmente, isso é compatível com o ElastiCache para Valkey, o ElastiCache para Redis OSS e o Serverless.

A criação de snapshots pode ser útil no caso de perda de dados por falha nos nós ou também no caso improvável de ocorrência de uma falha de hardware. Outro motivo comum para utilizar backups é para fins de arquivamento. Os snapshots são armazenados no Amazon S3.

Sim, você pode exportar seus snapshots do ElastiCache para um bucket S3 autorizado na mesma região do seu cache.

Sim. Primeiro você deve copiar o snapshot em um bucket autorizado do S3 de sua escolha na mesma região e, então, conceder permissões de bucket entre contas para a outra conta.

O ElastiCache fornece espaço de armazenamento para um snapshot gratuitamente para cada cache ativo do ElastiCache. O armazenamento adicional será cobrado com base no espaço consumido pelos snapshots, com USD 0,085/GB por mês (mesmo preço em todas as regiões). A transferência de dados para uso dos snapshots é gratuita.

Quando você exclui um cache do ElastiCache, os seus snapshots manuais são mantidos. Você também poderá criar um snapshot final antes da exclusão do cache. Os snapshots de cache automáticos não são retidos.

O mecanismo do ElastiCache é totalmente compatível com o Valkey ou o Redis OSS, mas também apresenta melhorias que aumentam a performance, a potência e a estabilidade. Algumas das melhorias incluem:

• Mais memória utilizável: agora, você pode alocar com segurança mais memória para a sua aplicação sem correr o risco de aumentar o uso de swap durante sincronizações e snapshots.
• Sincronização improvisada: sincronização mais robusta mediante cargas pesadas e durante a recuperação de desconexões de rede. Além disso, as sincronizações são mais rápidas, pois tanto o primário quanto suas réplicas não usam mais o disco para essa operação.
• Failovers mais estáveis: agora, no caso de um failover, o fragmento se recupera mais rapidamente, pois as réplicas não descarregam mais seus dados para fazerem uma ressincronização completa com o nó primário.

O mecanismo aprimorado é totalmente compatível com o Valkey ou o Redis OSS. Portanto, você poderá usufruir da robustez e estabilidade melhoradas sem precisar alterar o código das aplicações.

Não há cobrança adicional para o uso do mecanismo aprimorado.

Criptografia em trânsito, criptografia em repouso, Valkey AUTH e controle de acesso baseado em perfis (RBAC) são recursos que você pode selecionar ao criar seu cache do ElastiCache para Redis. Se você habilitou a criptografia em trânsito, pode optar por usar o AUTH ou o RBAC para aumentar a segurança e o controle de acesso.

A criptografia em repouso oferece mecanismos para proteger seus dados contra acesso não autorizado. Quando ativado, ele criptografa os seguintes aspectos:

• O disco durante as operações de sincronização, backup e troca
• Backups armazenados no Amazon S3

O ElastiCache oferece criptografia padrão (gerenciada pelo serviço) em repouso, bem como a capacidade de usar suas próprias chaves simétricas do AWS KMS gerenciadas pelo cliente no AWS KMS. Acesse Criptografia em repouso para saber mais.

O recurso de criptografia em trânsito facilita a criptografia das comunicações entre clientes e o ElastiCache, bem como entre os servidores (primário e réplicas de leitura). Leia mais sobre a Criptografia em trânsito do ElastiCache.

Não, o ElastiCache gerencia internamente a expiração e a renovação de certificações. Nenhuma ação de usuário é necessária para a manutenção contínua de certificados.

Não, não há custo adicional para usar a criptografia.

O Datastore global é um atributo do ElastiCache que disponibiliza replicação gerenciada, rápida, confiável e focada na segurança entre regiões. Com ele, você pode fazer gravações no cache em uma região e disponibilizar os dados para leitura em até dois outros clusters de réplica entre regiões. Isso permite leituras de baixa latência e recuperação de desastres entre regiões.

Projetado para aplicações em tempo real com uma presença global, o Datastore global normalmente replica dados entre regiões em menos de um segundo, aumentando a capacidade de resposta de suas aplicações ao fornecer leituras geolocais mais próximas dos usuários finais. No caso raro de uma degradação regional, um dos caches de réplica entre regiões que não apresentar problemas poderá ser promovido a primário com recursos completos de leitura e gravação. Geralmente, depois de iniciada, a promoção é concluída em menos de um minuto, o que permite que as aplicações permaneçam disponíveis.

O Global Datastore é compatível com o ElastiCache versão 7.2 para Valkey e o ElastiCache versão 5.0.6 em diante para Redis OSS.

Você pode fazer a replicação para até duas regiões secundárias dentro de um Datastore global. No caso raro de uma degradação regional, os caches em regiões secundárias podem ser usados para atender a leituras locais de baixa latência e para fazer a recuperação de desastres.

Você pode configurar um Datastore global ao usar um cache atual ou criar um novo que será usado como o primário. Você pode criar um Datastore global com apenas algumas etapas no Console de Gerenciamento do ElastiCache ou ao fazer download do SDK da AWS ou da AWS CLI mais recentes. O Datastore global é compatível com o AWS CloudFormation.

Não, o ElastiCache não promove automaticamente um cluster secundário no caso de degradação de um cluster principal (na região). Você pode iniciar manualmente o failover ao promover um cluster secundário para que ele se torne o primário. Geralmente, o failover e a promoção do cluster secundário são concluídos em menos de um minuto.

O ElastiCache não disponibiliza um SLA para RPO e RTO. O RPO varia com base no atraso da replicação entre regiões e depende da latência de rede entre regiões, bem como do congestionamento do tráfego de rede entre regiões. Geralmente, o RPO do Datastore global é de menos de um segundo. Assim, os dados gravados na região principal ficam disponíveis nas regiões secundárias dentro desse intervalo. Já o RTO do Datastore global é geralmente de menos de um minuto. Depois que o failover de um cluster secundário é iniciado, o ElastiCache normalmente o promove para que ele obtenha recursos completos de leitura e gravação em menos de um minuto.

O ElastiCache não cobra nenhum prêmio pelo uso do Datastore global. Você paga pelos caches primário e secundários no Datastore global e pelo tráfego de transferência de dados entre regiões.

Embora não haja um resposta exata para essa pergunta, com o ElastiCache, você não precisa se preocupar em obter o número de nós exato, pois é possível adicionar ou remover nós posteriormente de maneira muito rápida. Você também pode usar o ElastiCache sem servidor para simplificar a execução de um cache do Memcached altamente disponível. Os dois seguintes aspectos inter-relacionados poderiam ser considerados na escolha da sua configuração inicial:

• A memória total necessária para que os seus dados atinjam a taxa de acertos do cache de destino e
• O número de nós necessários para manter uma performance aceitável da aplicação sem sobrecarregar o back-end de banco de dados no caso de falhas do nó.

A quantidade de memória necessária depende do tamanho do seu conjunto de dados e dos padrões de acesso da aplicação. Para melhorar a tolerância a falhas, quando você tiver uma ideia aproximada da memória total necessária, divida essa memória em nós suficientes para que a aplicação possa sobreviver à perda de um ou dois nós. Por exemplo, se a sua solicitação de memória for de 13 GB, use dois nós cache.m4.large em vez de usar um nó cache.m4.xlarge. É importante que outros sistemas, como bancos de dados, não fiquem sobrecarregados se a taxa de acertos do cache for temporariamente reduzida durante a recuperação de falhas de um ou mais nós. Consulte o Guia do Usuário do ElastiCache para obter mais detalhes.

Sim. Ao criar um cluster ou adicionar nós a um cluster atual, você pode escolher as zonas de disponibilidade para os novos nós. É possível especificar o número de nós solicitada em cada zona de disponibilidade ou selecionar Distribuir nós entre as zonas. Se o cluster estiver na Amazon VPC, os nós podem apenas ser colocados em zonas de disponibilidade que fazem parte do grupo de sub-rede de cache selecionado. Para obter mais detalhes, consulte a documentação do ElastiCache VPC.

É possível executar no máximo 300 nós por região. Caso precise de mais nós, preencha o formulário de solicitação de aumento de limite do ElastiCache.

O serviço irá detectar a falha do nó e reagirá conforme as seguintes etapas automáticas:

• O ElastiCache reparará o nó obtendo novos recursos de serviços, redirecionando o nome de DNS atual do nó para que indique esses novos recursos. Para instalações da Amazon VPC, o ElastiCache garantirá que o nome de DNS e o endereço IP do nó permanecerá o mesmo quando o nós forem recuperados no caso de falha. Para instalações que não forem da Amazon VPC, o ElastiCache garantirá que o nome de DNS de um nó não seja alterado. No entanto, o endereço IP subjacente do nó poderá mudar.
• Caso associe um tópico SNS ao seu cluster, quando o novo nó for configurado e estiver pronto para ser utilizado, o ElastiCache enviará uma notificação SNS para você avisando que a recuperação do nó ocorreu. Assim, você terá a opção de organizar as aplicações para forçar a biblioteca cliente do Memcached a tentar reconectar-se aos nós reparados. Isso poderia ser importante, pois algumas bibliotecas do Memcached encerrarão o uso de um servidor (nó) indefinidamente, caso encontrem erros de comunicação ou esgotamento de tempo limite no servidor especificado.

Você pode adicionar mais nós ao seu cluster do Memcached atual ao usar a opção Add Node, na guia Nodes, para seu cluster de cache no console, ou ao chamar a API ModifyCacheCluster.

O ElastiCache funciona de modo ideal como um front-end para serviços da AWS, como o Amazon RDS e o DynamoDB, disponibilizando latência extremamente baixa para aplicações de alta performance e transferindo parte do volume de solicitações, além de proporcionar uma duradoura resiliência de dados. O serviço também pode ser usado para melhorar a performance da aplicação em conjunto com o Amazon EC2 e o Amazon EMR.

As bibliotecas de clientes do Memcached estão disponíveis para a maioria das linguagens de programação mais conhecidas. Caso encontre algum problema com clientes específicos do Memcached ao utilizar o ElastiCache, entre em contato conosco no fórum da comunidade do ElastiCache.

O ElastiCache não exige bibliotecas de cliente específicas e funciona com bibliotecas de cliente Memcached existentes sem recompilação ou revinculação de aplicações (Memcached 1.4.5 e versões posteriores). Os exemplos incluem libMemcached (C) e bibliotecas baseadas nele (por exemplo, PHP, Perl, Python), spyMemcached (Java) e fauna (Ruby).

A Descoberta Automática é um atributo que poupa tempo e esforço, reduzindo ao mesmo tempo a complexidade de suas aplicações. A Descoberta Automática descobre automaticamente nós de cache por clientes quando eles são adicionados ou removidos de um cluster do ElastiCache. Anteriormente, para processar alterações de associação de cluster os desenvolvedores tinham que atualizar manualmente a lista de endpoints de nó de cache. Dependendo de como a aplicação cliente foi arquitetada, geralmente será necessária uma inicialização de cliente (desligando a aplicação e reiniciando-a), resultando em tempo de inatividade. Por meio da Descoberta Automática, o ElastiCache remove essa complexidade. Com a Descoberta Automática, além de ser compatível com versões anteriores do protocolo Memcached, o ElastiCache fornece aos clientes informações sobre a associação de cluster de cache. Um cliente capaz de processar as informações adicionais se reconfigurará sozinho, sem qualquer inicialização, para usar os nós mais atuais de um cluster do ElastiCache.

Um cluster do ElastiCache pode ser criado com nós que são endereçáveis por meio de endpoints indicados. Com a Descoberta Automática, o cluster do ElastiCache também recebe um endpoint de configuração exclusivo, que é um Registro de DNS válido pela duração do cluster. Esse Registro de DNS contém os Nomes de DNS dos nós que pertencem ao cluster. O ElastiCache garantirá que o endpoint de configuração sempre aponte para, pelo menos, um desses nós de destino. Uma consulta ao nó de destino então retornará endpoints para todos os nós do cluster em questão. Depois disso, você poderá se conectar aos nós do cluster como antes e usar os comandos do protocolo Memcached, como get, set, incr e decr. Para obter mais detalhes, consulte a documentação. Para usar a Descoberta Automática, você precisará de um cliente compatível com a Descoberta Automática. Os clientes de Descoberta Automática para .Net, Java e PHP estão disponíveis para fazer download no console do ElastiCache. Após a inicialização, o cliente determinará automaticamente os atuais membros do cluster do ElastiCache usando o endpoint de configuração. Quando você fizer alterações em seu cluster de cache acrescentando ou removendo nós ou se um nó for substituído mediante falha, o cliente de Descoberta Automática determinará as alterações e você não precisará inicializar seus clientes manualmente.

Para começar a usar, faça download do Cliente de Cluster do ElastiCache selecionando o link “Download ElastiCache Cluster Client”, no console do ElastiCache. Para efetuar o download, você deverá ter uma conta do ElastiCache; se ainda não tiver uma, poderá se cadastrar na página de detalhes do ElastiCache. Depois de efetuar download do cliente, poderá começar a configurar e ativar seu cluster do ElastiCache acessando o console do ElastiCache. Mais detalhes podem ser encontrados na documentação.

Sim, você pode parar de usar a Descoberta Automática a qualquer momento. Você pode desativar a Descoberta Automática ao especificar o modo de operação durante a inicialização do cliente de Cluster do ElastiCache. Além disso, como o ElastiCache continua sendo compatível com o Memcached, você poderá usar qualquer cliente compatível com o protocolo Memcached como antes.

Para aproveitar as vantagens da Descoberta Automática, um cliente capaz de usar a Descoberta Automática deve ser usado para se conectar a um cluster do ElastiCache. Atualmente, o ElastiCache é compatível com clientes capazes de usar a Descoberta Automática para .Net, Java e PHP. Eles podem ser obtidos por download no console do ElastiCache. É possível criar clientes para qualquer outra linguagem ao criar com base nos clientes Memcached conhecidos disponíveis.

Você pode utilizar qualquer Biblioteca de Cliente Memcached e acrescentar suporte para a Descoberta Automática. Se quiser acrescentar ou modificar seu próprio cliente para habilitar a Descoberta Automática, consulte a documentação do conjunto de comandos da Descoberta Automática.

Sim, o, ElastiCache ainda está em conformidade com o protocolo Memcached e não requer que você altere seus clientes. No entanto, para aproveitar o atributo Descoberta Automática, aprimoramos os recursos do cliente Memcached. Se você escolher não usar o Cliente de Cluster do ElastiCache, poderá continuar usando seus próprios clientes ou modificar a biblioteca de seu próprio cliente para compreender o conjunto de comandos da Descoberta Automática.
 

Sim, o mesmo cluster do ElastiCache pode ser conectado através de um cliente compatível com Descoberta Automática e o cliente Memcached tradicional ao mesmo tempo. O ElastiCache permanece 100% em conformidade com o Memcached.

Sim, você pode parar de usar a Descoberta Automática a qualquer momento. Você pode desativar a Descoberta Automática ao especificar o modo de operação durante a inicialização do cliente de Cluster do ElastiCache. Além disso, como o ElastiCache continua sendo compatível com o Memcached, você poderá usar qualquer cliente compatível com o protocolo Memcached como antes.

O ElastiCache permite que você controle se e quando o software compatível com o protocolo do Memcached que está alimentando o seu cluster será atualizado com novas versões compatíveis com o ElastiCache. Isso lhe proporciona a flexibilidade de manter a compatibilidade com versões específicas do Memcached, testar novas versões com seu aplicativo antes de implementá-lo para produção e realizar atualizações de versões de acordo com seus próprios termos e cronogramas. Como as atualizações de versões principais envolvem alguns riscos de compatibilidade, não serão efetuadas automaticamente e devem ser executadas manualmente. Essa abordagem à aplicação de patches de software proporciona a você o controle sobre atualizações de versão, além de transferir o trabalho de aplicação de patches para o ElastiCache. Saiba mais sobre o gerenciamento de versões lendo as perguntas frequentes a seguir. Você também pode consultar o Guia do usuário do ElastiCache. Embora a funcionalidade de gerenciamento de versões de mecanismo tenha sido criada para oferecer o maior controle possível sobre como é feita a aplicação de patches, poderemos aplicar os patches no cluster por você, caso seja identificada alguma vulnerabilidade de segurança no sistema ou no software do cache.

É possível especificar qualquer versão compatível atual (secundária ou primária) ao criar um novo cluster. Se você desejar iniciar a atualização de uma versão de mecanismo compatível, use a opção “Modify” do seu cluster. Especifique a versão que deseja atualizar no campo “Cache Engine Version”. A atualização será aplicada automaticamente e de imediato (se a opção “Applied Immediately” estiver selecionada) ou durante a próxima janela de manutenção agendada para o seu cluster.

Sim. É possível fazer isso ao criar um novo cluster com a nova versão de mecanismo. Você pode direcionar a aplicação de desenvolvimento/preparação para esse cluster, testá-la e decidir se atualiza ou não o cluster original.

Pretendemos oferecer suporte a versões adicionais do Memcached para o ElastiCache, tanto principais quanto secundárias. O número de novos lançamentos de versões compatíveis em um determinado ano poderá variar de acordo com a frequência e o conteúdo dos lançamentos de versão do Memcached e o resultado de uma intensa inspeção do lançamento por nossa equipe de engenharia.

Você pode atualizar seu cluster atual do Memcached usando o processo Modify. Ao atualizar de uma versão mais antiga do Memcached para a versão 1.4.33 ou outra mais recente, verifique se os valores existentes do parâmetro max_chunk_size atendem às condições necessárias do parâmetro slab_chunk_max. Analise os pré-requisitos de atualização.

O ElastiCache fornece threads de E/S aprimorados que oferecem melhorias significativas no throughput e na latência em escala por meio de multiplexação, descarregamento da camada de apresentação e muito mais. Os threads de E/S aprimorados melhoram a performance usando mais núcleos para processar E/S e se ajustar dinamicamente à workload. O ElastiCache melhora o throughput de clusters habilitados para TLS ao transferir a criptografia para os mesmos threads de E/S aprimorados. O ElastiCache (Redis OSS) versão 7.0 introduziu a multiplexação de E/S aprimorada, que combina várias solicitações de clientes em um único canal e melhora a eficiência do thread principal.

No ElastiCache versão 7.1 e superior para Redis OSS , estendemos a funcionalidade aprimorada de threads de E/S para também lidar com a lógica da camada de apresentação. Os threads de E/S aprimorados não apenas leem a entrada do cliente, mas também analisam a entrada em um formato de comando binário, que é então encaminhado ao thread principal para execução, para fornecer ganhos de performance. Com o ElastiCache versão 7.1 para Redis OSS, você pode alcançar até 100% mais throughput e 50% menos latência P99 em comparação com a versão anterior. No r7g.4xlarge ou maior, você pode obter mais de 1 milhão de solicitações por segundo (RPS) por nó.

O ElastiCache fornece dois conjuntos diferentes de métricas para medir a utilização da CPU do seu cache, dependendo da sua opção de implantação de cache. Ao usar o ElastiCache sem servidor, você pode monitorar a utilização da CPU com a métrica de Unidades de processamento do ElastiCache (ECPU). O número de ECPUs consumidas por suas solicitações depende do tempo gasto pela vCPU e da quantidade de dados transferidos. Cada leitura e gravação, como os comandos GET e SET do Redis OSS ou os comandos get e set do Memcached, exigem 1 ECPU para cada quilobyte (KB) de dados transferidos. Alguns comandos do Redis OSS que operam em estruturas de dados na memória podem consumir mais tempo de vCPU do que um comando GET ou SET. O ElastiCache calcula o número de ECPUs consumidas com base no tempo de vCPU gasto pelo comando em comparação com uma linha de base do tempo de vCPU gasto por um comando SET ou GET. Se seu comando consumir mais tempo de vCPU e transferir mais dados do que a linha de base de 1 ECPU, o ElastiCache calculará as ECPUs necessárias com base na maior das duas dimensões.

Ao projetar seu próprio cluster, é possível monitorar EngineCPUUtilization e CPUUtilization. A métrica CPUUtilization mede o uso de CPU para a instância (nó) e a métrica EngineCPUUtilization mede o uso no nível de processo do mecanismo. Ambas as métricas, EngineCPUUtilization e CPUUtilization, são necessárias porque o principal processo do Redis OSS é single threaded e usa apenas uma CPU entre os vários núcleos de CPU disponíveis em uma instância. Portanto, a métrica CPUUtilization não fornece visibilidade precisa das taxas de uso de CPU no nível de processo do mecanismo. Recomendamos usar conjuntamente as métricas EngineCPUUtilization e CPUUtilization para ter um entendimento detalhado da utilização da CPU para seus clusters do Redis OSS.

Ambos os conjuntos de métricas estão disponíveis em todas as regiões da AWS, e você pode acessar essas métricas usando o Amazon CloudWatch ou no console. Além disso, recomendamos que você acesse a documentação para saber mais sobre métricas úteis para monitoramento de performance.

As réplicas de leitura têm duas finalidades no Redis OSS:

• Tratamento de falhas
• Escalabilidade de leitura

Quando você executa um cache com uma réplica de leitura, o nó primário atende a solicitações de gravações e leituras. A réplica serve exclusivamente para tráfego de leitura e também está disponível como um modo de espera aquecido caso o sistema primário fique danificado.

Com o ElastiCache sem servidor, as réplicas de leitura são mantidas automaticamente pelo serviço. Ao criar seu próprio cache, há vários cenários em que a implantação de uma ou mais réplicas de leitura para um determinado nó primário pode fazer sentido. Razões comuns para implementar uma réplica de leitura incluem:

• Escalabilidade além da capacidade computacional ou de E/S de um único nó primário para cargas de trabalho com muita leitura: esse excesso de tráfego de leitura pode ser direcionado para uma ou mais réplicas de leitura.
• Servindo tráfego de leitura enquanto o primário está indisponível: se o seu nó primário não puder aceitar solicitações de E/S (por exemplo, devido à suspensão de E/S para backups ou manutenção agendada), você poderá direcionar o tráfego de leitura para suas réplicas de leitura. Para esse caso de uso, lembre-se de que os dados na réplica de leitura podem estar desatualizados, já que a instância principal está indisponível. A réplica de leitura também pode ser usada no preparo para reiniciar um nó principal com falha.
• Cenários de proteção de dados: a hipótese improvável de falha do nó primário ou da indisponibilidade da zona de disponibilidade onde reside o nó primário, você pode promover uma réplica de leitura em uma outra zona de disponibilidade para que ela se torne o novo nó primário. 

Você pode se conectar a uma réplica de leitura da mesma forma que se conectaria a um nó de cache primário. Se você tem várias réplicas de leitura, seu aplicativo terá de determinar como o tráfego de leitura será distribuído entre elas. Veja aqui mais detalhes:

• Clusters do Redis OSS (modo de cluster desabilitado), use os endpoints de nós individuais para operações de leitura. (Na API/CLI, eles são chamados de endpoints de leitura.)
• Os clusters do Redis OSS (modo de cluster ativado) usam o endpoint de configuração do cluster para todas as operações. Você ainda pode ler a partir de endpoints de nós individuais. (Na API e na CLI, eles são chamados de endpoints de leitura.)

O ElastiCache permite criar até 5 (cinco) réplicas de leitura para um determinado nó de cache primário.

Caso ocorra um failover, todas as réplicas de leitura associadas e disponíveis devem automaticamente retomar a replicação após a conclusão do failover (recebendo atualizações da réplica de leitura recém-promovida).

As atualizações para um nó de cache primário serão automaticamente replicadas a qualquer réplica de leitura associada. Contudo, com a tecnologia de replicação assíncrona do Redis OSS, uma réplica de leitura pode ficar defasada em relação a seu nó de cache primário por vários motivos. Os principais motivos incluem:

• O volume de E/S de gravação para o nó de cache primário excede a taxa na qual as alterações podem ser aplicadas à réplica de leitura.
• Partições de rede ou latência entre o nó de cache primário e uma réplica de leitura.

As réplicas de leitura estão sujeitas aos pontos fortes e fracos da replicação do Redis OSS. Se você está usando réplicas de leitura, deve estar ciente do potencial de defasagem entre uma réplica de leitura e seu nó de cache primário, ou “inconsistência”. O ElastiCache emite uma métrica para ajudar você a entender a inconsistência.

Uma réplica de leitura é cobrada como um nó de cache padrão e com as mesmas taxas. Assim como um nó de cache padrão, a taxa por “hora de nó de cache” de uma réplica de leitura é determinada pela classe do nó de cache da réplica de leitura: visite a página de preços do ElastiCache para obter o preço atualizado. Você não será cobrado pela transferência de dados que ocorrer na replicação de dados entre seu nó de cache principal e a réplica de leitura. A cobrança por uma réplica de leitura será iniciada assim que a réplica de leitura for criada com êxito (quando o status for listado como ativo). A réplica de leitura continuará sendo cobrada com taxas por hora de nó de cache do ElastiCache padrão, até que você emita um comando para excluí-la.

O failover iniciado é compatível com o ElastiCache, para que você possa retomar as operações de cache o mais rápido possível. Ao ocorrer um failover, o ElastiCache inverte o registro DNS do seu nó de cache para apontar para a réplica de leitura, que, por sua vez, é promovida e se torna o novo nó primário. Aconselhamos a seguir as práticas recomendadas e implementar a repetição da conexão do nó de cache na camada de aplicação. Normalmente, do início ao fim, as etapas de um a cinco abaixo são concluídas em seis minutos.

Estes são eventos de failover automático, listados na ordem de ocorrência:

1. Mensagem do grupo de replicação: API Test Failover chamou pelo grupo de nós <node-group-id>
2. Mensagem do cluster de cache: failover do nó primário <primary-node-id> para o nó de réplica <node-id> concluído
3. Mensagem do grupo de replicação: failover do nó primário <primary-node-id> para o nó de réplica <node-id> concluído
4. Mensagem do cluster de cache: recuperando nós de cache <node-id>
5. Mensagem do cluster de cache: recuperação dos nós de cache <node-id> concluída

Não. A réplica de leitura só pode ser provisionada em uma zona de disponibilidade igual ou diferente da mesma região do nó de cache primário. No entanto, é possível usar o Datastore global para trabalhar com replicação totalmente gerenciada, rápida, confiável e focada em segurança entre as regiões da AWS. Com esse atributo, é possível criar cluster de réplica de leitura entre regiões para que o ElastiCache habilite leituras de baixa latência e recuperação de desastres entre as regiões da AWS.

Sim. É possível ter visibilidade da localização do nó primário atual utilizando o console ou a API DescribeCacheClusters.

Sim. É possível adicionar ou remover réplicas de leitura em um ou mais fragmentos em um ambiente de cluster. O cluster permanece online e atende a solicitações de E/S durante essa operação.

O Multi-AZ é um atributo que permite que você execute em uma configuração com maior disponibilidade ao projetar seu próprio cache do ElastiCache. Todos os caches do ElastiCache sem servidor são executados automaticamente em uma configuração Multi-AZ. Um grupo de replicação do ElastiCache consiste em um primário e até cinco réplicas de leitura. Se o Multi-AZ for habilitado, então pelo menos uma réplica de leitura será exigida por nó primário. Durante determinados tipos de manutenção planejada, ou no improvável caso de uma falha no nó do ElastiCache ou na zona de disponibilidade, o ElastiCache detectará automaticamente a falha de um principal, selecionará uma réplica de leitura e a promoverá a novo principal. O ElastiCache também propaga as alterações de DNS da réplica de leitura promovida. Assim, se o seu aplicativo gravar no endpoint do nó primário, nenhuma alteração de endpoint será necessária.

Os principais benefícios da execução do ElastiCache no modo Multi-AZ são maior disponibilidade e menor necessidade de administração. Quando o ElastiCache é executado em uma configuração Multi-AZ, seus caches se tornam elegíveis para o SLA de disponibilidade de 99,99%. Se uma falha de nó primário do ElastiCache ocorrer, o impacto na capacidade de ler e gravar no primário será limitado ao tempo necessário para a conclusão do failover automático. Quando o Multi-AZ é habilitado, o failover do nó do ElastiCache é automático e não exige administração. 

Você pode usar o Multi-AZ se utiliza o ElastiCache e tem um grupo de replicação consistindo em um nó primário e uma ou mais réplicas de leitura. Se o nó primário falhar, o ElastiCache detectará automaticamente a falha, selecionará uma das réplicas de leitura disponíveis e a promoverá a novo primário. O ElastiCache propagará as alterações de DNS da réplica promovida. Portanto, o seu aplicativo poderá continuar a gravar no endpoint primário. Além disso, o ElastiCache ativará um novo nó para substituir a réplica de leitura promovida na mesma zona de disponibilidade do principal que apresentou falha. Caso a falha do nó primário tenha sido motivada por uma falha temporária na zona de disponibilidade, a nova réplica será iniciada assim que a zona de disponibilidade for recuperada.

Sim. Observe que o posicionamento do primário e das réplicas na mesma zona de disponibilidade não tornará o grupo de replicação do ElastiCache resiliente a uma falha na zona de disponibilidade. Além disso, não será permitido ter réplicas na mesma zona de disponibilidade da primária se o Multi-AZ estiver ativado.

O ElastiCache executará um failover para uma réplica de leitura caso ocorra um dos seguintes eventos:

• Perda de disponibilidade no AZ da primária
• Perda de conectividade de rede para principal
• Falha de unidade computacional na principal

Se houver mais de uma réplica de leitura, será promovida a que tiver a menor diferença de replicação assíncrona em relação ao nó primário.

Sim, o ElastiCache criará um evento para informá-lo da ocorrência de um failover automático. Você pode usar a API DescribeEvents para retornar informações sobre eventos relacionados ao seu nó do ElastiCache, ou selecionar a seção Events no console de gerenciamento do ElastiCache.

As AZs são projetadas para fornecer conectividade de rede de baixa latência para outras AZs na mesma região. Você pode considerar a definição da arquitetura da sua aplicação e de outros recursos da AWS com redundância em várias zonas de disponibilidade para que a aplicação seja resiliente no caso de uma falha de zona de disponibilidade.

Para obter mais informações sobre o Multi-AZ, consulte a documentação do ElastiCache.

O recurso de backup e restauração permite criar snapshots dos seus caches do ElastiCache for Redis. O ElastiCache armazena os snapshots, permitindo que o usuário os utilize para restaurar caches. Atualmente, isso é compatível com o ElastiCache para Valkey, o ElastiCache para Redis OSS e o Serverless. 

A criação de snapshots pode ser útil no caso de perda de dados por falha nos nós ou também no caso improvável de ocorrência de uma falha de hardware. Outro motivo comum para utilizar backups é para fins de arquivamento. Os snapshots são armazenados no Amazon S3.

Quando um backup é iniciado, o ElastiCache cria um snapshot do cache que pode ser utilizado mais tarde para recuperação ou arquivamento. O backup pode ser iniciado a qualquer momento ou pode ser configurado com frequência diária e um período de retenção de até 35 dias. Ao escolher um snapshot para restaurar, um novo cluster do ElastiCache é criado e preenchido com os dados do snapshot. Os snapshots do ElastiCache são compatíveis com o formato de arquivo RDB do Redis OSS.

Você pode usar o atributo de backup e restauração por meio do console, das APIs do ElastiCache e da AWS CLI. O atributo pode ser reativado e desativado quando você quiser.

O recurso de backup e restauração cria snapshots por cache. Os usuários podem especificar qual cache do ElastiCache fazer backup por meio do console, da AWS CLI ou da API do ElastiCache. Recomendamos que os usuários habilitem o backup em uma das réplicas de leitura do cache, minimizando qualquer impacto potencial na primária. Quando o ElastiCache sem servidor é usado, os backups são realizados automaticamente em réplicas de leitura.

Sim, você pode exportar seus snapshots do ElastiCache para um bucket S3 autorizado na mesma região do seu cache.

Sim. Primeiro você deve copiar o snapshot em um bucket autorizado do S3 de sua escolha na mesma região e, então, conceder permissões de bucket entre contas para a outra conta.

O ElastiCache fornece espaço de armazenamento para um snapshot gratuitamente para cada cache ativo do ElastiCache. O armazenamento adicional será cobrado com base no espaço consumido pelos snapshots, com USD 0,085/GB por mês (mesmo preço em todas as regiões). A transferência de dados para uso dos snapshots é gratuita.

Quando você exclui um cache do ElastiCache, os seus snapshots manuais são mantidos. Você também poderá criar um snapshot final antes da exclusão do cache. Os snapshots de cache automáticos não são retidos.

O mecanismo do ElastiCache é totalmente compatível com o Redis OSS, mas também apresenta melhorias que aumentam a performance, a potência e a estabilidade. Algumas das melhorias incluem:

• Mais memória utilizável: agora, você pode alocar com segurança mais memória para a sua aplicação sem correr o risco de aumentar o uso de swap durante sincronizações e snapshots.
• Sincronização improvisada: sincronização mais robusta mediante cargas pesadas e durante a recuperação de desconexões de rede. Além disso, as sincronizações são mais rápidas, pois tanto o primário quanto suas réplicas não usam mais o disco para essa operação.
• Failovers mais estáveis: agora, no caso de um failover, o fragmento se recupera mais rapidamente, pois as réplicas não descarregam mais seus dados para fazerem uma ressincronização completa com o nó primário.
• Descarga de TLS e multiplexação de E/S: o ElastiCache foi projetado para usar melhor os recursos disponíveis da CPU ao lidar com determinados processos relacionados à rede em threads dedicados.

Não. O mecanismo aprimorado é totalmente compatível com o Redis OSS. Portanto, você poderá usufruir da robustez e estabilidade melhoradas sem precisar alterar o código das aplicações.

Não há cobrança adicional para o uso do mecanismo aprimorado.

A criptografia em repouso oferece mecanismos para proteger seus dados contra acesso não autorizado. Quando ativado, ele criptografa os seguintes aspectos:

• O disco durante as operações de sincronização, backup e troca
• Backups armazenados no Amazon S3

O ElastiCache oferece criptografia padrão (gerenciada pelo serviço) em repouso, bem como a capacidade de usar suas próprias chaves simétricas do AWS KMS gerenciadas pelo cliente no AWS KMS. Acesse Criptografia em repouso para saber mais.

O recurso de criptografia em trânsito facilita a criptografia das comunicações entre clientes e o ElastiCache, bem como entre os servidores (primário e réplicas de leitura). Leia mais sobre a Criptografia em trânsito do ElastiCache.

Criptografia em trânsito, criptografia em repouso, Redis OSS AUTH e controle de acesso baseado em perfis (RBAC) são recursos que você pode selecionar ao criar seu cache do ElastiCache para Redis. Se você habilitou a criptografia em trânsito, pode optar por usar o Redis OSS AUTH ou o RBAC para aumentar a segurança e o controle de acesso.

Não, o ElastiCache gerencia internamente a expiração e a renovação de certificações. Nenhuma ação de usuário é necessária para a manutenção contínua de certificados.

Não, não há custo adicional para usar a criptografia.

O Datastore global é um atributo do ElastiCache que disponibiliza replicação gerenciada, rápida, confiável e focada na segurança entre regiões. Com ele, você pode fazer gravações no cache em uma região e disponibilizar os dados para leitura em até dois outros clusters de réplica entre regiões. Isso permite leituras de baixa latência e recuperação de desastres entre regiões.

Projetado para aplicações em tempo real com uma presença global, o Datastore global normalmente replica dados entre regiões em menos de um segundo, aumentando a capacidade de resposta de suas aplicações ao fornecer leituras geolocais mais próximas dos usuários finais. No caso raro de uma degradação regional, um dos caches de réplica entre regiões que não apresentar problemas poderá ser promovido a primário com recursos completos de leitura e gravação. Geralmente, depois de iniciada, a promoção é concluída em menos de um minuto, o que permite que as aplicações permaneçam disponíveis.

Você pode fazer a replicação para até duas regiões secundárias dentro de um Datastore global. No caso raro de uma degradação regional, os caches em regiões secundárias podem ser usados para atender a leituras locais de baixa latência e para fazer a recuperação de desastres.

O Datastore global é aceito no ElastiCache para Redis 5.0.6 e em versões superiores.

Não, o ElastiCache não promove automaticamente um cluster secundário no caso de degradação de um cluster principal (na região). Você pode iniciar manualmente o failover ao promover um cluster secundário para que ele se torne o primário. Geralmente, o failover e a promoção do cluster secundário são concluídos em menos de um minuto.

Para manter os seus dados mais seguros, o Datastore global usa a criptografia em trânsito para o tráfego entre regiões. Além disso, você pode criptografar caches principais e secundários usando a criptografia em repouso para manter seus dados mais bem protegidos. Cada cache primário e secundário pode ter uma chave separada do AWS KMS gerenciada pelo cliente para criptografia em repouso.

O ElastiCache não disponibiliza um SLA para RPO e RTO. O RPO varia com base no atraso da replicação entre regiões e depende da latência de rede entre regiões, bem como do congestionamento do tráfego de rede entre regiões. Geralmente, o RPO do Datastore global é de menos de um segundo. Assim, os dados gravados na região principal ficam disponíveis nas regiões secundárias dentro desse intervalo. Já o RTO do Datastore global é geralmente de menos de um minuto. Depois que o failover de um cluster secundário é iniciado, o ElastiCache normalmente o promove para que ele obtenha recursos completos de leitura e gravação em menos de um minuto.

O ElastiCache não disponibiliza um SLA para RPO e RTO. O RPO varia com base no atraso da replicação entre regiões e depende da latência de rede entre regiões, bem como do congestionamento do tráfego de rede entre regiões. Geralmente, o RPO do Datastore global é de menos de um segundo. Assim, os dados gravados na região principal ficam disponíveis nas regiões secundárias dentro desse intervalo. Já o RTO do Datastore global é geralmente de menos de um minuto. Depois que o failover de um cluster secundário é iniciado, o ElastiCache normalmente o promove para que ele obtenha recursos completos de leitura e gravação em menos de um minuto.

A hierarquização de dados oferece uma nova opção de preço/performance utilizando unidades de estado sólido (SSDs) de baixo custo em cada nó de cluster, além de armazenar dados na memória. Ela é ideal para workloads que acessam até 20% do conjunto de dados geral regularmente e para aplicações que podem tolerar latência adicional ao acessar dados no SSD. Os nós R6gd do ElastiCache com memória e SSD contam com quase 5 vezes mais capacidade de armazenamento total e podem ajudar você a obter mais de 60% de economia no preço ao executá-los no uso máximo, comparado aos nós R6g do ElastiCache com somente memória.

Os níveis de dados funcionam movendo de forma automática e transparente os itens da memória usados com menos frequência para SSDs NVMe conectados localmente quando a capacidade de memória disponível é completamente consumida. Quando um item movido para o SSD for acessado posteriormente, o ElastiCache o retornará à memória de forma assíncrona antes de atender à solicitação.

Os níveis de dados foram projetados para ter um impacto mínimo na performance da aplicação. Assumindo valores de string de 500 bytes, você pode esperar uma latência adicional de 300 µs em média para solicitações de dados armazenados no SSD em comparação com solicitações de dados na memória.

O ElastiCache é compatível com níveis de dados para ElastiCache para Redis OSS versões 6.2 e posteriores.

O ElastiCache oferece suporte a níveis de dados em clusters que usam nós R6gd.

Todos os comandos do Valkey e Redis OSS e a maioria dos recursos do ElastiCache são compatíveis com níveis de dados. Para obter uma lista de atributos que não são compatíveis com clusters que usam níveis de dados, consulte a documentação.

Não há custos adicionais para o uso de níveis de dados além do custo por hora do nó. Os nós com níveis de dados estão disponíveis com preços sob demanda e como nós reservados. Para consultar preços, acesse a página de preços do ElastiCache.