AWS Digital Sovereignty Lens: Was das neue Well-Architected Framework für souveräne Workloads bedeutet

AWS Digital Sovereignty Lens: Was jetzt neu ist

AWS hat das Digital Sovereignty Lens für das Well-Architected Framework in aktueller Fassung veröffentlicht (Whitepaper-Stand 15. September 2026, Ankündigung im Architecture Blog am 5. Oktober 2026). Das ist kein neuer Service, sondern ein Prüfrahmen: Er hilft Ihnen, souveräne Workloads zu entwerfen, zu betreiben und gegenüber Auditoren zu belegen. Für Unternehmen in der DACH-Region, die unter DSGVO, NIS2 oder DORA arbeiten (in der Schweiz zählt vor allem das revidierte DSG), ist das interessant. Souveränität ist damit nicht mehr nur eine Frage von Verträgen und Zertifikaten. Sie wird zur Architekturfrage.

Das Lens knüpft an den AWS Digital Sovereignty Pledge an, den AWS im November 2022 vorgestellt hat: das Versprechen, die fortschrittlichsten Souveränitätskontrollen der Cloud anzubieten, ohne bei Leistung oder Skalierbarkeit Abstriche zu machen. Der Pledge war eine Absichtserklärung. Mit dem Lens können Sie prüfen, ob Ihre Architektur dazu passt.

Was das Lens enthält: vier Pillar, 21 Fragen, 37 Best Practices

Wer Well-Architected Reviews kennt, findet sich sofort zurecht: Pillar, Fragen, Best Practices, Verbesserungspläne. Das Digital Sovereignty Lens deckt vier der sechs Pillar des Well-Architected Framework ab, mit 21 Fragen und 37 Best Practices. Cost Optimization und Sustainability fehlen bewusst. Dort gelten die bestehenden Well-Architected-Empfehlungen auch für souveräne Workloads.

Die vier abgedeckten Pillar:

• Operational Excellence: Wie organisieren, betreiben und entwickeln Sie Ihre Compliance-Funktion über Jurisdiktionen hinweg weiter? Es geht um Souveränitäts-Governance, Compliance-Automatisierung, kontinuierliche Auditierbarkeit, Monitoring, Remediation und den Umgang mit regulatorischen Änderungen.
• Security: Wie schützen Sie Daten, steuern Zugriffe, erkennen Bedrohungen und reagieren auf Vorfälle innerhalb souveräner Grenzen? Dazu gehören sichere Grundlagen, Zugriffskontrolle, Kontrollverifizierung, Operator-Zugriff, Datenklassifizierung, Verschlüsselung und Incident Response.
• Reliability: Wie planen Sie Business Continuity, steuern Anbieterrisiken und sorgen für Interoperabilität, wenn sich die Rahmenbedingungen ändern? Das Lens benennt auch den Konflikt zwischen Datenresidenz und Disaster Recovery, das oft Replikation über Regionen hinweg verlangt.
• Performance Efficiency: Wie wählen Sie die passende souveräne Lösung für jeden Workload? Dazu gehört auch, Software-Abhängigkeiten auf Souveränitätsrisiken zu prüfen.

Was das Lens nicht tut: Es ersetzt weder Rechtsberatung noch eine Datenschutz-Folgenabschätzung. Es liefert die technische Architekturgrundlage. Die rechtliche Einordnung bleibt bei Ihnen.

Die fünf Fragen, die einen souveränen Workload definieren

Bevor Sie einzelne Best Practices durcharbeiten, stellt das Lens fünf Fragen, die Sie jeweils für eine bestimmte Jurisdiktion beantworten. Sie klären, welche Anforderungen auf Ihren Workload zutreffen und wie stark:

• Wo läuft mein Workload? (Locality)
• Wer kommt heran? (Access control)
• Läuft er weiter, wenn sich die Bedingungen ändern? (Continuity)
• Kann ich ihn woanders hin umziehen? (Portability und Interoperability)
• Kann ich belegen, dass die Kontrollen greifen? (Transparency und Auditability)

Nicht jede Frage wiegt in jedem Kontext gleich schwer. Die fünfte ist die unbequemste. Viele Unternehmen haben Kontrollen eingeführt, können aber nicht dauerhaft zeigen, dass sie wirken. Das Lens setzt deshalb auf Compliance as Code: automatische Durchsetzung, laufende Überwachung und Nachweise auf Abruf, statt Belege erst kurz vor dem Audit mühsam zusammenzusuchen.

Souveränitätskontrollen in der Praxis: Was AWS liefert, was Sie selbst bauen müssen

