AWS ElastiCache

ElastiCache é o serviço gerenciado da AWS para caches in-memory de Redis, Valkey e Memcached, e é a resposta operacional à pergunta de quem não quer operar o próprio cache em produção: patches, backups, substituição de nós falhos, monitoramento e escalonamento viram responsabilidade da plataforma. O serviço entrega os dois motores dominantes com operação distinta entre si, Memcached com sharding no cliente e Redis com topologia de grupos de replicação, e adiciona camadas que um cache self-hosted raramente tem com disciplina: failover automático com Multi-AZ, criptografia em trânsito e em repouso, autenticação integrada e, na variante serverless, dimensionamento automático de capacidade. Em produção, o ElastiCache costuma ser a dependência de latência mais acessada do sistema, e desenhar o cluster, node type, número de shards e réplicas, política de failover e estratégia de segurança, é desenhar o caminho crítico de leitura da aplicação. Este arquivo cobre a arquitetura do serviço, a escolha entre motores, cluster mode e sharding, réplicas e failover, segurança, a oferta serverless e o dimensionamento de capacidade.

Conceito e arquitetura do serviço

ElastiCache abstrai a operação de nós de cache rodando em instâncias EC2 dentro de VPC, acessíveis por endpoint privado a partir das subnets configuradas. A unidade de organização difere por motor: no Memcached, o cluster é um conjunto de nós equivalentes, cada um com seu endpoint, e a distribuição de chaves fica no cliente; no Redis e no Valkey, a unidade é o replication group, composto por shards (node groups), cada um com um primário e até cinco réplicas de leitura.

O gerenciamento inclui substituição automática de nós com falha de hardware, patching com janela de manutenção configurável, snapshots automáticos com retenção configurável (no Redis), notificações de eventos e integração com CloudWatch para métricas de CPU, memória, conexões, hits e misses, evictions e comandos por segundo.

A comparação honesta com o self-hosted considera o custo total: operar Redis próprio em EC2 ou Kubernetes traz flexibilidade de configuração (módulos como RediSearch, versões imediatas, tuning fino de memória) ao preço de operar failover, patch, backup e observabilidade com a própria equipe. O ElastiCache remove quase toda essa operação em troca de limites de configuração da plataforma, e para a maioria dos times de produto a troca é claramente favorável; times de plataforma maduros com necessidades específicas avaliam o contrário.

A rede é o contrato de acesso: security groups restringem quem alcança o endpoint, e a prática padrão coloca o cache no mesmo conjunto de subnets da aplicação, nunca exposto publicamente. A latência típica de acesso na mesma VPC fica na casa de sub-milissegundo a um milissegundo, e a topologia multi-AZ distribui nós entre zonas de disponibilidade para sobreviver à falha de uma delas.

Redis, Valkey e Memcached no serviço

A relação com as zonas de disponibilidade é parte do desenho de primeira hora: distribuir primário e réplicas entre AZs diferentes é o que permite sobreviver à perda de uma zona sem recriar o cluster, e a criação do replication group pede essa distribuição explícita quando o Multi-AZ está habilitado.

A escolha de motor dentro do ElastiCache repete a comparação do arquivo de cache de aplicação, com nuance de operação gerenciada: o Memcached multi-thread escala CPU verticalmente melhor em nós grandes para cache puro, e o Redis concentra recursos de estruturas, persistência e replicação.

O Valkey é o fork open source de Redis mantido sob a Linux Foundation, disponível no ElastiCache como engine de primeira classe e escolhido quando a governança pede licença BSD sem dependência da licença do Redis. Protocolo e cliente são compatíveis, e a migração entre Redis e Valkey no serviço é operacionalmente trivial.

Cluster mode, sharding e réplicas

O cluster mode enabled do Redis/Valkey no ElastiCache implementa o Redis Cluster oficial: os 16384 slots de hash são distribuídos entre os shards, e a capacidade de memória e de throughput de escrita escala adicionando shards. O cliente configurado com cluster mode recebe o mapa de slots e roteia cada chave para o shard correto, com redirecionamento automático em resharding.

Os endpoints do serviço resumem a topologia: o endpoint de configuração devolve o mapa de slots para clientes em cluster mode, cada shard expõe endpoint primário e de réplicas, e a melhor prática da aplicação é sempre usar o endpoint de configuração, deixando a descoberta de topologia e o failover por conta do cliente inteligente. Endpoints de nó fixados em configuração são dívida que vira incidente no primeiro resharding.

