Erwägungen zur Verwendung von Amazon Redshift bereitgestellter Cluster - Amazon Redshift

Amazon Redshift unterstützt ab dem 1. November 2025 nicht mehr die Erstellung neuer Python-UDFs. Wenn Sie Python-UDFs verwenden möchten, erstellen Sie die UDFs vor diesem Datum. Bestehende Python-UDFs funktionieren weiterhin wie gewohnt. Weitere Informationen finden Sie im Blog-Posting.

Erwägungen zur Verwendung von Amazon Redshift bereitgestellter Cluster

Nach der Erstellung Ihres Clusters finden Sie in diesem Abschnitt Informationen zu Regionen, in denen Features verfügbar sind, zu Wartungsaufgaben, Knotentypen und Nutzungsbeschränkungen.

Überlegungen zu Regionen und Availability Zones

Amazon Redshift ist in verschiedenen AWS-Regionen verfügbar. Standardmäßig stellt Amazon Redshift Ihren Cluster in einer zufällig ausgewählten Availability Zone (AZ) in der von Ihnen ausgewählten AWS-Region bereit. Alle Knoten des Clusters werden in derselben Availability Zone bereitgestellt.

Sie können optional eine bestimmte Availability Zone anfordern, wenn in dieser Zone Amazon Redshift verfügbar ist. Zum Beispiel: Wenn Sie bereits eine Amazon-EC2-Instance in einer Availability Zone ausführen, sollten Sie Ihren Amazon-Redshift-Cluster auch in dieser Zone erstellen, um die Latenz zu reduzieren. Andererseits können Sie eine andere Availability Zone für höhere Verfügbarkeit wählen. Amazon Redshift ist möglicherweise nicht in allen Availability Zones innerhalb einer AWS-Region verfügbar:

Eine Liste der unterstützen AWS-Regionen, in denen ein Amazon-Redshift-Cluster bereitgestellt werden kann, finden Sie unter Amazon-Redshift-Endpunkte in der Allgemeine Amazon Web Services-Referenz.

Clusterwartung

Amazon Redshift führt periodisch Wartungsaktivitäten durch, um Upgrades auf Ihren Cluster anzuwenden. Während dieser Aktualisierungen ist Ihr Amazon-Redshift-Cluster nicht für den Normalbetrieb verfügbar. Sie haben verschiedene Möglichkeiten zu steuern, wie wir Ihr Cluster warten. Sie können beispielsweise den Zeitpunkt der Bereitstellung von Updates für Ihre Cluster kontrollieren. Sie können auch auswählen, ob in Ihrem Cluster die neueste oder die zweitneueste Version ausgeführt wird. Schließlich können Sie noch einstellen, dass optionale Wartungsupdates eine Weile zurückgestellt werden.

Wartungsfenster

Amazon Redshift weist auf Zufallsbasis ein 30-minütiges Wartungsfenster aus einem 8-Stunden-Zeitblock pro AWS-Region zu, an einem zufällig ausgewählten Wochentag (Montag bis einschließlich Sonntag).

Standardwartungsfenster

