Amazon RDS Instance Types bestimmen Compute, Memory, Netzwerk und (indirekt) Storage-Performance Ihrer Datenbank – und zählen damit zu den größten Stellschrauben für Zuverlässigkeit und Kosten. Wer klug wählt, bekommt planbare Performance zu einem effizienten Preis. Wer falsch wählt, zahlt für ungenutzte Kapazität – oder kämpft mit Latenzen, Timeouts und unsauberen Failovers.
Amazon RDS Instance Types: die Kurzfassung
Amazon RDS Instance Types sind vorkonfigurierte Compute-Profile (vCPU, Memory, Netzwerk) für den Betrieb einer RDS-Datenbank. Nehmen Sie db.m für ausgewogene workloads, db.r für speicherintensive Datenbanken und hohe Parallelität sowie db.t für Dev/Test oder schwankende Nutzung. Kombinieren Sie die Instance mit dem passenden Storage (meist gp3 oder io2) und prüfen Sie die Auslastung quartalsweise, um sie laufend richtig zu dimensionieren.
Das erwartet Sie
- Die wichtigsten RDS-Instance-Klassen und wofür sie sich am besten eignen
- Wie Sie einen Instance Type anhand von 5 praxisnahen Entscheidungsfaktoren auswählen
- Wie sich Storage-Optionen (gp3, gp2, io1/io2) auf die reale Performance auswirken
- Häufige Fehler, die RDS-Kosten in die Höhe treiben (und wie Sie sie vermeiden)
- FAQ-Antworten für AEO und Featured Snippets
Umfassender Leitfaden zu Amazon RDS Instance Types
Cloud-Datenbanken zu betreiben ist eine Herausforderung, die jedes wachsende Unternehmen kennt. Ob Start-up oder Fortune-500-Konzern – immer wieder stellt sich dieselbe Frage: Wie erreichen Sie die nötige Performance, ohne Ihr Budget zu sprengen? Die Antwort liegt meistens in klugen Entscheidungen rund um Ihre Datenbank-Instances – Entscheidungen mit spürbarer Wirkung auf Ihr Ergebnis.
Die richtige Datenbank-Infrastruktur entscheidet über Performance und Wirtschaftlichkeit Ihrer Anwendung. Ein Beispiel: Ein E-Commerce-Unternehmen betrieb seine Produktkatalog-Datenbank lange auf einer überdimensionierten RDS-Instance und gab monatlich mehr als 5.000 US-Dollar für Ressourcen aus, die kaum genutzt wurden. Mit dem Wechsel auf einen passend dimensionierten Instance Type sanken die Kosten um 60 % – ohne Performance-Einbußen.
Dieses Beispiel zeigt eine typische Herausforderung: die richtige Balance zwischen Performance und Kosten. Mit dem passenden Vorgehen unterstützt Ihre Datenbank-Infrastruktur Ihre Anforderungen zuverlässig, ohne unnötige Ausgaben.
Amazon Relational Database Service (RDS) bietet eine breite Palette an Instance Types, jeweils zugeschnitten auf unterschiedliche workloads und Anforderungen. Stellen Sie sich Instance Types wie verschiedene Fahrzeugtypen vor: Ein Kleinwagen ist ideal für die Stadt, für schwere Lasten brauchen Sie einen LKW. Genauso kann eine burstable db.t3.medium perfekt für eine Entwicklungsumgebung sein, während Ihre Produktions-Analytics-Datenbank vielleicht eine speicheroptimierte db.r6g.2xlarge für anspruchsvolle Aufgaben benötigt.
Die eigentliche Hürde liegt für viele Organisationen nicht in der initialen Auswahl, sondern darin, den Instance Type laufend an die Entwicklung der workloads anzupassen. Genau deshalb lohnt es sich, die verschiedenen RDS Instance Types gut zu kennen. Die richtige Wahl steigert die Performance Ihrer Anwendung und hält die Kosten im Griff.
Einführung in Amazon RDS
Amazon RDS ist ein verwalteter Datenbankdienst, der Routineaufgaben rund um die Datenbank übernimmt und gleichzeitig die Flexibilität bietet, Ihre Umgebung gezielt für die jeweilige Workload zu optimieren.
Welcher Datenbank-Instance-Type der richtige ist, hängt vor allem von Ihrer Workload ab. Speicheroptimierte Instances eignen sich hervorragend für transaktionsintensive Aufgaben oder Analytics, während General-Purpose-Instances besser zu leseintensiven Anwendungen oder gleichmäßigem Traffic passen. Burstable Instances sind ideal für Entwicklung und Tests mit unvorhersehbaren workloads. Der gewählte Instance Type wirkt sich direkt auf Performance und Kosten Ihrer Datenbank aus.
Im Kern bestimmen Performance und Kosten Ihrer Datenbank maßgeblich vom gewählten Instance Type ab – also den Compute- und Memory-Ressourcen, die Ihre Datenbank nutzt. RDS automatisiert viele kritische Verwaltungsaufgaben, darunter:
- Automatisierte Backups mit Point-in-Time-Recovery (Aufbewahrung bis zu 35 Tage)
- Patching von Betriebssystem und Datenbank-Engine mit konfigurierbaren Wartungsfenstern
- Hohe Verfügbarkeit durch automatisches Failover bei Multi-AZ-Deployments (in der Regel innerhalb von 60 bis 120 Sekunden, abhängig von Faktoren wie Datenbankgröße und Workload)
- Verwaltung von Datenbank-Logrotation und -aufbewahrung
- Automatisiertes Snapshot-Management für die langfristige Aufbewahrung
Die eigentliche Hürde liegt für viele Organisationen nicht in der Auswahl des Instance Type, sondern darin, ihn auch dann optimal zu halten, wenn sich workloads im Lauf der Zeit ändern. Datenbank-Instances sind oft entweder über- oder unterdimensioniert – das bedeutet entweder verschwendetes Budget oder Performance-Probleme. Diese Diskrepanz zwischen Ressourcen und tatsächlichem Bedarf ist besonders typisch für wachsende Unternehmen, in denen sich die Anforderungen schnell ändern. Deshalb sind FinOps Best Practices wie regelmäßiges Monitoring und Optimierung (eine Spezialität von DoiT) der Schlüssel zur richtigen Balance zwischen Performance und Kosten.
Den passenden RDS Instance Type wählen (Schnell-Checkliste)
- Messen: CPU, Memory, Read/Write-IOPS, Storage-Latenz, Verbindungen und Query-Zeit.
- Klasse zuordnen: db.m (ausgewogen), db.r (Memory/Parallelität), db.t (burstable/Dev-Test).
- Storage validieren: gp3 für die meisten Fälle; io2 für dauerhaft niedrige Latenzen bei transaktionalen Anforderungen.
- Verfügbarkeit planen: Multi-AZ, wenn Ausfälle nicht akzeptabel sind; Failover-Verhalten testen.
- Quartalsweise prüfen: Right-Sizing, sobald sich Traffic und Query-Muster ändern.
RDS-Instance-Klassen verstehen
RDS-DB-Instance-Klassen werden nach ihren Compute- und Memory-Eigenschaften kategorisiert; jede Klasse ist auf bestimmte Performance-Profile zugeschnitten. Jede Instance-Familie ist durch ein Präfix gekennzeichnet, das ihre Kategorie beschreibt:
- db.m: Ausgewogene Allzweck-Instances mit einer guten Mischung aus Compute, Memory und Netzwerk. Ideal für transaktionale Anwendungen, Blogs oder Content-Management-Systeme. Wenn Sie mehr Lese-Performance brauchen, verteilen Read Replicas die Last.
- db.r: Speicheroptimierte Instances für Anwendungen mit intensiver In-Memory-Verarbeitung. Sie eignen sich hervorragend für transaktionsstarke workloads und viele gleichzeitige Verbindungen, etwa E-Commerce-Plattformen, Buchungssysteme oder datenintensive Anwendungen.
- db.t: Burstable Performance-Instances – ideal für Entwicklung, Tests oder workloads mit gelegentlichen Lastspitzen. Eine kostengünstige Option, die bei Bedarf zusätzliche Compute-Leistung freisetzt.
- db.x1/x2: High-Memory-Instances für spezialisierte workloads mit sehr hohem RAM-Bedarf.
Jede Instance-Klasse gibt es in mehreren Generationen (gekennzeichnet durch eine Zahl, z. B. m5 vs. m6) und in verschiedenen Größen (mit Suffixen wie large, xlarge, 2xlarge). Die richtige Auswahl bedeutet, Compute-Leistung, Memory und Netzwerk-Performance optimal auf Ihre Workload abzustimmen.
Storage-Überlegungen für RDS
Bei der Wahl des Instance Type sollten Sie die Storage-Performance nicht unterschätzen – sie ist genauso entscheidend. RDS bietet mehrere Storage-Optionen für unterschiedliche Workload-Anforderungen:
- GP3 (General Purpose SSD v3): Eine kosteneffiziente SSD-Option mit konfigurierbaren IOPS und Durchsatz – mit besserer Performance als GP2.
- GP2 (General Purpose SSD v2): Eine ältere, allgemein einsetzbare SSD, deren Performance mit der Speichergröße skaliert.
- Provisioned IOPS (io1/io2): Hochleistungs-Storage für Datenbanken mit niedrigen Latenzanforderungen und hohem Transaktionsaufkommen.
Die richtige Kombination aus Instance-Klasse und Storage ist entscheidend, damit Ihre Datenbank effizient, kostengünstig und skalierbar läuft. Ein Vergleich der Storage-Optionen GP3, GP2 und Provisioned IOPS hilft Ihnen, die passende Konfiguration fundiert auszuwählen.
Kategorien von RDS Instance Types
Amazon RDS Flussdiagramm
RDS Instance Types lassen sich anhand ihrer Eigenschaften und empfohlenen Einsatzgebiete in mehrere Gruppen einteilen:
General-Purpose-Instances
General-Purpose-Instances (db.m-Klassen) sind die Arbeitstiere von AWS RDS. Sie passen zu einer breiten Palette an Anwendungen und bieten ausgewogene Performance über Compute, Memory und Netzwerk hinweg. Sie eignen sich ideal für:
- Mittelgroße Datenbanken
- Entwicklungs- und Testumgebungen
- Content-Management-Systeme
- E-Commerce-Anwendungen
Aktuelle Generationen wie db.m6g (mit AWS-Graviton2-Prozessoren) bieten bis zu 40 % besseres Preis-Leistungs-Verhältnis im Vergleich zu db.m5.
Memory-optimierte Instances
Memory-optimierte Instances (db.r-Klassen) sind für speicherintensive Datenbank-workloads mit hohem Memory-zu-vCPU-Verhältnis ausgelegt. Sie zeigen ihre Stärken bei:
- Hochleistungs-Datenbanken
- Echtzeit-Big-Data-Analytics
- Großen In-Memory-Caches
- Anwendungen mit komplexen Queries
Die neuesten db.r6g-Instances bieten bis zu 512 GiB Memory – perfekt für Anwendungen, die große Datensätze im Arbeitsspeicher verarbeiten.
Burstable Performance-Instances
Burstable Performance-Instances (db.t-Klassen) sind eine kosteneffiziente Wahl für Anwendungen mit variablen workloads. Sie bieten:
- Baseline-Performance mit der Möglichkeit, kurzfristig zu "bursten"
- CPU-Credits, die in ruhigen Phasen anwachsen
- Unterstützung für Entwicklung, Staging und kleine Produktionsdatenbanken
Detaillierter Vergleich der RDS Instance Types
Sehen wir uns die wichtigsten Unterschiede zwischen den Instance Types an, um Ihre Auswahl zu erleichtern:
Vergleich der Amazon RDS Instance Types
Instance-Klasse
Anwendungsfall
vCPU
Memory (GiB)
Netzwerk-Performance
db.m6g
Standard-Webanwendungen, CMS-Systeme, E-Commerce
1–64
4–256
Bis zu 25 Gbps
db.m5
Anwendungen für kleine bis mittelständische Unternehmen
2–96
8–384
Bis zu 25 Gbps
db.r6g
Business-Intelligence-Tools, In-Memory-Analytics
2–64
16–512
Bis zu 25 Gbps
db.r5
Hochleistungs-Datenbanken, Enterprise Data Warehouses, Echtzeit-Analytics-Plattformen
2–96
16–768
Bis zu 25 Gbps
db.t4g
Entwicklungs- und Testumgebungen, Code-Repositories
2–8
1–32
Bis zu 5 Gbps
db.t3
Blogs mit wenig Traffic, kleine WordPress-Seiten
2–8
1–32
Bis zu 5 Gbps
Der Vergleich zeigt die Bandbreite der verfügbaren Optionen – von kleinen burstable Instances für Entwicklungsumgebungen bis zu großen, speicheroptimierten Instances für Enterprise-workloads. Instance Types entwickeln sich kontinuierlich weiter; neue Generationen bieten bessere Performance und höhere Effizienz, etwa solche mit AWS-Graviton-Prozessoren.
5 zentrale Faktoren bei der Wahl eines RDS Instance Type
Den richtigen Amazon RDS Instance Type zu wählen, setzt einen genauen Blick auf die Anforderungen Ihrer Anwendung voraus. So finden Sie das beste Verhältnis aus Performance, Kosteneinsparungen und Skalierbarkeit. Diese Punkte sollten Sie berücksichtigen.
1. Anforderungen der Workload
Das Verständnis Ihrer Workload ist die Grundlage jeder Instance-Type-Auswahl. Eine stark frequentierte E-Commerce-Plattform mit Tausenden Transaktionen pro Minute hat ganz andere Anforderungen als eine interne Reporting-Datenbank, die nachts Batch-Jobs verarbeitet. Berücksichtigen Sie diese Workload-Eigenschaften:
- Komplexität und Häufigkeit von Queries
- Spitzenlast vs. durchschnittliche Auslastung
- Anzahl gleichzeitiger User-Verbindungen
- Read/Write-Verhältnis der Datenbankoperationen
- Anforderungen an die Datenverarbeitung (OLTP vs. OLAP)
2. Performance vs. Kosten
Jede Organisation muss Performance-Anforderungen gegen Budgetgrenzen abwägen. Der leistungsstärkste Instance Type ist nicht automatisch die beste Wahl – entscheidend ist der Sweet Spot zwischen Performance und Effizienz. Wichtige Aspekte:
- CPU-Auslastungsmuster im Tagesverlauf
- Memory-Anforderungen Ihrer spezifischen Datenbank-Engine
- I/O-Anforderungen und Storage-Durchsatz
- Budgetgrenzen und Optimierungspotenziale
Wenn Ihre Anwendung beispielsweise vor allem Leseoperationen mit gelegentlichen Schreibzugriffen verarbeitet, profitieren Sie eher von einer speicheroptimierten Instance, die Ihren Datensatz effektiv im Cache halten kann, als von einer Compute-optimierten Variante.
Hinweis: Bei konstanter und vorhersehbarer Nutzung sind Reserved Instances (RIs) eine hervorragende Sparoption. Sie bieten Rabatte gegenüber On-Demand-Preisen und sind damit ein starker Kostensenker für Amazon RDS. Für unvorhersehbare Nutzungsmuster ist Amazon Aurora Serverless eine flexible Option, die je nach Bedarf skaliert.
Diagramm zu Amazon Aurora Serverless
3. Anforderungen an die Skalierbarkeit
Mit Ihrem Unternehmen wachsen auch die Anforderungen an Ihre Datenbank. Wer Skalierbarkeit von Anfang an mitdenkt, stellt sicher, dass der gewählte Instance Type dieses Wachstum ohne ständige Anpassungen mitträgt. Beachten Sie diese Skalierungsfaktoren:
- Prognostizierte Datenwachstumsraten
- Saisonale Traffic-Schwankungen
- Wartungsfenster und Backup-Anforderungen
- Multi-AZ-Deployment für hohe Verfügbarkeit
Entscheidend ist, einen Instance Type zu wählen, der nicht nur Ihren aktuellen Bedarf deckt, sondern auch Spielraum für Wachstum bietet – ohne übermäßiges Overprovisioning.
4. Kompatibilität mit der Datenbank-Engine
Datenbank-Engines wie MySQL, PostgreSQL, Oracle oder SQL Server nutzen Ressourcen unterschiedlich und haben jeweils eigene Anforderungen. Ein Instance Type, der für MySQL perfekt ist, muss für SQL Server nicht ebenso gut funktionieren. Wichtige Punkte:
- Engine-spezifische Memory-Anforderungen
- Versionskompatibilität mit Instance Types
- Feature-Unterstützung über verschiedene Instance-Familien hinweg
- Engine-spezifische Optimierungsmöglichkeiten
PostgreSQL profitiert beispielsweise dank seines Buffer-Managements oft von speicheroptimierten Instances, während MySQL bei vergleichbaren workloads häufig auch mit General-Purpose-Instances gute Ergebnisse liefert.
5. Compliance und Sicherheit
Compliance- und Sicherheitsanforderungen können bei der Wahl des Instance Type eine große Rolle spielen – besonders in regulierten Branchen wie Gesundheitswesen oder Finanzen. Wichtige Faktoren:
- Anforderungen an den Datenschutz
- Performance-Monitoring und Auditing
- Backup- und Recovery-Funktionen
- Geografische Beschränkungen und Anforderungen an die Datenresidenz
Wenn Ihre Compliance-Vorgaben beispielsweise Verschlüsselung im Ruhezustand bei gleichzeitig hoher Performance vorschreiben, brauchen Sie einen Instance Type, der den zusätzlichen Rechenaufwand verkraftet, ohne dass die Anwendungs-Performance leidet. Eine sichere RDS-Architektur – etwa der Wechsel von öffentlichen zu isolierten Subnetzen – kann ebenfalls ein Schritt zur Erfüllung von Compliance-Vorgaben sein.
All diese Faktoren wirken bei der Wahl des passenden Instance Type zusammen – betrachten Sie sie ganzheitlich, nicht isoliert. Bei DoiT analysieren wir diese Aspekte gemeinsam mit unseren Kunden über Cloud Analytics. So treffen sie fundierte, datenbasierte Entscheidungen für ihre RDS-Umgebung – häufig mit deutlichen Kosteneinsparungen bei gleichbleibend starker Performance.
5 Best Practices für die Auswahl von RDS-Instances
Die Wahl der richtigen RDS-Instance kann angesichts der vielen Faktoren und workloads schnell unübersichtlich werden. Damit Sie den Überblick behalten, haben wir die wichtigsten Best Practices zusammengestellt:
1. Performance-Tests
Gründliche Performance-Tests sind unverzichtbar, bevor Sie sich produktiv für einen Instance Type entscheiden. Ein umfassender Testansatz sollte Folgendes umfassen:
- Lasttests mit produktionsähnlichen workloads und Datenmengen
- Performance-Benchmarks über verschiedene Instance Types hinweg
- Tests in Spitzenlastszenarien
- Validierung von Backup- und Wartungsoperationen
2. Monitoring und Optimierung
Effektives Monitoring geht weit über das bloße Beobachten der CPU-Auslastung hinaus. Setzen Sie diese Praktiken um:
- Verfolgen Sie zentrale Performance-Metriken, einschließlich CPU-Auslastungsmuster:
- Memory-Nutzung und Swap-Aktivität
- I/O-Operationen und Latenz
- Verbindungszahlen und Query-Performance
- Richten Sie proaktive Alerts für Performance-Schwellenwerte ein
- Nutzen Sie DoiT Cloud Analytics für tiefe Einblicke in Kosten und Nutzung
- Prüfen Sie regelmäßig Slow-Query-Logs und Query-Muster
3. Kostenmanagement
Kostenoptimierung ist ein laufender Prozess, der sowohl kurzfristige als auch langfristige Ausgaben im Blick behalten muss. Eine durchdachte Strategie sollte enthalten:
- Strategischen Einsatz von AWS Reserved Instances für planbare workloads
- Automatische Skalierungsrichtlinien für variable Lasten
- Regelmäßige Right-Sizing-Reviews auf Basis von Auslastungsdaten
- Kostenallokation über unterschiedliche Umgebungen hinweg
DoiT Flexsave für AWS unterstützt Sie dabei, indem es Instance-Commitments intelligent steuert und Sparpotenziale identifiziert – ohne Performance-Einbußen.
4. Kapazitätsplanung
Eine durchdachte Kapazitätsplanung verhindert Overprovisioning und Performance-Probleme. Ein disziplinierter Ansatz sollte umfassen:
- Klare Wachstumsprognosen auf Basis historischer Datenmuster:
- Geschäftliche Expansionspläne
- Saisonale Schwankungen
- Geografische Expansionsziele
- Planung für Multi-Region-Szenarien, falls relevant
- Berücksichtigung von Backup- und Wartungs-Overhead
- Pufferkapazität für unerwartete Spitzen einplanen
5. Regelmäßige Reviews und Optimierung
Mit dem Wachstum Ihres Unternehmens ändern sich auch Ihre Datenbankanforderungen – regelmäßige Reviews und Optimierungen sind daher Pflicht. So behalten Sie den Überblick:
- Planen Sie quartalsweise Performance- und Kosten-Reviews
- Analysieren Sie Trends in der Ressourcennutzung:
- Query-Muster
- Kosten pro Transaktion
- Performance-Metriken
- Passen Sie Instance Types an veränderte Anforderungen an
- Dokumentieren Sie Optimierungsentscheidungen und deren Ergebnisse
Ein Review mit Python kann etwa zeigen, dass Ihre Entwicklungsumgebungen außerhalb der Geschäftszeiten überdimensioniert laufen – ein guter Anlass für automatisches Skalieren oder Instance-Scheduling.
Denken Sie daran: Optimierung ist ein iterativer Prozess. Was heute funktioniert, ist in sechs Monaten möglicherweise nicht mehr optimal, weil sich Ihre workloads weiterentwickeln. Die Cloud-Experten von DoiT helfen Ihnen, eine Optimierungsstrategie aufzubauen und kontinuierlich weiterzuentwickeln, während Ihr Cloud-Footprint wächst.
Optimieren Sie Ihre Kosten mit DoiT
Den richtigen RDS Instance Type zu wählen, ist erst der Anfang. Um Ihre Datenbankkosten wirklich zu optimieren und gleichzeitig die Performance hoch zu halten, brauchen Sie kontinuierliches Monitoring und Optimierung. DoiT Cloud Intelligence™ bietet:
- Flexsave: Automatisierte RDS-Kostenoptimierung durch intelligentes Management von Instance-Commitments
- Cloud Analytics: Tiefe Einblicke in Datenbanknutzung und Kostenmuster
- Expertensupport: Zugriff auf Datenbank-Spezialisten, die Ihr RDS-Deployment optimieren
- Automatisiertes Monitoring: Proaktive Alerts und Empfehlungen für Optimierungspotenziale
Wer RDS Instance Types versteht, kann eine Datenbankumgebung aufbauen, die effizient und kosteneffektiv zugleich ist. Ob Sie neu mit RDS starten oder bestehende Deployments feinjustieren möchten – DoiT Cloud Intelligence hilft Ihnen, Kosten zu senken und gleichzeitig die Performance auf Top-Niveau zu halten. Kontaktieren Sie uns noch heute und reduzieren Sie Ihre Cloud-Kosten.
Häufige Fragen zu Amazon RDS Instance Types
Was sind Amazon RDS Instance Types?
Amazon RDS Instance Types sind vordefinierte Compute-Konfigurationen (vCPU, Memory und Netzwerk-Performance), auf denen Ihre verwaltete Datenbank läuft. Sie wählen einen Instance Type passend zu Ihrer Workload und kombinieren ihn mit einer geeigneten Storage-Option (gp3, gp2, io1/io2).
Was ist der Unterschied zwischen db.m, db.r und db.t?
db.m ist ausgewogen für allgemeine workloads, db.r ist speicheroptimiert für hohe Parallelität und In-Memory-Verarbeitung, und db.t ist burstable für Dev/Test oder workloads mit niedriger Grundlast und gelegentlichen Spitzen.
Welcher RDS Instance Type eignet sich am besten für PostgreSQL?
Für viele PostgreSQL-workloads ist db.m ein solider Standard für ausgewogene Nutzung, während db.r bei hoher Parallelität oder speicherintensivem Caching oft besser abschneidet. Die beste Wahl hängt von Query-Mustern, Verbindungen und Cache-Verhalten ab.
Woran erkenne ich, dass meine RDS-Instance überdimensioniert ist?
Typische Anzeichen sind dauerhaft niedrige CPU-Auslastung, geringer Memory-Druck, konstant niedrige IOPS und stabile Verbindungszahlen – kombiniert mit hohen Monatskosten. Validieren Sie diese Hinweise vor einem Downsizing mit CloudWatch-Metriken, Query-Performance und Storage-Latenz.
Ist gp3 besser als gp2 für RDS?
In vielen Fällen ja. Mit gp3 können Sie IOPS und Durchsatz unabhängig von der Speichergröße provisionieren, was Performance-Planbarkeit und Kosteneffizienz im Vergleich zu gp2 häufig verbessert.
Wann sollte ich Provisioned IOPS (io1/io2) einsetzen?
Setzen Sie io1/io2 ein, wenn Sie dauerhaft hohe IOPS und niedrige Latenzen für transaktionale workloads benötigen oder wenn die Storage-Performance ein bekannter Engpass ist. Besonders wertvoll, wenn gp3 Ihre Anforderungen an Latenz oder Durchsatz nicht erfüllen kann.
Wie oft sollte ich RDS-Instances einem Right-Sizing unterziehen?
Eine gute Baseline ist quartalsweise, ergänzt um Reviews nach größeren Produkt-Launches, Traffic-Verschiebungen, Schema-Änderungen oder Veränderungen bei den Query-Mustern. Right-Sizing sollte ein laufender Prozess sein, der mit Ihren workloads mitwächst.