Versteckte Kosten von RDS und Alternativen

Die strategischen Gründe für den Einsatz von Amazon RDS liegen vor allem in der Maximierung der betrieblichen Effizienz, der Minderung systemischer Infrastrukturrisiken und der Beschleunigung der Entwicklungsgeschwindigkeit. Bei einer herkömmlichen, selbstverwalteten Datenbankarchitektur, die auf reinen Recheninstanzen oder lokaler Hardware gehostet wird, tragen Unternehmen die volle und uneingeschränkte Verantwortung für die Gewährleistung der Hochverfügbarkeit, die Konfiguration der Point-in-Time-Wiederherstellung, die Absicherung des Betriebssystems und die manuelle Skalierung von Speichervolumen. Amazon RDS beseitigt diese manuellen Aufgaben systematisch durch hochgradig koordinierte Automatisierung.

Hohe Verfügbarkeit ist wohl das überzeugendste Merkmal, das die Einführung in Unternehmen vorantreibt. Dies wird durch die Multi-AZ-Bereitstellungsoption erreicht, die automatisch eine synchrone Standby-Replik der Datenbank in einer geografisch getrennten Verfügbarkeitszone innerhalb derselben AWS-Region bereitstellt und verwaltet. Im Falle eines Infrastrukturausfalls, einer Speicherbeeinträchtigung oder einer Netzwerkisolierung, die den Primärknoten betrifft, erkennt die Steuerungsebene die Anomalie und leitet eine automatische Failover-Sequenz ein. Diese Koordination leitet die Datenbankverbindungen der Anwendung auf die Standby-Instanz um, wodurch der Dienst in der Regel mit minimaler Unterbrechung wiederhergestellt wird und sichergestellt wird, dass strenge Recovery Time Objectives (RTOs) und Recovery Point Objectives (RPOs) ohne menschliches Eingreifen eingehalten werden.

Für Anwendungen, die sich durch ein hohes Verhältnis von Lese- zu Schreibvorgängen auszeichnen, ermöglicht der Dienst die Erstellung von Lese-Replikaten. Diese Funktion nutzt asynchrone Replikation, um Daten vom Primärknoten auf mehrere zusätzliche Instanzen zu kopieren, wodurch Architekten leseintensive Abfrage- und Analyse-Workloads von der primären Transaktionsdatenbank auslagern können. Diese Fähigkeit zur horizontalen Skalierung ist entscheidend für kundenorientierte Anwendungen, bei denen es zu plötzlichen Traffic-Spitzen kommt.

Darüber hinaus gewährleisten automatisierte Backup-Protokolle, dass Transaktionsprotokolle und Snapshots der Speichervolumes kontinuierlich in einem äußerst beständigen Objektspeicher archiviert werden. Dieser Mechanismus ermöglicht es Datenbankadministratoren, eine granulare Wiederherstellung zu einem bestimmten Zeitpunkt bis auf die Sekunde genau durchzuführen und schützt das Unternehmen so vor versehentlichem Datenverlust oder böswilliger Manipulation. Routinemäßige Wartungsarbeiten, darunter kritische Sicherheitspatches für das Betriebssystem und kleinere Datenbank-Versions-Upgrades, werden nahtlos innerhalb vordefinierter, vom Kunden gesteuerter Wartungsfenster durchgeführt. Diese Automatisierung gewährleistet die Einhaltung unternehmensinterner Sicherheitsvorgaben und minimiert gleichzeitig das Risiko unbehobener Sicherheitslücken. Für Entwicklungsteams bedeutet die Auslagerung dieser Aufgaben eine direkte Beschleunigung der Bereitstellungszyklen. Durch die Entlastung bei der Infrastrukturwartung können technische Mitarbeiter ihren Fokus und ihre Ressourcen auf wertschöpfende Aktivitäten wie Anwendungsentwicklung, Optimierung logischer Schemata und Leistungsoptimierung komplexer Abfragen verlagern.

Die wahre Komplexität des Finanzmanagements in der Cloud zeigt sich nicht in den primären Rechen- und Speicherebenen, sondern in den unzähligen Zusatzdiensten, betrieblichen Nachteilen und externen Integrationsmechanismen, die erforderlich sind, um eine produktionsreife Datenbank sicher und effektiv zu betreiben. Diese sekundären und tertiären Abrechnungsdimensionen werden bei der anfänglichen Kostenmodellierung häufig übersehen und summieren sich unbemerkt, während die Arbeitslasten skalieren und die architektonische Komplexität zunimmt.

RDS-Proxy und Verbindungsmanagement

Relationale Datenbank-Engines verbrauchen erhebliche interne CPU- und Speicherressourcen, um offene Client-Verbindungen auszuhandeln, herzustellen und aufrechtzuerhalten. In modernen serverlosen Architekturen, in denen als Reaktion auf Traffic-Spitzen Tausende von kurzlebigen Rechenfunktionen gleichzeitig gestartet werden können, kann die Datenbank ihre begrenzten Verbindungslimits schnell ausschöpfen. Dieses als „Connection Storm“ bezeichnete Phänomen führt zu schwerwiegenden Anwendungs-Timeouts, Speicherengpässen und einer Verschlechterung der Dienstqualität.

