Amazon RDS-DB-Instance-Speicher - Amazon Relational Database Service

Amazon RDS-DB-Instance-Speicher

DB-Instances für Amazon RDS for MySQL, MariaDB, PostgreSQL, Oracle und Microsoft SQL Server verwenden Amazon Elastic Block Store (Amazon EBS)-Volumes als Datenbank- und Protokollspeicher. Je nach Größe des erforderlichen Speichers verteilt Amazon RDS Daten automatisch per Striping auf mehrere Amazon EBS-Volumes, um die IOPS-Leistung zu verbessern.

Amazon RDS-Speichertypen

Amazon RDS bietet drei Speichertypen: Allzweck-SSD (auch als gp2 bezeichnet), bereitgestellte IOPS-SSD (auch als io1 bezeichnet) und Magnetfestplatten (auch als Standard bezeichnet). Diese unterscheiden sich bei den Leistungsmerkmalen und im Preis, das bedeutet, dass Sie die Speicherleistung und -kosten an die Anforderungen der Datenbank-Workload anpassen können. Sie können MySQL-, MariaDB-, Oracle- und PostgreSQL-RDS-DB-Instances mit bis zu 64 TiB Speicherplatz erstellen. Sie können SQL Server-RDS-DB-Instances mit bis zu 16 TiB Speicherplatz erstellen. Bei dieser Speichermenge verwenden Sie die Speichertypen „SSD mit bereitgestellten IOPS“ und „Allzweck-SSD“.

In der folgenden Liste werden die drei Speichertypen beschrieben:

  • Allzweck-SSD –. Diese Volumes bieten kosteneffizienten Speicher, der für ein breites Spektrum an Workloads geeignet ist. Diese Volumes bieten Latenzen im einstelligen Millisekundenbereich und die Möglichkeit, für längere Zeiträume auf 3 000 IOPS zu beschleunigen. Die Baseline-Performance für diese Volumes wird durch die Größe des Volumes bestimmt.

    Weitere Informationen über Allzweck-SSD einschließlich der Speichergrößenbereiche finden Sie unter Allzweck-SSD-Speicher.

  • Bereitgestellte IOPS – Diese Speicherart ist darauf ausgelegt, die Anforderungen E/A-intensiver Workloads zu erfüllen, insbesondere von Datenbank-Workloads, bei denen eine geringe E/A-Latenz und ein konstanter E/A-Durchsatz erforderlich sind.

    Weitere Informationen über bereitgestellte IOPS einschließlich der Speichergrößenbereiche finden Sie unter Bereitgestellter IOPS SSD-Speicher.

  • Magnetspeicher – Amazon RDS unterstützt auch magnetische Speicherung für die Abwärtskompatibilität. Wir empfehlen generell die Nutzung von Allzweck-SSD-Speicher oder Speicher mit bereitgestellten IOPS. Der maximal zulässige Speicherplatz für DB-Instances auf magnetischem Speicher ist geringer als bei den anderen Speichertypen. Weitere Informationen finden Sie unter Magnetfestplatten.

Mehrere Faktoren können sich auf die Leistung von Amazon EBS-Volumes auswirken, z. B. Instance-Konfiguration, E/A-Merkmale und Auslastung. Weitere Informationen zur optimalen Nutzung von Volumes mit bereitgestellten IOPS finden Sie unter Leistung des Amazon EBS-Volumes.

Allzweck-SSD-Speicher

Allzweck-SSD-Speicher ist kosteneffizient und für die meisten Datenbank-Workloads akzeptabel. Nachfolgend sind die Speichergrößenbereiche für Allzweck-SSD-DB-Instances aufgeführt:

  • MariaDB-, MySQL-, Oracle- und PostgreSQL-Datenbank-Instances: 20 GiB–64 TiB

  • SQL Server Enterprise-, Standard-, Web- und Express-Editionen: 20 GiB–16 TiB