Die folgende Liste zeigt die Zeitblöcke für jede AWS-Region auf, von denen die Standard-Wartungsfenster zugewiesen werden:

  • Region USA Ost (Nord-Virginia): 03.00 bis 11.00 Uhr (UTC)

  • Region USA Ost (Ohio): 03.00 bis 11.00 Uhr (UTC)

  • Region USA West (Nordkalifornien): 06.00 bis 14.00 Uhr (UTC)

  • Region USA West (Oregon): 06.00 bis 14.00 Uhr (UTC)

  • Region Afrika (Kapstadt): 20.00 bis 04.00 Uhr (UTC)

  • Region Asien-Pazifik (Hongkong): 13.00 bis 21.00 Uhr (UTC)

  • Region Asien-Pazifik (Hyderabad): 16.30 bis 00.30 Uhr (UTC)

  • Region Asien-Pazifik (Jakarta): 15.00 bis 23.00 Uhr (UTC)

  • Region Asien-Pazifik (Malaysia): 14.00 bis 22.00 Uhr (UTC)

  • Region Asien-Pazifik (Melbourne): 12.00 bis 20.00 Uhr (UTC)

  • Region Asien-Pazifik (Mumbai): 16.30 bis 00.30 Uhr (UTC)

  • Region Asien-Pazifik (Neuseeland): 10:00 bis 18:00 Uhr UTC

  • Region Asien-Pazifik (Osaka): 13.00 bis 21.00 Uhr (UTC)

  • Region Asien-Pazifik (Seoul): 13.00 bis 21.00 Uhr (UTC)

  • Region Asien-Pazifik (Singapur): 14.00 bis 22.00 Uhr (UTC)

  • Region Asien-Pazifik (Sydney): 12.00 bis 20.00 Uhr (UTC)

  • Region Asien-Pazifik (Taipei): 14.00 bis 22.00 Uhr (UTC)

  • Region Asien-Pazifik (Thailand): 15.00 bis 23.00 Uhr (UTC)

  • Region Asien-Pazifik (Tokio): 13.00 bis 21.00 Uhr (UTC)

  • Region Kanada (Zentral): 03.00 bis 11.00 Uhr (UTC)

  • Region Kanada West (Calgary): 04:00–12:00 Uhr UTC

  • Region China (Peking): 13.00 bis 21.00 Uhr (UTC)

  • Region China (Ningxia): 13.00 bis 21.00 Uhr (UTC)

  • Region Europa (Frankfurt): 06.00 bis 14.00 Uhr (UTC)

  • Region Europa (Irland): 22.00 bis 06.00 Uhr (UTC)

  • Region Europa (London): 22.00 bis 06.00 Uhr (UTC)

  • Region Europa (Mailand): 21.00 bis 05.00 Uhr (UTC)

  • Region Europa (Paris): 23.00 bis 07.00 Uhr (UTC)

  • Region Europa (Stockholm): 23.00 bis 07.00 Uhr (UTC)

  • Region Europa (Zürich): 20.00 bis 04.00 Uhr (UTC)

  • Region Israel (Tel Aviv): 20:00–04:00 Uhr UTC

  • Region Mexiko (Zentral): 4.00 bis 12.00 Uhr (UTC)

  • Region Europa (Spanien): 21.00 bis 05.00 Uhr (UTC)

  • Region Naher Osten (Bahrain): 13.00 bis 21.00 Uhr (UTC)

  • Region Naher Osten (VAE): 18:00 bis 02:00 Uhr (UTC)

  • Region Südamerika (São Paulo): 19.00 bis 03.00 Uhr (UTC)

Wenn ein Wartungsereignis für eine bestimmte Woche geplant ist, wird es in dem zugewiesenen 30-minütigen Wartungsfenster gestartet. Während Amazon Redshift die Wartung durchführt, beendet es alle Abfragen und anderen ausgeführten Operationen. Die meisten Wartungsaktivitäten werden innerhalb des 30-minütigen Wartungsfensters abgeschlossen. Einige können jedoch auch nach dem Schließen des Fensters fortgesetzt werden. Wenn während des geplanten Wartungsfensters keine Wartungsaktivitäten auszuführen sind, wird Ihr Cluster bis zum nächsten geplanten Wartungsfenster normal weiterbetrieben.

Sie können das geplante Wartungsfenster ändern, indem Sie den Cluster modifizieren, entweder auf programmatischem Wege oder mit der Amazon-Redshift-Konsole. Auf der Registerkarte Wartungfinden Sie das Wartungsfenster und können den Tag und die Uhrzeit für den Cluster festlegen.

Es ist möglich, dass ein Cluster außerhalb eines Wartungsfensters neu gestartet wird. Es gibt mehrere Gründe, warum dies geschehen kann. Ein häufiger Grund ist, dass ein Problem mit dem Cluster festgestellt wurde und Wartungsarbeiten durchgeführt werden, um den Cluster wieder in einen fehlerfreien Zustand zu versetzen. Weitere Informationen finden Sie hier: Warum wurde mein Amazon-Redshift-Cluster außerhalb des Wartungsfensters neu gestartet? Dort werden die Gründe dafür detailliert beschrieben.

Aufschieben der Wartung

