Perguntas frequentes sobre o Amazon ElastiCache

O Amazon ElastiCache é um serviço web que simplifica a implantação e a execução de caches compatíveis com os protocolos Valkey, Memcached ou Redis OSS na nuvem. O ElastiCache melhora a performance das aplicações ao permitir que você recupere informações de um sistema rápido e gerenciado na memória, em vez de depender de sistemas baseados em disco mais lentos. O serviço simplifica e facilita o gerenciamento, o monitoramento e a operação de ambientes na memória, permitindo que seus recursos de engenharia concentrem-se no desenvolvimento de aplicações. Com a utilização do ElastiCache, você não só melhora os tempos de resposta e carga de consultas e ações de usuários, como também reduz os gastos associados ao dimensionamento de aplicações Web.

O ElastiCache automatiza tarefas administrativas comuns necessárias para operar um ambiente distribuído de chave-valor na memória. Ao usar o ElastiCache, é possível adicionar uma camada de cache ou na memória à arquitetura da sua aplicação em questão de minutos com algumas etapas no Console de Gerenciamento da AWS. O ElastiCache foi projetado para manter automaticamente a alta disponibilidade e fornece um Acordo de Serviço (SLA) de 99,99% de disponibilidade. O ElastiCache oferece compatibilidade de protocolo com o Valkey, o Memcached e o Redis OSS. Portanto, o código, as aplicações e as ferramentas conhecidas que você usa hoje em ambientes do Valkey, Memcached ou Redis OSS atuais funcionarão perfeitamente com o serviço. Não há necessidade de investimentos iniciais e você paga somente pelos recursos que utiliza.

O armazenamento em cache na memória fornecido pelo ElastiCache pode ser usado para melhorar significativamente a latência e o throughput de muitas workloads de aplicações que exigem muita leitura (como redes sociais, jogos, compartilhamento de mídia e portais de perguntas e respostas) ou workloads de computação intensiva (como um mecanismo de recomendação). O armazenamento em cache na memória melhora a performance da aplicação, armazenando fragmentos críticos de dados na memória para oferecer acesso de baixa latência. As informações em cache podem incluir os resultados de consultas a banco de dados com uso intenso de E/S ou os resultados de cálculos com uso intenso de computação.

Sim, você pode adquirir Savings Plans para bancos de dados para usar o Amazon ElastiCache e reduzir seus custos em até 30% ao se comprometer com uma quantidade consistente de uso por um período de um ano. Informações adicionais sobre uso elegível podem ser encontradas na página de preços dos Savings Plans para bancos de dados.

O ElastiCache gerencia o trabalho envolvido na configuração de um ambiente na memória distribuído, que abrange do provisionamento de recursos solicitados por você até a instalação do software. Ao usar o Amazon ElastiCache sem servidor, não há infraestrutura que você precise configurar e gerenciar. Ao projetar seu próprio cluster do ElastiCache, o serviço automatiza tarefas administrativas comuns, como aplicação de patches de software e detecção e recuperação de falhas. O ElastiCache disponibiliza métricas de monitoramento detalhadas associadas aos seus recursos, permitindo que você diagnostique e reaja aos problemas rapidamente. Por exemplo, é possível configurar limites e ser avisado por meio de alarmes quando um de seus caches estiver sobrecarregado de solicitações.

O ElastiCache oferece Valkey, Memcached e Redis OSS totalmente gerenciados para suas aplicações mais exigentes que precisam de tempos de resposta abaixo de milissegundos.

Se você ainda não se cadastrou no ElastiCache, pode selecionar Comece a usar na página do ElastiCache e concluir o processo de cadastro. É necessário ter uma conta da AWS. Se você ainda não tiver uma, será solicitado a criá-la ao iniciar o processo de cadastro no ElastiCache. Após o cadastro no ElastiCache, consulte a documentação do ElastiCache, que inclui os Guias de conceitos básicos para o Amazon ElastiCache.

Depois de se familiarizar com o ElastiCache, você poderá criar um cache em minutos usando o console ou as APIs do ElastiCache.

