RDS-Engines und Instance-Klassen

Amazon RDS unterstützt sechs Datenbank-Engines: MySQL, PostgreSQL, MariaDB, Oracle, Microsoft SQL Server und Amazon Aurora. Jede Engine ist eine vollständig verwaltete Version der Open-Source- oder kommerziellen Datenbank, mit der Sie bereits vertraut sind. AWS übernimmt Patching, Backups und Failover, sodass Sie sich auf die Logik Ihrer Anwendung konzentrieren können.

Die Wahl der richtigen Engine hängt von den Anforderungen Ihrer bestehenden Anwendung, den Lizenzkosten und den Funktionen der jeweiligen Engine ab. Aurora ist die cloudnative Option von AWS und wurde für hohe Leistung und Verfügbarkeit entwickelt.

MySQL ist die weltweit beliebteste relationale Open-Source-Datenbank und eignet sich besonders für Webanwendungen und CMS. PostgreSQL bietet eine fortschrittliche SQL-Konformität, leistungsfähige JSONB-Unterstützung und ein umfangreiches Ökosystem an Erweiterungen und ist daher bei Analyse- und Geodaten-Workloads beliebt.

Beide Engines unterstützen auf RDS automatisierte Backups, Multi-AZ-Bereitstellungen und Read Replicas. PostgreSQL Read Replicas können sich über mehrere Regionen erstrecken, während MySQL mit Aurora MySQL bis zu 15 regionenübergreifende Replikate unterstützt.

MariaDB ist ein von der Community entwickelter Fork von MySQL und auf Protokollebene vollständig mit MySQL-Clients kompatibel. Die Datenbank bietet zusätzliche Storage-Engines, in einigen Workloads eine bessere Leistung und ein offenes Entwicklungsmodell ohne proprietäre Funktionen.

Auf RDS ist MariaDB ein direkter Ersatz für MySQL, wenn Sie die MySQL-Lizenzierung von Oracle vermeiden möchten oder den Community-Fork bevorzugen. MariaDB unterstützt dieselben Funktionen für automatisierte Backups, Multi-AZ und Read Replicas wie MySQL.

Oracle Database auf RDS unterstützt sowohl die Modelle License Included (LI) als auch Bring Your Own License (BYOL). Bei LI ist die Oracle-SE2-Lizenz im Stundenpreis enthalten, während Sie bei BYOL Ihre bestehende Enterprise-Edition-Lizenz für Funktionen wie Partitionierung und Advanced Security verwenden können.

Microsoft SQL Server auf RDS bietet ebenfalls LI-Editionen (Express, Web, Standard, Enterprise) und BYOL. Beide Engines unterstützen Multi-AZ mit synchroner Spiegelung, jedoch keine Read Replicas auf dieselbe Weise wie Open-Source-Engines.

Amazon Aurora ist eine cloudnative relationale Datenbank, die mit MySQL und PostgreSQL kompatibel ist. Aurora erreicht auf derselben Hardware bis zu das 5-Fache des MySQL-Durchsatzes und das 3-Fache des PostgreSQL-Durchsatzes, indem eine verteilte Storage-Ebene verwendet wird, die Daten automatisch sechsmal über drei Availability Zones repliziert.

Der Storage von Aurora wächst automatisch in Schritten von 10 GB bis auf 128 TiB, sodass keine manuelle Bereitstellung von Storage erforderlich ist. Durch die Trennung von Rechenleistung und Storage kann Aurora Serverless die Kapazität außerdem automatisch nach oben und unten skalieren.

RDS-Instance-Klassen folgen derselben Benennungskonvention wie EC2, erhalten jedoch das Präfix db. anstelle des reinen Familienbuchstabens. Die wichtigsten Familien sind:

• db.t — Burst-fähige Leistung, kostengünstig für Entwicklung und Tests (z. B. db.t3.micro, db.t4g.small)
• db.m — Universeller Einsatz, ausgewogenes Verhältnis von CPU und Arbeitsspeicher (z. B. db.m6g.large)
• db.r — Für viel Arbeitsspeicher optimiert, für große Caches und In-Memory-Tabellen (z. B. db.r6g.xlarge)
• db.x — Extrem viel Arbeitsspeicher für Oracle und SQL Server mit SAP-Workloads

Wählen Sie db.t für die Entwicklung, db.m für typische Produktionsumgebungen und db.r für Datenbanken mit großen Working Sets.

Für die Auswahl einer RDS-Instance-Klasse müssen Sie die CPU-Auslastung, den Arbeitsspeicherverbrauch, den IOPS-Bedarf und die Netzwerkbandbreite Ihres Workloads analysieren. AWS Compute Optimizer und das Tool RDS Performance Insights helfen Ihnen festzustellen, ob Ihre aktuelle Instance über- oder unterdimensioniert ist.

