Airbus Walked. Could You? A CTO’s Cloud Exit Playbook for 2026

Airbus stepping away from AWS isn’t about team sports. It’s a signal. If a tier‑one enterprise is willing to rework its stack to regain leverage, you should at least ask a brutal question: if you had to move 25% of your workloads in 12 months, could you do it without blowing up delivery?

Most startups and scale‑ups can’t. Not because the code won’t run elsewhere, but because the glue won’t. Managed services, identity wiring, network assumptions, and data gravity become concrete. This post is a decision framework to get you from nice idea to credible option.

What Airbus’s move actually means for you

When a heavyweight declares independence, cloud providers listen. Pricing softens. Migration credits appear. Roadmaps shift. But you only benefit if you’re technically ready to walk. Leverage comes from exit capability, not tweets.

In 2026, exit capability is less about “lift and shift” and more about “can we operate the same SLOs without proprietary behavior?” That means replacing special‑case features (Step Functions, SQS FIFO semantics, X‑Ray, KMS key policies) with open equivalents you can run anywhere.

The honest inventory: your dependencies are the lock‑in

Forget the marketing deck — run a dependency census. In practice, lock‑in hides in five places:

• Identity and auth: STS/KMS‑bound IAM roles, cloud‑specific service identities, and signed URL flows baked into code.
• Networking: NAT gateways, VPC endpoints, and cross‑AZ billing assumptions. Egress and hairpins can dominate cost and complexity.
• Data plane: DynamoDB GSIs/streams, Redshift and BigQuery SQLisms, S3 eventing, and object storage lifecycle policies.
• Async and workflows: SQS/SNS fan‑out patterns, Step Functions, EventBridge rules, Kinesis partitioning.
• Observability and ops: Cloud‑native traces/metrics/logs (e.g., X‑Ray, CloudWatch Logs) and managed secret stores (SSM, Secrets Manager).

When we audit real stacks, 60–80% of app containers are portable in hours. The other 20–40% are glued to one provider by the bullets above. That is the real migration map.

A four‑box decision framework for your portfolio

Tag every workload into one of these buckets. Be ruthless.

1) Portable today (ship first)

Stateless services in containers with externalized config and OpenTelemetry, talking to Postgres or Redis over TCP. These move in days if you’ve got images, IaC, and secrets abstracted. Use them to prove your landing zone and GitOps.

2) Portable with shims (needs replacements)

Anything using SQS/SNS, CloudWatch/X‑Ray, Secrets Manager, or KMS envelope encryption tied to IAM. You’ll need drop‑in equivalents: NATS/Redpanda, OpenTelemetry collectors, external secrets controllers, and a platform KMS that supports envelope keys with per‑service roles.

3) Anchored by data gravity (move last)

RDS/aurora in the multi‑terabyte range, Redshift/BigQuery warehouses, petabyte‑scale S3 buckets with event glue. Plan dual‑write or CDC replication, schema normalization (ANSI SQL + views), and backfill windows with explicit RPO/RTO.

4) Hard‑anchored PaaS (avoid net‑new)

Step Functions, EventBridge‑heavy automations, Kinesis analytics, proprietary ML endpoints. Freeze new dependencies, pay down the ones you can, and isolate the rest behind internal façades so the blast radius stays small.

Do the math: egress, NAT, and transfer aren’t rounding errors

This isn’t a fear play. It’s arithmetic.

• Internet egress: As a ballpark, data transfer out of a major cloud to the internet often ranges from roughly $0.05–$0.09/GB depending on tier and volume. Move 200 TB in a month and you’re in the $10k–$18k range just for bytes leaving. That is before compute, storage reads, and ops.
• NAT gateway tax: Many teams discover six‑figure annual NAT bills late. At $0.045/GB, 500 TB/month of outbound traffic through NAT is ≈$23k/month. Put private endpoints and egress architecture under a microscope before you mirror traffic to a new cloud.
• Private links: Direct interconnects can cut per‑GB transfer costs materially versus public egress, but you exchange capex/commit for opex savings. Price and plan both paths; don’t assume one is universally better.
• Bulk export: For one‑time large moves from object storage, consider physical export devices or negotiated migration credits. Ask your account team. Exit leverage increases your odds of meaningful concessions.

Model three scenarios: one‑time bulk exit, steady‑state dual‑run (3–6 months), and steady‑state multi‑cloud (indefinite). Each has a different cost curve and operating risk.

Design principles that make exit possible

These aren’t dogma. They’re the minimum viable portability layer.