Die E/A-Basisleistung bei Allzweck-SSD-Speicher liegt bei 3 IOPS pro GiB mit mindestens 100 IOPS. Dieses Verhältnis bedeutet, dass die Leistung bei großen Volumes besser. Beispielsweise verfügt ein Volume mit 100 GiB über eine Basisleistung von 300 IOPS. Ein Volume mit 1 TiB verfügt über eine Basisleistung von 3.000 IOPS. Ein Volume mit 5,34 TiB verfügt über eine Basisleistung von 16.000 IOPS.

Volumes unter 1 TiB können über einen längeren Zeitraum zudem bis auf 3.000 IOPS steigen. Die Steigerung ist bei Volumes über 1 TiB nicht relevant. Die Steigerungsleistung wird durch das E/A-Guthaben der Instance bestimmt. Weitere Informationen zu den E/A-Guthabenpunkten der Instance finden Sie unter E/A-Guthaben und Maximalleistung.

Bei vielen Workloads wird das Steigerungsguthaben nie aufgebraucht, wodurch sich die Allzweck-SSD für viele Workloads am besten zur Speicherung eignet. Einige Workloads können das Speicherguthaben für die Steigerung auf 3,000 IOPS allerdings erschöpfen, daher sollten Sie Ihre Speicherkapazität so planen, dass sie den Anforderungen Ihrer Workloads entspricht.

E/A-Guthaben und Maximalleistung

Die Leistung des Allzweck-SSD-Speichers hängt von der Volume-Größe ab, die Basisleistung des Volumes bestimmt und von der abhängt, wie schnell sich E/A-Guthabenpunkte ansammeln. Größere Volumes verfügen über eine höhere Basisleistung und sammeln schneller E/A-Guthaben an. E/A-Guthabenpunkte repräsentieren die verfügbare Bandbreite, die ein Allzweck-SSD-Speicher aufwenden kann, wenn für große E/A-Mengen mehr als die Basisleistung benötigt wird. Je mehr E/A-Guthabenpunkte für den Speicher vorliegen, desto länger kann die Leistung über die Basisleistung hinaus gesteigert werden und desto besser ist die Leistung, wenn für Ihr Workload mehr Leistung benötigt wird.

Bei Verwendung des Allzweck-SSD-Speichers erhält Ihre DB-Instance ein anfängliches E/A-Guthaben in Höhe von 5,4 Millionen E/A-Guthabenpunkten. Dieses anfängliche Guthaben reicht für 30 Minuten gesteigerter Leistung mit 3.000 IOPS aus. Es soll einen schnellen ersten Systemstartzyklus für Start-Volumes und ein gutes Bootstrapping für andere Anwendungen bieten. Volumes sammeln mit der Basisleistungsrate von 3 IOPS pro GiB der Volume-Größe E/A-Guthabenpunkte an. Beispielsweise verfügt ein SSD-Volume mit 100 GiB über eine Basisleistung von 300 IOPS.

Wenn der Speicher mehr als die E/A-Basisleistung benötigt, werden E/A-Guthabenpunkte verbraucht, um die benötigte Leistung zu liefern. Das Maximum einer derartigen Steigerung liegt bei 3.000 IOPS. Speicher, der größer als 1.000 GiB ist, verfügt über eine Basisleistung, die so groß wie oder größer als die Maximalleistung ist. Wenn der Speicher pro Sekunde weniger E/A-Guthaben verbraucht, als er ansammelt, werden ungenutzte E/A-Guthabenpunkte dem E/A-Guthaben hinzugefügt. Der Höchstwert für das E/A-Guthaben für eine DB-Instance mit Allzweck-SSD-Speicher beträgt – wie das anfängliche E/A-Guthaben – 5,4 Millionen E/A-Guthabenpunkte.

