Resumo

  • Os grandes provedores passaram a oferecer direitos mais amplos de saída, migração parcial e operação multicloud, mas esses direitos não formam uma tabela mundial uniforme. AWS, Azure e Google aplicam combinações distintas de país da conta ou faturamento, região de origem, serviço elegível, rota de rede, finalidade da transferência, identidade do destino e cumprimento de procedimentos.

  • O movimento regulatório britânico tornou essa fragmentação mais visível. Em março de 2026, a CMA registrou medidas de AWS e Microsoft que ampliam janelas de migração para 180 dias, permitem saída de serviços individuais, reduzem custos de multicloud contínuo e reforçam direitos contratuais e interconexão. As regras existem; ainda não há evidência suficiente para concluir quanto alteraram adoção, churn, economia ou pressão competitiva.

  • A distinção decisiva é entre três operações diferentes: saída total do provedor, saída parcial de um serviço e uso permanente de duas ou mais nuvens em paralelo. Uma política pode tornar a primeira gratuita e continuar cobrando pela terceira. O Data Act europeu elimina cobranças de switching a partir de 12 de janeiro de 2027, mas não transforma todo tráfego multicloud em transferência mundial gratuita.

A mesma transferência, três contratos

Considere uma empresa que precisa mover um grande conjunto de dados de uma nuvem para outra. Tecnicamente, a operação pode parecer trivial: ler objetos, enviá-los por uma conexão IP e gravá-los no destino. Comercialmente, ela já não é uma única operação.

Se a conta estiver enquadrada no programa global de saída da AWS, há um processo de suporte e uma janela de 90 dias para concluir a mudança. Se a mesma organização tiver uma conta elegível pelo adendo britânico, a definição de switching é mais ampla: o Account Country precisa ser o Reino Unido, o pedido deve chegar com antecedência mínima de dois meses e o período de transição é de 180 dias. A saída pode abranger toda a conta ou apenas serviços elegíveis.

No Azure, a diferença aparece de outra forma. O programa geral concede crédito para egress pela internet durante uma janela de 60 dias e, para a saída global, exige ao final o cancelamento das assinaturas associadas. Para clientes com endereço de faturamento no Reino Unido retirando dados de datacenters britânicos, a janela chega a 180 dias, a saída pode ocorrer por serviço e o benefício alcança também determinadas transferências pela Microsoft Premium Global Network.

O Google organiza o problema como sequência processual: aviso de saída, período para iniciar a migração, período de migração e comunicação de conclusão. O benefício acompanha a saída do serviço relevante, não simplesmente qualquer transferência para fora.

Nada disso significa que um código postal, isoladamente, determine o preço. “Endereço de cobrança” é uma forma de descrever uma geografia contratual. O que importa é a combinação de entidade contratante, território, localização do workload, serviço, rota e finalidade.

Egress não explica sozinho o lock-in

A investigação britânica de 2025 é útil justamente porque não sustenta uma narrativa simples na qual a cobrança de egress seria sempre a maior barreira à troca de nuvem.

A CMA encontrou barreiras técnicas e comerciais relevantes à mudança de provedor e ao multicloud, mas a evidência dos clientes sobre egress foi heterogênea. Para várias empresas, essas taxas não apareciam como preocupação principal. Para outras, especialmente quando a arquitetura exige sincronização frequente ou movimentação de grandes volumes entre repositórios, elas passam a alterar a economia da solução.

Isso importa porque uma redução de egress não torna automaticamente uma aplicação portátil. Diferenciação entre serviços, dependência de PaaS e serverless, modelos de dados, APIs, ferramentas operacionais, identidade, segurança, refatoração e capacidade interna de engenharia continuam determinando o custo real de mudança. Acordos de gasto comprometido acrescentam outra camada: mesmo que transferir dados fique barato, pode continuar economicamente difícil reduzir consumo de um fornecedor antes de usar o valor contratado.

A leitura correta, portanto, não é que egress deixou de importar nem que sempre dominou o problema. É que o peso da tarifa depende do workload. Para um backup ocasional, pode ser marginal. Para bancos de dados continuamente sincronizados entre provedores, pode ser estrutural.