Os caches são simples de criar, usando o console, as APIs do ElastiCache ou as ferramentas de linha de comando. Ao usar o ElastiCache sem servidor, você pode criar um cache usando as configurações padrão recomendadas e começar a usá-lo em menos de um minuto.

O ElastiCache funciona de modo ideal como 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, fornecendo 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.

Sim. Você pode criar réplicas entre regiões usando o recurso Datastore global no ElastiCache. O Datastore global disponibiliza replicação gerenciada, rápida, confiável e focada em segurança entre regiões. Com ele, você pode fazer gravações no cluster do ElastiCache em uma região e disponibilizar os dados para leitura de 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.

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 para 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, o ElastiCache versão 8.1 para Valkey fornece uma nova tabela de hash que resulta em até 40% menos uso de memória para clusters baseados em nós com o Modo Cluster em comparação com o ElastiCache versão 7.2 para Valkey e a versão 7.1 para Redis OSS. A configuração sem servidor melhorou a performance ajustando a escala para cinco milhões de solicitações por segundo por cache em minutos, até cinco vezes mais rápido que o Valkey 7.2, com latência de leitura de microssegundos.

O ElastiCache fornece dois conjuntos distintos de métricas para medir a utilização de CPU do cache, dependendo da 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 do volume 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 uma 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 uma 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 as métricas 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 de 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.

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 sem servidor é 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 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 Serviço (SLA) com disponibilidade de 99,99% para todas as 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 Definição de preços do ElastiCache para saber mais.

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

• Mais memória utilizável: agora, você pode alocar com segurança mais memória para a aplicação, sem correr o risco de aumentar o uso de gravação de memória em disco 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 principal 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. O ElastiCache para Memcached não oferece um recurso de mecanismo aprimorado.

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

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.

Suas reservas do Redis OSS se aplicam automaticamente aos nós do Valkey na mesma família de instâncias e região. Como o Valkey tem um preço 20% menor do que o Redis OSS, se você já tiver um nó reservado do Redis OSS, poderá atualizar o cache para o mecanismo Valkey e continuar recebendo os benefícios de reserva com 20% a mais de valor. Por exemplo, se você comprou uma reserva para cinco nós cache.r7g.2xlarge para o mecanismo Redis OSS, ao atualizar seus nós para o mecanismo Valkey, será possível criar um sexto nó cache.r7g2xlarge (20% a mais que cinco nós) na mesma região sem custo adicional“.

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.

Adquira uma reserva de nó da mesma categoria 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 é 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 classe e a região do 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 elegíveis sejam cobrados com a taxa por hora mais baixa de nó de cache reservado.

Não, você não pode cancelar sua reserva de nó reservado e o pagamento único (se aplicável) não é reembolsável. Ao comprar um nó reservado, você se compromete com um prazo completo de um ou três anos para não poder cancelar, obter um reembolso, alterar o tipo de instância ou vender ou transferir a reserva para outra conta da AWS. Você continuará a pagar por hora durante o período de vigência do nó reservado, independentemente da utilização.

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.

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 uma pequena taxa é cobrada por 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 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 a sua aplicação 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 está habilitado, o failover do nó do ElastiCache é automático e não exige administração.