Um den Zeitplan für das Wartungsfenster Ihres Clusters zu ändern, können Sie die Wartung um bis zu 45 Tage aufschieben. Beispiel: Wenn Ihr Wartungsfenster auf Mittwoch, 08:30–09:00 Uhr UTC festgelegt ist, Sie aber zu dieser Zeit auf den Cluster zugreifen müssen, können Sie die Wartung aufschieben.

Wenn Sie die Wartung verschieben, wendet Amazon Redshift weiterhin Hardware-Updates oder andere obligatorische Sicherheitsupdates auf Ihren Cluster an. Während dieser Aktualisierungen ist Ihr Cluster nicht verfügbar.

Wenn während des bevorstehenden Wartungsfensters ein Hardware-Update oder ein anderes obligatorisches Sicherheitsupdate geplant ist, sendet Ihnen Amazon Redshift Vorabbenachrichtigungen in der Kategorie Ausstehend. Weitere Informationen zu Benachrichtigungen über ausstehende Ereignisse finden Sie unter Abonnieren von Cluster-Ereignisbenachrichtigungen von Amazon Redshift provisioned.

Zum Senden und Empfangen von SMS-Benachrichtigungen können Sie den Amazon Simple Notification Service (Amazon SNS) verwenden. Weitere Informationen zum Abonnieren von Amazon-RDS-Ereignisbenachrichtigungen finden Sie unter Auflistung der Abonnements für Ereignisbenachrichtigungen zu Amazon-Redshift-Clustern.

Wenn Sie die Wartung Ihres Clusters aufschieben, ist das auf den Aufschub folgende Wartungsfenster obligatorisch und kann nicht seinerseits verschoben werden.

Anmerkung

Es ist nicht möglich, eine bereits begonnene Wartung aufzuschieben.

Weitere Informationen zur Cluster-Wartung finden Sie in der folgenden Dokumentation:

Auswählen des Cluster-Wartungspfads

Wenn Amazon Redshift eine neue Clusterversion veröffentlicht, wird Ihr Cluster in seinem Wartungsfenster aktualisiert. Sie können angeben, ob der Cluster auf die zuletzt freigegebene oder die vorherige Version aktualisiert wird.

Welche Cluster-Version in einem Wartungszeitraum installiert wird, wird über den Track gesteuert. Wenn Amazon Redshift eine neue Clusterversion veröffentlicht, wird diese Version dem aktuellen Pfad zugewiesen, und die Vorversion dem nachgestellten Pfad.

Weitere Informationen zu Cluster-Tracks finden Sie unter Tracks für von Amazon Redshift bereitgestellte Cluster und Serverless-Arbeitsgruppen.

Wie RA3-Knoten Datenverarbeitung und Speicher trennen

In diesen Abschnitten werden die für RA3-Knotentypen verfügbaren Aufgaben detailliert beschrieben, ihre Anwendbarkeit auf eine Reihe von Anwendungsfällen aufgezeigt und ihre Vorteile gegenüber zuvor verfügbaren Knotentypen detailliert beschrieben.

Vorteile und Verfügbarkeit von RA3-Knoten

RA3-Knoten bieten folgende Vorteile:

  • Sie sind flexibel, um Ihre Datenverarbeitungskapazität zu erweitern, ohne Ihre Speicherkosten zu erhöhen. Dazu skalieren sie Ihren Speicher ohne übermäßige Bereitstellung von Datenverarbeitungskapazität.

  • Sie verwenden Hochleistungs-SSDs für Ihre heißen Daten und Amazon S3 für kalte Daten. So bieten sie Benutzerfreundlichkeit, kostengünstige Speicherung und hohe Abfrageleistung.

  • Sie nutzen Netzwerke mit hoher Bandbreite, die auf dem AWS Nitro-System aufbaut, um den Zeitaufwand für das Auslagern und Abrufen von Daten von Amazon S3 weiter zu reduzieren.

In folgenden Fällen sollten Sie erwägen, RA3-Knotentypen zu wählen:

  • Sie benötigen Flexibilität, um Datenverarbeitungsleistung getrennt vom Speicher zu skalieren.

  • Sie fragen einen Bruchteil Ihrer Gesamtdaten ab.

  • Ihr Datenvolumen wächst schnell, oder es wird erwartet, dass es schnell wächst.

  • Sie brauchen die Flexibilität, den Cluster nur auf Ihre Leistungsanforderungen zu skalieren.

