Europa-only Alternative zu Oracle Cloud (OCI).

Oracle Cloud Infrastructure ist der kleinste der großen Hyperscaler im EU-Mittelstandsmarkt, spielt aber in regulierten Branchen wegen der Oracle-Database-Bindung eine überproportionale Rolle. Oracle Corporation ist ein US-Unternehmen; die OCI-EU-Regionen (Frankfurt, Amsterdam, Marseille, Mailand, Madrid, Stockholm, Zürich) befinden sich in der EU, unterliegen jedoch der US-Kontrolle nach dem CLOUD Act. Oracle vermarktet seit 2023 die „EU Sovereign Cloud“ - operativ getrennte EU-Regionen mit EU-ansässigem Personal - aber die übergeordnete Jurisdiktion bleibt unverändert. Für Schrems-II-strikte Analysen ist das keine vollständige Souveränität.

Vereinigte Staaten Ersatz-Stack, ausschließlich EU 12 Dienste zugeordnet

Gespräch vereinbaren Erst Domain scannen

Anbieter: Oracle Cloud (OCI)
Hauptsitz: Austin, TX
Rechtsmacht: Vereinigte Staaten
Rechtsregime: CLOUD Act, FISA 702, EO 12333

"EU-Region" ist keine Souveränität. Vier Fragen entscheiden.

Data-Residency sagt, wo die Bits liegen. Souveränität sagt, welches Rechtssystem Zugriff erzwingen kann. Die Antwort muss auf allen vier Punkten halten, sonst ist der Stack nicht souverän.

Residenz

Wo sind die Daten physisch gespeichert?

Nicht "in der Cloud": welches Rechenzentrum, in welchem Land, unter welcher Jurisdiktion.

Subprozessoren

Wer ist sonst noch in Ihrem Datenpfad?

Jeder Anbieter, der die Daten berührt: das CDN, das E-Mail-Relay, der Error-Tracker, die Analytics-Pipeline.

Rechtsmacht

Wessen Gesetze können die Offenlegung erzwingen?

Ein Anbieter mit US-Hauptsitz untersteht FISA 702 und dem CLOUD Act, auch wenn die Bits in Frankfurt liegen.

Schlüsselverwahrung

Wer hält tatsächlich die Verschlüsselungsschlüssel?

Wenn der Cloud-Anbieter sowohl die Daten als auch die Schlüssel hält, sind die Daten für ihn lesbar, unabhängig von jedem AVV.

Erfüllt nicht AWS · Azure · GCP · EU-Region

Scheitert an Rechtsmacht und Schlüsselverwahrung.

EU-Daten, US-Mutterkonzern, US-Subprozessoren im Standardpfad, vom Anbieter verwaltete Schlüssel.

Erfüllt Binadit Managed Stack

Besteht in allen vier Punkten.

EU-gehostet auf Infrastruktur mit EU-Hauptsitz. Null US-Subprozessoren im Standardpfad. Kunden- oder EU-KMS-Schlüssel. Namentlich in Ihrer Artikel-28-AVV aufgeführt.

Warum Teams aussteigen Oracle Cloud (OCI)

Oracle-Exits, die wir durchgeführt haben, umfassen fast immer zusätzlich zur Infrastruktur eine Datenbankmigration - typischerweise Oracle DB → PostgreSQL, was für sich genommen schon ein umfangreiches Projekt ist. Die Auslöser: ein Financial-Services-Audit unter DORA, das Oracle als US-jurisdiktionales Konzentrationsrisiko einstuft, eine Kostenprüfung, die das tatsächliche Ausmaß der Oracle-DB-Lizenzkosten in der Cloud aufdeckt, oder eine strategische Entscheidung, die Oracle-Abhängigkeit vollständig zu entfernen. Die mittelfristige Ersparnis ist dramatisch, wenn sowohl die OCI-Infrastrukturkosten als auch die Oracle-DB-Lizenzkosten wegfallen.

Oracle Cloud (OCI) Dienste und ihre EU-only Äquivalente

Eine Migration ist nicht "eine Box gegen eine andere tauschen". Die Zuordnung unten ist das, was wir für Kunden ausführen, die Folgendes verlassen: Oracle Cloud (OCI) auf Grundlage von Schrems II: vollständige EU-Jurisdiktion, kein US-Mutterkonzern im Datenpfad.

Oracle Cloud (OCI) Dienst	Was wir stattdessen betreiben	Engineering-Hinweis
Compute Instances	Binadit Managed Cloud Platform. KVM-VMs auf Debian oder Ubuntu, provisioniert mit Terraform und konfiguriert mit Ansible.	Standard-VM-Migration; Image-Neuerstellung und Rebase. Oracle Linux kann ohne Auswirkungen auf die Anwendung durch Rocky oder Alma ersetzt werden.
Object Storage	Binadit Managed Cloud Platform. MinIO oder Ceph RGW, S3-kompatibel.	OCI Object Storage verfügt über eine nicht S3-kompatible API; die Umstellung ist klein, erfordert aber SDK-Änderungen.
Autonomous Database	Binadit Managed Cloud Platform. PostgreSQL oder MySQL mit Patroni für Failover und pgBackRest für Point-in-Time Recovery.	Die längste Einzelmigrationsaufgabe. Tools wie ora2pg und Cybertecs Migrator haben sich erheblich verbessert. Planen Sie je nach Schema-Komplexität einen Parallelbetrieb von 3-9 Monaten ein.
OKE (Oracle Kubernetes Engine)	Binadit Managed Cloud Platform. Kubernetes auf Debian oder Talos, mit Cilium-Networking und cert-manager für Zertifikate.	Helm Charts und YAML lassen sich sauber übertragen; OKE-spezifische Funktionen (Container Engine for Kubernetes Managed Nodepools) werden durch Standardäquivalente ersetzt.
Block Volumes	Binadit Managed Cloud Platform. Ceph RBD oder Longhorn für Kubernetes-native Volumes.	Volume-Migration via Snapshot + Restore.
Virtual Cloud Network (VCN)	Binadit Private Infrastructure. Isolierte VLANs mit WireGuard für Site-to-Site- und Operator-Zugriff.	OCI-VCN-Konzepte (Subnets, Routingtabellen, NAT-Gateways) lassen sich direkt auf Standard-Cloud-Networking übertragen.
Functions (FaaS)	Binadit Managed Cloud Platform. Knative oder OpenFaaS auf Ihrem Kubernetes-Cluster.	Die Migration ist mechanisch; OCI Functions basiert auf Fn Project, weshalb das Runtime-Modell portabel ist.
Streaming (Kafka-compatible)	Binadit Managed Cloud Platform. Apache Kafka oder Redpanda, Kafka-Protokoll-kompatibel.	Die Kafka-Migration ist eine Producer/Consumer-Umleitung; Datenreplikation über MirrorMaker.
API Gateway	Binadit Managed Cloud Platform. Traefik oder Kong, mit Rate Limiting und OIDC am Edge.	KrakenD hat seinen Hauptsitz in Spanien und ist eine starke souveräne Wahl.
Load Balancer	Binadit Managed Cloud Platform. HAProxy oder Nginx, mit keepalived für Failover.	Standard-L4/L7-Load-Balancing.
Vault (KMS)	Binadit Private Infrastructure. Vault Transit für Key-Management, mit HSM-gestützten Keys, wo das Compliance-Regime es erfordert.	Vault ist die produktionsreife souveräne Antwort.
Logging / Monitoring	Binadit Managed Cloud Platform. Prometheus, Grafana, Loki und Tempo, verbunden mit OpenTelemetry.	OpenTelemetry-Instrumentierung macht die anwendungsseitige Migration mechanisch.

Compute Instances

Was wir stattdessen betreiben: Binadit Managed Cloud Platform. KVM-VMs auf Debian oder Ubuntu, provisioniert mit Terraform und konfiguriert mit Ansible.
Engineering-Hinweis: Standard-VM-Migration; Image-Neuerstellung und Rebase. Oracle Linux kann ohne Auswirkungen auf die Anwendung durch Rocky oder Alma ersetzt werden.

Object Storage

Was wir stattdessen betreiben: Binadit Managed Cloud Platform. MinIO oder Ceph RGW, S3-kompatibel.
Engineering-Hinweis: OCI Object Storage verfügt über eine nicht S3-kompatible API; die Umstellung ist klein, erfordert aber SDK-Änderungen.

Autonomous Database

