DSGVO-konforme AWS-Architektur: Daten in der EU halten

Irgendwann fragt jeder Geschäftsführer: Sind unsere Daten auf AWS DSGVO-konform? Die übliche Antwort, "wir sind in Frankfurt", klingt beruhigend und greift zu kurz. Wo die Daten liegen, ist nur die halbe Frage. Die andere Hälfte ist, wer rechtlich Zugriff erzwingen kann, und genau da wird es 2026 kompliziert.

Dieser Artikel trennt die beiden Hälften sauber, ordnet die Rechtslage ein, zeigt drei Stufen von EU-tauglich auf AWS und liefert eine Checkliste, mit der ein Team das eigene Setup prüfen kann. Eines vorweg: Das ist ein Architektur- und Entscheidungs-Leitfaden, kein Rechtsgutachten. Die rechtliche Einordnung gehört am Ende zu einem Fachanwalt für IT-Recht. Die Architektur schafft die Grundlage, der Vertrag macht sie belastbar.

Versionsstand ist Juli 2026, Region eu-central-1 (Frankfurt) als Referenz.

Datenresidenz ist nicht Datensouveränität

Die wichtigste Unterscheidung des ganzen Themas steckt in zwei Wörtern, die oft synonym verwendet werden, obwohl sie verschiedene Dinge meinen.

Datenresidenz ist, wo die Daten physisch liegen. eu-central-1 hält sie in Frankfurt, eu-west-1 in Irland. Das ist die einfache, technische Hälfte, und sie ist mit der Wahl einer EU-Region erledigt.

Datensouveränität ist, wer rechtlich Zugriff erzwingen kann, unabhängig vom physischen Standort. Hier kommt der CLOUD Act ins Spiel. Ein US-kontrollierter Anbieter kann unter US-Recht zur Herausgabe von Daten gezwungen werden, auch wenn diese Daten in der EU liegen und der Zugriff dem EU-Recht widerspricht. Die Daten sind in Frankfurt, die rechtliche Reichweite bleibt amerikanisch.

Die Konsequenz ist unbequem: Eine EU-Region löst die Residenz, nicht automatisch die Souveränität. Wer beides verwechselt, hält sich für sicherer, als er ist. Das ist kein Grund zur Panik, aber der Ausgangspunkt für jede ehrliche Bewertung.

Die Rechtslage 2026

Schrems II und das Privacy-Shield-Aus

2020 kippte der Europäische Gerichtshof im Schrems-II-Urteil den Privacy Shield, die damalige Grundlage für transatlantische Datentransfers. Der Grund: US-Überwachungsrecht, konkret Section 702 FISA und Executive Order 12333, erlaubt US-Geheimdiensten Zugriffe auf Daten bei US-Unternehmen, die über das hinausgehen, was nach EU-Recht verhältnismäßig ist. Das ist strukturell mit den Garantien der DSGVO unvereinbar.

Data Privacy Framework und Schrems III

Im Juli 2023 verabschiedete die EU-Kommission den Angemessenheitsbeschluss für das EU-US Data Privacy Framework, den Nachfolger des Privacy Shield. Das Problem: Es steht bereits wieder vor Gericht, auf im Kern denselben Gründen. Die Schrems-III-Klage liegt beim EuGH, und eine Entscheidung wird für Ende 2026 erwartet. Der zugrunde liegende Konflikt ist 2026 ungelöst.

Standard Contractual Clauses, also Standard-Vertragsklauseln, bleiben das gültige Übertragungsmittel, und AWS-Kunden können sich für Datentransfers außerhalb des EWR weiter darauf stützen. Aber der Europäische Datenschutzausschuss und die EU-Kommission gehen davon aus, dass Daten bei US-kontrollierten Anbietern ein Restrisiko tragen, das Vertragsklauseln allein nicht beseitigen. Die ehrliche Einordnung für 2026: Wer sich allein auf das Framework stützt, baut auf eine Position, die die europäische Justiz schon einmal verworfen hat und erneut prüfen soll. Das ist ein Grund, die eigene Risikoposition bewusst zu wählen, statt sie zu ignorieren.

Drei Stufen von EU-tauglich auf AWS

In der Praxis gibt es nicht "konform oder nicht", sondern drei Stufen, die sich in Aufwand und Restrisiko unterscheiden.

Stufe 1: EU-Region plus Basis

Eine EU-Region wie eu-central-1, Verschlüsselung at rest und in transit, Standard-Vertragsklauseln und ein unterschriebener Auftragsverarbeitungsvertrag. Für viele Mittelständler ist das die pragmatische Wahl, mit einem bewusst akzeptierten CLOUD-Act-Restrisiko. Wichtig ist das Wort "bewusst": Die Stufe ist legitim, solange die Entscheidung getroffen und dokumentiert ist, nicht versehentlich.

Stufe 2: plus harte Kontrollen

Dieselbe Basis, zusätzlich kundenverwaltete KMS-Schlüssel statt der von AWS verwalteten, gesperrte Cross-Region-Replikation, EU-only-Guardrails per Service Control Policy und eine echte Datenklassifizierung. Das beseitigt das rechtliche Restrisiko nicht, reduziert aber die praktische Angriffsfläche deutlich, weil der Kunde die Schlüssel kontrolliert und keine Daten unbemerkt die EU verlassen.

Stufe 3: European Sovereign Cloud

Seit dem 15. Januar 2026 ist die AWS European Sovereign Cloud in Brandenburg generell verfügbar. Sie ist physisch und logisch von den bestehenden AWS-Regionen getrennt und wird ausschließlich von EU-ansässigem Personal betrieben. Sie hat eine eigene Partition (aws-eusc), eine eigene Region (eusc-de-east-1), eigenes IAM, eigenes Billing und eigene Route-53-Nameserver, alles innerhalb der EU. Betrieben wird sie über eine EU-Rechtsperson unter deutschem Recht. Das ist mehr als Datenresidenz: operative Souveränität mit technischen Kontrollen, die einen Zugriff von außerhalb der EU verhindern sollen.

Die ehrliche Einordnung: Die meisten Mittelständler liegen bei Stufe 1 oder 2 richtig. Stufe 3 ist für Gesundheit, öffentliche Hand, Finanz und vergleichbar regulierte Bereiche, oder wenn ein Kunde oder eine Aufsichtsbehörde nachweisbare Souveränität verlangt. Und nicht jeder Dienst ist in der Sovereign Cloud sofort verfügbar, das gehört vor einer Entscheidung geprüft.

Praktische Architektur, um Daten in der EU zu halten

Region pinnen und Guardrails

Der erste und wichtigste Schritt ist banal und wird trotzdem oft ausgelassen: Nur EU-Regionen erlauben und alle anderen per Service Control Policy sperren. Das verhindert, dass jemand versehentlich in us-east-1 deployt, der Default-Region vieler Tools und Tutorials. Eine SCP, die genau das tut:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyNonEuRegions",
      "Effect": "Deny",
      "NotAction": [
        "iam:*",
        "organizations:*",
        "route53:*",
        "cloudfront:*",
        "support:*"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": ["eu-central-1", "eu-west-1"]
        }
      }
    }
  ]
}

Die ausgenommenen Dienste sind global und haben kein Regions-Konzept im klassischen Sinn. Genau diese globalen Dienste, IAM, CloudFront und Route 53, gehören geprüft: Bei CloudFront etwa muss man wissen, wo Inhalte zwischengespeichert werden, und gegebenenfalls die Edge-Standorte einschränken.

Verschlüsselung mit eigenen Schlüsseln

Wer den Schlüssel kontrolliert, kontrolliert den Zugriff. Deshalb gehören sensible Daten unter kundenverwaltete KMS-Schlüssel, nicht unter die von AWS standardmäßig verwalteten. Die Key-Policy legt fest, wer den Schlüssel nutzen darf, und damit, wer die Daten überhaupt lesen kann:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "EnableRootAccount",
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::123456789012:root" },
      "Action": "kms:*",
      "Resource": "*"
    },
    {
      "Sid": "AllowAppRole",
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::123456789012:role/laravel-task-role" },
      "Action": ["kms:Decrypt", "kms:GenerateDataKey"],
      "Resource": "*"
    }
  ]
}

Dazu kommt das Sperren der Cross-Region-Replikation in Nicht-EU-Regionen, ebenfalls per SCP erzwungen, eine Datenklassifizierung, die personenbezogene Daten kennt und taggt, und CloudTrail mit Logs in einer EU-Region, damit nicht ausgerechnet das Audit-Log die Residenz bricht.

AVV und geteilte Verantwortung

Die Technik ist die eine Hälfte, der Vertrag die andere. AWS bietet einen DSGVO-konformen Auftragsverarbeitungsvertrag, den AVV. Darin ist der Kunde der Verantwortliche und AWS der Auftragsverarbeiter. Diese Rollenverteilung ist wichtig, weil sie die Verantwortung klar zieht.

Das Modell der geteilten Verantwortung bedeutet konkret: AWS sichert die Infrastruktur, der Kunde verantwortet Daten, Konfiguration und Zugriffe. Eine öffentlich erreichbare S3-Bucket mit personenbezogenen Daten ist das Problem des Kunden, nicht von AWS. Die meisten DSGVO-Vorfälle in der Cloud sind Fehlkonfigurationen auf der Kundenseite, keine Versäumnisse des Anbieters.

