AWS Redshift RG: Graviton steigt in den Analytics-Stack auf

Die Plattformentscheidung, die in diesem Quartal auf dem Schreibtisch eines CTO landet, lautet nicht mehr „Warehouse versus Lakehouse". Die Frage ist, ob das nächste Drei-Jahres-Commitment für Analytics auf x86-Snowflake-Credits, Databricks-DBUs oder Arm-basiertem Redshift aufgebaut wird. AWS hat die dritte Option gerade deutlich schwerer ignorierbar gemacht – und die Unit-Economics sind der Grund.

Was passiert ist

Diese Woche hat AWS Graviton-basierte RG-Instanzen für Amazon Redshift eingeführt, wie Data Center Knowledge am 15. Mai berichtete. Die Kerndaten von AWS: bis zu 2,2x schnellere Data-Warehouse-Performance gegenüber der vorherigen RA3-Generation bei 30% niedrigeren Kosten pro vCPU. Apache-Iceberg-Workloads laufen bis zu 2,4x schneller, Apache Parquet bis zu 1,5x schneller – beide gemessen gegen RA3.

Die strukturelle Veränderung ist wichtiger als die Benchmark-Folie. RG-Instanzen vereinen Warehouse- und Data-Lake-Abfragen in einer einzigen Engine. AWS zufolge laufen Abfragen auf Warehouse-Daten und auf offenen Tabellenformaten in S3 nun von derselben Compute-Schicht aus – ohne die separate Redshift-Spectrum-Infrastruktur, die bislang pro gescanntem Terabyte in Rechnung gestellt wurde. Diese Scan-Gebühren entfallen auf diesem Pfad.

AWS positionierte die Instanzen ausdrücklich für „Analytics- und Agentic-AI-Workloads", die latenzarmen Zugriff auf große Datensätze benötigen. Die Interna: Eine eingebaute vektorisierte Query-Engine verarbeitet Iceberg- und Parquet-Daten direkt auf den Cluster-Knoten, und lokales NVMe-Caching hält heiße Datensätze nah an der Compute-Schicht.

Matt Kimball, Vice President und Principal Analyst für Datacenter-Technologien bei Moor Insights & Strategy, erklärte gegenüber Data Center Knowledge: „AWS adressiert wesentliche Herausforderungen, die für jedes Unternehmen relevant sind: Performance, TCO und Komplexität." Zur Preis-/Leistungsdifferenz war er direkt: „Wenn man Zahlen wie 2,2x schneller bei Data-Warehouse-Workloads und 2,4x bei Apache Iceberg sieht – kombiniert mit 30% niedrigerem Preis pro vCPU –, ist es schwer, das als inkrementell in der Kosten-/Leistungskennzahl zu bezeichnen." Kimball hob auch die strategische Lesart hervor: „AWS scheint sein Silizium den Stack hinaufzubewegen. Nicht nur in die Infrastruktur wie EC2, sondern in die Daten- und Analytics-Schicht selbst."

Technische Anatomie

Drei Architekturelemente erledigen hier die Arbeit, und Plattformverantwortliche sollten jede davon unabhängig verstehen, da sie unterschiedliche Lebenszyklen auf einer Roadmap haben.

Erstens das Silizium. Graviton ist AWS' eigene Arm-Prozessorfamilie. Indem AWS Graviton unter Redshift einsetzt, besitzt AWS den Margin-Stack vom Wafer bis zum SQL-Parser. So lässt sich ein 30%iger Preisnachlass pro vCPU mit einem Performance-Zuwachs vereinbaren: AWS verkauft auf dieser Ebene kein Intel- oder AMD-Silizium weiter, kann also gegen die eigene Kostenkurve statt gegen die eines Zulieferers kalkulieren. Snowflake und Databricks, die beide auf fremdem Compute laufen, können diese Mathematik nicht nachahmen, ohne das Substrat neu zu verhandeln, auf dem sie aufsetzen. Snowflake-Kunden, die das Credit-Modell lesen, sollten darüber nachdenken, wer den Kostenvorteil von Arm beim nächsten Verlängerungszyklus absorbiert.