Um RA3-Knotentypen zu verwenden, muss Ihre AWS-Region RA3 unterstützen. Weitere Informationen finden Sie unter Verfügbarkeit der RA3-Knotentypen in AWS-Regionen.

Wichtig

ra3.xlplus-Knotentypen können nur mit Cluster-Version 1.0.21262 oder höher verwendet werden. Sie können sich die Version eines vorhandenen Clusters mithilfe der Amazon-Redshift-Konsole anzeigen lassen. Weitere Informationen finden Sie unter Ermitteln der Arbeitsgruppen- oder Cluster-Version.

Stellen Sie sicher, dass Sie beim Arbeiten mit RA3-Knotentypen die neue Amazon-Redshift-Konsole verwenden.

Um RA3-Knotentypen mit Amazon-Redshift-Operationen verwenden zu können, die den Track verwenden, muss der Wert des Wartungspfads auf eine Cluster-Version gesetzt werden, die RA3 unterstützt. Weitere Informationen zu Tracks finden Sie unter Auswählen des Cluster-Wartungspfads.

Berücksichtigen Sie Folgendes, wenn Sie RA3-Knotentypen mit nur einem Knoten verwenden.

  • Datenfreigabe-Produzenten und -Konsumenten werden unterstützt.

  • Zum Ändern der Knotentypen wird nur klassische Größenanpassung unterstützt. Das Ändern des Knotentyps mit elastischer Größenanpassung oder Snapshot-Wiederherstellung wird nicht unterstützt. Die folgenden Szenarien werden unterstützt:

    • Klassische Größenanpassung eines dc2.xlarge mit 1 Knoten zu einem ra3.xlplus mit 1 Knoten und umgekehrt.

    • Klassische Größenanpassung eines dc2.xlarge mit 1 Knoten zu einem ra3.xlplus mit mehreren Knoten und umgekehrt.

    • Klassische Größenanpassung eines dc2.xlarge mit mehreren Knoten zu einem ra3.xlplus mit 1 Knoten und umgekehrt.

Arbeiten mit von Amazon Redshift verwaltetem Speicher

Mit von Amazon Redshift verwaltetem Speicher können Sie alle Ihre Daten in Amazon Redshift speichern und verarbeiten und gleichzeitig mehr Flexibilität bei der getrennten Skalierung von Datenverarbeitungs- und Speicherkapazität erhalten. Sie speisen weiterhin Daten mit dem Befehl COPY (KOPIEREN) bzw. INSERT (EINFÜGEN) ein. Um die Leistung zu optimieren und die automatische Datenplatzierung über verschiedene Speicherebenen hinweg zu verwalten, nutzt Amazon Redshift Optimierungen wie die Datenblocktemperatur, das Datenblockalter und die Workload-Muster. Bei Bedarf skaliert Amazon Redshift die Lagerung automatisch auf Amazon S3, ohne dass manuelle Maßnahmen erforderlich sind.

Weitere Information zu Speicherkosten finden Sie unter Amazon Redshift – Preise.

Verwalten von RA3-Knotentypen

Um die Vorteile der Trennung von Datenverarbeitungsleistung und Speicher zu nutzen, können Sie Ihren Cluster mit dem RA3-Knotentyp erstellen oder aktualisieren. Um die RA3-Knotentypen zu verwenden, erstellen Sie Ihre Cluster in einer Virtual Private Cloud (EC2-VPC).

Führen Sie einen der folgenden Schritte aus, um die Anzahl der Knoten des Amazon-Redshift-Clusters mit einem RA3-Knotentyp zu ändern:

  • Hinzufügen oder Entfernen von Knoten mit der elastischen Größenanpassung. In einigen Situationen ist das Entfernen von Knoten aus einem RA3-Cluster mit der elastischen Größenanpassung nicht zulässig. Dies ist beispielsweise der Fall, wenn bei einem Upgrade der 2:1 -Knotenanzahl die Anzahl der Slices pro Knoten auf 32 gesetzt wird. Weitere Informationen finden Sie unter Größenanpassung eines Clusters. Wenn die elastische Größenanpassung nicht verfügbar ist, verwenden Sie die klassische Größenanpassung.

  • Hinzufügen oder Entfernen von Knoten mit der klassischen Größenanpassung. Wählen Sie diese Option aus, wenn Sie die Konfiguration auf eine Größe ändern, die über die elastische Größenanpassung nicht verfügbar ist. Die elastische Größenanpassung ist schneller als die klassische Größenanpassung. Weitere Informationen finden Sie unter Größenanpassung eines Clusters.