Ein übliches Vorgehen besteht darin, für die Erstellung eines Prototyps mit einer db.t3 zu beginnen, bei gleichmäßiger Auslastung auf db.m6g umzusteigen und zu db.r6g zu wechseln, sobald Abfragen von einem größeren Buffer Pool profitieren. Auf Graviton2 basierende Instances (db.m6g, db.r6g) bieten typischerweise ein bis zu 35 % besseres Preis-Leistungs-Verhältnis als vergleichbare x86-Instances.

RDS bietet drei Storage-Typen, die im Hintergrund EBS-Volumes zugeordnet werden:

• gp2 / gp3 — SSD für allgemeine Zwecke; mit gp3 können Sie IOPS und Durchsatz unabhängig voneinander bereitstellen, ohne für zusätzlichen Storage zu bezahlen
• io1 / io2 — SSD mit bereitgestellten IOPS für latenzempfindliche OLTP-Datenbanken, die eine konstante Antwortzeit im Submillisekundenbereich benötigen
• st1 — HDD mit für den Durchsatz optimierter Leistung, nur für bestimmte Engines und Test-Workloads verfügbar

Für die meisten RDS-Produktionsbereitstellungen ist gp3 die empfohlene Standardeinstellung, da es 3.000 IOPS ohne zusätzliche Kosten bietet und unabhängig von der Storage-Größe skaliert werden kann.

RDS unterstützt zwei Skalierungsdimensionen. Für die vertikale Skalierung (Änderung der Instance-Klasse) ist ein kurzes Wartungsfenster mit Ausfall erforderlich, sofern Multi-AZ nicht aktiviert ist – mit Multi-AZ ermöglicht das Failover während der Größenänderung nahezu keine Ausfallzeit. Sie können die Änderung für das nächste Wartungsfenster planen oder sofort anwenden.

Die horizontale Skalierung ist schreibgeschützt: Sie fügen Read Replicas hinzu, um SELECT-Abfragen von der primären Instance wegzuverteilen. Read Replicas verwenden asynchrone Replikation, sodass eine geringe Replikationsverzögerung auftritt, die Ihre Anwendung tolerieren muss.

Berücksichtigen Sie bei der Wahl zwischen Aurora und MySQL/PostgreSQL aus der Community die folgenden Vor- und Nachteile:

• Aurora: höherer Durchsatz, automatische sechsfache Replikation, schnelles Failover (ca. 30 s), keine manuelle Verwaltung des Storage, höhere Kosten pro Stunde
• MySQL/PostgreSQL: niedrigere Kosten, umfangreicheres Community-Ökosystem für Erweiterungen, BYOL-Option, vertraute Tools für den Betrieb

In Prüfungsszenarien wird Aurora bevorzugt, wenn die Frage hohe Verfügbarkeit, automatisches Wachstum des Storage oder eine Leistung nahe der kommerzieller Datenbanken zum Preis von Open-Source-Datenbanken hervorhebt. Community-Engines sind die bessere Wahl, wenn Kostenminimierung oder Funktionsparität mit On-Premises-Systemen Priorität hat.

RDS unterscheidet zwischen Upgrades auf eine Nebenversion (z. B. MySQL 8.0.32 → 8.0.36) und Upgrades auf eine Hauptversion (z. B. MySQL 5.7 → 8.0). Upgrades auf Nebenversionen können durch Aktivieren von --auto-minor-version-upgrade so eingestellt werden, dass sie automatisch während des Wartungsfensters angewendet werden. Upgrades auf Hauptversionen erfolgen manuell und erfordern möglicherweise Kompatibilitätstests der Anwendung.

Testen Sie Upgrades auf Hauptversionen immer zuerst in einer Staging-Umgebung. Vor dem Upgrade können Sie einen DB-Snapshot erstellen, um bei auftretenden Problemen ein Rollback durchzuführen. Aurora-Cluster unterstützen Upgrades auf Hauptversionen direkt im laufenden Betrieb mit minimaler Beeinträchtigung.

Testen Sie Ihr Verständnis der Konzepte aus dieser Lektion für AWS Solutions Architect (SAA-C03).

In dieser Lektion haben Sie gelernt: RDS unterstützt sechs Engines (MySQL, PostgreSQL, MariaDB, Oracle, SQL Server, Aurora), Instance-Klassen entsprechen unterschiedlichen Workload-Profilen (db.t für Entwicklung und Tests, db.m für allgemeine Zwecke, db.r für speicherintensive Workloads) und Aurora bietet im Vergleich zu Community-Engines einen höheren Durchsatz und eine automatische Storage-Skalierung. Als Nächstes beschäftigen wir uns mit Multi-AZ-Bereitstellungen und automatisierten Backups für hohe Verfügbarkeit.