Você poderá usar o multi-AZ caso utilize o ElastiCache e tenha um grupo de replicação que consista 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 em nó primário

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 informar você 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 zonas de disponibilidade (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 multi-AZ, consulte a documentação do ElastiCache.

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 caches por meio de grupos de segurança de rede. Um grupo de segurança age como firewall, controlando o acesso de rede ao cache. Por padrão, o acesso de rede é desativado para os caches. Se você quiser que as aplicações acessem o 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 recursos do ElastiCache usando a autenticação do IAM. Para obter 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 AWS Services in Scope by Compliance Program para ver uma lista atual dos programas de conformidade aceitos.

Sim. O programa de conformidade com PCI da AWS inclui o ElastiCache como serviço compatível com 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 AWS Services in Scope by Compliance Program.

Sim, o ElastiCache é um serviço qualificado para HIPAA e está coberto pelo Adendo de associado comercial (BAA) 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.

Se você assinou um Acordo de associado comercial (BAA) 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. 

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

O programa de conformidade com o FedRAMP da AWS inclui o ElastiCache como 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
• AWS FedRAMP Compliance

Para ver a lista atual dos programas de conformidade para os quais o ElastiCache está no escopo, consulte AWS Services in Scope by Compliance Program.

Criptografia em trânsito, em repouso, Valkey AUTH e controle de acesso baseado em perfis (RBAC) são atributos que você pode selecionar ao criar seu cache do ElastiCache. 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á custos adicionais para usar a criptografia.

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 modo standby passivo, caso o sistema primário seja comprometido.

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 implantar 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: na hipótese improvável de falha do nó primário ou de indisponibilidade da AZ onde reside o nó primário, você pode promover uma réplica de leitura em 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, sua aplicação terá de determinar como o tráfego de leitura será distribuído entre elas. Veja aqui mais detalhes:

• Os clusters do Valkey ou Redis OSS (modo de cluster desabilitado) usam 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 habilitado) usam o endpoint de configuração do cluster para todas as operações. Você ainda pode ler usando endpoints de nós individuais. (Na API e na CLI, eles são chamados de endpoints de leitura.)

O ElastiCache permite criar até 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 ao 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 o 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 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: acesse a página de preços do ElastiCache para obter os preços atualizados. 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 ou de teste é 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 de 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
2. Mensagem do cluster de cache: Failover do nó primário para o nó de réplica concluído
3. Mensagem do grupo de replicação: Failover do nó primário para o nó de réplica concluído
4. Mensagem do cluster de cache: recuperando os nós de cache
5. Mensagem do cluster de cache: recuperação concluída para os nós de cache

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 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, um novo nó íntegro se junta ao cluster em seis minutos. O tempo de sincronização do nó varia com base na workload e no tamanho do cluster, o que afeta o tempo de conclusão das etapas de um a cinco abaixo. Estes são eventos de failover automático, listados na ordem de ocorrência:

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

O atributo de backup e restauração permite que você crie snapshots dos seus caches do ElastiCache. O ElastiCache armazena os snapshots, permitindo que os usuários os utilizem subsequentemente para restaurar caches. No momento, isso é compatível com o ElastiCache para Valkey, o ElastiCache para Redis OSS e Sem Servidor.

Quando um backup é iniciado, o ElastiCache cria o snapshot de um cache especificado 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.

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.

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 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 do 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, em seguida, 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 usar os snapshots é gratuita.

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

Sim, um backup feito de qualquer versão do ElastiCache para Redis OSS pode ser restaurado para qualquer versão do ElastiCache para Valkey. Para obter mais informações sobre como restaurar backups, consulte a documentação do ElastiCache.

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 Datastore global é um recurso do ElastiCache que disponibiliza replicação totalmente 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 Datastore global é 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 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. Há suporte para o Datastore global no AWS CloudFormation.

Não, o ElastiCache não promove automaticamente um cluster secundário no caso de degradação de um cluster (região) principal. 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 de um 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 para 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ário no Datastore global e pelo tráfego de transferência de dados entre regiões.

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 do AWS KMS separada e gerenciada pelo cliente para criptografia em repouso.

O recurso de níveis de dados oferece uma nova opção de preço/performance utilizando unidades SSD 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 SSDs contam com quase cinco 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, em comparação com os nós R6g do ElastiCache com memória apenas.

Os níveis de dados funcionam movendo de forma automática e transparente os itens usados com menos frequência da memória para SSDs NVMe conectados localmente quando a capacidade de memória disponível foi totalmente 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 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 os níveis de dados do 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 recursos que não são compatíveis com os 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.

O Valkey é uma evolução de código aberto do Redis OSS liderada pela Linux Foundation compatível com uma variedade de casos de uso, como cache, tabelas de classificação e armazenamentos de sessão, criada por colaboradores e mantenedores de longa data do Redis OSS. O Valkey é apoiado por mais de 40 empresas e tem sido adotado rapidamente desde a criação do projeto em março de 2024.