Das Lens legt die Arbeitsteilung zwischen AWS und Ihnen offen, und das ist einer seiner praktischsten Punkte. AWS bringt die Grundlagen mit. Das Nitro System ist so gebaut, dass AWS-Personal ohne Zugriff auf Kundeninhalte in EC2 arbeitet. AWS CloudTrail protokolliert API-Aktivität, AWS Config überwacht Ressourcenkonfigurationen laufend. AWS Control Tower bietet über 245 Kontrollen in der Kategorie „Digitale Souveränität“ für Datenresidenz, Zugriffsbeschränkung, Verschlüsselung und Resilienz. Beim Thema Standort kommen die AWS-Regionen, AWS Outposts und die AWS European Sovereign Cloud hinzu.

Darauf müssen Sie selbst aufbauen: einen Compliance-Katalog, der Ihre regulatorischen Pflichten auf implementierte Kontrollen abbildet, automatisierte Durchsetzung über Service Control Policies (SCPs), Resource Control Policies (RCPs) und IAM-Policies sowie eine Governance-Funktion, die regulatorische Änderungen verfolgt und die Architektur nachzieht.

Für Finanzdienstleister unter DORA ist das besonders relevant. DORA verlangt nicht nur technische Kontrollen, sondern auch dokumentierte ICT-Risikomanagementprozesse und Nachweise zu Drittanbieter-Risiken. Das Lens gibt Ihnen die Architekturgrundlage. Die DORA-spezifische Dokumentation müssen Sie separat aufbauen.

Ein verbreitetes Missverständnis: Souveränität hängt nicht allein am Serverstandort. Vertragsklauseln und Auftragsverarbeitungsverträge legen Pflichten zwischen Parteien fest, erzeugen aber keine technisch überprüfbaren Kontrollen. Das Lens ergänzt vertragliche Zusagen deshalb um automatisierte technische Durchsetzung. Nur so entsteht eine Souveränitätsposition, die sich prüfen lässt.

Für wen das Lens relevant ist, und für wen nicht

Das Lens beschreibt sieben Szenarien, in denen Souveränitätsanforderungen typischerweise entstehen. Vier davon zeigen die Bandbreite: Sie gehen mit einem Workload in eine neue Jurisdiktion und müssen vorab klären, welche Pflichten dort gelten. Sie verarbeiten personenbezogene Daten und müssen Residenz- und Transferregeln einhalten und nachweisen. Vorschriften legen fest, wer operativen Support leisten darf, von wo und mit welcher Befugnis. Oder Sie führen generative KI ein, und die neuen Datenflüsse dürfen bestehende Souveränitätskontrollen nicht aushebeln.

Trifft keines dieser Szenarien auf Sie zu, verarbeiten Sie also keine regulierten Daten, sind in keiner regulierten Branche tätig und haben keine grenzüberschreitenden Anforderungen, ist das Lens für Sie heute nicht zwingend. Bei den meisten Mittelständlern in der DACH-Region, die personenbezogene Daten verarbeiten oder im Finanz-, Gesundheits- oder öffentlichen Sektor arbeiten, dürfte mindestens eines zutreffen.

Und es ist kein reines Thema für den öffentlichen Sektor. Souveränitätsanforderungen entstehen überall dort, wo Jurisdiktionsgrenzen, Datenschutzpflichten oder Betreibervorschriften eine Rolle spielen, auch in privaten Unternehmen.

So starten Sie: Lens importieren und erste Review durchführen

Das Lens gibt es als Whitepaper und als Custom Lens im öffentlichen AWS Well-Architected Custom Lens GitHub Repository. Der Einstieg läuft wie bei jedem Custom Lens: Lens-Definition herunterladen, ins AWS Well-Architected Tool importieren, einen Workload auswählen und die Review starten. Sie zeigt High- und Medium-Risk-Issues, aus denen Sie priorisierte Verbesserungspläne ableiten.

Unser Rat: Beginnen Sie mit einem repräsentativen Workload statt mit dem ganzen Portfolio. So bauen Sie erst Erfahrung auf und rollen dann aus. Wenn Sie die Infrastrukturoptionen noch nicht gut kennen, lohnt sich vorher ein Blick auf AWS Outposts als eine der Deployment-Möglichkeiten.

Welche Souveränitätsanforderungen für Ihre Workloads gelten, nimmt Ihnen das Lens nicht ab. Das klären Recht, Compliance und Technik gemeinsam. Danach hilft das Lens, die Anforderungen in Architekturentscheidungen zu übersetzen und zu belegen, dass sie greifen. Wer früh anfängt, hat beim nächsten Audit weniger Stress.