Um diese architektonischen Reibungsverluste zu beheben, bietet Amazon den RDS Proxy an, einen vollständig verwalteten, hochverfügbaren Datenbank-Proxy, der zwischen der Anwendung und der Datenbank angesiedelt ist, um bestehende Verbindungen zu bündeln und gemeinsam zu nutzen. Dieser Proxy schützt die Datenbank-Engine zwar wirksam vor einer Erschöpfung der Verbindungen, führt jedoch eine separate, kontinuierliche und erhebliche Abrechnungskomponente ein. Bei bereitgestellten Instanzen wird RDS Proxy mit 0,015 US-Dollar pro vCPU-Stunde abgerechnet, wobei sich der Preis ausschließlich nach der Größe der zugrunde liegenden Datenbankinstanz richtet, die er bedient, wobei eine Mindestgebühr von 2 vCPUs anfällt^.13 Wenn ein Unternehmen also eine stark skalierte Flotte von r5.4xlarge-Instanzen mit jeweils 16 vCPUs betreibt, verursacht die Einbindung des Proxy-Mechanismus versteckte Rechenkosten in Höhe von Hunderten von Dollar pro Instanz und Monat. Diese Kosten fallen Stunde für Stunde an, völlig unabhängig vom tatsächlichen Volumen des Anwendungsdatenverkehrs, der die Proxy-Schicht durchläuft.¹³

Observability: CloudWatch Database Insights und Performance Insights

Eine umfassende Beobachtbarkeit der Datenbank ist eine unverzichtbare betriebliche Anforderung, um langsame Abfrageausführungen zu identifizieren, Transaktions-Deadlocks zu beheben und Indexineffizienzen zu mindern. Amazon RDS erfüllt diese Anforderung, indem „Performance Insights“ bereits bei der Erstellung der Instanz automatisch aktiviert wird. Damit steht ein spezielles grafisches Tool zur Verfügung, mit dem sich die Datenbankauslastung visualisieren und präzise Leistungsengpässe auf Abfrageebene isolieren lassen.¹⁴

Die kostenlose Basisversion von Performance Insights bietet eine rollierende Aufbewahrungsfrist von sieben Tagen für den Verlauf der Leistungsdaten und umfasst bis zu einer Million API-Anfragen pro Monat ohne zusätzliche Kosten.¹⁵ Eine umfassende Optimierung der Datenbankleistung erfordert jedoch häufig eine Langzeitanalyse der Daten über mehrere Wochen hinweg, um saisonale Schwankungen im Datenverkehr und langfristige Verschlechterungstrends zu erfassen. Die Verlängerung dieses Aufbewahrungszeitraums ist mit erheblichen Mehrkosten verbunden. Wählt ein Administrator eine kostenpflichtige flexible Aufbewahrungsstufe zwischen einem und 24 Monaten, wird dem Unternehmen eine Pauschale von 1,50 US-Dollar pro vCPU und Monat in Rechnung gestellt.¹⁵ Bei hoch skalierten Instanzen mit Dutzenden von Kernen entwickelt sich diese „Observability-Gebühr“ schnell zu einem bedeutenden Posten auf der monatlichen Rechnung.

Darüber hinaus durchläuft die Architekturlandschaft für die Datenbank-Observability derzeit eine erzwungene, von den Anbietern vorgeschriebene Migration. Bis zum 30. Juni 2026 werden die native Performance Insights-Konsole und die damit verbundenen flexiblen Preismodelle für die Aufbewahrungsdauer offiziell das Ende ihrer Lebensdauer (End of Life, EOL) erreichen.¹⁴ Nutzer werden gezwungen sein, ihre Observability-Workflows in den „Erweiterten Modus“ von Amazon CloudWatch Database Insights zu migrieren. Instanzen, die nicht vor Ablauf der Frist im Jahr 2026 von Administratoren proaktiv aktualisiert werden, werden standardmäßig in einen eingeschränkten „Standardmodus“ versetzt. Dieser Standardzustand führt zum dauerhaften Verlust des Zugriffs auf Leistungsdaten, die älter als sieben Tage sind, sowie zum Wegfall wichtiger Diagnosefunktionen für Ausführungspläne und On-Demand-Sperranalysen.¹⁴ Der Übergang zu CloudWatch verursacht für Unternehmen zudem zusätzliche Kosten durch API-Abfragen. Benutzerdefinierte Überwachungs-Dashboards, die häufig aktualisiert werden, generieren enorme Mengen an API-Aufrufen; alle Anfragen, die über das anfängliche Kontingent von 1 Million kostenlosen Aufrufen hinausgehen, werden mit 0,01 US-Dollar pro 1.000 Anfragen abgerechnet, was sich bei Betriebsteams, die Echtzeitüberwachung nutzen, unbemerkt summiert.¹⁵

Anwachsender Speicherbedarf für Backups

Datenschutz und Notfallwiederherstellung sind grundlegende Prinzipien von verwalteten Datenbankdiensten. Amazon stellt automatisierten Backup-Speicher ohne zusätzliche Kosten zur Verfügung, wobei diese Zuweisung jedoch streng auf 100 % der insgesamt für eine bestimmte Region bereitgestellten Datenbankspeichergröße begrenzt ist.⁵ So werden beispielsweise einer aktiven Datenbank, für die 500 GiB Elastic Block Store-Kapazität bereitgestellt wurden, entsprechend 500 GiB kostenloser Backup-Speicher zugewiesen. Strenge Compliance-Vorgaben und Audit-Anforderungen von Unternehmen erfordern jedoch häufig längere Aufbewahrungsfristen für Backups, verbunden mit der routinemäßigen Erstellung manueller Snapshots vor risikobehafteten Anwendungsbereitstellungen.