Angenommen, Ihr Speicher braucht das gesamte E/A-Guthaben auf. In diesem Fall wird die Maximalleistung auf die Basisleistung (die Geschwindigkeit, mit der das Volume E/A-Guthabenpunkte ansammelt) reduziert, bis der E/A-Bedarf unter die Grundrate fällt und dem E/A-Guthaben ungenutzte Guthabenpunkte hinzugefügt werden. (Der Basis-Performance-Level ist die Rate, mit der Ihr Storage E/A-Credits verdient). Je mehr Speicher vorhanden ist, desto höher ist seine Basisleistung und desto schneller wird das E/A-Guthaben wieder aufgefüllt.

Anmerkung

Speicherkonvertierungen zwischen magnetischem Speicher und Allzweck-SSD-Speicher können unter Umständen Ihre E/A-Guthabenpunkte verbrauchen, wodurch es zu längeren Konvertierungszeiten kommt. Weitere Informationen über die Skalierung von Speicher finden Sie unter Arbeiten mit Speicher für Amazon RDS-DB-Instances.

Die folgende Tabelle führt verschiedene Speichergrößen auf. Für jede Speichergröße wird die jeweils zugehörige Basisleistung des Speichers aufgelistet, also die Rate, mit der E/A-Guthabenpunkte gesammelt werden. In der Tabelle wird auch die Burst-Dauer bei einem Maximum von 3.000 IOPS angegeben, wenn mit einem vollen E/A-Guthaben begonnen wird. Zusätzlich wird in der Tabelle die Zeit in Sekunden angegeben, die der Speicher benötigt, um ein leeres E/A-Guthaben aufzufüllen.

Anmerkung

Die IOPS-Wert erreicht sein Maximum bei einer Volumegröße von 5 334 GiB.

Speichergröße (GiB) Basisleistung (IOPS) Maximale Steigerungsdauer bei 3.000 IOPS (Sekunden) Sekunden zum Auffüllen des vollständig verbrauchten E/A-Guthabens
1 100 1,862 54,000
100 300 2000 18.000
250 750 2.400 7,200
500 1.500 3.600 3.600
750 2.250 7.200 2.400
1.000 3.000 Unendlich --
5.334 16.000 -- --

Die Burst-Dauer des Speichers hängt von der Größe des Speichers, der benötigten IOPS-Spitzenleistung und dem E/A-Guthaben zum Zeitpunkt der Leistungssteigerung ab. Dieses Verhältnis wird anhand der folgenden Gleichung veranschaulicht.

(Credit balance) Burst duration =  ------------------------------------ (Burst IOPS) - 3(Storage size in GiB)

Sie bemerken möglicherweise, dass die Speicherleistung häufig aufgrund eines leeren E/A-Guthabens auf die Grundrate begrenzt ist. In diesem Fall können Sie weiteren Allzweck-SSD-Speicher mit einer höheren Basisleistungsstufe zuweisen. Alternativ können Sie für Workloads, die konstante IOPS-Leistung benötigen, zu Speicher mit bereitgestellten IOPS wechseln.

Werden weniger als 100 GiB Allzweck-SSD-Speicher für Workloads zur Verfügung gestellt, die konsistente E/A-Leistung benötigen, führt dies möglicherweise zu größeren Latenzen, sobald das anfängliche E/A-Guthaben des Allzweck-SSD-Speichers aufgebraucht ist.

Anmerkung

Im Allgemeinen übersteigen die meisten Workloads nie das E/A-Guthaben.

Eine detailliertere Beschreibung, wie sich die Basisleistung und die E/A-Guthaben auf die Leistung auswirken, finden Sie unter Verstehen von Burst vs. Baseline Performance mit Amazon RDS und GP2.

Bereitgestellter IOPS SSD-Speicher

