Der Grundgedanke ist derselbe wie bei einem klassischen Data Warehouse, nur konsequent für die Cloud gedacht: Redshift bündelt Analysedaten aus vielen Quellen an einem zentralen Ort und macht sie über SQL blitzschnell auswertbar. Der entscheidende Unterschied zu einer selbst betriebenen Datenbank ist, dass AWS die zugrunde liegende Infrastruktur bereitstellt und verwaltet – bei der Serverless-Variante bis hin zu vollständig automatisch bereitgestellter Rechenleistung. Sie konzentrieren sich auf Daten und Abfragen, nicht auf Server-Hardware.
Drei Eigenschaften definieren Amazon Redshift:
In Projektgesprächen werden diese Begriffe oft synonym verwendet, obwohl sie Unterschiedliches meinen. Eine Datenbank im operativen Sinn (etwa PostgreSQL, MySQL oder Microsoft SQL Server) ist für das schnelle Schreiben und Lesen einzelner Datensätze in Anwendungen optimiert – etwa für ein Bestellsystem. Ein Data Warehouse ist dagegen für analytische Abfragen über große Datenmengen ausgelegt, also für Fragen wie „Wie hat sich unsere Marge nach Region und Produktgruppe über drei Jahre entwickelt?“. Amazon Redshift ist im Kern ein solches analytisches Data Warehouse.
Der Zusatz Cloud bedeutet dabei, dass Sie diese Infrastruktur nicht selbst besitzen und im eigenen Rechenzentrum betreiben, sondern als Dienst von AWS beziehen. Für die Praxis ist die begriffliche Feinheit weniger wichtig als das Grundverständnis: Redshift ist der zentrale Ort, an dem Ihre Analysedaten leben – und aus dem heraus Berichte, Dashboards und datengetriebene Anwendungen gespeist werden.
Amazon Redshift wurde bereits Anfang der 2010er-Jahre eingeführt und war eines der ersten Cloud Data Warehouses überhaupt. Dieser lange Reifeprozess erklärt eine zentrale Stärke: Redshift ist ein robustes, breit erprobtes System mit einem großen Ökosystem an Werkzeugen, Beratern und Erfahrungswissen. Zugleich hat sich das Produkt über die Jahre stark gewandelt – von einem rein cluster-basierten Dienst hin zu einer Plattform, die mit der Serverless-Variante, moderner Skalierung und integrierten KI-Funktionen den Vergleich mit jüngeren Wettbewerbern nicht scheuen muss. Für Mittelständler bedeutet das: Sie setzen auf ein ausgereiftes Fundament, das dennoch aktiv weiterentwickelt wird und nicht am Markt zurückfällt.
Der wichtigste Unterschied betrifft die Frage, wer über die Rechenkapazität entscheidet. Im Provisioned-Modell wählen Sie einen Knotentyp und die Anzahl der Knoten und betreiben damit einen dauerhaft laufenden Cluster. Das gibt Ihnen volle Kontrolle und ist bei einer stabilen, planbaren Dauerlast häufig kostengünstig – verlangt aber, dass Sie die Kapazität richtig dimensionieren und den Cluster im Blick behalten. Im Serverless-Modell geben Sie diese Verantwortung an AWS ab: Sie legen im Wesentlichen nur Grenzen fest, und AWS stellt die passende Rechenleistung automatisch bereit und rechnet nach tatsächlichem Verbrauch ab. Das senkt den Betriebsaufwand deutlich und eignet sich besonders für schwankende Lasten und den Einstieg.
Für viele Mittelständler ist die Serverless-Variante heute der pragmatische Startpunkt: Man beginnt klein, ohne einen Cluster überdimensionieren zu müssen, und zahlt nur für die tatsächlich genutzte Rechenleistung. Erreicht die Nutzung ein stabiles, hohes Dauerniveau, kann ein Wechsel oder eine Kombination mit der Provisioned-Variante wirtschaftlich sinnvoll werden. Welche Variante günstiger ist, hängt vom konkreten Nutzungsmuster ab und ist eine Rechnung für den Einzelfall – nicht pauschal beantwortbar.
Im Provisioned-Modell besteht ein Redshift-Cluster aus mehreren Rechenknoten, über die Daten und Abfragen verteilt werden. AWS bietet verschiedene Knotentypen an, die sich in der Balance zwischen Rechenleistung und Speicherkapazität unterscheiden. Neuere Knotengenerationen trennen zudem Rechenleistung und Speicher stärker voneinander – ein Prinzip, das die anderen modernen Cloud-Warehouses ebenfalls verfolgen: Es erlaubt, Rechen- und Speicherkapazität unabhängig voneinander wachsen zu lassen, statt beides immer gemeinsam skalieren zu müssen. Für die Praxis bedeutet das mehr Flexibilität und eine bessere Kostenanpassung an das tatsächliche Nutzungsprofil.
So wie BigQuery an die Google Cloud und Microsoft Fabric an Azure gebunden ist, ist Redshift eng mit AWS verwoben. Das ist zugleich seine größte Stärke und seine wichtigste Kehrseite: Die tiefe Integration macht Redshift innerhalb einer AWS-Landschaft außerordentlich mächtig und komfortabel, bindet die Datenplattform aber an einen einzelnen Cloud-Anbieter. Wer Redshift einführt, entscheidet sich – zumindest für diesen Teil der Datenlandschaft – bewusst für AWS als Plattform. Diese strategische Weichenstellung sollte aktiv getroffen und nicht nebenbei entschieden werden. Cloud-neutrale Alternativen wie Snowflake existieren gerade für Unternehmen, die sich diese Bindung nicht wünschen.
Die beiden prägenden Prinzipien von Redshift wirken erst im Zusammenspiel. Die spaltenorientierte Speicherung sorgt dafür, dass eine analytische Abfrage nur die tatsächlich benötigten Spalten liest – bei einer Auswertung des Umsatzes nach Region etwa nur die Spalten „Umsatz“ und „Region“, nicht die gesamte Tabelle mit allen Feldern. Zusätzlich lassen sich spaltenweise gespeicherte Daten sehr stark komprimieren, was Speicherplatz spart und die zu lesende Datenmenge weiter reduziert. Die massiv parallele Verarbeitung verteilt diese Leseoperation dann auf viele Rechenknoten, die gleichzeitig an unterschiedlichen Datenabschnitten arbeiten. Wo eine klassische, zeilenorientierte Datenbank bei Milliarden von Zeilen ins Straucheln gerät, beantwortet Redshift solche Abfragen durch die Kombination beider Prinzipien in überschaubarer Zeit.
Ein Punkt, an dem sich gute von schwachen Redshift-Implementierungen unterscheiden, sind die Verteil- und Sortierschlüssel. Der Verteilschlüssel bestimmt, wie die Zeilen einer Tabelle über die Rechenknoten verteilt werden; der Sortierschlüssel legt fest, in welcher Reihenfolge sie innerhalb eines Knotens abgelegt sind. Werden diese Schlüssel passend zu den typischen Abfragen gewählt, muss Redshift bei Verknüpfungen (Joins) und Filtern deutlich weniger Daten zwischen den Knoten bewegen und kann irrelevante Datenblöcke überspringen. Falsch gewählt, entstehen unnötige Datenbewegungen, die Abfragen ausbremsen. Neuere Redshift-Funktionen automatisieren einen Teil dieser Optimierung – doch ein grundlegendes Verständnis des Datenmodells bleibt für eine performante und wirtschaftliche Nutzung wichtig. Aus unserer Erfahrung ist eine durchdachte Datenmodellierung einer der unterschätzten Erfolgsfaktoren jeder Redshift-Einführung.
Als ausgereiftes, verwaltetes System bringt Redshift eine Reihe von Betriebs- und Sicherheitsfunktionen mit, die man von einer Unternehmensplattform erwartet: automatische Sicherungen und die Möglichkeit, einen Zustand zu einem früheren Zeitpunkt wiederherzustellen, Verschlüsselung der Daten im Ruhezustand und bei der Übertragung sowie eine feingliedrige Rechteverwaltung. Über die Einbindung in die zentrale AWS-Rechteverwaltung (IAM) lässt sich steuern, wer welche Daten sehen und welche Aktionen ausführen darf. Diese Funktionen laufen weitgehend im Hintergrund, sind für einen sicheren und datenschutzkonformen Betrieb aber essenziell – und ein wichtiger Grund, warum Redshift auch für regulierte Branchen eine ernst zu nehmende Option ist.
Der Leitgedanke folgt einem klaren Prinzip: Bring die Analyse und die KI zu den Daten, nicht die Daten zur Analyse. Statt große Datenmengen aus Redshift herauszukopieren, in einer separaten Umgebung zu verarbeiten und Ergebnisse zurückzuspielen, lässt Redshift viele Berechnungen direkt dort laufen, wo die Daten liegen. Das reduziert Datenbewegungen, vereinfacht die Governance und hält sensible Daten innerhalb der kontrollierten Plattform – ein Aspekt, der gerade unter Datenschutz-Gesichtspunkten relevant ist.
Redshift ML erlaubt es, Machine-Learning-Modelle direkt aus Redshift heraus zu erstellen, zu trainieren und anzuwenden – mit vertrauten SQL-Befehlen und in Zusammenarbeit mit dem AWS-Dienst für maschinelles Lernen (Amazon SageMaker), der im Hintergrund die eigentliche Modellierung übernimmt. Für Anwender bedeutet das: Datenanalysten müssen nicht zu Data Scientists werden, um typische Aufgaben abzudecken – etwa Absatzprognosen, die Einschätzung von Abwanderungsrisiken oder die Segmentierung von Kunden. Das bestehende SQL-Team kann erste ML-Anwendungen umsetzen, ohne zunächst eine eigene Data-Science-Abteilung aufbauen zu müssen.
Realistisch eingeordnet: Redshift ML ist stark für pragmatische Modelle auf strukturierten Unternehmensdaten und für den Einstieg ins maschinelle Lernen. Für hochspezialisierte Deep-Learning-Forschung mit großen Rechenanforderungen ist die dedizierte AWS-KI-Plattform (SageMaker) oder eine spezialisierte ML-Umgebung die naheliegendere Wahl – wobei Redshift und SageMaker eng zusammenarbeiten. Im typischen Mittelstands-Szenario deckt Redshift ML den Bedarf jedoch gut ab und senkt die Hürde, überhaupt mit maschinellem Lernen zu beginnen.
Ein zweiter Schwerpunkt ist die zunehmende Automatisierung des Betriebs. In der Serverless-Variante passt Redshift die Rechenkapazität automatisch an die aktuelle Last an – steigt die Zahl gleichzeitiger Abfragen, wird mehr Kapazität bereitgestellt; sinkt sie, wird wieder heruntergefahren. Aber auch die Provisioned-Variante kennt Mechanismen, um bei Lastspitzen vorübergehend zusätzliche Rechenleistung zuzuschalten (Concurrency Scaling), damit interaktive Abfragen nicht in einer Warteschlange hängen bleiben. Hinzu kommen selbstoptimierende Funktionen, die etwa Sortierschlüssel oder die Verteilung von Daten im Hintergrund automatisch anpassen. Diese Automatisierung nimmt Betriebsteams Arbeit ab – ersetzt aber nicht das grundlegende Verständnis dafür, wie Daten sinnvoll modelliert werden.
Wie die gesamte Branche integriert auch AWS zunehmend generative KI in seine Datenwerkzeuge – etwa assistierende Funktionen, die beim Schreiben und Erklären von SQL helfen oder Abfragen aus natürlichsprachlichen Beschreibungen erzeugen. Solche Assistenten entwickeln sich schnell weiter und sind ein vielversprechender Beschleuniger für erfahrene Anwender. Aus Beratungssicht empfehlen wir jedoch, sie zunächst als Werkzeug zu betrachten, das Routinearbeit abnimmt und Vorschläge liefert, statt sich blind auf generierte Abfragen zu verlassen. Jede von einer KI erzeugte Auswertung sollte fachlich geprüft werden, bevor Geschäftsentscheidungen darauf aufbauen.
Der typische Aufbau in unseren Projekten sieht so aus: Redshift ist die „Single Source of Truth“ – der eine, verlässliche Ort, an dem alle Analysedaten zusammenlaufen, sauber modelliert und mit Zugriffsrechten versehen. Darum herum liegen die Werkzeuge, die Daten einspeisen, transformieren und darstellen. Weil die Rechenleistung in Redshift liegt, bleiben die BI-Tools schlank: Sie schicken Abfragen an Redshift und stellen nur die Ergebnisse dar. Das hält auch große Datenmengen handhabbar.
Im Zentrum der AWS-Datenwelt steht Amazon S3 als kostengünstiger Objektspeicher – häufig die Landezone für Rohdaten und, über Spectrum, direkt aus Redshift abfragbar. Für den Datentransfer und die Aufbereitung bietet AWS eigene Dienste: etwa AWS Glue für ETL- und Katalogaufgaben, Dienste für Streaming-Daten sowie Werkzeuge zur Datenintegration aus operativen Datenbanken. Wer bereits in AWS zu Hause ist, findet damit den kompletten Weg von der Datenquelle bis ins Warehouse innerhalb einer Plattform abgebildet. Daneben verbinden sich die gängigen Integrationswerkzeuge des Marktes – etwa Fivetran, Airbyte oder Talend – problemlos mit Redshift und binden Standardquellen wie ERP-, CRM- und E-Commerce-Systeme an.
Ein häufig übersehener, aber entscheidender Baustein ist die Transformations-Schicht zwischen Rohdaten und BI. Werkzeuge wie dbt modellieren die Daten direkt in Redshift zu sauberen, dokumentierten und getesteten Analysetabellen, bevor sie ins BI-Tool gelangen. Dieser Schritt entscheidet maßgeblich über die Qualität und Vertrauenswürdigkeit der späteren Berichte – und ist aus unserer Sicht kein Nice-to-have, sondern Pflicht für eine belastbare Analytics-Landschaft.
Innerhalb der AWS-Welt ist Amazon QuickSight das native BI-Werkzeug, das besonders gut mit Redshift harmoniert und sich verbrauchsbasiert abrechnen lässt. In der Praxis des deutschen Mittelstands ist jedoch Microsoft Power BI das mit Abstand verbreitetste BI-Werkzeug – und auch die Anbindung an Redshift ist ausgereift. Power BI verbindet sich über einen nativen Connector und bietet die üblichen Modi: den Import-Modus, bei dem Daten ins Power-BI-Modell geladen werden (sehr schnell für Nutzer, aber mit regelmäßigen Aktualisierungen), und DirectQuery, bei dem die Rechenlast in Redshift bleibt und jede Interaktion als Abfrage durchgereicht wird. Auch Tableau und weitere gängige Werkzeuge sind problemlos anschließbar. Die Wahl des Modus hat unmittelbare Auswirkungen auf Aktualität, Performance und Kosten – in der Praxis bewährt sich häufig ein gemischter Ansatz.
Ein aktueller Trend in der AWS-Welt sind sogenannte Zero-ETL-Integrationen, die Daten aus operativen AWS-Datenbanken nahezu in Echtzeit und ohne aufwendige eigene Datenpipelines nach Redshift bringen. Die Grundidee: Der klassische, oft fehleranfällige Schritt des Extrahierens, Transformierens und Ladens (ETL) soll für bestimmte Konstellationen weitgehend entfallen, sodass analysierbare Daten schneller und mit weniger Wartungsaufwand bereitstehen. Für Unternehmen, deren operative Systeme ohnehin auf AWS laufen, kann das die Datenintegration erheblich vereinfachen. In der Praxis bleibt eine durchdachte Transformations- und Modellierungs-Schicht dennoch wichtig – Zero-ETL beschleunigt die Datenbereitstellung, ersetzt aber nicht das saubere Modellieren belastbarer Analysetabellen.
Alle vier sind im Kern leistungsfähige Cloud-Plattformen für SQL-Analytik über große Datenmengen, doch ihre Herkunft und Positionierung unterscheiden sich. Redshift und BigQuery sind jeweils an ihre Cloud (AWS bzw. Google Cloud) gebunden. Snowflake ist bewusst cloud-neutral und läuft auf mehreren Hyperscalern. Microsoft Fabric bündelt Data Warehouse, Data Lake und BI (mit Power BI) zu einer integrierten Plattform innerhalb der Microsoft-Welt. Der wichtigste Auswahlfaktor ist daher oft nicht die reine Technik, sondern in welcher Cloud-Landschaft ein Unternehmen bereits zu Hause ist.
Aus unserer Beratungspraxis kristallisieren sich klare Muster heraus. Redshift ist meist die richtige Wahl, wenn ein Unternehmen ohnehin tief in der AWS-Welt verankert ist – etwa weil operative Systeme, Datenspeicher oder Anwendungen bereits auf AWS laufen. Dann ist Redshift der Weg des geringsten Widerstands: Die Daten sind ohnehin „in der Nähe“, Rechte und Sicherheit lassen sich zentral verwalten, und die Serverless-Variante erlaubt einen einfachen Einstieg. Auch wer ein ausgereiftes, breit erprobtes Warehouse mit großem Ökosystem sucht, ist bei Redshift gut aufgehoben.
BigQuery ist oft naheliegend, wenn ein Unternehmen in der Google-Welt zu Hause ist und einen vollständig serverlosen Betrieb ohne jegliche Cluster-Verwaltung wünscht. Snowflake spielt seine Stärken aus, wenn bewusst eine cloud-neutrale Plattform gewünscht ist, die sich nicht an einen einzelnen Hyperscaler bindet. Microsoft Fabric ist meist die erste Wahl für Unternehmen, die bereits stark mit Microsoft 365, Azure und Power BI arbeiten und eine integrierte End-to-End-Plattform bevorzugen. Wichtig: Es gibt selten ein objektiv „bestes“ System – die richtige Wahl hängt von Datenstrategie, vorhandenen Kompetenzen und der bestehenden Cloud-Landschaft ab.
Der häufigste Fehler ist, Redshift als Selbstzweck einzuführen – „weil wir jetzt ein Data Warehouse brauchen“. Erfolgreiche Projekte starten umgekehrt: mit einem konkreten, schmerzhaften Geschäftsproblem. Typische Einstiegs-Use-Cases im Mittelstand sind etwa ein abteilungsübergreifendes Vertriebs- und Deckungsbeitrags-Reporting, das heute mühsam aus mehreren Systemen in Excel zusammengetragen wird; die Zusammenführung von Marketing- und Vertriebsdaten zu einer belastbaren Auswertung; oder eine 360-Grad-Sicht auf den Kunden aus ERP-, CRM- und Webshop-Daten.
Der Vorteil dieses Vorgehens: Ein klar umrissener erster Anwendungsfall liefert schnell sichtbaren Wert, schafft Akzeptanz im Unternehmen und hält den Aufwand überschaubar. Die Serverless-Variante von Redshift unterstützt das ideal – Sie können klein beginnen und wachsen, ohne anfangs einen großen Cluster dimensionieren und dauerhaft betreiben zu müssen.
Steht der erste Use-Case, geht es an die Daten. In den meisten Fällen müssen Daten aus den Quellsystemen regelmäßig nach Redshift geladen werden. Hier kommen die in Kapitel 05 beschriebenen Wege ins Spiel – AWS-eigene Dienste wie Glue und S3, Zero-ETL-Integrationen ebenso wie spezialisierte Integrationswerkzeuge des Marktes. Direkt in Redshift werden die Rohdaten anschließend in saubere, dokumentierte Analysetabellen modelliert und mit sinnvollen Verteil- und Sortierschlüsseln versehen – ein Schritt, der über spätere Performance, Kosten und Datenqualität entscheidet.
Wer von einem bestehenden, klassischen Data Warehouse migriert, sollte den Aufwand nicht unterschätzen: SQL-Dialekte unterscheiden sich, gewachsene Logik muss überprüft und oft neu strukturiert werden, und nicht jede alte Berechnung verdient es, eins zu eins übernommen zu werden. Eine Migration ist immer auch eine Chance, Altlasten zu bereinigen. Wir empfehlen ein schrittweises Vorgehen pro Datenbereich statt eines riskanten Big-Bang-Umzugs.
Ein zentraler Erfolgsfaktor ist Governance – und zwar von Beginn an. Dazu gehört ein durchdachtes rollenbasiertes Rechtekonzept über die zentrale AWS-Rechteverwaltung (IAM) und die Datenbankrechte in Redshift, das festlegt, wer welche Daten sehen und welche Abfragen ausführen darf. Dazu gehören klare Namens- und Strukturkonventionen für Datenbanken, Schemata und Tabellen, damit die Plattform nicht im Wildwuchs endet. Und dazu gehört die Kostensteuerung, auf die Kapitel 09 näher eingeht. Gerade im Mittelstand, wo oft wenige Personen viele Rollen tragen, ist diese Struktur entscheidend, damit die Plattform auch nach dem ersten Projekt wartbar und sicher bleibt. AWS macht den technischen Betrieb – gerade mit der Serverless-Variante – einfach; die organisatorische Disziplin müssen Sie selbst mitbringen.
Besonders naheliegend ist Redshift für Unternehmen, deren digitale Infrastruktur bereits auf AWS läuft – etwa der Online-Shop, die Kundenanwendung oder zentrale Fachsysteme. Deren Daten lassen sich mit vergleichsweise geringem Aufwand nach Redshift bringen und dort mit den kaufmännischen Daten aus ERP und CRM verknüpfen. So entsteht eine belastbare Sicht darauf, welche Kunden, Produkte oder Kanäle tatsächlich profitabel sind – eine Frage, die viele Unternehmen mit isolierten Tool-Berichten nicht sauber beantworten können.
Weitere typische Felder sind ein unternehmensweites Management-Reporting, das Kennzahlen aus verschiedenen Abteilungen zusammenführt; die Auswertung von Produktions- und Maschinendaten gemeinsam mit kaufmännischen Kennzahlen; oder die Analyse großer Mengen an Transaktions- und Ereignisdaten, etwa aus einem Online-Shop oder einer digitalen Anwendung. In all diesen Fällen spielt Redshift seine Stärke aus, sehr große Datenmengen ohne eigenen Server-Betrieb schnell analysierbar zu machen.
Ein erster, klar umrissener Redshift-Use-Case – von der Anbindung der Quellsysteme über die Datenmodellierung bis zum produktiven Dashboard – ist in vielen Mittelstands-Projekten in wenigen Wochen bis wenigen Monaten umsetzbar, gerade wenn die Serverless-Variante genutzt wird und bereits eine AWS-Basis besteht. Der Aufbau einer breiten, unternehmensweiten Datenplattform mit vielen Quellen, sauberer Governance und mehreren Fachbereichen ist dagegen ein fortlaufendes Programm über mehrere Monate. Wer mit einem fokussierten Pilotprojekt startet und daraus lernt, baut die Plattform tragfähig aus – statt sich an einem überdimensionierten Erstwurf zu verheben. Genau an dieser Schnittstelle zwischen Technik, Daten und Organisation setzt unsere Beratungsarbeit an.
Redshift rechnet je nach Betriebsvariante unterschiedlich ab. Im Provisioned-Modell zahlen Sie im Kern für die Laufzeit und Größe Ihres Clusters – also für die bereitgestellte Rechen- und Speicherkapazität, unabhängig davon, wie stark sie genutzt wird. Im Serverless-Modell zahlen Sie verbrauchsorientiert für die tatsächlich genutzte Rechenleistung sowie für den Speicher. Hinzu kommen je nach Nutzung weitere Komponenten, etwa für Spectrum-Abfragen auf S3 oder für Zusatzfunktionen. Konkrete Eurobeträge nennen wir bewusst nicht – die Preise unterscheiden sich je nach Variante, Knotentyp, Region und Vertrag und ändern sich über die Zeit. Verlässlich ist nur das Prinzip: Sie zahlen für bereitgestellte oder verbrauchte Rechenleistung und für gespeicherte Daten, und beides lässt sich aktiv steuern.
Die häufigste böse Überraschung entsteht nicht durch Redshift selbst, sondern durch unbedachte Nutzung. Typische Ursachen sind: ein dauerhaft laufender Provisioned-Cluster, der deutlich größer dimensioniert ist als nötig; ineffizient modellierte Tabellen mit schlecht gewählten Verteil- und Sortierschlüsseln, sodass jede Abfrage unnötig viele Daten bewegt; sowie ineffizient gebaute Dashboards, die bei jeder Interaktion große Datenmengen anfassen. Die gute Nachricht: Genau hier liegen auch die wirksamsten Hebel zur Kostenkontrolle.
Aus unserer Sicht ist die Kostensteuerung kein einmaliges Setup, sondern eine laufende Disziplin – vergleichbar mit dem bewussten Umgang mit Cloud-Ausgaben generell (oft als „FinOps“ bezeichnet). Unternehmen, die von Anfang an klare Verantwortlichkeiten, Budgets und Monitoring etablieren, erleben Redshift als planbar und wirtschaftlich. Der Unterschied liegt nicht in der Technik, sondern in der Governance.
Redshift ist ein Dienst von Amazon Web Services, einem US-amerikanischen Konzern, der auf AWS-eigener globaler Infrastruktur läuft. Für deutsche und europäische Unternehmen wirft das berechtigte Fragen zu Datenschutz und Datenhoheit auf. AWS bietet hier wichtige Stellschrauben – die endgültige Bewertung bleibt jedoch eine Frage des Einzelfalls.
Der wichtigste Hebel für die Datenhoheit ist die Wahl der AWS-Region. AWS ist in zahlreichen Regionen weltweit verfügbar – darunter mehrere in der Europäischen Union, etwa Frankfurt (eu-central-1), Irland oder Paris. Wer eine EU-Region wählt, sorgt dafür, dass die betreffenden Daten physisch in europäischen Rechenzentren liegen und dort verarbeitet werden. Das ist eine notwendige Grundlage für einen DSGVO-konformeren Betrieb und reduziert das Risiko, dass Daten unbeabsichtigt in Drittländer abfließen. AWS stellt zudem die üblichen vertraglichen Instrumente bereit – insbesondere einen Auftragsverarbeitungsvertrag und Standardvertragsklauseln – und verfügt über etablierte Zertifizierungen und Sicherheitsstandards.
Bestehen bleibt – auch bei Speicherung in einer EU-Region – ein grundsätzliches Thema: Amazon ist ein US-Mutterkonzern und unterliegt damit potenziell US-amerikanischem Recht, ein Punkt, der seit den Schrems-Urteilen und der Diskussion um den US Cloud Act kontrovers bewertet wird. Die EU-Region adressiert den Aspekt der Datenlokalisierung, beseitigt aber nicht jedes theoretische Zugriffsrisiko, das aus der US-Konzernzugehörigkeit folgen könnte. In der Praxis ist dieses Restrisiko für viele Mittelständler mit überschaubar sensiblen Analysedaten vertretbar – insbesondere mit EU-Region, sauberem Auftragsverarbeitungsvertrag, Verschlüsselung und Datenminimierung. Für besonders schützenswerte Datenkategorien oder hohe Souveränitätsanforderungen kann die Bewertung anders ausfallen; dann sind zusätzliche Schutzmaßnahmen, eine Datenschutz-Folgenabschätzung oder europäische bzw. souveräne Alternativen zu prüfen.