• Identity: OIDC everywhere. Standardize on OIDC service identities with short‑lived tokens. For in‑cluster identities, adopt SPIFFE/SPIRE so workloads don’t assume IAM/Service Accounts of one cloud. Gate KMS access by OIDC claims, not provider‑specific roles.
• Secrets: externalize with a controller. Use an external secrets operator (Kubernetes) that can read from any backend (cloud KMS, HashiCorp Vault). Your apps get the same mount regardless of where the secret lives.
• Compute: containers first, functions later. If it doesn’t need bursty millisecond scale, run it in containers. Where you must keep FaaS, choose a runtime that also runs on Knative or OpenFaaS and hide provider SDKs behind an internal interface.
• Networking: collapse hairpins. Before you mirror traffic, cut NAT and cross‑AZ hairpins using VPC endpoints, private service connect, dual‑stack IPv6, and internal load balancers. Portability dies under bandwidth bills.
• Data: choose open formats and portable engines. Prefer Postgres over proprietary NoSQL unless you truly need Dynamo‑class scale. For analytics, standardize on Parquet + Apache Iceberg or similar open table formats so engines (Spark, Trino, Dremio, DuckDB) are interchangeable.
• Async: standardize on a portable bus. SQS is fine until it isn’t. For complex topologies, standardize on Kafka/Redpanda or NATS JetStream and treat cloud queues as edge adapters.
• Observability: OpenTelemetry or bust. Emit OTel traces/metrics/logs. Route through collectors you control. If you depend on X‑Ray or Cloud Monitoring features, keep them as sinks, not sources.

A two‑lane migration plan that preserves delivery

You don’t have to choose between feature work and portability. Run two lanes in parallel with strict blast‑radius limits.

Lane A: Stop digging

• Freeze net‑new proprietary features. Put an exception process in place. If someone wants Step Functions, they bring a portability story or you ship an internal wrapper.
• Standardize the platform contract. Define golden paths: container buildpacks, service identities, secrets, OTel, health probes, SLOs. Make it easier to comply than to deviate.
• Refactor the glue, not the app. Replace SDK calls to cloud services with internal interfaces. Move signing, pagination, retries, and idempotency into shared libraries you own.

Lane B: Build the alternate landing zone

• Pick a credible target. Another hyperscaler, a regional player, or a colo Kubernetes cluster — choose one and get real. Don’t aim for abstract multi‑cloud; aim for a second home you can operate.
• Stand up a minimal platform. Kubernetes with GitOps, SPIRE, external‑secrets, OTel collectors, S3‑compatible object storage (native or MinIO), Postgres, and your message bus. Fewer moving parts win.
• Mirror traffic for a small, high‑value service. Pick a portable service with clear SLOs. Run it side‑by‑side. Prove your deploy, rollback, observability, and incident paths in the new land.
• Wire data responsibly. Use CDC (e.g., Debezium) to mirror Postgres. For object storage, replicate buckets with checksums. For analytics, write new tables into Iceberg and backfill incrementally.

Set an explicit objective: within 90 days, 10% of production RPS should be able to run exclusively on the new landing zone with the same SLOs. If that sounds impossible, your platform contract is too loose.

Patterns for the sticky bits

DynamoDB‑heavy apps

Three options:

• Keep and isolate: If you’re married to Dynamo semantics (GSIs, streams, conditional writes), isolate the dependency behind a service and keep the data “at home” while compute moves. Accept latency and egress costs.
• Schema and access makeover: Move hot paths to Postgres JSONB with well‑chosen indexes or to a Cassandra/Scylla cluster. Use CDC to keep systems in sync until you cut over.
• Façade first: Introduce an internal repository layer that matches only the subset of Dynamo features you use. Replace the implementation later.

Step Functions and EventBridge

Replace with Temporal or Cadence if you rely on long‑running workflows. It’s not free: you’ll absorb operational complexity, but you’ll own your orchestration and run it anywhere.

S3 events and signed URLs

Standardize on S3 API semantics as your internal contract. For other clouds, terminate to the same API through a gateway (native S3‑compat or a proxy) so your apps don’t learn new dialects. Re‑implement event triggers with your portable bus.

ML endpoints and proprietary accelerators

Do not call vendor SDKs directly from product code. Front every external model endpoint with a broker you control, with per‑model feature flags and fallbacks. Containerize your inference where possible and keep weights in open formats. If you must use a proprietary accelerator, quarantine it behind a clear interface and measure the replacement cost quarterly.

Negotiation: exit leverage is worth real money

You can — and should — negotiate:

• Egress credits for migration. Ask for credits explicitly tied to exit or dual‑run windows. You’d be surprised how much appears when you have a functioning alternative.
• Bring‑your‑own key terms. If KMS key custody is a sticking point, negotiate BYOK/BYOKMS improvements or portability clauses so rotating away later doesn’t brick you.
• Committed use flexibility. Push for convertibility across services and regions. The ability to reallocate commits lubricates a staged exit.