Wenn das Gesamtvolumen der gespeicherten manuellen Snapshots und automatisierten Transaktionsprotokolle die 100-prozentige Basislinie des bereitgestellten Speichers überschreitet, wird die überschüssige Kapazität mit einem Satz von 0,095 US-Dollar pro GiB-Monat in Rechnung gestellt.⁵ Eine hochaktive Transaktionsdatenbank, die große Mengen an Transaktionsprotokollen erzeugt, kann diesen kostenlosen Schwellenwert leicht und schnell überschreiten. Entscheidend ist: Wenn ein Infrastrukturadministrator eine Datenbankinstanz vorübergehend anhält, um außerhalb der Geschäftszeiten stündliche Rechenkosten einzusparen, fallen für die Instanz weiterhin dauerhaft Gebühren für das bereitgestellte Speichervolumen und den damit verbundenen Backup-Speicher an.² Wenn die zugrunde liegende Datenbankinstanz dauerhaft beendet wird, verfällt der Freimengen-Ausgleich sofort, und alle verbleibenden manuellen Snapshots werden anschließend auf unbestimmte Zeit zum vollen Satz von 0,095 $ pro GiB-Monat in Rechnung gestellt.⁵

Snapshot-Export und S3-Integration

Data-Engineering-Pipelines stützen sich häufig auf Snapshots relationaler Datenbanken, um analytische Data Lakes oder externe Business-Intelligence-Umgebungen zu befüllen. Amazon bietet eine spezielle Funktion, mit der Snapshot-Daten automatisch direkt im Apache-Parquet-Format in den Amazon Simple Storage Service (S3) exportiert werden können. Dieses spaltenorientierte Format ist äußerst vorteilhaft, da es den Speicherbedarf reduziert und die nachgelagerte Verarbeitung durch Abfrage-Engines wie Amazon Athena beschleunigt.¹⁶

Diese Bequemlichkeit unterliegt jedoch einer äußerst starren und kostspieligen Preisstruktur. Der Snapshot-Export wird gemessen und mit 0,010 US-Dollar pro GB der gesamten, aggregierten Snapshot-Größe abgerechnet, unabhängig davon, ob der Benutzer Filterregeln anwendet, um nur bestimmte, kleinere Tabellen zu exportieren.⁵ So fallen beispielsweise bei der Durchführung eines gefilterten Exports einer 10-GB-Teilmenge aus einem riesigen 1-TB-Datenbank-Snapshot Rechenkosten an, die sich ausschließlich auf das gesamte Volumen von 1 TB beziehen. Darüber hinaus ist der Exportvorgang grundsätzlich nicht inkrementell^.16 Nachfolgende Exporte von Daten aus genau demselben Snapshot oder der routinemäßige tägliche Export neu erstellter Snapshots lösen bei jeder einzelnen Ausführung eine vollständige Abrechnung für das gesamte Datensatzvolumen aus. Diese gesonderten Kosten für die Exportverarbeitung fallen parallel zu und zusätzlich zu den Standardgebühren für Amazon S3-PUT-Anfragen sowie den laufenden Objekt-Speichergebühren für die Speicherung der resultierenden Parquet-Dateien an.¹⁸

Krise bei den Preisen für erweiterten Support

Datenbank-Engines unterliegen strengen Lebenszyklusplänen, die von den Betreibern der Open-Source-Community oder kommerziellen Anbietern vorgegeben werden. Wenn eine Hauptversion das Ende des Lebenszyklus (EOL) in der Community erreicht, stellen die Upstream-Betreiber die Bereitstellung kritischer Sicherheitspatches, Fehlerbehebungen und Leistungsupdates offiziell ein. Um ältere Workloads zu schützen, die aufgrund komplexer Anwendungsabhängigkeiten oder technischer Schulden nicht sofort aktualisiert werden können, bietet AWS ein Programm für erweiterten Support an, das die Bereitstellung kritischer Sicherheitspatches für bis zu drei weitere Jahre garantiert.²

Diese Übergangsfrist fungiert jedoch als aggressiver, eskalierender finanzieller Strafmechanismus, der ausdrücklich darauf ausgelegt ist, Unternehmen zur Durchführung von Upgrades zu zwingen. Mit Wirkung zum 1. März 2026 wurde die Preisstruktur für das dritte Jahr des erweiterten Supports massiv angehoben, wodurch sich die Strafzuschläge für weit verbreitete ältere Datenbank-Engines – insbesondere MySQL 5.7 und PostgreSQL 11.²⁰ – effektiv verdoppelten.

Die finanziellen Auswirkungen dieser Strafgebühr werden streng auf Basis der einzelnen vCPUs und Stunden berechnet. Vor März 2026 betrug der Aufschlag in Regionen wie „US East (Ohio)“ 0,100 US-Dollar pro vCPU-Stunde. Nach Erreichen des Schwellenwerts am 1. März 2026 verdoppelte sich dieser Satz auf 0,200 US-Dollar pro vCPU-Stunde.¹⁶

Tabelle 2: Die finanziellen Auswirkungen der ab dem 1. März 2026 geltenden Strafpreise für den erweiterten Support (Jahr 3).

