Amazon OpenSearch Service FAQs

Ja. Mit dem Assistenten zur Domain-Erstellung in der Konsole können Sie mit nur wenigen Klicks eine neue Amazon-OpenSearch-Service-Domain erstellen. Beim Erstellen einer neuen Domain können Sie die Anzahl von Instances und die Instance-Typen sowie die EBS-Volumes angeben, die Sie Ihrer Domain zuweisen möchten. Außerdem können Sie über die Konsole bestehende Amazon-OpenSearch-Service-Domain bearbeiten und löschen.

Ja. Amazon OpenSearch Service ist in Amazon VPC integriert. Wenn Sie den VPC-Zugriff wählen, sind die IP-Adressen Ihrer VPC Ihrer Amazon-OpenSearch-Service-Domain zugewiesen. Sämtlicher Netzwerkdatenverkehr bleibt innerhalb des AWS-Netzwerks und ist nicht über das Internet zugänglich. Zusätzlich können Sie mit Sicherheitsgruppen und IAM-Richtlinien den Zugriff auf Ihre Amazon-OpenSearch-Service-Domains einzuschränken.

Ja. AWS CloudFormation unterstützt Amazon OpenSearch Service. Weitere Informationen finden Sie in der CloudFormation-Vorlagenreferenz-Dokumentation.

Ja. Sie können dedizierte Master-Knoten für Ihre Domains konfigurieren. Wenn Sie eine dedizierte Master-Konfiguration wählen, können Sie Typ und Anzahl der Instances festlegen.

Ja. Sie können mehrere OpenSearch-Indizes innerhalb einer Amazon-OpenSearch-Service-Domain erstellen. Elasticsearch und OpenSearch verteilt die Indexe und alle zugewiesenen Replikate automatisch auf die der Domain zugeteilten Instances.

Amazon OpenSearch Service unterstützt drei Optionen für die Dateneinspeisung:

• Für große Daten-Volumes empfehlen wir Amazon Kinesis Data Firehose, einen vollständig verwalteten Service, der automatisch skaliert, um dem Durchsatz Ihrer Daten gerecht zu werden, und keine laufende Verwaltung erfordert. Er kann die Daten zudem vor dem Laden umwandeln, in Stapel zusammenfassen und komprimieren.
• Amazon OpenSearch Service unterstützt die Kombination mit Logstash. Sie können Ihre Amazon-OpenSearch-Service-Domain als Datenspeicher für alle neu erstellten Protokolle aus Ihrer Logstash-Bereitstellung konfigurieren.
• Sie können native Elasticsearch (bis Version 7.10)- und OpenSearch-APIs wie den Index und Massen-APIs verwenden, um Daten in Ihre Domain zu laden.

Ja. Amazon OpenSearch Service unterstützt die Kombination mit Logstash. Sie können Ihre Amazon-OpenSearch-Service-Domain als Backend-Speicher für alle Protokolle einrichten, die über Ihre Logstash-Implementierung eingehen. Sie können die Zugriffskontrolle für Ihre Amazon-OpenSearch-Service-Domain so einrichten, dass entweder eine Signierung zum Authentifizieren von Aufrufen aus Ihrer Logstash-Implementierung verlangt wird oder dass ressourcenbasierte IAM-Richtlinien verwendet werden, um IP-Adressen der Instances einzubeziehen, die Ihre Logstash-Implementierung ausführen.

Ja. Amazon OpenSearch Service bietet Visualisierungsfunktionen, die von OpenSearch Dashboards und Kibana (Versionen 1.5 bis 7.10) unterstützt werden.

Sie können zwischen lokaler Speicherung in einer einzelnen Instance oder in EBS-Volumes wählen. Während der Erstellung einer Domain können Sie die Größe des Speicher-Volumes nach Bedarf erweitern oder verkleinern, sofern Sie EBS-Speicher wählen.

Sie können zwischen den folgenden Volumes wählen: Magnetdatenträger-, Standard- und bereitgestellte IOPS-EBS-Volumes.

Ja. Amazon OpenSearch Service stellt Speicher basierend auf der Wahl der Instance und/oder der Größe des zugeordneten EBS-Volumes bereit. Der maximale Speicherplatz pro Knoten beträgt 24 TB bei R6g.12xlarge-Instances mit EBS-gp3-Speicher. Mit einem standardmäßigen Maximum von 80 erlaubten Datenknoten pro Amazon-OpenSearch-Service-Domain können Sie einer einzelnen Domain ungefähr 1 920 TB Speicher zuweisen. Sie können eine Erhöhung des Service-Limits auf bis zu 200 Instances pro Domain anfordern, indem Sie einen Fall im AWS Support Center erstellen. Mit 200 Instances können Sie einer einzelnen Domain ungefähr 3 PB Speicher zuweisen.

Wenn Sie Ihre Daten-Instances in einer einzelnen AZ bereitstellen, werden Ihre dedizierten Master-Instances ebenfalls in dieser AZ bereitgestellt. Wenn Sie Ihre Master-Instances jedoch auf zwei oder drei AZs bereitstellen, verteilt Amazon OpenSearch Service die dedizierten Master-Instances automatisch auf drei AZs. Es gilt eine Ausnahme von dieser Regel, und zwar dann, wenn eine Region nur zwei AZs aufweist oder wenn Sie einen Instance-Typ einer älteren Generation für die Master-Instances auswählen, der nicht in allen AZs verfügbar ist. Weitere Details finden Sie in der Dokumentation.

Bei Produktions-Workloads empfehlen wir die Bereitstellung Ihrer Dateninstanzen auf drei AZs, da diese eine bessere Verfügbarkeit bieten. Außerdem empfehlen wir für eine gleichmäßige Verteilung auf AZs, Instances mit einem Vielfachen von drei bereitzustellen. In Regionen, in denen drei AZs nicht verfügbar sind, empfehlen wir, zwei AZ-Bereitstellungen mit einer geraden Anzahl an Daten-Instances zu wählen. In allen Fällen empfehlen wir die Bereitstellung von drei dedizierten Master-Instances.

Sie können über die AWS-Konsole, die Befehlszeilenschnittstelle (CLI) oder über SDKs Bereitstellungen mit drei AZs für vorhandene und neue Domains aktivieren. Weitere Details finden Sie in der Dokumentation.

Nein. Amazon OpenSearch Service verlangt keine Gebühren für das Aktivieren von Bereitstellungen mit drei AZs. Sie zahlen nur für die Anzahl der Instances in Ihrer Domain, nicht aber für die Anzahl der AZs, für die sie bereitgestellt werden.

Auf allen Domains, die für mehrere AZs konfiguriert wurden, ist das Zonenbewusstsein aktiviert, um damit sicherzustellen, dass die Shards auf alle Availability Zones verteilt werden. In der Konsole können Sie nun explizit Bereitstellungen mit zwei oder drei AZs auswählen. Domains, die bisher mit „Zonenbewusstsein“ konfiguriert waren, können auch weiterhin auf zwei AZs bereitgestellt werden, wenn die Konfiguration unverändert bleibt. Weitere Details finden Sie in der Dokumentation.

Wenn eine oder mehrere Instances in einer AZ nicht erreichbar sind oder nicht funktionieren, versucht Amazon OpenSearch Service automatisch, neue Instances in derselben AZ zu aktivieren, um die betroffenen Instances zu ersetzen. In den seltenen Fällen, in denen neue Instances nicht in der AZ aktiviert werden können, aktiviert Amazon OpenSearch Service neue Instances in den anderen verfügbaren AZs, wenn die Domain so konfiguriert wurde, dass Instances auf mehreren AZs bereitgestellt werden können. Sobald das Problem mit der AZ gelöst ist, führt Amazon OpenSearch Service einen Neuausgleich der Instances aus, sodass sie gleichmäßig auf die für die Domain konfigurierten AZs verteilt werden. Weitere Details finden Sie in der Dokumentation.