Für eine Produktionsanwendung, die eine schnelle und konsistente E/A-Leistung erfordert, empfehlen wir Speicher mit bereitgestellten IOPS (Input/Output Operations Per Second, Eingabe-/Ausgabevorgänge pro Sekunde). Ein Speicher mit bereitgestellten IOPS liefert voraussagbare Leistung und konsistente niedrige Latenz. Speicher mit bereitgestellten IOPS ist für Workloads bei der Online-Transaktionsverarbeitung (OLTP) optimiert, die konsistente Performance erfordern. Speicher mit bereitgestellten IOPS trägt zur Optimierung dieser Workloads bei.

Anmerkung

Ihr Datenbank-Workload kann die bereitgestellten IOPS möglicherweise nicht zu 100 Prozent erreichen. Weitere Informationen finden Sie unter Faktoren, die die Speicherleistung beeinflussen.

Wenn Sie eine DB-Instance erstellen, geben Sie die IOPS-Rate und die Größe des Volumes an. Das Verhältnis von IOPS zu zugewiesenem Speicher (in GiB) muss mindestens 0,5 betragen. Amazon RDS stellt diese IOPS-Rate für die DB-Instance bereit, bis Sie diese ändern.

Die folgende Tabelle zeigt den Bereich der bereitgestellten IOPS und den Bereich der Speichergröße für jede Datenbank-Engine.

Datenbank-Engine Bereitgestellte IOPS-Leistung Speicherplatzbereich

MariaDB

1.000–80.000 IOPS 100 GiB–64 TiB
SQL Server Enterprise-, Standard- und Web-Editionen 1000–64000 IOPS* 20 GiB–16 TiB
SQL Server Express Edition 1000–64000 IOPS* 100 GiB–16 TiB
MySQL 1.000–80.000 IOPS 100 GiB–64 TiB
Oracle 1.000–80.000 IOPS 100 GiB–64 TiB
PostgreSQL 1.000–80.000 IOPS 100 GiB–64 TiB

* Die maximalen IOPS von 64.000 werden nur für Nitro-basierte Instances garantiert, die sich auf den Instance-Typen m5, r5 und z1d befinden. Andere Instance-Familien garantieren eine Leistung von bis zu 32.000 IOPS. Weitere Informationen zur IOPS-Leistung der DB-Instance finden Sie unter Amazon EBS-optimierte Instances.

Kombinieren von bereitgestelltem IOPS-Speicher mit Multi-AZ-Bereitstellungen oder Lesereplikaten

Für OLTP-Anwendungsfälle in Produktionsumgebungen empfehlen wir die Verwendung von Multi-AZ-Bereitstellungen, da diese bei Speicher mit bereitgestellten IOPS, der schnelle und voraussagbare Leistung bereitstellt, eine erweiterte Fehlertoleranz bieten.

Sie können SSD-Speicher mit bereitgestellten IOPS auch mit Lesereplikaten für MySQL, MariaDB oder PostgreSQL verwenden. Der Speichertyp für ein Read Replica ist von der Speicherart der primärem DB-Instance unabhängig. Beispielsweise verwenden Sie ggf. eine Allzweck-SSD für Read Replicas mit einer primären DB-Instance, die SSD-Speicher mit bereitgestellten IOPS nutzt, um Kosten zu sparen. Die Leistung Ihres Read Replica kann in diesem Fall jedoch von der einer Konfiguration abweichen, wenn sowohl die primäre DB-Instance als auch die Read Replicas SSD-Speicher mit bereitgestellten IOPS verwenden.

Kosten für bereitgestellten IOPS-Speicher

Bei Speicher mit bereitgestellten IOPS werden Ihnen die bereitgestellten Ressourcen berechnet, auch wenn Sie diese während des jeweiligen Monats nicht genutzt haben.

Weitere Informationen zu Preisen finden Sie unter Amazon RDS-Preise.

Erzielen der besten Leistung mit Amazon RDS bereitgestelltem IOPS SSD-Speicher