Verfügbarkeit der RA3-Knotentypen in AWS-Regionen

Die RA3-Knotentypen sind nur in den folgenden AWS-Regionen verfügbar:

  • Region USA Ost (Nord-Virginia) (us-east-1)

  • Region USA Ost (Ohio) (us-east-2)

  • Region USA West (Nordkalifornien) (us-west-1)

  • Region USA West (Oregon) (us-west-2)

  • Region Afrika (Kapstadt) (af-south-1)

  • Region Asien-Pazifik (Hongkong) (ap-east-1)

  • Region Asien-Pazifik (Hyderabad) (ap-south-2)

  • Region Asien-Pazifik (Jakarta) (ap-southeast-3)

  • Asien-Pazifik (Malaysia) – ap-southeast-5

  • Region Asien-Pazifik (Melbourne) (ap-southeast-4)

  • Region Asien-Pazifik (Mumbai) (ap-south-1)

  • Asien-Pazifik (Neuseeland) – ap-southeast-6

  • Region Asien-Pazifik (Osaka) (ap-northeast-3)

  • Region Asien-Pazifik (Seoul) (ap-northeast-2)

  • Region Asien-Pazifik (Singapur) (ap-southeast-1)

  • Region Asien-Pazifik (Sydney) (ap-southeast-2)

  • Region Asien-Pazifik (Taipei) (ap-east-2)

  • Region Asien-Pazifik (Thailand) (ap-southeast-7)

  • Region Asien-Pazifik (Tokio) (ap-northeast-1)

  • Region Kanada (Zentral) (ca-central-1)

  • Region Kanada West (Calgary) (ca-west-1)

  • Region China (Peking) (cn-north-1)

  • Region China (Ningxia) (cn-northwest-1)

  • Region Europa (Frankfurt) (eu-central-1)

  • Region Europa (Zürich) (eu-central-2)

  • Region Europa (Irland) (eu-west-1)

  • Region Europa (London) (eu-west-2)

  • Region Europa (Mailand) (eu-south-1)

  • Region Europa (Spanien) (eu-south-2)

  • Region Europa (Paris) (eu-west-3)

  • Region Europa (Stockholm) (eu-north-1)

  • Region Israel (Tel Aviv) (il-central-1)

  • Region Mexiko (Zentral) (mx-central-1)

  • Region Naher Osten (Bahrain) (me-south-1)

  • Region Naher Osten (VAE) (me-central-1)

  • Region Südamerika (São Paulo) (sa-east-1)

  • AWS GovCloud (US-East) (us-gov-east-1)

  • AWS GovCloud (US-West) (us-gov-west-1)

Migration zu RA3-Knotentypen