Selbst wenn Sie ein Replica konfigurieren, empfehlen wir drei AZs. Bei einer AZ-Unterbrechung in einer Domain mit drei AZs verlieren Sie nur ein Drittel Ihrer Kapazität, wenn die Unterbrechung jedoch in einer Domain mit zwei AZs auftritt, verlieren Sie die Hälfte Ihrer Kapazität. Eine solche Situation kann zu einer spürbareren Unterbrechung führen. Wenn bei einer Domain mit drei AZs eine AZ unterbrochen ist, kann Amazon OpenSearch Service auf die verbleibenden zwei AZs zurückgreifen und nach wie vor eine Replikation über AZs hinweg unterstützen. Bei einer Domain mit zwei AZs verlieren Sie die AZ-übergreifende Replikation, wenn eine AZ unterbrochen ist. Dies kann eine weitere Reduzierung der Verfügbarkeit zur Folge haben. Weitere Details finden Sie in der Dokumentation.

Die Anzahl der AZs, in denen Ihre Domain bereitgestellt wird, entspricht der Anzahl der Subnetze, die Sie für Ihre VPC-Domain konfiguriert haben. Sie müssen mindestens drei Subnetze in Ihrer VPC-Domain konfigurieren, um eine Bereitstellung mit drei AZs zu aktivieren. Weitere Details zur Konfiguration von VPC finden Sie in unserer Dokumentation.

Ja. Die Programme mit öffentlichem Internetzugriff können über einen öffentlichen Endpunkt auf Amazon-OpenSearch-Service-Domains zugreifen. Wenn Ihr Rechenzentrum bereits über Direct Connect oder SSH-Tunneling mit Amazon VPC verbunden ist, können Sie auch VPC-Zugriff nutzen. In beiden Fällen können Sie IAM-Richtlinien und Sicherheitsgruppen konfigurieren, damit Programme auf Servern außerhalb von AWS auf Ihre Amazon-OpenSearch-Service-Domains zugreifen können. Klicken Sie hier, um weitere Informationen zu signierten Anforderungen zu erhalten.

Um Daten von einem bestehenden Elasticsearch- oder OpenSearch-Cluster zu migrieren, sollten Sie einen Snapshot eines bestehenden Clusters erstellen und ihn in Ihrem Amazon-S3-Bucket speichern. Anschließend können Sie eine neue Amazon-OpenSearch-Service-Domain erstellen und Daten aus dem Snapshot in die neu erstellte Amazon-OpenSearch-Service-Domain mithilfe der Wiederherstellungs-API laden.

Amazon OpenSearch Service ermöglicht Ihnen, die Skalierung Ihrer Amazon-OpenSearch-Service-Domain über Konsole, API und CLI zu kontrollieren. Sie können Ihre Amazon-OpenSearch-Service-Domain skalieren, indem Sie je nach Anwendungsanforderungen Instances oder Speicher-Volumes hinzufügen, entfernen oder ändern. Amazon OpenSearch Service ist mit Amazon CloudWatch kombiniert, um Metriken über den Status Ihrer Amazon-OpenSearch-Service-Domain zur Verfügung zu stellen, die Sie in die Lage versetzen, geeignete Skalierungsentscheidungen für Ihre Domains zu treffen.

Nein. Die Skalierung Ihrer Amazon-OpenSearch-Service-Domain durch Hinzufügen oder Ändern von Instances und Speicher-Volumes wird online durchgeführt und verursacht keine Ausfallzeiten.

Ja. Wenn Sie Replicas für Ihre OpenSearch/Elasticsearch-Indizes aktivieren und mehrere Availability Zones verwenden, verteilt Amazon OpenSearch Service die primären und Replica-Shards automatisch auf Instances in verschiedenen AZs.

Ja. Amazon OpenSearch Service liefert über Amazon CloudWatch verschiedene Leistungsmetriken. Dazu gehören die Anzahl der Knoten, Status des Clusters, durchsuchbare Dokumente, EBS-Metriken (falls zutreffend) sowie CPU-, Arbeitsspeicher und Datenträgernutzung für Daten und Master-Knoten. In der Servicedokumentation finden Sie eine vollständige Liste der verfügbaren CloudWatch-Metriken.

Ja. AWS CloudTrail ist ein Web-Service, der Aufrufe von AWS-APIs für Ihr Konto aufzeichnet und Protokolldateien an Sie übermittelt. Der AWS-API-Aufrufverlauf, der von AWS CloudTrail generiert wird, ermöglicht Sicherheitsanalysen, Nachverfolgung von Ressourcenänderungen und Compliance-Überwachung. Weitere Informationen zu AWS CloudTrail finden Sie auf der Detailseite zu AWS CloudTrail. Auf der CloudTrail-Startseite in der AWS-Managementkonsole können Sie CloudTrail aktivieren.

Ein Snapshot ist eine Kopie Ihrer Amazon-OpenSearch-Service-Domain zu einer bestimmten Zeit.

Das Erstellen von Snapshots kann bei durch einen Knotenausfall verursachten Datenverlusten sowie im unwahrscheinlichen Fall eines Hardwareausfalls nützlich sein. Sie können Snapshots verwenden, um Ihre Amazon-OpenSearch-Service-Domain mit vorgeladenen Daten wiederherzustellen oder um eine neue Amazon-OpenSearch-Service-Domain mit vorgeladenen Daten zu erstellen. Sicherungen werden außerdem für Archivierungszwecke verwendet. Die Snapshots werden in Amazon S3 aufbewahrt.

Ja. Amazon OpenSearch Service erstellt standardmäßig von jeder Amazon-OpenSearch-Service-Domain automatisch tägliche Snapshots und speichert sie 14 Tage lang.

Amazon OpenSearch Service bewahrt die automatischen stündlichen Snapshots der letzten 14 Tage auf.

Für die automatischen täglichen Snapshots entstehen keine zusätzlichen Kosten. Die Snapshots werden kostenlos in einem Amazon OpenSearch Service S3-Bucket gespeichert und für Knotenwiederherstellungen zur Verfügung gestellt.

Ja. Sie können die Snapshot-API verwenden, um manuelle Snapshots zusätzlich zu den automatischen täglichen Snapshots von Amazon OpenSearch Service zu erstellen. Die manuellen Snapshots werden in Ihrem S3-Bucket gespeichert, wofür die normalen nutzungsabhängigen Amazon S3-Gebühren berechnet werden.

Ja. Die Kunden können eine neue Amazon-OpenSearch-Service-Domain erstellen und mit der OpenSearch/Elasticsearch-API für Wiederherstellungen Daten aus dem Snapshot in die neu erstellte Amazon-OpenSearch-Service-Domain laden.

Mit der Domain werden auch die Snapshots gelöscht, die von Amazon OpenSearch Service aufbewahrt wurden. Bevor Sie eine Domain löschen, sollten Sie in Betracht ziehen, mithilfe des manuellen Snapshot-Verfahrens einen Snapshot der Domain anzufertigen und in Ihren eigenen S3-Buckets zu speichern. Die in Ihrem eigenen S3-Bucket gespeicherten Snapshots werden nicht gelöscht, wenn Sie Ihre Amazon-OpenSearch-Service-Domain löschen.

Amazon OpenSearch Service zeigt drei Elasticsearch- oder OpenSearch-Protokolle über Amazon CloudWatch Logs an: Fehlerprotokolle, Slow-Suchprotokolle und Slow-Indizierungsprotokolle. Diese Protokolle sind hilfreich, um Leistungs- und Stabilitätsprobleme mit der Domain zu beheben.

Slow-Protokolle sind Protokolldateien, die Ihnen dabei helfen, die Leistungsfähigkeit verschiedener Stufen eines Vorgangs zu verfolgen. OpenSearch kann zwei Arten von Slow-Protokollen anzeigen:

• Slow-Indizierungsprotokolle: Diese Protokolle bieten Einblicke in den Indizierungsvorgang und können dabei helfen, die Indizierungseinrichtung genauer einzustellen.
• Slow-Suchprotokolle: Diese Protokolle bieten Einblicke, wie schnell oder langsam Anfragen und Abrufe erfolgen. Mit diesen Protokollen können Sie die Leistung jeder Art von Suchvorgang auf OpenSearch genau anpassen.

Die kompletten Details zu den Slow-Protokollen finden Sie in der OpenSearch-Dokumentation.

Sie können Slow-Protokolle mit einem Klick über die Konsole oder über unser CLI und unsere APIs aktivieren. Weitere Details finden Sie in unserer Dokumentation.

Ja. Sie können die Einstellungen eines bestimmten Index anpassen, um Slow-Protokolle dafür zu aktivieren oder zu deaktivieren. Weitere Details finden Sie in unserer Dokumentation.

Nein. Wenn Sie Slow-Protokolle in Amazon OpenSearch Service aktivieren, können Sie die generierten Protokolle auf Amazon CloudWatch Logs für die Indizes in der angegebenen Domain veröffentlichen. Um die Protokolle zu generieren, müssen Sie aber zuerst die Einstellungen für einen oder mehrere Indizes anpassen, damit der Protokollierungsvorgang gestartet wird. Weitere Details zum Einstellen der Indexkonfiguration, um Slow-Protokolle zu aktivieren, finden Sie in unserer Dokumentation.

Nein. Die Generierung der Protokolldateien hängt von den Indexeinstellungen ab. Um die Generierung von Protokolldateien zu deaktivieren, müssen Sie die Indexkonfiguration anpassen. Weitere Details zum Einstellen der Indexkonfiguration, um Slow-Protokolle zu aktivieren, finden Sie in unserer Dokumentation.

Es kann nur die Genauigkeit der Protokollierung für Slow-Protokolle geändert werden. OpenSearch zeigt mehrere Protokollierungsstufen für Slow-Protokolle an. Sie müssen die entsprechende Stufe in der jeweiligen Indexkonfiguration festlegen. Weitere Details zum Einstellen der Indexkonfiguration, um Slow-Protokolle zu aktivieren, finden Sie in der OpenSearch-Dokumentation.

Wenn Sie Slow-Protokolle oder Fehlerprotokolle aktivieren, veröffentlicht Amazon OpenSearch Service die generierten Protokolle auf Amazon CloudWatch Logs. Amazon OpenSearch Service verlangt keine Gebühren für das Aktivieren der Protokolle. Es werden jedoch die üblichen CloudWatch-Gebühren fällig.

OpenSearch verwendet Apache Log4j 2 und die integrierten Protokollstufen (von am wenigsten schwerwiegend bis am schwerwiegendsten) TRACE, DEBUG, INFO, WARN, ERROR und FATAL. Wenn Sie die Fehlerprotokolle aktivieren, veröffentlicht Amazon OpenSearch Service Protokollzeilen für WARN, ERROR und FATAL sowie bestimmte Fehler aus der DEBUG-Ebene in CloudWatch. Weitere Details finden Sie in der Dokumentation.

Sie können Fehlerprotokolle mit einem Klick über die AWS-Konsole oder über unser CLI und unsere APIs aktivieren. Weitere Details finden Sie in unserer Dokumentation.

Nein, Fehlerprotokolle werden für die gesamte Domain angezeigt. Dies bedeutet, dass nach der Aktivierung Fehlerprotokolle aus allen Indizes in der Domain verfügbar sind.

Nein, Fehlerprotokolle sind nur für die Elasticsearch-Versionen 5.x und höher verfügbar.

Ja. Jeder Protokolleintrag auf CloudWatch umfasst maximal 255 000 Zeichen. Wenn Ihr Protokolleintrag größer ist, wird er nach 255 000 Zeichen abgeschnitten.

Slow-Protokolle sind nur dann erforderlich, wenn Sie Ihre Indizes auf Fehler prüfen oder ihre Leistungsfähigkeit anpassen möchten. Wir empfehlen Ihnen, dass Sie Slow-Protokolle nur für die Indizes aktivieren, von denen Sie weitere Leistungsdaten einsehen möchten. Sobald Sie diese Informationen erhalten haben, sollten Sie die Slow-Protokolle wieder deaktivieren, um keine unnötigen Kosten zu verursachen. Weitere Details finden Sie in unserer Dokumentation.

CloudWatch bietet hierzu verschiedene Möglichkeiten. Sie können die Protokolldaten einsehen, sie nach S3 exportieren oder sie in Echtzeit verarbeiten. Weitere Informationen dazu finden Sie im CloudWatch-Logs-Enticklerleitfaden.

Ja. Slow-Protokolle können bei allen von Amazon OpenSearch Service unterstützten OpenSearch und Elasticsearch-Versionen aktiviert werden. Es gibt jedoch bei jeder Elasticsearch-Version geringfügige Unterschiede bei der Einstellung von Protokolleinstellungen. Weitere Details finden Sie in unserer Dokumentation.

Nein. Es gibt keine Ausfallzeiten. Jedes Mal, wenn der Protokollstatus aktualisiert wird, stellen wir im Hintergrund einen neuen Cluster bereit und ersetzen den vorhandenen Cluster mit dem neuen. Dieser Vorgang führt nicht zu Ausfallzeiten. Da jedoch ein neuer Cluster bereitgestellt wird, geschieht die Aktualisierung des Protokollstatus nicht unverzüglich.

Amazon OpenSearch Service unterstützt derzeit das vorhandene Versionsupgrade für Domains mit OpenSearch-Version oder Elasticsearch ab Version 5.x. Wir unterstützen die folgenden Zielversionen für das Upgrade: 5.6, 6.3, 6.4, 6.5, 6.7, 6.8, 7.1, 7.4, 7.7, 7.8, 7.9 und 7.10. Weitere Details finden Sie in der Dokumentation.

Weitere Details zur Migration von verschiedenen Elasticsearch-Versionen finden Sie in unserer Dokumentation.

Nein. Während des Upgrades bleibt Ihre Domain weiterhin verfügbar. Während das Upgrade durchgeführt wird, müssen jedoch Shards neu zugewiesen werden, wodurch die Leistung der Domain beeinträchtigt wird. Wir raten Ihnen, das Upgrade durchzuführen, wenn die Belastung Ihrer Domain niedrig ist.

Das vorhandene Versionsupgrade ist nur für Domain verfügbar, auf denen Elasticsearch 5.x oder höher ausgeführt wird. Wird auf Ihrer Domain Version 5.x oder höher ausgeführt, führen Sie die Berechtigungsprüfung aus, um festzustellen, ob Ihre Domain auf die gewünschte Version upgegradet werden kann. Weitere Informationen finden Sie in unserer Dokumentation.

Eine Liste der Überprüfungen, die wir zur Bestätigung der Upgradeberechtigung durchführen, finden Sie in unserer Dokumentation.

Nein. Sobald das vorhandene Versionsupgrade gestartet wurde, können Sie keine Änderungen an der Konfiguration Ihrer Domain vornehmen, bis das Upgrade abgeschlossen ist oder durch einen Fehler unterbrochen wird. Sie können weiterhin Daten lesen und schreiben, während das Upgrade durchgeführt wird. Außerdem können Sie die Domain löschen. Das Upgrade wird in diesem Fall beendet und die Domain wird gelöscht.

Während des Prozesses des Versionsupgrades wird automatisch ein Snapshot des Systems aufgenommen. Das eigentliche Upgrade wird nur nach erfolgreichem Erstellen des Snapshots durchgeführt. Wird das Upgrade zur Startzeit des automatischen Snapshots ausgeführt, wird das Erstellen des automatischen Snapshots auf den nächsten Tag verschoben.