Wenn die E/A Ihres Workload begrenzt ist, kann die Verwendung von SSD-Speicher mit bereitgestellten IOPS die Anzahl der gleichzeitig vom System verarbeiteten E/A-Anfragen erhöhen. Dadurch verringert sich die Latenz, da E/A-Anfragen weniger Zeit in der Warteschlange verbringen. Dadurch wiederum werden Datenbank-Commits beschleunigt, was die Reaktionszeit und den Datenbankdurchsatz verbessert.

SSD-Speicher mit bereitgestellten IOPS bietet die Möglichkeit, E/A-Kapazität durch das Angeben von IOPS zu reservieren. Der Maximaldurchsatz unter Last wird allerdings, wie alle anderen Systemkapazitätsattribute auch, durch diejenige Ressource begrenzt, die zuerst verbraucht wird. Dies kann entweder Netzwerkbandbreite, CPU, Arbeitsspeicher oder eine datenbankinterne Ressource sein.

Magnetfestplatten

Amazon RDS unterstützt außerdem aus Gründen der Rückwärtskompatibilität Magnetspeichergeräte. Wir empfehlen generell die Nutzung von Allzweck-SSD-Speicher oder SSD-Speicher mit bereitgestellten IOPS. Nachfolgend finden Sie einige Einschränkungen bei Magnetfestplatten:

  • Eine Speicherskalierung ist bei Verwendung der SQL Server-Datenbank-Engine nicht möglich.

  • Automatische Speicherskalierung wird nicht unterstützt.

  • Elastic Volumes werden nicht unterstützt.

  • Begrenzt auf eine Maximalgröße von 3 TiB.

  • Begrenzt auf eine Maximalgröße von 1.000 IOPS.

Überwachung der Speicherleistung

Amazon RDS bietet mehrere Metriken, mit deren Hilfe Sie die Leistung der DB-Instance ermitteln können. Sie können die Metriken auf der Übersichtsseite Ihrer Instance in der Amazon RDS Management Console anzeigen. Sie können auch Amazon CloudWatch zur Überwachung der Metriken verwenden. Weitere Informationen finden Sie unter Anzeigen von DB-Instance-Metriken. Erweiterte Überwachung bietet detailliertere E/A-Metriken. Weitere Informationen finden Sie unter Enhanced Monitoring (Erweiterte Überwachung).

Die folgenden Metriken sind für die Überwachung des Speichers Ihrer DB-Instance nützlich:

  • IOPS – die Anzahl der abgeschlossenen E/A-Vorgänge pro Sekunde. Diese Metrik gibt die durchschnittliche IOPS-Leistung für einen bestimmten Zeitraum an. Amazon RDS gibt Lese- und Schreib-IOPS separat für 1-minütige Intervalle an. Gesamt-IOPS ist die Summe der Lese- und Schreib-IOPS. Übliche Werte für IOPS liegen zwischen null und mehreren zehntausend pro Sekunde.

  • Latenz – die verstrichene Zeit zwischen der Übermittlung einer E/A-Anfrage und ihrer Ausführung. Diese Metrik gibt die durchschnittliche Latenz für einen bestimmten Zeitraum an. Amazon RDS gibt Lese- und Schreiblatenz separat für 1-minütige Intervalle in Sekunden an. Übliche Werte für die Latenz liegen im Millisekundenbereich (ms). So gibt Amazon RDS beispielsweise 2 ms als 0,002 Sekunden an.

  • Durchsatz – die Anzahl der Bytes, die pro Sekunde an die bzw. von der Festplatte übertragen werden. Diese Metrik gibt den durchschnittlichen Durchsatz für einen bestimmten Zeitraum an. Amazon RDS gibt Lese- und Schreibdurchsatz separat für 1-minütige Intervalle in Megabyte pro Sekunde (MB/s) an. Übliche Werte für den Durchsatz liegen zwischen null und der maximalen Bandbreite des E/A-Kanals.

  • Warteschlangentiefe – die Anzahl der E/A-Anfragen, die in der Warteschlange auf ihre Verarbeitung warten. Hierbei handelt es sich um E/A-Anfragen, die von der Anwendung übermittelt, aber noch nicht an das Gerät gesendet wurden, weil das Gerät mit anderen E/A-Anfragen beschäftigt ist. Zeit in der Warteschlange ist ein Teil der Latenz- und Verarbeitungszeit (nicht als Metrik verfügbar). Diese Metrik gibt die durchschnittliche Warteschlangentiefe für einen bestimmten Zeitraum an. Amazon RDS gibt die Warteschlangentiefe für 1-minütige Intervalle an. Übliche Werte für die Warteschlangentiefe liegen zwischen null und mehreren hundert.

