Amazon ElastiCache – Häufig gestellte Fragen

ElastiCache Serverless ist eine Serverless Option, mit der Sie in weniger als einer Minute ohne Infrastrukturbereitstellung oder Kapazitätsplanung mit einem Cache beginnen können. ElastiCache Serverless macht eine zeitaufwändige Kapazitätsplanung überflüssig, da die Rechen-, Speicher- und Netzwerkauslastung eines Caches kontinuierlich überwacht wird, so dass eine sofortige Skalierung bei Bedarf ohne Ausfallzeiten oder Leistungseinbußen möglich ist. ElastiCache Serverless repliziert Daten automatisch über mehrere Availability Zones (AZs) und bietet Kunden ein Service Level Agreement (SLA) von 99,99 % Verfügbarkeit für jeden Cache. Mit ElastiCache Serverless zahlen Sie nur für die Daten, die Sie speichern, und für die Rechenressourcen, die Ihre Anwendung nutzt. Um zu beginnen, erstellen Sie in wenigen Schritten einen ElastiCache-Serverless-Cache, indem Sie einen Cache-Namen über die Konsole, das ElastiCache Development Kit (SDK) oder die AWS Command Line Interface (AWS CLI) angeben.

Sie können einen vorhandenen ElastiCache-Workload verschieben, indem Sie den Valkey-, Memcached- oder Redis-OSS-Endpunkt in Ihrer Anwendung in Ihren neuen ElastiCache-Serverless-Cache-Endpunkt ändern. Sie können vorhandene ElastiCache-Daten zu ElastiCache Serverless migrieren, indem Sie den Amazon Simple Storage Service (Amazon S3)-Speicherort einer Sicherungsdatei angeben. Besuchen Sie unsere ElastiCache-Serverless-Dokumentation, um mehr über die Migration Ihrer Workloads zu erfahren.

ElastiCache Serverless unterstützt Valkey 7.2, Memcached Version 1.6.21 und Redis OSS Version 7.0 und höher.

ElastiCache Serverless überwacht kontinuierlich die Speicher-, Rechen- und Netzwerkauslastung Ihres Caches, um sofort skalieren zu können. ElastiCache Serverless lässt sich ohne Ausfallzeiten oder Leistungseinbußen für die Anwendung skalieren, indem der Cache hochskaliert werden kann und das Scale-Out parallel initiiert wird, um die Anwendungsanforderungen rechtzeitig zu erfüllen. Weitere Informationen zur Skalierung finden Sie in unserer ElastiCache-Serverless-Dokumentation.

ElastiCache Serverless speichert Daten automatisch redundant über mehrere AZs hinweg und bietet ein Service Level Agreement (SLA) von 99,99 % Verfügbarkeit für alle Workloads.

Mit ElastiCache Serverless zahlen Sie nur für die Daten, die Sie speichern, und für die Rechenleistung, die Ihre Anwendung nutzt. Weitere Informationen finden Sie auf der Seite mit den ElastiCache-Preisen.

Reserved Nodes oder Reserved Instances (RIs) bieten Ihnen einen erheblichen Rabatt gegenüber der On-Demand-Nutzung, wenn Sie sich für ein Jahr oder drei Jahre verpflichten. Mit Reserved Nodes können Sie eine einmalige Vorauszahlung für eine ein- oder dreijährige Reservierung zur Ausführung Ihres Caches in einer bestimmten Region tätigen und erhalten einen erheblichen Rabatt auf die laufenden stündlichen Nutzungsgebühren. Es gibt drei Arten von Reserved Nodes – Keine Vorauszahlung, Teilweise Vorauszahlung, Komplette Vorauszahlung – die es Ihnen ermöglichen, eine Abstimmung zwischen dem Betrag Ihrer Vorauszahlung und Ihrem effektiven Stundensatz zu finden.

Reserved Nodes bieten einen Rabatt, der für die Nutzung von ElastiCache auf Abruf gilt. ElastiCache Serverless ist nicht mit Reserved Nodes kompatibel.

Sie können bis zu 300 Reserved Nodes erwerben. Wenn Sie mehr als 300 Knoten betreiben möchten, füllen Sie das Formular zum Anfordern von ElastiCache-Knoten aus.

Erwerben Sie eine Knotenreservierung derselben Knotenklasse in derselben Region wie der Knoten, den Sie aktuell ausführen und reservieren möchten. Nach erfolgreichem Erwerb der Reservierung wendet ElastiCache die neue stündliche nutzungsabhängige Gebühr automatisch auf Ihren bestehenden Knoten an.

Preisänderungen für Reserved Nodes werden aktiviert, sobald Ihre Anfrage eingegangen ist und während die Zahlungsautorisierung verarbeitet wird. Sie können den Status Ihrer Reservierung auf der Seite zu den AWS-Kontoaktivitäten oder über den API-Befehl DescribeReservedCacheNodes verfolgen. Falls die einmalige Zahlung nicht erfolgreich bis zur nächsten Abrechnungsperiode autorisiert werden kann, wird der rabattierte Preis nicht übernommen.

Nach Ablauf Ihres Reservierungszeitraums gilt für Ihren Reserved Node wieder der entsprechende On-Demand-Stundentarif Ihrer Knotenklasse und -region.

Die ElastiCache-APIs zum Erstellen, Ändern und Löschen von Knoten unterscheiden nicht zwischen On-Demand-Nodes und Reserved Nodes, sodass Sie beide problemlos verwenden können. Bei der Verarbeitung Ihrer Abrechnung wendet unser System automatisch Ihre Reservierungen an, sodass alle berechtigten Knoten nach dem reduzierten Stundentarif für Reserved Nodes abgerechnet werden.

Jeder Reserved Node ist einer bestimmten Region zugeordnet, die für die Lebensdauer der Reservierung festgelegt ist und nicht geändert werden kann. Jede Reservierung kann jedoch in beliebigen AZs der zugeordneten Region verwendet werden.

Nein. Sie können Ihre Knotenreservierung nicht stornieren, und die einmalige Zahlung (falls zutreffend) ist nicht erstattungsfähig. Sie zahlen weiterhin für jede Stunde während der Laufzeit Ihres Reserved Nodes, unabhängig von Ihrer Nutzung.

Wenn Sie einen Reserved Node mit der Zahlungsoption „Komplette Vorauszahlung“ erwerben, zahlen Sie in einer Vorauszahlung für die gesamte Laufzeit des Reserved Nodes. Bei Wahl der Option „Keine Vorauszahlung“ leisten Sie vorab keine Zahlung. Der gesamte Wert des Node No Upfront Reserved Node wird auf jede Stunde der Laufzeit verteilt, und Ihnen wird jede Stunde in der Laufzeit in Rechnung gestellt, unabhängig von der Nutzung. Die dritte Zahlungsoption heißt "Teilweise Vorauszahlung". Sie leisten eine niedrige Vorauszahlung und anschließend wird Ihnen ein niedriger Stundentarif für die Dauer der Laufzeit in Rechnung gestellt.

Ja. Reservierte ElastiCache-Knoten bieten flexible Größe innerhalb einer Instance-Familie (oder Knotenfamilie) und einer AWS-Region. Dies bedeutet, dass der bestehende Rabatt für reservierte Knoten automatisch auf die Nutzung aller Größen innerhalb derselben Knotenfamilie angewendet wird.

Mit ElastiCache können Sie die Verschlüsselung ruhender Daten mithilfe des AWS Key Management Service (AWS KMS), die Verschlüsselung von Daten während der Übertragung mit Transport Layer Security (TLS), die Authentifizierung mithilfe von AWS Identity and Access Management (IAM) und die Netzwerkzugriffskontrolle mit Amazon-Elastic-Compute-Cloud-Sicherheitsgruppen (Amazon EC2) konfigurieren.

Wenn Sie Amazon Virtual Private Cloud (Amazon VPC) nicht verwenden, können Sie mit ElastiCache den Zugriff auf Ihre Caches über Netzwerksicherheitsgruppen steuern. Eine Sicherheitsgruppe fungiert wie eine Firewall zum Steuern des Netzwerkzugriffs auf Ihren Cache. Der Netzwerkzugriff auf Ihre Caches ist standardmäßig deaktiviert. Wenn Ihre Anwendungen auf Ihren Cache-Cluster zugreifen sollen, müssen Sie den Zugriff von Hosts aus in spezifischen Amazon-EC2-Sicherheitsgruppen explizit aktivieren.

Sie können den Zugriff auf Ihre ElastiCache-Ressourcen auch mithilfe der IAM-Authentifizierung steuern. Weitere Informationen finden Sie in der Dokumentation zur Authentifizierung mit IAM.

ElastiCache unterstützt Compliance-Programme wie SOC 1, SOC 2, SOC 3, ISO, MTCS, C5, PCI DSS, HIPAA und FedRAMP. Eine aktuelle Liste der unterstützten Compliance-Programme finden Sie unter AWS Services im Geltungsbereich nach Compliance-Programm.

Ja, das PCI-Compliance-Programm von AWS beinhaltet ElastiCache als PCI-kompatiblen Service. Weitere Informationen finden Sie in den folgenden Ressourcen:

• ElastiCache-Einhaltung
• Seite AWS-PCI-Compliance

Die aktuelle Liste der Compliance-Programme, die über ElastiCache verfügbar sind, finden Sie unter AWS-Services in Scope nach Compliance-Programm.

Ja, ElastiCache ist ein HIPAA-fähiger Service und fällt unter das AWS Business Associate Addendum (BAA). Dies bedeutet, dass Sie ElastiCache zur Verarbeitung, Verwaltung und Speicherung geschützter Gesundheitsdaten sowie zum Betreiben von Anwendungen aus dem Gesundheitswesen einsetzen können.

Nein, für die Verwendung von Compliance-Funktionen fallen keine zusätzlichen Kosten an.