Amazon OpenSearch Service führt vor dem Ausführen des Upgrades eine Reihe von Überprüfungen durch, um nach bekannten Problemen zu suchen, die das Upgrade möglicherweise blockieren. Werden keine Probleme gefunden, nimmt der Service einen Snapshot der Domain auf und startet das Upgrade nach erfolgreicher Aufnahme des Snapshots. Treten bei einem dieser Schritte Probleme auf, wird das Upgrade nicht gestartet.

Sind die aufgetretenen Probleme gering und lösbar, versucht Amazon OpenSearch Service automatisch, sie zu beheben und das Upgrade freizugeben. Wird das Upgrade jedoch von einem Problem blockiert, kehrt der Service zum vorher aufgenommenen Snapshot zurück und protokolliert den Fehler. Weitere Details zum Ansehen der Protokolle des Upgradefortschritts finden Sie in unserer Dokumentation.

Ja. Sie können die Upgradeprotokolle von der AWS-Konsole aus einsehen oder sie mithilfe von CLI oder SDKs anfordern. Weitere Details finden Sie in unserer Dokumentation.

Nein. Nachdem das Upgrade gestartet wurde, ist ein Anhalten oder Abbrechen nicht möglich bis das Upgrade entweder abgeschlossen ist, oder durch einen Fehler beendet wird.

Ja. Wenn Sie jedoch auf all Ihren Domain die gleiche Version ausführen möchten, empfehlen wir, die Berechtigungsüberprüfung auf allen Domains auszuführen, bevor Sie das Upgrade durchführen. Dieser Schritt hilft dabei, Probleme bei einer Domain aufzudecken, die bei einer anderen möglicherweise nicht auftreten.

Anhängig von der Menge der Daten und der Größe des Clusters nimmt das Durchführen des Upgrades mehrere Minuten bis hin zu mehreren Stunden in Anspruch.

Nein. Beim Versionsupgrade werden alle Daten in Ihrem Cluster als Teil des Upgradevorgangs wiederhergestellt. Möchten Sie nur die Domain allein upgraden, nehmen Sie einen Snapshot Ihrer Daten auf, löschen all Ihre Indizes aus der Domain und starten anschließend das vorhandene Versionsupgrade. Alternativ erstellen Sie eine separate Domain mit der neueren Version und stellen dann Ihre Daten in dieser Domain wieder her.

Nein. Wenn Sie eine Zurückstufung auf eine ältere Version benötigen, wenden Sie sich an den AWS Support, um den automatischen Snapshot vor dem Upgrade in einer neuen Domain wiederherzustellen. Wenn Sie einen manuellen Snapshot der ursprünglichen Domain erstellt haben, können Sie diesen Schritt selbst durchführen.

Multi-AZ mit Standby ist eine neue Bereitstellungsoption für Amazon OpenSearch Service, die eine hohe Verfügbarkeit und konsistente Leistung für geschäftskritische Workloads ermöglicht. Mit Multi-AZ mit Standby sind die von OpenSearch Service verwalteten Cluster widerstandsfähig gegenüber Infrastrukturausfällen wie Knotenausfällen oder einem Ausfall einer einzelnen Availability Zone, sodass eine Beeinträchtigung der Leistung oder Verfügbarkeit ausgeschlossen ist, selbst wenn eine einzelne Availability Zone ausfällt. Multi-AZ mit Standby bietet den zusätzlichen Vorteil, dass die Clusterkonfiguration und -verwaltung vereinfacht werden, indem bewährte Methoden durchgesetzt und die Komplexität reduziert werden.

Um Multi-AZ mit Standby zu aktivieren, müssen verwaltete Cluster die folgenden Bedingungen erfüllen:

• OpenSearch 1.3 oder eine neuere Version ausführen.
• In AWS-Regionen mit 3-AZ bereitstellen. Derzeit unterstützt die AWS-Region Nordkalifornien 3-AZ nicht und ist daher nicht für Multi-AZ mit Standby geeignet.
• Die Anzahl der Datenknoten muss ein Vielfaches von drei sein.
• Die Anzahl der Datenkopien (primär + Replikat) sollte ein Vielfaches von drei sein.
• Beachten Sie die Größenrichtlinien für den Leader (empfohlene Größe basiert auf der Anzahl der Knoten, der Anzahl der Shards und der Anzahl der Zuordnungen in Ihrem Cluster).

Mit Multi-AZ mit Standby erkennt Amazon OpenSearch Service einige der Infrastrukturausfälle und stellt diese automatisch wieder her. Amazon OpenSearch Service führt in weniger als einer Minute automatisch ein Failover von aktiven Knoten zu Standby-Knoten durch, wenn eines der folgenden Ereignisse eintritt:

• Verlust einer aktiven AZ oder aller Knoten in einer aktiven AZ
• Verlust der Konnektivität zu einer aktiven AZ
• Instance-Hardwarefehler in der aktiven AZ
• Speicherausfall auf einem Knoten in der aktiven AZ

Derzeit deckt Multi-AZ mit Standby die folgenden Ereignisse nicht ab:

• Verlust des Master-Quorums, da die Wiederherstellung nach diesem Ereignis mehrere Minuten dauern kann
• Verlust von mehreren Availability Zones
• Verlust der Konnektivität zu einer Region
• Verlust von mehr als 50 % der Knoten in mehr als einer AZ
• Ausfallzeiten aufgrund unzureichender Rechen- oder Speicherkapazität als Folge von Änderungen der Workload-Eigenschaften
• Ausfallzeiten aufgrund von bösartigen Abfragen
• Verlust eines oder mehrerer Services, von denen Amazon OpenSearch Service abhängig ist, wie ARPS und ALB
• Ausfallzeiten des OpenSearch-Dashboards während Versionsupgrades

Nein. Im Prinzip bleiben die Größenrichtlinien dieselben. Multi-AZ mit Standby verfügt über Voraussetzungen, die das mentale Modell vereinfachen, das für die Größe des Clusters erforderlich ist. Bei der Dimensionierung eines verwalteten Clusters sollten Sie von der Kapazität ausgehen, die für die Verwaltung Ihres Workloads erforderlich ist, und dann 50 % hinzufügen, um die Redundanz zu gewährleisten. Der Hauptunterschied zwischen der aktuellen Option für Zonenbewusstsein und Multi-AZ mit Standby besteht darin, wie mit redundanter oder zusätzlicher Kapazität umgegangen wird, um die Verfügbarkeit aufrechtzuerhalten. Multi-AZ mit Standby erfordert, dass Sie mindestens eine Kopie der Daten in jeder AZ haben, sodass Multi-AZ mit Standby ausdrücklich Kapazität in einer AZ als Standby reservieren kann. Diese Standby-Kapazität dient als Failover-Ziel bei einer AZ-Unterbrechung oder einem Instance-Ausfall. Das bestehende Modell erfordert, dass Sie über ein optimales Maß an Ressourcen verfügen, um Ihre Workload zu bewältigen. Sie würden Ihren Cluster weiterhin auf Größenprobleme überwachen und Korrekturmaßnahmen ergreifen, wenn sich die Workload-Eigenschaften ändern.

Nein. Amazon OpenSearch Service arbeitet nach einem Modell der geteilten Verantwortung. Sie sind dafür verantwortlich, dass Ihr Cluster entsprechend Ihrer Workload dimensioniert ist. Multi-AZ mit Standby macht das mentale Modell für die Einrichtung Ihres Clusters einfach. Sie sollten die Fehler- und Latenzmetriken sowie die Speicher-, CPU- und RAM-Auslastung weiterhin auf Signale überwachen, die darauf hinweisen, dass der Cluster überlastet ist und möglicherweise skaliert werden muss.

