Diseño de caché con Amazon ElastiCache - Selección entre Valkey, Redis OSS y Memcached y estrategias de caché
Organizamos los criterios de selección entre Valkey, Redis OSS y Memcached, y presentamos las estrategias de caché Lazy Loading y Write-Through junto con el uso del modo Serverless.
Criterios de selección entre Valkey, Redis OSS y Memcached
ElastiCache ofrece tres motores, Valkey, Redis OSS y Memcached, y procesa millones de solicitudes por segundo con una latencia del orden de microsegundos. Valkey es un motor compatible de código abierto que nació como fork de Redis, y se ofrece como motor predeterminado de ElastiCache. Valkey y Redis OSS funcionan con un modelo de bucle de eventos de un solo hilo y ofrecen estructuras de datos ricas, como cadenas, hashes, listas, conjuntos, Sorted Set, Streams y HyperLogLog. Admiten la persistencia de datos mediante AOF (Append Only File) e instantáneas RDB, las réplicas de lectura, el failover automático y la mensajería Pub/Sub. Por ello, pueden usarse no solo como caché, sino también como almacén de sesiones, tablas de clasificación, rankings en tiempo real y broker de mensajes. Memcached tiene una arquitectura multihilo especializada en la caché simple de pares clave-valor, y el escalado horizontal mediante la adición de nodos es sencillo. Es adecuado cuando no se necesitan la persistencia de datos ni la replicación y solo se quiere almacenar en caché los resultados de las consultas a la base de datos. En la selección del motor es decisivo que Valkey use el mismo conjunto de comandos y las mismas bibliotecas de cliente que Redis OSS y, aun así, tenga precios más bajos. Su tarifa por hora de los nodos, su tarifa de ECPU de Serverless y su almacenamiento mínimo facturado de Serverless son todos inferiores a los de Redis OSS. Por eso, en la práctica se separan los usos: Valkey como punto de partida para las implantaciones nuevas, Redis OSS cuando se prolonga la vida de un clúster existente o se depende de una versión concreta, y Memcached para una capa de caché simple que no necesita replicación ni persistencia.
| Aspecto | Valkey (motor predeterminado) | Redis OSS | Memcached |
|---|---|---|---|
| Modelo de ejecución | Bucle de eventos de un solo hilo | Bucle de eventos de un solo hilo | Multihilo |
| Estructuras de datos | Cadenas, hashes, listas, conjuntos, Sorted Set, Streams, HyperLogLog | Igual que Valkey (Valkey es compatible con Redis OSS) | Solo clave-valor simple |
| Persistencia y replicación | AOF e instantáneas RDB, réplicas de lectura, failover automático | AOF e instantáneas RDB, réplicas de lectura, failover automático | No tiene ninguna de ellas |
| Forma de escalar | Sharding y réplicas de lectura | Sharding y réplicas de lectura | Escalado horizontal sencillo añadiendo nodos |
| Usos más allá de la caché | Almacén de sesiones, tablas de clasificación, rankings en tiempo real, broker de mensajes de Pub/Sub | Almacén de sesiones, tablas de clasificación, rankings en tiempo real, broker de mensajes de Pub/Sub | Básicamente solo como caché |
| Compatibilidad con Serverless | Compatible. El almacenamiento mínimo facturado es de 100 MB por caché | Compatible. El almacenamiento mínimo facturado es de 1 GB por caché | Compatible. El almacenamiento mínimo facturado es de 1 GB por caché |
| Nivel de costo | El más barato de los 3 motores (en la tarifa por hora de los nodos, la tarifa de ECPU y la tarifa de almacenamiento de Serverless) | Más caro que Valkey | Tarifa por hora de los nodos al mismo nivel que Redis OSS |
| Casos adecuados | Opción predeterminada para las implantaciones nuevas. La forma más barata de empezar manteniendo la compatibilidad con Redis OSS | Cuando se quieren seguir usando tal cual los activos existentes de Redis OSS | Cuando solo se quieren almacenar en caché los resultados de las consultas a la base de datos |
Diseño de estrategias de caché
Lazy Loading (Cache-Aside) es una estrategia que, cuando se produce un fallo de caché, obtiene los datos de la base de datos y los escribe en la caché. Como en la caché solo se almacenan los datos que realmente se solicitan, la eficiencia de memoria es alta, pero en el acceso inicial se produce un fallo de caché. Write-Through es una estrategia que actualiza también la caché al mismo tiempo que se escribe en la base de datos. Los datos de la caché se mantienen siempre actualizados, pero la latencia de escritura aumenta y también se almacenan en la caché datos que no se leen. En el uso real, resulta efectivo el enfoque de combinar ambas: actualizar la caché al escribir con Write-Through y, a la vez, configurar un TTL para que los datos antiguos caduquen automáticamente. El valor del TTL se decide según los requisitos de frescura de los datos: corto (de unos segundos a unos minutos) para los datos que exigen inmediatez y largo (de unas horas a unos días) para los datos maestros. La clave de la operación es supervisar de forma continua la tasa de aciertos de caché con las métricas de CloudWatch y revisar periódicamente el ajuste del TTL y del tamaño de los nodos.
| Aspecto | Lazy loading (cache-aside) | Write-through |
|---|---|---|
| Qué provoca la escritura en caché | Un fallo de caché: se guarda el valor al traerlo de la base de datos | Una escritura en la base de datos: la caché se actualiza en el mismo momento |
| Qué acaba en la caché | Solo los datos que se pidieron de verdad | Todo lo escrito, incluidos datos que nadie lee |
| Eficiencia de memoria | Alta | Suele ser menor |
| Frescura de los datos | La caché puede quedarse obsoleta | Siempre al día |
| Punto débil | El primer acceso siempre falla | Aumenta la latencia de escritura |
| Dónde aterriza la práctica | Combinar ambos: actualizar en la escritura con write-through y dejar que un TTL caduque lo obsoleto. Segundos o minutos para datos que deben parecer en tiempo real; horas o días para datos maestros | |
Modo cluster y sharding
Al habilitar el modo cluster en Valkey o Redis OSS, los datos se distribuyen en 16384 hash slots y se puede escalar horizontalmente con varios shards. En cada shard se colocan un primario y hasta 5 réplicas de lectura para repartir la carga de lectura. El límite predeterminado del clúster no se determina por el número de shards, sino por el de nodos: hasta 90 nodos por clúster entre primarios y réplicas (hasta 90 shards en una configuración sin réplicas). En Valkey 7.2 o posterior (Redis OSS 5.0.6 o posterior), solicitando un aumento del límite se puede ampliar hasta un máximo de 500 nodos por clúster (valor de la documentación oficial, a fecha de agosto de 2026). Los clientes envían las solicitudes al shard correcto según la asignación de hash slots y, si un slot se ha movido, se reconectan automáticamente mediante la redirección MOVED. Para el tipo de nodo, las instancias de la serie r optimizadas para memoria (serie cache.r7g) son adecuadas para las cargas de trabajo de caché, y el número de shards y de réplicas se ajusta según el volumen de datos y los requisitos de rendimiento. Si se habilitan la implementación Multi-AZ y el failover automático, ante un fallo del primario se promueve automáticamente la réplica con el menor retraso de replicación. En la documentación oficial se indica que, normalmente, se tarda unos segundos hasta poder reanudar las escrituras. Sin embargo, como la replicación es asíncrona, si la réplica promovida va ligeramente retrasada, es posible que se pierdan las escrituras correspondientes. Se parte de la base de que los datos que no se pueden perder se escriben también en un almacén persistente, como DynamoDB o RDS.
Migración a Valkey y Global Datastore
Valkey permite usar tal cual las bibliotecas de cliente y los conjuntos de comandos de Redis existentes, y ofrece un entorno compatible con Redis sin preocupaciones de licencia. Desde un clúster de Redis OSS en funcionamiento se puede migrar a Valkey con una operación de actualización del motor, y se conservan los descuentos de los nodos reservados ya adquiridos. Con Global Datastore, los datos se replican de forma asíncrona entre regiones, lo que permite la recuperación ante desastres (DR) y la mejora de la latencia de lectura global. Ante un fallo de la región primaria se puede promover la región secundaria. Según los valores de las FAQ oficiales de AWS (a fecha de agosto de 2026), el RPO es normalmente inferior a 1 segundo y el RTO también es normalmente inferior a 1 minuto (tras iniciarse el failover, la secundaria pasa normalmente en un plazo de 1 minuto a poder atender tanto lecturas como escrituras). Los datos enviados por la replicación entre regiones generan cargos por transferencia, así que en los clústeres con mucho volumen de escritura hay que incluirlos en la estimación de costos.
ElastiCache Serverless y operación
ElastiCache Serverless es un modo que apareció en 2023 y no requiere diseñar de antemano el tipo de nodo ni el tamaño del clúster. Es compatible con los tres motores, Valkey, Redis OSS y Memcached, y basta con elegir el motor para crear una caché. La capacidad escala automáticamente según la carga de trabajo, de modo que se empieza con una configuración mínima y se responde automáticamente al aumento del tráfico. El precio es de pago por uso, basado en la cantidad de almacenamiento de datos (GB-hora) y en el uso de ElastiCache Processing Units (ECPU). Como base, 1 KB de datos transferidos en lecturas y escrituras equivale a 1 ECPU, y en Valkey y Redis OSS los comandos que usan mucho tiempo de vCPU se calculan con el valor más alto entre el volumen transferido y el tiempo de vCPU. Además, hay un almacenamiento mínimo facturado por caché: 100 MB en Valkey y 1 GB en Redis OSS y Memcached (valor de la página oficial de precios, a fecha de agosto de 2026). Se pueden establecer límites superiores e inferiores para el almacenamiento de datos y la tasa de solicitudes: el superior contiene los costos inesperados y el inferior garantiza un rendimiento de referencia. Es especialmente adecuado para aplicaciones nuevas con patrones de tráfico difíciles de prever y para entornos de desarrollo y pruebas. En cambio, en los entornos de producción con patrones de tráfico estables, una configuración aprovisionada con nodos reservados puede resultar más rentable.
Precios de ElastiCache
(A fecha de agosto de 2026, en Virginia del Norte us-east-1 y Tokio ap-northeast-1) ElastiCache cobra por cuatro conceptos: las horas de nodo de los clústeres basados en nodos, el almacenamiento de datos y las ECPU de Serverless, el almacenamiento de las copias de seguridad (instantáneas) y la transferencia de datos entre regiones de Global Datastore. Las horas de nodo cuestan, para Valkey cache.r7g.large, 0.1752 USD por hora en Virginia del Norte y 0.2104 USD por hora en Tokio. Con el mismo tipo de nodo, Redis OSS y Memcached cuestan 0.219 USD por hora en Virginia del Norte, de modo que Valkey tiene un precio alrededor de un 20 % más bajo. En Serverless, el almacenamiento de datos se factura en GB-hora (GB-Hours): Valkey cuesta 0.084 USD por GB-hora en Virginia del Norte y 0.101 USD por GB-hora en Tokio, y Redis OSS y Memcached, 0.125 USD por GB-hora en Virginia del Norte. Las ECPU tienen un precio por cada 1 millón de ECPU: Valkey cuesta 0.0023 USD en Virginia del Norte y 0.0027 USD en Tokio, y Redis OSS y Memcached, 0.0034 USD en Virginia del Norte. Las copias de seguridad cuestan 0.085 USD por GB-mes (GB-months) por el almacenamiento que supere la asignación gratuita, igual en ambas regiones. Los datos enviados por la replicación entre regiones de Global Datastore cuestan 0.02 USD/GB desde Virginia del Norte y 0.09 USD/GB desde Tokio. Hay tres puntos sobre la facturación mínima y las excepciones. Serverless tiene un almacenamiento mínimo facturado por caché (Valkey 100 MB / Redis OSS y Memcached 1 GB), que se factura aunque la caché esté inactiva. Los nodos de Valkey con la opción de durabilidad (escritura síncrona) habilitada tienen un concepto de facturación aparte de la tarifa del nodo, que en cache.r7g.large es de 0.0315 USD por hora en Virginia del Norte y 0.0379 USD por hora en Tokio. Si se sigue usando una versión del motor cuyo soporte estándar ha finalizado, se añade un concepto de facturación por soporte extendido, que en cache.r7g.large en Virginia del Norte es de 0.175 USD por hora en los años 1 y 2, y de 0.35 USD por hora en el año 3. La capa gratuita varía según la fecha de registro: si se registró en la capa gratuita de AWS antes del 15 de julio de 2025, el uso de nodos cache.t3.micro de 750 horas al mes es gratuito durante un máximo de 12 meses (Serverless no está incluido). En los registros a partir de esa fecha, se elige entre Free Plan y Paid Plan, y el uso se cubre con créditos. En las cargas de trabajo con tráfico intermitente, Serverless resulta de menor costo, y en las cargas de trabajo con alto rendimiento constante, los nodos aprovisionados son más ventajosos. En una configuración aprovisionada, los nodos reservados permiten bajar mucho el costo: el pago anticipado total a 3 años de Valkey cache.r7g.large es de 2,071.92 USD en Virginia del Norte y 2,488.19 USD en Tokio. Dividido entre 3 años (26,280 horas), el costo por hora es de alrededor de un 45 % del precio bajo demanda, es decir, un descuento efectivo de alrededor de un 55 %.
Resumen
ElastiCache es un servicio de caché que contribuye directamente a reducir la carga de la base de datos y a mejorar la velocidad de respuesta de las aplicaciones. En las implantaciones nuevas, se parte de Valkey, el motor predeterminado, y la estrategia de caché se diseña combinando Lazy Loading y Write-Through. La escalabilidad se asegura con el sharding del modo cluster y las réplicas de lectura, y con Global Datastore también se puede dar soporte a despliegues globales y a la recuperación ante desastres. Un enfoque efectivo es empezar fácilmente con el modo Serverless y, cuando la carga de trabajo se estabilice, considerar la migración a una configuración aprovisionada con nodos reservados.
Referencias (recursos oficiales de AWS)
Las fuentes primarias de esta página son el sitio web y la documentación oficiales de AWS. Consulta las páginas oficiales siguientes para conocer las especificaciones y los precios más recientes.
- Amazon ElastiCache (página oficial)
- Amazon DynamoDB (página oficial)
- Amazon RDS (página oficial)
- Documentación de AWS (oficial)
Si esta página y la documentación oficial difieren, prevalece la documentación oficial.