Preguntas frecuentes sobre Amazon ElastiCache

ElastiCache sin servidor es una opción sin servidor que le permite empezar a utilizar una caché en menos de un minuto sin necesidad de aprovisionar la infraestructura ni planificar la capacidad. ElastiCache sin servidor elimina la necesidad de planificar la capacidad, que consume mucho tiempo, ya que supervisa continuamente la utilización de la red, la memoria y el procesamiento de la memoria caché, de modo que pueda escalarse al instante para satisfacer la demanda sin tiempo de inactividad ni degradación del rendimiento. ElastiCache sin servidor replica automáticamente los datos en varias zonas de disponibilidad (AZ) y proporciona a los clientes un acuerdo de nivel de servicio (SLA) de disponibilidad del 99,99 % para cada caché. Con ElastiCache sin servidor, solo paga por los datos que almacena y los recursos de computación que utiliza su aplicación. Para comenzar, cree una caché de ElastiCache sin servidor en tan solo unos pasos. Para ello, especifique un nombre de caché mediante la consola, el kit de desarrollo (SDK) de ElastiCache o la Interfaz de línea de comandos de AWS (AWS CLI).

Puede trasladar una carga de trabajo de ElastiCache existente. Para ello, cambie el punto de conexión de Valkey, Memcached o Redis OSS a un nuevo punto de conexión de caché de ElastiCache sin servidor en la aplicación. Puede migrar los datos de ElastiCache existentes a ElastiCache sin servidor al especificar la ubicación de Amazon Simple Storage Service (Amazon S3) de un archivo de copia de seguridad. Visite nuestra documentación de ElastiCache sin servidor para obtener más información sobre la migración de sus cargas de trabajo.

ElastiCache sin servidor es compatible con la versión 7.2 de Valkey, la versión 1.6.21 de Memcached y la versión 7.0 y superiores de Redis OSS.

ElastiCache sin servidor supervisa continuamente la memoria, el procesamiento y la utilización de la red de la memoria caché para escalarla al instante. ElastiCache sin servidor escala sin tiempo de inactividad ni degradación del rendimiento de la aplicación, ya que permite que la caché escale vertical u horizontalmente en paralelo para cumplir con los requisitos de la aplicación justo a tiempo. Visite nuestra documentación de ElastiCache sin servidor para obtener más información sobre el escalado.

ElastiCache sin servidor almacena automáticamente los datos de forma redundante en varias zonas de disponibilidad y ofrece un Acuerdo de nivel de servicio (SLA) de disponibilidad del 99,99 % para todas las cargas de trabajo.

Con ElastiCache sin servidor, solo paga por los datos que almacena y la computación que utiliza su aplicación. Consulte la página de precios de ElastiCache para obtener más información.

Los nodos reservados o instancias reservadas (RI) le ofrecen un descuento importante en comparación con el uso bajo demanda si se compromete a un periodo de uno o tres años. Con los nodos reservados, puede efectuar un pago inicial único para realizar una reserva por un plazo de uno o tres años, ejecutar la caché en una región específica y recibir un importante descuento en el cargo por hora para un uso constante. Hay tres tipos de nodos reservados (pago total inicial, ningún pago inicial y pago inicial parcial), que le permiten equilibrar el importe del pago inicial con el precio por hora efectivo.

Los nodos reservados ofrecen un descuento que se aplica al uso bajo demanda de ElastiCache. ElastiCache sin servidor no es compatible con los nodos reservados.

Puede comprar hasta 300 nodos reservados. Si desea ejecutar más de 300 nodos, complete el formulario de solicitud de nodos de ElastiCache.

Compre una reserva de nodo con la misma clase de nodo dentro de la misma región en la que se encuentra el nodo que está ejecutando actualmente y que desearía reservar. Si compra la reserva correctamente, ElastiCache aplicará automáticamente el nuevo cargo por uso por hora al nodo existente.

Los cambios de precio asociados con un nodo reservado se activan cuando la solicitud se recibe y mientras se procesa la autorización del pago. Podrá seguir el estado de su reserva en la página Actividad de la cuenta de AWS o mediante la API DescribeReservedCacheNodes. Si el pago único no puede autorizarse correctamente antes del siguiente periodo de facturación, no se aplicará el precio con descuento.

Cuando venza el plazo de reserva, al nodo reservado se le volverá a aplicar la tarifa de uso por hora bajo demanda correspondiente a la clase y región de su nodo reservado.

Las API de ElastiCache para crear, modificar y eliminar nodos no distinguen entre nodos bajo demanda y reservados, por lo que puede utilizar ambos sin problemas. A la hora de calcular su factura, nuestro sistema aplicará de forma automática sus reservas para que todos los nodos que cumplan los requisitos se le cobren según la tarifa horaria más reducida para nodos de caché reservados.

Cada nodo reservado está asociado a una región concreta, que es fija mientras dura la reserva y no puede modificarse. No obstante, las reservas pueden utilizarse en cualquiera de las zonas de disponibilidad disponibles dentro de la región asociada.

No, no puede cancelar la reserva de nodo y el pago único (si procede) tampoco es reembolsable. Seguirá pagando por cada hora durante el período del acuerdo para los nodos reservados, independientemente del uso que haga.

Cuando adquiere un nodo reservado con la opción Pago total anticipado, el plazo completo del nodo reservado se abona en un solo pago anticipado. Elija la opción Sin pago inicial si no desea realizar ningún pago inicial. El valor total del nodo reservado sin pago inicial se distribuye en cada hora del período de vigencia y se le facturará por cada hora durante todo el plazo de la instancia reservada, independientemente del uso. La opción Pago inicial parcial es una combinación de las opciones Pago inicial total y Sin pago inicial. Se efectúa un pequeño pago inicial y se le facturará una tarifa por hora baja por cada hora durante todo el plazo, independientemente del uso.

Sí, los nodos reservados de ElastiCache ofrecen flexibilidad de tamaño dentro de una familia de instancias (o familia de nodos) y una región de AWS. Esto significa que la tarifa de nodos reservados con descuento existente se aplicará automáticamente al uso de todos los tamaños en la misma familia de nodos.

ElastiCache le permite configurar el cifrado de los datos en reposo mediante AWS Key Management Service (AWS KMS), el cifrado de los datos en tránsito mediante la seguridad de la capa de transporte (TLS), la autenticación mediante AWS Identity and Access Management (IAM) y el control de acceso a la red con los grupos de seguridad de Amazon Elastic Compute Cloud (Amazon EC2).

Cuando no se utiliza Amazon Virtual Private Cloud (Amazon VPC), ElastiCache permite controlar el acceso a sus cachés a través de grupos de seguridad de red. Un grupo de seguridad actúa como un firewall, controlando el acceso de red a su caché. De forma predeterminada, el acceso de red a sus cachés está desactivado. Si desea que sus aplicaciones obtengan acceso a su caché, debe habilitar de forma explícita el acceso de los hosts a los grupos de seguridad de Amazon EC2 específicos.

También puede controlar el acceso a los recursos de ElastiCache mediante la autenticación de IAM. Para obtener más información, consulte la documentación sobre la autenticación con IAM.

ElastiCache admite programas de conformidad como SOC 1, SOC 2, SOC 3, ISO, MTCS, C5, PCI DSS, HIPAA y FedRAMP. Consulte “Servicios de AWS en el ámbito del programa de conformidad” para obtener una lista vigente de los programas de cumplimiento compatibles.

Sí, el programa de conformidad PCI de AWS incluye ElastiCache como servicio compatible con PCI. Para obtener más información, consulte los siguientes recursos:

• Conformidad de ElastiCache
• Página de conformidad de AWS PCI

Para consultar la lista actual de programas de cumplimiento en los que se incluye ElastiCache, consulte “Servicios de AWS en el ámbito del programa de conformidad”.

Sí, ElastiCache es un servicio que cumple los requisitos de la HIPAA y está cubierto bajo el Anexo para socios comerciales (BAA) de AWS. Esto significa que puede usar ElastiCache a fin de recibir ayuda para procesar, mantener y almacenar información sanitaria protegida (PHI) y respaldar aplicaciones para el sector sanitario.

No, el uso de estas características no tiene cargo adicional.