Nein. Das Feature „Multi-AZ mit Standby“ ist ohne zusätzliche Kosten verfügbar. Sie zahlen weiterhin für die Ressourcen, die im Cluster bereitgestellt werden, um Ihren Workload zu bewältigen. Wenn Ihr Cluster bereits die bewährten Methoden befolgt und über mindestens drei Datenkopien für einen 3-AZ-Cluster verfügt, ist es unwahrscheinlich, dass Ihnen bei der Umstellung auf Multi-AZ mit Standby zusätzliche Kosten entstehen. Wenn Ihr Cluster jedoch zu klein ist oder nicht über genügend redundante Kapazität verfügt, um Ihren Workload zu bewältigen, müssen Sie Kapazität hinzufügen, um auf Multi-AZ mit Standby umzustellen und die Verfügbarkeit und Leistung zu verbessern. Die Standby-Kapazität wird aus der konfigurierten Gesamtkapazität reserviert.

Die SLA für unseren Amazon OpenSearch Service garantiert einen monatlichen Uptime-Prozentsatz von mindestens 99,9 % für Amazon OpenSearch Service.

Sie haben Anspruch auf eine SLA-Gutschrift für Amazon OpenSearch Service im Rahmen der SLA für Amazon OpenSearch Service, wenn eine Domain mit mehreren AZs auf Amazon OpenSearch Service während eines monatlichen Abrechnungszyklus einen monatlichen Uptime-Prozentsatz von weniger als 99,9 % aufweist.

Ausführliche Informationen zu allen Bestimmungen der SLA sowie Einzelheiten zur Geltendmachung eines Anspruchs finden Sie auf der Seite zur SLA für Amazon OpenSearch Service.

Die Cluster-übergreifende Suche ist ein Elasticsearch- und OpenSearch-Feature, mit dem die Durchführung von Abfragen und Aggregationen über zwei verbundene Cluster ermöglicht wird. Sie funktioniert, indem es eine leichtgewichtige unidirektionale Verbindung zwischen teilnehmenden Clustern herstellt.

Domains, die an der Cluster-übergreifenden Suche teilnehmen, müssen die folgenden Kriterien erfüllen:

• Teilnehmende Domains sollten OpenSearch oder Elasticsearch Version 6.8 und höher unterstützen.
• Für teilnehmende Domains muss die Verschlüsselung bei der Übertragung aktiviert sein.
• Für teilnehmende Domains muss die differenzierte Zugriffskontrolle (Fine Grained Access Control, FGAC) aktiviert sein.
• Für die Versionen von teilnehmenden Domains sollten die selben Grundsätze gelten wie für rollierende Versions-Upgrades.

Die Cluster-übergreifende Suche wird derzeit auf den folgenden Instance-Typen unterstützt

• i2-, i3-Familie
• r3-, r4-, r5-Familie
• m4-, m5-Familie
• c4-, c5-Familie
• Graviton-Familie

Die Cluster-übergreifende Suche wird aufgrund von technischen Einschränkungen nicht auf Instances der t2- und m3-Familien unterstützt.

Ja. Teilnehmende Domains können zwei unterschiedlichen AWS-Konten angehören.

Ja.

Um mit der Cluster-übergreifenden Suche zu beginnen, folgen Sie der Dokumentation hier.

Cluster-übergreifende Replikation ist eine neue Funktion, die es Amazon-OpenSearch-Service-Kunden ermöglicht, das Kopieren und Synchronisieren von Indexen von einem Cluster zu einem anderen mit geringer Latenz in derselben oder in verschiedenen AWS-Regionen zu automatisieren.

Domains, die an der Cluster-übergreifenden Replikation teilnehmen, müssen die folgenden Kriterien erfüllen:

• Teilnehmende Domains sollten Elasticsearch Version 7.10 unterstützen.
• Für teilnehmende Domains muss die Verschlüsselung bei der Übertragung aktiviert sein.
• Für teilnehmende Domains muss die differenzierte Zugriffskontrolle (Fine Grained Access Control, FGAC) aktiviert sein.
• Für die Versionen von teilnehmenden Domains sollten die selben Grundsätze gelten wie für rollierende Versions-Upgrades.

Ja. Domains in zwei verschiedenen AWS-Regionen können an der Cluster-übergreifenden Replikation teilnehmen.

Nein. Die aktuelle Implementierung der Cluster-übergreifenden Replikation unterstützt weder Ultrawarm noch Cold Storage.

Ja. Sie zahlen standardmäßige AWS-Datenübertragungsgebühren für Daten, die in und aus Amazon OpenSearch Service übertragen werden.

Am 12. April 2021 kündigten wir das OpenSearch-Projekt an, ein von der Community betriebenes Open-Source-Fork von Elasticsearch und Kibana. Wir haben uns zu einer langfristigen Investition in OpenSearch entschlossen, um sicherzustellen, dass den Nutzern auch weiterhin eine sichere, qualitativ hochwertige und vollständig quelloffene Such- und Analyse-Suite mit einer umfangreichen Roadmap mit neuen und innovativen Funktionen zur Verfügung steht. Dieses Projekt umfasst OpenSearch (abgeleitet von Elasticsearch 7.10.2) und OpenSearch-Dashboards (abgeleitet von Kibana 7.10.2). Wir haben Version 1.0 von OpenSearch am 12. Juli 2021 veröffentlicht. Als Teil unseres langfristigen Engagements für OpenSearch haben wir am 7. September 2021 Unterstützung für OpenSearch 1.0 in den verwalteten Service aufgenommen und den Namen von Amazon Elasticsearch Service in Amazon OpenSearch Service geändert. Zusammen mit OpenSearch 1.0 unterstützen wir weiterhin ältere Elasticsearch-Versionen bis 7.10 auf dem Service. Abgesehen von der Namensänderung können Sie sicher sein, dass wir Ihnen auch weiterhin dieselbe großartige Erfahrung bieten werden, ohne dass dies Auswirkungen auf den laufenden Betrieb, die Entwicklungsmethodik oder die geschäftliche Nutzung hat. Mehr über OpenSearch erfahren Sie hier: https://opensearch.org.

Wir haben uns bemüht, diese Namensänderung für Sie so nahtlos wie möglich zu gestalten. Es gibt Aspekte, wie z. B. die neuen SDK-/Konfigurations-APIs, die Ihr Handeln erfordern, um sicherzustellen, dass Sie die Vorteile des Services optimal ausschöpfen können. Während das bestehende SDK aus Kompatibilitätsgründen weiterhin funktioniert, werden alle neuen Funktionen, die neue Konfigurations-APIs erfordern, nur im neuen SDK bereitgestellt. Wir empfehlen Ihnen daher, auf das neue SDK umzusteigen. Unabhängig vom neuen SDK empfehlen wir Ihnen außerdem dringend, Ihre bestehenden IAM-Richtlinien auf die umbenannten Konfigurations-APIs umzustellen. Ab sofort funktionieren Ihre bestehenden IAM-Richtlinien weiterhin mit der alten API-Definition. Wir werden jedoch auf die neue API-basierte Berechtigungsvalidierung umstellen und von Ihnen verlangen, dass Sie die neuen APIs in Ihren Richtlinien verwenden (insbesondere für die APIs, deren Name sich geändert hat, z. B. CreateElasticsearchDomain in CreateDomain). Weitere Einzelheiten finden Sie in unserer Dokumentation.

Nein. Aus Sicht der Abwärtskompatibilität stellen wir sicher, dass Ihre bestehende Einrichtung weiterhin mit OpenSearch 1.0 funktioniert. Wir empfehlen Ihnen jedoch, wie oben erwähnt, auf das neueste SDK umzusteigen, um eine sauberere und aktuellere Anwendung zu erhalten.