Was zum Fachanwalt gehört: der AVV selbst, die Risikobewertung der Übertragung, und die Formulierung in der Datenschutzerklärung, in der AWS als Auftragsverarbeiter mit seinen Sub-Prozessoren benannt werden muss. Die Architektur kann noch so sauber sein, ohne den Vertrag fehlt die rechtliche Grundlage.

Die Compliance-Checkliste

Diese Checkliste deckt Architektur, Verschlüsselung, Vertrag und Governance ab. Ein Team kann sie durchgehen und hat danach eine Liste konkreter Lücken.

Das ist die freie Variante. Die ausführliche Version mit Referenzarchitektur, IaC-Starter und AVV-Checkliste baue ich gerade als GDPR-Pack (mehr dazu am Ende).

Wann Standard-Region reicht, wann Sovereign Cloud

Vier Fragen klären die Stufe, bevor man Aufwand investiert. Verarbeiten wir besondere Kategorien personenbezogener Daten, etwa Gesundheit oder Biometrie? Unterliegen wir branchenspezifischer Regulierung? Verlangt ein Kunde oder eine Aufsichtsbehörde nachweisbare Souveränität? Und wie hoch ist unsere Toleranz für das CLOUD-Act-Restrisiko?

Was die Geschäftsführung fragen sollte

Man muss kein Architekt sein, um die richtigen Fragen zu stellen. In welcher Region liegen unsere personenbezogenen Daten? Wer kontrolliert die Verschlüsselungsschlüssel? Haben wir einen unterschriebenen AVV, und kennen wir die Sub-Prozessoren? Wenn die Antworten unsicher sind, ist das ein Handlungspunkt, kein Detail.

Die ehrliche Risikofrage steht am Ende: Wenn eine Aufsichtsbehörde morgen fragt, können wir nachweisen, dass personenbezogene Daten DSGVO-konform verarbeitet werden? DSGVO-Konformität ist eine bewusste Entscheidung über akzeptiertes Risiko, getragen von Geschäftsführung und Technik gemeinsam, keine Checkbox, die ein Team allein abhakt.

Anti-Patterns

"Frankfurt gleich DSGVO-sicher". Ignoriert die Souveränitäts-Hälfte. Die Region löst die Residenz, nicht den CLOUD Act.

Default-Region us-east-1. Personenbezogene Daten landen außerhalb der EU, oft unbemerkt, weil es die Default-Region vieler Tools ist.

Keine Region-Guardrails. Ein Deploy in die falsche Region passiert irgendwann, ohne SCP fällt es niemandem auf.

AWS-managed Schlüssel für sensible Daten. Kein eigener Kontroll-Hebel über den Zugriff. Sensible Daten gehören unter kundenverwaltete Schlüssel.

Cross-Region-Replikation in die USA. Hebt die Residenz wieder auf, oft als bequeme Backup-Strategie eingerichtet und vergessen.

Kein AVV. Die rechtliche Grundlage fehlt, unabhängig davon, wie sauber die Technik ist.

Compliance als rein technisches Projekt. Ohne Vertrag und Risikobewertung bleibt es Stückwerk. Es ist Architektur, Vertrag und Entscheidung zusammen.

Sub-Prozessoren ignorieren. Die Datenschutzerklärung muss sie nennen, das ist keine Kür.

Fazit

DSGVO-Konformität auf AWS ist die Schnittmenge aus Architektur, Vertrag und einer ehrlichen Risikobewertung, nicht die Wahl einer Region. Datenresidenz ist die einfache Hälfte und mit einer EU-Region und Guardrails schnell gelöst. Datensouveränität ist die schwierige Hälfte, und 2026 mit der European Sovereign Cloud erstmals sauber adressierbar, für die, die sie brauchen.

Die meisten Mittelständler sind mit Stufe 1 oder 2 plus einer bewussten Risikoentscheidung richtig aufgestellt. Wer regulierte oder besonders sensible Daten verarbeitet, prüft Stufe 3. Der entscheidende Schritt ist nicht die Technik allein, sondern die bewusste Entscheidung, die Geschäftsführung und Technik gemeinsam treffen und dokumentieren. Genau das macht aus "wir sind in Frankfurt" eine belastbare Position.

Verarbeiten Sie personenbezogene Daten auf AWS und sind sich nicht sicher, ob Architektur und Vertrag zusammenpassen? Kontaktieren Sie mich für einen DSGVO- und Architektur-Audit, der Region, Verschlüsselung, Guardrails und Vertragslage in wenigen Tagen prüft. Die rechtliche Einordnung stimme ich mit Ihrem Fachanwalt ab, die Architektur bringe ich mit.

An einem EU/GDPR-Ready AWS Architecture Pack arbeite ich gerade, einer Referenzarchitektur mit IaC-Starter und AVV-Checkliste. Wer früh Bescheid wissen will, kann sich unverbindlich auf die Liste setzen lassen. Kein Newsletter-Dauerfeuer, nur eine Nachricht, wenn es so weit ist.