Gemessene IOPS-Werte sind von der Größe der individuellen E/A-Operation unabhängig. Wenn Sie die E/A-Leistung messen, sollten Sie also auf den Durchsatz der Instance achten und nicht einfach auf die Anzahl der E/A-Operationen.

Faktoren, die die Speicherleistung beeinflussen

Die Speicherleistung kann von Systemaktivitäten und Datenbank-Workloads beeinflusst werden.

Systemaktivitäten

Die folgenden systembezogenen Aktivitäten verbrauchen E/A-Kapazität und verringern möglicherweise die Leistung der Datenbank-Instance, wenn sie ausgeführt werden:

  • Standby-Erstellung mit Multi-AZ

  • Read Replica-Erstellung

  • Ändern von Speichertypen

Datenbank-Workload

In einigen Fällen führt der Entwurf Ihrer Datenbank oder Anwendung zu Gleichzeitigkeitsproblemen, Sperren oder anderen Datenbankkonflikten. Dann können Sie die gesamte bereitgestellte Bandbreite möglicherweise nicht direkt nutzen. Außerdem kann es zu folgenden Situationen bezüglich des Workloads kommen:

  • Die Durchsatzgrenze des zugrunde liegenden Instance-Typs wird erreicht.

  • Die Tiefe der Warteschlange liegt konstant unter 1, da Ihre Anwendung nicht genug E/A-Operationen durchführen kann.

  • Sie bemerken auch bei noch ungenutzter E/A-Kapazität Abfragekonflikte in der Datenbank.

Wenn nicht mindestens eine Systemressource ausgelastet oder fast ausgelastet ist und das Hinzufügen weiterer Threads die Datenbanktransaktionsrate nicht erhöht, dann wird der Engpass höchstwahrscheinlich durch Konflikte in der Datenbank verursacht. Die verbreitetsten Formen sind Zeilensperr- und Indexseitensperrkonflikte, aber zahlreiche andere Möglichkeiten bestehen ebenso. Falls dies Ihre Situation beschreibt, sollten Sie den Rat eines Experten für die Optimierung der Datenbankleistung einholen.

DB-Instance-Klasse (DB instance class)

Um Ihre Amazon RDS-Datenbank-Instance optimal zu nutzen, sollten Sie einen aktuellen Instance-Typ mit ausreichend Bandbreite für Ihren Speichertyp verwenden. Sie können beispielsweise EBS-optimierte Instances und Instances mit einer Netzwerkkonnektivität in Höhe von 10 Gigabit nutzen.

Die vollständige Liste der Amazon EC2-Instance-Typen, die EBS-Optimierung unterstützen, finden Sie unter Instance-Typen, die EBS-Optimierung unterstützen.

Wir empfehlen Ihnen, Instances der aktuellen Generation zu verwenden, um die bestmögliche Leistung zu erhalten. DB-Instances der vorherigen Generationen haben eine niedrigere Instance-Speichergrenze. Die folgende Tabelle zeigt den maximalen Speicherplatz, auf den jede DB-Instance-Klasse für die einzelnen Datenbank-Engines skaliert werden kann. Alle Werte sind in Tebibyte (TiB) angegeben.