O número de shards é a decisão de capacidade de escrita e de memória total; o número de réplicas por shard é a decisão de throughput de leitura e de disponibilidade. Um shard único com réplicas atende a maioria dos casos de cache até o ponto em que a memória de um nó não comporta o working set, e a partição por slots passa a ser necessária.

O dimensionamento parte de duas medidas de produção: working set quente em memória (dado que precisa estar no cache para o hit ratio alvo) e taxa de comandos por segundo com pico. Nós maiores resolvem memória e conexões; shards adicionais resolvem throughput de escrita; réplicas adicionais resolvem leitura e failover, e não há combinação única correta sem essas medidas.

Scaling horizontal no Redis com cluster mode exige resharding, operação online suportada pelo serviço que migra slots entre shards, com custo de latência nas chaves em movimento. O scaling vertical (troca de node type) também é online, com substituição de nós em sequência e failover entre réplicas, e janelas de manutenção concentram essas operações.

Réplicas, failover e Multi-AZ

No replication group com Multi-AZ habilitado, cada shard tem um primário e réplicas distribuídas em zonas de disponibilidade diferentes, e o serviço monitora a saúde do primário: em falha, uma réplica é promovida automaticamente, o endpoint permanece o mesmo e a aplicação reconecta sem intervenção, com indisponibilidade típica de dezenas de segundos.

O custo do failover automático é a possibilidade de perda das últimas escritas: a replicação é assíncrona, e escritas confirmadas no primário que não alcançaram a réplica promovida se perdem. Para cache, essa perda é geralmente aceitável (o dado é recomputável), e para uso de Redis como armazenamento com exigência de durabilidade, a conversa muda de patamar, com validação explícita de risco.

Réplicas também servem leitura: o cliente com modo de leitura de réplicas distribui reads entre elas, ampliando o throughput de leitura do shard. A contrapartida é a defasagem eventual entre primário e réplica (replication lag, métrica de CloudWatch), e fluxos sensíveis a leitura do que acabou de ser escrito devem ler do primário.

# Criação de replication group Redis com cluster mode, Multi-AZ e segurança
aws elasticache create-replication-group \
  --replication-group-id cache-producao \
  --description "cache de aplicacao producao" \
  --engine redis \
  --engine-version 7.1 \
  --cache-node-type cache.r7g.large \
  --num-node-groups 3 \
  --replicas-per-node-group 2 \
  --automatic-failover-enabled \
  --multi-az-enabled \
  --cache-subnet-group-name subnet-cache-prod \
  --security-group-ids sg-0cache123 \
  --transit-encryption-enabled \
  --at-rest-encryption-enabled \
  --user-group-id-name grupo-apps \
  --snapshot-retention-limit 7 \
  --snapshot-window "04:00-05:00"

Backup e reconstrução do cache

O ElastiCache for Redis suporta snapshots automáticos em janela diária com retenção configurável (até 35 dias) e snapshots manuais sob demanda, além da persistência AOF para sobreviver a reinício de nó. A cópia de snapshot para S3 e entre regiões habilita a reconstrução do cache em outra região, parte da estratégia 3-2-1 quando o cache carrega estado relevante, como sessão de usuário.

A reconstrução do cache tem dois caminhos com perfis de custo diferentes: restaurar snapshot (estado conhecido, sobe frio e aquece pela carga) ou reconstruir vazio a partir do banco (cache frio total, pico de miss gerenciado com as técnicas de stampede do arquivo anterior). A decisão por caminho depende da reconstituibilidade do dado: dado derivado puro reconstrói do banco, sessão e computação cara valem snapshot.

No Memcached gerenciado, não existe snapshot: a perda do nó perde o conteúdo, e o desenho aceita cache frio como norma. Essa assimetria entre motores é mais um fator de decisão quando o cache guarda estado com custo alto de reconstrução.

Segurança: auth, criptografia e isolamento

A segurança do ElastiCache tem três camadas que precisam estar todas ativas em produção, porque o cache guarda sessão, token e dado de usuário que vaza tão caro quanto o banco. A primeira é isolamento de rede: cache em subnets privadas, security group permitindo apenas os SGs da aplicação, sem acesso público.

A segunda é criptografia. Em trânsito (TLS no endpoint, transit encryption enabled) protege o caminho entre aplicação e cache, com custo de CPU e uma leve latência; em repouso (at rest encryption enabled) criptografa snapshots e arquivos em disco com chave KMS, essencial quando o dado é sensível e o snapshot exporta para S3.

