Von AWS/Azure abhaengig: Wie Kubernetes Ihnen die Cloud-Exit-Option sichert

TL;DR

• Cloud Vendor Lock-in entsteht nicht durch die Cloud selbst, sondern durch proprietaere Services (Aurora, Cosmos DB, Lambda, Azure Functions).
• Kubernetes ist die beste Exit-Versicherung: Workloads laufen auf EKS, AKS, GKE und On-Premise identisch -- wenn Sie es richtig aufsetzen.
• Portable Manifests + Terraform-Abstraktionen ermoeglichen einen Cloud-Wechsel in Wochen statt Jahren.
• Der vollstaendige Exit aus AWS/Azure kostet typischerweise 150.000-500.000 EUR und dauert 6-18 Monate. Mit Kubernetes-Portabilitaet reduziert sich das auf ein Drittel.
• Die Cloud-Exit-Option ist auch dann wertvoll, wenn Sie sie nie nutzen -- sie staerkt Ihre Verhandlungsposition bei Vertragserneuerungen.

Warum Cloud Lock-in ein echtes Problem ist

Sie haben vor drei Jahren auf AWS gesetzt. Die Entscheidung war richtig: schneller Start, keine Hardware-Investition, globale Verfuegbarkeit. Aber jetzt, drei Jahre spaeter, sieht die Bilanz anders aus.

Ihre Applikationen nutzen Aurora statt PostgreSQL. Die Event-Verarbeitung laeuft auf Lambda. IAM-Rollen sind tief in den Applikationscode integriert. SQS, SNS, S3, CloudFront -- ueberall proprietaere Services.

Ein Wechsel zu Azure oder zurueck On-Premise? Ihr CTO schaetzt 18 Monate und 500.000 EUR. Also bleiben Sie bei AWS und akzeptieren die naechste Preiserhoehung.

Genau das ist Cloud Vendor Lock-in. Und es betrifft nicht nur Grosskonzerne -- gerade der Mittelstand mit begrenzten Ressourcen fuer Migrationen ist besonders verwundbar.

Wo Lock-in tatsaechlich entsteht

Nicht alles in der Cloud erzeugt Lock-in. Es ist wichtig zu unterscheiden, welche Services portabel sind und welche Sie fesseln:

Die Faustregel: Je weiter oben im Stack, desto proprietaerer. Kubernetes sitzt bewusst in der Mitte -- es abstrahiert die Infrastruktur, ohne Sie in ein spezifisches Oekosystem zu zwingen.

Kubernetes als Portabilitaetsschicht

Kubernetes ist nicht nur ein Orchestrator -- es ist eine Abstraktionsschicht. Ein Deployment-Manifest, das auf EKS laeuft, laeuft auch auf AKS, GKE oder einem Bare-Metal-Cluster in Ihrem Rechenzentrum. Das ist der entscheidende Unterschied zu Lambda oder Azure Functions.

Was portabel ist (und was nicht)

Portabel (Kubernetes-Standard-API):
├── Deployments, StatefulSets, DaemonSets
├── Services (ClusterIP, NodePort)
├── ConfigMaps, Secrets
├── RBAC (Roles, RoleBindings)
├── Network Policies
├── CronJobs, Jobs
├── HPA (Horizontal Pod Autoscaler)
└── PersistentVolumeClaims (mit CSI-Treibern)

Cloud-spezifisch (braucht Anpassung):
├── LoadBalancer Services (ALB, Azure LB)
├── Ingress (AWS ALB Controller vs. nginx)
├── StorageClasses (gp3 vs. managed-premium)
├── ServiceAccounts mit Cloud-IAM
├── ExternalDNS-Konfiguration
└── Cluster Autoscaler / Karpenter Config

Der Trick: Die cloud-spezifischen Teile machen typischerweise 10-15% der gesamten Kubernetes-Konfiguration aus. Wenn Sie diese sauber abstrahieren, ist der Rest portabel.

Praxis: Portable Manifests schreiben

Strategie 1: Kustomize Overlays fuer Multi-Cloud

