Airbus ist ausgestiegen. Könnten Sie es auch? Das CTO‑Cloud‑Exit‑Playbook für 2026

Dass Airbus sich von AWS abwendet, ist kein Mannschaftssport. Es ist ein Signal. Wenn ein Tier‑1‑Unternehmen bereit ist, seinen Stack neu zu verkabeln, um wieder Hebelwirkung zu gewinnen, sollten Sie sich zumindest eine harte Frage stellen: Wenn Sie innerhalb von 12 Monaten 25 % Ihrer Workloads verlagern müssten – könnten Sie das tun, ohne die Lieferfähigkeit zu sprengen?

Die meisten Start‑ups und Scale‑ups können das nicht. Nicht, weil der Code anderswo nicht laufen würde, sondern weil der Klebstoff nicht hält. Managed Services, Identity‑Verdrahtung, Netzwerkannahmen und Daten‑Schwerkraft werden zu Beton. Dieser Beitrag bietet ein Entscheidungs‑Framework, das Sie von der guten Idee zur belastbaren Option bringt.

Was der Schritt von Airbus für Sie wirklich bedeutet

Wenn ein Schwergewicht Unabhängigkeit erklärt, hören Cloud‑Provider zu. Preise werden weicher. Migrationsguthaben tauchen auf. Roadmaps verschieben sich. Profitieren werden Sie aber nur, wenn Sie technisch bereit sind, zu gehen. Hebelwirkung kommt von Exit‑Fähigkeit, nicht von Tweets.

2026 bedeutet Exit‑Fähigkeit weniger „Lift‑and‑Shift“ und mehr „können wir die gleichen SLOs ohne proprietäres Verhalten betreiben?“. Das heißt, Sonderfunktionen (Step Functions, SQS‑FIFO‑Semantik, X‑Ray, KMS‑Key‑Policies) durch offene Äquivalente zu ersetzen, die Sie überall betreiben können.

Die ehrliche Inventur: Ihre Abhängigkeiten sind der Lock‑in

Vergessen Sie das Marketing‑Deck — machen Sie einen Abhängigkeits‑Zensus. In der Praxis versteckt sich Lock‑in an fünf Stellen:

• Identity und Auth: STS/KMS‑gebundene IAM‑Rollen, cloud‑spezifische Service‑Identitäten und im Code verbackene signierte URL‑Flows.
• Networking: NAT‑Gateways, VPC‑Endpoints und Annahmen zur Abrechnung über AZs hinweg. Egress und Hairpins können Kosten und Komplexität dominieren.
• Data Plane: DynamoDB‑GSIs/Streams, Redshift‑ und BigQuery‑SQLismen, S3‑Eventing und Lifecycle‑Policies für Objektspeicher.
• Async und Workflows: SQS/SNS‑Fan‑out‑Muster, Step Functions, EventBridge‑Regeln, Kinesis‑Partitionierung.
• Observability und Ops: Cloud‑native Traces/Metrics/Logs (z. B. X‑Ray, CloudWatch Logs) und gemanagte Secret Stores (SSM, Secrets Manager).

Wenn wir reale Stacks auditieren, sind 60–80 % der App‑Container in Stunden portierbar. Die anderen 20–40 % werden durch die oben genannten Punkte an einen Provider geklebt. Das ist die echte Migrationslandkarte.

Ein Vier‑Felder‑Entscheidungs‑Framework für Ihr Portfolio

Kennzeichnen Sie jede Workload in einem dieser Buckets. Seien Sie kompromisslos.

1) Heute portierbar (zuerst verschieben)

Stateless Services in Containern mit externalisierter Config und OpenTelemetry, die über TCP mit Postgres oder Redis sprechen. Diese ziehen in wenigen Tagen um, wenn Sie Images, IaC und Secrets abstrahiert haben. Nutzen Sie sie, um Ihre Landing Zone und GitOps zu beweisen.

2) Mit Shims portierbar (braucht Ersatz)

Alles, was SQS/SNS, CloudWatch/X‑Ray, Secrets Manager oder KMS‑Envelope‑Verschlüsselung mit IAM‑Bindung nutzt. Sie brauchen Drop‑in‑Äquivalente: NATS/Redpanda, OpenTelemetry‑Collector, External‑Secrets‑Controller und ein Plattform‑KMS, das Envelope Keys mit service‑spezifischen Rollen unterstützt.

3) Durch Daten‑Schwerkraft verankert (zuletzt bewegen)