Si tiene formalizado un Acuerdo para socio empresarial (BAA) suscrito con AWS, puede usar ElastiCache para crear aplicaciones que almacenen y procesen HI según la HIPAA. Si no es el caso, o si tiene otras preguntas sobre el uso de AWS en las aplicaciones, contáctenos para obtener más información. 

Sí, el programa de conformidad para FedRAMP de AWS incluye a ElastiCache como un servicio autorizado por FedRAMP. Los clientes del gobierno de EE. UU. y sus socios ahora pueden usar la versión más reciente de ElastiCache para procesar y almacenar sus sistemas, datos y cargas de trabajo de misión crítica y de alto impacto del FedRAMP en las regiones AWS GovCloud (Este de EE. UU.) y AWS GovCloud (Oeste de EE. UU.) y en un nivel de impacto moderado en las regiones Este de EE. UU. (Ohio), Este de EE. UU. (Norte de Virginia), Oeste de EE. UU. (Norte de California) y Oeste de EE. UU. (Oregón).

Para obtener más información, consulte los siguientes recursos:

• Conformidad de ElastiCache
• Conformidad con FedRAMP de AWS

Para consultar la lista actual de programas de cumplimiento en los que se incluye ElastiCache, consulte “Servicios de AWS en el ámbito del programa de conformidad”.

ElastiCache proporciona subprocesos de E/S mejorados que ofrecen mejoras significativas en el rendimiento y la latencia a escala mediante la multiplexación, la descarga de capas de presentación y más. Los subprocesos de E/S mejorados mejoran el rendimiento al aprovechar más núcleos para procesar las E/S y ajustarse dinámicamente a la carga de trabajo. ElastiCache mejora el rendimiento de los clústeres habilitados para TLS al descargar el cifrado a los mismos subprocesos de E/S mejorados. La versión 7.2 de ElastiCache para Valkey introdujo una multiplexación de E/S mejorada, que combina numerosas solicitudes de clientes en un único canal y mejora la eficiencia de los subprocesos.

En la versión 7.2 de ElastiCache para Valkey y versiones superiores, ampliamos la funcionalidad mejorada de subprocesos de E/S para también gestionar la lógica de la capa de presentación. Los subprocesos de E/S mejorados, además de leer las entradas de los clientes, las interpretan en un formato de comando binario, que luego se envía al subproceso principal para su ejecución, con el fin de mejorar el rendimiento. Con la versión 7.2 de ElastiCache para Valkey, se puede lograr hasta un 100 % más de rendimiento y un 50 % menos de latencia P99, en comparación con la versión anterior. En r7g.4xlarge o superior, puede lograr más de 1 millón de solicitudes por segundo (RPS) por nodo.

ElastiCache proporciona dos conjuntos diferentes de métricas para medir la utilización de la CPU de la caché en función del despliegue de la caché que elija. Al usar ElastiCache sin servidor, puede supervisar el uso de la CPU con la métrica ElastiCache Processing Units (ECPU). La cantidad de ECPU consumidas por las solicitudes depende del tiempo empleado por la vCPU y de la cantidad de datos transferidos. Cada lectura y escritura, como ocurre con los comandos GET y SET de Valkey o los comandos get y set de Memcached, requiere 1 ECPU por cada kilobyte (KB) de datos transferidos. Algunos comandos que operan sobre estructuras de datos en memoria pueden consumir más tiempo de vCPU que un comando GET o SET. ElastiCache calcula la cantidad de ECPU consumidas en función del tiempo de vCPU que tarda el comando en comparación con una línea de base del tiempo de vCPU que tarda un comando SET o GET. Si el comando requiere más tiempo de vCPU y transfiere más datos que la línea base de 1 ECPU, ElastiCache calcula las ECPU necesarias en función de la dimensión de mayor valor.

Al diseñar su propio clúster, puede supervisar las métricas EngineCPUUtilization y CPUUtilization. La métrica CPUUtilization mide la utilización de la CPU correspondiente a la instancia (nodo), mientras que la métrica EngineCPUUtilization mide la utilización a nivel de proceso del motor. Se necesita la métrica EngineCPUUtilization además de la métrica CPUUtilization, ya que el proceso principal del motor es de un solo subproceso y utiliza únicamente una CPU de los múltiples núcleos de CPU disponibles en una instancia. Por lo tanto, la métrica CPUUtilization no proporciona una visibilidad precisa de las tasas de utilización de la CPU a nivel de proceso. Recomendamos que utilice tanto la métrica CPUUtilization como la métrica EngineCPUUtilization conjuntamente para obtener una comprensión detallada de la utilización de la CPU correspondiente a los clústeres de Valkey.

Ambos conjuntos de métricas están disponibles en todas las regiones de AWS y puede acceder a ellas mediante Amazon CloudWatch o en la Consola. Además, le recomendamos que consulte la documentación a fin de obtener más información sobre métricas útiles para la supervisión del rendimiento.

Las réplicas de lectura tienen dos finalidades:

• Gestión de fallas
• Escalado de la lectura

Cuando ejecuta una caché con una réplica de lectura, la caché principal se ocupa de las escrituras y lecturas. La réplica sirve exclusivamente para tráfico de lectura y también está disponible en espera en caso de que la caché principal falle.

Con ElastiCache sin servidor, el servicio mantiene automáticamente las réplicas de lectura. Al diseñar su propia memoria caché, hay una variedad de escenarios en los que podría tener sentido implementar una o más réplicas de lectura para un nodo principal determinado. Entre los motivos habituales para implementar una réplica de lectura están:

• Escalar más allá de la capacidad de procesamiento o E/S de un único nodo principal para cargas de trabajo con mucha lectura: Este exceso de tráfico de lectura se puede dirigir a una o más réplicas de lectura.
• Atender el tráfico de lectura mientras el principal no está disponible: Si el nodo principal no puede recopilar solicitudes de E/S (por ejemplo, debido a la suspensión de E/S para las copias de seguridad o un mantenimiento programado), podrá dirigir el tráfico de lectura hacia las réplicas de lectura. Para este caso de uso, debe tener en cuenta que tal vez los datos situados en la réplica de lectura sean obsoletos, ya que la instancia principal no está disponible. La réplica de lectura también puede utilizarse para reiniciar la preparación de la instancia principal que ha dado error.

Escenarios de protección de datos: En el caso poco probable de que falle el nodo principal o que la zona de disponibilidad en la que reside el nodo principal no se encuentre disponible, puede definir una réplica de lectura que se encuentre en una zona de disponibilidad diferente para que se convierta en la nueva principal.

Puede conectarse a una réplica de lectura del mismo modo que lo haría con un nodo de caché principal. Si cuenta con varias réplicas de lectura es decisión de su aplicación determinar la cantidad de tráfico que se distribuirá entre ellas. Aquí puede encontrar más información:

• En clústeres Valkey o Redis (modo clúster desactivado) OSS, utilice los puntos de conexión de cada nodo para las operaciones de lectura. (En la API/CLI, se denominan puntos de enlace de lectura).
• En clústeres Valkey o Redis OSS (modo clúster activado), utilice el punto de conexión de configuración del clúster para todas las operaciones. Aún puede leer desde puntos de enlace de nodos individuales. (En la API y la CLI, se denominan puntos de conexión de lectura).

ElastiCache le permite crear hasta cinco (5) réplicas de lectura para un nodo de caché principal determinado.

En caso de producirse una conmutación por error, las réplicas de lectura asociadas y disponibles deberán reanudar automáticamente la replicación una vez completada la conmutación por error (adquiriendo las actualizaciones de la réplica de lectura que se acaba de promocionar).

Las actualizaciones realizadas en un nodo de caché principal se replicarán automáticamente en las réplicas de lectura asociadas. Sin embargo, con la tecnología de replicación asíncrona de Valkey o Redis OSS, una réplica de lectura se puede quedar rezagada con respecto a su nodo de caché principal por diversas razones. Algunos motivos habituales son:

• El volumen de E/S de escritura para el nodo de caché principal supera la tasa a la que se pueden aplicar los cambios a la réplica de lectura.
• La latencia o las particiones de red entre el nodo de caché principal y una réplica de lectura.

Las réplicas de lectura están sujetas a las fortalezas y debilidades de la replicación de Valkey o Redis OSS. Si utiliza réplicas de lectura, debe ser consciente de los retrasos que pueden producirse entre una réplica de lectura y su nodo de caché principal, lo que también se conoce como “incoherencia”. ElastiCache emite una métrica para ayudarlo a entender la inconsistencia.

Las réplicas de lectura se facturan como un nodo de caché estándar y con las mismas tarifas. Al igual que un nodo de caché estándar, la tarifa por hora de nodo de caché para una réplica de lectura depende de la clase de nodo de caché de la réplica de lectura: consulte la página de precios de ElastiCache para conocer los precios actualizados. No se le cobrarán las transferencias de datos que realice durante la replicación de datos entre su nodo de caché principal y la réplica de lectura. La facturación de una réplica de lectura comienza en cuanto la réplica de lectura se creó con éxito (es decir, cuando el estado aparece como activo). La réplica de lectura se seguirá facturando con las tarifas por hora por nodo de caché de ElastiCache hasta que emita un comando para eliminarla.

ElastiCache admite la conmutación por error iniciada, por lo que puede reanudar operaciones de la caché tan rápido como sea posible. Durante la conmutación por error, ElastiCache cambia el registro DNS de su nodo de caché para que apunte a la réplica de lectura, que a su vez se define como el nuevo nodo principal. Le sugerimos que siga las prácticas recomendadas e implemente el reintento de conexión de nodo de caché en la capa de la aplicación. Por lo general, de principio a fin, los pasos uno a cinco que se indican a continuación se completan en seis minutos.

Estos son los eventos de conmutación por error automática, enumerados por orden de aparición:

1. Mensaje de grupo de replicación: API de prueba de conmutación por error solicitada para el grupo de nodos <node-group-id>
2. Mensaje de clúster de caché: se ha completado la conmutación por error del nodo principal <primary-node-id> al nodo de réplica <node-id>
3. Mensaje de grupo de replicación: se ha completado la conmutación por error del nodo principal <primary-node-id> al nodo de réplica <node-id>
4. Mensaje de clúster de caché: recuperando los nodos de caché <node-id>
5. Mensaje del clúster de caché: Recuperación de los nodos de caché <node-id> finalizada

No. La réplica de lectura solo se puede aprovisionar en la misma zona de disponibilidad o en una diferente de la misma región que el nodo de caché principal. Sin embargo, puede utilizar el Global Datastore para trabajar con una replicación completamente administrada, rápida, de confianza y centrada en la seguridad en todas las regiones de AWS. Con esta característica, puede crear clústeres de réplicas de lectura entre regiones para que ElastiCache permita lecturas de baja latencia y la recuperación ante desastres en todas las regiones de AWS.

Sí. Puede agregar o eliminar una réplica de lectura en una o más particiones en un entorno de clúster. El clúster permanece en línea y proporciona el servicio de E/S mientras se realiza esta operación.

Multi-AZ es una característica que le permite ejecutar una configuración de mayor disponibilidad al diseñar su propia caché de ElastiCache. Todas las cachés de ElastiCache sin servidor se ejecutan automáticamente en una configuración Multi-AZ. Los grupos de replicación de ElastiCache se componen de un nodo principal y hasta cinco réplicas de lectura. Si Multi-AZ está habilitado, se requiere al menos una réplica por nódulo principal. Durante ciertas tareas de mantenimiento planificadas, o en el caso poco probable de que se produzca un error en el nodo de ElastiCache o en la zona de disponibilidad, ElastiCache detectará automáticamente el error del nodo principal, seleccionará una réplica de lectura y la convertirá en el nuevo nodo principal. ElastiCache también propaga los cambios de DNS de la réplica de lectura elevada, de modo que si su aplicación está escribiendo en el punto de enlace del nodo principal, no será necesario efectuar ningún cambio en dicho punto de enlace.

Los beneficios principales de ejecutar ElastiCache en modo Multi-AZ son el incremento de la disponibilidad y una reducción de las tareas de administración necesarias. Al ejecutar ElastiCache en una configuración Multi-AZ, sus cachés cumplen los requisitos para el SLA de disponibilidad del 99,99 %. Si se produce un error en el nodo principal de ElastiCache, las restricciones de lectura y escritura en el nodo principal dependerán del tiempo que tarde en completarse la conmutación por error automática. Cuando la opción Multi-AZ está activada, la conmutación por error del nodo de ElastiCache se efectúa de manera automática, sin administración.

Puede hacer uso de Multi-AZ si está utilizando ElastiCache y dispone de un grupo de replicación compuesto de un nodo principal, o de una o más réplicas de lectura. Si se produce un error en el nodo principal, ElastiCache lo detectará de manera automática, seleccionará una réplica de lectura disponible y la definirá como nuevo nodo principal. ElastiCache propagará los cambios de DNS de la réplica definida para que su aplicación pueda seguir escribiendo en el punto de enlace del nodo principal. Asimismo, ElastiCache configurará un nuevo nodo para que sustituya a la réplica de lectura promovida en la misma zona de disponibilidad en la que se encuentra el nodo principal donde se produjo el error. Si el fallo del nodo principal se debe a una interrupción temporal de la zona de disponibilidad, la nueva réplica se lanzará una vez que la zona de disponibilidad se haya recuperado.

Sí. Tenga en cuenta que si coloca el nodo principal y las réplicas en la misma zona de disponibilidad, su grupo de replicación de ElastiCache se puede ver afectado por las interrupciones de la zona de disponibilidad.

ElastiCache realizará una conmutación por error a una réplica de lectura si sucede lo siguiente:

• Pérdida de disponibilidad en la zona de disponibilidad del nodo principal
• Pérdida de conectividad de red a principal
• Error de unidad informática en principal

Si hay más de una réplica de lectura, se promoverá aquella con menor retardo de replicación asíncrona respecto a la principal.

Sí, ElastiCache creará un evento para informarle de que se ha efectuado una conmutación por error automática. Puede utilizar la API DescribeEvents para devolver información sobre los eventos relacionados con su nodo de ElastiCache o seleccionar la sección “Eventos” (eventos) en la consola de administración de ElastiCache.

Las AZ están diseñadas para ofrecer conectividad de red de baja latencia con otras AZ que se encuentren dentro de la misma región. Debe considerar la posibilidad de diseñar su aplicación y otros recursos de AWS con redundancia entre varias zonas de disponibilidad, de forma que su aplicación sea sólida en caso de producirse una interrupción en una zona de disponibilidad.

Para obtener más información sobre Multi-AZ, consulte la documentación de ElastiCache.

Copia de seguridad y restauración es una característica que le permite crear instantáneas de las cachés de ElastiCache. ElastiCache almacena las instantáneas a fin de que los usuarios puedan utilizarlas posteriormente para restablecer cachés. En la actualidad, esto se admite con ElastiCache para Valkey, ElastiCache para Redis OSS y sin servidor.

La creación de instantáneas puede resultar útil en caso de que se produzcan pérdidas de datos por errores en los nodos o en el caso poco frecuente de que el hardware presente algún error. Las copias de seguridad también suelen utilizarse con fines de archivado. Las snapshots se almacenan en Amazon S3.

Sí, puede exportar sus instantáneas de ElastiCache a un bucket de S3 autorizado situado en la misma región que su caché.

Sí. Primero debe copiar la instantánea al bucket de S3 autorizado que desee y que esté ubicado en la misma región. A continuación, conceda permisos de cuenta cruzada de acceso al bucket a la otra cuenta.

ElastiCache ofrece espacio de almacenamiento gratuito para una instantánea por cada caché activa de ElastiCache. El almacenamiento adicional se cobrará en función del espacio utilizado por las instantáneas, a un precio de 0,085 USD/GB al mes (el mismo precio en todas las regiones). Las transferencias de datos por utilizar las snapshots son gratuitas.

Cuando se elimina una caché de ElastiCache, las instantáneas manuales se retienen. También tendrá la opción de crear una instantánea final antes de la eliminación de la caché. En cambio, las snapshots de caché automáticas no se retienen.

El motor dentro de ElastiCache es plenamente compatible con Valkey y Redis OSS, pero además cuenta con mejoras que aumentan el rendimiento, la robustez y la estabilidad. Entre las mejoras se encuentra lo siguiente:

• Más memoria utilizable: Ya puede asignar con seguridad más memoria a su aplicación sin arriesgar el incremento de uso de intercambio durante sincronizaciones y snapshots.
• Sincronización mejorada: sincronización más sólida con cargas intensivas y al recuperarse de pérdidas de conexiones a la red. Además, las sincronizaciones son más rápidas, ya que el nodo principal y las réplicas de lectura no utilizan el disco para realizar la operación.
• Conmutaciones por error más sencillas: si se produce una conmutación por error, la partición se recupera con mayor rapidez, ya que las réplicas de lectura no vacían sus datos para volver a sincronizarlo todo con el nodo principal.
• Descarga de TLS y multiplexación de E/S: ElastiCache está diseñado para utilizar mejor los recursos de CPU disponibles mediante la gestión de determinados procesos relacionados con la red en subprocesos dedicados.

El motor mejorado es plenamente compatible con Valkey o Redis OSS, por lo que podrá disfrutar de su robustez y estabilidad mejoradas sin necesidad de realizar ningún cambio en el código de la aplicación.

El uso del motor mejorado no conlleva cargos adicionales.

El cifrado en tránsito, el cifrado en reposo, AUTH de Valkey y el control de acceso basado en roles (RBAC) son características que se pueden seleccionar al crear la caché de ElastiCache. Si ha habilitado el cifrado en tránsito, puede optar por utilizar AUTH o RBAC para obtener mayor seguridad y control de acceso.

El cifrado en reposo ofrece mecanismos de protección contra el acceso no autorizado a los datos. Cuando está activado, cifra los siguientes aspectos:

• El disco durante las operaciones de sincronización, copia de seguridad e intercambio
• Copias de seguridad en Amazon S3

ElastiCache ofrece un cifrado predeterminado (administrado por el servicio) en reposo, así como la posibilidad de utilizar sus propias claves simétricas de AWS KMS administradas por el cliente en AWS KMS. Visite cifrado en reposo para obtener más información.

La característica de cifrado en tránsito facilita el cifrado de las comunicaciones entre los clientes y ElastiCache, así como entre los servidores (réplicas principales y de lectura). Obtenga más información sobre el cifrado en tránsito de ElastiCache.

No, ElastiCache administra el vencimiento y la renovación de certificados en segundo plano. El usuario no debe realizar ninguna acción para el mantenimiento continuo de certificados.

No, no se aplican cargos adicionales por el uso del cifrado.

El almacén de datos global es una característica de ElastiCache que ofrece un servicio de replicación entre regiones completamente administrado, rápido, fiable y centrado en la seguridad. Con Global Datastore, puede escribir en su caché en una región y disponer de los datos para su lectura en otros dos clústeres replicados en regiones diferentes. De este modo, es posible realizar lecturas de baja latencia y hacer recuperaciones ante desastres entre regiones.

Global Datastore, diseñado para aplicaciones en tiempo real con presencia global, suele replicar los datos entre regiones en menos de un segundo, lo que aumenta la respuesta de las aplicaciones al brindar lecturas más cercanas geográficamente a los usuarios finales. En el improbable caso de que una región se deteriore, se puede ascender a caché principal a una de las cachés de réplica entre regiones que esté en buen estado y otorgarle funciones completas de lectura y escritura. Una vez que se inicia, este cambio se completa normalmente en menos de un minuto, de forma que sus aplicaciones siguen estando disponibles.

Con Global Datastore, puede realizar replicaciones en hasta dos regiones secundarias. En el improbable caso de que una región se vea afectada, se pueden usar las cachés de regiones secundarias para atender lecturas locales de baja latencia y casos de recuperación de desastres.

El almacén de datos global se admite en la versión 7.2 de ElastiCache para Valkey y a partir de la versión 5.0.6 de ElastiCache para Redis OSS.

Para configurar un almacén de Global Datastore, puede usar una caché existente o crear una caché nueva para usarlo como principal. Puede crear un Global Datastore con solo unos pasos en la consola de administración de ElastiCache o si descarga el SDK o la versión de AWS CLI más recientes. Global Datastore es compatible con AWS CloudFormation.

No, ElastiCache no convierte automáticamente un clúster secundario en principal cuando un clúster principal (región) presenta problemas. Para iniciar manualmente la conmutación por error, debe convertir un clúster secundario en principal. Normalmente, la conmutación por error y la promoción de un clúster secundario demora menos de un minuto.

ElastiCache no aplica ningún cargo adicional por el uso de Global Datastore. Debe pagar por las cachés principales y secundarias de Global Datastore y por el tráfico de transferencia de datos entre regiones.

ElastiCache no ofrece un SLA para RPO ni RTO. El objetivo de punto de recuperación varía en función del retraso de la replicación entre regiones y depende de la latencia de red entre las regiones y de la congestión del tráfico de la red entre regiones. El RPO de Global Datastore normalmente es menor a un segundo, por lo que los datos que se escriben en una región principal quedan a disposición en las regiones secundarias en menos de un segundo. El objetivo de tiempo de recuperación de Global Datastore generalmente es inferior a un minuto. Cuando se inicia la conmutación por error a un clúster secundario, ElastiCache normalmente otorga al clúster secundario capacidades de lectura y escritura plenas en menos de un minuto.

Aunque no hay una respuesta precisa para esta pregunta, con ElastiCache, no es necesario que se preocupe por obtener el número preciso de nodos, ya que puede agregar o eliminar de forma rápida los nodos posteriormente. También puede usar ElastiCache sin servidor para simplificar la ejecución de una caché de Memcached de alta disponibilidad. Al seleccionar la configuración inicial, pueden tenerse en cuenta los siguientes dos aspectos interrelacionados:

• La memoria total necesaria para que los datos consigan la tasa de aciertos de caché de destino.
• El número de nodos necesarios para mantener un rendimiento aceptable de las aplicaciones sin sobrecargar el back-end de base de datos en caso de error del nodo.

El volumen de memoria necesario depende del tamaño del conjunto de datos y de los patrones de acceso de la aplicación. Para mejorar la tolerancia a errores, cuando tenga una idea aproximada de la memoria total necesaria, divida la memoria en los nodos suficientes para que la aplicación pueda continuar funcionando a pesar de la pérdida de uno o dos nodos. Por ejemplo, si el requisito de memoria es 13 GB, convendría utilizar dos nodos cache.m4.large en lugar de utilizar un nodo cache.m4.xlarge. Es importante que otros sistemas como las bases de datos no se sobrecarguen si la tasa de aciertos de caché se reduce temporalmente durante la recuperación de errores de uno o varios nodos. Consulte la Guía del usuario de ElastiCache para obtener más detalles.

Sí. A la hora de crear un clúster o agregar nodos a un clúster ya existente, puede elegir las zonas de disponibilidad para los nuevos nodos. Puede especificar la cantidad solicitada de nodos en cada zona de disponibilidad, o bien, seleccionar Distribuir nodos a todas las zonas. Si el clúster está en Amazon VPC, los nodos solo se pueden ubicar en zonas de disponibilidad que formen parte del grupo de subred de la caché seleccionada. Para obtener más detalles, consulte la documentación de la VPC de ElastiCache.

Puede ejecutar un máximo de 300 nodos por región. Si necesita más nodos, complete el formulario de solicitud de aumento de límite de ElastiCache.

El servicio detecta el error del nodo y reacciona efectuando los siguientes pasos automáticos:

• ElastiCache reparará el nodo mediante la adquisición de nuevos recursos de servicio y, a continuación, redireccionará el nombre DNS existente del nodo para que remita a los nuevos recursos de servicio. En el caso de las instalaciones de Amazon VPC, ElastiCache se asegurará de que el nombre DNS y la dirección IP del nodo sean iguales cuando los nodos se recuperen tras un error. En las instalaciones que no son de VPC, ElastiCache garantiza que el nombre DNS de un nodo no cambie; sin embargo, la dirección IP subyacente del nodo puede cambiar.
• Si ha asociado un tema de SNS con el clúster, cuando el nuevo nodo esté configurado y listo para utilizarse, ElastiCache enviará una notificación de SNS para informarle que se ha producido la recuperación del nodo. Esto permite opcionalmente disponer las aplicaciones para forzar que la biblioteca del cliente de Memcached intente volver a conectarse con los nodos reparados. Esto podría ser importante, ya que algunas bibliotecas de Memcached dejarán de utilizar un servidor (nodo) indefinidamente si detectan errores de comunicación o tiempos de espera con dicho servidor.

Puede agregar más nodos al clúster de Memcached existente mediante la opción “Agregar nodo” de la pestaña “Nodos” de su clúster de caché en la consola o mediante una llamada a la API ModifyCacheCluster.

ElastiCache es idóneo como front-end para servicios de Amazon Web Services, por ejemplo, Amazon RDS y DynamoDB, ya que proporciona una latencia extremadamente baja para aplicaciones de alto rendimiento y descarga parte del volumen de solicitudes mientras estos servicios proporcionan una durabilidad de los datos a largo plazo. Asimismo, el servicio se puede utilizar para mejorar el rendimiento de aplicaciones en conjunto con Amazon EC2 y Amazon EMR.

Las bibliotecas de cliente de Memcached están disponibles para muchos de los lenguajes de programación conocidos, si no para todos. Si al utilizar ElastiCache, detecta algún problema con los clientes específicos de Memcached, consúltenos a través del foro de la comunidad de ElastiCache.

ElastiCache no requiere bibliotecas cliente específicas y funciona con las bibliotecas cliente de Memcached existentes sin necesidad de volver a compilarlas ni volver a vincular las aplicaciones (Memcached 1.4.5 y versiones posteriores). Algunos ejemplos son libMemcached (C) y bibliotecas basadas en él (por ejemplo, PHP, Perl, Python), spyMemcached (Java) y fauna (Ruby).

La detección automática es una característica que ahorra tiempo y esfuerzo a los desarrolladores, a la vez que reduce la complejidad de las aplicaciones. La detección automática permite que los clientes detecten automáticamente los nodos de caché cuando se agregan o eliminan de un clúster de ElastiCache. Antes, para gestionar los cambios de la pertenencia al clúster, los desarrolladores tenían que actualizar manualmente la lista de puntos de conexión de los nodos de caché. Aunque depende de cómo esté diseñada la aplicación cliente, suele ser necesario inicializar el cliente, apagando o restaurando la aplicación, por lo que se experimentan tiempos de inactividad. Mediante la detección automática, ElastiCache elimina esta complejidad. Con la detección automática, además de disponer de compatibilidad retroactiva con el protocolo de Memcached, ElastiCache facilita a los clientes información sobre la pertenencia a clústeres de caché. Un cliente capaz de procesar la información adicional se reconfigura por sí solo, sin necesidad de tener que inicializarlo, para poder utilizar los nodos más actualizados de un clúster de ElastiCache.

Un clúster de ElastiCache se puede crear con nodos direccionables mediante puntos de conexión designados. Con la detección automática, al clúster de ElastiCache se le asigna también un punto de conexión de configuración único, que es un registro DNS válido durante toda la vida útil del clúster. Este registro DNS contiene los nombres DNS de los nodos que pertenecen al clúster. ElastiCache garantizará que el punto de conexión de configuración siempre remita al menos a uno de estos nodos de destino. Luego, una consulta al nodo de destino devuelve los puntos de conexión para todos los nodos del clúster en cuestión. Después de esto, puede conectarse a los nodos del clúster como antes y utilizar los comandos del protocolo de Memcached, como get, set, incr y decr. Para obtener más detalles, consulte la documentación. Para utilizar la detección automática necesita un cliente que admita esta característica. Los clientes de detección automática para Java y PHP pueden descargarse de la consola de ElastiCache. Tras la inicialización, el cliente determinará automáticamente los miembros actuales del clúster de ElastiCache mediante el uso del punto de conexión de configuración. Al realizar cambios en el clúster de caché mediante la adición o eliminación de nodos o al reemplazar un nodo por la presencia de errores, el cliente de la detección automática determina automáticamente los cambios, con lo que no es necesario que inicialice los clientes manualmente.

Para comenzar, descargue el cliente del clúster de ElastiCache. Para ello, haga clic en el enlace Descargar el cliente del clúster de ElastiCache de la consola de ElastiCache. Para poder realizar la descarga, debe disponer de una cuenta de ElastiCache. Si aún no la tiene, puede inscribirse en la página de detalles de ElastiCache. Después de descargar el cliente, visite la consola de ElastiCache para comenzar a configurar y activar el clúster de ElastiCache. Se pueden encontrar más detalles en la documentación.

Sí, puede dejar de utilizar la detección automática cuando lo desee. Puede desactivar la detección automática si especifica el modo de operación durante la inicialización del cliente del clúster de ElastiCache. Asimismo, habida cuenta de que ElastiCache continúa admitiendo totalmente Memcached, puede utilizar como antes cualquier cliente compatible en protocolo de Memcached.

Para poder beneficiarse de la detección automática, se debe utilizar un cliente compatible con esta característica para establecer conexión con un clúster de ElastiCache. Actualmente, ElastiCache admite clientes con capacidad de detección automática para .Net, Java y PHP. Estos clientes pueden descargarse desde la consola de ElastiCache. Puede crear clientes para cualquier otro lenguaje basándose en los clientes conocidos de Memcached que se encuentren disponibles.

Puede utilizar cualquier biblioteca de clientes de Memcached y añadirle compatibilidad para la detección automática. Si desea añadir o modificar su propio cliente para habilitar la detección automática, consulte la documentación sobre el conjunto de comandos de detección automática.

Sí, ElastiCache aún es compatible con el protocolo de Memcached y no requiere que modifique sus clientes. Sin embargo, para aprovechar la característica de detección automática, hemos mejorado las capacidades del cliente de Memcached. Si prefiere no utilizar el cliente del clúster de ElastiCache, puede continuar utilizando sus propios clientes o modificar la biblioteca de clientes de la que dispone para entender el conjunto de comandos de detección automática.
 

Sí, el mismo clúster de ElastiCache se puede conectar al mismo tiempo a través de un cliente compatible con la detección automática y de un cliente de Memcached tradicional. ElastiCache sigue siendo totalmente compatible con Memcached.

Sí, puede dejar de utilizar la detección automática cuando lo desee. Puede desactivar la detección automática si especifica el modo de operación durante la inicialización del cliente del clúster de ElastiCache. Asimismo, habida cuenta de que ElastiCache continúa admitiendo totalmente Memcached, puede utilizar como antes cualquier cliente compatible en protocolo de Memcached.

ElastiCache permite controlar la situación y el momento en que el software compatible con el protocolo de Memcached con el que funciona su clúster se actualizará a nuevas versiones compatibles con ElastiCache. Esto le ofrece la flexibilidad necesaria para mantener la compatibilidad con versiones concretas de Memcached, probar nuevas versiones con su aplicación antes de implementarlas en producción y actualizar las versiones según sus plazos y condiciones. Dado que las actualizaciones de versiones principales implican ciertos riesgos de compatibilidad, no se realizarán de forma automática y deberá iniciarlas usted. Este enfoque de aplicación de parches de software le da control sobre las actualizaciones de versión, pero le deja el trabajo de aplicación de parches a ElastiCache. Encontrará más información sobre la administración de versiones en las preguntas frecuentes que aparecen a continuación. Si lo prefiere, puede consultar la Guía del usuario de ElastiCache. Aunque la funcionalidad de administración de versiones del motor está pensada para ofrecerle el máximo control posible sobre la aplicación de parches, podemos revisar por usted el clúster si determinamos que existe alguna vulnerabilidad de seguridad en el sistema o software de la caché.

Puede especificar cualquier versión admitida (secundaria o principal) al crear un nuevo clúster. Si desea iniciar una actualización a una versión de motor admitida, puede hacerlo a través de la opción Modificar para el clúster. Especifique la versión que desea actualizar a través del campo “Versión del motor de caché”. Posteriormente, la actualización se aplicará en su nombre de forma inmediata (si la opción “Aplicado de inmediato” está seleccionada) o durante el siguiente periodo de mantenimiento programado para su clúster.

Sí. Debe crear un nuevo clúster con la nueva versión del motor de caché. Puede hacer que su aplicación de desarrollo u organización en fases remita a este clúster, probarlo y decidir si actualizar o no el clúster original.

Planeamos admitir versiones de Memcached adicionales para ElastiCache, tanto principales como secundarias. El número de lanzamientos de nuevas versiones admitidas en un año determinado variará en función de la frecuencia y el contenido de las versiones de Memcached, así como del resultado de un minucioso análisis del lanzamiento por parte de nuestro equipo de ingeniería.

Puede actualizar su clúster de Memcached existente mediante el proceso de modificación. Cuando actualice de una versión anterior de Memcached a la versión 1.4.33 u otra posterior, asegúrese de que los valores “max_chunk_size” de los parámetros existentes cumplan las condiciones necesarias para el parámetro “slab_chunk_max”. Consulte los requisitos previos de actualización.

ElastiCache proporciona subprocesos de E/S mejorados que ofrecen mejoras significativas en el rendimiento y la latencia a escala mediante la multiplexación, la descarga de capas de presentación y más. Los subprocesos de E/S mejorados mejoran el rendimiento al aprovechar más núcleos para procesar las E/S y ajustarse dinámicamente a la carga de trabajo. ElastiCache mejora el rendimiento de los clústeres habilitados para TLS al descargar el cifrado a los mismos subprocesos de E/S mejorados. La versión 7.0 de ElastiCache (Redis OSS) introdujo una multiplexación de E/S mejorada, que combina numerosas solicitudes de clientes en un único canal y mejora la eficiencia de los subprocesos.

En la versión 7.1 y versiones superiores de ElastiCache para Redis OSS, ampliamos la funcionalidad mejorada de subprocesos de E/S para también manejar la lógica de la capa de presentación. Los subprocesos de E/S mejorados, además de leer las entradas de los clientes, las interpretan en un formato de comando binario, que luego se envía al subproceso principal para su ejecución, con el fin de mejorar el rendimiento. Con la versión 7.1 de ElastiCache para Redis OSS, se puede lograr hasta un 100 % más de rendimiento y un 50 % menos de latencia P99, en comparación con la versión anterior. En r7g.4xlarge o superior, puede lograr más de 1 millón de solicitudes por segundo (RPS) por nodo.

ElastiCache proporciona dos conjuntos diferentes de métricas para medir la utilización de la CPU de la caché en función del despliegue de la caché que elija. Al usar ElastiCache sin servidor, puede supervisar el uso de la CPU con la métrica ElastiCache Processing Units (ECPU). La cantidad de ECPU consumidas por las solicitudes depende del tiempo empleado por la vCPU y de la cantidad de datos transferidos. Cada lectura y escritura, como los comandos GET y SET de Redis OSS o los comandos get y set de Memcached, requiere 1 ECPU por cada kilobyte (KB) de datos transferidos. Algunos comandos de Redis OSS que operan en estructuras de datos en memoria pueden consumir más tiempo de vCPU que un comando GET o SET. ElastiCache calcula la cantidad de ECPU consumidas en función del tiempo de vCPU que tarda el comando en comparación con una línea de base del tiempo de vCPU que tarda un comando SET o GET. Si el comando requiere más tiempo de vCPU y transfiere más datos que la línea base de 1 ECPU, ElastiCache calcula las ECPU necesarias en función de la dimensión de mayor valor.

Al diseñar su propio clúster, puede supervisar las métricas EngineCPUUtilization y CPUUtilization. La métrica CPUUtilization mide la utilización de la CPU correspondiente a la instancia (nodo), mientras que la métrica EngineCPUUtilization mide la utilización a nivel de proceso del motor. Necesita la métrica EngineCPUUtilization además de la métrica CPUUtilization, ya que el proceso principal de Redis OSS tiene un único subproceso y usa solamente una CPU de los múltiples núcleos de CPU disponibles en una instancia. Por lo tanto, la métrica CPUUtilization no proporciona una visibilidad precisa de las tasas de utilización de la CPU a nivel de proceso del motor. Recomendamos usar la métrica CPUUtilization junto con la EngineCPUUtilization para obtener datos detallados sobre la utilización de CPU de sus clústeres de Redis OSS.

Ambos conjuntos de métricas están disponibles en todas las regiones de AWS y puede acceder a ellas a través de Amazon CloudWatch o de la Consola. Además, recomendamos que consulte la documentación para obtener más información sobre métricas útiles para la supervisión del rendimiento.

Las réplicas de lectura tienen dos propósitos en Redis OSS:

• Gestión de fallas
• Escalado de la lectura

Cuando ejecuta una caché con una réplica de lectura, la caché principal se ocupa de las escrituras y lecturas. La réplica sirve exclusivamente para tráfico de lectura y también está disponible en espera en caso de que la caché principal falle.

Con ElastiCache sin servidor, el servicio mantiene automáticamente las réplicas de lectura. Al diseñar su propia memoria caché, hay una variedad de escenarios en los que podría tener sentido implementar una o más réplicas de lectura para un nodo principal determinado. Entre los motivos habituales para implementar una réplica de lectura están:

• Escalar más allá de la capacidad de procesamiento o E/S de un único nodo principal para cargas de trabajo con mucha lectura: Este exceso de tráfico de lectura se puede dirigir a una o más réplicas de lectura.
• Atender el tráfico de lectura mientras el principal no está disponible: Si el nodo principal no puede recopilar solicitudes de E/S (por ejemplo, debido a la suspensión de E/S para las copias de seguridad o un mantenimiento programado), podrá dirigir el tráfico de lectura hacia las réplicas de lectura. Para este caso de uso, debe tener en cuenta que tal vez los datos situados en la réplica de lectura sean obsoletos, ya que la instancia principal no está disponible. La réplica de lectura también puede utilizarse para reiniciar la preparación de la instancia principal que ha dado error.
• Escenarios de protección de datos: En el caso poco probable de que falle el nodo principal o que la zona de disponibilidad en la que reside el nodo principal no se encuentre disponible, puede definir una réplica de lectura que se encuentre en una zona de disponibilidad diferente para que se convierta en la nueva principal. 

Puede conectarse a una réplica de lectura del mismo modo que lo haría con un nodo de caché principal. Si cuenta con varias réplicas de lectura es decisión de su aplicación determinar la cantidad de tráfico que se distribuirá entre ellas. Aquí puede encontrar más información:

• Los clústeres de Redis OSS (modo de clúster desactivado) utilizan los puntos de enlace de los nodos individuales para las operaciones de lectura. (En la API/CLI, se denominan puntos de enlace de lectura).
• Para los clústeres de Redis OSS (modo clúster habilitado) utilice el punto de enlace de configuración del clúster para todas las operaciones. Aún puede leer desde puntos de enlace de nodos individuales. (En la API y la CLI, se denominan puntos de conexión de lectura).

ElastiCache le permite crear hasta cinco (5) réplicas de lectura para un nodo de caché principal determinado.

En caso de producirse una conmutación por error, las réplicas de lectura asociadas y disponibles deberán reanudar automáticamente la replicación una vez completada la conmutación por error (adquiriendo las actualizaciones de la réplica de lectura que se acaba de promocionar).

Las actualizaciones realizadas en un nodo de caché principal se replicarán automáticamente en las réplicas de lectura asociadas. Sin embargo, con la tecnología de replicación asincrónica de Redis OSS, una réplica de lectura puede quedar retrasada respecto a su nodo de caché principal por diversas razones. Algunos motivos habituales son:

• El volumen de E/S de escritura para el nodo de caché principal supera la tasa a la que se pueden aplicar los cambios a la réplica de lectura.
• La latencia o las particiones de red entre el nodo de caché principal y una réplica de lectura.

Las réplicas de lectura están sujetas a las fortalezas y a las debilidades de la replicación de Redis OSS. Si utiliza réplicas de lectura, debe ser consciente de los retrasos que pueden producirse entre una réplica de lectura y su nodo de caché principal, lo que también se conoce como “incoherencia”. ElastiCache emite una métrica para ayudar a entender la inconsistencia.

Las réplicas de lectura se facturan como un nodo de caché estándar y con las mismas tarifas. De la misma forma que en un nodo de caché estándar, la tarifa por hora de nodo de caché para una réplica de lectura se determina según la clase de nodo de caché de la réplica de lectura. Visite la página de precios de ElastiCache para conocer los precios actualizados. No se le cobrarán las transferencias de datos que realice durante la replicación de datos entre su nodo de caché principal y la réplica de lectura. La facturación de una réplica de lectura comienza en cuanto la réplica de lectura se creó con éxito (es decir, cuando el estado aparece como activo). La réplica de lectura se seguirá facturando con las tarifas por hora por nodo de caché de ElastiCache hasta que emita un comando para eliminarla.