Kustomize ist in kubectl eingebaut und ermoeglicht es, eine Basis-Konfiguration mit cloud-spezifischen Overlays zu kombinieren:

# base/deployment.yaml -- laeuft ueberall identisch
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-service
spec:
  replicas: 3
  selector:
    matchLabels:
      app: api-service
  template:
    metadata:
      labels:
        app: api-service
    spec:
      containers:
        - name: api
          image: registry.company.de/api-service:v2.4.1
          ports:
            - containerPort: 8080
          resources:
            requests:
              cpu: "250m"
              memory: "512Mi"
            limits:
              cpu: "1"
              memory: "1Gi"
          env:
            - name: DATABASE_URL
              valueFrom:
                secretKeyRef:
                  name: db-credentials
                  key: url
---
# base/service.yaml -- portabel
apiVersion: v1
kind: Service
metadata:
  name: api-service
spec:
  selector:
    app: api-service
  ports:
    - port: 80
      targetPort: 8080
---
# overlays/aws/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - ../../base
patches:
  - target:
      kind: Service
      name: api-service
    patch: |
      - op: add
        path: /metadata/annotations
        value:
          service.beta.kubernetes.io/aws-load-balancer-type: "nlb"
          service.beta.kubernetes.io/aws-load-balancer-scheme: "internet-facing"
      - op: replace
        path: /spec/type
        value: LoadBalancer
---
# overlays/azure/kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - ../../base
patches:
  - target:
      kind: Service
      name: api-service
    patch: |
      - op: add
        path: /metadata/annotations
        value:
          service.beta.kubernetes.io/azure-load-balancer-internal: "false"
      - op: replace
        path: /spec/type
        value: LoadBalancer

Deployment: kubectl apply -k overlays/aws/ oder kubectl apply -k overlays/azure/. Die Basis bleibt identisch, nur die Overlay-Dateien aendern sich.

Strategie 2: Terraform fuer cloud-agnostische Infrastruktur

Terraform abstrahiert die Cloud-Infrastruktur unter Kubernetes. Statt direkt EKS oder AKS zu konfigurieren, definieren Sie Module, die austauschbar sind:

# modules/kubernetes-cluster/main.tf
# Einheitliches Interface, verschiedene Backends

variable "cloud_provider" {
  type        = string
  description = "aws, azure oder hetzner"
}

variable "cluster_name" {
  type = string
}

variable "node_count" {
  type    = number
  default = 3
}

variable "node_size" {
  type        = string
  description = "Abstrakte Groesse: small, medium, large"
}

locals {
  node_types = {
    aws = {
      small  = "t3.medium"
      medium = "m5.large"
      large  = "m5.xlarge"
    }
    azure = {
      small  = "Standard_D2s_v3"
      medium = "Standard_D4s_v3"
      large  = "Standard_D8s_v3"
    }
    hetzner = {
      small  = "cpx31"
      medium = "cpx41"
      large  = "cpx51"
    }
  }
}

module "eks" {
  source = "./eks"
  count  = var.cloud_provider == "aws" ? 1 : 0

  cluster_name = var.cluster_name
  node_type    = local.node_types["aws"][var.node_size]
  node_count   = var.node_count
}

module "aks" {
  source = "./aks"
  count  = var.cloud_provider == "azure" ? 1 : 0

  cluster_name = var.cluster_name
  node_type    = local.node_types["azure"][var.node_size]
  node_count   = var.node_count
}

module "hetzner" {
  source = "./hetzner"
  count  = var.cloud_provider == "hetzner" ? 1 : 0

  cluster_name = var.cluster_name
  node_type    = local.node_types["hetzner"][var.node_size]
  node_count   = var.node_count
}

# Output: kubeconfig -- egal welcher Provider
output "kubeconfig" {
  value = coalesce(
    try(module.eks[0].kubeconfig, ""),
    try(module.aks[0].kubeconfig, ""),
    try(module.hetzner[0].kubeconfig, "")
  )
  sensitive = true
}

Der Wechsel des Cloud-Providers wird zu einer Aenderung von cloud_provider = "aws" zu cloud_provider = "azure". Die Kubernetes-Manifests oben drauf aendern sich nicht.