Was wir stattdessen betreiben: Binadit Managed Cloud Platform. PostgreSQL oder MySQL mit Patroni für Failover und pgBackRest für Point-in-Time Recovery.
Engineering-Hinweis: Die längste Einzelmigrationsaufgabe. Tools wie ora2pg und Cybertecs Migrator haben sich erheblich verbessert. Planen Sie je nach Schema-Komplexität einen Parallelbetrieb von 3-9 Monaten ein.

OKE (Oracle Kubernetes Engine)

Was wir stattdessen betreiben: Binadit Managed Cloud Platform. Kubernetes auf Debian oder Talos, mit Cilium-Networking und cert-manager für Zertifikate.
Engineering-Hinweis: Helm Charts und YAML lassen sich sauber übertragen; OKE-spezifische Funktionen (Container Engine for Kubernetes Managed Nodepools) werden durch Standardäquivalente ersetzt.

Block Volumes

Was wir stattdessen betreiben: Binadit Managed Cloud Platform. Ceph RBD oder Longhorn für Kubernetes-native Volumes.
Engineering-Hinweis: Volume-Migration via Snapshot + Restore.

Virtual Cloud Network (VCN)

Was wir stattdessen betreiben: Binadit Private Infrastructure. Isolierte VLANs mit WireGuard für Site-to-Site- und Operator-Zugriff.
Engineering-Hinweis: OCI-VCN-Konzepte (Subnets, Routingtabellen, NAT-Gateways) lassen sich direkt auf Standard-Cloud-Networking übertragen.

Functions (FaaS)

Was wir stattdessen betreiben: Binadit Managed Cloud Platform. Knative oder OpenFaaS auf Ihrem Kubernetes-Cluster.
Engineering-Hinweis: Die Migration ist mechanisch; OCI Functions basiert auf Fn Project, weshalb das Runtime-Modell portabel ist.

Streaming (Kafka-compatible)

Was wir stattdessen betreiben: Binadit Managed Cloud Platform. Apache Kafka oder Redpanda, Kafka-Protokoll-kompatibel.
Engineering-Hinweis: Die Kafka-Migration ist eine Producer/Consumer-Umleitung; Datenreplikation über MirrorMaker.

API Gateway

Was wir stattdessen betreiben: Binadit Managed Cloud Platform. Traefik oder Kong, mit Rate Limiting und OIDC am Edge.
Engineering-Hinweis: KrakenD hat seinen Hauptsitz in Spanien und ist eine starke souveräne Wahl.

Load Balancer

Was wir stattdessen betreiben: Binadit Managed Cloud Platform. HAProxy oder Nginx, mit keepalived für Failover.
Engineering-Hinweis: Standard-L4/L7-Load-Balancing.

Vault (KMS)

Was wir stattdessen betreiben: Binadit Private Infrastructure. Vault Transit für Key-Management, mit HSM-gestützten Keys, wo das Compliance-Regime es erfordert.
Engineering-Hinweis: Vault ist die produktionsreife souveräne Antwort.

Logging / Monitoring

Was wir stattdessen betreiben: Binadit Managed Cloud Platform. Prometheus, Grafana, Loki und Tempo, verbunden mit OpenTelemetry.
Engineering-Hinweis: OpenTelemetry-Instrumentierung macht die anwendungsseitige Migration mechanisch.

Wie wir migrieren von Oracle Cloud (OCI)

Eine typische Mittelstand-Migration läuft in drei Phasen. Die Zahlen unten gehen von einem 6-10-köpfigen Engineering-Team und einem mäßig komplexen Anwendungs-Stack aus.

Wochen 1-4

Entscheidung zum Datenbank-Umfang

Erfassen Sie jedes verwendete Oracle-DB-spezifische Feature (PL/SQL, Oracle Text, Partitionierung, materialisierte Views, hierarchische Abfragen, Oracle Spatial). Entscheidungspunkt: vollständige Migration zu PostgreSQL oder hybrid (kompatibilitätskritische Workloads auf einer Oracle-kompatiblen PostgreSQL-Distribution). Dies ist die zeitplanbestimmende Aufgabe.
Wochen 4-10

Infrastrukturmigration

Compute, Networking und Storage wurden auf den souveränen EU-Stack verschoben. K8s-Workloads wurden migriert. Object Storage wurde migriert, mit API-Anpassungen, wo nötig. CI/CD wurde neu ausgerichtet.
Wochen 8-24