Wie die Daten eindeutig belegen, übersteigt der Aufschlag für den erweiterten Support regelmäßig und deutlich die Grundkosten der zugrunde liegenden Recheninstanz selbst.²⁰ Diese Dynamik führt zu katastrophalen, unvorhergesehenen Budgetüberschreitungen für Entwicklerteams, die durch Einschränkungen bei der Anwendungskompatibilität handlungsunfähig sind. Für Unternehmen, die serverlose Bereitstellungen wie Aurora Serverless v2 nutzen, wird der Aufschlag pro Aurora-Kapazitätseinheit und Stunde berechnet, was zu einem gleichbleibenden, skalierbaren finanziellen Risiko bei unvorhersehbaren Workloads führt.²

Die versteckte Netzwerkgebühr: NAT-Gateways und PrivateLink

Strenge Best Practices für die Sicherheitsarchitektur schreiben vor, dass relationale Datenbanken ausschließlich in privaten Subnetzen bereitgestellt werden müssen, ohne direkte Ein- oder Ausgangsverbindungen zum öffentlichen Internet. Zusätzliche architektonische Anforderungen machen jedoch häufig eine ausgehende Internetverbindung erforderlich. Beispielsweise benötigt eine Lambda-Funktion, die sich im selben privaten Subnetz befindet, möglicherweise Zugriff sowohl auf die interne Datenbankinstanz als auch auf eine externe Zahlungs-API eines Drittanbieters, oder die Datenbank selbst benötigt einen ausgehenden Zugriff, um bestimmte Software-Updates abzurufen. Dieses ausgehende Routing wird traditionell über ein NAT-Gateway (Network Address Translation) realisiert.

NAT-Gateways stellen eine der heimtückischsten und am schnellsten anwachsenden versteckten Kosten im Bereich Cloud-Netzwerke dar.²¹ Ihre Kosten werden anhand von drei sich gegenseitig verstärkenden Faktoren ermittelt:

• Stündliche Bereitstellungsgebühr: Jedes bereitgestellte NAT-Gateway kostet 0,045 US-Dollar pro Stunde, was allein für die Bereitstellung etwa 32,85 US-Dollar pro Monat entspricht – unabhängig davon, ob auch nur ein einziges Byte Datenverkehr durch das Gateway fließt.¹² Eine hochverfügbare Architektur der Enterprise-Klasse, die sich über drei Verfügbarkeitszonen erstreckt, erfordert die Bereitstellung von drei unabhängigen NAT-Gateways, wodurch sich die Grundkosten im Leerlauf auf fast 100 US-Dollar pro Monat belaufen.²³
• Datenverarbeitungsgebühr: Für jedes Gigabyte an Daten, das das NAT-Gateway durchläuft, fällt eine feste Datenverarbeitungsgebühr in Höhe von 0,045 US-Dollar an.¹²
• Internet-Ausgangsverkehr: Nach der Verarbeitung durch das NAT-Gateway fallen für den Datenverkehr die üblichen regionalen Gebühren für ausgehenden Datenverkehr an, die in der Regel bei 0,09 US-Dollar pro GB beginnen.¹²

Folglich kostet die Verarbeitung von einem Terabyte ausgehenden Datenverkehrs, der über ein NAT-Gateway geleitet wird, effektiv 135 US-Dollar (45 US-Dollar für die Verarbeitungsgebühr plus 90 US-Dollar für die Ausgangsgebühr), was eine enorme finanzielle Belastung darstellt, die völlig unabhängig von den zentralen Abrechnungskennzahlen der Datenbank ist.

Alternativ können Netzwerkarchitekten AWS PrivateLink über VPC-Endpunkte nutzen, um den Datenverkehr sicher an andere AWS-Dienste weiterzuleiten, ohne das öffentliche Internet oder ein stark ausgelastetes NAT-Gateway zu durchlaufen. Dies mindert zwar wirksam die hohen NAT-Verarbeitungsgebühren, doch VPC-Endpunkte bringen ihre eigene finanzielle Belastung mit sich: eine stündliche Bereitstellungsgebühr von 0,01 US-Dollar pro Endpunkt und Verfügbarkeitszone sowie eine Datenverarbeitungsgebühr von 0,01 US-Dollar pro GB.¹² Ein Unternehmen, das dedizierte Endpunkte für S3, Secrets Manager, CloudWatch und Systems Manager über mehrere Verfügbarkeitszonen hinweg unterhält, verursacht schnell Grundkosten für die Netzwerknutzung in Höhe von mehreren hundert Dollar. Darüber hinaus verursacht die Zuweisung öffentlicher IPv4-Adressen in der gesamten Infrastruktur unvermeidbare, laufende Kosten in Höhe von 0,005 US-Dollar pro Stunde bzw. etwa 3,65 US-Dollar pro Monat und IP-Adresse.¹²

OLAP-Unterstützung über Redshift und Zero-ETL

Amazon RDS wurde von Grund auf für die Online-Transaktionsverarbeitung (OLTP) entwickelt und optimiert. Seine zeilenbasierte Speicherarchitektur eignet sich hervorragend für die Ausführung schneller Lese- und Schreibvorgänge einzelner Datensätze, weist jedoch erhebliche Leistungseinbußen auf, wenn sie komplexen, tabellenübergreifenden analytischen Abfragen ausgesetzt ist, wie sie für die Online-Analytik (OLAP) typisch sind. Um Business-Intelligence-Analysen in Echtzeit durchzuführen, ohne das primäre Transaktionssystem lahmzulegen, sind Unternehmen gezwungen, ihre relationalen Daten in ein dediziertes, spaltenorientiertes Data Warehouse zu replizieren, insbesondere in Amazon Redshift.²⁶