Wenn Sie ein ausgeführtes Business Associate Agreement (BAA) mit AWS haben, können Sie ElastiCache verwenden, um Anwendungen zu erstellen, die HI unter HIPAA speichern und verarbeiten. Wenn keine BAA vorhanden ist oder Sie weitere Fragen zur Verwendung von AWS für Ihre Anwendungen haben, setzen Sie sich mit uns in Verbindung. 

Das AWS FedRAMP-Konformitätsprogramm umfasst ElastiCache als FedRAMP-autorisierten Service. Kunden der US-Regierung und ihre Partner können jetzt die neueste Version von ElastiCache verwenden, um ihre FedRAMP-Systeme, Daten und geschäftskritischen Workloads mit hoher Auswirkung in den Regionen AWS GovCloud (USA-Ost) und AWS GovCloud (USA-West) zu verarbeiten und zu speichern, und bei moderaten Auswirkungen in den Regionen USA Ost (Ohio), USA Ost (Nord-Virginia), USA West (Nordkalifornien) und USA West (Oregon).

Weitere Informationen finden Sie in den folgenden Ressourcen:

• ElastiCache-Einhaltung
• AWS FedRAMP-Einhaltung

Die aktuelle Liste der Compliance-Programme, die über ElastiCache verfügbar sind, finden Sie unter AWS-Services in Scope nach Compliance-Programm.

Es gibt mehrere Leistungsvorteile.

ElastiCache bietet erweiterte E/A-Threads, die durch Multiplexing, Presentation Layer Offloading und mehr zu deutlichen Verbesserungen des Durchsatzes und der Latenz in großem Maßstab führen. Erweiterte E/A-Threads verbessern die Leistung, indem sie mehr Kerne für die E/A-Verarbeitung nutzen und sich dynamisch an den Workload anpassen. ElastiCache verbessert den Durchsatz von TLS-fähigen Clustern, indem es die Verschlüsselung auf dieselben erweiterten E/A-Threads auslagert. Dadurch kann ElastiCache für Valkey bis zu 100 % mehr Durchsatz und eine um 50 % niedrigere P99-Latenz als ElastiCache Version 7.0 für Redis OSS liefern. Sie können über 1 Million Anfragen pro Sekunde pro Knoten oder 500 Millionen Anfragen pro Sekunde pro Cluster auf r7g.4xlarge Knoten oder größer erreichen.

Darüber hinaus bietet Ihnen ElastiCache Version 8.0 für Valkey eine verbesserte Speichereffizienz für knotenbasierte Cluster im Cluster-Modus, da 32 Byte weniger Speicher pro Schlüssel verwendet werden als ElastiCache Version 7.2 für Valkey und Version 7.1 für Redis OSS. Die Serverless-Konfiguration hat eine verbesserte Leistung und skaliert innerhalb von Minuten auf 5 Millionen Anfragen pro Sekunde pro Cache, bis zu fünfmal schneller als Valkey 7.2, mit einer Leselatenz von Mikrosekunden.

ElastiCache bietet zwei verschiedene Gruppen von Metriken, um die CPU-Auslastung Ihres Caches zu messen, je nachdem, welche Cache-Bereitstellung Sie gewählt haben. Wenn Sie ElastiCache Serverless verwenden, können Sie die CPU-Auslastung mit der ElastiCache Processing Units (eCPU)-Metrik überwachen. Die Anzahl der von Ihren Anfragen verbrauchten eCPUs hängt von der benötigten vCPU-Zeit und der übertragenen Datenmenge ab. Jeder Lese- und Schreibvorgang, wie die Valkey-Befehle GET und SET oder die Memcached-Befehle get und set, erfordert 1 ECPU für jedes übertragene Kilobyte (KB) Daten. Einige Befehle, die mit speicherinternen Datenstrukturen arbeiten, können mehr vCPU-Zeit beanspruchen als ein GET- oder SET-Befehl. ElastiCache berechnet die Anzahl der verbrauchten ECPUs basierend auf der vCPU-Zeit, die der Befehl benötigt, im Vergleich zu einer Basislinie der vCPU-Zeit, die ein SET- oder GET-Befehl benötigt. Wenn Ihr Befehl zusätzliche vCPU-Zeit benötigt und mehr Daten als die Baseline von 1 ECPU überträgt, berechnet ElastiCache die erforderlichen eCPUs auf der Grundlage der höheren der beiden Dimensionen.

Wenn Sie Ihren eigenen Cluster entwerfen, können Sie EngineCPUUtilization und CPUUtilization überwachen. Die CPUUtilization-Metrik misst die CPU-Auslastung für die Instance (Knoten), und die EngineCPUUtilization-Metrik misst die Auslastung auf Engine-Prozessebene. Sie benötigen die EngineCPUUtilization-Metrik zusätzlich zur CPUUtilization-Metrik, da der Hauptprozess der Engine einen einzigen Thread umfasst und nur eine CPU der mehreren CPU-Kerne verwendet, die auf einer Instance verfügbar sind. Daher bietet die CPUUtilization-Metrik keinen genauen Einblick in die CPU-Auslastungsraten auf Prozessebene. Wir empfehlen Ihnen, die Metriken CPUUtilization und EngineCPUUtilization zusammen zu verwenden, um ein detailliertes Verständnis der CPU-Auslastung für Ihre Valkey-Cluster zu erhalten.

Beide Sätze von Metriken sind in allen AWS-Regionen verfügbar, und Sie können auf diese Metriken mit Amazon CloudWatch oder in der Konsole zugreifen. Außerdem empfehlen wir Ihnen, die Dokumentation um mehr über nützliche Metriken zur Leistungsüberwachung zu erfahren.

Lese-Replikate dienen zwei Zwecken:

• Behandlung von Störungen
• Leseskalierung

Wenn Sie einen Cache mit einem Lesereplikat betreiben, dient der Primärknoten sowohl für Schreib- als auch für Lesevorgänge. Das Replikat dient ausschließlich dem Leseverkehr und ist auch als Warm-Standby verfügbar, falls die primäre Version beeinträchtigt wird.

Mit ElastiCache Serverless werden Lesereplikate automatisch vom Service verwaltet. Beim Entwerfen Ihres eigenen Caches gibt es eine Vielzahl von Szenarien, in denen die Bereitstellung einer oder mehrerer Lesereplikate für einen bestimmten primären Knoten sinnvoll sein kann. Häufige Gründe für die Bereitstellung einer Read Replica:

• Skalierung über die Rechen- oder E/A-Kapazität eines einzelnen primären Knotens für leseintensive Workloads hinaus: Dieser überschüssige Leseverkehr kann auf ein oder mehrere Lesereplikate geleitet werden.
• Servieren von Leseverkehr, während der primäre Knoten nicht verfügbar ist: Wenn Ihr primärer Knoten keine E/A-Anforderungen annehmen kann (z. B. aufgrund einer E/A-Sperre für Backups oder geplante Wartungsarbeiten), können Sie den Leseverkehr auf Ihre Lesereplikate umleiten. Denken Sie in diesem Fall daran, dass die Daten im Lesereplikat veraltet sein können, da die Primär-Instance nicht verfügbar ist. Das Lesereplikat kann auch zum Neustarten eines ausgefallenen eingeschalteten Primärknotens verwendet werden.

Szenarien zur Datensicherung: Im unwahrscheinlichen Fall eines Ausfalls des primären Knotens oder wenn die AZ, in der sich Ihr primärer Knoten befindet, nicht mehr verfügbar ist, können Sie ein Lesereplikat in einer anderen AZ zum neuen primären Knoten ernennen.

Sie können eine Verbindung zu einem Lesereplikat genauso herstellen, wie Sie eine Verbindung zu einem primären Cache-Knoten herstellen würden. Wenn Sie mehrere Read Replicas nutzen, muss Ihre Anwendung bestimmen, wie der Lesedatenverkehr auf diese verteilt wird. Hier weitere Informationen:

• Valkey- oder Redis-OSS-Cluster (Cluster-Modus deaktiviert) verwenden die einzelnen Knotenendpunkte für Lesevorgänge. (In der API/CLI werden diese als Leseendpunkte bezeichnet.)
• Valkey- oder Redis-OSS-Cluster (Cluster-Modus aktiviert): Verwenden Sie den Konfigurationsendpunkt des Clusters für alle Vorgänge. Sie können immer noch von einzelnen Knotenendpunkten lesen. (In der API und CLI werden diese als Leseendpunkte bezeichnet.)

ElastiCache bietet Ihnen die Möglichkeit, bis zu fünf (5) Lesereplikate für einen primären Cache-Knoten zu erstellen.

Im Falle eines Failovers müssen alle zugeordneten und verfügbaren Read Replicas automatisch die Replikation fortsetzen, nachdem das Failover abgeschlossen wurde (d. h., sie beginnen mit dem Abrufen von Updates aus der neu hochgestuften Read Replica).

Aktualisierungen eines primären Cache-Knotens werden automatisch in allen zugeordneten Lesereplikaten repliziert. Bei der asynchronen Replikationstechnologie Valkey oder Redis OSS kann ein Lese-Replikat jedoch aus verschiedenen Gründen hinter ihren primären Cache-Knoten zurückfallen. Typische Gründe hierfür sind:

• Das E/A-Schreibvolumen in den primären Cache-Knoten übersteigt die Rate, mit der Änderungen vom Lesereplikat übernommen werden können.
• Netzwerkpartitionen oder Latenz zwischen dem primären Cache-Knoten und einem Lesereplikat.

Lese-Replikate unterliegen den Stärken und Schwächen der Valkey- oder Redis-OSS-Replikation. Wenn Sie Lesereplikate verwenden, sollten Sie sich über die potenziellen Verzögerungen (die so genannten „Inkonsistenzen“) zwischen einem Lesereplikat und ihrem primären Cache-Knoten bewusst sein. ElastiCache gibt eine Metrik aus, die Ihnen hilft, die Inkonsistenz zu verstehen.

