Escolha entre opções de implantação
O Amazon ElastiCache tem duas opções de implantação:
Armazenamento em cache sem servidor
Clusters baseados em nós
Para obter uma lista de comandos aceitos para ambos, consulte Comandos Valkey, Memcached e Redis OSS compatíveis e restritos.
Armazenamento em cache sem servidor
O Amazon ElastiCache Sem Servidor simplifica a criação de cache e escala instantaneamente para dar suporte às aplicações mais exigentes dos clientes. Com o ElastiCache Sem Servidor, você pode criar um cache altamente disponível e escalável em menos de um minuto, eliminando a necessidade de provisionar, planejar e gerenciar a capacidade do cluster. O ElastiCache Sem Servidor armazena automaticamente os dados de maneira redundante em três zonas de disponibilidade e oferece um Acordo de Serviço (SLA) com 99,99% de disponibilidade. Os backups de clusters Valkey baseados em nós ou de Redis OSS podem ser restaurados em uma configuração com tecnologia sem servidor.
Clusters baseados em nós
Se você precisar de controle detalhado sobre seu cluster do Valkey, Memcached ou Redis OSS, poderá escolher criar um cluster baseado em nós com o ElastiCache. Escolha o tipo de nó, o número de nós e o posicionamento do nó nas zonas de disponibilidade da AWS para o cluster. Por ser um serviço totalmente gerenciado, o ElastiCache ajuda a gerenciar o provisionamento, o monitoramento, as substituições de nó e a aplicação de patches de software para o cluster. Clusters baseados em nós podem ser projetados para fornecer um SLA de disponibilidade de até 99,99%. Backups de caches Valkey ou Redis OSS de tecnologia sem servidor podem ser restaurados em um cluster baseado em nós.
Escolha entre opções de implantação
Escolha o armazenamento sem servidor se:
Você está criando um cache para workloads novas ou difíceis de prever.
Você tem tráfego de aplicativos imprevisível.
Você deseja a maneira mais fácil de começar a usar um cache.
Crie seu próprio cluster baseado em nós se:
Você já está executando o ElastiCache sem servidor e deseja um controle mais refinado sobre o tipo de nó que executa o Valkey, Memcached ou Redis OSS, o número de nós e o posicionamento desses nós.
Você espera que o tráfego do seu aplicativo seja relativamente previsível e deseja um controle refinado sobre desempenho, disponibilidade e custo.
Você pode prever os requisitos de capacidade para controlar os custos.
Comparar cache com tecnologia sem servidor e clusters baseados em nós
| Recurso | Armazenamento em cache sem servidor | Clusters baseados em nós |
|---|---|---|
|
Configuração de cache |
Crie um cache com apenas um nome em menos de um minuto |
Fornece controle refinado sobre o design do cluster. O usuário pode escolher o tipo de nó, o número de nós e o posicionamento nas zonas de disponibilidade da AWS |
|
Versão aceita do ElastiCache |
Valkey 7.2 e superior, Redis OSS versão 7.1 e superior, Memcached 1.6.21 e superior |
Valkey 7.2 e superior, Redis OSS versão 4.0 e superior, Memcached 1.4 e superior |
|
Modo Cluster (Valkey e Redis OSS) |
Opera motores somente em |
Pode ser configurado para operar no modo cluster habilitado ou desabilitado. |
|
Escalabilidade |
Escala automaticamente os mecanismos vertical e horizontalmente sem qualquer gerenciamento de capacidade. |
Fornece controle sobre o escalonamento, ao mesmo tempo em que exige monitoramento para garantir que a capacidade atual esteja atendendo adequadamente à demanda. Para Valkey e Redis OSS, você pode escolher escalar verticalmente aumentando ou diminuindo o tamanho do nó de cache quando necessário. Você também pode escalar horizontalmente ao adicionar novos fragmentos ou adicionar mais réplicas aos fragmentos. Esse recurso não está disponível para o Memcached. Com o atributo de ajuste de escala automático, você também pode configurar o dimensionamento com base em uma programação ou em métricas como uso de CPU e memória no cache. |
|
Conexão do cliente |
Os clientes se conectam a um único endpoint. Isso permite que a topologia do nó de cache subjacente (escalonamento, substituições e atualizações) mude sem desconectar o cliente. |
Os clientes se conectam a cada nó de cache individual. Se um nó for substituído, o cliente redescobre a topologia do cluster e restabelece as conexões. |
|
Configure |
Nenhuma configuração refinada disponível. Os clientes podem configurar configurações básicas, incluindo sub-redes que podem acessar o cache, se os backups automáticos estão ativados ou desativados e limites máximos de uso do cache. |
Clusters baseados em nós oferecem opções de configuração refinadas. Os clientes podem usar grupos de parâmetros para um controle refinado. Para uma tabela desses valores de parâmetro por tipo de nó, consulte Parâmetros específicos do mecanismo. |
|
Multi-AZ |
Os dados são replicados de forma assíncrona em várias Zonas de Disponibilidade para maior disponibilidade e melhor latência de leitura. |
Oferece uma opção para criar o cluster em uma única zona de disponibilidade ou em várias zonas de disponibilidade (AZ). Ao usar o Valkey ou o Redis OSS, são fornecidos clusters Multi-AZ com dados replicados de forma assíncrona em várias zonas de disponibilidade para maior disponibilidade e melhor latência de leitura. |
|
Criptografia em repouso |
Sempre habilitado. Os clientes podem usar uma chave Chave gerenciada pela AWS ou uma chave gerenciada pelo cliente no AWS KMS. |
Opção para habilitar ou desabilitar a criptografia em repouso. Quando habilitada, os clientes podem usar uma chave Chave gerenciada pela AWS ou uma chave gerenciada pelo cliente no AWS KMS. |
|
Criptografia em trânsito (TLS) |
Sempre habilitado. Os clientes devem oferecer suporte à conectividade TLS. |
Opção para habilitar ou desabilitar. |
|
Backups |
Aceita backups automáticos e manuais de caches sem impacto no desempenho. Os backups do Valkey e do Redis OSS são compatíveis entre si e podem ser restaurados em um cache ElastiCache sem servidor ou em um cluster baseado em nós. |
Aceita backups automáticos e manuais para Valkey e Redis OSS. Os clusters podem ter algum impacto sobre o desempenho, dependendo da memória reservada disponível. Para obter mais informações, consulte Gerenciamento de memória reservada para Valkey e Redis OSS. Os backups do Valkey e do Redis OSS são compatíveis entre si e podem ser restaurados em um cache ElastiCache sem servidor ou em um cluster baseado em nós. |
|
Monitoramento |
Aceita a métricas de nível de cache, incluindo taxa de acerto de cache, taxa de falha de cache, tamanho de dados e ECPUs consumidas. O ElastiCache sem servidor envia eventos usando o EventBridge quando eventos significativos acontecem em seu cache. É possível optar por monitorar, ingerir, transformar e agir em eventos do ElastiCache usando o Amazon EventBridge. Para obter mais informações, consulte Eventos de cache sem servidor. |
Os clusters baseados em nós do ElastiCache emitem métricas em cada nível de nó, incluindo métricas de nível de host e métricas de cache. Clusters baseados em nós emitem notificações de SNS para eventos significativos. Consulte Métricas para o Memcached e Métricas para o Valkey e Redis OSS. |
|
Disponibilidade |
Acordo de Serviço (SLA) |
Clusters baseados em nós podem ser projetados para atingir um Acordo de Serviço (SLA) |
|
Atualizações e correções de software |
Atualiza automaticamente o software de cache para a versão secundária e de patch mais recente, sem impacto no aplicativo. Os clientes recebem uma notificação sobre atualizações de versões principais e podem atualizar para a versão principal mais recente quando quiserem. |
Os clusters baseados em nós oferecem autoatendimento habilitado pelo cliente para atualizações de versões secundárias e de patches, bem como atualizações de versões principais. As atualizações gerenciadas são aplicadas automaticamente durante as janelas de manutenção definidas pelo cliente. Os clientes também podem optar por aplicar um upgrade de versão secundária ou de patch sob demanda. |
|
Global Data Store |
Não compatível |
Suporta Global Data Store, que permite replicação entre regiões com gravações de região única e leituras multirregionais |
|
Hierarquização de dados |
Não compatível |
Clusters que são criados usando nós da família r6gd têm seus dados classificados em níveis entre a memória e o armazenamento local em unidades de estado sólido (Solid state Drives, SSD). A classificação de dados em níveis fornece uma opção de relação entre preço e desempenho para workloads do Valkey e Redis OSS, utilizando unidades de estado sólido (SSDs) de menor custo em cada nó de cluster, além do armazenamento de dados na memória. |
|
Modelo de definição de preços |
Pagamento por uso, com base em dados armazenados em GB/hora e solicitações nas unidades de processamento do ElastiCache (ECPU). Consulte detalhes de preço aqui |
Pagamento por hora, com base no uso do nó de cache. Consulte detalhes de preço aqui |
Tópicos relacionados:
