6 Min. Lesezeit
Reshoring ist 2026 kein Marketing-Label mehr, sondern ein Budgetposten. Deutsche Mittelständler verlagern konkrete Workloads aus US-Regionen der Hyperscaler zurück in EU-Rechenzentren – manche komplett, viele hybrid. Treiber sind selten reine Souveränitätsdebatten. Es sind Audit-Fragen aus BSI-KRITIS-Prüfungen, C5-Testate der Kunden und KRITIS-Dachgesetz-Pflichten ab Oktober 2025, die operativ durchschlagen.
Das Wichtigste in Kürze
- Workload-Triage statt Cloud-Exit. Zurückgeholt werden vor allem KRITIS-Workloads, personenbezogene Analytics und Backups mit Aufbewahrungspflicht. Der Rest bleibt hybrid oder pragmatisch beim Hyperscaler.
- Audit-Nachweise sind die Treiber. C5-Typ-2, BSI-KRITIS-Prüfungen und das KRITIS-Dachgesetz drücken Entscheidungen durch – nicht die Souveränitätsdebatte, nicht Gaia-X-Narrative.
- Scheitern liegt nicht an Infrastruktur. STACKIT, OVHcloud, IONOS und Open Telekom Cloud tragen die Workloads – das Projekt scheitert an SaaS-Abhängigkeiten und fehlenden Managed Services wie BigQuery oder DynamoDB.
VerwandtCloud Repatriation 2026: Das TCO-Modell / Broadcom-VMware-Channel: Die Provider-Landschaft 2026
Die Bewegung läuft nicht als großer Exit. Sie läuft als Workload-Triage: Was muss zwingend in die EU, was kann hybrid laufen, was bleibt pragmatisch bei AWS us-east-1 oder Azure East US. Dieser Text beschreibt, was in Projekten seit Anfang 2026 tatsächlich passiert – und wo das Narrativ an der Realität der Hyperscaler-Skala scheitert.
Welche Workloads konkret zurückgeholt werden
Es gibt drei klare Cluster, die Mittelständler 2026 aktiv migrieren. Erster Cluster: KRITIS-relevante Workloads. Seit dem KRITIS-Dachgesetz und der NIS2-Umsetzung in Deutschland müssen Betreiber kritischer Anlagen Nachweise über Standort, Zugriff und Weisungsgebundenheit der Datenverarbeitung erbringen. Energieversorger, Wasserwerke und Klinikverbünde ziehen ihre Patient- und Steuerungsdaten zurück, oft auf Open Telekom Cloud oder IONOS.
Zweiter Cluster: personenbezogene Analytics und CRM-Daten mit Schrems-II-Risiko. Unternehmen, die 2024/25 auf AWS-SCCs und EU-US Data Privacy Framework gesetzt haben, erleben bei Audits Rückfragen. Analytics-Pipelines wandern auf EU-native Anbieter oder auf AWS Frankfurt (eu-central-1) mit expliziten Region-Lock-Policies.
Dritter Cluster: Backups und Langzeit-Archive mit gesetzlicher Aufbewahrungspflicht (Handels- und Steuerrecht, §257 HGB, §147 AO). Hier wandern kalte Daten von S3 in den USA zu S3-kompatiblen EU-Anbietern oder auf OVHcloud-Object-Storage. Der Migrationsaufwand ist überschaubar, das Compliance-Argument stark.
Was die Zertifizierungen wirklich treiben
Drei Frameworks prägen die Diskussion, jedes mit unterschiedlichem Gewicht. C5 (Cloud Computing Compliance Criteria Catalogue) des BSI ist der praktisch wichtigste Hebel. Großkunden und öffentliche Auftraggeber fordern C5 Typ 2 als Vertragsgrundlage. AWS, Azure und Google Cloud haben C5-Testate für ihre EU-Regionen, aber die Zusatzkriterien (DEU C5:2020) zur Datenlokalität zwingen zu expliziter Region-Konfiguration. Wer bisher global deployed hat, muss umarchitekten.
BSI-KRITIS ist kein Zertifikat, sondern ein Pflichtregime für Betreiber kritischer Infrastrukturen. Die Nachweispflicht nach §8a BSI-Gesetz verlangt alle zwei Jahre Prüfung angemessener Schutzmaßnahmen. In der Praxis heißt das: Cloud-Auslagerungen müssen dokumentiert, Auftragsverarbeitungsverträge wasserdicht und Exit-Strategien belastbar sein. Hyperscaler-Standard-AVVs reichen oft nicht mehr.
Gaia-X liefert ein Architektur- und Label-Framework (Gaia-X Labels Level 1 bis 3), das Datensouveränität zusichert. Produktive Workloads auf Gaia-X-zertifizierten Services sind selten. Gaia-X wirkt vor allem als Ausschreibungskriterium im öffentlichen Sektor und als Argumentations-Schablone für interne Governance. Wer Gaia-X als fertige Cloud erwartet, wird enttäuscht.
Wo das Narrativ an der Hyperscaler-Realität scheitert
Die Souveränitäts-Erzählung klingt sauber: raus aus US-Clouds, rein in EU-Anbieter. In der Projektrealität bricht das Narrativ an drei Punkten.
- C5 Typ 2, BSI-KRITIS-konforme Architekturen out of the box
- Deutsches/europäisches Recht, keine US-Konzernmutter
- Direkte Ansprechpartner, oft bilingual, Support-SLAs ohne Zeitzonen-Drama
- Preise für Compute und Storage wettbewerbsfähig zu Hyperscaler-EU-Regionen
- Managed-Service-Tiefe: Bedrock, SageMaker, BigQuery, Synapse – kein 1:1-Ersatz in der EU
- Globale Failover-Topologien, die nationale Anbieter nicht abbilden
- Ökosystem aus ISVs und Integrationen, das Entwicklerproduktivität treibt
- ML/AI-Stack mit aktuellen GPU-Generationen in EU-Regionen verfügbar
Erster Bruchpunkt: Managed Services. Wer produktiv auf Amazon Aurora, DynamoDB oder Azure Cosmos DB läuft, hat bei EU-Anbietern keinen gleichwertigen Managed-Service. Migration bedeutet oft, auf Self-Managed PostgreSQL oder auf kleinere Service-Cataloge zu wechseln. Das ist machbar, kostet aber Engineering-Zeit.
Zweiter Bruchpunkt: SaaS-Abhängigkeiten. Microsoft 365, Salesforce, ServiceNow liegen auf US-Konzernen. Auch Microsoft-EU-Cloud-Angebote (EU Data Boundary) entkommen dem CLOUD Act nicht vollständig. Wer ernsthaft US-Zugriff ausschließen will, muss bei der SaaS-Schicht anfangen, nicht bei IaaS.
Dritter Bruchpunkt: KI-Stack. EU-Anbieter investieren (STACKIT hat KI-Plattform, OVHcloud bietet GPU-Instanzen), aber die Lücke zu Bedrock oder Vertex AI ist groß. Teams, die LLM-basierte Produkte bauen, bleiben zumindest für Inference häufig bei US-Hyperscalern. Reshoring heißt hier: Daten in der EU, Modell-Inferenz dort, wo die Modelle laufen.
„Reshoring ist 2026 kein Marketing-Label mehr, sondern ein Budgetposten.“
Praktische Schritte für ein Reshoring-Projekt
Wer ein Reshoring-Projekt startet, sollte in dieser Reihenfolge vorgehen:
- Workload-Triage (Woche 1-3): Alle Workloads nach drei Kriterien einordnen – KRITIS-Relevanz, Personenbezug, Aufbewahrungspflicht. Nur Workloads mit echtem Compliance-Treiber migrieren. Der Rest bleibt vorerst, wo er ist. Ergebnis: priorisierte Liste mit maximal 15 bis 20 Prozent des Portfolios.
- Zielarchitektur definieren (Woche 3-6): Pro Workload-Cluster einen Zielanbieter wählen. Datenbank-Workloads auf Open Telekom Cloud oder IONOS, Object-Storage auf OVHcloud, Kubernetes-Basis auf STACKIT. Keine Multi-Anbieter-Strategie in einem Cluster – das kostet Betriebskomplexität ohne Souveränitätsgewinn.
- Proof-of-Migration mit einem Workload (Monat 2-3): Eine konkrete, nicht geschäftskritische Anwendung migrieren. Laufzeitverhalten, Supportqualität und Kosten real messen. Erst danach skalieren. Unternehmen, die direkt fünf Workloads parallel migrieren, produzieren Betriebsrisiken ohne Erkenntnisgewinn.
- Exit-fähige Betriebsprozesse etablieren (Monat 3-5): Infrastructure as Code (Terraform, Pulumi), portable Container und standardisierte Datenexport-Formate von Anfang an. Wer bei EU-Anbietern in Vendor-Lock landet, hat das Ursprungsproblem nur geografisch verschoben.
- Reporting und Zertifikats-Mapping (Monat 4-6): C5-Testate der Anbieter in die eigenen Audit-Unterlagen überführen, KRITIS-Nachweise aktualisieren, BSI-Meldewege anpassen. Das ist der Teil, der den Nutzen des Projekts gegenüber Vorstand und Aufsichtsrat sichtbar macht.
Reshoring 2026 ist kein politisches Statement, sondern ein Engineering-Projekt mit Compliance-Treiber. Die sauberste Herangehensweise ist unspektakulär: Workloads priorisieren, einen Anbieter konsequent testen, Exit-Fähigkeit einbauen. Wer das diszipliniert macht, bekommt Datensouveränität ohne die Skalierungs-Rückschritte, die das Narrativ oft unterschlägt. Wer Reshoring als Totalausstieg aus US-Clouds plant, landet schnell in SaaS-Debatten, die das IaaS-Team nicht lösen kann.
Am Ende entscheidet die Frage, wofür man den Audit-Stempel braucht. Für KRITIS-Pflichten und öffentliche Ausschreibungen führt in den meisten Fällen kein Weg an EU-Anbietern vorbei. Für produktive KI- und Datenplattformen bleibt die hybride Realität: EU-Region beim Hyperscaler, strenge Region-Locks, zusätzlicher EU-nativer Anbieter für die Teile, die C5 Typ 2 zwingend brauchen. Diese Zwei-Schichten-Architektur ist unsexy, aber sie überlebt die nächsten Audit-Zyklen.
Wie Gaia-X und EuroStack in die Reshoring-Debatte spielen
Gaia-X ist in der operativen Architektur-Arbeit 2026 selten ein eigener Anforderungspunkt, taucht aber regelmäßig in Ausschreibungen des öffentlichen Sektors und regulierter Branchen auf. Relevant sind in der Praxis die Self-Description-Schemata und das Label-System: Ein Anbieter mit Gaia-X Label Level 2 oder 3 signalisiert, dass bestimmte Souveränitäts-Kriterien (Sitz der Datenverarbeitung, Zugriffsrechte, Jurisdiktion) vertraglich zugesichert sind. Für ein KRITIS-Unternehmen, das seinem Wirtschaftsprüfer erklären muss, warum ein bestimmter Workload in einer US-Cloud bleibt, ist das Label ein verwertbares Argument. Ohne Label wird die Diskussion länger.
EuroStack ist jünger, politisch aufgeladener und aktuell vor allem eine Roadmap-Debatte. Die Idee, einen durchgängigen europäischen Infrastruktur-Stack zu bauen – von Silizium über Compute bis zu Plattform-Diensten – ist für mittelständische Architektur-Entscheidungen 2026 noch keine Grundlage. Sie taucht aber in Förder-Calls auf und beeinflusst die Frage, welche EU-Anbieter für die nächsten fünf Jahre strategisch interessant bleiben. Wer heute Reshoring plant, sollte die Liste der Anbieter prüfen, die aktiv in EuroStack-Projekten mitarbeiten. Das ist kein Kaufkriterium, aber ein Signal für langfristige Investitionsbereitschaft.
Praktisch heißt das: In der Ausschreibung Gaia-X Label als Muss-Kriterium, EuroStack-Beteiligung als Plus-Bewertung. Beides kommuniziert man intern unaufgeregt. Wer Gaia-X als Marketing-Thema aufbläst, verliert die Compliance-Abteilung; wer es ignoriert, verliert öffentliche Ausschreibungen.
DSGVO, Schrems II und die Frage nach der Jurisdiktion
Der juristische Kern der Reshoring-Welle sitzt nicht in Berlin, sondern in Luxemburg. Seit dem Schrems-II-Urteil 2020 und den Folgedebatten um das EU-US Data Privacy Framework ist die Übertragung personenbezogener Daten in die USA nur mit zusätzlichen technischen und organisatorischen Maßnahmen zulässig. Das Data Privacy Framework von 2023 hat die Situation formal stabilisiert, steht aber unter Dauerbeobachtung. Mehrere Datenschutz-Aufsichtsbehörden in der EU haben signalisiert, dass sie im Zweifel erneut prüfen lassen würden, wenn der Rahmen politisch oder juristisch kippt.
Für die Architektur bedeutet das: Wer heute produktive Systeme mit personenbezogenen Daten in US-Regionen betreibt, trägt ein Rest-Risiko, das sich durch Region-Locks in der EU mildern, aber nicht vollständig ausschalten lässt. Der CLOUD Act erlaubt US-Behörden unter bestimmten Bedingungen Zugriff auf Daten bei US-Unternehmen, unabhängig davon, wo die Daten physisch liegen. Für die meisten Mittelständler ist das kein operatives Problem, aber ein Auditable Item – und Auditable Items landen früher oder später im Risikoregister.
Die sauberste Architektur-Antwort 2026 ist nicht der Totalausstieg, sondern die Trennung nach Datenklassen: Personenbezogene Daten mit hoher Sensibilität (Gesundheit, Mitarbeiterdaten, Kommunikation) in EU-native Anbieter, Betriebsdaten ohne Personenbezug weiter bei den Hyperscalern, Mischformen nach Einzelfall. Das ist mehr Verwaltung, reduziert aber das juristische Angriffsfeld signifikant – und es ist genau die Sprache, die DSGVO-Aufsichtsbehörden hören wollen.
Was Reshoring nicht löst
Zwei Missverständnisse halten sich hartnäckig. Erstens: Reshoring löst nicht die Abhängigkeit von US-Software-Stacks. Wer seine Daten in einem EU-Rechenzentrum ablegt, die Daten aber mit Microsoft 365, Salesforce oder ServiceNow verarbeitet, hat die Jurisdiktion nicht wirklich verlassen. Die SaaS-Frage ist ein eigenes Projekt und braucht eigene Antworten – Stichwort europäische Alternativen wie Nextcloud, Open-Xchange oder spezialisierte Vertical-SaaS aus dem DACH-Raum.
Was Reshoring löst
- Datenstandort-Nachweis für KRITIS- und Kunden-Audits
- Jurisdiktions-Exposure gegenüber Schrems-II-Fragen
- Egress-Kostenstruktur bei EU-nahen Analytics-Pipelines
- C5-Typ-2-Belegbarkeit über europäische Anbieterketten
Was Reshoring NICHT löst
- SaaS-Abhängigkeiten (Salesforce, M365, ServiceNow, HubSpot)
- Fehlende Managed Services (BigQuery, DynamoDB, Lambda-Äquivalent)
- Shared-Responsibility bei ISV-Software mit US-Header-Verträgen
- Personalbedarf für eigenen Plattform-Betrieb und Lifecycle
Zweitens: Reshoring ist kein Kosten-Projekt. EU-native Anbieter sind in den meisten Preisvergleichen teurer als Hyperscaler, insbesondere bei elastischen Workloads. Das muss man dem CFO ehrlich sagen, sonst kippt das Projekt in der ersten Budget-Runde. Der Business Case rechtfertigt sich über Audit-Tragfähigkeit, nicht über die Infrastruktur-Rechnung. Wer das umdreht, baut ein Reshoring-Projekt, das nach zwei Jahren rückabgewickelt wird, weil die Einspar-Erwartung nicht eingelöst wurde.
Häufige Fragen
Ab wann lohnt es sich, Reshoring überhaupt als Projekt aufzusetzen?
Spätestens wenn KRITIS-Pflichten, C5-Testate oder BSI-Vorgaben im nächsten Audit-Zyklus auf dem Tisch liegen und der Wirtschaftsprüfer die Jurisdiktions-Frage explizit adressiert. Unterhalb dieser Schwelle reicht in vielen Fällen ein sauber dokumentierter Region-Lock in der EU-Region des Hyperscalers – das ist weniger Aufwand und erfüllt die meisten Anforderungen im Mittelstand.
Muss ich für Reshoring komplett aus der US-Cloud raus?
Nein. Die Mehrheit der Projekte 2026 läuft hybrid: kritische Workloads nach Datenklasse in EU-native Anbieter, der Rest bleibt bei AWS, Azure oder Google Cloud mit EU-Region-Lock. Die Totalausstiegs-Rhetorik funktioniert in Sonntagsreden, selten in der Roadmap.
Welche Zertifikate sind für die Reshoring-Diskussion wirklich relevant?
In der Praxis: C5 Typ 2 des BSI als Grund-Messlatte, ISO 27001 als Basis, Gaia-X Label Level 2+ bei öffentlichen Ausschreibungen. KRITIS-Nachweise kommen branchenspezifisch dazu (B3S). Alles andere ist Marketing-Beigabe – nicht unwichtig, aber kein Entscheidungskriterium.
Wie vermeide ich, dass ich vom US-Lock-in in einen EU-Lock-in rutsche?
Von Tag eins auf portable Technologien setzen: Kubernetes statt proprietärer Orchestrierung, Terraform statt anbieterspezifischer Konsole, offene Datenformate statt Managed-Service-Spezifika. Exit-Pläne nicht erst schreiben, wenn der Wechsel ansteht, sondern als Bestandteil des Onboardings mit dem neuen Anbieter vertraglich fixieren.
Was bedeutet Reshoring für die SaaS-Landschaft im Unternehmen?
Wenig bis nichts, solange der Fokus auf IaaS liegt. Die SaaS-Debatte ist ein eigenes Projekt mit anderen Treibern und meist höheren politischen Kosten. Wer Reshoring beim IaaS-Umzug sauber macht und die SaaS-Frage ausklammert, hat eine ehrliche Antwort geliefert – niemand kippt Microsoft 365 als Nebenprojekt eines Infrastruktur-Programms.
Lesetipps der Redaktion
Mehr aus dem MBF Media Netzwerk
Quelle Titelbild: Pexels / Sergei Starostin (px:6466141)