Ein Lesereplikat wird als Standard-Cache-Knoten und zu denselben Tarifen abgerechnet. Wie bei einem Standard-Cache-Knoten auch wird der Tarif pro Cache-Knoten-Stunde für ein Lese-Replikat von der Cache-Knoten-Klasse des Lese-Replikats bestimmt. Aktuelle Preisangaben finden Sie auf der Seite mit den Preisen für ElastiCache. Der bei der Replikation von Daten zwischen Ihrem primären Cache-Knoten und dem Lesereplikat anfallende Datenverkehr wird nicht in Rechnung gestellt. Die Fakturierung für ein Lesereplikat beginnt, sobald diese erfolgreich erstellt wurde (wenn der Status als aktiv ausgewiesen ist). Das Lesereplikat wird so lange nach standardmäßigen Cache-Knoten-Stundensätzen von ElastiCache abgerechnet, bis Sie den Befehl zu ihrem Löschen aufrufen.

Das Failover wird automatisch von ElastiCache ausgelöst, damit Sie Cache-Vorgänge schnellstmöglich fortsetzen können. Bei einem Failover schaltet ElastiCache den DNS-Datensatz Ihres Cache-Knotens auf das Lesereplikat um, die wiederum zum neuen Primärknoten hochgestuft wird. Wir empfehlen Ihnen, sich an bewährte Methoden zu halten und eine Funktion auf Anwendungsebene zu implementieren, die ggf. erneut versucht, eine Cache-Knotenverbindung herzustellen. In der Regel sind die Schritte eins bis fünf von Anfang bis Ende innerhalb von sechs Minuten abgeschlossen.

Dies sind die automatischen Failover-Ereignisse, aufgelistet in der Reihenfolge ihres Auftreten:

1. Meldung der Replikationsgruppe: Test Failover-API für Knotengruppe <Knotengruppen-ID> aufgerufen
2. Cache-Cluster-Meldung: Failover von Primärknoten <Primärknoten-ID> auf Replikatknoten <Knoten-ID> abgeschlossen
3. Meldung der Replikationsgruppe: Failover von Primärknoten <Primärknoten-ID> auf Replikatknoten <Knoten-ID> abgeschlossen
4. Cache-Cluster-Meldung: Cache-Knoten <Knoten-ID> wiederherstellen
5. Cache-Cluster-Meldung: Wiederherstellung für Cache-Knoten <Knoten-id> beendet

Nein, Ihr Lesereplikat kann nur in derselben oder einer anderen AZ derselben Region wie Ihr primärer Cache-Knoten bereitgestellt werden. Sie können jedoch den Global Datastore verwenden, um mit einer vollständig verwalteten, schnellen, zuverlässigen und sicherheitsorientierten Replikation über AWS-Regionen hinweg zu arbeiten. Mit diesem Feature können Sie regionenübergreifende Lesereplikat-Cluster für ElastiCache erstellen, um Lesevorgänge mit niedriger Latenz und Notfallwiederherstellung über AWS-Regionen hinweg zu ermöglichen.

Ja. Sie können ein Lese-Replikat über einen oder mehrere Shards in einer Cluster-Umgebung hinweg hinzufügen oder entfernen. Der Cluster bleibt online und verarbeitet während des Vorgangs weiterhin eingehende E/A.

Multi-AZ ist ein Feature, das es Ihnen ermöglicht, in einer Konfiguration mit höherer Verfügbarkeit zu arbeiten, wenn Sie Ihren eigenen ElastiCache-Cache entwerfen. Alle ElastiCache Serverless Caches werden automatisch in einer Multi-AZ-Konfiguration ausgeführt. Ein ElastiCache-Replikationsgruppe besteht aus einem Primärknoten und bis zu fünf Lesereplikaten. Wenn Multi-AZ aktiviert ist, ist mindestens ein Replikat pro Primärknoten erforderlich. Während bestimmter geplanter Wartungsarbeiten oder im unwahrscheinlichen Fall eines ElastiCache-Knotenausfalls oder eines AZ-Ausfalls erkennt ElastiCache automatisch den Ausfall eines primären Knotens, wählt ein Lesereplikat aus und ernennt es zum neuen primären. ElastiCache überträgt auch die DNS-Änderungen der hochgestuften Read Replica. Wenn Ihre Anwendung auf den Primärknoten-Endpunkt schreibt, ist daher keine Änderung des Endpunkts erforderlich.

Die Hauptvorteile beim Ausführen Ihres ElastiCache im Multi-AZ-Modus sind verbesserte Verfügbarkeit und ein geringerer Bedarf für Administration. Wenn Sie ElastiCache in einer Multi-AZ-Konfiguration ausführen, kommen Ihre Caches für das SLA mit einer Verfügbarkeit von 99,99 % in Frage. Wenn ein für ElastiCache-Primärknoten ausfällt, sind die Auswirkungen auf Ihre Fähigkeit zum Lesen und Schreiben auf den Primärknoten auf die Zeit begrenzt, die für die Durchführung des automatischen Failovers benötigt wird. Wenn Multi-AZ aktiviert ist, wird der Failover des ElastiCache-Knotens automatisch durchgeführt und benötigt keine Administration.

Sie können Multi-AZ benutzen, wenn Sie ElastiCache verwenden und über eine Replikationsgruppe verfügen, die aus einem Primärknoten und einer oder mehreren Lesereplikaten besteht. Wenn der Primärknoten ausfällt, entdeckt ElastiCache automatisch den Ausfall, wählt eins der verfügbaren Lesereplikate und stuft dieses zum neuen Primärknoten hoch. ElastiCache propagiert die DNS-Änderungen des hochgestuften Replikats, damit Ihre Anwendung weiterhin auf den primären Endpunkt schreiben kann. ElastiCache richtet auch einen neuen Knoten ein, um das hochgestufte Lesereplikat in der gleichen AZ des ausgefallenen primären zu ersetzen. Falls die primäre Kopie aufgrund einer vorübergehenden Störung der AZ ausfällt, wird die neue Kopie gestartet, sobald sich die AZ erholt hat.

Ja. Beachten Sie, dass die Platzierung sowohl der primären als auch der Replikate in der gleichen AZ Ihre ElastiCache-Replikationsgruppe nicht widerstandsfähig gegenüber einer AZ-Störung macht.

ElastiCache führt bei folgenden Ereignissen einen Failover auf ein Lesereplikat durch:

• Verlust der Erreichbarkeit im AZ des Primärknotens
• Verlust der Netzwerkverbindung zur Primär-Instanz
• Ausfall einer Datenverarbeitungseinheit in der Primär-Instanz

Wenn mehr als ein Lese-Replikat vorhanden ist, wird das Lese-Replikat mit der geringeren asynchronen Replikationsverzögerung zum Primärserver hochgestuft.

Ja, ElastiCache erstellt ein Ereignis, um Sie zu informieren, dass ein automatischer Failover durchgeführt wurde. Sie können die DescribeEvents-API verwenden, um Informationen zu Ereignissen im Zusammenhang mit Ihrem ElastiCache-Knoten abzurufen, oder den Abschnitt Ereignisse der ElastiCache-Managementkonsole wählen.

Die AZs sind so konzipiert, dass sie Netzwerkverbindungen mit geringer Latenz zu anderen AZs in derselben Region bieten. Sie sollten in Erwägung ziehen, Ihre Anwendung und andere AWS-Ressourcen mit Redundanz über mehrere AZs hinweg zu gestalten, damit Ihre Anwendung im Falle einer AZ-Störung widerstandsfähig ist.

Weitere Informationen über Multi-AZ finden Sie in der ElastiCache-Dokumentation.

Backup and Restore ist ein Feature, mit dem Sie Snapshots Ihrer ElastiCache-Caches erstellen können. ElastiCache speichert die Snapshots, die Benutzer anschließend zum Wiederherstellen von Caches verwenden können. Dies wird derzeit mit ElastiCache für Valkey, ElastiCache für Redis OSS und Serverless unterstützt.

Das Erstellen von Snapshots kann bei durch einen Knotenausfall verursachten Datenverlusten sowie im unwahrscheinlichen Fall eines Hardwareausfalls nützlich sein. Sicherungen werden außerdem für Archivierungszwecke verwendet. Die Snapshots werden in Amazon S3 aufbewahrt.

Ja, Sie können Ihre ElastiCache-Snapshots in einen autorisierten S3-Bucket in derselben Region wie Ihr Cache exportieren.

Ja. Sie müssen zunächst Ihren Snapshot in einen autorisierten S3-Bucket Ihrer Wahl in derselben Region kopieren und anschließend dem anderen Konto kontenübergreifende Bucket-Berechtigungen gewähren.

ElastiCache bietet kostenlos Speicherplatz für einen Snapshot jedes aktiven ElastiCache-Cache. Zusätzlicher Speicherplatz wird basierend auf dem von den Snapshots belegten Speicherplatz mit monatlich 0,085 USD pro GB in Rechnung gestellt (Einheitspreis in allen Regionen). Die Datenübertragung zur Nutzung der Snapshots ist kostenlos.

Wenn Sie einen ElastiCache-Cache löschen, bleiben Ihre manuellen Snapshots erhalten. Sie haben auch die Möglichkeit, einen letzten Snapshot zu erstellen, bevor der Cache gelöscht wird. Automatisch erstellte Cache-Snapshots werden nicht aufbewahrt.

Die Engine in ElastiCache ist vollständig kompatibel mit Valkey und Redis OSS, verfügt jedoch auch über Verbesserungen, die die Leistung, Zuverlässigkeit und Stabilität verbessern. Einige der Erweiterungen umfassen:

• Mehr nutzbarer Arbeitsspeicher: Sie können jetzt problemlos mehr Arbeitsspeicher für Ihre Anwendung zuweisen, ohne während Synchronisierungen und Snapshots eine erhöhte Swap-Nutzung zu riskieren.
• Verbesserte Synchronisierung: Zuverlässigere Synchronisierung unter hoher Last und beim Wiederherstellen von getrennten Netzwerkverbindungen. Außerdem sind Synchronisierungen schneller, da Primärknoten und Replikate die Festplatte nicht mehr für diesen Vorgang verwenden.
• Problemlosere Failovers: Im Falle eines Failovers wird die Shard jetzt schneller wiederhergestellt, da Replikate ihre Daten nicht mehr komplett löschen, um eine vollständige erneute Synchronisierung mit dem Primärknoten durchzuführen.