RDS/Aurora im Multi‑Terabyte‑Bereich, Redshift/BigQuery‑Warehouses, S3‑Buckets im Petabyte‑Maßstab mit Event‑Glue. Planen Sie Dual‑Write oder CDC‑Replikation, Schema‑Normalisierung (ANSI‑SQL + Views) und Backfill‑Fenster mit explizitem RPO/RTO.

4) Hart verankertes PaaS (keine neuen Abhängigkeiten)

Step Functions, EventBridge‑lastige Automationen, Kinesis‑Analytics, proprietäre ML‑Endpoints. Frieren Sie neue Abhängigkeiten ein, bauen Sie bestehende ab, wo es geht, und kapseln Sie den Rest hinter internen Fassaden, damit der Blast Radius klein bleibt.

Rechnen Sie nach: Egress, NAT und Transfer sind keine Rundungsfehler

Das ist kein Angstmachen. Es ist Arithmetik.

• Internet‑Egress: Als Hausnummer liegt der Datentransfer aus einer großen Cloud ins Internet oft bei etwa $0.05–$0.09/GB je nach Stufe und Volumen. Bewegen Sie 200 TB in einem Monat, liegen Sie allein für ausgehende Bytes bei $10k–$18k. Das ist vor Compute, Storage‑Reads und Ops.
• NAT‑Gateway‑Steuer: Viele Teams entdecken sechsstellige jährliche NAT‑Rechnungen spät. Bei $0.045/GB entsprechen 500 TB/Monat ausgehendem NAT‑Traffic ≈$23k/Monat. Nehmen Sie Private Endpoints und Egress‑Architektur bevor Sie Traffic in eine neue Cloud spiegeln, unter das Mikroskop.
• Private Links: Direkte Interconnects können die Kosten pro GB gegenüber öffentlichem Egress deutlich senken, aber Sie tauschen Capex/Commit gegen Opex‑Einsparungen. Bewerten und planen Sie beide Wege; nehmen Sie nicht an, dass einer universell besser ist.
• Bulk‑Export: Für einmalige große Umzüge aus Objektspeichern erwägen Sie physische Exportgeräte oder verhandelte Migrationsguthaben. Sprechen Sie Ihr Account‑Team an. Exit‑Hebel erhöhen die Chancen auf spürbare Zugeständnisse.

Modellieren Sie drei Szenarien: einmaliger Bulk‑Exit, Dual‑Run im steady state (3–6 Monate) und Multi‑Cloud im steady state (unbefristet). Jedes hat eine andere Kostenkurve und ein anderes Betriebsrisiko.

Designprinzipien, die einen Exit möglich machen

Das ist kein Dogma. Es ist die minimal tragfähige Portabilitätsschicht.

• Identity: OIDC überall. Standardisieren Sie auf OIDC‑Service‑Identitäten mit kurzlebigen Tokens. Für In‑Cluster‑Identitäten nutzen Sie SPIFFE/SPIRE, damit Workloads nicht IAM/Service Accounts einer einzelnen Cloud voraussetzen. Steuern Sie KMS‑Zugriff über OIDC‑Claims, nicht über provider‑spezifische Rollen.
• Secrets: externalisieren mit Controller. Verwenden Sie einen External‑Secrets‑Operator (Kubernetes), der aus jedem Backend lesen kann (Cloud‑KMS, HashiCorp Vault). Ihre Apps bekommen den gleichen Mount, egal wo das Secret lebt.
• Compute: zuerst Container, Funktionen später. Wenn es keine burstige Millisekunden‑Skalierung braucht, läuft es in Containern. Wo Sie FaaS behalten müssen, wählen Sie eine Runtime, die auch auf Knative oder OpenFaaS läuft, und verstecken Sie Provider‑SDKs hinter einer internen Schnittstelle.
• Networking: Hairpins eliminieren. Bevor Sie Traffic spiegeln, reduzieren Sie NAT‑ und Cross‑AZ‑Hairpins mittels VPC‑Endpoints, Private Service Connect, Dual‑Stack‑IPv6 und internen Load Balancern. Portabilität scheitert an Bandbreitenrechnungen.
• Data: offene Formate und portable Engines. Bevorzugen Sie Postgres gegenüber proprietärem NoSQL, es sei denn, Sie brauchen wirklich Dynamo‑Klassen‑Skalierung. Für Analytics standardisieren Sie auf Parquet + Apache Iceberg oder ähnliche offene Tabellenformate, damit Engines (Spark, Trino, Dremio, DuckDB) austauschbar sind.
• Async: auf einen portablen Bus standardisieren. SQS ist gut – bis es das nicht mehr ist. Für komplexe Topologien standardisieren Sie auf Kafka/Redpanda oder NATS JetStream und behandeln Sie Cloud‑Queues als Edge‑Adapter.
• Observability: OpenTelemetry oder gar nicht. Emittieren Sie OTel‑Traces/Metrics/Logs. Routen Sie über Collectors, die Sie kontrollieren. Wenn Sie auf X‑Ray oder Cloud‑Monitoring‑Features angewiesen sind, behalten Sie sie als Sinks, nicht als Sources.