Nein. Es gibt keine Änderungen der Preise.

OpenSearch enthält bestimmte von Apache lizenzierten Elasticsearch-Codes von Elasticsearch B.V. und anderen Quellcodes. Elasticsearch B.V. ist nicht die Quelle dieses anderen Quellcodes. ELASTICSEARCH ist eine eingetragene Marke von Elasticsearch B.V.

Ein Upgrade auf OpenSearch 1.x stellt sicher, dass Ihre Suchinfrastruktur auf einem wachsenden und dynamischen Apache-lizenzierten Open-Source-Projekt aufbaut, und gibt Ihnen Zugang zu einer Fülle innovativer Verbesserungen und Features, die in OpenSearch 1.2 (zum Zeitpunkt dieses Schreibens) verfügbar sind.  Features wie Sicherheit auf Unternehmensebene, Warnmeldungen, Datenlebenszyklusmanagement, Beobachtbarkeit, ML-basierte Anomalieerkennung und vieles mehr sind alle Teil von OpenSearch Service, ohne dass zusätzliche Lizenzgebühren anfallen.

Bei der Aktualisierung verwenden wir einen blau/grünen (BG) Bereitstellungsprozess. Während einer BG fügt der Dienst dem OpenSearch-Service-Cluster Knoten in der neuen Konfiguration und Version hinzu, migriert Daten von den alten Knoten und entfernt die alten Knoten, wenn die Datenmigration abgeschlossen ist. Während einer BG sind die Such- und Indizierungs-APIs verfügbar und funktionieren normal. Obwohl BG so konzipiert ist, dass Abfrage- und Indizierungsanfragen nicht beeinträchtigt werden, können einige Änderungen (insbesondere solche, die Änderungen an sicherheitsrelevanten Einstellungen beinhalten) dazu führen, dass Dashboards während des Änderungszeitraums nicht verfügbar sind.

OpenSearch unterstützt mehrere Versionen von Elasticsearch und OpenSearch, für einige davon wurde bereits das Ende des Standard- und des erweiterten Supports angekündigt. Eine vollständige Liste der Engine-Versionen und der entsprechenden Support-Daten finden Sie in der Dokumentation. Weitere Informationen zum erweiterten Support finden Sie unter Erweiterter Support.

AWS verwaltet 19 Versionen der Apache-2.0-lizenzierten Elasticsearch. Keine dieser Versionen ist zur Zeit veraltet oder zur Abschaffung vorgesehen.

Ja, das Upgrade löst einen BG-Bereitstellungsprozess aus. Bitte lesen Sie hier die Vorbereitungen und Schritte für das Upgrade.

Bitte wenden Sie sich an Ihr AWS-Kundenteam, um Informationen zu Ihrer speziellen Situation mit RIs zu erhalten.

Das OpenSearch-Projekt 1.0 ist eine Abzweigung von Open Source Elasticsearch 7.10.2. Es ist Kabel-kompatibel mit Elasticsearch 7.10 – Sie müssen Ihre Verwendung nicht ändern. Um zu migrieren, können Sie Ihre Domain von einer früheren Version der 6.x- und 7.x-Reihe auf die Version Elasticsearch 7.10 aktualisieren, einen Snapshot erstellen und diesen Snapshot in einer Domain mit OpenSearch Service 1.x wiederherstellen. Einige Clients oder Tools enthalten Versionsprüfungen, die dazu führen können, dass der Client oder das Tool nicht mit OpenSearch Service funktioniert. Aktivieren Sie beim Upgrade den Kompatibilitätsmodus, um diese Versionsprüfungen zu umgehen.

In den meisten Fällen können Sie Ihre bestehenden Kunden weiterverwenden. Die APIs und die wichtigsten Suchfunktionen sind mit Elasticsearch Version 7.10.2 kompatibel. Wenn Sie ältere Clients haben, die Clients Versionsprüfungen durchführen oder die Clients Funktionen nutzen, die auf ältere Versionen von Elasticsearch ausgerichtet sind, wie z.B. die Hauptversionen 5 oder 6, dann empfehlen wir, dass Sie versuchen, Ihre Clients auf einen Mindeststandard der Unterstützung von 7.10.2 zu bringen, um einen reibungslosen Übergang zu gewährleisten.

Das OpenSearch-Projekt unterstützt eine breite Palette von Clients, die speziell für die OpenSearch-Versionen der Suchmaschine auf Amazon OpenSearch Service entwickelt wurden. Überprüfen Sie Ihren Client anhand der Liste der neuesten OpenSearch-Clients und der unterstützten Programmiersprachen für diese Clients.

Sie können den Kompatibilitätsmodus aktivieren, um mit Clients anderer Anbieter zusammenzuarbeiten, aber denken Sie daran, die von OpenSearch gemeldete Version zu überprüfen. Aktivieren Sie diese Einstellung, um sicherzustellen, dass der Dienst mit Version 7.10.2 auf Clients antwortet, die vor der Einführung der OpenSearch-Service-Engine entwickelt wurden.

Elasticsearch-5.x-Indizes sind nicht kompatibel mit Elasticsearch 7.10 oder OpenSearch 1.x. Sie müssen einen neuen Index erstellen und Daten aus Ihrer Quelle laden. Wenn Sie eine Protokollanalyse-Workload ausführen, können Sie prüfen, ob Ihre Datenaufbewahrungsstrategie eine parallele Ausführung unterstützt, während Sie einen vollständigen Datensatz auf der neuen Domain aufbauen.

Ja, bitte wenden Sie sich an opensearchmigration-si-support@amazon.com, um eine Liste von Partnern für Ihre Region, Branche und Projektkomplexität anzufordern. Die Partner des AWS Partner Network (APN) sind geschult und verfügen über die nötige Erfahrung, um Sie bei Upgrades zu unterstützen. 

OpenSearch 1.0 ist eine Abzweigung von Elasticsearch 7.10.2. OpenSearch und Elasticsearch sind kompatibel. Wenn Sie den Kompatibilitätsmodus aktivieren, sind Elasticsearch-Clients auch mit OpenSearch 1.0 kompatibel.

Amazon OpenSearch Service bietet keine Versionen der Elasticsearch-Engine nach Version 7.10.2 an und wird dies auch in Zukunft nicht tun.

Wie AWS bei der Abzweigung von Elasticsearch angekündigt hat, wollten wir eine florierende Community rund um OpenSearch aufbauen und haben dies auch getan. Wir haben eine Roadmap für OpenSearch veröffentlicht, komplett mit Beiträgen der Community und einer Zustimmung über die Prioritäten der Features. Wir werden alle angemessenen Anstrengungen unternehmen, um die Kompatibilität mit Elasticsearch zu erhalten. Unser Ziel ist es, mit unserer Community und den Amazon-OpenSearch-Service-Kunden zu wachsen.

Sie können direkt von den Elasticsearch- und Kibana-Versionen 6.8.0 bis 7.10.2 und der Open Distro für Elasticsearch (ODFE) 1.x auf OpenSearch Service 1.0 aktualisieren. Für rollende Upgrades von ODFE auf OpenSearch empfehlen wir, zuerst auf ODFE 1.13 und dann auf OpenSearch 1.0 zu aktualisieren.

Ressourcen zur Migration finden Sie hier:

Analytik-Migrationen

Migrieren zu Amazon OpenSearch Service