In der Vergangenheit erforderte die Umsetzung dieser Replikation den Aufbau maßgeschneiderter ETL-Pipelines (Extract, Transform, Load) oder den Einsatz separater CDC-Dienste (Change Data Capture) wie dem AWS Database Migration Service (DMS), Managed Streaming for Apache Kafka (MSK) oder Apache Flink. Die Nutzung von DMS erfordert dedizierte Replikationsinstanzen, die stundenweise nach ihrer Größe abgerechnet werden, sowie zusätzlichen Speicherbedarf für Replikationsprotokolle, Auslagerungsspeicher und Daten-Caching.⁹ Darüber hinaus skaliert DMS die Rechenkapazität über DMS Capacity Units (DCUs), wobei die Preise stark davon abhängen, ob die Replikation für „Single-AZ“- oder „Multi-AZ“-Ausfallsicherheit konfiguriert ist.⁹

Um diese komplexe Integration zu optimieren und den Wartungsaufwand für die Pipeline zu reduzieren, hat AWS die Zero-ETL-Integration eingeführt. Diese Funktion verspricht eine nahezu in Echtzeit erfolgende Replikation von Transaktionsdaten aus Quellen wie Amazon Aurora und Amazon RDS direkt in Redshift, ohne dass eigener Code gepflegt werden muss.²⁸ Zwar weist AWS ausdrücklich und wiederholt darauf hin, dass für die Zero-ETL-Integration selbst keine zusätzlichen Gebühren anfallen, doch führen die damit verbundenen architektonischen Anforderungen zu erheblichen, unvermeidbaren Kostensprüngen.²⁶

Die größte finanzielle Gefahr liegt tief in den Funktionsmechanismen von Redshift Serverless und der kontinuierlichen CDC verborgen. Redshift Serverless berechnet die Rechenkapazität in Redshift-Verarbeitungseinheiten pro Sekunde und wendet dabei für jede Aktivität eine Mindestgebühr von 60 Sekunden an.³¹ Die Zero-ETL-Integration ist auf einen kontinuierlichen, ununterbrochenen Strom von CDC-Ereignissen angewiesen, um eine Datenlatenz nahezu in Echtzeit aufrechtzuerhalten. Dieses dauerhafte Streaming mit geringem Datenaufkommen deaktiviert die nativen Auto-Pause-Funktionen von Redshift Serverless vollständig.³⁰

Darüber hinaus erfordert die Konfiguration einer Redshift Serverless-Arbeitsgruppe als Ziel für eine Zero-ETL-Integration algorithmisch eine strenge Mindestkapazität von 32 Redshift-Verarbeitungseinheiten (RPU).²⁹ Bei einem regionalen Standardtarif von etwa 0,36 US-Dollar pro RPU-Stunde kostet ein aktiver Cluster mit 32 RPUs 11,52 US-Dollar pro Stunde^.26 Da der kontinuierliche Zustrom von CDC-Daten verhindert, dass der Cluster jemals in den Ruhezustand wechselt oder auf null heruntergefahren wird, werden Unternehmen 24 Stunden am Tag, sieben Tage die Woche für 32 RPUs in Rechnung gestellt. Dies führt zu absoluten Grundkosten von über 8.200 $ pro Monat allein für den Empfang der replizierten Daten, völlig unabhängig davon, ob jemals eine einzige analytische Abfrage von einem menschlichen Nutzer oder einem BI-Tool ausgeführt wird.³⁰

Erschwerend kommt hinzu, dass die replizierten Daten sehr starr sind. Tabellen, die über Zero-ETL in der Redshift-Umgebung befüllt werden, sind streng schreibgeschützt^.30 Um die erforderliche nachgelagerte Dimensionsmodellierung durchzuführen, müssen Dateningenieure sekundäre materialisierte Ansichten oder Transformationstabellen bereitstellen, was den erforderlichen Speicherbedarf für Redshift Managed Storage (RMS) erhöht und zusätzliche Rechen-RPUs für die fortlaufende Datenumstrukturierung beansprucht, was in der Regel zu 30 % bis 40 % mehr Entwicklungsaufwand führt.³⁰

Vektorsuche, RAG und KI-Workloads

Die rasante Verbreitung generativer künstlicher Intelligenz (GenAI) hat die „Retrieval-Augmented Generation“ (RAG) zu einem unverzichtbaren Architekturmuster für moderne Anwendungen gemacht. Die Implementierung von RAG erfordert die Fähigkeit, proprietäre Textdaten in hochdimensionale mathematische Vektoren – sogenannte Embeddings – umzuwandeln und anschließend als Reaktion auf Benutzeranfragen semantische Ähnlichkeitssuchen anhand dieser Vektoren durchzuführen.

