A Airbus saiu. E você? Um playbook de saída da nuvem para CTOs em 2026

A Airbus se afastando da AWS não é torcida organizada. É um sinal. Se uma empresa de primeira linha está disposta a retrabalhar seu stack para recuperar alavancagem, você deveria ao menos fazer uma pergunta brutal: se você tivesse que mover 25% das suas workloads em 12 meses, conseguiria fazer isso sem explodir a entrega?

A maioria das startups e scale-ups não consegue. Não porque o código não roda em outro lugar, mas porque a cola não roda. Serviços gerenciados, fiação de identidade, suposições de rede e gravidade dos dados viram concreto. Este post é um framework de decisão para sair de ideia bonita para opção crível.

O que a decisão da Airbus realmente significa para você

Quando um peso-pesado declara independência, os provedores de nuvem escutam. Preços amolecem. Créditos de migração aparecem. Roadmaps mudam. Mas você só se beneficia se estiver tecnicamente pronto para sair andando. A alavancagem vem da capacidade de saída, não de tweets.

Em 2026, capacidade de saída é menos sobre “lift and shift” e mais sobre “conseguimos operar com os mesmos SLOs sem comportamento proprietário?”. Isso significa substituir recursos de caso especial (Step Functions, semântica de SQS FIFO, X‑Ray, políticas de chave do KMS) por equivalentes abertos que possam rodar em qualquer lugar.

O inventário honesto: suas dependências são o lock‑in

Esqueça o deck de marketing — faça um censo de dependências. Na prática, o lock‑in se esconde em cinco lugares:

• Identidade e autenticação: papéis IAM presos a STS/KMS, identidades de serviço específicas da nuvem e fluxos de URL assinada embutidos no código.
• Rede: NAT gateways, endpoints de VPC e suposições de cobrança entre AZs. Egress e hairpins podem dominar custo e complexidade.
• Plano de dados: GSIs/streams de DynamoDB, SQLismos de Redshift e BigQuery, eventing de S3 e políticas de ciclo de vida de storage de objetos.
• Assíncrono e orquestrações: padrões de fan‑out com SQS/SNS, Step Functions, regras de EventBridge, particionamento do Kinesis.
• Observabilidade e operações: traces/métricas/logs nativos da nuvem (por exemplo, X‑Ray, CloudWatch Logs) e cofres de segredo gerenciados (SSM, Secrets Manager).

Quando auditamos stacks reais, 60–80% dos contêineres de app são portáveis em horas. Os outros 20–40% estão colados a um provedor pelos bullets acima. Esse é o mapa real de migração.

Um framework de decisão em quatro caixas para o seu portfólio

Classifique cada workload em um destes buckets. Seja implacável.

1) Portável hoje (entregue primeiro)

Serviços stateless em contêineres com configuração externalizada e OpenTelemetry, falando com Postgres ou Redis via TCP. Esses se movem em dias se você tem imagens, IaC e segredos abstraídos. Use‑os para provar sua landing zone e GitOps.

2) Portável com shims (precisa de substituições)

Qualquer coisa usando SQS/SNS, CloudWatch/X‑Ray, Secrets Manager ou criptografia envelope do KMS atrelada ao IAM. Você vai precisar de equivalentes drop‑in: NATS/Redpanda, coletores OpenTelemetry, controladores de segredos externos e um KMS de plataforma que suporte chaves envelope com papéis por serviço.

3) Ancorado por gravidade de dados (mova por último)

RDS/aurora na faixa de multi‑terabytes, warehouses Redshift/BigQuery, buckets S3 em petabytes com cola de eventos. Planeje dual‑write ou replicação via CDC, normalização de esquema (ANSI SQL + views) e janelas de backfill com RPO/RTO explícitos.

4) PaaS fortemente ancoradas (evite criar novas)

Step Functions, automações pesadas em EventBridge, Kinesis analytics, endpoints de ML proprietários. Congele novas dependências, pague a dívida das que der e isole o resto atrás de fachadas internas para manter pequeno o raio de explosão.

Faça as contas: egress, NAT e transferência não são detalhe

Isto não é medo. É aritmética.

• Egress para a internet: Como ordem de grandeza, transferência de dados para fora de uma nuvem grande para a internet costuma ficar na faixa de aproximadamente US$0,05–US$0,09/GB dependendo do tier e volume. Movendo 200 TB em um mês você está na faixa de US$10k–US$18k só pelos bytes saindo. Isso é antes de compute, leituras de storage e operações.
• Imposto de NAT gateway: Muitas equipes descobrem faturas anuais de NAT de seis dígitos tarde demais. A US$0,045/GB, 500 TB/mês de tráfego de saída passando por NAT dá ≈US$23k/mês. Coloque endpoints privados e a arquitetura de egress sob microscópio antes de espelhar tráfego para uma nova nuvem.
• Links privados: Interconexões dedicadas podem reduzir materialmente o custo por GB versus egress público, mas você troca capex/commit por economias de opex. Precifique e planeje ambos os caminhos; não assuma que um é universalmente melhor.
• Exportação em massa: Para movimentos únicos e grandes a partir de storage de objetos, considere dispositivos físicos de exportação ou créditos de migração negociados. Peça ao seu time de conta. Alavancagem de saída aumenta suas chances de concessões significativas.

Modele três cenários: saída em massa única, dual‑run em steady‑state (3–6 meses) e multi‑cloud em steady‑state (indefinido). Cada um tem uma curva de custo e risco operacional diferente.

Princípios de design que viabilizam a saída

Não é dogma. É o mínimo viável de portabilidade.

• Identidade: OIDC em todo lugar. Padronize identidades de serviço OIDC com tokens de curta duração. Para identidades dentro do cluster, adote SPIFFE/SPIRE para que workloads não assumam IAM/Service Accounts de uma nuvem específica. Controle acesso ao KMS por claims OIDC, não por papéis específicos de provedor.
• Segredos: externalize com um controlador. Use um operador de segredos externo (Kubernetes) que possa ler de qualquer backend (KMS da nuvem, HashiCorp Vault). Seus apps recebem o mesmo mount independentemente de onde o segredo mora.
• Compute: containers primeiro, functions depois. Se não precisa de escala burst de milissegundos, rode em contêineres. Onde for inevitável manter FaaS, escolha um runtime que também rode em Knative ou OpenFaaS e esconda SDKs de provedor atrás de uma interface interna.
• Rede: elimine hairpins. Antes de espelhar tráfego, corte hairpins de NAT e entre AZs usando VPC endpoints, private service connect, IPv6 dual‑stack e load balancers internos. Portabilidade morre sob faturas de banda.
• Dados: escolha formatos abertos e engines portáveis. Prefira Postgres a NoSQL proprietário a menos que você realmente precise de escala classe Dynamo. Para analytics, padronize em Parquet + Apache Iceberg ou formatos de tabela abertos similares, de modo que engines (Spark, Trino, Dremio, DuckDB) sejam intercambiáveis.
• Assíncrono: padronize um barramento portável. SQS é ótimo até deixar de ser. Para topologias complexas, padronize em Kafka/Redpanda ou NATS JetStream e trate filas da nuvem como adaptadores de borda.
• Observabilidade: OpenTelemetry ou nada. Emita traces/métricas/logs OTel. Faça o roteamento por coletores que você controla. Se você depende de recursos do X‑Ray ou Cloud Monitoring, mantenha-os como sinks, não como sources.

Um plano de migração em duas pistas que preserva a entrega

Você não precisa escolher entre features e portabilidade. Rode duas pistas em paralelo com limites rígidos de raio de explosão.

Pista A: Pare de cavar

• Congele recursos proprietários novos. Estabeleça um processo de exceção. Se alguém quiser Step Functions, traga uma história de portabilidade ou você entrega um wrapper interno.
• Padronize o contrato da plataforma. Defina caminhos dourados: buildpacks de contêiner, identidades de serviço, segredos, OTel, health probes, SLOs. Torne mais fácil seguir o padrão do que desviar.
• Refatore a cola, não o app. Substitua chamadas de SDK da nuvem por interfaces internas. Traga assinatura, paginação, retries e idempotência para bibliotecas compartilhadas que você controla.

Pista B: Construa a landing zone alternativa