Zweitens die Engine. Bislang fragte Redshift externe S3-Daten über Redshift Spectrum ab – einen separaten Dienst mit eigener Infrastruktur und terabytebezogener Scan-Abrechnung. Die RG-Architektur eliminiert diesen Umweg. Eine vektorisierte Engine auf dem Cluster liest Iceberg und Parquet direkt, mit lokalem NVMe-Caching für das Working Set. Das ist dieselbe architektonische Richtung, die ClickHouse vor Jahren einschlug: vektorisierte Ausführung nahe am Storage mit aggressivem Caching. Dass AWS bei diesem Design angelangt ist, zeigt, wo sich mainstream Cloud-Analytics einpendelt.

Drittens das Tabellenformat. Iceberg ist nun ein erstklassiger Bestandteil von Redshifts Compute-Pfad, kein föderierter Gast mehr. Das ist eine stille, aber bedeutsame Wette: AWS signalisiert, dass Kundendaten in offenen Formaten auf Object Storage leben werden und das Warehouse zur Query-Engine wird, die man darüber mietet. Das Lock-in verlagert sich von Datengravitation zu Engine-Ergonomie – eine völlig andere Verhandlung, wenn die Vertragsverlängerung kommt.

Das „Agentic-AI"-Framing ist Marketing, aber das Substrat ist real. Agenten-Workloads erzeugen stoßartige, unvorhersehbare Lesemuster auf breiten Datensätzen. Per-TB-Scan-Gebühren machten das finanziell unattraktiv. Deren Wegfall verändert, welche Workloads sich wirtschaftlich interaktiv betreiben lassen.

Wer unter Druck gerät

Beginnen wir mit dem offensichtlichen Angriffsziel: Snowflakes Mid-Market-Kundenstamm. Teams, die stabile Warehouse-Workloads auf Snowflake betreiben und wachsende Iceberg-Ambitionen haben, sind genau das Segment, gegen das AWS jetzt seinen Preis gesetzt hat. Das 30%ige Per-vCPU-Delta wird sich nicht eins zu eins in eine 30%ige Rechnungsreduzierung übersetzen (Workloads sind nicht direkt vergleichbar), gibt einem CFO aber genug Munition, um einen Verlängerungsrabatt zu fordern oder einen parallelen POC zu starten. Snowflakes jüngster Iceberg-Vorstoß sollte diese Flanke verteidigen. Jetzt muss sie auch preislich verteidigt werden.

Databricks ist weniger direkt betroffen, da sein Schwerpunkt auf ML- und Spark-Workloads auf Delta Lake liegt. Aber die Iceberg-Performance-Zahlen komprimieren den Analytics-only-Anwendungsfall, bei dem Databricks SQL mit Redshift konkurriert. Schärfere Photon-Preisverhandlungen sind zu erwarten.

Im Enterprise-IT-Bereich ist der Druck interessanter. Data-Platform-Teams, die aufwendige Spectrum-zu-Redshift-Kostenmanagement-Tools, Query-Router, Scan-Budget-Alerts und Materialized-View-Strategien zur Vermeidung von Per-TB-Gebühren gebaut haben, haben gerade erlebt, wie ein Teil dieser Arbeit zum Legacy wurde. Kimballs eigene Formulierung trifft zu: „Als Enterprise-IT-Leiter möchte ich reduzieren, wie viel ich Daten duplizieren und bewegen muss." Die Teams, die ihre Karriere auf dem Management dieser Duplizierung und Bewegung aufgebaut haben, haben nun eine kleinere Fläche zu verteidigen.

Der CFO jedes Series-B-Fintechs oder iGaming-Operators, der Redshift betreibt, sollte diese Woche den VP Engineering fragen: Wie sieht unsere annualisierte Redshift-Rechnung auf RG-Instanzen bei aktueller Workload aus, und was kostet die Migration, um das herauszufinden? Das ist ein Zwei-Wochen-Spike, keine quartalsweite Initiative, und die Antwort stellt das FY27-Datenplattformbudget neu auf. Wenn der VP Engineering innerhalb von zehn Werktagen keine Zahl liefern kann, hat die Data-Org ein Planungsproblem, das unabhängig von AWS besteht.