Die Cloud-Exit-Kostenrechnung

Jeder IT-Leiter sollte wissen, was ein Cloud-Exit kosten wuerde -- auch wenn er nie stattfindet. Hier die realistische Kalkulation:

Ohne Portabilitaetsstrategie

Cloud-Exit von AWS nach Azure (ohne Kubernetes-Portabilitaet):

Analyse und Planung:                    40.000 -  80.000 EUR
Applikations-Refactoring:              100.000 - 250.000 EUR
  (Aurora -> PostgreSQL, Lambda -> Containers,
   SQS -> RabbitMQ, IAM-Umbau)
Daten-Migration:                        20.000 -  50.000 EUR
Testing und Validierung:                30.000 -  60.000 EUR
Parallelbetrieb (3-6 Monate):          50.000 - 100.000 EUR
Schulung des Teams:                     10.000 -  20.000 EUR
──────────────────────────────────────────────────────────────
Gesamt:                                250.000 - 560.000 EUR
Dauer:                                 12 - 18 Monate
Risiko:                                Hoch

Mit Kubernetes-Portabilitaetsstrategie

Cloud-Exit von AWS nach Azure (mit Kubernetes + Terraform):

Analyse und Planung:                    15.000 -  25.000 EUR
Terraform-Anpassung (Module wechseln):  10.000 -  20.000 EUR
Kustomize-Overlays anpassen:             5.000 -  10.000 EUR
Daten-Migration:                        20.000 -  50.000 EUR
Testing und Validierung:                15.000 -  30.000 EUR
Parallelbetrieb (4-8 Wochen):          10.000 -  20.000 EUR
──────────────────────────────────────────────────────────────
Gesamt:                                 75.000 - 155.000 EUR
Dauer:                                  3 - 6 Monate
Risiko:                                 Mittel-Niedrig

Die Differenz: 175.000-405.000 EUR gespart. Das ist der Wert einer Portabilitaetsstrategie.

Die 5 groessten Lock-in-Fallen (und wie Sie sie vermeiden)

Falle 1: Proprietaere Datenbanken

Problem: Aurora Serverless, Cosmos DB oder DynamoDB sind bequem, aber nicht portabel. Ein Wechsel erfordert Applikations-Umbau.

Loesung: Verwenden Sie Standard-Datenbanken (PostgreSQL, MySQL, Redis) als Managed Service oder als Operator im Cluster. CloudNativePG oder der Zalando PostgreSQL Operator laufen ueberall.

Falle 2: Cloud-native IAM im Applikationscode

Problem: boto3.client('sts').assume_role() im Python-Code bindet Sie direkt an AWS.

Loesung: Nutzen Sie Kubernetes ServiceAccounts mit Workload Identity Federation. Die Applikation kennt nur den ServiceAccount -- die Zuordnung zum Cloud-IAM passiert aussen.

Falle 3: Serverless Functions statt Containern

Problem: 200 Lambda-Funktionen migrieren ist ein Albtraum.

Loesung: Fuer neue Workloads: Container statt Functions. Fuer bestehende: Evaluieren Sie Knative als portablen Serverless-Layer auf Kubernetes.

Falle 4: Managed Message Queues

Problem: SQS, SNS und Kinesis haben keine 1:1-Entsprechung bei Azure.

Loesung: NATS oder RabbitMQ als Helm Chart im Cluster deployen. Performance und Features reichen fuer die meisten Mittelstands-Workloads.

Falle 5: Cloud-spezifische Storage-Features

Problem: EFS, EBS-Snapshots oder Azure Files haben unterschiedliche APIs.

Loesung: Nutzen Sie Kubernetes CSI-Treiber konsequent. PVCs sind portabel -- nur die StorageClass aendert sich pro Cloud.

Mehr zum Thema Storage-Abstraktionen finden Sie im Kubernetes Storage Guide.

Multi-Cloud vs. Cloud-Exit-Option: Was brauchen Sie wirklich?

