Por Gabriel Xavier Supervisor de Gestão e Arquitetura de Sistemas | Especialista em Governança de TI e Analytics
Sua arquitetura distribuída entre dois hyperscalers parece estrategicamente sólida, até você somar as taxas de saída de dados. Aqui está a matemática que os decks de vendas evitam mostrar, com cenários reais e a conta exata que corrói orçamentos de TI por dentro.
Quando o time de infraestrutura apresenta ao CFO a proposta de uma estratégia multicloud, o slide mais convincente geralmente traz um diagrama limpo: workloads distribuídos entre AWS e Google Cloud, com setas bidirecionais entre serviços, e a promessa de “zero dependência de fornecedor”. O que esse slide nunca traz é uma planilha com a projeção de custos de transferência de dados entre essas duas nuvens ao longo de 12 meses.
E é justamente nessa omissão que mora o problema mais caro da computação em nuvem contemporânea. Não estamos falando de centavos. Estamos falando de um mecanismo financeiro que, em cenários corporativos reais, adiciona entre 30% e 62% ao custo total da operação multicloud, segundo dados de engenheiros que documentaram suas próprias faturas em produção ao longo de 2024 e 2025.
Este artigo não é para quem está decidindo “se” vai para a nuvem. É para quem já está lá, distribuiu workloads entre AWS e GCP por razões estratégicas legítimas, e agora precisa entender por que a fatura mensal não fecha com o que foi projetado. E mais importante: precisa de um framework de decisão para saber se o custo da “liberdade” justifica o investimento ou se está financiando, sem saber, o lock-in mais sofisticado do mercado.
O custo de mover dados entre nuvens transforma o que deveria ser “liberdade de fornecedor” em uma das estratégias mais caras do mercado. Ingressar dados é gratuito. Retirá-los pode custar de US$ 0,08 a US$ 0,23 por GB, dependendo da rota e do volume. Em 50 TB mensais, isso significa entre US$ 4.000 e US$ 11.500 apenas em taxas de saída.
A anatomia financeira do Egress: o que acontece quando cada byte cruza a fronteira entre AWS e GCP
Para compreender o impacto real do egress em uma arquitetura multicloud, é preciso primeiro desmontar a mecânica de cobrança. Ambos os provedores seguem a mesma lógica assimétrica: receber dados não custa nada; enviar dados para fora da rede cobra por gigabyte. Essa assimetria não é acidental, é um modelo de retenção econômica deliberado.
A AWS cobra US$ 0,09 por GB para os primeiros 10 TB de transferência para a internet a partir de EC2, S3 ou qualquer outro serviço na maioria das regiões dos EUA. Acima de 10 TB, o valor cai para US$ 0,085, e atinge US$ 0,05 por GB apenas a partir de 150 TB mensais. A franquia gratuita é de 100 GB por mês, um volume irrelevante para qualquer workload em produção.
No Google Cloud, com o tier Premium (que é o padrão), a taxa de egress para a internet a partir de us-central1 chega a US$ 0,12 por GB até 1 TB, cai para US$ 0,11 até 10 TB, e atinge US$ 0,08 acima disso. No tier Standard, os valores são mais competitivos: US$ 0,085 até 10 TB, e US$ 0,045 acima de 150 TB, mas com a penalidade de roteamento pela internet pública, o que degrada performance e SLA.
O detalhe que complica: transferência inter-região não é Egress para internet
Quando o dado sai de uma VM no GCP em us-central1 e precisa chegar a uma instância EC2 em us-east-1 da AWS, a cobrança não segue necessariamente a tabela de “internet data transfer out”. Se a rota for via internet pública, sim, aplica-se a tabela cheia. Mas se a empresa utiliza Cross-Cloud Interconnect ou AWS Interconnect – multicloud (lançado em preview em novembro de 2025), a cobrança segue as tabelas de Cloud Interconnect, que, na América do Norte, custam US$ 0,02 por GB.
Parece uma economia brutal, certo? É, mas tem um preço fixo de entrada. O circuito de 10 Gbps do Cross-Cloud Interconnect custa US$ 5,60 por hora. São US$ 4.032 por mês, por circuito. Com redundância (mínimo recomendado), são US$ 8.064 por mês antes de um único byte ser transmitido. Some as VLAN attachments (US$ 0,10/hora cada) e o custo base de infraestrutura para interconnect ultrapassa US$ 8.200 mensais.
Simulação real: quanto custa manter 2 TB/dia trafegando entre AWS e GCP
Saímos das tabelas abstratas e entramos em cenários concretos. Uma empresa de médio porte com pipeline de dados distribuído, ingestão em GCP BigQuery, processamento de ML em AWS SageMaker, e resultados voltando ao GCP para dashboards no Looker, é o tipo de arquitetura que gera tráfego bidirecional constante. Documentações de casos reais publicadas em 2025 mostram que esse perfil de empresa movimenta entre 1,5 TB e 3 TB de dados por dia entre clouds.
Vamos trabalhar com 2 TB/dia como referência, um volume comum para pipelines de analytics de médio porte.
Sessenta mil dólares por ano apenas para mover dados entre dois provedores que, supostamente, estão ali para evitar lock-in. E esse cálculo assume volume estático. Em cenários com crescimento de dados de 15% a 25% ao ano (a média reportada pelo Flexera 2025 State of the Cloud), o custo de egress pode ultrapassar US$ 78 mil no segundo ano.
E se usarmos Cross-Cloud Interconnect?
Aqui entra a alternativa que tanto AWS quanto GCP vendem como solução: conectividade privada dedicada. Lançado como colaboração conjunta entre os dois providers no final de 2025, o AWS Interconnect – multicloud em combinação com o Cross-Cloud Interconnect do GCP promete provisionamento em minutos, redundância quad, e criptografia MACsec. O custo por GB via interconnect na América do Norte cai para US$ 0,02.
A Armadilha do Interconnect para Volumes Médios
Com 60 TB/mês de tráfego bidirecional, o Cross-Cloud Interconnect custa US$ 9.436/mês contra US$ 5.068/mês via internet. O interconnect só se torna financeiramente vantajoso acima de aproximadamente 180 TB/mês de tráfego, quando o diferencial de US$ 0,065/GB por byte começa a superar o custo fixo de US$ 8.208. Abaixo disso, você paga mais caro pela infraestrutura do que economiza em egress.
O ponto de equilíbrio: quando o Interconnect Compensa
Existe um número mágico que todo arquiteto de soluções multicloud deveria calcular antes de aprovar um interconnect dedicado. A fórmula é simples:
Para empresas que trafegam menos de 128 TB mensais entre clouds, o que inclui a grande maioria das operações de médio porte, o Cross-Cloud Interconnect representa um custo adicional, não uma economia. É um investimento que se justifica por performance e segurança, não por redução de custos de egress.
Cenário de uso A: pipeline de analytics com processamento distribuído
Cenário A — Data Pipeline Híbrido
Perfil: Empresa de e-commerce com ingestão de eventos via GCP Pub/Sub + BigQuery, processamento de modelos de recomendação em AWS SageMaker, e dashboards de volta no Looker (GCP).
Volume diário: ~1,5 TB de dados brutos enviados do GCP para AWS; ~200 GB de resultados processados voltando para GCP.
Fluxo: GCP → AWS (1,5 TB/dia) + AWS → GCP (0,2 TB/dia)
Quase setenta mil dólares anuais em taxas de trânsito de dados. Sem que um único byte adicional de armazenamento ou processamento tenha sido provisionado. Esse valor é, em muitas empresas, equivalente ao salário de um engenheiro de dados pleno, gasto exclusivamente para manter a arquitetura “livre” de dependência.
Cenário de uso B: disaster recovery ativo-ativo entre Clouds
Cenário B — DR Ativo-Ativo Multicloud
Perfil: Fintech com requisito regulatório de disaster recovery em provider distinto. Banco de dados primário em AWS RDS, réplica assíncrona em GCP Cloud SQL. Replicação contínua + snapshots incrementais.
Volume diário: ~3 TB de replicação contínua (AWS → GCP) + ~500 GB de sincronização reversa para reconciliação.
Fluxo: AWS → GCP (3 TB/dia) + GCP → AWS (0,5 TB/dia)
O Mito do egress gratuito: o que os anúncios dos hyperscalers realmente dizem
Em 2024, tanto a AWS quanto o Google Cloud fizeram anúncios que foram recebidos com entusiasmo pelos meios especializados: remoção de taxas de egress para clientes que estivessem migrando para fora da nuvem. O título de um artigo no blog da AWS chegou a usar a frase “free data transfer out to internet when moving out of AWS”.
Acontece que os termos e condições contam uma história diferente. A isenção de egress se aplica exclusivamente ao contexto de migração completa para fora do provedor,, ou seja, é ativada como incentivo para que o processo de saída seja menos doloroso caso você tenha sido obrigado a deixar o provedor (por regulação, fusão, etc.). Não se aplica ao tráfego operacional contínuo de uma arquitetura multicloud.
Em outras palavras: se você está enviando dados diariamente entre AWS e GCP como parte do seu fluxo de trabalho normal, cada gigabyte continua sendo cobrado integralmente. O “egress grátis” é uma política de retenção reputacional, não uma redução real de custos para quem opera em multicloud.
A isenção de egress da AWS e do GCP se aplica apenas para migração definitiva de saída do provedor (offboarding). O tráfego operacional entre clouds, replicação, sincronização, APIs, processamento distribuído, continua integralmente cobrado. Nenhum dos dois provedores oferece desconto de egress para tráfego multicloud recorrente sem um contrato de interconnect dedicado.
A cronologia do lock-in financeiro: como a dependência se instala em 18 meses
O lock-in financeiro por egress não acontece de uma vez. Ele se instala de forma gradual, à medida que a arquitetura multicloud amadurece e os volumes de dados crescem organicamente. Quem gerenciou esse tipo de ambiente reconhece o padrão com clareza.
- Meses 1-3: Lua de Mel
Os volumes de transferência são baixos. A equipe testa integrações, move datasets de referência. O egress mal aparece na fatura. O CFO aprova a estratégia. Custo de egress mensal: ~US$ 200-600.
- Meses 4-6: Aceleração
Pipelines de produção começam a rodar. Replicação de bancos de dados entra em operação. Volumes saltam de gigabytes para terabytes. Egress mensal: US$ 1.500-3.000. Ninguém questiona, ainda está “dentro do orçamento”.
- Meses 7-12: Normalização do Custo
O custo de egress se torna uma linha fixa no budget de infra. A equipe de FinOps identifica o problema, mas a arquitetura já está consolidada. Refatorar para reduzir tráfego cross-cloud exigiria meses de engenharia. Egress mensal: US$ 3.000-8.000.
- Meses 13-18: Ponto de Não Retorno
Integrações entre serviços dos dois providers estão profundamente entrelaçadas. O custo de migrar workloads de volta para um único provider é estimado em 4-8 meses de engenharia. O egress agora é estrutural. Custo mensal: US$ 5.000-15.000+. A “liberdade” virou lock-in financeiro.
O relatório Flexera 2025 State of the Cloud revelou que 86% das organizações operam com estratégia multicloud, e que o principal desafio reportado é a gestão de custos. A pesquisa indica que o gasto com nuvem tende a aumentar 28% ano a ano e os custos de transferência de dados compõem uma parcela crescente desse incremento, frequentemente não mapeada nos orçamentos iniciais.
As variáveis que apenas 1% dos times calculam: egress oculto em serviços gerenciados
O cálculo de egress que fizemos até aqui considera transferência direta entre compute instances. Mas em arquiteturas reais, o egress se multiplica em camadas invisíveis dentro dos próprios serviços gerenciados e é aqui que os orçamentos realmente explodem sem explicação aparente.
BigQuery export: o custo que ninguém planeja
Quando você exporta dados do BigQuery para Cloud Storage (para posterior transferência à AWS), o egress inter-região dentro do GCP já custa US$ 0,01 por GB se origem e destino estão na mesma região, e sobe para US$ 0,02-0,08 entre regiões. Esse custo se soma ao egress do Cloud Storage para a internet. Em pipelines que processam centenas de queries por dia, cada export gera uma camada adicional de cobrança que não aparece no cálculo primário.
S3 Cross-region replication: o multiplicador silencioso
Se sua estratégia multicloud inclui replicação do S3 entre regiões da AWS (para aproximar os dados do ponto de saída para GCP), a transferência inter-região dentro da AWS custa US$ 0,02 por GB, nos dois sentidos. Um bucket de 20 TB replicado entre us-east-1 e us-west-2 gera US$ 409,60 mensais apenas em trânsito interno, antes mesmo de o dado sair da AWS.
CloudFront + Cloud CDN: egress cascateado
Empresas que usam CDNs de ambos os providers para servir conteúdo global acabam com um padrão de egress cascateado: o dado sai do storage origin (egress #1), vai para o edge da CDN (egress #2 se cross-region), e é entregue ao usuário final (egress #3 para internet). Cada camada tem sua tabela de preços, e a soma frequentemente surpreende quem olhou apenas o custo de “data transfer out” do serviço primário.
Diagrama: camadas de egress em pipeline multicloud real
Diagrama: camadas de egress. (Imagem: Stormz)
Kubernetes cross-cloud: a armadilha do service mesh
Empresas que operam clusters GKE no Google Cloud e EKS na AWS com comunicação via service mesh (Istio, Linkerd) entre serviços distribuídos nos dois clouds enfrentam um problema adicional. Cada chamada de microserviço que cruza a fronteira entre providers gera egress. Em arquiteturas com dezenas de microserviços fazendo centenas de milhares de chamadas por hora, o volume de dados é baixo por chamada, mas astronômico em agregado. Um trace de 2 KB multiplicado por 500 mil requests por hora totaliza 1 GB por hora, ou 720 GB por mês, apenas em telemetria e payloads de API.
Framework de decisão: quando multicloud se justifica e quando é dinheiro queimado
Após anos trabalhando com arquiteturas distribuídas entre clouds, um padrão claro se forma. A decisão de adotar multicloud não deveria ser tomada com base em slides sobre “evitar vendor lock-in”. Deveria ser tomada com base em uma planilha de custos projetados que inclua, linha por linha, o egress esperado para cada fluxo de dados entre providers.
Multicloud se justifica quando:
Regulação exige provider independente para DR. Fintechs, bancos e empresas de saúde em jurisdições que exigem disaster recovery em provedor distinto do primário não têm escolha. Nesse caso, o custo de egress é um compliance cost, não um custo de arquitetura e deve ser tratado como tal no orçamento.
Workloads são genuinamente especializados por provider. Se o Google Cloud oferece o melhor pipeline de ML com Vertex AI para seu caso de uso e a AWS tem a infraestrutura de compute com instâncias Graviton mais adequada para seu back-end, a distribuição faz sentido funcional. Mas só se os dados entre esses dois mundos fluírem em volumes baixos e previsíveis.
O volume de transferência cross-cloud é inferior a 5 TB/mês. Abaixo desse patamar, o custo de egress é administrável (US$ 400-600/mês) e justificável dentro da margem de otimização de um budget de infra.
Multicloud é dinheiro queimado quando:
A motivação principal é “não ficar preso”. A ironia é que o custo de egress cria um lock-in financeiro mais forte do que o lock-in técnico. Sair de um provider único exige esforço de engenharia. Sair de um setup multicloud exige esforço de engenharia, refatoração de pipelines de dados, migração de workloads, e absorção de custos de egress massivos durante a transição.
Pipelines de dados são o core da operação. Se o coração do seu negócio é mover, transformar e analisar dados de alto volume, distribuir esse pipeline entre dois clouds é essencialmente colocar um pedágio no meio da sua estrada principal. Cada GB que cruza a fronteira custa dinheiro e adiciona latência.
Não há um cálculo documentado de egress projetado. Se o time de arquitetura não consegue responder com precisão “quanto vamos gastar em egress nos próximos 12 meses”, a decisão multicloud foi tomada sem o dado mais importante.
| Critério | Multicloud Justificado | Multicloud Questionável |
|---|---|---|
| Volume cross-cloud mensal | < 5 TB | > 20 TB |
| Motivação primária | Regulação / Especialização | “Evitar lock-in” |
| Dados fluem em qual direção? | Unidirecional, batch | Bidirecional, real-time |
| Custo de egress projetado | < 5% do budget de infra | > 15% do budget |
| Break-even do interconnect | Atingido em < 6 meses | Nunca atingido |
| Ação recomendada | Prosseguir com monitoramento | Reavaliar consolidação |
Alternativas pragmáticas para quem já está preso no egress multicloud
Se você já está operando em multicloud com volumes de egress significativos, refatorar toda a arquitetura raramente é viável a curto prazo. Existem, no entanto, intervenções cirúrgicas que podem reduzir entre 30% e 60% do custo de transferência sem redesenho completo.
Camada de cache cross-cloud com Alluxio ou similar
A Expedia Group documentou como a implantação do Alluxio, uma camada de cache que opera entre compute e storage, reduziu seus custos de egress cross-region no S3 em 50%. Em uma arquitetura multicloud, o Alluxio pode ser posicionado no cloud de destino para cachear datasets frequentemente acessados, eliminando transferências repetitivas do cloud de origem. Se 60% dos seus dados transferidos são leituras repetidas dos mesmos datasets (padrão comum em analytics), o impacto financeiro é direto e mensurável.
Staging em provedores de egress zero
O Cloudflare R2 e o Backblaze B2 oferecem armazenamento de objetos com egress gratuito ou próximo de zero. A empresa Vim documentou a eliminação completa de US$ 50 mil/mês em custos de egress ao migrar assets frequentemente acessados do S3 para o R2. Em uma arquitetura multicloud, o R2 pode funcionar como zona neutra de staging: o dado sai do cloud A para o R2 (pagando egress uma vez), e é lido pelo cloud B sem custo adicional. O R2 mantém compatibilidade com a API do S3, o que reduz o esforço de migração.
Compressão agressiva nos pipelines de transferência
Parece óbvio, mas em auditorias de custos de cloud, a compressão é frequentemente negligenciada nos pipelines de transferência cross-cloud. A aplicação de compressão gzip ou zstd em payloads de API e datasets de transferência pode reduzir o volume efetivo em 60% a 85%, dependendo do tipo de dado. Em 60 TB/mês de tráfego, uma compressão de 70% reduziria o volume cobrado para 18 TB, uma economia de mais de US$ 3.400/mês nos cenários que calculamos.
Redesenho de fluxo: processar onde o dado já está
A intervenção mais eficaz e mais difícil, é o redesenho do fluxo de dados para minimizar o cruzamento entre clouds. Se 80% do seu egress vem de mover dados brutos do GCP para processamento na AWS, a pergunta é: o processamento pode ser feito no GCP? A diferença de custo entre os serviços de ML dos dois providers é quase sempre inferior ao custo de egress para mover os dados. Um modelo treinado no Vertex AI pode custar 10-20% mais do que no SageMaker, mas essa diferença se dissolve quando comparada com US$ 67 mil anuais em egress.
Regra Operacional:
Antes de mover qualquer workload para um segundo cloud, calcule o custo de egress anual projetado e compare com a diferença de custo do serviço equivalente no cloud primário. Em 8 de cada 10 cenários que analisei em produção, manter o workload no mesmo cloud e pagar mais caro pelo serviço sai mais barato do que pagar egress para distribuir entre providers.
O que mudou em 2025-2026 e para onde os custos de egress estão indo
O mercado de cloud está em um momento de transição que merece atenção. Dois movimentos recentes alteram o panorama, embora nenhum resolva o problema fundamental.
AWS Interconnect, multicloud: a resposta conjunta
Lançado em preview em novembro de 2025, o AWS Interconnect, multicloud é o resultado de uma colaboração direta entre AWS e Google Cloud para simplificar a conectividade entre os dois providers. A especificação é aberta (publicada no GitHub), o provisionamento é automatizado, e a redundância quad vem por padrão. Azure é esperado no ecossistema em 2026. O SLA de uptime é de 99,99% no lado AWS.
Esse é um avanço genuíno em usabilidade e confiabilidade. Mas, e aqui está o ponto, não resolve o problema econômico. O custo por GB via interconnect é menor, porém o custo fixo de infraestrutura é elevado. Para a maioria das empresas de médio porte, a economia líquida é nula ou negativa.
Pressão regulatória na Europa e Reino Unido
O regulador britânico (Ofcom/CMA) publicou em 2025 um relatório final sobre o mercado de cloud que aborda diretamente as taxas de egress como barreira à competição e ao multicloud. O relatório europeu do BEREC segue na mesma direção. A tendência é de pressão crescente para redução ou eliminação de taxas de egress por regulação, seguindo o modelo do EU Data Act, que já restringe certas cobranças de switching. Mas a implementação prática dessas regulações está no horizonte de 2027-2028, não no ciclo orçamentário atual.
O paradoxo do preço de egress em 2026
A AWS, na contramão das expectativas, aumentou os custos de transferência cross-region em 25-40% e o egress base de US$ 0,08 para US$ 0,09/GB entre 2024 e 2025. O Google Cloud fez ajustes similares no tier Premium no início de 2024. Ou seja: apesar da retórica de “cloud aberto”, os preços de egress estão subindo, não descendo. A promessa de “liberdade” está ficando mais cara a cada ciclo de precificação.
A conta final: liberdade tem preço, e ele está na fatura de rede
Multicloud não é uma estratégia inerentemente ruim. É uma estratégia inerentemente cara e o custo mais significativo não está nos serviços de compute, storage ou ML que você consume em cada provider. Está no espaço invisível entre eles: a rede.
Os cálculos que apresentamos neste artigo não são teóricos. São baseados nas tabelas de preços publicadas pelos próprios providers, validados contra relatos de custos reais documentados por engenheiros de plataforma em produção, e projetados com as taxas de crescimento de dados reportadas pelo Flexera 2025 State of the Cloud (28% ao ano).
Para uma empresa que trafega 2 TB por dia entre AWS e GCP, o custo de egress via internet pública é de aproximadamente US$ 60 mil por ano. Com Cross-Cloud Interconnect, sobe para US$ 113 mil (por conta da infraestrutura fixa). Em cenários de DR ativo-ativo com volumes maiores, o custo facilmente ultrapassa US$ 114 mil anuais.
A pergunta que todo arquiteto, CTO e CFO deveria fazer antes de aprovar uma estratégia multicloud não é “vamos evitar lock-in?”. A pergunta é: “quanto estamos dispostos a pagar por mês para mover dados entre dois provedores, e esse custo se justifica pelo que ganhamos em troca?”
Na maioria dos casos que passaram pelo crivo de uma análise financeira rigorosa, a resposta é desconfortável: a liberdade de nuvem é uma das estratégias mais caras do mercado. E o lock-in mais eficiente que existe não é técnico. É financeiro. Está na taxa de egress. E ele já está na sua fatura.