Um Ihren vorhandenen Knotentyp zu RA3 zu aktualisieren, haben Sie die folgenden Optionen, um den Knotentyp zu ändern:

  • Die Wiederherstellung aus einem Snapshot – Amazon Redshift verwendet den neuesten Snapshot Ihres Clusters und stellt ihn wieder her, um einen neuen RA3-Cluster zu erstellen. Sobald die Clustererstellung abgeschlossen ist (in der Regel innerhalb von Minuten), sind RA3-Knoten bereit, den vollständigen Produktions-Workload auszuführen. Da die Datenverarbeitung vom Speicher getrennt ist, werden Hot Data dank einer großen Netzwerkbandbreite mit hohen Geschwindigkeiten in den lokalen Cache verschoben. Wenn Sie aus dem neuesten DC2-Snapshot wiederherstellen, behält RA3 Hot-Block-Informationen des DC2-Workloads bei und füllt den lokalen Cache mit den neuesten Blöcken auf. Weitere Informationen finden Sie unter Wiederherstellen eines Clusters aus einem Snapshot.

    Um den selben Endpunkt für Ihre Anwendungen und Benutzer beizubehalten, können Sie den neuen RA3-Cluster mit demselben Namen wie der ursprüngliche DC2-Cluster umbenennen. Um den Cluster umzubenennen, ändern Sie den Cluster in der Amazon-Redshift-Konsole oder die API-Operation ModifyCluster. Weitere Informationen finden Sie unter Umbenennen von Clustern oder API-Operation ModifyCluster in der API-Referenz von Amazon Redshift.

  • Elastische Größenanpassung – ändern Sie die Größe des Clusters mit der elastischen Größenanpassung. Wenn Sie die elastische Größenanpassung verwenden, um den Knotentyp zu ändern, erstellt Amazon Redshift automatisch einen Snapshot, einen neuen Cluster, löscht den alten Cluster und benennt den neuen Cluster um. Die elastische Größenanpassung kann On-Demand ausgeführt oder für einen Zeitpunkt in der Zukunft geplant werden. Sie können mit der elastischen Größenanpassung Ihre vorhandenen DC2-Knotentyp-Cluster schnell auf RA3 aktualisieren. Weitere Informationen finden Sie unter Elastic resize (Elastische Größenanpassung).

Die folgende Tabelle zeigt Empfehlungen für das Upgrade auf RA3-Knotentypen. (Diese Empfehlungen gelten auch für reservierte Knoten.)

Die Empfehlungen in dieser Tabelle beziehen sich auf die Typen und Größen von Cluster-Knoten, hängen jedoch von den Datenverarbeitungsanforderungen Ihres Workloads ab. Um Ihre Anforderungen besser einschätzen zu können, sollten Sie einen Machbarkeitsnachweis (Proof of Concept, POC) durchführen, bei dem Test Drive zur Ausführung potenzieller Konfigurationen verwendet wird. Stellen Sie statt Redshift Serverless einen Cluster für Ihr POC Data Warehouse bereit. Weitere Informationen zur Durchführung eines Machbarkeitsnachweises finden Sie unter Durchführen eines Machbarkeitsnachweises (POC) für Amazon Redshift im Datenbankentwicklerhandbuch zu Amazon Redshift.

Vorhandener Knotentyp Vorhandene Anzahl von Knoten Empfohlener neuer Knotentyp Upgrade-Aktion

dc2.8xlarge

2–15

ra3.4xlarge

Beginnen Sie mit 2 Knoten des Typs ra3.4xlarge für jeweils 1 Knoten des Typs dc2.8xlarge1.

dc2.8xlarge

16–128

ra3.16xlarge

Beginnen Sie mit 1 Knoten des Typs ra3.16xlarge für jeweils 2 Knoten des Typs dc2.8xlarge1.

dc2.large

1–4

ra3.large

Beginnen Sie mit 1 Knoten des Typs ra3.large für jeweils 1 Knoten des Typs dc2.large1.

Beginnen Sie mit 2 Knoten des Typs ra3.large für jeweils 2 Knoten des Typs dc2.large 1.

Beginnen Sie mit 3 Knoten des Typs ra3.large für jeweils 3 Knoten des Typs dc2.large 1.

Beginnen Sie mit 3 Knoten des Typs ra3.large für jeweils 4 Knoten des Typs dc2.large 1.

dc2.large

5–15

ra3.xlplus

Beginnen Sie mit 3 Knoten des Typs ra3.xlplus für jeweils 8 Knoten des Typs dc2.large1.

dc2.large

16–32

ra3.4xlarge

Beginnen Sie mit 1 Knoten des Typs ra3.4xlarge für jeweils 8 Knoten des Typs dc2.large1,2.

1Je nach Workload-Anforderungen können zusätzliche Knoten benötigt werden. Fügen Sie Knoten basierend auf den Datenverarbeitungsanforderungen Ihrer erforderlichen Abfrageleistung hinzu, oder entfernen Sie sie.

2Cluster mit dem Knotentyp dc2.large sind auf 32 Knoten begrenzt.