Exit‑readiness also makes renewal discussions rational. You’re not bluffing when you can move 10–25% of load without re‑architecture.

Risk and SLOs: what to measure so you don’t burn the house down

Cloud exits fail when leaders under‑specify risk. Make these explicit:

• RPO/RTO by service tier. Tag services by criticality and set concrete targets (e.g., Tier 1: RPO ≤ 1 minute, RTO ≤ 15 minutes). Your replication and failover designs should prove it.
• Cost guardrails. Cap dual‑run cost by stage (e.g., +15% platform spend for 90 days). If you exceed it, pause and optimize egress/NAT instead of sprinting blind.
• Operational parity. Incident response, on‑call, dashboards, log retention, and security controls must exist in the new landing zone before you send customer traffic.
• Compliance gaiting. Run a targeted security review on IAM, secrets handling, logging, and data residency. Exits often change your compliance story; don’t let auditors be your first feedback loop.

Where a nearshore pod actually helps

This is shovel work à la carte, not a moonshot. A small nearshore pod (Brazil gives you 6–8 hours of overlap with US time zones) can chew through portability chores while your core team ships product:

• Refactor cloud SDK usage behind internal interfaces and shared libraries.
• Stand up GitOps, SPIRE, external‑secrets, and OTel collectors with IaC.
• Swap managed queues/workflows for Kafka/NATS/Temporal and harden with chaos tests.
• Normalize analytics to Parquet + Iceberg and backfill with verifiable checksums.
• Instrument migration runs with cost telemetry (per‑GB, per‑request) so finance sees progress in dollars, not adjectives.

Done right, you get options without dragging your feature roadmap through mud.

12 months, three milestones

• 0–90 days: Freeze net‑new proprietary features. Build the alternate landing zone. Migrate 1–2 stateless services end‑to‑end. Stand up CDC for a non‑critical Postgres instance. Implement cost and SLO guardrails.
• 90–180 days: Replace observability and secrets paths. Move a real, revenue‑touching service (low to mid tier) and run it for 30 days at ≥25% RPS. Start de‑Dynamo‑izing one hot path or isolate it behind a façade.
• 180–365 days: Land your first data‑gravity move (a warehouse or a large object bucket) with measurable RPO/RTO. Achieve the ability to run 25% of production traffic entirely off your primary cloud for at least a week without SLO regression.

The anti‑patterns that kill exits

• Rewriting everything. You’re not doing a greenfield. Wrap and strangle. Replace the glue, not the app.
• Abstracting to death. Thin, owned interfaces beat universal adapters you don’t understand.
• Skipping observability parity. If you can’t see it, you can’t run it. Do OTel before cutover, not after.
• Assuming egress is trivial. Bytes cost money and time. Model it. Test it. Negotiate it.

Lock‑in isn’t just clouds — watch your formats

This week also brought a reminder that proprietary formats are the quietest lock‑in lever. Make the same call inside your stack:

• Data: Parquet + Iceberg over vendor‑specific table layers. Treat the table format as a first‑class contract.
• APIs: Prefer gRPC/HTTP contracts you own over sprinkling vendor SDK calls through product code.
• Config: Keep IaC in Terraform/OpenTofu/Crossplane rather than proprietary templates. Generate, don’t click.

Once your formats are yours, clouds compete on price, latency, and services. That is leverage.

The punch line

You don’t have to leave your cloud. You have to be able to. Airbus’s move is the latest proof that exit capability is a strategic asset. Build it in deliberate layers — identity, secrets, observability, data formats, async — and prove it with a second landing zone that carries real traffic. When finance asks “why now,” show them the cost curves and the negotiation chips you earn by being credibly multi‑home.

Key Takeaways

• Tag every workload into four buckets: portable now, portable with shims, anchored by data, and hard‑anchored PaaS. Plan migrations in that order.
• Egress, NAT, and dual‑run costs are material. Model one‑time, dual‑run, and multi‑cloud scenarios before you touch traffic.
• Standardize identity (OIDC/SPIRE), secrets (external controllers), observability (OpenTelemetry), and data formats (Parquet + Iceberg) to unlock portability.
• Run a two‑lane plan: freeze new proprietary features while you stand up a second landing zone and migrate a small, high‑value service end‑to‑end.
• Negotiate egress credits and flexible commits once you can move 10–25% of traffic without SLO pain — exit capability is leverage.
• Use a nearshore pod to refactor glue and platform plumbing while your core team ships product.