Instance class MariaDB Microsoft SQL Server MySQL Oracle PostgreSQL
db.m5 – Standard-Instance-Klassen der neuesten Generation
db.m5.24xlarge 64 16 64 64 64
db.m5.16xlarge 64 16 64 64 64
db.m5.12xlarge 64 16 64 64 64
db.m5.8xlarge 64 16 64 64 64
db.m5.4xlarge 64 16 64 64 64
db.m5.2xlarge 64 16 64 64 64
db.m5.xlarge 64 16 64 64 64
db.m5.large 64 16 64 64 64
db.m4: Standard-Instance-Klassen der aktuellen Generation
db.m4.16xlarge 64 16 64 64 64
db.m4.10xlarge 64 16 64 64 64
db.m4.4xlarge 64 16 64 64 64
db.m4.2xlarge 64 16 64 64 64
db.m4.xlarge 64 16 64 64 64
db.m4.large 64 16 64 64 64
db.m3: Standard-Instance-Klassen der vorherigen Generation
db.m3.2xlarge 6 16 6 6 6
db.m3.xlarge 6 16 6 6 6
db.m3.large 6 16 6 6 6
db.m3.medium 32 16 32 32 32
db.r5: Speicheroptimierte Instance-Klassen der neuesten Generation
db.r5.24xlarge 64 16 64 64 64
db.r5.16xlarge 64 16 64 64 64
db.r5.12xlarge 64 16 64 64 64
db.r5.8xlarge 64 16 64 64 64
db.r5.4xlarge 64 16 64 64 64
db.r5.2xlarge 64 16 64 64 64
db.r5.xlarge 64 16 64 64 64
db.r5.large 64 16 64 64 64
db.r4: Speicheroptimierte Instance-Klassen der aktuellen Generation
db.r4.16xlarge 64 16 64 64 64
db.r4.8xlarge 64 16 64 64 64
db.r4.4xlarge 64 16 64 64 64
db.r4.2xlarge 64 16 64 64 64
db.r4.xlarge 64 16 64 64 64
db.r4.large 64 16 64 64 64
db.r3: Speicheroptimierte Instance-Klassen der vorherigen Generation
db.r3.8xlarge 64 16 64 64 64
db.r3.4xlarge 64 16 64 64 64
db.r3.2xlarge 64 16 64 64 64
db.r3.xlarge 64 16 64 64 64
db.r3.large 64 16 64 64 64
db.t3 – Instance-Klassen mit Spitzenleistung der neuesten Generation
db.t3.2xlarge 16 16 16 64 64
db.t3.xlarge 16 16 16 64 64
db.t3.large 16 16 16 64 64
db.t3.medium 16 16 16 32 32
db.t3.small 16 16 16 32 16
db.t3.micro 16 16 16 32 16
db.t2: Burstable Performance Instance-Klassen der aktuellen Generation
db.t2.2xlarge 64 16 64 64 64
db.t2.xlarge 64 16 64 64 64
db.t2.large 64 16 64 64 64
db.t2.medium 32 16 32 32 32
db.t2.small 16 16 16 16 16
db.t2.micro 16 16 16 16 16
db.x1e: Speicheroptimierte Instance-Klassen der neuesten Generation
db.x1e.32xlarge 16 64
db.x1e.16xlarge 16 64
db.x1e.8xlarge 16 64
db.x1e.4xlarge 16 64
db.x1e.2xlarge 16 64
db.x1e.xlarge 16 64
db.x1: Speicheroptimierte Instance-Klassen der aktuellen Generation
db.x1.32xlarge 16 64
db.x1.16xlarge 16 64

Bei Oracle wird eine Skalierung auf bis zu 80.000 IOPS nur für die folgenden Instance-Klassen unterstützt.

  • db.m5.24xlarge

  • db.r5.24xlarge

  • db.x1.32xlarge

  • db.x1e.32xlarge

Weitere Informationen zu allen unterstützten Instance-Klassen finden Sie unter DB-Instances der vorherigen Generation.