A terceira é autenticação e autorização: AUTH token simples para casos básicos, e o recurso de RBAC (user groups) para Redis/Valkey, que cria usuários com senhas e permissões por padrão de comando e padrão de chave, permitindo isolar aplicações que compartilham o cluster. A combinação TLS mais RBAC é o desenho padrão de múltiplas aplicações em um mesmo fleet de cache.

A governança complementar é IAM no plano de controle: quem pode criar, modificar e deletar clusters, e a proteção contra deleção acidental via políticas e etiquetas. Incidentes de cache deletado por automação descontrolada são classe real de erro.

ElastiCache Serverless

O ElastiCache Serverless é a modalidade sem nós configurados: a aplicação aponta para um endpoint único, e o serviço dimensiona memória e throughput automaticamente em escala de milissegundos, com cobrança por GB de dados armazenados e por elastic cache processing units (ECPU) consumidas. O desenho elimina a decisão de node type, shards e réplicas, e o serviço mantém alta disponibilidade distribuída por padrão.

O modelo encaixa perfeitamente em cargas variáveis e imprevisíveis, ambientes de múltiplas aplicações e times sem disciplina de dimensionamento. O contraponto é custo: em carga constante e alta, a modalidade serverless tende a custar mais que nós reservados devidamente dimensionados, e o contraste é a análise financeira clássica de sob demanda versus capacidade dedicada.

A migração entre modalidades é suportada, e a arquitetura da aplicação não muda: mesmo protocolo Redis compatível, mesmo modelo de chave. A decisão típica começa em serverless para validar padrões de acesso e migra para nós dedicados quando a carga estabiliza e o custo se torna dominante.

Os limites do serverless (máximo de dados armazenados e de throughput por cluster, com escalonamento automático dentro deles) cobrem a esmagadora maioria dos casos de cache de aplicação, e os componentes de rede (VPC, security groups, RBAC, TLS) são iguais aos da modalidade de nós, o que mantém o desenho de segurança único entre os dois modelos.

Escolha de node type e dimensionamento

O node type define CPU, memória e capacidade de rede de cada nó, com famílias otimizadas para memória (cache.r7g, maior memória por vCPU) e para uso geral (cache.m7g). A escolha parte do working set quente: memória necessária mais folga de 30 a 50% para eviction e failover, e depois valida se CPU e conexões do nó escolhido comportam o pico de comandos.

As métricas de dimensionamento de CloudWatch que guiam a decisão: CPUUtilization (próximo de 90% em Redis pede shards, pois o motor é predominantemente single-thread por shard), DatabaseMemoryUsagePercentage contra maxmemory, evictions por segundo (eviction ativa significa memória insuficiente para o working set), currConnections contra limites do tipo de nó e hit ratio por aplicação.

Dimensionamento errado tem dois desastres opostos e reconhecíveis: nó grande demais, dinheiro desperdiçado com utilização abaixo de 20%, e nó pequeno demais, evictions e misses em pico destróem o hit ratio e empurram a carga para o banco exatamente no momento crítico. A revisão periódica do dimensionamento com base em métricas de 30 dias é rotina de FinOps, e a adoção de reserved nodes para a base estável de capacidade corta o custo de forma significativa.

Erros comuns e boas práticas

• Escolher Multi-AZ e assumir perda zero de escrita no failover; replicação assíncrona perde as últimas escritas, e uso de cache raramente sente, mas uso de Redis como fonte de verdade precisa de análise explícita.
• Habilitar cluster mode sem validar o suporte do cliente; comandos multi-key entre slots diferentes falham sem hash tags, e a convenção de chave precisa nascer cluster-aware.
• Deixar o cache em subnet com acesso amplo por SG; o SG do cache deve listar exclusivamente os SGs da aplicação, e a auditoria de rede entra na rotina de segurança.
• Ignorar replication lag ao distribuir leitura em réplicas; leitura de dado escrito a um segundo atrás gera defeito funcional, e a rota do cliente precisa considerar o lag para fluxos sensíveis.
• Dimensionar por média e não por pico; evictions em Black Friday não voltam atrás, e o p99 de comandos por segundo é o insumo correto do node type.
• Não configurar janela de manutenção nem snapshots em clusters Redis com dado semipersistente; a janela evita patch em pico, e o snapshot protege o rebuild do cache frio.
• Usar o cache como armazenamento primário sem durabilidade adequada; o ElastiCache é acelerador por desenho, e persistência total com transações é trabalho para o banco de dados.
• Migrar para serverless por conveniência e esquecer o custo por ECPU em carga constante; medir os dois modelos com dados reais de 30 dias antes de fixar a modalidade.