Datenbank-Umschaltung

Schema mit ora2pg konvertiert. Daten via logischer Replikation oder Change-Data-Capture für Live-Workloads migriert. Anwendungscode auf Oracle-spezifisches SQL geprüft. Cutover-Fenster mit vollständigem Rollback-Plan geplant.

5-Jahres-TCO bei vollständigen Oracle-Exits (Infrastruktur + Datenbank): typischerweise 50-70% günstiger. Die größten Einsparungen ergeben sich aus dem Wegfall der Oracle-DB-Lizenzierung (Enterprise-Preise pro Core sind brutal), gefolgt von EU-IaaS, das bei vergleichbaren Specs rund 40% günstiger ist als OCI. Das Datenbank-Konvertierungsprojekt selbst ist die größte einmalige Kostenposition, amortisiert sich aber noch im 2. Jahr.

Häufig gestellte Fragen

Alle häufig gestellten Fragen anzeigen

Was ist mit Oracle EU Sovereign Cloud?

Oracle EU Sovereign Cloud (gestartet 2023, Regionen in Madrid und Frankfurt) wird von EU-ansässigem Oracle-Personal mit operativer Trennung von Nicht-EU-Oracle betrieben. Das ist eine Verbesserung der Dokumentationslage für viele regulierte Workloads - aber Oracle Corporation bleibt rechtlicher Eigentümer der Daten. Für Schrems-II-Analysen, die auf die Muttergesellschaftsjurisdiktion abstellen, ist das keine vollständige Souveränität.

Können wir Oracle DB behalten und nur OCI verlassen?

Ja. Eine Oracle-kompatible PostgreSQL-Distribution bleibt auf SQL- und PL/SQL-Ebene für die meisten Workloads kompatibel. Für Oracle-Anwendungen mittlerer Komplexität ist dies ein gangbarer Weg, der keine vollständige Neuentwicklung der Datenbank erfordert.

Wie umfangreich ist das Datenbank-Migrationsprojekt wirklich?

Für eine typische Mid-Market-Oracle-DB (50-500GB, überschaubarer PL/SQL-Umfang, keine Oracle-spezifischen Funktionen über Standard-SQL hinaus): 3-6 Monate Parallelbetrieb, 2-4 Wochen für den eigentlichen Cutover. Für eine Anwendung mit umfangreichem PL/SQL oder Abhängigkeit von Oracle-Funktionen: 9-18 Monate. Die ehrliche Einschätzung des Umfangs gelingt am besten Leuten, die es bereits gemacht haben.

Was ist mit Oracle Fusion Apps und Oracle ERP Cloud?

Das sind SaaS-Lösungen, keine Infrastruktur - dieselbe Diskussion wie bei Microsoft 365 oder Salesforce. Die Entscheidung, davon wegzuziehen, ist strategisch, nicht infrastrukturell. Wir konzentrieren uns auf die OCI-Infrastrukturebene; die SaaS-Migration ist in der Regel ein separates Projekt, das von einer Business-Systems-Beratung durchgeführt wird.

Ist OCI preislich wirklich wettbewerbsfähig?

Die Headline-IaaS-Preise von OCI sind wettbewerbsfähig im Vergleich zu AWS/Azure/GCP. Teuer wird OCI bei der Datenbanklizenzierung in der Cloud (Oracle-DB-BYOL-Kosten sind hoch). Für reines Compute ist der EU-souveräne Stack weiterhin 30-40% günstiger. Bei Oracle-DB-Workloads wird der Vergleich von der Lizenz dominiert, nicht vom Compute.

Wie lange dauert ein Oracle-Exit end-to-end?

Nur für Infrastruktur (keine DB-Migration): 8-14 Wochen. Für einen vollständigen Exit einschließlich PostgreSQL-Migration: 6-18 Monate Laufzeit, abhängig von der Datenbankkomplexität. Das Zeitplanrisiko liegt vollständig auf der Datenbankseite.

Plane deinen Exit von Oracle Cloud (OCI).

30-minütiges Scoping-Gespräch. Wir bilden Ihren Stack auf EU-only Alternativen ab, schätzen den Migrationsaufwand und sagen Ihnen, ob es die richtige Entscheidung ist.

Gespräch vereinbaren Anderen Anbieter vergleichen