ElastiCache admite la conmutación por error iniciada, por lo que puede reanudar operaciones de la caché tan rápido como sea posible. Durante la conmutación por error, ElastiCache cambia el registro DNS de su nodo de caché para que apunte a la réplica de lectura, que a su vez se define como el nuevo nodo principal. Le sugerimos que siga las prácticas recomendadas e implemente el reintento de conexión de nodo de caché en la capa de la aplicación. Por lo general, de principio a fin, los pasos uno a cinco que se indican a continuación se completan en seis minutos.

Estos son los eventos de conmutación por error automática, enumerados por orden de aparición:

1. Mensaje de grupo de replicación: API de prueba de conmutación por error solicitada para el grupo de nodos <node-group-id>
2. Mensaje de clúster de caché: se ha completado la conmutación por error del nodo principal <primary-node-id> al nodo de réplica <node-id>
3. Mensaje de grupo de replicación: se ha completado la conmutación por error del nodo principal <primary-node-id> al nodo de réplica <node-id>
4. Mensaje de clúster de caché: recuperando los nodos de caché <node-id>
5. Mensaje del clúster de caché: Recuperación de los nodos de caché <node-id> finalizada

No. La réplica de lectura solo se puede aprovisionar en la misma zona de disponibilidad o en una diferente de la misma región que el nodo de caché principal. Sin embargo, puede utilizar el Global Datastore para trabajar con una replicación completamente administrada, rápida, fiable y centrada en la seguridad en todas las regiones de AWS. Con esta característica, puede crear clústeres de réplicas de lectura entre regiones para que ElastiCache permita lecturas de baja latencia y la recuperación ante desastres en todas las regiones de AWS.

Sí. Sí, puede obtener información sobre la ubicación en la que se encuentra su nodo principal actual mediante la consola o la API DescribeCacheClusters.

Sí. Puede agregar o eliminar una réplica de lectura en una o más particiones en un entorno de clúster. El clúster permanece en línea y proporciona el servicio de E/S mientras se realiza esta operación.

Multi-AZ es una característica que le permite ejecutar una configuración de mayor disponibilidad al diseñar su propia caché de ElastiCache. Todas las cachés de ElastiCache sin servidor se ejecutan automáticamente en una configuración Multi-AZ. Los grupos de replicación de ElastiCache se componen de un nodo principal y hasta cinco réplicas de lectura. Si Multi-AZ está habilitado, se requiere al menos una réplica por nódulo principal. Durante ciertas tareas de mantenimiento planificadas, o en el caso poco probable de que se produzca un error en el nodo de ElastiCache o en la zona de disponibilidad, ElastiCache detectará automáticamente el error del nodo principal, seleccionará una réplica de lectura y la convertirá en el nuevo nodo principal. ElastiCache también propaga los cambios de DNS de la réplica de lectura elevada, de modo que si su aplicación está escribiendo en el punto de enlace del nodo principal, no será necesario efectuar ningún cambio en dicho punto de enlace.

Los beneficios principales de ejecutar ElastiCache en modo Multi-AZ son el incremento de la disponibilidad y una reducción de las tareas de administración necesarias. Al ejecutar ElastiCache en una configuración Multi-AZ, sus cachés cumplen los requisitos para el SLA de disponibilidad del 99,99 %. Si se produce un error en el nodo principal de ElastiCache, las restricciones de lectura y escritura en el nodo principal dependerán del tiempo que tarde en completarse la conmutación por error automática. Cuando la opción Multi-AZ está activada, la conmutación por error del nodo de ElastiCache se efectúa de manera automática, sin administración. 

Puede hacer uso de Multi-AZ si está utilizando ElastiCache y dispone de un grupo de replicación compuesto de un nodo principal, o de una o más réplicas de lectura. Si se produce un error en el nodo principal, ElastiCache lo detectará de manera automática, seleccionará una réplica de lectura disponible y la definirá como nuevo nodo principal. ElastiCache propagará los cambios de DNS de la réplica definida para que su aplicación pueda seguir escribiendo en el punto de enlace del nodo principal. Asimismo, ElastiCache configurará un nuevo nodo para que sustituya a la réplica de lectura promovida en la misma zona de disponibilidad en la que se encuentra el nodo principal donde se produjo el error. Si el fallo del nodo principal se debe a una interrupción temporal de la zona de disponibilidad, la nueva réplica se lanzará una vez que la zona de disponibilidad se haya recuperado.

Sí. Tenga en cuenta que si coloca el nodo principal y las réplicas en la misma zona de disponibilidad, su grupo de replicación de ElastiCache se puede ver afectado por las interrupciones de la zona de disponibilidad. Además, no se permitirá tener réplicas en la misma zona de disponibilidad que la principal si está activada la opción Multi-AZ.

ElastiCache realizará una conmutación por error a una réplica de lectura si sucede lo siguiente:

• Pérdida de disponibilidad en la zona de disponibilidad del nodo principal
• Pérdida de conectividad de red a principal
• Error de unidad informática en principal

Si hay más de una réplica de lectura, aquella con el menor retardo de replicación asíncrona respecto a la principal será promovida.

Sí, ElastiCache creará un evento para informarle de que se ha efectuado una conmutación por error automática. Puede utilizar la API DescribeEvents para obtener información sobre los eventos relacionados con su nodo de ElastiCache o seleccionar la sección Eventos en la consola de administración de ElastiCache.

Las AZ están diseñadas para ofrecer conectividad de red de baja latencia con otras AZ que se encuentren dentro de la misma región. Debe considerar la posibilidad de diseñar su aplicación y otros recursos de AWS con redundancia entre varias zonas de disponibilidad, de forma que su aplicación sea sólida en caso de producirse una interrupción en una zona de disponibilidad.

Para obtener más información sobre Multi-AZ, consulte la documentación de ElastiCache.

Copia de seguridad y restauración es una característica que le permite crear instantáneas de las cachés de ElastiCache. ElastiCache almacena las instantáneas a fin de que los usuarios puedan utilizarlas posteriormente para restablecer cachés. En la actualidad, esto se admite con ElastiCache para Valkey, ElastiCache para Redis OSS y sin servidor. 

La creación de instantáneas puede resultar útil en caso de que se produzcan pérdidas de datos por errores en los nodos o en el caso poco frecuente de que el hardware presente algún error. Las copias de seguridad también suelen utilizarse con fines de archivado. Las snapshots se almacenan en Amazon S3.

Cuando se inicia una copia de seguridad, ElastiCache realiza una instantánea de una caché determinada que puede utilizarse posteriormente a efectos de recuperación o archivado. Puede iniciar una copia de seguridad cuando lo desee o definir una copia de seguridad recurrente con un período de retención de hasta 35 días. Cuando elija una instantánea para una tarea de restablecimiento, se creará una caché nueva de ElastiCache y este se completará con los datos de la instantánea. Las instantáneas de ElastiCache son compatibles con el formato de archivo RDB de Redis OSS.

Puede utilizar la característica de copia de seguridad y restauración a través de la consola, las API de ElastiCache y AWS CLI. Puede desactivar y reactivar la característica siempre que lo desee.

La característica de copias de seguridad y restauración crea instantáneas de cada caché. Los usuarios pueden especificar de qué caché de ElastiCache desean realizar copias de seguridad a través de la consola, AWS CLI o la API de ElastiCache. Recomendamos a los usuarios que habiliten la copia de seguridad en una de las réplicas de lectura de la caché para minimizar cualquier posible impacto en la caché principal. Cuando se usa ElastiCache sin servidor, las copias de seguridad se realizan automáticamente en las réplicas de lectura.

Sí, puede exportar sus instantáneas de ElastiCache a un bucket de S3 autorizado situado en la misma región que su caché.

Sí. Primero debe copiar la instantánea al bucket de S3 autorizado que desee y que esté ubicado en la misma región. A continuación, conceda permisos de cuenta cruzada de acceso al bucket a la otra cuenta.

ElastiCache ofrece espacio de almacenamiento gratuito para una instantánea por cada caché activa de ElastiCache. El almacenamiento adicional se cobrará en función del espacio utilizado por las instantáneas, a un precio de 0,085 USD/GB al mes (el mismo precio en todas las regiones). Las transferencias de datos por utilizar las snapshots son gratuitas.