Die verbesserte Engine ist vollständig kompatibel mit Valkey oder Redis OSS, sodass Sie von der verbesserten Zuverlässigkeit und Stabilität profitieren können, ohne Änderungen an Ihrem Anwendungs-Code vornehmen zu müssen.

Für die Verwendung der erweiterten Engine fallen keine zusätzlichen Gebühren an.

Verschlüsselung während der Übertragung, Verschlüsselung im Ruhezustand, Valkey AUTH und rollenbasierte Zugriffskontrolle (RBAC) sind Features, die Sie beim Erstellen Ihres ElastiCache-Caches auswählen können. Wenn Sie die Verschlüsselung während der Übertragung aktiviert haben, können Sie für zusätzliche Sicherheit und Zugriffskontrolle zwischen AUTH und RBAC auswählen.

Die Verschlüsselung im Ruhezustand bietet Mechanismen zum Schutz vor unberechtigtem Zugriff auf Ihre Daten. Wenn diese Option aktiviert ist, werden die folgenden Aspekte verschlüsselt:

• Festplatte während Synchronisations-, Sicherungs- und Auslagerungsvorgängen
• In Amazon S3 gespeicherte Backups

ElastiCache bietet standardmäßige (service-verwaltete) Verschlüsselung im Ruhezustand sowie die Möglichkeit, Ihre eigenen symmetrischen, vom Kunden verwalteten AWS-KMS-Schlüssel in AWS KMS zu verwenden. Weitere Informationen finden Sie unter Verschlüsselung im Ruhezustand.

Das Feature Verschlüsselung in Transit ermöglicht die Verschlüsselung der Kommunikation zwischen Clients und ElastiCache sowie zwischen den Servern (primäre und Lesereplikate). Erfahren Sie mehr über die Verschlüsselung während der Übertragung durch ElastiCache.

Nein. ElastiCache verwaltet den Ablauf und die Verlängerung von Zertifikaten im Hintergrund. Vom Benutzer werden für den Zertifikaterhalt keine Aktionen erwartet.

Nein, für die Nutzung der Verschlüsselung werden keine zusätzlichen Gebühren berechnet.

Globaler Datenspeicher ist ein Feature von ElastiCache, die eine vollständig verwaltete, schnelle, zuverlässige und sicherheitsorientierte regionenübergreifende Replikation ermöglicht. Mit Global Datastore können Sie in Ihren Cache in einer Region schreiben und die Daten in bis zu zwei anderen regionenübergreifenden Replikat-Clustern zum Lesen bereitstellen, was Lesevorgänge mit niedriger Latenz und Notfallwiederherstellung über Regionen hinweg ermöglicht.

Global Datastore wurde für Echtzeitanwendungen mit globaler Präsenz entwickelt und repliziert Daten in der Regel in weniger als einer Sekunde über die Regionen hinweg, wodurch die Reaktionsfähigkeit Ihrer Anwendungen verbessert wird, da geolokale Lesevorgänge näher am Endbenutzer stattfinden. Im unwahrscheinlichen Fall eines regionalen Ausfalls kann einer der gesunden regionenübergreifenden Replikat-Caches zum primären Cache mit vollen Lese- und Schreibfunktionen werden. Nach dem Start ist die Beförderung in der Regel in weniger als einer Minute abgeschlossen, sodass Ihre Anwendungen weiterhin zur Verfügung stehen.

Global Datastore wird von ElastiCache Version 7.2 für Valkey und ElastiCache Version 5.0.6 für Redis OSS aufwärts unterstützt.

Sie können auf bis zu zwei sekundäre Regionen innerhalb eines globalen Datenspeichers replizieren. Die Caches in den sekundären Regionen können für lokale Lesevorgänge mit geringer Latenz und für die Notfallwiederherstellung im unwahrscheinlichen Fall eines Ausfalls der Region verwendet werden.

Sie können einen Global Datastore einrichten, indem Sie einen vorhandenen Cache verwenden oder einen neuen Cache erstellen, der als primärer Cache verwendet wird. Sie können einen globalen Datenspeicher mit nur wenigen Schritten in der ElastiCache Management Console oder durch Herunterladen des neuesten AWS-SDK oder der AWS-CLI erstellen. Es gibt Unterstützung für den Global Datastore in AWS CloudFormation.

Nein. ElastiCache fördert nicht automatisch einen sekundären Cluster, wenn der primäre Cluster (Region) degradiert wird. Sie können das Failover manuell durchführen, indem Sie einen sekundären Cluster zu einem primären heraufstufen. Der Failover und die Heraufstufung eines sekundären Clusters sind in der Regel in weniger als einer Minute abgeschlossen.

ElastiCache bietet kein SLA für RPO und RTO. Das RPO variiert je nach Replikationsverzögerung zwischen den Regionen und hängt von der Netzwerklatenz zwischen den Regionen und der regionsübergreifenden Netzwerküberlastung ab. Das RPO von Global Datastore liegt typischerweise unter einer Sekunde, sodass die in der primären Region geschriebenen Daten in den sekundären Regionen innerhalb einer Sekunde verfügbar sind. Das RTO von Global Datastore beträgt in der Regel weniger als eine Minute. Sobald ein Failover auf einen sekundären Cluster eingeleitet wird, gewährt ElastiCache in der Regel dem sekundären Cluster vollständige Lese-/Schreibfähigkeiten in weniger als einer Minute.

ElastiCache verlangt keine Gebühren für die Nutzung von Global Datastore. Sie zahlen nur für den primären und sekundären Caches in Ihrem Global Datastore sowie für den regionsübergreifenden Datenverkehr.

Es gibt zwar keine präzise Antwort auf diese Frage, doch mit ElastiCache müssen Sie sich keine Gedanken darum machen, ob die Zahl der Knoten wirklich hundertprozentig richtig ist, da Sie Knoten zu einem späteren Zeitpunkt auf einfache Weise hinzufügen oder entfernen können. Sie können ElastiCache Serverless auch verwenden, um die Ausführung eines Memcached-Caches mit hoher Verfügbarkeit zu vereinfachen. Bei der Wahl Ihrer Erstkonfiguration können Sie die folgenden beiden miteinander verbundenen Aspekte berücksichtigen:

• Die Gesamtspeicherkapazität, die für Ihre Daten erforderlich ist, um die Cache-Trefferrate für das Ziel zu erzielen.
• Die Anzahl der Knoten, die erforderlich sind, um eine akzeptable Anwendungsleistung beizubehalten, ohne das Datenbank-Backend im Falle des Ausfalls eines Knotens zu überlasten.

Die erforderliche Speicherkapazität hängt von der Größe Ihres Datensets und den Zugriffsmustern Ihrer Anwendung ab. Sobald Sie grob wissen, wie viel Gesamtspeicher benötigt wird, teilen Sie, den Speicher in ausreichend Knoten ein, sodass Ihre Anwendung den Verlust von ein, zwei Knoten verkraften kann. So können Sie die Fehlertoleranz verbessern. Wenn Sie beispielsweise 13 GB benötigen, könnten Sie statt eines Knotens des Typs cache.m4.xlarge zwei Knoten des Typs cache.m4.large verwenden. Andere Systeme, beispielsweise Datenbanken, dürfen nicht überlastet werden, wenn die Trefferrate des Caches während der Fehlerwiederherstellung eines oder mehrerer Knoten zeitweilig reduziert wird. Für weitere Informationen hierzu siehe ElastiCache-Benutzerhandbuch.

Ja. Beim Erstellen eines Clusters oder beim Hinzufügen von Knoten zu einem bestehenden Cluster können Sie die AZs für die neuen Knoten auswählen. Sie können entweder die gewünschte Anzahl von Knoten in jeder AZ angeben oder die Option Knoten über Zonen verteilen auswählen. Wenn sich der Cluster in einer Amazon VPC befindet, können die Knoten nur in AZs platziert werden, die Teil der ausgewählten Cache-Subnetzgruppe sind. Weitere Details finden Sie in der ElastiCache-VPC-Dokumentation.

Sie können pro Region maximal 300 Knoten ausführen. Wenn Sie mehr Knoten benötigen, füllen Sie das Formular zur Beantragung der Erhöhung des ElastiCache-Limits aus.

Der Service erkennt den Ausfall des Knotens und reagiert mit den folgenden automatischen Schritten:

• ElastiCache repariert den Knoten, indem neue Serviceressourcen beschafft werden und der vorhandene DNS-Namen des Cache-Knotens zu den neuen Serviceressourcen umgeleitet wird. Bei Amazon-VPC-Installationen stellt ElastiCache sicher, dass sowohl der DNS-Name als auch die IP-Adresse des Knotens gleich bleiben, wenn Knoten nach einem Ausfall wiederhergestellt werden. Bei Nicht-Amazon-VPC-Installationen stellt ElastiCache sicher, dass der DNS-Name eines Knotens unverändert bleibt. Die zugrunde liegende IP-Adresse des Knotens kann sich allerdings ändern.
• Wenn Sie, nachdem der neue Knoten konfiguriert wurde und einsatzbereit ist, Ihrem Cluster ein SNS-Thema zugeordnet haben, sendet ElastiCache eine SNS-Benachrichtigung, in der Sie über die Wiederherstellung des Knotens informiert werden. Auf diese Weise können Sie für Ihre Anwendung optional arrangieren, dass die erneute Anmeldung der Memcached-Client-Bibliothek bei den reparierten Knoten erzwungen wird. Dies könnte wichtig sein, weil einige Memcached-Bibliotheken auf unbestimmte Zeit keinen Server (Knoten) mehr verwenden, wenn es auf diesem Server zu Kommunikationsfehlern oder Zeitüberschreitungen kommt.