Ein zweispuriger Migrationsplan, der die Lieferfähigkeit erhält

Sie müssen nicht zwischen Feature‑Entwicklung und Portabilität wählen. Fahren Sie zwei Spuren parallel mit strikt begrenztem Blast Radius.

Spur A: Aufhören zu graben

• Neue proprietäre Features einfrieren. Etablieren Sie einen Ausnahmeprozess. Wenn jemand Step Functions will, bringt er eine Portabilitäts‑Story mit — oder Sie liefern einen internen Wrapper.
• Den Plattform‑Vertrag standardisieren. Definieren Sie Golden Paths: Container‑Buildpacks, Service‑Identitäten, Secrets, OTel, Health‑Probes, SLOs. Machen Sie Konformität einfacher als Abweichung.
• Refaktorieren Sie den Klebstoff, nicht die App. Ersetzen Sie SDK‑Aufrufe zu Cloud‑Services durch interne Schnittstellen. Verlagern Sie Signierung, Pagination, Retries und Idempotenz in Shared Libraries, die Sie besitzen.

Spur B: Die alternative Landing Zone bauen

• Ein glaubwürdiges Ziel wählen. Ein anderer Hyperscaler, ein regionaler Player oder ein Colo‑Kubernetes‑Cluster — wählen Sie eines und werden Sie konkret. Zielen Sie nicht auf abstrakte Multi‑Cloud, sondern auf ein zweites Zuhause, das Sie betreiben können.
• Eine minimale Plattform aufsetzen. Kubernetes mit GitOps, SPIRE, External‑Secrets, OTel‑Collectors, S3‑kompatiblem Objektspeicher (nativ oder MinIO), Postgres und Ihrem Message Bus. Weniger bewegliche Teile gewinnen.
• Traffic für einen kleinen, wertvollen Service spiegeln. Wählen Sie einen portablen Service mit klaren SLOs. Fahren Sie Side‑by‑Side. Beweisen Sie Deploy, Rollback, Observability und Incident‑Pfad im neuen Land.
• Daten verantwortungsvoll verdrahten. Nutzen Sie CDC (z. B. Debezium), um Postgres zu spiegeln. Replizieren Sie für Objektspeicher Buckets mit Checksummen. Für Analytics schreiben Sie neue Tabellen in Iceberg und füllen inkrementell auf.

Setzen Sie ein explizites Ziel: Innerhalb von 90 Tagen sollen 10 % der Produktions‑RPS ausschließlich auf der neuen Landing Zone mit den gleichen SLOs laufen können. Wenn das unmöglich klingt, ist Ihr Plattform‑Vertrag zu locker.

Patterns für die klebrigen Stellen

DynamoDB‑lastige Apps

Drei Optionen:

• Behalten und isolieren: Wenn Sie an Dynamo‑Semantik gebunden sind (GSIs, Streams, Conditional Writes), isolieren Sie die Abhängigkeit hinter einem Service und lassen Sie die Daten „zu Hause“, während Compute umzieht. Akzeptieren Sie Latenz und Egress‑Kosten.
• Schema‑ und Zugriffs‑Makeover: Migrieren Sie Hot Paths auf Postgres‑JSONB mit gut gewählten Indizes oder auf einen Cassandra/Scylla‑Cluster. Nutzen Sie CDC, um Systeme bis zum Cutover synchron zu halten.
• Fassade zuerst: Führen Sie eine interne Repository‑Schicht ein, die nur den Teil der Dynamo‑Features abbildet, den Sie nutzen. Ersetzen Sie die Implementierung später.

Step Functions und EventBridge

Ersetzen Sie bei langlaufenden Workflows durch Temporal oder Cadence. Das ist nicht kostenlos: Sie übernehmen operative Komplexität, besitzen aber Ihre Orchestrierung und können sie überall betreiben.

S3‑Events und signierte URLs