Cuando se elimina una caché de ElastiCache, las instantáneas manuales se retienen. También tendrá la opción de crear una instantánea final antes de la eliminación de la caché. En cambio, las snapshots de caché automáticas no se retienen.

El motor de ElastiCache es totalmente compatible con Redis OSS, pero además incorpora mejoras que incrementan el rendimiento, la solidez y la estabilidad. Entre las mejoras se encuentra lo siguiente:

• Más memoria utilizable: Ya puede asignar con seguridad más memoria a su aplicación sin arriesgar el incremento de uso de intercambio durante sincronizaciones y snapshots.
• Sincronización mejorada: sincronización más sólida con cargas intensivas y al recuperarse de pérdidas de conexiones a la red. Además, las sincronizaciones son más rápidas, ya que el nodo principal y las réplicas de lectura no utilizan el disco para realizar la operación.
• Conmutaciones por error más sencillas: si se produce una conmutación por error, la partición se recupera con mayor rapidez, ya que las réplicas de lectura no vacían sus datos para volver a sincronizarlo todo con el nodo principal.
• Descarga de TLS y multiplexación de E/S: ElastiCache está diseñado para utilizar mejor los recursos de CPU disponibles mediante la gestión de determinados procesos relacionados con la red en subprocesos dedicados.

No. El motor mejorado es totalmente compatible con Redis OSS, por lo que puede disfrutar de la mejora en la solidez y estabilidad sin necesidad de cambiar el código de la aplicación.

El uso del motor mejorado no conlleva cargos adicionales.

El cifrado en reposo ofrece mecanismos de protección contra el acceso no autorizado a los datos. Cuando está activado, cifra los siguientes aspectos:

• El disco durante las operaciones de sincronización, copia de seguridad e intercambio
• Copias de seguridad en Amazon S3

ElastiCache ofrece un cifrado predeterminado (administrado por el servicio) en reposo, así como la posibilidad de utilizar sus propias claves simétricas de AWS KMS administradas por el cliente en AWS KMS. Visite cifrado en reposo para obtener más información.

La característica de cifrado en tránsito facilita el cifrado de las comunicaciones entre los clientes y ElastiCache, así como entre los servidores (réplicas principales y de lectura). Obtenga más información sobre el cifrado en tránsito de ElastiCache.

El cifrado en tránsito, el cifrado en reposo, AUTH de Redis OSS y el control de acceso basado en roles (RBAC) son características que puede seleccionar al crear su caché de ElastiCache. Si ha activado el cifrado en tránsito, puede optar por utilizar AUTH de Redis OSS o el control de acceso basado en roles para aumentar la seguridad y el control de acceso.

No, ElastiCache administra el vencimiento y la renovación de certificados en segundo plano. El usuario no debe realizar ninguna acción para el mantenimiento continuo de certificados.

No, no se aplican cargos adicionales por el uso del cifrado.

Global Datastore es una característica de ElastiCache que ofrece una replicación entre regiones ágil, fiable, centrada en la seguridad y completamente administrada. Con Global Datastore, puede escribir en su caché en una región y disponer de los datos para su lectura en otros dos clústeres replicados en regiones diferentes. De este modo, es posible realizar lecturas de baja latencia y hacer recuperaciones ante desastres entre regiones.

Global Datastore, diseñado para aplicaciones en tiempo real con presencia global, suele replicar los datos entre regiones en menos de un segundo, lo que aumenta la respuesta de las aplicaciones al brindar lecturas más cercanas geográficamente a los usuarios finales. En el improbable caso de que una región se deteriore, se puede ascender a caché principal a una de las cachés de réplica entre regiones que esté en buen estado y otorgarle funciones completas de lectura y escritura. Una vez que se inicia, este cambio se completa normalmente en menos de un minuto, de forma que sus aplicaciones siguen estando disponibles.

Con Global Datastore, puede realizar replicaciones en hasta dos regiones secundarias. En el improbable caso de que una región se vea afectada, se pueden usar las cachés de regiones secundarias para atender lecturas locales de baja latencia y casos de recuperación de desastres.

Global Datastore se admite a partir de la versión 5.0.6 de ElastiCache para Redis.

No, ElastiCache no convierte automáticamente un clúster secundario en principal cuando un clúster principal (región) presenta problemas. Para iniciar manualmente la conmutación por error, debe convertir un clúster secundario en principal. Normalmente, la conmutación por error y la promoción de un clúster secundario demora menos de un minuto.

Global Datastore utiliza el cifrado en tránsito para el tráfico entre regiones a fin de mejorar la protección de sus datos. Además, también puede cifrar las cachés principales y secundarias con cifrado en reposo para una mayor protección de los datos. Cada caché principal y secundaria puede tener una clave de AWS KMS independiente administrada por el cliente para el cifrado en reposo.

ElastiCache no ofrece un SLA para RPO ni RTO. El objetivo de punto de recuperación varía en función del retraso de la replicación entre regiones y depende de la latencia de red entre las regiones y de la congestión del tráfico de la red entre regiones. El RPO de Global Datastore normalmente es menor a un segundo, por lo que los datos que se escriben en una región principal quedan a disposición en las regiones secundarias en menos de un segundo. El objetivo de tiempo de recuperación de Global Datastore generalmente es inferior a un minuto. Cuando se inicia la conmutación por error a un clúster secundario, ElastiCache normalmente otorga al clúster secundario capacidades de lectura y escritura plenas en menos de un minuto.

ElastiCache no ofrece un SLA para RPO ni RTO. El objetivo de punto de recuperación varía en función del retraso de la replicación entre regiones y depende de la latencia de red entre las regiones y de la congestión del tráfico de la red entre regiones. El RPO de Global Datastore normalmente es menor a un segundo, por lo que los datos que se escriben en una región principal quedan a disposición en las regiones secundarias en menos de un segundo. El objetivo de tiempo de recuperación de Global Datastore generalmente es inferior a un minuto. Cuando se inicia la conmutación por error a un clúster secundario, ElastiCache normalmente otorga al clúster secundario capacidades de lectura y escritura plenas en menos de un minuto.

Los niveles de datos brindan una nueva opción en la relación precio-rendimiento al utilizar unidades de estado sólido (SSD) de menor coste en cada nodo de clúster, además de almacenar datos en la memoria. Es ideal para cargas de trabajo que acceden de manera habitual a hasta un 20 % de sus conjuntos de datos generales, y para aplicaciones que puedan tolerar una latencia adicional al acceder a datos ubicados en el SSD. Los nodos R6gd de ElastiCache con memoria y SSD tienen una capacidad de almacenamiento total de casi 5 veces más y pueden ayudar a los clientes a ahorrar más del 60 % del costo en el precio cuando se ejecutan con el uso máximo en comparación con los nodos R6g de ElastiCache con solo memoria.

Los niveles de datos funcionan moviendo, de forma transparente y automática, los elementos utilizados hace más tiempo de la memoria a los SSD NVM adjuntos localmente una vez que la capacidad de memoria disponible se ha consumido por completo. Cuando se accede posteriormente a un elemento que se ha movido al SSD, ElastiCache lo devuelve a la memoria de manera asíncrona antes de servir la solicitud.

Los niveles de datos están diseñados parar tener el mínimo impacto en el rendimiento de la aplicación. Al asumir valores de cadena de 500 bytes, puede esperar una latencia adicional de 300 µs de media para solicitudes de datos almacenados en el SSD, en comparación con solicitudes de datos almacenados en la memoria.

ElastiCache admite la clasificación de datos en niveles para las versiones 6.2 y superiores de ElastiCache para Redis OSS.

ElastiCache admite los niveles de datos en los clústeres mediante nodos R6gd.

Todos los comandos de Valkey y Redis OSS y la mayoría de las características de ElastiCache son compatibles cuando se utiliza la clasificación de datos en niveles. Para obtener una lista de las características que no son compatibles en los clústeres con niveles de datos, consulte la documentación.

No hay ningún costo adicional para usar los niveles de datos aparte del costo por hora del nodo. Los nodos con niveles de datos están disponibles con precios en diferido y como nodos reservados. Para obtener más información sobre los precios, consulte la página de precios de ElastiCache.