Sie können weitere Knoten zu Ihrem bestehenden Memcached-Cluster hinzufügen, indem Sie die Option Knoten hinzufügen auf der Registerkarte Knoten für Ihren Cache-Cluster in der Konsole verwenden oder die API ModifyCacheCluster aufrufen.

ElastiCache eignet sich ideal als Front-End für AWS-Services wie Amazon RDS und DynamoDB. Es bietet extrem niedrige Latenzzeiten für Hochleistungsanwendungen und entlastet einen Teil des Anfragevolumens, während diese Services für eine lange Haltbarkeit der Daten sorgen. Mit dem Service verbessern Sie auch die Anwendungsleistung in Verbindung mit Amazon EC2 und Amazon EMR.

Memcached-Client-Bibliotheken sind für viele, wenn auch nicht alle gängigen Programmiersprachen verfügbar. Wenn Sie Probleme mit bestimmten Memcached-Clients bei der Verwendung von ElastiCache haben, wenden Sie sich bitte über das ElastiCache-Community-Forum an uns.

ElastiCache benötigt keine speziellen Clientbibliotheken und funktioniert mit vorhandenen Memcached-Clientbibliotheken ohne Neukompilierung oder Neuverknüpfung von Anwendungen (Memcached 1.4.5 und höher). Beispiele hierfür sind libMemCached (C) und darauf basierende Bibliotheken (zum Beispiel PHP, Perl, Python), spyMemCached (Java) und fauna (Ruby).

Autoerkennung ist eine Funktion, die Entwicklern Zeit und Mühe spart und gleichzeitig die Komplexität ihrer Anwendungen reduziert. Autoerkennung ermöglicht Clients das automatische Auffinden von Cache-Knoten, wenn diese einem ElastiCache-Cluster hinzugefügt oder daraus entfernt werden. Bisher mussten die Entwickler die Liste der Cache-Knoten-Endpunkte manuell aktualisieren, um Änderungen der Cluster-Mitgliedschaft zu verarbeiten. Je nach Architektur der Client-Anwendung ist zumeist eine Client-Initialisierung durch ein Herunterfahren der Anwendung und ihren Neustart erforderlich, was zu Ausfallzeiten führt. Durch Auto Discovery beseitigt ElastiCache diese Komplexität. Über Autoerkennung, die zudem mit dem Memcached-Protokoll abwärtskompatibel ist, stellt ElastiCache Clients Informationen zu Cache-Cluster-Mitgliedern bereit. Ein Client, der die zusätzlichen Informationen verarbeiten kann, konfiguriert sich selbst ohne jegliche Initialisierung für die Nutzung der neuesten Knoten eines ElastiCache-Clusters neu.

Ein ElastiCache-Cluster kann mit Knoten erstellt werden, die durch benannte Endpunkte adressierbar sind. Über Autoerkennung erhält der ElastiCache-Cluster zudem einen eindeutigen Konfigurationsendpunkt, bei dem es sich um einen für die Nutzungsdauer des Clusters gültigen DNS-Eintrag handelt. Dieser DNS-Eintrag enthält die DNS-Namen der zum Cluster gehörenden Knoten. ElastiCache stellt sicher, dass der Konfigurationsendpunkt stets auf mindestens einen solchen Zielknoten verweist. Eine an den Zielknoten gerichtete Abfrage gibt anschließend Endpunkte aller Knoten des betreffenden Clusters zurück. Danach können Sie sich wie bisher mit den Clusterknoten verbinden und die Memcached-Protokollbefehle wie get, set, incr und decr verwenden. Weitere Informationen finden Sie in der Dokumentation. Um Autoerkennung zu verwenden, benötigen Sie einen Client, der Autoerkennung unterstützt. Autoerkennung-Clients für .Net, Java und PHP stehen in der ElastiCache-Konsole zum Herunterladen bereit. Bei der Initialisierung ermittelt der Client automatisch die aktuellen Mitglieder des ElastiCache-Clusters mithilfe des Konfigurationsendpunkts. Wenn Sie Änderungen am Cache-Cluster vornehmen, indem Sie Knoten hinzufügen oder entfernen oder einen ausgefallener Knoten austauschen, erkennt der Autoerkennung-Client automatisch die Änderungen, sodass Sie Ihre Clients nicht manuell initialisieren müssen.

Laden Sie zunächst den ElastiCache-Cluster-Client herunter, indem Sie in der ElastiCache-Konsole den Link ElastiCache-Cluster-Client herunterladen auswählen. Zum Herunterladen benötigen Sie ein ElastiCache-Konto. Sollten Sie noch keines haben, können Sie sich auf der ElastiCache-Seite mit den Details anmelden. Nachdem Sie den Client heruntergeladen haben, können Sie Ihren ElastiCache-Cluster über die ElastiCache-Konsole einrichten und aktivieren. Weitere Details finden Sie in der Dokumentation.

Ja, Sie können die Nutzung von Autoerkennung jederzeit einstellen. Sie können Autoerkennung deaktivieren, indem Sie während der Initialisierung des ElastiCache-Cluster-Clients den Betriebsmodus angeben. Und da ElastiCache Memcached weiter unterstützt, können Sie jeden mit Memcached auf Protokollebene kompatiblen Client wie zuvor nutzen.

Um die Vorteile der Autoerkennung zu nutzen, muss ein Client, der die Autoerkennung unterstützt, für die Verbindung mit einem ElastiCache-Cluster verwendet werden. ElastiCache unterstützt derzeit Clients, die Autoerkennung für .Net, Java und PHP unterstützen. Diese können aus der ElastiCache-Konsole heruntergeladen werden. Aufbauend auf den verfügbaren beliebten Memcached-Clients können Sie Clients für andere Programmiersprachen erstellen.

Sie können eine beliebige Memcached-Client-Bibliothek wählen und Unterstützung für Autoerkennung hinzufügen. Wenn Sie möchten, dass Ihr eigener Client Autoerkennung unterstützt, konsultieren Sie die Unterlagen für den Befehlssatz für Autoerkennung.

Ja, ElastiCache unterstützt weiter das Memcached-Protokoll, sodass Sie Ihre Clients nicht ändern müssen. Um jedoch die Autoerkennungs-Funktion nutzen zu können, haben wir die Funktionen des Memcached-Clients verbessert. Wenn Sie den ElastiCache-Cluster-Client nicht nutzen möchten, können Sie weiter Ihre eigenen Clients einsetzen oder Ihre eigene Client-Bibliothek so ändern, dass der Befehlssatz von Autoerkennung unterstützt wird.
 

Ja, derselbe ElastiCache-Cluster kann über einen Client, der Autoerkennung beherrscht, und den traditionellen Memcached-Client gleichzeitig verbunden werden. ElastiCache bleibt zu 100 % mit Memcached kompatibel.

Ja, Sie können die Nutzung von Autoerkennung jederzeit einstellen. Sie können Autoerkennung deaktivieren, indem Sie während der Initialisierung des ElastiCache-Cluster-Clients den Betriebsmodus angeben. Und da ElastiCache Memcached weiter unterstützt, können Sie jeden mit Memcached auf Protokollebene kompatiblen Client wie zuvor nutzen.

Mit ElastiCache können Sie steuern, ob und wann die mit dem Memcached-Protokoll kompatible Software, die Ihrem Cluster zugrunde liegt, auf neue, von ElastiCache unterstützte Versionen aktualisiert werden soll. Damit bleiben Sie flexibel – Sie können die Kompatibilität mit spezifischen Memcached-Versionen sicherstellen, neue Versionen mit Ihrer Anwendung testen, bevor Sie sie in der Produktionsumgebung bereitstellen, und Versions-Upgrades nach Ihren eigenen Vorstellungen und Zeitplänen durchführen. Versions-Upgrades bergen ein gewisses Kompatibilitätsrisiko, daher erfolgen sie nicht automatisch, sondern müssen von Ihnen initiiert werden. Mit diesem Ansatz des Software-Patchings haben Sie die Kontrolle über die Versions-Upgrades, können aber gleichzeitig die mit dem Patching verbundenen Arbeitsschritte an ElastiCache weitergeben. Weitere Informationen über die Versionsverwaltung finden Sie in den folgenden häufig gestellten Fragen. Weitere Informationen finden Sie auch im ElastiCache-Benutzerhandbuch. Die Funktion des Versionsmanagements für die Engine soll Ihnen möglichst viel Flexibilität in Bezug auf das Patching gewähren. Das Patching für Ihren Cluster kann jedoch auch automatisch erfolgen, wenn wir Sicherheitslücken im System oder in der Cache-Software erkennen.

Beim Erstellen eines neuen Clusters können Sie eine beliebige derzeit unterstützte Version (Haupt-/oder Nebenversion) angeben. Wenn Sie ein Upgrade auf eine unterstützte Engine-Version auslösen möchten, wählen Sie die Option „Ändern“ für Ihren Cluster. Geben Sie im Feld Cache Engine Version die Version an, auf die Sie aktualisieren möchten. Das Upgrade wird dann entweder sofort (bei aktivierter Option Sofort angewendet) oder im nächsten für Ihren Cluster geplanten Wartungsfenster ausgeführt.

Ja. Erstellen Sie zu diesem Zweck einen neuen Cluster mit der neuen Engine-Version. Verweisen Sie Ihre Entwicklungs- oder Staging-Anwendung auf diesen Cluster, testen Sie ihn und entscheiden Sie, ob der ursprüngliche Cluster aktualisiert werden soll.

Wir planen, weitere Memcached-Versionen für ElastiCache zu unterstützen, sowohl als Haupt- als auch als Nebenversion. Die Anzahl der in einem Jahr unterstützten neuen Versionsveröffentlichungen variiert je nach Häufigkeit und Inhalt der Memcached-Versions-Veröffentlichungen und dem Ergebnis einer gründlichen Prüfung der Veröffentlichung durch unser Engineering-Team.