Standardmäßigen relationalen Datenbank-Engines fehlen von Haus aus optimierte, leistungsstarke Funktionen zur Vektorverarbeitung. Zwar unterstützt PostgreSQL die beliebte pgvector-Erweiterung, doch birgt deren Einsatz auf einer Standardinfrastruktur erhebliche Betriebsrisiken und führt zu Leistungsengpässen. Algorithmen zur Vektorähnlichkeitssuche, insbesondere hierarchische, navigierbare „Small-World“-Graphen, sind außerordentlich speicherintensiv.³² Wenn eine OLTP-Datenbank gezwungen wird, Millionen hochdimensionaler Einbettungen zu speichern, zu indizieren und abzufragen, führt dies zu einer massiven Belastung der Datenbank-Pufferpools. Dieser Prozess verdrängt standardmäßige relationale Daten aus dem Arbeitsspeicher, zwingt die Datenbank zum Lesen von der Festplatte und beeinträchtigt den transaktionalen Durchsatz erheblich. Zwar führten Aktualisierungen wie die Version 0.8.0 von pgvector iteratives Scannen und eine verbesserte Abfrageplanung ein, doch zwingt die Auslagerung von Vektor-Workloads auf einen relationalen Knoten das Unternehmen fast immer dazu, eine vertikale Skalierung auf äußerst teure, speicherintensive Instanzen der R-Serie durchzuführen, um den Speicherbedarf auszugleichen.³²

Um eine Destabilisierung der primären Transaktionsdatenbank zu vermeiden, sind Cloud-Architekten gezwungen, stark fragmentierte, uneinheitliche KI-Ökosysteme zu nutzen. Dies beinhaltet in der Regel die Weiterleitung von Daten aus der Datenbank an Amazon SageMaker zur Erstellung benutzerdefinierter Einbettungen oder den Einsatz von Amazon Bedrock in Verbindung mit Amazon OpenSearch Serverless. Diese stark verteilte Architektur ist außerordentlich komplex und mit hohen Kosten verbunden.

Durch die Integration wird mittels Mindestanforderungen für den Vektorspeicher eine feste Abrechnungsuntergrenze festgelegt. Die Einrichtung einer Wissensdatenbank in Amazon Bedrock löst die automatische Erstellung einer OpenSearch Serverless-Vektorsammlung im Hintergrund aus. Dieser Mechanismus schreibt eine Mindestbereitstellung von zwei OpenSearch Compute Units vor – eine für die Indizierung und eine für die Suchreplikation –, was Kosten von etwa 350 US-Dollar pro Monat verursacht, selbst wenn die Datenbank völlig ungenutzt bleibt und keine Abfragen eingehen.³³

Die Umwandlung der relationalen Rohdaten in Vektoren erfordert die Weiterleitung der Daten durch Embedding-Modelle, die auf SageMaker oder Bedrock gehostet werden, was strenge Inferenzgebühren auslöst, die pro Million verarbeiteter Token abgerechnet werden.³⁵ Darüber hinaus erfordern fortgeschrittene RAG-Pipelines ein semantisches Reranking, um die mathematische Genauigkeit der zurückgegebenen Ergebnisse zu verbessern. Die Anwendung von Amazon Rerank 1.0 verursacht einen zusätzlichen Aufschlag von 1,00 US-Dollar pro 1.000 Abfragen.³⁴ Die Nutzung von Bedrock Guardrails zum Filtern bösartiger Eingaben oder halluzinierter Ausgaben führt zu einer weiteren laufenden Verarbeitungsgebühr von 0,30 US-Dollar pro 1.000 Texteinheiten.³⁴ Schließlich erfordert die ständige Notwendigkeit der Datensynchronisation – das Verschieben aktualisierter relationaler Datensätze aus der Quelldatenbank in den OpenSearch-Vektorindex – die Pflege benutzerdefinierter Lambda-Funktionen oder kontinuierlicher Streaming-Pipelines, was dem monatlichen Abrechnungsbeleg eine weitere Ebene an Rechen- und Datenverarbeitungsgebühren hinzufügt.

Die Idle-Standby-Strafe und die Komplexitäten im Aktiv-Aktiv-Betrieb

Obwohl Multi-AZ-Bereitstellungen intensiv als Standard für Hochverfügbarkeit vermarktet werden, bringen sie eine enorme Kostenineffizienz mit sich: Der Standby-Knoten ist rein passiv. Bei einer standardmäßigen Amazon RDS Multi-AZ-Instanzbereitstellung kann die synchrone Standby-Replik nicht zur Bedienung des Leseverkehrs genutzt werden; sie bleibt vollständig ungenutzt, bis ein Failover-Ereignis ausgelöst wird. Das Unternehmen bezahlt somit effektiv 100 % der Rechenkapazität eines sekundären Knotens, der im Normalbetrieb keinerlei Durchsatzwert liefert. Wenn eine Anwendung eine Skalierung der Leseleistung erfordert, muss das Unternehmen zusätzlich zu seiner Multi-AZ-Bereitstellung völlig separate Lesereplikate bereitstellen und dafür bezahlen.

Zudem unterstützt Amazon RDS für MySQL (Versionen 8.0.35 und höher) zwar Aktiv-Aktiv-Architekturen über das Community-Plugin „MySQL Group Replication“, doch handelt es sich hierbei nicht um eine vollständig verwaltete, nahtlose Lösung. Es sind umfangreiche manuelle Konfigurationsschritte erforderlich, und wenn eine Datenbankinstanz nicht wieder in die Gruppe aufgenommen werden kann, müssen Administratoren häufig eingreifen und die Gruppenreplikation manuell neu starten.

Das Fehlen einer nativen automatischen Skalierung der Rechenleistung