Jede Engine-Version, die im OpenSearch Service eingeführt wird, ist standardmäßig durch den Standard-Support abgedeckt. Im Rahmen des Standard-Supports stellt AWS regelmäßige Fehlerbehebungen und Sicherheitsupdates bereit. Wenn der Standard-Support für eine Version endet, bietet AWS einen erweiterten Supportzeitraum von mindestens 12 Monaten nach dem Enddatum des Standard-Supports an. Während des erweiterten Supportzeitraums stellt AWS kritische Sicherheitskorrekturen und Betriebssystem-Patches bereit. So haben Sie mehr Zeit, um Ihr Upgrade auf eine neuere unterstützte Engine-Version zu planen. Wenn Sie eine Version ausführen, für die der erweiterte Support gilt, wird Ihnen zusätzlich zu den Standardkosten für Instances und Speicherplatz eine Pauschalgebühr/NIH (Normalized Instance Hour) berechnet. Weitere Informationen zum erweiterten Support und zum Zeitplan für verschiedene Versionen finden Sie in der Dokumentation. Informationen zu Preisen finden Sie auf der Preisseite.

Nein. Domains, auf denen Versionen ausgeführt werden, für die der Standard-Support ausgelaufen ist, sind automatisch durch den erweiterten Support abgedeckt und werden entsprechend bepreist. Sobald Sie Ihre Domain auf eine neuere Version unter Standard-Support aktualisieren, wird Ihnen der erweiterte Support nicht mehr in Rechnung gestellt.

Domains, für die der erweiterte Support gilt, wird zusätzlich zu den Standardpreisen für Instances und Speicherplatz eine zusätzliche Pauschalgebühr/NIH (Normalized Instance Hour) berechnet. Die genauen Preise nach Region finden Sie auf der Preisseite. Die Gebühren für den erweiterten Support werden Ihrer Domain automatisch ab dem Tag nach Ablauf des Standard-Supports berechnet. Wenn für Ihre Domain eine Version ausgeführt wird, für die Standard- und erweiterte Supportdaten veröffentlicht sind (siehe hier für Details), senden wir Ihnen drei Monate vor Ablauf des Standard-Supportdatums eine Benachrichtigung über Ihr persönliches Gesundheits-Dashboard, über die OpenSearch Service-Konsole und über EventBridge-Ereignisse. Weitere Informationen zu Überwachungsbenachrichtigungen im OpenSearch Service finden Sie in der Dokumentation hier.

Für Domains, auf denen Versionen unter dem erweiterten Support ausgeführt werden, wird eine zusätzliche Pauschalgebühr/Normalisierte Instanzstunde (NIH) berechnet. NIH wird als Faktor der Instanzgröße (etwa mittel, groß) und der Anzahl der Instanzstunden berechnet. Wenn Sie beispielsweise eine m7g.medium.search-Instanz 24 Stunden lang in den USA Ost (Nord-Virginia) ausführen, die einen Preis von 0,068 USD/Stunde (On-Demand) hat, zahlen Sie in der Regel 1,632 USD (0,068 USD x 24) als Instanzkosten. Wenn Sie eine Version mit erweitertem Support ausführen, zahlen Sie zusätzlich 0,0065 USD/NIH, was sich wie folgt berechnet: 0,0065 USD x 24 (Anzahl der Instance-Stunden) x 2 (Größen-Normalisierungsfaktor; 2 für mittelgroße Instances), was 0,312 USD für den erweiterten Support für 24 Stunden ergibt. Der Gesamtbetrag, den Sie für 24 Stunden zahlen, setzt sich aus den Standardkosten für die Verwendung der Instance (ohne Speicher) und den Kosten für den erweiterten Support zusammen, die sich auf 1,944 USD (1,632 USD + 0,312 USD) belaufen. Weitere Informationen finden Sie in der Dokumentation.

Sie können Ihre Domain auf eine Engine-Version aktualisieren, die durch den Standard-Support abgedeckt ist. Eine Version ist bis zum veröffentlichten Ende des Standard-Supports oder bis kein Ende des Standard-Supports für die Version angekündigt wurde, durch den Standard-Support abgedeckt.

Nein. Wir empfehlen Ihnen, ein Upgrade auf eine Version durchzuführen, die durch den Standard- oder erweiterten Support abgedeckt ist, oder auf eine Version, für die das Support-Ende noch nicht angekündigt wurde. Sobald der erweiterte Support für eine Version endet, erhalten Domains, auf denen die betreffende Version ausgeführt wird, keine Fehlerbehebungen oder Sicherheitsupdates mehr.

Sobald der erweiterte Support für eine Version endet, werden wir keine Bugfixes oder Sicherheitsupdates mehr für diese bestimmte Version veröffentlichen. Domains, auf denen nicht unterstützte Versionen ausgeführt werden, werden isoliert und die Daten werden mindestens 30 Tage lang aufbewahrt. Auf isolierte Domains kann nicht mehr zugegriffen werden, und Sie müssen Daten in einer neuen Domain wiederherstellen, auf der eine unterstützte Version ausgeführt wird. Wir empfehlen Ihnen dringend, Ihre Domain vor Ablauf des erweiterten Supports für eine bestimmte Version auf eine unterstützte Version zu aktualisieren. Wenn Sie weitere Unterstützung benötigen, wenden Sie sich bitte an den AWS-Support.

Ja. Solange die von Ihnen verwendete Engine-Version durch den erweiterten Support abgedeckt ist, können Sie den Service wie gewohnt und ohne Einschränkungen weiter nutzen.

Im Rahmen des erweiterten Supports stellt AWS bei Bedarf kritische Sicherheitskorrekturen und Betriebssystem-Patches bereit.

Ja, je nach Version, von der Sie upgraden und auf die Sie upgraden. Eine Liste der unterstützten Upgrade-Pfade finden Sie in der Dokumentation hier. Wenn Sie von älteren Versionen wie ES 1.5 oder ES 2.3 wechseln, unterstützen wir keine direkten Upgrades. In der Dokumentation hier finden Sie Anweisungen zum Upgrade Ihrer Domains, auf denen ältere Versionen ausgeführt werden.

Die Null-ETL-Integration in Amazon DynamoDB abstrahiert die operative Komplexität bei der Orchestrierung der Replikation von Daten von einem Betriebsdatenspeicher in einen Suchdatenspeicher. Datenpipelines, die verwendet werden, um verschiedene Datenspeicher synchron zu halten, können schwierig und kostspielig sein, und es treten gelegentlich Fehler auf, die schwer nachzuverfolgen sind. Diese Integration ermöglicht es Amazon-DynamoDB-Kunden, nahezu in Echtzeit Suchergebnisse aus ihren Transaktionsdaten zu erhalten, indem eine vollständig verwaltete Lösung angeboten wird, mit der Transaktionsdaten aus Amazon DynamoDB innerhalb von Sekunden nach dem Schreiben in Amazon OpenSearch Service verfügbar gemacht werden können.

Die Null-ETL-Integration von Amazon OpenSearch Service in Amazon DynamoDB nutzt Amazon OpenSearch Ingestion, um Betriebsdaten nahtlos von Amazon DynamoDB zu Amazon OpenSearch Service zu übertragen. Um eine Integration zu ermöglichen, wählen Kunden zunächst die Amazon DynamoDB-Tabelle aus, deren Daten repliziert werden müssen. Das Feature Null-ETL-Integration richtet eine Amazon-OpenSearch-Ingestion-Pipeline im Kundenkonto ein, die sich um die Replikation der Daten in einen von Amazon OpenSearch Service verwalteten Cluster oder eine Serverless-Sammlung kümmert. Amazon OpenSearch Ingestion versteht die Struktur der Amazon-DynamoDB-Tabellen und lädt dann eine entsprechende, vom Amazon OpenSearch Service verwaltete Cluster- oder Serverless-Sammlung mit den vorhandenen Daten aus den DynamoDB-Tabellen. Optional können Kunden ein Schema für die Indizes angeben, die in Amazon OpenSearch Service erstellt werden. Alle Aktualisierungen der DynamoDB-Tabelle werden auch in Amazon OpenSearch Service repliziert, ohne dass Kunden manuell eingreifen müssen.

