TL;DR

• Datensouveraenitaet ist kein Marketing-Buzzword, sondern eine konkrete Anforderung: DSGVO Art. 44-49, Schrems-II-Urteil und branchenspezifische Regulierung machen den Standort der Cloud relevant.
• Open Telekom Cloud (OTC) bietet Managed Kubernetes (Cloud Container Engine) mit Rechenzentren in Biere und Magdeburg -- vollstaendig unter deutscher Jurisdiktion.
• Kostenvergleich zeigt: OTC ist 10-30% guenstiger als AWS/Azure bei vergleichbarer Kubernetes-Leistung, allerdings mit kleinerem Service-Katalog.
• Fuer den Mittelstand mit 500 Mitarbeitern ist die Kombination aus deutscher Cloud und Managed Kubernetes der pragmatische Weg zu Compliance ohne eigenes Cloud-Team.
• Vendor-Lock-in ist gering, weil Kubernetes als Standard-Orchestrierung den Wechsel zwischen Cloud-Anbietern technisch erleichtert.

Deutsche Cloud fuer den Mittelstand: Kubernetes auf Open Telekom Cloud betreiben

Warum der Cloud-Standort fuer den Mittelstand zaehlt

Wenn ein IT-Leiter in einem Unternehmen mit 500 Mitarbeitern die Cloud-Strategie verantwortet, steht er vor einer Entscheidung, die ueber Technik hinausgeht. Die Geschaeftsfuehrung fragt: "Sind unsere Daten sicher?" Der Datenschutzbeauftragte fragt: "Wo genau liegen die Daten?" Und der Branchenverband schickt Checklisten zur NIS2-Compliance.

Die ehrliche Antwort bei AWS oder Azure lautet: Die Daten liegen in einer EU-Region -- betrieben von einem US-Konzern, der dem CLOUD Act unterliegt. US-Behoerden koennen theoretisch Zugriff auf Daten in EU-Rechenzentren verlangen, unabhaengig davon, wo die Server physisch stehen.

Fuer viele mittelstaendische Unternehmen ist das kein theoretisches Risiko, sondern ein konkretes Compliance-Problem:

Wenn Sie in einer dieser Branchen arbeiten, ist "AWS Frankfurt" nicht automatisch die richtige Antwort. Es lohnt sich, Alternativen zu kennen.

Open Telekom Cloud: Was Sie als IT-Leiter wissen muessen

Ueberblick

Die Open Telekom Cloud (OTC) ist ein Public-Cloud-Angebot der Deutschen Telekom, technisch basierend auf OpenStack und Huawei-Technologie. Die Rechenzentren stehen in Biere und Magdeburg (Sachsen-Anhalt). Der Betrieb liegt bei T-Systems, einer Tochter der Deutschen Telekom.

Fuer Kubernetes bietet OTC den Dienst Cloud Container Engine (CCE) -- ein Managed Kubernetes Service, vergleichbar mit EKS, AKS oder GKE.

Was CCE kann

Cloud Container Engine (CCE):
├── Kubernetes-Versionen: 1.28, 1.29, 1.30
├── Node-Management: Auto-Scaling, Node Pools
├── Networking: VPC-natives Networking, ELB-Integration
├── Storage: EVS (Block), SFS (File), OBS (Object)
├── Monitoring: Cloud Eye Integration
├── Security: IAM, Security Groups, Encryption
└── Compliance: C5-Testat, ISO 27001, SOC 2

Was CCE nicht kann (im Vergleich zu EKS/AKS)

Ehrlichkeit ist wichtig: OTC hat einen kleineren Service-Katalog als die Hyperscaler. Dienste, die Sie bei AWS oder Azure als Managed Service bekommen, muessen Sie auf OTC teilweise selbst betreiben:

Die Luecken sind real, aber loesbar. Und genau hier wird ein Managed Kubernetes Service wertvoll: Der Partner schliesst die Luecken mit Open-Source-Tools, waehrend Sie sich auf Ihre Anwendungen konzentrieren.

Kubernetes auf OTC: Technischer Aufbau

Cluster-Architektur

Ein Production-Ready Kubernetes-Setup auf OTC sieht so aus:

OTC Region DE (Biere/Magdeburg)
├── VPC (Virtual Private Cloud)
│   ├── Subnet Management (10.0.1.0/24)
│   │   └── CCE Control Plane (Managed by OTC)
│   ├── Subnet Worker (10.0.2.0/24)
│   │   ├── Node Pool Standard (3x s3.xlarge.2)
│   │   └── Node Pool Compute (2x c6.2xlarge.4)
│   └── Subnet Database (10.0.3.0/24)
│       └── RDS for PostgreSQL (HA)
├── ELB (Elastic Load Balancer)
│   └── HTTPS Termination + WAF
├── OBS (Object Storage)
│   └── Backup + Logging
└── NAT Gateway
    └── Outbound Internet

CCE-Cluster erstellen

# OTC CLI (otc-tools) -- Cluster provisionieren
otc cce create-cluster \
  --name production-cluster \
  --flavor cce.s2.medium \
  --vpc-id vpc-abc123 \
  --subnet-id subnet-def456 \
  --container-network-type vpc-router \
  --kubernetes-version v1.30

# Node Pool hinzufuegen
otc cce create-node-pool \
  --cluster-name production-cluster \
  --name worker-standard \
  --flavor s3.xlarge.2 \
  --os EulerOS \
  --initial-node-count 3 \
  --min-node-count 2 \
  --max-node-count 10 \
  --autoscaling-enabled true

Storage-Konfiguration

# Persistent Volume Claim mit OTC EVS (Block Storage)
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: app-data
  annotations:
    everest.io/disk-volume-type: SSD
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: csi-disk
  resources:
    requests:
      storage: 100Gi
---
# Fuer Shared Storage: SFS Turbo (NFS-kompatibel)
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: shared-data
spec:
  accessModes:
    - ReadWriteMany
  storageClassName: csi-sfs-turbo
  resources:
    requests:
      storage: 500Gi

Kostenvergleich: OTC vs. Hyperscaler

Monatliche Kosten fuer ein typisches Mittelstands-Setup

Annahme: 3 Worker Nodes, 100 GB Block Storage, Load Balancer, Managed Database, 1 TB Outbound Traffic.

Open Telekom Cloud (CCE):
├── CCE Cluster Management:              0 EUR (kostenfrei)
├── 3x s3.xlarge.2 (4 vCPU, 8 GB):    285 EUR
├── 100 GB SSD EVS:                      12 EUR
├── ELB (Shared):                        35 EUR
├── RDS PostgreSQL (HA, s3.large.2):   280 EUR
├── 1 TB Outbound:                       75 EUR
└── OBS (100 GB Backup):                  3 EUR
──────────────────────────────────────────────
GESAMT:                                ~690 EUR/Monat

AWS (EKS, eu-central-1 Frankfurt):
├── EKS Cluster:                         73 EUR
├── 3x m6i.xlarge (4 vCPU, 16 GB):    330 EUR
├── 100 GB gp3 EBS:                       9 EUR
├── ALB:                                  25 EUR + Traffic
├── RDS PostgreSQL (Multi-AZ, m6i.l):  340 EUR
├── 1 TB Outbound:                       85 EUR
└── S3 (100 GB):                           3 EUR
──────────────────────────────────────────────
GESAMT:                                ~865 EUR/Monat

Azure (AKS, Germany West Central):
├── AKS Cluster:                          0 EUR (Standard Free)
├── 3x D4s_v5 (4 vCPU, 16 GB):        320 EUR
├── 100 GB Premium SSD:                  18 EUR
├── App Gateway:                          60 EUR
├── Azure DB PostgreSQL (HA):           380 EUR
├── 1 TB Outbound:                       75 EUR
└── Blob Storage (100 GB):                3 EUR
──────────────────────────────────────────────
GESAMT:                                ~856 EUR/Monat

OTC ist 20-25% guenstiger bei vergleichbarer Compute-Leistung. Der Preisvorteil kommt hauptsaechlich durch guenstigere VM-Preise und kostenloses Cluster-Management.

Aber Vorsicht: Die niedrigeren Kosten bei OTC koennen durch hoeheren Betriebsaufwand ausgeglichen werden, wenn Sie Dienste selbst betreiben muessen, die bei AWS/Azure als Managed Service verfuegbar sind. Ein Managed Kubernetes Partner schliesst diese Luecke.

DSGVO und Datensouveraenitaet: Konkreter Nutzen