• Escolha um alvo crível. Outro hyperscaler, um player regional ou um cluster Kubernetes em colo — escolha um e torne‑se realista. Não mire no multi‑cloud abstrato; mire em um segundo lar que você consiga operar.
• Levante uma plataforma mínima. Kubernetes com GitOps, SPIRE, external‑secrets, coletores OTel, storage de objetos compatível com S3 (nativo ou MinIO), Postgres e seu barramento de mensagens. Menos peças vencem.
• Espelhe tráfego para um serviço pequeno e de alto valor. Escolha um serviço portável com SLOs claros. Rode lado a lado. Prove seus caminhos de deploy, rollback, observabilidade e incidentes na nova casa.
• Ligue os dados com responsabilidade. Use CDC (por exemplo, Debezium) para espelhar Postgres. Para storage de objetos, replique buckets com checksums. Para analytics, escreva novas tabelas em Iceberg e faça backfill incremental.

Defina um objetivo explícito: em 90 dias, 10% do RPS de produção deve poder rodar exclusivamente na nova landing zone com os mesmos SLOs. Se isso soar impossível, seu contrato de plataforma está frouxo demais.

Padrões para as partes pegajosas

Apps fortemente dependentes de DynamoDB

Três opções:

• Manter e isolar: Se você está casado com as semânticas do Dynamo (GSIs, streams, writes condicionais), isole a dependência atrás de um serviço e mantenha os dados “em casa” enquanto o compute se move. Aceite latência e custos de egress.
• Reforma de esquema e acesso: Mova hot paths para Postgres JSONB com índices bem escolhidos ou para um cluster Cassandra/Scylla. Use CDC para manter sistemas em sincronia até o corte.
• Fachada primeiro: Introduza uma camada de repositório interna que reflita apenas o subconjunto de recursos do Dynamo que você usa. Substitua a implementação depois.

Step Functions e EventBridge

Substitua por Temporal ou Cadence se você depende de workflows de longa duração. Não é de graça: você absorve complexidade operacional, mas passa a possuir sua orquestração e pode rodá‑la em qualquer lugar.

Eventos do S3 e URLs assinadas

Padronize as semânticas da API do S3 como seu contrato interno. Em outras nuvens, termine na mesma API por meio de um gateway (compatível nativamente com S3 ou um proxy) para que seus apps não aprendam novos dialetos. Reimplemente gatilhos de evento com seu barramento portável.

Endpoints de ML e aceleradores proprietários

Não chame SDKs de fornecedor diretamente do código de produto. Coloque todo endpoint de modelo externo atrás de um broker que você controla, com feature flags por modelo e fallbacks. Containerize sua inferência onde possível e mantenha weights em formatos abertos. Se você precisar usar um acelerador proprietário, coloque‑o em quarentena atrás de uma interface clara e meça trimestralmente o custo de substituição.

Negociação: a alavancagem de saída vale dinheiro de verdade

Você pode — e deve — negociar:

• Créditos de egress para migração. Peça créditos explicitamente atrelados à saída ou a janelas de dual‑run. Você se surpreende com o quanto aparece quando tem uma alternativa funcionando.
• Termos de bring‑your‑own key. Se a custódia de chaves no KMS for um ponto duro, negocie melhorias de BYOK/BYOKMS ou cláusulas de portabilidade para que girar para fora depois não te bloqueie.
• Flexibilidade de compromissos. Pressione por conversibilidade entre serviços e regiões. A capacidade de realocar commits lubrifica uma saída em estágios.

Estar pronto para sair também torna as discussões de renovação racionais. Você não está blefando quando consegue mover 10–25% da carga sem rearquitetura.

Risco e SLOs: o que medir para não incendiar a casa

Saídas de nuvem falham quando líderes subespecificam risco. Torne explícito:

• RPO/RTO por tier de serviço. Classifique serviços por criticidade e defina metas concretas (por exemplo, Tier 1: RPO ≤ 1 minuto, RTO ≤ 15 minutos). Suas arquiteturas de replicação e failover devem provar isso.
• Guardrails de custo. Limite o custo de dual‑run por estágio (por exemplo, +15% de gasto de plataforma por 90 dias). Se exceder, pause e otimize egress/NAT em vez de correr às cegas.
• Paridade operacional. Resposta a incidentes, on‑call, dashboards, retenção de logs e controles de segurança devem existir na nova landing zone antes de enviar tráfego de clientes.
• Gates de compliance. Faça uma revisão de segurança focada em IAM, tratamento de segredos, logging e residência de dados. Saídas muitas vezes mudam sua história de conformidade; não deixe auditores serem seu primeiro feedback.

Onde um pod nearshore realmente ajuda