Sie können Ihren vorhandenen Memcached-Cluster mithilfe des Modify-Prozesses ändern. Wenn Sie von einer älteren Memcached-Version auf die Memcached-Version 1.4.33 oder neuer upgraden, stellen Sie sicher, dass Ihre vorhandenen Werte des Parameters max_chunk_size den für den Parameter slab_chunk_max erforderlichen Bedingungen entsprechen. Die Voraussetzungen für Upgrades finden Sie hier.

ElastiCache bietet erweiterte E/A-Threads, die durch Multiplexing, Presentation Layer Offloading und mehr zu deutlichen Verbesserungen des Durchsatzes und der Latenz in großem Maßstab führen. Erweiterte E/A-Threads verbessern die Leistung, indem sie mehr Kerne für die E/A-Verarbeitung nutzen und sich dynamisch an den Workload anpassen. ElastiCache verbessert den Durchsatz von TLS-fähigen Clustern, indem es die Verschlüsselung auf dieselben erweiterten E/A-Threads auslagert. ElastiCache (Redis OSS) Version 7.0 führte ein verbessertes E/A-Multiplexing ein, das viele Anfragen von Clients in einem einzigen Kanal zusammenfasst und die Threads-Effizienz verbessert.

In ElastiCache Version 7.1 und höher für Redis OSS haben wir die erweiterte E/A-Thread-Funktionalität erweitert, um auch die Logik der Präsentationsebene zu verarbeiten. Erweiterte E/A-Threads lesen nicht nur Client-Eingaben, sondern analysieren die Eingaben auch in ein binäres Befehlsformat, das dann zur Ausführung an den Haupt-Thread weitergeleitet wird, um Leistungssteigerungen zu erzielen. Mit ElastiCache Version 7.1 für Redis OSS können Sie im Vergleich zur Vorgängerversion einen bis zu 100 % höheren Durchsatz und eine um 50 % geringere P99-Latenz erreichen. Auf r7g.4xlarge oder größer können Sie über 1 Million Anfragen pro Sekunde (RPS) pro Knoten erreichen.

ElastiCache bietet zwei verschiedene Gruppen von Metriken, um die CPU-Auslastung Ihres Caches zu messen, je nachdem, welche Cache-Bereitstellung Sie gewählt haben. Wenn Sie ElastiCache Serverless verwenden, können Sie die CPU-Auslastung mit der ElastiCache Processing Units (eCPU)-Metrik überwachen. Die Anzahl der von Ihren Anfragen verbrauchten eCPUs hängt von der benötigten vCPU-Zeit und der übertragenen Datenmenge ab. Jedes Lesen und Schreiben erfordert, wie die Redis-OSS-Befehle GET und SET oder die Memcached-Befehle get und set, 1 ECPU für jedes übertragene Kilobyte (KB) an Daten. Einige Redis-OSS-Befehle, die mit speicherinternen Datenstrukturen arbeiten, können mehr vCPU-Zeit in Anspruch nehmen als ein GET- oder SET-Befehl. ElastiCache berechnet die Anzahl der verbrauchten ECPUs basierend auf der vCPU-Zeit, die der Befehl benötigt, im Vergleich zu einer Basislinie der vCPU-Zeit, die ein SET- oder GET-Befehl benötigt. Wenn Ihr Befehl zusätzliche vCPU-Zeit benötigt und mehr Daten als die Baseline von 1 ECPU überträgt, berechnet ElastiCache die erforderlichen eCPUs auf der Grundlage der höheren der beiden Dimensionen.

Wenn Sie Ihren eigenen Cluster entwerfen, können Sie EngineCPUUtilization und CPUUtilization überwachen. Die CPUUtilization-Metrik misst die CPU-Auslastung für die Instance (Knoten), und die EngineCPUUtilization-Metrik misst die Auslastung auf Engine-Prozessebene. Sie benötigen die EngineCPUUtilization-Metrik zusätzlich zur CPUUtilization-Metrik, weil der Redis-OSS-Hauptprozess einen einzigen Thread umfasst und nur eine CPU der verschiedenen CPU-Cores nutzt, die auf einer Instance verfügbar sind. Daher bietet die CPUUtilization-Metrik keinen genauen Einblick in die CPU-Auslastungsraten auf der Ebene des Engine-Prozesses. Es wird empfohlen, dass Sie sowohl die CPUUtilization- als auch die EngineCPUUtilization-Metrik zusammen verwenden, um ein detailliertes Verständnis der CPU-Auslastung für Ihre Redis-OSS-Cluster zu erhalten.

Beide Sätze von Metriken sind in allen AWS-Regionen verfügbar, und Sie können auf diese Metriken mit Amazon CloudWatch oder in der Konsole zugreifen. Außerdem empfehlen wir Ihnen, die Dokumentation um mehr über nützliche Metriken zur Leistungsüberwachung zu erfahren.

Lesereplikate dienen in Redis OSS zwei Zwecken:

• Behandlung von Störungen
• Leseskalierung

Wenn Sie einen Cache mit einem Lesereplikat betreiben, dient der Primärknoten sowohl für Schreib- als auch für Lesevorgänge. Das Replikat dient ausschließlich dem Leseverkehr und ist auch als Warm-Standby verfügbar, falls die primäre Version beeinträchtigt wird.

Mit ElastiCache Serverless werden Lesereplikate automatisch vom Service verwaltet. Beim Entwerfen Ihres eigenen Caches gibt es eine Vielzahl von Szenarien, in denen die Bereitstellung einer oder mehrerer Lesereplikate für einen bestimmten primären Knoten sinnvoll sein kann. Häufige Gründe für die Bereitstellung einer Read Replica:

• Skalierung über die Rechen- oder E/A-Kapazität eines einzelnen primären Knotens für leseintensive Workloads hinaus: Dieser überschüssige Leseverkehr kann auf ein oder mehrere Lesereplikate geleitet werden.
• Servieren von Leseverkehr, während der primäre Knoten nicht verfügbar ist: Wenn Ihr primärer Knoten keine E/A-Anforderungen annehmen kann (z. B. aufgrund einer E/A-Sperre für Backups oder geplante Wartungsarbeiten), können Sie den Leseverkehr auf Ihre Lesereplikate umleiten. Denken Sie in diesem Fall daran, dass die Daten im Lesereplikat veraltet sein können, da die Primär-Instance nicht verfügbar ist. Das Lesereplikat kann auch zum Neustarten eines ausgefallenen eingeschalteten Primärknotens verwendet werden.
• Szenarien zur Datensicherung: Im unwahrscheinlichen Fall eines Ausfalls des primären Knotens oder wenn die AZ, in der sich Ihr primärer Knoten befindet, nicht mehr verfügbar ist, können Sie ein Lesereplikat in einer anderen AZ zum neuen primären Knoten ernennen. 

Sie können eine Verbindung zu einem Lesereplikat genauso herstellen, wie Sie eine Verbindung zu einem primären Cache-Knoten herstellen würden. Wenn Sie mehrere Read Replicas nutzen, muss Ihre Anwendung bestimmen, wie der Lesedatenverkehr auf diese verteilt wird. Hier weitere Informationen:

• Redis-OSS-Cluster (Clustermodus deaktiviert) verwenden die einzelnen Knotenendpunkte für Lesevorgänge. (In der API/CLI werden diese als Leseendpunkte bezeichnet.)
• Redis-OSS-Cluster (aktivierter Cluster-Modus) verwenden für alle Vorgänge den Konfigurationsendpunkt. Sie können immer noch von einzelnen Knotenendpunkten lesen. (In der API und CLI werden diese als Leseendpunkte bezeichnet.)

ElastiCache bietet Ihnen die Möglichkeit, bis zu fünf (5) Lesereplikate für einen primären Cache-Knoten zu erstellen.

Im Falle eines Failovers müssen alle zugeordneten und verfügbaren Read Replicas automatisch die Replikation fortsetzen, nachdem das Failover abgeschlossen wurde (d. h., sie beginnen mit dem Abrufen von Updates aus der neu hochgestuften Read Replica).

Aktualisierungen eines primären Cache-Knotens werden automatisch in allen zugeordneten Lesereplikaten repliziert. Bei der asynchronen Replizierungstechnologie von Redis OSS kann es jedoch aus verschiedenen Gründen dazu kommen, dass ein Lesereplikat hinter ihren primären Cache-Knoten zurückfällt. Typische Gründe hierfür sind:

• Das E/A-Schreibvolumen in den primären Cache-Knoten übersteigt die Rate, mit der Änderungen vom Lesereplikat übernommen werden können.
• Netzwerkpartitionen oder Latenz zwischen dem primären Cache-Knoten und einem Lesereplikat.

Lesereplikate unterliegen den Stärken und Schwächen der Redis-OSS-Replikation. Wenn Sie Lesereplikate verwenden, sollten Sie sich über die potenziellen Verzögerungen (die so genannten „Inkonsistenzen“) zwischen einem Lesereplikat und ihrem primären Cache-Knoten bewusst sein. ElastiCache gibt eine Metrik aus, die Ihnen hilft, die Inkonsistenz zu verstehen.

Ein Lesereplikat wird als Standard-Cache-Knoten und zu denselben Tarifen abgerechnet. Wie bei einem Standard-Cache-Knoten auch wird der Tarif pro „Cache-Knoten-Stunde“ für ein Lesereplikat von der Cache-Knoten-Klasse des Lesereplikats bestimmt. Aktuelle Preisangaben finden Sie auf der Preisseite von ElastiCache. Der bei der Replikation von Daten zwischen Ihrem primären Cache-Knoten und dem Lesereplikat anfallende Datenverkehr wird nicht in Rechnung gestellt. Die Fakturierung für ein Lesereplikat beginnt, sobald diese erfolgreich erstellt wurde (wenn der Status als aktiv ausgewiesen ist). Das Lesereplikat wird so lange nach standardmäßigen Cache-Knoten-Stundensätzen von ElastiCache abgerechnet, bis Sie den Befehl zu ihrem Löschen aufrufen.