Was "deutsche Cloud" rechtlich bedeutet

Der Begriff "deutsche Cloud" ist nicht geschuetzt. Entscheidend sind drei Kriterien:

1. Datenstandort: Rechenzentrum in Deutschland (OTC: Biere/Magdeburg)
2. Betreiber-Jurisdiktion: Deutsches Unternehmen, deutsches Recht (T-Systems International GmbH)
3. Kein Zugriff durch Drittstaaten: Kein CLOUD Act, kein FISA (kein US-Mutterkonzern)

OTC erfuellt alle drei Kriterien. AWS Frankfurt erfuellt nur Kriterium 1.

Praktische Auswirkungen

Fuer Ihren Datenschutzbeauftragten bedeutet das:

Das heisst nicht, dass AWS oder Azure unsicher sind. Es heisst, dass die rechtliche Argumentation einfacher ist, wenn Sie gegenueber Aufsichtsbehoerden, Kunden oder Auditoren nachweisen muessen, wo und wie Daten verarbeitet werden.

Mehr zu DSGVO-Compliance in Kubernetes finden Sie im DSGVO-Compliance-Guide.

Wann OTC die richtige Wahl ist -- und wann nicht

OTC ist die richtige Wahl, wenn:

• Regulatorische Anforderungen den Betrieb auf deutscher Infrastruktur nahelegen (KRITIS, Gesundheitswesen, oeffentlicher Sektor)
• Kunden oder Partner explizit eine deutsche Cloud verlangen (z.B. in Ausschreibungen)
• Der Workload Standard ist: Webapplikationen, APIs, Datenbanken, Batch-Processing
• Budget relevant ist: 20-25% geringere Infrastrukturkosten sind fuer den Mittelstand signifikant
• Einfachheit gefragt ist: Weniger Services bedeutet auch weniger Entscheidungskomplexitaet

OTC ist nicht die richtige Wahl, wenn:

• Sie AWS/Azure-spezifische Services brauchen: Lambda, SageMaker, Cognitive Services etc. haben kein OTC-Equivalent
• Globale Verfuegbarkeit noetig ist: OTC hat Regionen in DE und NL, aber keine globale Praesenz wie die Hyperscaler
• Ihr Team bereits Hyperscaler-Expertise hat: Umlernen kostet Zeit, auch wenn die Konzepte aehnlich sind
• Advanced Networking gebraucht wird: Service Mesh, API Management und aehliche Dienste muessen selbst betrieben werden

Der pragmatische Mittelweg

Fuer viele Mittelstaendler ist die Antwort nicht "entweder oder", sondern eine bewusste Verteilung:

Workloads mit personenbezogenen Daten:
└── Open Telekom Cloud (CCE)
    ├── Kunden-Datenbank
    ├── ERP-Anbindung
    └── Dokumenten-Management

Workloads ohne regulatorische Anforderungen:
└── AWS oder Azure
    ├── Marketing-Website
    ├── Analytics-Pipeline
    └── KI/ML-Workloads

Kubernetes macht diese Aufteilung technisch einfach: Gleiche Container, gleiche Helm Charts, verschiedene Cluster in verschiedenen Clouds.

Managed Kubernetes auf OTC: Warum das sinnvoll ist

Die Kombination aus OTC und Managed Kubernetes Service loest zwei Probleme gleichzeitig:

Problem 1: OTC hat weniger Managed Services als die Hyperscaler. Ein Managed Kubernetes Partner kompensiert das mit Open-Source-Tools: Prometheus/Grafana statt CloudWatch, Cert-Manager statt ACM, ArgoCD statt CodePipeline.

Problem 2: Ihr Team hat keine Cloud-Expertise. Ein Mittelstaendler mit 500 Mitarbeitern hat typischerweise 3-5 IT-Mitarbeiter, die sich um alles kuemmern -- von Helpdesk bis Netzwerk. Kubernetes-Expertise auf OTC selbst aufzubauen ist unrealistisch.

Was der Managed Service auf OTC abdeckt

Ihr Team:                       Managed Service:
├── Applikationen deployen      ├── CCE Cluster Betrieb
├── Monitoring-Dashboards       ├── Worker Node Management
│   ansehen                     ├── Prometheus + Grafana Setup
├── Incidents melden            ├── Backup mit Velero
└── Features entwickeln         ├── Network Policies
                                ├── Security Scanning (Trivy)
                                ├── Log-Aggregation (Loki)
                                ├── Ingress + TLS (cert-manager)
                                └── 24/7 Operations