Die Mindestanzahl von Knoten für einige RA3-Knotentypen beträgt zwei Knoten. Berücksichtigen Sie dies beim Erstellen eines RA3-Clusters.

Netzwerkfunktionen, die von RA3-Knoten unterstützt werden

RA3-Knoten unterstützen eine Reihe von Netzwerk-Features, die für andere Knotentypen nicht verfügbar sind. Dieser Abschnitt enthält kurze Beschreibungen der einzelnen Features und Links zu zusätzlicher Dokumentation:

  • VPC-Endpunkt eines bereitgestellten Clusters – Wenn Sie einen RA3-Cluster erstellen oder wiederherstellen, verwendet Amazon Redshift einen Port innerhalb der Bereiche 5431-5455 oder 8191-8215. Wenn der Cluster auf einen Port in einem dieser Bereiche eingestellt ist, erstellt Amazon Redshift automatisch einen VPC-Endpunkt in Ihrem AWS-Konto für den Cluster und fügt ihm eine private IP-Adresse hinzu. Wenn Sie den Cluster auf öffentlich zugänglich einstellen, erstellt Redshift eine Elastic-IP-Adresse in Ihrem AWS-Konto und fügt sie dem VPC-Endpunkt hinzu. Weitere Informationen finden Sie unter Konfigurieren der Kommunikationseinstellungen von Sicherheitsgruppen für einen Amazon-Redshift-Cluster oder eine Arbeitsgruppe von Amazon Redshift Serverless.

  • RA3-Cluster mit einem einzigen Subnetz – Sie können einen RA3-Cluster mit einem einzigen Subnetz erstellen, dieser kann jedoch keine Notfallwiederherstellungs-Funktionen verwenden. Eine Ausnahme tritt auf, wenn Sie die Cluster-Verschiebung aktivieren, wenn das Subnetz nicht über mehrere Availability Zones (AZs) verfügt.

  • RA3-Cluster und Subnetzgruppen mit mehreren Subnetzen – Sie können einen RA3-Cluster mit mehreren Subnetzen erstellen, indem Sie bei der Bereitstellung des Clusters in Ihrer Virtual Private Cloud (VPC) eine Subnetzgruppe erstellen. Eine Cluster-Subnetzgruppe ermöglicht Ihnen die Angabe einer Reihe von Subnetzen in Ihrer VPC. Amazon Redshift erstellt den Cluster in einem davon. Nach dem Erstellen einer Subnetzgruppe können Sie zuvor hinzugefügte Subnetze entfernen oder weitere Subnetze hinzufügen. Weitere Informationen finden Sie unter Subnetzgruppen von Amazon-Redshift-Clustern.

  • Konto- oder VPC-übergreifender Endpunktzugriff – Sie können auf einen bereitgestellten Cluster oder eine Arbeitsgruppe von Amazon Redshift Serverless zugreifen, indem Sie einen von Redshift verwalteten VPC-Endpunkt einrichten. Sie können dies als private Verbindung zwischen einer VPC, die einen Cluster oder eine Arbeitsgruppe enthält, und einer VPC, auf der Sie beispielsweise ein Client-Tool ausführen. Damit können Sie auf das Data Warehouse zugreifen, ohne öffentliche IP-Adressen zu verwenden oder Datenverkehr über das Internet zu leiten. Weitere Informationen zu finden Sie unter Arbeiten mit von Redshift verwalteten VPC-Endpunkten.

  • Cluster-Verschiebung – Bei einer Serviceunterbrechung können Sie einen Cluster ohne Datenverlust in eine andere Availability Zone (AZ) verschieben. Diesen Vorgang führen Sie in der Konsole durch. Weitere Informationen finden Sie unter Verschieben eines Clusters.

  • Benutzerdefinierter Domain-Name – Sie können für Ihren Amazon-Redshift-Cluster einen benutzerdefinierten Domain-Namen, auch als benutzerdefinierte URL bezeichnet, erstellen. Es handelt sich dabei um einen leicht lesbaren DNS-Datensatz, der SQL-Client-Verbindungen an Ihren Cluster-Endpunkt weiterleitet. Weitere Informationen finden Sie unter Verwenden benutzerdefinierter Domain-Namen für Client-Verbindungen.