Das Failover wird automatisch von ElastiCache ausgelöst, damit Sie Cache-Vorgänge schnellstmöglich fortsetzen können. Bei einem Failover schaltet ElastiCache den DNS-Datensatz Ihres Cache-Knotens auf das Lesereplikat um, die wiederum zum neuen Primärknoten hochgestuft wird. Wir empfehlen Ihnen, sich an bewährte Methoden zu halten und eine Funktion auf Anwendungsebene zu implementieren, die ggf. erneut versucht, eine Cache-Knotenverbindung herzustellen. In der Regel sind die Schritte eins bis fünf von Anfang bis Ende innerhalb von sechs Minuten abgeschlossen.

Dies sind die automatischen Failover-Ereignisse, aufgelistet in der Reihenfolge ihres Auftreten:

1. Meldung der Replikationsgruppe: Test Failover-API für Knotengruppe <Knotengruppen-ID> aufgerufen
2. Cache-Cluster-Meldung: Failover von Primärknoten <Primärknoten-ID> auf Replikatknoten <Knoten-ID> abgeschlossen
3. Meldung der Replikationsgruppe: Failover von Primärknoten <Primärknoten-ID> auf Replikatknoten <Knoten-ID> abgeschlossen
4. Cache-Cluster-Meldung: Cache-Knoten <Knoten-ID> wiederherstellen
5. Cache-Cluster-Meldung: Wiederherstellung für Cache-Knoten <Knoten-id> beendet

Nein, Ihr Lesereplikat kann nur in derselben oder einer anderen AZ derselben Region wie Ihr primärer Cache-Knoten bereitgestellt werden. Sie können jedoch den Global Datastore verwenden, um mit einer vollständig verwalteten, schnellen, zuverlässigen und sicherheitsorientierten Replikation über AWS-Regionen hinweg zu arbeiten. Mit diesem Feature können Sie regionenübergreifende Lesereplikat-Cluster für ElastiCache erstellen, um Lesevorgänge mit niedriger Latenz und Notfallwiederherstellung über AWS-Regionen hinweg zu ermöglichen.

Ja. Sie können mithilfe der DescribeCacheClusters-API den Speicherort des aktuellen Primärknotens ermitteln.

Ja. Sie können ein Lese-Replikat über einen oder mehrere Shards in einer Cluster-Umgebung hinweg hinzufügen oder entfernen. Der Cluster bleibt online und verarbeitet während des Vorgangs weiterhin eingehende E/A.

Multi-AZ ist ein Feature, das es Ihnen ermöglicht, in einer Konfiguration mit höherer Verfügbarkeit zu arbeiten, wenn Sie Ihren eigenen ElastiCache-Cache entwerfen. Alle ElastiCache Serverless Caches werden automatisch in einer Multi-AZ-Konfiguration ausgeführt. Ein ElastiCache-Replikationsgruppe besteht aus einem Primärknoten und bis zu fünf Lesereplikaten. Wenn Multi-AZ aktiviert ist, ist mindestens ein Replikat pro Primärknoten erforderlich. Während bestimmter geplanter Wartungsarbeiten oder im unwahrscheinlichen Fall eines ElastiCache-Knotenausfalls oder eines AZ-Ausfalls erkennt ElastiCache automatisch den Ausfall eines primären Knotens, wählt ein Lesereplikat aus und ernennt es zum neuen primären. ElastiCache überträgt auch die DNS-Änderungen der hochgestuften Read Replica. Wenn Ihre Anwendung auf den Primärknoten-Endpunkt schreibt, ist daher keine Änderung des Endpunkts erforderlich.

Die Hauptvorteile beim Ausführen Ihres ElastiCache im Multi-AZ-Modus sind verbesserte Verfügbarkeit und ein geringerer Bedarf für Administration. Wenn Sie ElastiCache in einer Multi-AZ-Konfiguration ausführen, kommen Ihre Caches für das SLA mit einer Verfügbarkeit von 99,99 % in Frage. Wenn ein für ElastiCache-Primärknoten ausfällt, sind die Auswirkungen auf Ihre Fähigkeit zum Lesen und Schreiben auf den Primärknoten auf die Zeit begrenzt, die für die Durchführung des automatischen Failovers benötigt wird. Wenn Multi-AZ aktiviert ist, wird der Failover des ElastiCache-Knotens automatisch durchgeführt und benötigt keine Administration. 

Sie können Multi-AZ benutzen, wenn Sie ElastiCache verwenden und über eine Replikationsgruppe verfügen, die aus einem Primärknoten und einer oder mehreren Lesereplikaten besteht. Wenn der Primärknoten ausfällt, entdeckt ElastiCache automatisch den Ausfall, wählt eins der verfügbaren Lesereplikate und stuft dieses zum neuen Primärknoten hoch. ElastiCache propagiert die DNS-Änderungen des hochgestuften Replikats, damit Ihre Anwendung weiterhin auf den primären Endpunkt schreiben kann. ElastiCache richtet auch einen neuen Knoten ein, um das hochgestufte Lesereplikat in der gleichen AZ des ausgefallenen primären zu ersetzen. Falls die primäre Kopie aufgrund einer vorübergehenden Störung der AZ ausfällt, wird die neue Kopie gestartet, sobald sich die AZ erholt hat.

Ja. Beachten Sie, dass die Platzierung sowohl der primären als auch der Replikate in der gleichen AZ Ihre ElastiCache-Replikationsgruppe nicht widerstandsfähig gegenüber einer AZ-Störung macht. Außerdem sind Replikate in derselben AZ wie die primäre nicht zulässig, wenn Multi-AZ aktiviert ist.

ElastiCache führt bei folgenden Ereignissen einen Failover auf ein Lesereplikat durch:

• Verlust der Erreichbarkeit im AZ des Primärknotens
• Verlust der Netzwerkverbindung zur Primär-Instanz
• Ausfall einer Datenverarbeitungseinheit in der Primär-Instanz

Wenn mehr als ein Lese-Replikat vorhanden ist, wird das Lese-Replikat mit der geringeren asynchronen Replikationsverzögerung zum Primärserver hochgestuft.

Ja, ElastiCache erstellt ein Ereignis, um Sie zu informieren, dass ein automatischer Failover durchgeführt wurde. Sie können die DescribeEvents-API verwenden, um Informationen zu Ereignissen im Zusammenhang mit Ihrem ElastiCache-Knoten abzurufen, oder den Abschnitt Ereignisse der ElastiCache-Managementkonsole wählen.

Die AZs sind so konzipiert, dass sie Netzwerkverbindungen mit geringer Latenz zu anderen AZs in derselben Region bieten. Sie sollten in Erwägung ziehen, Ihre Anwendung und andere AWS-Ressourcen mit Redundanz über mehrere AZs hinweg zu gestalten, damit Ihre Anwendung im Falle einer AZ-Störung widerstandsfähig ist.

Weitere Informationen über Multi-AZ finden Sie in der ElastiCache-Dokumentation.

Backup and Restore ist ein Feature, mit dem Sie Snapshots Ihrer ElastiCache-Caches erstellen können. ElastiCache speichert die Snapshots, die Benutzer anschließend zum Wiederherstellen von Caches verwenden können. Dies wird derzeit mit ElastiCache für Valkey, ElastiCache für Redis OSS und Serverless unterstützt. 

Das Erstellen von Snapshots kann bei durch einen Knotenausfall verursachten Datenverlusten sowie im unwahrscheinlichen Fall eines Hardwareausfalls nützlich sein. Sicherungen werden außerdem für Archivierungszwecke verwendet. Die Snapshots werden in Amazon S3 aufbewahrt.

Bei Auslösen einer Sicherung erstellt ElastiCache einen Snapshot eines angegebenen Cache, der später für Wiederherstellungs- oder Archivierungszwecke verwendet werden kann. Sie können jederzeit eine Sicherung starten oder eine täglich wiederkehrende Sicherung mit einer Aufbewahrungsfrist von bis zu 35 Tagen festlegen. Wenn Sie einen Snapshot zur Wiederherstellung auswählen, wird ein neuer ElastiCache-Cache erstellt und mit den Daten des Snapshots gefüllt. ElastiCache-Snapshots sind mit dem Redis-OSS-RDB-Dateiformat kompatibel.

Sie können die Sicherungs- und Wiederherstellungsfunktion über die Konsole, ElastiCache-APIs und AWS CLI verwenden. Sie können das Feature jederzeit de- bzw. reaktivieren.

Die Sicherungs- und Wiederherstellungsfunktion erstellt Snapshots pro Cache. Benutzer können über die Konsole, AWS CLI oder die ElastiCache-API angeben, welcher ElastiCache-Cache gesichert werden soll. Es wird empfohlen, die Sicherung auf einem der Lesereplikate des Cache zu aktivieren, um mögliche Auswirkungen auf den Primärknoten zu minimieren. Bei Verwendung von ElastiCache Serverless werden Backups automatisch anhand von Lesereplikaten durchgeführt.

Ja, Sie können Ihre ElastiCache-Snapshots in einen autorisierten S3-Bucket in derselben Region wie Ihr Cache exportieren.

Ja. Sie müssen zunächst Ihren Snapshot in einen autorisierten S3-Bucket Ihrer Wahl in derselben Region kopieren und anschließend dem anderen Konto kontenübergreifende Bucket-Berechtigungen gewähren.

ElastiCache bietet kostenlos Speicherplatz für einen Snapshot jedes aktiven ElastiCache-Cache. Zusätzlicher Speicherplatz wird basierend auf dem von den Snapshots belegten Speicherplatz mit monatlich 0,085 USD pro GB in Rechnung gestellt (Einheitspreis in allen Regionen). Die Datenübertragung zur Nutzung der Snapshots ist kostenlos.