Regulierte Branchen erhalten einen zusätzlichen Vorteil. Die Integration von Spectrum in die Kern-Engine reduziert die Anzahl der Service-Grenzen, über die Auditoren nachdenken müssen. Weniger serviceweise Logs, weniger IAM-Oberflächen, weniger Abrechnungsposten, die gegen Datenresidenz-Anforderungen abgeglichen werden müssen. GCs bei lizenzierten Betreibern sollten das – stillschweigend – begrüßen.

Playbook für Data-Teams

Konkrete Maßnahmen für die nächsten 30 bis 90 Tage, geordnet nach Nutzwert.

Führen Sie den RG-Benchmark mit Ihrer tatsächlichen Workload durch, nicht mit der von AWS. Die 2,2x- und 2,4x-Zahlen sind vom Anbieter veröffentlicht. Wählen Sie Ihre drei teuersten wiederkehrenden Abfragen (jene, über die Product Manager klagen) und Ihre zwei Spectrum-Jobs mit den höchsten Scan-Kosten, spielen Sie sie auf einem RG-Cluster ab und erfassen Sie sowohl die Wanduhrzeit als auch die prognostizierten monatlichen Ausgaben. Diese Daten sind das Argument bei der nächsten Snowflake- oder Databricks-Verlängerung, selbst wenn Sie nie migrieren.

Prüfen Sie Ihre Iceberg-Bereitschaft. Wenn Ihr Lake noch Parquet-on-S3 mit Glue-Katalog und ohne Tabellenformat ist, lassen Sie die größere Hälfte des Performance-Gewinns liegen. Iceberg-Adoption ist nun eine Beschaffungsentscheidung, nicht nur eine Engineering-Präferenz. Dokumentieren Sie den Migrationspfad und die Kosten.

Überprüfen Sie Ihren Semantic Layer. Wenn Transformationen in dbt gegen Redshift laufen, ist die Migrationsstory unkompliziert – Modelle sind Warehouse-portabel. Wenn sie in Snowflake-spezifischen oder Databricks-spezifischen Konstrukten leben, sind die Lock-in-Kosten gerade zu einem quantifizierbaren Posten geworden.

Sprechen Sie mit Ihrem AWS-Account-Team über Committed-Use-Rabatte auf RG, bevor der Standardlistenpreis zum Verhandlungsboden wird. New-Instance-Launches sind das Zeitfenster, in dem AWS-Vertreter die größte Flexibilität haben. Dieses Fenster ist jetzt offen und schließt sich, sobald der SKU Mainstream ist.

Abschließend zum Thema Einstellungen: Arm-natives Performance-Tuning ist eine Nischenfähigkeit, die bald mehr zählen wird. Der Pool an Engineers, die eine vektorisierte Query-Engine auf Graviton profilen und über NVMe-Cache-Lokalität nachdenken können, ist kleiner als der Pool derer, die ein Snowflake-Warehouse tunen können. Passen Sie Stellenbeschreibungen und Vergütungsbänder entsprechend an, bevor der Markt es tut.

Key Takeaways

• AWS Redshift RG-Instanzen versprechen bis zu 2,2x schnellere Warehouse-Performance und 30% niedrigere Kosten pro vCPU gegenüber RA3, mit Iceberg-Workloads bis zu 2,4x schneller.
• Die integrierte Engine eliminiert die separate Redshift-Spectrum-Infrastruktur und ihre Terabyte-Scan-Gebühren und verändert damit die Unit-Economics von Lake-Abfragen.
• AWS' Kontrolle über den Silizium-zu-SQL-Stack via Graviton ist ein struktureller Preisvorteil, den Snowflake und Databricks auf Substratebene nicht leicht egalisieren können.
• Der Konkurrenzdruck trifft am härtesten Mid-Market-Snowflake-Kunden mit Iceberg-Ambitionen sowie internes Kostenmanagement-Tooling, das auf Spectrums Abrechnungsmodell aufgebaut wurde.
• Teams, die ihr FY27-Analytics-Platform-Commitment evaluieren, sollten jetzt fragen, was ihre tatsächlichen Workload-Kosten auf RG sind – vor dem nächsten Verlängerungsgespräch mit jedem bestehenden Anbieter.