Sair, reduzir ou continuar em duas nuvens

A expressão “portabilidade” costuma esconder três decisões econômicas diferentes.

A primeira é a saída total. O cliente transfere workloads e dados e deixa de consumir o fornecedor de origem. É o caso mais próximo da ideia convencional de switching.

A segunda é a saída parcial ou por serviço. Uma empresa pode querer abandonar um banco de dados, uma camada de armazenamento ou outro serviço específico, preservando o restante da conta. Essa modalidade é especialmente importante porque a nuvem é comprada como portfólio. Uma empresa raramente decide, em um único dia, substituir centenas de componentes de uma plataforma.

A terceira é o multicloud paralelo contínuo. Aqui não existe necessariamente intenção de sair. O cliente mantém serviços ativos em duas nuvens e movimenta dados entre elas para que uma aplicação, pipeline ou sistema funcione.

Misturar essas três situações produz conclusões erradas. Uma política de saída gratuita pode melhorar bastante a ameaça de migração sem reduzir o custo de uma arquitetura que transfere petabytes todos os meses entre dois provedores. Uma tarifa multicloud a custo pode melhorar essa segunda economia sem tornar portátil um serviço gerenciado profundamente proprietário.

É por isso que a nova geografia contratual precisa ser lida por finalidade.

AWS: três camadas de portabilidade

Na AWS, a primeira camada é o programa global de transferência gratuita na saída. O cliente aciona o suporte e recebe créditos para transferência de dados durante o processo de migração. Desde a atualização de 2025, a janela padrão é de 90 dias. A regra global não exige, por si só, que toda a conta seja encerrada como condição equivalente à encontrada em algumas outras ofertas.

A segunda camada é britânica. O AWS UK Customer Switching and Portability Addendum vincula os benefícios a uma conta elegível cujo Account Country seja o Reino Unido. O cliente deve apresentar o pedido pelo menos dois meses antes do início planejado. O período de transição é de 180 dias, com mecanismos para uma mudança completa ou para a troca de serviços elegíveis.

O mesmo adendo trata de uso paralelo. Quando AWS e um provedor de destino são utilizados conjuntamente, a transferência para uso interno do mesmo cliente pode receber preço reduzido, limitado ao custo da AWS. A fronteira é importante: o benefício não cobre tráfego destinado a usuários finais, clientes ou outros terceiros.

A terceira camada é física e econômica: AWS Interconnect – multicloud. Nesse produto, a AWS não cobra por gigabyte transferido. Cobra pela conexão, de acordo com largura de banda, região e faixa definida pela distância entre a origem do tráfego e a região local do interconnect. Existe uma conexão gratuita de 500 Mbps por provedor de nuvem e por região. O outro provedor, entretanto, continua livre para cobrar pelo seu lado.

“Sem tarifa por GB”, portanto, não significa conexão sem custo. Significa apenas que o preço foi deslocado de uma unidade variável de tráfego para capacidade e topologia.

Azure: endereço, datacenter e caminho de rede

O Azure deixa ainda mais explícito como localização contratual e caminho de rede podem se combinar.

Na política geral de saída, o cliente abre um pedido de suporte, informa a assinatura, a data planejada e uma estimativa do volume. A janela padrão de crédito é de 60 dias. Para a saída global, as assinaturas associadas precisam ser canceladas depois da transferência. Serviços especializados de rede — incluindo ExpressRoute, ExpressRoute Direct, VPN, Azure Front Door e CDN — ficam fora da oferta padrão de crédito.

Para endereço de faturamento britânico e dados que saem de datacenters do Reino Unido, a regra é diferente. A janela chega a 180 dias, pode haver saída de apenas alguns serviços e a Microsoft inclui a MGN entre os caminhos elegíveis.