Com o ElastiCache para Valkey, você pode se beneficiar de uma experiência totalmente gerenciada, baseada em tecnologia de código aberto, enquanto aproveita a segurança, a excelência operacional, o SLA de disponibilidade de 99,99% e a confiabilidade que a AWS oferece. Você pode otimizar ainda mais os custos do ElastiCache sem servidor para Valkey com redução de 33% no preço e armazenamento mínimo de dados de 100 MB, 90% menor do que o ElastiCache Redis OSS. No ElastiCache para Valkey baseado em nó, você pode se beneficiar de um custo até 20% menor por nó. 

Sim. Com o ElastiCache, você pode criar uma réplica de leitura em outra zona de disponibilidade da AWS. Quando o ElastiCache sem servidor é usado, os dados são automaticamente armazenados de forma redundante em várias zonas de disponibilidade para alta disponibilidade. Ao projetar seu próprio cache do ElastiCache, em caso de falha de um nó, provisionaremos um novo. Em cenários em que o nó primário falhar, o ElastiCache promoverá automaticamente uma réplica de leitura existente para a função primária. Para obter mais detalhes sobre como lidar com falhas de nós, acesse understanding replication.

Você pode atualizar rapidamente para uma versão mais recente do mecanismo usando as APIs do ElastiCache e especificando sua versão de mecanismo preferida. No console do ElastiCache, você pode selecionar um cache e selecionar Modificar. O processo de atualização do mecanismo foi projetado para reter seus dados existentes. Para obter mais detalhes, consulte caching strategies and best practices.

Não, o downgrade para uma versão anterior não é aceito.

Sim, você terá os mesmos atributos, SLAs e funcionalidades se fizer o upgrade do ElastiCache for Redis OSS para o ElastiCache for Valkey.

Há três maneiras nas quais o ElastiCache para Valkey é diferente do ElastiCache para Redis OSS. Primeiro, com o ElastiCache para Valkey, você pode obter uma escala mais rápida e 20% mais eficiência de memória em comparação com o ElastiCache para Redis OSS. Em segundo lugar, o ElastiCache para Valkey tem um preço até 33% menor do que o ElastiCache para Redis OSS. Por último, o ElastiCache for Valkey usa o Valkey, o projeto de código aberto, que evita a dependência de fornecedor.

Você pode atualizar sua versão existente do mecanismo Redis OSS para a versão mais recente em vigor do Valkey, sem tempo de inatividade e com apenas alguns cliques. Para obter um guia passo a passo para atualizar seu mecanismo, consulte a documentação de atualização do mecanismo ElastiCache. Você pode fazer o upgrade de qualquer versão do Redis OSS compatível com o ElastiCache para qualquer versão do ElastiCache para Valkey. Se você atualizar de versões do Redis OSS anteriores à 5.0.6, será necessária uma propagação de DNS que pode ter um tempo de failover de 30 a 60 segundos. Para obter uma lista completa das mudanças entre todas as versões principais e secundárias, consulte a documentação da versão do ElastiCache. 

Você pode migrar seus dados do Valkey ou Redis OSS autogerenciado em execução no Amazon EC2 para o Amazon ElastiCache com o recurso de migração on-line. Se preferir, crie um snapshot do cluster do Redis OSS em execução no EC2 e restaure-o no ElastiCache para Valkey.

Sim, você pode atualizar seus clusters existentes do ElastiCache para Redis OSS para o ElastiCache para Valkey via CloudFormation alterando as propriedades Engine e EngineVersion.

Todos os clientes Redis OSS que aceitam o Redis OSS 7.2 são totalmente compatíveis com todas as versões do Valkey. Você pode encontrar uma lista das bibliotecas oficiais do cliente Valkey na página do cliente valkey.io. 

Sim, as taxas de desconto do nó reservado serão aplicadas às suas RIs existentes ao migrar do ElastiCache for Redis para o ElastiCache Valkey. O cenário 5 deste blog fornece detalhes adicionais.

Com os nós reservados do Redis OSS, além de poder aplicar seus benefícios na família e no mecanismo de nós de cache, você também pode optar por fazer o upgrade para o mecanismo Valkey e receber mais valor incremental. O Valkey tem um desconto de 20% em relação ao Redis OSS e, com a flexibilidade do nó reservado, você pode aplicar seus nós reservados do Redis OSS a 20% mais nós reservados do Valkey. Para obter mais informações sobre flexibilidade de nós reservados, consulte este blog.