Standardisieren Sie S3‑API‑Semantik als internen Vertrag. Für andere Clouds terminieren Sie auf dieselbe API über ein Gateway (native S3‑Kompatibilität oder ein Proxy), damit Ihre Apps keine neuen Dialekte lernen. Implementieren Sie Event‑Trigger mit Ihrem portablen Bus neu.

ML‑Endpoints und proprietäre Beschleuniger

Rufen Sie Vendor‑SDKs nicht direkt aus dem Produktcode auf. Schalten Sie vor jeden externen Modell‑Endpoint einen von Ihnen kontrollierten Broker mit Feature Flags und Fallbacks pro Modell. Containerisieren Sie Inference, wo möglich, und halten Sie Gewichte in offenen Formaten. Wenn Sie einen proprietären Beschleuniger verwenden müssen, isolieren Sie ihn hinter einer klaren Schnittstelle und messen Sie die Austauschkosten quartalsweise.

Verhandlung: Exit‑Hebel sind bares Geld wert

Sie können — und sollten — verhandeln:

• Egress‑Guthaben für Migration. Fordern Sie Guthaben, die explizit an Exit‑ oder Dual‑Run‑Zeitfenster gebunden sind. Sie werden überrascht sein, was auftaucht, wenn Sie eine funktionierende Alternative haben.
• Bring‑Your‑Own‑Key‑Konditionen. Wenn KMS‑Key‑Hoheit ein Knackpunkt ist, verhandeln Sie BYOK/BYOKMS‑Verbesserungen oder Portabilitätsklauseln, damit eine spätere Abkehr Sie nicht lahmlegt.
• Flexibilität bei Commitments. Drängen Sie auf Konvertibilität über Services und Regionen hinweg. Die Möglichkeit, Commitments umzuschichten, erleichtert einen gestuften Exit.

Exit‑Readiness macht auch Verlängerungsgespräche rational. Sie bluffen nicht, wenn Sie 10–25 % der Last ohne Re‑Architecture verlagern können.

Risiko und SLOs: Was Sie messen müssen, damit das Haus nicht abbrennt

Cloud‑Exits scheitern, wenn Führungskräfte Risiko zu wenig spezifizieren. Machen Sie Folgendes explizit:

• RPO/RTO pro Service‑Tier. Taggen Sie Services nach Kritikalität und setzen Sie konkrete Ziele (z. B. Tier 1: RPO ≤ 1 Minute, RTO ≤ 15 Minuten). Ihre Replikations‑ und Failover‑Designs sollten das belegen.
• Kostengeländer. Deckeln Sie Dual‑Run‑Kosten je Phase (z. B. +15 % Plattform‑Spend für 90 Tage). Wenn Sie darüber liegen, pausieren Sie und optimieren Egress/NAT, statt blind zu sprinten.
• Operative Parität. Incident Response, Rufbereitschaft, Dashboards, Log‑Retention und Security‑Kontrollen müssen in der neuen Landing Zone existieren, bevor Sie Kunden‑Traffic senden.
• Compliance‑Gating. Führen Sie ein fokussiertes Security‑Review zu IAM, Umgang mit Secrets, Logging und Data Residency durch. Exits verändern oft Ihre Compliance‑Story; lassen Sie Auditoren nicht Ihren ersten Feedback‑Loop sein.

Wo ein Nearshore‑Pod wirklich hilft

Das ist Aushubarbeit à la carte, kein Moonshot. Ein kleines Nearshore‑Pod (Brazil gibt Ihnen 6–8 Stunden Überlappung mit US‑Zeitzonen) kann Portabilitäts‑Arbeiten erledigen, während Ihr Kernteam Produkt ausliefert:

• Nutzung von Cloud‑SDKs hinter internen Schnittstellen und Shared Libraries refaktorieren.
• GitOps, SPIRE, External‑Secrets und OTel‑Collectors mit IaC aufsetzen.
• Managed Queues/Workflows durch Kafka/NATS/Temporal ersetzen und mit Chaos‑Tests abhärten.
• Analytics auf Parquet + Iceberg normalisieren und mit verifizierbaren Checksummen backfillen.
• Migrationläufe mit Kosten‑Telemetrie instrumentieren (pro GB, pro Request), damit Finance Fortschritt in Dollars statt in Adjektiven sieht.

Richtig gemacht, erhalten Sie Optionen, ohne Ihre Feature‑Roadmap durch den Schlamm zu ziehen.

12 Monate, drei Meilensteine