Isto é trabalho braçal à la carte, não um moonshot. Um pod nearshore pequeno (Brazil te dá 6–8 horas de sobreposição com os fusos dos EUA) pode mastigar tarefas de portabilidade enquanto seu time core entrega produto:

• Refatorar o uso de SDKs de nuvem atrás de interfaces internas e bibliotecas compartilhadas.
• Levantar GitOps, SPIRE, external‑secrets e coletores OTel com IaC.
• Trocar filas/workflows gerenciados por Kafka/NATS/Temporal e endurecer com testes de caos.
• Normalizar analytics para Parquet + Iceberg e fazer backfill com checksums verificáveis.
• Instrumentar execuções de migração com telemetria de custo (por GB, por requisição) para que o financeiro veja progresso em dólares, não em adjetivos.

Feito direito, você ganha opções sem arrastar seu roadmap de features na lama.

12 meses, três marcos

• 0–90 dias: Congele recursos proprietários novos. Construa a landing zone alternativa. Migre 1–2 serviços stateless de ponta a ponta. Levante CDC para uma instância de Postgres não crítica. Implemente guardrails de custo e SLO.
• 90–180 dias: Substitua caminhos de observabilidade e segredos. Mova um serviço real que toca receita (tier baixo a médio) e rode por 30 dias com ≥25% do RPS. Comece a “des‑Dynamo‑izar” um hot path ou isole‑o atrás de uma fachada.
• 180–365 dias: Pouse seu primeiro movimento de gravidade de dados (um warehouse ou um bucket grande de objetos) com RPO/RTO mensuráveis. Alcance a capacidade de rodar 25% do tráfego de produção inteiramente fora de sua nuvem primária por pelo menos uma semana sem regressão de SLO.

Os antipadrões que matam saídas

• Reescrever tudo. Você não está fazendo greenfield. Encapsule e estrangule. Substitua a cola, não o app.
• Abstrair até a morte. Interfaces finas e próprias vencem adaptadores universais que você não entende.
• Pular a paridade de observabilidade. Se você não vê, você não opera. Faça OTel antes do cutover, não depois.
• Assumir que egress é trivial. Bytes custam dinheiro e tempo. Modele. Teste. Negocie.

Lock‑in não é só nuvem — fique de olho nos formatos

Esta semana também trouxe um lembrete de que formatos proprietários são a alavanca de lock‑in mais silenciosa. Tome a mesma decisão dentro do seu stack:

• Dados: Parquet + Iceberg em vez de camadas de tabela específicas de fornecedor. Trate o formato de tabela como um contrato de primeira classe.
• APIs: Prefira contratos gRPC/HTTP que você possui em vez de salpicar chamadas de SDK de fornecedor pelo código de produto.
• Config: Mantenha IaC em Terraform/OpenTofu/Crossplane em vez de templates proprietários. Gere, não clique.

Quando os formatos são seus, as nuvens competem em preço, latência e serviços. Isso é alavancagem.

A moral da história

Você não precisa sair da sua nuvem. Você precisa ser capaz de sair. A decisão da Airbus é a mais recente prova de que capacidade de saída é um ativo estratégico. Construa isso em camadas deliberadas — identidade, segredos, observabilidade, formatos de dados, assíncrono — e prove com uma segunda landing zone que carrega tráfego real. Quando o financeiro perguntar “por que agora”, mostre as curvas de custo e as fichas de negociação que você ganha por ser credivelmente multi‑home.

Pontos‑chave

• Classifique cada workload em quatro buckets: portável agora, portável com shims, ancorado por dados e PaaS fortemente ancoradas. Planeje migrações nessa ordem.
• Egress, NAT e custos de dual‑run são materiais. Modele cenários de saída única, dual‑run e multi‑cloud antes de tocar no tráfego.
• Padronize identidade (OIDC/SPIRE), segredos (controladores externos), observabilidade (OpenTelemetry) e formatos de dados (Parquet + Iceberg) para destravar portabilidade.
• Rode um plano de duas pistas: congele novos recursos proprietários enquanto levanta uma segunda landing zone e migra um serviço pequeno e de alto valor de ponta a ponta.
• Negocie créditos de egress e commits flexíveis quando você puder mover 10–25% do tráfego sem dor de SLO — capacidade de saída é alavancagem.
• Use um pod nearshore para refatorar a cola e a tubulação da plataforma enquanto seu time core entrega produto.