Standard-Amazon-RDS unterstützt nativ die automatische Skalierung des Speichers und erweitert den persistenten Blockspeicher nahtlos, wenn die Datensätze wachsen. Es fehlt jedoch ausdrücklich eine native vertikale oder horizontale automatische Skalierung der Rechenleistung. Wenn bei einer Standard-RDS-Instanz (nicht Aurora) ein plötzlicher Anstieg des Datenverkehrs auftritt, verfügt der Dienst über keine integrierte Funktion zur automatischen Skalierung der CPU-Leistung oder des Arbeitsspeichers. Um eine automatisierte Skalierung der Rechenleistung zu erreichen, sind Infrastrukturteams gezwungen, benutzerdefinierte, komplexe Workflows mithilfe von Amazon CloudWatch-Alarmen, Amazon SNS-Benachrichtigungen und AWS Lambda-Funktionen zu erstellen, um Instanzänderungen auszulösen. Da diese selbst erstellte Automatisierung operative Risiken und Ausfallzeiten während der vertikalen Skalierung mit sich bringt, entscheiden sich die meisten Unternehmen einfach dafür, ihre Instanzgrößen dauerhaft überdimensioniert zu dimensionieren, um Spitzenauslastungen bewältigen zu können – was zu massiven Verschwendungen bei den Rechenkosten während der Leerlaufzeiten führt.

Die verborgenen menschlichen Kosten: Datenbankadministratoren

Das Marketingversprechen vollständig verwalteter Cloud-Datenbanken verleitet Unternehmen oft zu der falschen Annahme, dass sie keine Datenbankadministratoren (DBAs) mehr benötigen. Amazon RDS automatisiert Aufgaben auf Infrastrukturebene wie die Bereitstellung von Hardware, die Installation von Betriebssystem-Patches und Backups, basiert jedoch auf einem strengen Modell der geteilten Verantwortung. Kritische Datenbankfunktionen wie Abfrageoptimierung, Indizierungsstrategien, Schema-Design und tiefgreifende Leistungsoptimierung müssen weiterhin vollständig selbst durchgeführt werden. AWS bietet reaktiven Infrastruktur-Support, was bedeutet, dass langsame Abfragen nicht proaktiv optimiert werden. Folglich zahlen Unternehmen einen enormen Aufschlag für Managed Services auf die Recheninstanzen und tragen gleichzeitig die laufenden Kosten für ein festangestelltes, internes DBA-Team, um den effizienten Betrieb der Datenbank sicherzustellen.