• 0–90 Tage: Neue proprietäre Features einfrieren. Alternative Landing Zone bauen. 1–2 Stateless Services End‑to‑End migrieren. CDC für eine nicht kritische Postgres‑Instanz aufsetzen. Kosten‑ und SLO‑Geländer implementieren.
• 90–180 Tage: Observability‑ und Secrets‑Pfade ersetzen. Einen echten, umsatznahen Service (Low bis Mid Tier) verlagern und 30 Tage bei ≥25 % RPS betreiben. Beginnen Sie, einen Hot Path zu ent‑Dynamo‑isieren oder isolieren Sie ihn hinter einer Fassade.
• 180–365 Tage: Ihren ersten Daten‑Schwerkraft‑Move landen (ein Warehouse oder ein großer Objektspeicher‑Bucket) mit messbarem RPO/RTO. Erreichen Sie die Fähigkeit, 25 % des Produktions‑Traffics für mindestens eine Woche vollständig außerhalb Ihrer primären Cloud zu fahren — ohne SLO‑Regression.

Anti‑Patterns, die Exits töten

• Alles neu schreiben. Sie machen kein Greenfield. Wrappen und strangeln. Ersetzen Sie den Klebstoff, nicht die App.
• Abstrahieren bis zum Umfallen. Schlanke, eigene Schnittstellen schlagen universelle Adapter, die Sie nicht verstehen.
• Observability‑Parität überspringen. Was Sie nicht sehen, können Sie nicht betreiben. Machen Sie OTel vor dem Cutover, nicht danach.
• Egress als trivial annehmen. Bytes kosten Geld und Zeit. Modellieren. Testen. Verhandeln.

Lock‑in ist nicht nur Cloud — achten Sie auf Ihre Formate

Diese Woche erinnerte auch daran, dass proprietäre Formate der leiseste Lock‑in‑Hebel sind. Treffen Sie dieselbe Entscheidung in Ihrem Stack:

• Data: Parquet + Iceberg statt anbieter‑spezifischer Table Layers. Behandeln Sie das Tabellenformat als First‑Class‑Vertrag.
• APIs: Bevorzugen Sie gRPC/HTTP‑Verträge, die Sie besitzen, statt Vendor‑SDK‑Aufrufe im Produktcode zu verstreuen.
• Config: Halten Sie IaC in Terraform/OpenTofu/Crossplane statt in proprietären Templates. Generieren, nicht klicken.

Sobald die Formate Ihnen gehören, konkurrieren Clouds über Preis, Latenz und Services. Das ist Hebelwirkung.

Die Pointe

Sie müssen Ihre Cloud nicht verlassen. Sie müssen es können. Der Schritt von Airbus ist der jüngste Beleg, dass Exit‑Fähigkeit ein strategisches Asset ist. Bauen Sie sie in bewussten Schichten auf — Identity, Secrets, Observability, Datenformate, Async — und belegen Sie sie mit einer zweiten Landing Zone, die echten Traffic trägt. Wenn die Finanzabteilung fragt „warum jetzt“, zeigen Sie ihnen die Kostenkurven und die Trümpfe in der Verhandlung, die Sie durch glaubwürdiges Multi‑Home verdienen.

Wesentliche Erkenntnisse

• Jede Workload in vier Buckets taggen: jetzt portierbar, mit Shims portierbar, durch Daten verankert, hart verankertes PaaS. Planen Sie Migrationen in genau dieser Reihenfolge.
• Egress‑, NAT‑ und Dual‑Run‑Kosten sind wesentlich. Modellieren Sie einmalige, Dual‑Run‑ und Multi‑Cloud‑Szenarien, bevor Sie Traffic bewegen.
• Standardisieren Sie Identity (OIDC/SPIRE), Secrets (externe Controller), Observability (OpenTelemetry) und Datenformate (Parquet + Iceberg), um Portabilität freizuschalten.
• Fahren Sie zweispurig: Frieren Sie neue proprietäre Features ein, während Sie eine zweite Landing Zone aufsetzen und einen kleinen, wertvollen Service End‑to‑End migrieren.
• Verhandeln Sie Egress‑Guthaben und flexible Commitments, sobald Sie 10–25 % des Traffics ohne SLO‑Schmerzen bewegen können — Exit‑Fähigkeit ist Hebel.
• Nutzen Sie einen Nearshore‑Pod, um Klebstoff und Plattform‑Plumbing zu refaktorieren, während Ihr Kernteam das Produkt ausliefert.