Dieses Null-ETL-Feature verwendet Amazon OpenSearch Ingestion, um die Daten von Amazon DynamoDB zu Amazon OpenSearch Service zu verschieben, und nutzt die systemeigenen Datentransformationsfunktionen der Amazon-OpenSearch-Ingestion-Pipelines, um die Daten während der Übertragung zu aggregieren und zu filtern. Beim Verschieben der Daten aus einer Amazon-DynamoDB-Tabelle möchten Kunden möglicherweise einige Felder löschen oder neue Felder erstellen, die auf Aggregationen vorhandener Felder basieren. Optional können Kunden auch eine benutzerdefinierte Logik für Amazon OpenSearch Ingestion schreiben, um maßgeschneiderte Transformationsfunktionen zu erreichen. Für andere Benutzer, die nur ihre gesamten Daten von der Quelle zur Sink verschieben möchten, bietet Amazon OpenSearch Ingestion sofort einsatzbereite Vorlagen, sodass sie die Integrationen mit nur wenigen Tastenklicks durchführen können.

Um sicherzustellen, dass Amazon OpenSearch Ingestion über die erforderlichen Berechtigungen verfügt, um Daten zwischen diesen beiden Systemen zu replizieren, erstellt das Feature Null-ETL-Integration eine IAM-Rolle mit den erforderlichen Berechtigungen, um Daten aus Amazon DynamoDB-Tabellen zu lesen und in eine Amazon-OpenSearch-Domain oder -Sammlung zu schreiben. Diese Rolle wird dann von den Amazon-OpenSearch-Ingestion-Pipelines übernommen, um sicherzustellen, dass beim Verschieben der Daten von der Quelle zum Ziel immer die richtige Sicherheitslage eingehalten wird.

Sie können alle Metriken zu Ihrer Null-ETL-Integration in Amazon DynamoDB in den von Amazon OpenSearch Ingestion bereitgestellten Dashboards zusammen mit Echtzeitprotokollen in Amazon CloudWatch einsehen. Auf diese Weise können Kunden benutzerdefinierte Benachrichtigungen einrichten, die ausgelöst werden, wenn benutzerdefinierte Schwellenwerte überschritten werden.

Die OpenSearch-Service-Abfrage-Engine wurde neu konzipiert, um die Analyse von Betriebsdaten zu unterstützen, die in Cloud-Objektspeichern wie Amazon S3 und S3-basierten Data Lakes gespeichert sind. Dies geschieht, ohne Daten zu duplizieren. Wenn Sekunden einen Unterschied machen, können Kunden die Leistung ihrer Abfragen steigern und schnell ladende Dashboards erstellen, indem sie die integrierten Funktionen der neuen Integration zur Abfragebeschleunigung nutzen.

Um mit der AWS-Managementkonsole zu beginnen, richten Kunden eine neue Datenquelle aus einer bestehenden OpenSearch-Service-Domain ein, auf der OpenSearch Service Version 2.11 oder höher ausgeführt wird. Bei der Einrichtung der neuen Direct-Query-Datenquelle müssen Kunden Lese-/Schreibzugriff auf Amazon S3 und AWS-Glue-Datenkatalog gewähren, um das Abfragen von Daten in Amazon S3 aus OpenSearch Service zu erleichtern. Kunden können IAM-Richtlinien anpassen, um den Zugriff auf bestimmte Buckets in Amazon S3 oder Ressourcen im AWS-Glue-Datenkatalog einzuschränken. Nach der Konfiguration der neuen Datenquelle in der Konsole können Kunden zu OpenSearch Service wechseln, um rollenbasierte Zugriffskontrollen, Beschleunigungen zur Beschleunigung der Abfrageleistung und optional sofort einsatzbereite Dashboards für beliebte Protokolltypvorlagen wie VPC-Flow-Protokolle, Elastic-Load-Balancer-Protokolle und NGINX-Protokolle zu konfigurieren. Den Kunden werden die verbrauchten Rechenressourcen in Form von Direct Query OpenSearch Compute Units (OCUs) in Rechnung gestellt; es fallen Nutzungsgebühren an. Nach der Konfiguration der neuen Datenquelle können Kunden damit beginnen, ihre Daten direkt über die OpenSearch-API oder OpenSearch-Dashboards abzufragen.

Kunden zahlen nur für die Ressourcen, die durch ihren Workload verbraucht werden. OpenSearch Service berechnet nur die Rechenleistung, die für die direkte Abfrage externer Daten sowie für die Verwaltung optionaler Indizes in OpenSearch Service erforderlich ist. Die Rechenkapazität wird in OpenSearch Compute Units (OCUs) gemessen. Dabei handelt es sich um dieselben Einheiten, die von Amazon OpenSearch Serverless und Amazon OpenSearch Ingestion verwendet werden. Die Anzahl der OCUs entspricht direkt der vCPU und dem Arbeitsspeicher, die zum Abfragen oder Verwalten von Indizes auf der Grundlage der Daten erforderlich sind. Kunden sehen einen Eintrag für die Berechnung in OCU-Stunden mit der Bezeichnung für die Direktabfrage. OCUs werden auf Stundenbasis mit granularer Genauigkeit pro Minute abgerechnet. Wenn keine Abfragen oder Indexierungsaktivitäten aktiv sind, werden keine OCUs verbraucht. Die Kosten für Amazon S3 oder AWS-Glue-Datenkatalog werden im Konto des Kunden separat in Rechnung gestellt. Weitere Preisinformationen finden Sie auf der Seite mit den Preisinformationen für Amazon OpenSearch Service.

Die Integration zwischen Amazon OpenSearch Service und Amazon Security Lake bietet ein optimiertes Erlebnis für die direkte Suche, Gewinnung von Erkenntnissen und Analyse der in Security Lake gespeicherten Daten – alles innerhalb des OpenSearch Service. Es gibt zwei Möglichkeiten, Security Lake und OpenSearch Service zu integrieren: Abfragezugriff und Datenzugriff.

Mit der Abfragezugriff-Integration können Sicherheitsanalysten die OpenSearch-Dashboards-Konsole verwenden, um direkte Abfragen der Daten in Security Lake durchzuführen und On-Demand-Indizierung und vorgefertigte Inhalte zu nutzen, um mit sicherheitsbezogenen Abfragen zu beginnen. Für die Datenzugriff-Integration stellt der OpenSearch-Ingestion-Dienst einen vorkonfigurierten Security Lake-Blueprint bereit, der eine Standardkonfiguration für die Aufnahme von Open-Cybersecurity-Schema-Framework-(OCSF)-Parquet-Dateien aus Security Lake enthält. Die Null-ETL-Integration mit Security Lake wird nur für Sammlungen mit OpenSearch-Benutzeroberfläche und nicht für Cluster angeboten.

Um loszulegen, benötigen Sie zunächst ein vorhandenes Security-Lake-Setup in Ihrer AWS-Umgebung. Dies ermöglicht die zentrale Speicherung und den Zugriff auf Ihre Unternehmenssicherheitsdaten.

Anschließend können Sie die Integration zwischen den beiden Services über die AWS-Managementkonsole oder mithilfe von AWS-CloudFormation-Vorlagen aktivieren. Dazu müssen Sie die erforderlichen Berechtigungen und Zugriffskontrollen konfigurieren, damit Amazon OpenSearch Service sicher auf die Daten in Ihrem Security Lake zugreifen und diese abfragen kann.

Anschließend können Sie die vorgefertigten Abfragen und Integrationen erkunden, die über OCSF verfügbar sind, um schnell mit gängigen Anwendungsfällen für Sicherheitsanalysen zu beginnen. Sie haben auch die Möglichkeit, die On-Demand-Indizierung bestimmter Datensätze aus Ihrem Security Lake in OpenSearch Service für erweiterte Analyse- und Visualisierungsanforderungen zu konfigurieren.