O que é vendor lock-in em cloud e por que você deve se preocupar antes de contratar

Você assina o contrato de cloud pensando em uptime, latência e preço por hora de VM. Vendor lock-in não aparece em nenhuma dessas linhas. Ele aparece dezoito meses depois, quando você tenta tirar 40 TB de dados de um provedor e descobre que isso custa mais do que a migração inteira deveria.

Esse artigo é para quem constrói e decide arquitetura de infraestrutura: onde o lock-in se esconde tecnicamente (dados, API, IaC, rede) e o que mudou de fato na regulação em 2025 e 2026, incluindo o motivo pelo qual essa regra europeia importa mesmo para quem opera só no Brasil.

O que é vendor lock-in em cloud, na prática

Vendor lock-in em cloud é a situação em que migrar sua operação de um provedor para outro custa tempo e dinheiro desproporcionais ao valor técnico da mudança. Não é dependência declarada em contrato. É dependência construída em silêncio, decisão técnica após decisão técnica, até o ponto em que sair vira um projeto de meses.

A causa raiz quase nunca é intenção maliciosa do provedor. É acoplamento. Você usa o serviço gerenciado de banco de dados de um provedor, a fila de mensageria proprietária de outro módulo, o storage com API específica, e cada peça economiza tempo de desenvolvimento no curto prazo. Multiplicado por dois ou três anos de produto em produção, essas peças formam uma base que só roda ali.

Os quatro pontos onde o lock-in se instala

Dados e formato de armazenamento

Bancos gerenciados, data warehouses e serviços de storage costumam usar formatos proprietários de exportação, índices internos que não replicam em outro provedor, ou APIs de consulta que existem só naquele ecossistema. Exportar os dados é possível quase sempre. Exportá-los de um jeito que outro provedor consiga importar sem reescrever pipeline é outra história.

Um exemplo concreto: um data warehouse gerenciado que usa formato colunar proprietário para otimizar consulta interna exporta os dados em CSV ou Parquet sem problema, mas as otimizações de particionamento, os metadados de schema e as views materializadas ficam para trás. Quem migra recebe os dados brutos e precisa reconstruir toda a camada de performance do zero, no novo provedor. O dado saiu, a engenharia por trás dele não.

APIs e serviços gerenciados exclusivos

Funções serverless, filas de mensageria, serviços de IA embutidos: cada hyperscaler tem sua versão, com contrato de API próprio. Código escrito contra essas APIs não porta. Ele precisa ser reescrito, função por função, o que transforma uma migração de infraestrutura em um projeto de engenharia de produto.

Infraestrutura como código amarrada a um provedor

Terraform, Pulumi e Ansible resolvem parte do problema ao declarar sua infra como código versionável. Mas um módulo Terraform escrito com os providers específicos de um hyperscaler documenta o lock-in, não o evita. Esse código não roda em outro provedor sem reescrita total.

Para mitigar esse risco de plataforma, arquiteturas modernas recorrem à conteinerização (como Kubernetes e Docker) como camada de abstração. Nesse desenho, o IaC fica focado apenas em provisionar a fundação básica (IaaS), enquanto a aplicação e suas dependências rodam isoladas das especificidades do provedor.

Custo de saída via egress

Este é o ponto mais mecânico e menos discutido. Em 2026, as três maiores plataformas de cloud internacionais cobram entre US$ 0,087 e US$ 0,12 por GB de tráfego de saída para internet, dependendo do provedor e da faixa de volume. Uma operação com 10 TB de tráfego de saída por mês paga cerca de 900 dólares só em egress. Isso, antes de qualquer custo de migração. Para uma empresa que precisa tirar dezenas de terabytes de um provedor de uma vez, esse valor sobe rápido. Na prática, vira uma multa por sair.

O detalhe que a maioria dos times descobre tarde: egress não é só o que sai para a internet. Tráfego entre zonas de disponibilidade da mesma região, processamento em NAT Gateway e replicação entre regiões também são cobrados separadamente, e cada um desses itens aparece como linha isolada na fatura, difícil de rastrear até a causa raiz. Uma arquitetura que parecia barata na calculadora de preços vira cara na prática porque ninguém somou o tráfego interno ao tráfego externo antes de assinar o contrato.

Por que isso deixou de ser só um problema teórico em 2025

Até pouco tempo, vendor lock-in era discutido como risco arquitetural abstrato. Isso mudou com uma peça de regulação específica: o Data Act da União Europeia, em vigor desde janeiro de 2024 e aplicável desde 12 de setembro de 2025, que obriga provedores de cloud a tornar os dados de clientes portáveis e remover barreiras contratuais e técnicas de saída.