1. Der ultimative Leitfaden zu den Preisen für Cloud-Speicher im Jahr 2026: Versteckte Gebühren, Cloud -Kosten und wie man zu hohe Kosten vermeidet – https://medium.com/@orboncloud/the-ultimate-guide-to-cloud-storage-pricing-in-2026-hidden-fees-egress-costs-how-to-avoid-b8e7bcac2c5d
2. Preise für Amazon RDS – https://aws.amazon.com/rds/pricing/
3. OpenWorks 2023 – SkySQL vs. AWS RDS vs. GCP Cloud SQL – https://mariadb.com/wp-content/uploads/2023/05/OpenWorks-2023-SkySQL-vs-AWS-RDS-vs-GCP-Cloud-SQL-Venkat-Iyer.pdf
4. Preise für Amazon RDS für SQL Server – https://aws.amazon.com/rds/sqlserver/pricing/
5. Amazon RDS-Preise | Alle Kosten pro Engine und versteckte Gebühren (2026) – https://go-cloud.io/amazon-rds-pricing/
6. Preise für Amazon RDS für „ MariaDB “ –https://aws.amazon.com/rds/mariadb/pricing/
7. Abrechnung von DB-Instanzen für Amazon RDS – https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/User_DBInstanceBilling.html
8. Der ultimative Leitfaden zu den AWS RDS-Preisen: Eine umfassende Kostenaufschlüsselung für 2025 – https://cloudchipr.com/blog/rds-pricing
9. AWS DMS-Preise – https://aws.amazon.com/dms/pricing/
10. Übersicht über die Datenübertragungskosten bei gängigen Architekturen – https://aws.amazon.com/blogs/architecture/overview-of-data-transfer-costs-for-common-architectures/
11. Eine Untersuchung der Datenübertragungskosten für verwaltete Datenbanken von AWS –https://aws.amazon.com/blogs/architecture/exploring-data-transfer-costs-for-aws-managed-databases/
12. Der umfassende Leitfaden zu den Netzwerkkosten bei „ Cloud “: VPCs, NAT-Gateways und Datentransfer – https://zop.dev/resources/blogs/the-complete-guide-to-cloud-networking-costs-vpcs-nat-gateways-and-data-transfer/
13. Preise für Amazon RDS Proxy https://aws.amazon.com/rds/proxy/pricing/
14. Überblick über Leistungsdaten zu Amazon Aurora – https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/USER_PerfInsights.Overview.html
15. Preise für Performance Insights – https://aws.amazon.com/rds/performance-insights/pricing/
16. Preise für Amazon RDS für MySQL – https://aws.amazon.com/rds/mysql/pricing/
17. Exportieren von Datenbank-Snapshot-Daten nach Amazon S3 für Amazon RDS https://docs.aws.amazon.com/AmazonRDS/latest/UserGuide/USER_ExportSnapshot.html
18. Preise für Amazon Aurora – https://aws.amazon.com/rds/aurora/pricing/
19. Preise für Amazon S3 – https://aws.amazon.com/s3/pricing/
20. Amazon RDS-Preise: Für Nutzer von MySQL 5.7 fällt nun eine Gebühr von 292 US-Dollar pro Monat an – https://cloudburn.io/blog/amazon-rds-pricing
21. Die versteckte „ Cloud “-Steuer: Wie IPv4-Mieten und Egress-Gebühren die Budgets für 2026 still und leise belasten – https://www.cloudcostchefs.com/blog/cloud-networking-costs-ipv4-egress-2026
22. Amazon VPC-Preise: 4 Kosten, die sich hinter der kostenlosen VPC verbergen – https://cloudburn.io/blog/amazon-vpc-pricing
23. Die versteckte Gebühr von 33 $ pro Monat: Die Kosten für das AWS NAT Gateway verstehen –https://dev.to/cloudwiseteam/the-silent-33month-charge-understanding-aws-nat-gateway-costs-19c3
24. Ich versuche, die NAT-Preise besser zu verstehen: r/aws – https://www.reddit.com/r/aws/comments/1b83lu1/trying_to_better_understand_nat_pricing/
25. Preise für AWS PrivateLink – https://aws.amazon.com/privatelink/pricing/
26. Preise für Amazon Redshift – https://aws.amazon.com/redshift/pricing/
27. Preise für Amazon Redshift: Was Sie erwarten können und wie das Angebot im Vergleich abschneidet – https://www.rudderstack.com/blog/amazon-redshift-pricing/
28. Vereinfachen Sie die Datenintegration mithilfe von Zero-ETL von Amazon RDS zu Amazon Redshift – https://aws.amazon.com/blogs/database/simplify-data-integration-using-zero-etl-from-amazon-rds-to-amazon-redshift/
29. Zero-ETL-Integrationen – Amazon Redshift – https://docs.aws.amazon.com/redshift/latest/mgmt/zero-etl-using.html
30. AWS Zero-ETL für Redshift: Vorteile in Echtzeit, versteckte Fallstricke – https://medium.com/@amitmeme/aws-zero-etl-to-redshift-real-time-wins-hidden-traps-and-the-cost-smart-path-to-production-b15d0b5e5928
31. Preise für Amazon Redshift – https://www.amazonaws.cn/en/redshift/pricing/
32. Deutliche Steigerung der Leistung und Relevanz bei der Vektorsuche mit pgvector 0.8.0 auf Amazon Aurora PostgreSQL – https://aws.amazon.com/blogs/database/supercharging-vector-search-performance-and-relevance-with-pgvector-0-8-0-on-amazon-aurora-postgresql/
33. Amazon OpenSearch Service – Preise – https://aws.amazon.com/opensearch-service/pricing/
34. Preise für Amazon Bedrock: Hinter den Token-Preisen verbirgt sich eine Falle von 350 $ pro Monat – https://cloudburn.io/blog/amazon-bedrock-pricing
35. Preise für Amazon Bedrock https://aws.amazon.com/bedrock/pricing/
36. MariaDB Beschleunigt „ Cloud “-Bereitstellungen und erweitert das Angebot durch „Agentic AI“ und serverlose Funktionen dank der Übernahme von SkySQL – https://mariadb.com/newsroom/press-releases/mariadb-accelerates-cloud-deployments-adds-agentic-ai-and-serverless-capability-with-acquisition-of-skysql/
37. Ankündigung der Veröffentlichung von „ MariaDB “Enterprise Platform 2026 – https://mariadb.com/resources/blog/announcing-the-release-of-mariadb-enterprise-platform-2026/
38. MariaDB Cloud Preise – https://mariadb.com/pricing/#mariadb-cloud
39. MariaDB Enterprise Platform Übersicht – https://mariadb.com/resources/datasheets/mariadb-enterprise-platform/
40. MariaDB vereint transaktionale, analytische und Vektordatenbanken in der Version 2026 der „ MariaDB “Enterprise Platform – https://sdtimes.com/data/mariadb-unifies-transactional-analytical-and-vector-databases-in-mariadb-enterprise-platform-2026-release/
41. Einführung der Vektorsuche mit der neuesten Version von „ MariaDB “ – https://mariadb.com/resources/blog/introducing-vector-search-with-the-latest-version-of-mariadb-enterprise-platform/
42. Vielseitigkeit bei Datenbank-Workloads – https://mariadb.com/products/enterprise/workload-versatility/
43. Auswertung von Vektorindizes in „ MariaDB “ und „pgvector“: Teil 1 – http://smalldatum.blogspot.com/2025/01/evaluating-vector-indexes-in-mariadb.html
44. Einführung in die Vektorsuche in „ MariaDB “ – Severalnines – https://severalnines.com/blog/introduction-to-mariadb-vector-search/
45. Vergleich zwischen „ MariaDB “ und „SkySQL“ im Jahr 2026 – https://slashdot.org/software/comparison/MariaDB-vs-SkySQL/
46. SkySQL- MariaDB . vs. AWS Aurora MySQL: Preis-Leistungs-Vergleich – https://skysql.com/blog/skysql-mariadb-vs-aws-aurora-mysql-a-price-performance-comparison
47. MariaDB Cloud Serverless – https://mariadb.com/docs/mariadb-cloud/readme/serverless
48. Preise für Unternehmensdatenbanken für „ MariaDB “ – https://mariadb.com/pricing/