Viele verwechseln diese beiden Strategien. Sie sind grundverschieden:

Empfehlung fuer den Mittelstand: Fahren Sie eine Cloud, aber sichern Sie sich die Exit-Option. Multi-Cloud aktiv zu betreiben ist fuer Unternehmen mit 300-1.000 Mitarbeitern in der Regel zu komplex und zu teuer. Die Exit-Option hingegen ist eine Versicherung, die wenig kostet und viel bringt.

Zur Vertiefung empfehlen wir den Multi-Cluster Management Guide.

Die Verhandlungsposition staerken

Der groesste Wert der Cloud-Exit-Option ist oft nicht der Exit selbst, sondern die Verhandlungsposition.

Wenn Ihr AWS-Account-Manager weiss, dass Sie in 3 Monaten zu Azure oder Hetzner wechseln koennten, verhandeln Sie Enterprise Discount Programs ganz anders. Cloud-Provider geben routinemaessig 10-30% Rabatt fuer langfristige Commitments -- aber nur, wenn sie glauben, dass Sie tatsaechlich wechseln koennten.

Dokumentieren Sie Ihre Portabilitaetsstrategie. Zeigen Sie beim naechsten Vertragsgespraech Ihre Terraform-Module und Kustomize-Overlays. Das ist mehr wert als jeder Preisvergleich auf einem PowerPoint-Slide.

Checkliste: Cloud-Portabilitaet bewerten

Pruefen Sie fuer Ihren aktuellen Stack:

Infrastruktur:

• Kubernetes-Cluster per Terraform/Pulumi verwaltet (nicht per Cloud-Console)?
• Cluster-Setup cloud-agnostisch abstrahiert (austauschbare Module)?
• DNS und Load Balancing ueber ExternalDNS und Ingress Controller (nicht cloud-nativ)?

Applikationen:

• Deployments, Services, ConfigMaps als Standard-Kubernetes-Manifests?
• Kein cloud-spezifischer Code in den Applikationen (kein boto3, kein Azure SDK fuer Kernlogik)?
• Datenbanken als Standard-Engine (PostgreSQL, MySQL) statt proprietaer?

Daten:

• Backup-Strategie, die cloud-unabhaengig funktioniert (Velero)?
• Daten-Export-Mechanismus getestet?
• Object Storage ueber S3-kompatible API angebunden (MinIO als Fallback)?

Prozesse:

• CI/CD-Pipeline cloud-unabhaengig (GitHub Actions, GitLab CI, ArgoCD)?
• Container Registry austauschbar (Harbor als Self-Hosted-Option)?
• Monitoring-Stack Open Source (Prometheus/Grafana statt CloudWatch/Azure Monitor)?

Fuer die CI/CD-Portabilitaet empfehlen wir unseren ArgoCD GitOps Tutorial.

Fazit

Cloud Vendor Lock-in mit Kubernetes zu vermeiden ist keine Raketenwissenschaft -- es erfordert aber Disziplin. Die drei Grundregeln:

1. Standard-Kubernetes-API nutzen, wo immer moeglich. Kustomize Overlays fuer cloud-spezifische Anpassungen.
2. Proprietaere Services meiden oder hinter Abstraktionen verstecken. PostgreSQL statt Aurora, NATS statt SQS, Container statt Lambda.
3. Terraform-Module cloud-agnostisch strukturieren. Der Provider-Wechsel sollte eine Variable sein, kein Projekt.

Die Exit-Option kostet Sie 10-20% mehr Aufwand beim initialen Setup. Sie spart Ihnen im Ernstfall Hunderttausende Euro und Monate an Migrationszeit. Und sie staerkt ab sofort Ihre Verhandlungsposition.

Kubernetes ist nicht die Cloud -- Kubernetes laeuft auf jeder Cloud. Nutzen Sie das.

Sie moechten Ihre aktuelle Cloud-Strategie auf Portabilitaet pruefen lassen? Wir analysieren Ihren Stack und zeigen konkret, wo Lock-in-Risiken bestehen und wie Sie diese reduzieren -- kostenloses Erstgespraech vereinbaren.