Wenn Sie einen ElastiCache-Cache löschen, bleiben Ihre manuellen Snapshots erhalten. Sie haben auch die Möglichkeit, einen letzten Snapshot zu erstellen, bevor der Cache gelöscht wird. Automatisch erstellte Cache-Snapshots werden nicht aufbewahrt.

Die Engine in ElastiCache ist vollständig mit Redis OSS kompatibel, bietet aber auch Verbesserungen, die die Leistung, Robustheit und Stabilität verbessern. Einige der Erweiterungen umfassen:

• Mehr nutzbarer Arbeitsspeicher: Sie können jetzt problemlos mehr Arbeitsspeicher für Ihre Anwendung zuweisen, ohne während Synchronisierungen und Snapshots eine erhöhte Swap-Nutzung zu riskieren.
• Verbesserte Synchronisierung: Zuverlässigere Synchronisierung unter hoher Last und beim Wiederherstellen von getrennten Netzwerkverbindungen. Außerdem sind Synchronisierungen schneller, da Primärknoten und Replikate die Festplatte nicht mehr für diesen Vorgang verwenden.
• Problemlosere Failovers: Im Falle eines Failovers wird die Shard jetzt schneller wiederhergestellt, da Replikate ihre Daten nicht mehr komplett löschen, um eine vollständige erneute Synchronisierung mit dem Primärknoten durchzuführen.
• TLS-Offload und IO-Multiplexing: ElastiCache wurde entwickelt, um verfügbare CPU-Ressourcen besser zu nutzen, indem bestimmte netzwerkbezogene Prozesse in dedizierten Threads verarbeitet werden.

Nein. Das erweiterte Engine ist mit Redis OSS voll kompatibel, so dass Sie die verbesserte Zuverlässigkeit und Stabilität nutzen können, ohne Änderungen am Anwendungscode vorzunehmen zu müssen.

Für die Verwendung der erweiterten Engine fallen keine zusätzlichen Gebühren an.

Die Verschlüsselung im Ruhezustand bietet Mechanismen zum Schutz vor unberechtigtem Zugriff auf Ihre Daten. Wenn diese Option aktiviert ist, werden die folgenden Aspekte verschlüsselt:

• Festplatte während Synchronisations-, Sicherungs- und Auslagerungsvorgängen
• In Amazon S3 gespeicherte Backups

ElastiCache bietet standardmäßige (service-verwaltete) Verschlüsselung im Ruhezustand sowie die Möglichkeit, Ihre eigenen symmetrischen, vom Kunden verwalteten AWS-KMS-Schlüssel in AWS KMS zu verwenden. Weitere Informationen finden Sie unter Verschlüsselung im Ruhezustand.

Das Feature Verschlüsselung in Transit ermöglicht die Verschlüsselung der Kommunikation zwischen Clients und ElastiCache sowie zwischen den Servern (primäre und Lesereplikate). Erfahren Sie mehr über die Verschlüsselung während der Übertragung durch ElastiCache.

Verschlüsselung während der Übertragung, Verschlüsselung im Ruhezustand, Redis OSS AUTH und Role-Based Access Control (RBAC) sind Features, die Sie bei der Erstellung Ihres ElastiCache-Caches auswählen können. Wenn Sie die Verschlüsselung während der Übertragung aktiviert haben, können Sie Redis OSS AUTH oder RBAC für zusätzliche Sicherheit und Zugriffskontrolle verwenden.

Nein. ElastiCache verwaltet den Ablauf und die Verlängerung von Zertifikaten im Hintergrund. Vom Benutzer werden für den Zertifikaterhalt keine Aktionen erwartet.

Nein, für die Nutzung der Verschlüsselung werden keine zusätzlichen Gebühren berechnet.

Global Datastore ist ein Feature von ElastiCache, die eine vollständig verwaltete, schnelle, zuverlässige und sicherheitsorientierte regionenübergreifende Replikation ermöglicht. Mit Global Datastore können Sie in Ihren Cache in einer Region schreiben und die Daten in bis zu zwei anderen regionenübergreifenden Replikat-Clustern zum Lesen bereitstellen, was Lesevorgänge mit niedriger Latenz und Notfallwiederherstellung über Regionen hinweg ermöglicht.

Global Datastore wurde für Echtzeitanwendungen mit globaler Präsenz entwickelt und repliziert Daten in der Regel in weniger als einer Sekunde über die Regionen hinweg, wodurch die Reaktionsfähigkeit Ihrer Anwendungen verbessert wird, da geolokale Lesevorgänge näher am Endbenutzer stattfinden. Im unwahrscheinlichen Fall eines regionalen Ausfalls kann einer der gesunden regionenübergreifenden Replikat-Caches zum primären Cache mit vollen Lese- und Schreibfunktionen werden. Nach dem Start ist die Beförderung in der Regel in weniger als einer Minute abgeschlossen, sodass Ihre Anwendungen weiterhin zur Verfügung stehen.

Sie können auf bis zu zwei sekundäre Regionen innerhalb eines globalen Datenspeichers replizieren. Die Caches in den sekundären Regionen können für lokale Lesevorgänge mit geringer Latenz und für die Notfallwiederherstellung im unwahrscheinlichen Fall eines Ausfalls der Region verwendet werden.

Global Datastore wird in ElastiCache für Redis 5.0.6 und höher unterstützt.

Nein. ElastiCache fördert nicht automatisch einen sekundären Cluster, wenn der primäre Cluster (Region) degradiert wird. Sie können das Failover manuell durchführen, indem Sie einen sekundären Cluster zu einem primären heraufstufen. Der Failover und die Heraufstufung eines sekundären Clusters sind in der Regel in weniger als einer Minute abgeschlossen.

Der globale Datenspeicher verwendet für den regionsübergreifenden Datenverkehr eine Verschlüsselung während der Übertragung, um die Sicherheit Ihrer Daten zu erhöhen. Zusätzlich können Sie auch Ihre primären und sekundären Caches mit der Verschlüsselung im Ruhezustand absichern, um Ihre Daten besser zu schützen. Jeder primäre und sekundäre Cache kann über einen separaten, vom Kunden verwalteten AWS-KMS-Schlüssel für die Verschlüsselung im Ruhezustand verfügen.

ElastiCache bietet kein SLA für RPO und RTO. Das RPO variiert je nach Replikationsverzögerung zwischen den Regionen und hängt von der Netzwerklatenz zwischen den Regionen und der regionsübergreifenden Netzwerküberlastung ab. Das RPO von Global Datastore liegt typischerweise unter einer Sekunde, sodass die in der primären Region geschriebenen Daten in den sekundären Regionen innerhalb einer Sekunde verfügbar sind. Das RTO von Global Datastore beträgt in der Regel weniger als eine Minute. Sobald ein Failover auf einen sekundären Cluster eingeleitet wird, gewährt ElastiCache in der Regel dem sekundären Cluster vollständige Lese-/Schreibfähigkeiten in weniger als einer Minute.

ElastiCache bietet kein SLA für RPO und RTO. Das RPO variiert je nach Replikationsverzögerung zwischen den Regionen und hängt von der Netzwerklatenz zwischen den Regionen und der regionsübergreifenden Netzwerküberlastung ab. Das RPO von Global Datastore liegt typischerweise unter einer Sekunde, sodass die in der primären Region geschriebenen Daten in den sekundären Regionen innerhalb einer Sekunde verfügbar sind. Das RTO von Global Datastore beträgt in der Regel weniger als eine Minute. Sobald ein Failover auf einen sekundären Cluster eingeleitet wird, gewährt ElastiCache in der Regel dem sekundären Cluster vollständige Lese-/Schreibfähigkeiten in weniger als einer Minute.

Daten-Tiering bietet eine neue Preis-Leistungs-Option durch die Verwendung kostengünstiger Solid-State-Laufwerke (SSDs) in jedem Clusterknoten zusätzlich zur Speicherung von Daten im Speicher. Es ist ideal für Workloads, die regelmäßig auf bis zu 20 % ihres gesamten Datenbestands zugreifen, und für Anwendungen, die zusätzliche Latenzzeiten beim Zugriff auf SSD-Daten tolerieren können. ElastiCache-R6gd-Knoten mit Arbeitsspeicher und SSDs verfügen über eine fast 5-fach höhere Gesamtspeicherkapazität und können Ihnen bei maximaler Auslastung im Vergleich zu ElastiCache R6g-Knoten mit nur Arbeitsspeicher zu einer Preisersparnis von über 60 % verhelfen.

Das Daten-Tiering funktioniert durch automatisches und transparentes Verschieben der am wenigsten verwendeten Elemente aus dem Speicher auf lokal angeschlossene NVMe-SSDs, wenn die verfügbare Speicherkapazität vollständig aufgebraucht ist. Wenn auf ein Element, das auf den SSD verschoben wurde, später zugegriffen wird, verschiebt ElastiCache es asynchron zurück in den Speicher, bevor die Anforderung bedient wird.

Daten-Tiering ist so konzipiert, dass es nur minimale Auswirkungen auf die Anwendungsleistung hat. Geht man von 500-Byte-String-Werten aus, kann man mit einer zusätzlichen Latenzzeit von durchschnittlich 300 µs für Anfragen an auf SSD gespeicherte Daten im Vergleich zu Anfragen an Daten im Speicher rechnen.

ElastiCache unterstützt Daten-Tiering für ElastiCache für Redis-OSS-Versionen 6.2 und höher.

ElastiCache unterstützt Daten-Tiering auf Clustern mithilfe von R6gd-Knoten.

Alle Valkey- und Redis-OSS-Befehle und die meisten ElastiCache-Features werden bei der Verwendung von Daten-Tiering unterstützt. Eine Liste der Features, die auf Clustern mit Daten-Tiering nicht unterstützt werden, finden Sie in der Dokumentation.

Außer den Stundenkosten des Knotens fallen keine weiteren Kosten für die Verwendung von Daten-Tiering an. Knoten mit Daten-Tiering sind mit On-Demand-Preisen und als reservierte Knoten erhältlich. Preise finden Sie auf der ElastiCache-Preisseite.