Die Kosten dafuer liegen typischerweise bei 2.500-4.000 EUR/Monat -- deutlich weniger als eine einzige DevOps-Stelle. Warum das sinnvoll ist, erklaert auch unser Freelancer vs. Managed Service Vergleich.

Migration: Von bestehender Infrastruktur auf OTC

Von On-Premise auf OTC

Wenn Sie heute eigene Server betreiben, ist der Weg zu OTC ein zweistufiger Prozess:

1. Containerisierung: Ihre Anwendungen in Docker-Container verpacken (unabhaengig von der Ziel-Cloud)
2. Deployment auf CCE: Container auf dem OTC Kubernetes-Cluster deployen

Der Aufwand liegt typischerweise bei 4-8 Wochen fuer eine Standard-Applikation. Details zur Cloud-Migration finden Sie im Cloud-Native-Migrations-Guide.

Von AWS/Azure auf OTC

Wenn Sie bereits Kubernetes nutzen, ist die Migration einfacher:

# Kubernetes-Manifests sind cloud-agnostisch
# Was sich aendert:

# 1. StorageClass (AWS gp3 wird zu OTC EVS)
# storageClassName: gp3        -> storageClassName: csi-disk

# 2. Load Balancer Annotations
# service.beta.kubernetes.io/aws-load-balancer-type: nlb
# wird zu:
# kubernetes.io/elb.class: shared

# 3. Node-Selektoren (wenn verwendet)
# node.kubernetes.io/instance-type: m6i.xlarge
# wird zu:
# node.kubernetes.io/instance-type: s3.xlarge.2

Helm Charts und Kustomize-Overlays machen diese Unterschiede handhabbar. Der eigentliche Aufwand liegt nicht im Kubernetes-Layer, sondern in der Migration von Managed Services (RDS, Elasticache, S3-Buckets).

Checkliste: Ist OTC fuer Ihr Unternehmen geeignet?

Beantworten Sie diese Fragen fuer Ihre Situation:

[ ] Verarbeiten wir personenbezogene Daten, die unter DSGVO fallen?
[ ] Haben wir Kunden oder Partner, die eine deutsche Cloud fordern?
[ ] Unterliegen wir branchenspezifischer Regulierung (BaFin, BSI, etc.)?
[ ] Sind unsere Workloads Standard (Web, API, DB) ohne exotische Cloud-Services?
[ ] Ist unser IT-Budget begrenzt (OTC ist 20-25% guenstiger)?
[ ] Haben wir Bedenken gegenueber dem US CLOUD Act?

Mehr als 3x Ja: OTC ist eine ernsthafte Option.
Weniger als 3x Ja: Bleiben Sie bei Ihrem Hyperscaler.

Fazit: Deutsche Cloud ist kein Patriotismus, sondern Pragmatismus

Die Entscheidung fuer eine deutsche Cloud ist keine ideologische, sondern eine geschaeftliche. Fuer mittelstaendische Unternehmen in regulierten Branchen vereinfacht OTC die Compliance-Argumentation erheblich. Die Kombination mit einem Managed Kubernetes Service kompensiert die Luecken im Service-Katalog und den fehlenden internen Cloud-Knowhow.

Das Ergebnis: Kubernetes-Workloads auf deutscher Infrastruktur, DSGVO-konform, zu wettbewerbsfaehigen Kosten -- ohne dass Sie ein Cloud-Team aufbauen muessen.

Verwandte Artikel

• DSGVO-konforme Kubernetes-Cluster: Encryption, RBAC und Audit-Logging
• Kubernetes Compliance ohne Vollzeit-Security-Team
• Cloud-Native Migration fuer den Mittelstand
• Kubernetes Managed Service vs. Inhouse im Vergleich
• NIS2-Compliance mit Kubernetes umsetzen

Sie evaluieren eine deutsche Cloud fuer Ihre Kubernetes-Workloads? Wir beraten bei der Auswahl und uebernehmen den Betrieb -- auf OTC, Hetzner oder jeder anderen Plattform Ihrer Wahl. Sprechen Sie uns an.