Você pode armazenar em cache uma variedade de objetos usando o ElastiCache para Memcached. Esses objetos incluem o conteúdo em armazenamentos de dados persistentes (como Amazon Relational Database Service (Amazon RDS), Amazon DynamoDB ou bancos de dados autogerenciados hospedados no Amazon EC2), páginas da Web geradas dinamicamente (com o Nginx, por exemplo) e dados de sessão transitórios que podem não exigir um armazenamento de apoio persistente. Você também pode utilizar o serviço para implementar contadores de alta frequência a fim de implantar o controle de admissão em aplicações web de alto volume.

Sim. O ElastiCache é um front-end ideal para datastores, como Amazon RDS ou DynamoDB, que proporciona um nível médio de alta performance para aplicações com taxas de solicitação extremamente altas ou requisitos de baixa latência.

O ElastiCache apresenta protocolo compatível com o Memcached. Portanto, você pode usar operações padrão do Memcached como get, set, incr e decr da mesma forma que usaria em implantações do Memcached. O ElastiCache é compatível com protocolos de texto e binários. Também suporta a maioria dos resultados de estatísticas padrão, os quais também podem ser vistos como gráficos com o CloudWatch. Sendo assim, você pode passar a usar o ElastiCache sem recompilar ou refazer os links de suas aplicações. As bibliotecas que usa continuarão funcionando. Para configurar os servidores de cache acessados pela aplicação, basta atualizar o arquivo de configuração Memcached da aplicação para incluir os endpoints dos servidores (nós) que provisionamos para você. Você pode usar a opção Copy Node Endpoints no console ou a API DescribeCacheClusters para obter uma lista dos endpoints. Como em qualquer processo de migração, é recomendável um teste completo da nova implantação do ElastiCache antes de concluir o corte de sua solução atual.

Você pode acessar clusters do ElastiCache em uma Amazon VPC pela rede do Amazon EC2 ou do seu próprio datacenter. Consulte os padrões de acesso da Amazon VPC para obter mais detalhes. O ElastiCache usa entradas DNS para permitir que aplicações cliente localizem servidores (nós). O nome de DNS de um nó não muda, mas o endereço IP de um nó pode ser alterado com o tempo, por exemplo, quando os nós forem substituídos automaticamente após uma falha em uma instalação que não seja da VPC. Consulte as perguntas frequentes para obter recomendações sobre como lidar com falhas de nó.

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

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 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 usando a opção Add Node, na guia Nodes, para seu cluster de cache no console, ou chamando a API ModifyCacheCluster.

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 no seu cluster de cache adicionando 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 clientes Memcached e adicionar suporte para a Descoberta Automática. Se quiser adicionar 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ê optar por não usar o cliente de cluster do ElastiCache, poderá continuar usando seus próprios clientes ou modificar sua própria biblioteca de clientes para compreender o conjunto de comandos da Descoberta Automática.
 

Sim, o mesmo cluster do ElastiCache pode ser conectado por meio de um cliente compatível com a 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 sua aplicação antes de implantá-la na 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 principal) 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 ou 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.

Consulte nossos preços para obter informações atualizadas.

Você pode atualizar rapidamente para uma versão mais recente do mecanismo usando as APIs do ElastiCache e especificando sua versão de mecanismo preferida. No console do ElastiCache, você pode selecionar um cache e selecionar Modificar. O processo de atualização de mecanismo foi projetado para reter seus dados existentes. Para obter mais detalhes, consulte a documentação.

Não, o downgrade para uma versão anterior não é aceito.

O ElastiCache continuará oferecendo suporte às versões anteriores do Redis OSS, incluindo o Redis OSS 7.1. Com o tempo, encerraremos as versões mais antigas de todos os mecanismos (incluindo Valkey, Memcached e Redis OSS) e forneceremos um período para que os usuários atualizem seus mecanismos antes que uma determinada versão do mecanismo seja descontinuada.