A regra não é cosmética. A partir de 12 de janeiro de 2027, cobranças de troca de provedor ficam proibidas, egress de saída incluído. Até lá, contratos de cloud podem ser encerrados com dois meses de aviso prévio. Os provedores também precisam documentar suas interfaces e dar suporte ativo à migração, sem impor obstrução comercial ou técnica.

Você não opera na União Europeia. Ainda assim, a regra importa por dois motivos concretos. Primeiro, ela expõe publicamente o quanto egress de saída funcionava como mecanismo de retenção: mover 100 TB de dados de um hyperscaler podia custar vários milhares de euros, antes mesmo de começar o projeto de migração. Segundo, as grandes plataformas internacionais de cloud responderam globalmente, não só na Europa. Hoje oferecem programas de egress zero para clientes que estão de fato saindo da plataforma. As condições são muito mais estreitas do que a manchete sugere: não cobrem tráfego operacional do dia a dia, exigem aprovação prévia via tickets de suporte (não é um desconto automático) e, frequentemente, obrigam o encerramento definitivo da conta e da infraestrutura em uma janela de tempo estrita para validar a isenção.

O ponto prático: se um provedor precisou de uma lei para parar de cobrar para você sair, isso diz alguma coisa sobre o modelo de negócio dele.

O que muda ao rodar fora dos hyperscalers globais

Nada disso depende de regulação europeia para fazer sentido no Brasil. No Locaweb Cloud, o tráfego de saída entre zonas e o balanceamento de carga não têm cobrança adicional, e os valores são cobrados em reais, sem a variação cambial que distorce o planejamento de quem roda a fatura toda em dólar. Você fecha o mês sabendo quanto vai pagar.

A Tray, plataforma de e-commerce do mesmo grupo LWSA, estimou economia de R$ 45 mil por mês ao consolidar sua operação no Locaweb Cloud, e o CTO da empresa atribuiu o ganho à possibilidade de concentrar o time em construir produto em vez de administrar custo de infraestrutura multi-provedor. É o tipo de resultado que vem de rodar no core da internet brasileira, previsibilidade financeira em troca de menos tempo de engenharia gasto gerenciando a própria conta de cloud.

Como avaliar lock-in antes de assinar, não depois

Antes de migrar workload para qualquer provedor, três perguntas técnicas valem mais do que qualquer promessa comercial:

Meus dados saem em formato aberto? Peça o formato de exportação de cada serviço gerenciado que você vai usar. Se a resposta for “formato proprietário, mas exportável”, isso significa retrabalho de engenharia na saída, não portabilidade real.

Meu código de infraestrutura roda em outro provider sem reescrita total? Se seu Terraform depende de recursos exclusivos de um hyperscaler, sua IaC documenta o lock-in, não evita ele. Prefira provisionar com providers e módulos que tenham equivalente direto em pelo menos dois provedores.

Quanto custa tirar meus dados hoje, não daqui a três anos? Faça a conta de egress agora, com o volume atual, e projete para o volume esperado em dois anos. Se o número já incomoda, o momento de revisar arquitetura é antes de crescer, não depois.

Sem respostas claras para essas três perguntas, o preço por hora da VM vira o único critério de escolha, e é exatamente aí que o lock-in se instala sem ninguém perceber.

Onde vendor lock-in aparece na prática: LGPD, custo e arquitetura

Vendor lock-in não é uma preocupação isolada. Ele se conecta com dois outros problemas que quem opera cloud enfrenta com regularidade. O primeiro é regulatório e de soberania de dados: onde seus dados residem afeta tanto conformidade quanto a complexidade de uma eventual migração (veja “LGPD e Cloud Computing: onde seus dados precisam estar”, locaweb.com.br/blog). O segundo é financeiro: fatura de cloud que cresce sem controle é, com frequência, sintoma da mesma causa raiz que gera lock-in, que é falta de visibilidade sobre o que sua arquitetura realmente depende de um único provedor (veja “Por que sua fatura de cloud cresce todo mês sem você mudar nada”, locaweb.com.br/blog).

Do lado da solução técnica, infraestrutura como código bem estruturada é a ferramenta mais direta para tornar seu ambiente auditável e, na medida do possível, portável (veja “Terraform: O que é e por que usar Infraestrutura como Código”, locaweb.com.br/blog). Não elimina lock-in de API sozinha, mas documenta exatamente onde ele existe, o que já é metade do trabalho de mitigação.

FAQ – Perguntas frequentes sobre vendor lock-in em cloud