O regime de multicloud contínuo acrescenta outras condições. Clientes e parceiros na Europa podem pedir transferência a custo quando Azure e outro provedor são usados em paralelo. A elegibilidade está ligada a faturamento no Espaço Econômico Europeu, EFTA ou Reino Unido, além de critérios de localização. O chamado deve incluir Subscription ID, ASN do endpoint externo e estimativa da parcela de dados transferida.

A propriedade econômica do destino também conta: o processamento precisa ocorrer para a mesma organização. Entrega por CDN e tráfego entre clientes diferentes ficam fora.

E a rota altera o resultado. Para grande parte da Europa, o regime a custo privilegia o caminho de internet via rede de trânsito do ISP quando o serviço o suporta. O uso da MGN não recebe automaticamente o mesmo tratamento; a exceção britânica é mais ampla para transferências originadas de datacenters do Reino Unido.

A arquitetura de rede, nesse desenho, deixa de ser apenas decisão de latência e resiliência. Torna-se variável de faturamento.

Google: a saída é um processo

O Google separa de maneira particularmente nítida saída e multicloud contínuo.

O Exit Cloud exige que o cliente registre um aviso antes da migração. Depois há uma fase para iniciar a transferência, um período de migração e uma comunicação de conclusão. A transferência gratuita cobre produtos elegíveis e está ligada à intenção de encerrar o uso do serviço do qual os workloads e dados estão sendo removidos.

Isso permite uma saída por serviço sem exigir que toda a relação comercial com o Google Cloud desapareça. Mas não permite usar o programa de saída para retirar apenas uma parcela dos dados de um serviço enquanto o consumo daquele mesmo serviço continua normalmente.

Para esse segundo problema, clientes europeus podem recorrer ao Data Transfer Essentials. A oferta foi desenhada para tráfego entre serviços da mesma organização distribuídos por diferentes provedores. Inicialmente não há cobrança, mas a elegibilidade está estreitamente definida.

O tráfego precisa usar serviços, camadas e regiões suportados, conexão por IP externo e destinos configurados com ASNs reconhecidos. Não é uma tarifa promocional genérica para qualquer pacote que deixe o Google Cloud.

O produto também incorpora controles operacionais. Um prefixo ou endpoint que deixe de cumprir os critérios pode ser considerado inválido; o tráfego correspondente volta a ser cobrado pelas tarifas normais de internet. Aplicações que atendem terceiros não entram no desenho, e o próprio Data Transfer Essentials não oferece SLA.

Há ainda uma separação de estados: um serviço já inscrito no programa de saída gratuita não pode simultaneamente ser enquadrado no Data Transfer Essentials. A distinção entre “estou saindo” e “continuarei usando as duas nuvens” não é semântica. É uma variável de cobrança.

O Reino Unido transformou promessas em direitos mais específicos

O documento publicado pela CMA em 31 de março de 2026 mostra como esse mercado começou a sair da fase de declarações gerais para regras mais concretas.

AWS e Microsoft ofereceram janelas de pelo menos 180 dias para switching de clientes britânicos, ampliaram a possibilidade de trocar serviços individuais e apresentaram mecanismos para reduzir o custo do multicloud contínuo. Também houve movimentos em direitos contratuais e interconexão.

Isso é material porque uma facilidade comercial anunciada em uma página de preços não tem exatamente o mesmo valor de opção que uma obrigação contratual que o cliente pode incorporar a uma decisão de longo prazo.

Mas o documento da CMA também preserva uma distinção essencial entre existência do remédio e efeito do remédio. A autoridade pediu passos adicionais, diálogo contínuo e uma revisão do progresso em seis meses. Em 22 de agosto de 2026, é possível observar novas regras e novos produtos. Ainda não é possível afirmar, com a mesma segurança, que eles produziram uma determinada taxa de migração, redução de custo, aumento de multicloud ou redistribuição de participação de mercado.

O mercado precisa de evidência de uso, não apenas de elegibilidade.

O Data Act não cria multicloud gratuito

A União Europeia adiciona um piso legal a essa transformação.

O Data Act passou a ser aplicável em 12 de setembro de 2025. Seu artigo 25 exige que direitos do cliente e obrigações do fornecedor relacionados à troca de serviços sejam apresentados com clareza contratual. O artigo 29 estabelece a retirada gradual das switching charges: até 12 de janeiro de 2027, as cobranças reduzidas não podem exceder os custos diretamente ligados ao processo; a partir dessa data, não devem existir switching charges para o processo de mudança.

Isso não significa tarifa zero para toda movimentação de dados.

O artigo 34 trata das obrigações técnicas de interoperabilidade, e o regime permite que custos associados ao uso simultâneo de serviços sejam tratados de maneira diferente da saída. A própria evolução comercial dos hiperescaladores reflete essa diferença: switching pode caminhar para gratuidade enquanto multicloud paralelo aparece como transferência a custo, conexão por capacidade ou produto específico de rede.

A consequência econômica é mais interessante do que uma simples proibição de egress. O preço deixa de depender apenas do volume e passa a depender da classificação da atividade: sair, operar em paralelo, servir terceiros ou simplesmente transferir dados pela rota padrão.

Portabilidade como limite ao poder do serviço

Uma forma útil de testar essas regras é perguntar se o direito de portabilidade pode ser efetivamente exercido. Um direito só limita poder quando é operacionalmente utilizável. O ponto relevante para a nuvem é estreito: portabilidade precisa funcionar como opção econômica concreta, não apenas como possibilidade nominal prevista em contrato.

Portabilidade utilizável reduz a capacidade de um serviço competir pelo medo da saída. Um fornecedor forte deveria conseguir reter o cliente pela qualidade, preço, desempenho e inovação do que oferece, não porque a alternativa de partir é opaca demais para ser calculada.

Da mesma forma, geografia não deveria esconder controle comercial. Se duas contas compram nominalmente o mesmo serviço, mas uma recebe 180 dias, outra 60 ou 90; uma pode usar determinada rota, outra não; uma pode sair por serviço e outra precisa cumprir uma condição mais ampla, essa diferença deve estar exposta antes da contratação.

Condições comuns, nesse sentido, precisam ser finas, explícitas e verificáveis. Quanto mais exceções ficam enterradas em combinações de país, ASN, produto, destino e procedimento, menor é o valor prático de uma promessa genérica de portabilidade.

O novo trabalho começa antes da migração

A mudança mais profunda pode ocorrer muito antes de qualquer empresa decidir sair de uma nuvem.

Arquitetos agora precisam perguntar onde a entidade de faturamento ficará, não apenas onde os servidores ficarão. Equipes de rede precisam entender se uma rota pela internet, por uma rede premium ou por interconexão dedicada muda a tarifa. Compras precisam separar cláusulas de saída total, saída de serviço e multicloud contínuo. FinOps precisa distinguir preço nominal de egress do preço realmente aplicável ao caso de uso.

Um contrato de gasto comprometido também precisa ser avaliado junto com esses direitos. Portabilidade técnica pode aumentar enquanto portabilidade econômica continua baixa porque o cliente já prometeu consumir determinado valor. O contrário também é possível: uma aplicação simples pode ser barata de mover apesar de uma tarifa de rede relativamente alta.

Isso desloca o debate de “quanto custa egress?” para uma pergunta mais rigorosa: qual direito de movimentação esta arquitetura conserva, para este cliente, a partir desta região, por esta rota e para este destino?

É uma pergunta menos elegante. É também mais próxima do mercado real.

A portabilidade da nuvem não caminha para uma tarifa mundial única de zero. Caminha para um mosaico em que a saída tende a ganhar proteção maior, o uso paralelo recebe tratamentos específicos e a elegibilidade depende cada vez mais de regras que podem ser testadas contra contratos, topologia e identidade do cliente.

A prioridade, portanto, não é esperar por uma nuvem sem preços de rede. É tornar os direitos de saída e de uso paralelo legíveis e comparáveis antes que arquitetura, integrações proprietárias e gasto comprometido se consolidem. É nesse momento — antes do lock-in econômico, não depois — que a portabilidade tem maior valor competitivo.

Fontes