Atualizado em
Cloud Repatriation: Guia Estratégico Completo para Avaliar, Planejar e Executar a Repatriação de Workloads
Entenda quando migrar de volta para infraestrutura privada faz sentido econômico, técnico e estratégico — e como fazer isso sem comprometer a operação.
Resumo Executivo
Sumário
- O que é Cloud Repatriation
- Por que empresas estão repatriando workloads
- Os custos invisíveis da cloud pública
- Quando Cloud Repatriation faz sentido — e quando não faz
- Classificação de workloads: elegíveis e não elegíveis
- Como calcular o TCO e o ROI da repatriação
- Adentro Cloud Repatriation Index (ACRI)
- Riscos da repatriação e como mitigá-los
- Cloud Repatriation vs. Arquitetura Híbrida
- Erros comuns e como evitá-los
- Comparativo: Cloud Pública × Cloud Privada
- Checklist de Avaliação de Cloud Repatriation
- Exemplos práticos por segmento
- FAQ — Perguntas Frequentes
- Glossário
- Conclusão e próximos passos
O que é Cloud Repatriation
Cloud Repatriation é o processo de mover workloads, aplicações ou dados de ambientes de cloud pública — como AWS, Microsoft Azure ou Google Cloud — de volta para infraestrutura privada, seja ela própria, em colocation ou em cloud privada gerenciada.
O termo ganhou força a partir de 2022, quando grandes empresas começaram a tornar públicos os números de suas contas de cloud pública e a questionar se a premissa “cloud é sempre mais barata e mais eficiente” se sustentava para todos os tipos de carga.
É importante separar Cloud Repatriation de dois conceitos próximos:
- Repatriação é uma decisão estratégica de workload placement baseada em análise econômica, técnica e regulatória.
- Não é anti-cloud. Empresas que repatriam não abandonam a cloud pública — elas redistribuem cargas para onde cada ambiente oferece a melhor relação custo-benefício.
- Não é um retrocesso. É a evolução natural da estratégia cloud-first para cloud-smart.
O contexto histórico: de cloud-first a cloud-smart
Entre 2015 e 2021, o movimento predominante foi o de adoção acelerada de cloud pública. O argumento era convincente: sem CapEx, elasticidade ilimitada, velocidade de provisionamento e acesso a serviços gerenciados avançados.
Esse raciocínio está correto para muitos cenários. O problema surgiu quando a estratégia de “migrar tudo” foi aplicada indiscriminadamente a workloads que não foram projetados para se beneficiar dessas características — bancos de dados grandes e estáveis, processamentos batch de alto volume, arquivos, ERPs, sistemas de gestão internos.
Para esses workloads, o modelo de pagamento por uso da cloud pública transforma o que parecia uma vantagem — sem custo fixo — em um custo recorrente crescente e difícil de controlar.
Cloud Repatriation não é uma tendência de nicho. A Andreessen Horowitz, referência em tecnologia, publicou em 2021 o estudo “The Cost of Cloud, a Trillion Dollar Paradox”, mostrando que, para empresas de software em escala, os custos de cloud pública podem representar entre 50% e 80% do custo dos produtos vendidos (COGS). Para organizações que cresceram na cloud pública sem revisão periódica de TCO, a repatriação parcial pode representar uma das maiores oportunidades de redução de custo disponíveis.
Por que empresas estão repatriando workloads
A repatriação não é impulsionada por uma única razão. Na prática, organizações que tomam essa decisão identificam múltiplos fatores que, juntos, tornam a mudança economicamente e estrategicamente justificada.
1. Custo: a motivação mais frequente
Para workloads previsíveis e de uso contínuo — aqueles que rodam 24 horas por dia, 7 dias por semana, com consumo de recursos relativamente estável — a cloud pública cobra uma taxa de conveniência permanente. Instâncias reservadas e Savings Plans reduzem esse custo, mas não eliminam o diferencial em relação à infraestrutura própria depreciada.
Em 2022, a 37signals (criadora do Basecamp e do HEY) tornou pública sua decisão de migrar para infraestrutura própria, saindo da AWS. Segundo David Heinemeier Hansson (DHH), cofundador da empresa, a estimativa era de que o custo anual de cloud seria de aproximadamente US$ 3,2 milhões. Com servidores próprios, a empresa projetou uma economia de vários milhões de dólares ao longo de cinco anos. Workloads previsíveis em escala raramente se beneficiam do modelo de precificação por hora da cloud pública.
2. Conformidade, privacidade e LGPD
A Lei Geral de Proteção de Dados Pessoais (LGPD) e as exigências de auditabilidade de setores regulados — financeiro, saúde, educação, governo — colocam questões que a cloud pública nem sempre resolve de forma simples:
- Onde exatamente os dados estão armazenados?
- Quem tem acesso físico e lógico à infraestrutura?
- Como é garantida a exclusão definitiva de dados pessoais?
- Como é auditada a cadeia de custódia de dados sensíveis?
Para organizações que processam grandes volumes de dados pessoais ou sensíveis, a infraestrutura privada certificada com ISO 27001 e ISO 27701 oferece um nível de controle, auditabilidade e evidência documental que pode ser difícil de replicar com a mesma profundidade em ambientes de cloud pública compartilhada.
A ISO 27701 define o framework para um Sistema de Gestão de Privacidade da Informação (PIMS). Quando avaliando onde hospedar dados pessoais, verificar se o provedor de infraestrutura privada possui essa certificação é uma forma de obter evidência objetiva de que o ambiente possui controles de privacidade auditados por terceiros — não apenas declarações de boas intenções.
3. Performance e latência
Aplicações que dependem de latência ultra-baixa entre componentes — como sistemas de tempo real, bancos de dados com alto volume de transações e aplicações de processamento de imagem ou vídeo — frequentemente apresentam performance mais consistente em infraestrutura dedicada.
Na cloud pública, o desempenho pode variar em função do “barulho de vizinhança” (noisy neighbor effect), onde outros inquilinos da mesma infraestrutura física afetam a performance do seu ambiente.
4. Controle e segurança
Em infraestrutura privada, a organização tem controle completo sobre a pilha: hardware, hypervisor, rede, storage e software. Isso facilita a implementação de políticas de segurança específicas, a auditoria de logs completos e a resposta a incidentes sem depender de APIs ou painéis de terceiros.
5. Vendor lock-in e dependência tecnológica
Quanto mais tempo um workload permanece em cloud pública e consome serviços gerenciados nativos do provedor, maior é o custo e a complexidade de migração futura. Isso não é necessariamente um problema — serviços gerenciados têm valor real — mas é um fator de risco estratégico que organizações maduras consideram em seus planos de continuidade.
Os custos invisíveis da cloud pública
A fatura de cloud pública raramente representa o custo total. Existem categorias de custo que frequentemente não são contabilizadas no TCO inicial e que se tornam relevantes ao longo do tempo.
Egress fees: o custo de tirar dados da cloud
Os principais provedores de cloud pública cobram para que dados saiam de seus ambientes — seja para a internet, para outro provedor ou para infraestrutura local. Esse custo é muitas vezes subestimado ou ignorado no planejamento inicial.
Para organizações que processam e movimentam grandes volumes de dados — bancos de dados analíticos, ambientes de backup, sistemas de arquivos — as taxas de egress podem representar uma parcela significativa da fatura mensal.
Egress fees são frequentemente listados em casas decimais de centavos por GB, o que parece insignificante. No entanto, aplicações que movimentam dezenas ou centenas de terabytes por mês transformam esse “centavo por GB” em custos de dezenas de milhares de reais mensais. A Comissão Europeia iniciou investigações sobre as práticas de egress dos grandes provedores, reconhecendo que esses custos funcionam como uma barreira artificial à portabilidade.
Recursos órfãos e provisioned capacity não utilizada
A FinOps Foundation estima que, em média, 30% a 35% dos recursos de cloud pública são subutilizados ou completamente inativos. Instâncias EC2 esquecidas, volumes de disco não anexados, snapshots acumulados e bancos de dados de desenvolvimento que nunca foram desativados geram custo contínuo sem gerar valor.
Licenciamento por uso em escala
Bancos de dados gerenciados, ferramentas de observabilidade, APIs e serviços de segurança na cloud pública cobram por unidade de uso. Em escala, esses custos se somam de forma não linear e frequentemente superam o custo equivalente de licenças perpetuas ou subscriptions de software rodando em infraestrutura própria.
Custo de engenharia de cloud management
Gerenciar um ambiente de cloud pública com disciplina — revisão de custos, otimização de instâncias, gestão de reservas, tagging, políticas de governança — demanda tempo e especialização. O custo do time dedicado a essa função raramente entra no TCO comparativo, mas é real.
| Categoria de custo | Frequência com que aparece no TCO inicial | Impacto típico |
|---|---|---|
| Instâncias / VMs | Sempre | Alto — custo mais visível |
| Storage (objetos, blocos, arquivos) | Geralmente | Médio a alto em ambientes maduros |
| Egress fees | Raramente | Alto para cargas intensivas em dados |
| Serviços gerenciados (DB, cache, filas) | Parcialmente | Alto em ambientes com microserviços |
| Recursos órfãos | Nunca | Médio — 20-35% do total típico |
| Suporte premium | Raramente | Médio — pode ser $15k–$100k+/ano |
| Engenharia de cloud management | Nunca | Alto — 0.5 a 2 FTEs dedicados |
Quando Cloud Repatriation faz sentido — e quando não faz
Cloud Repatriation não é a decisão certa para todas as organizações ou para todos os workloads. A resposta depende de uma análise objetiva de fatores econômicos, técnicos, regulatórios e operacionais.
Indicadores que favorecem a repatriação
- TCO da cloud pública maior que o da infraestrutura privada em horizonte de 3 anos, após incluir todos os custos (egress, serviços, operação, suporte).
- Workloads com utilização contínua e previsível — que rodam 24×7 com consumo de recursos estável.
- Alto volume de dados que precisam ser movimentados regularmente entre o ambiente e sistemas externos, gerando egress fees elevadas.
- Exigências regulatórias que demandam controle total sobre localização, acesso e auditoria dos dados (LGPD, BACEN, ANS, ANVISA).
- SLAs mais rigorosos do que os que a cloud pública pode garantir contratualmente.
- Equipe interna com capacidade operacional para gerenciar infraestrutura privada ou parceiro confiável para operação gerenciada.
- Preocupações com soberania digital e dependência de provedores estrangeiros.
Quando Cloud Repatriation provavelmente não vale
- Workloads com demanda altamente variável ou imprevisível — onde a elasticidade da cloud pública tem valor real e mensurável.
- Aplicações globalmente distribuídas que precisam de presença em múltiplas regiões do mundo.
- Ambientes de desenvolvimento e testes com ciclos curtos e recursos temporários.
- Times sem capacidade ou interesse em operar infraestrutura (e sem parceiro para fazê-lo).
- Forte acoplamento com serviços nativos do provedor de cloud (ex.: Lambda, DynamoDB, BigQuery) — onde a migração exigiria reescrita significativa.
- Organizações em fase de crescimento acelerado sem clareza sobre escala futura — o CapEx de infraestrutura pode ser prematuro.
Cloud Repatriation raramente deve ser uma decisão de “tudo ou nada”. A abordagem mais eficaz é a análise workload por workload: identificar quais cargas têm perfil de uso contínuo, alta intensidade de dados e requisitos de conformidade — e avaliar cada uma individualmente com base em TCO comparativo de 3 a 5 anos.
Classificação de workloads: elegíveis e não elegíveis
| Workload | Elegível para repatriação? | Principal razão |
|---|---|---|
| Banco de dados relacional (OLTP) estável | Sim | Alto custo de instâncias RDS/SQL MI; uso previsível 24×7 |
| Data warehouse / analytics interno | Sim | Alto volume de dados; egress elevado; cargas previsíveis |
| Sistema ERP | Sim | Uso previsível; dados sensíveis; SLA controlado internamente |
| Backup e arquivamento de dados | Sim | Custo de storage e egress acumulado; dados críticos |
| Servidores de arquivos internos | Sim | Uso constante; alto volume; dados corporativos sensíveis |
| Ambientes de monitoramento / SIEM | Sim | Alta ingestão de logs; custo de ingestão cresce com o ambiente |
| Aplicação web com tráfego estável | Depende | Avaliar elasticidade; se previsível, repatriar é viável |
| Aplicação com picos sazonais intensos | Não | Elasticidade da cloud pública tem valor real aqui |
| Funções serverless (Lambda, Cloud Functions) | Não | Sem infraestrutura equivalente simples em privado |
| CDN e entrega de conteúdo global | Não | Presença global que infraestrutura privada não replica |
| Ambiente de ML/AI (treino de modelos) | Depende | Repatriar para GPU dedicada se uso for frequente e previsível |
| Containers com orquestração (K8s) | Depende | Viável em privado se equipe tem competência em Kubernetes |
| Ambiente de desenvolvimento efêmero | Não | Flexibilidade e temporalidade favorecem cloud pública |
| SaaS e integrações nativas de cloud | Não | Dependência de APIs nativas; migração exigiria reescrita |
Como calcular o TCO e o ROI da repatriação
A decisão de repatriar deve ser fundamentada em uma análise de TCO (Total Cost of Ownership) honesta, que inclua todos os custos relevantes de ambos os lados — não apenas o custo de compute na fatura do provedor de cloud.
Custos a considerar no lado da cloud pública (atual)
- Instâncias compute (on-demand, reservadas ou Savings Plans)
- Storage (block storage, object storage, file storage)
- Banco de dados gerenciado (RDS, SQL Managed Instance, Cloud SQL)
- Transferência de dados — especialmente egress e inter-region
- Serviços de rede (Load Balancers, NAT Gateway, VPN)
- Serviços de segurança (WAF, DDoS protection, KMS, Secrets Manager)
- Observabilidade (CloudWatch, Azure Monitor, logging)
- Suporte premium
- Licenças de software adicional (ex.: Windows Server BYOL)
- Custo de equipe de FinOps / cloud management
Custos a considerar no lado da infraestrutura privada
- Hardware (servidores, storage, rede) — CapEx ou leasing
- Colocation ou data center próprio (energia, espaço, refrigeração)
- Licenças de hypervisor e software de virtualização (VMware, Hyper-V, KVM)
- Licenças de backup e replicação (Veeam, etc.)
- Firewall e segurança de borda (Fortinet, etc.)
- Conectividade (links dedicados, redundância)
- Equipe de operação (própria ou gerenciada)
- Custo de migração (planejamento, execução, testes)
- Custo de manutenção e renovação de hardware (ciclo de 5 anos)
A equação do TCO comparativo
Para que a comparação seja válida, o TCO deve ser calculado sobre o mesmo horizonte de tempo — recomendamos 36 meses como mínimo e 60 meses como cenário estratégico.
Comparar o custo de cloud pública (que inclui operação completa) com o custo de hardware privado (excluindo operação, conectividade, licenças e migração) é um dos erros mais comuns e produz análises enganosas. O TCO comparativo deve incluir todos os custos relevantes de ambos os lados, incluindo o custo do time.
Período de retorno (Payback Period)
Em projetos de repatriação bem planejados, o payback médio ocorre entre 12 e 24 meses, dependendo do volume de workloads migrados e da escala do ambiente. Projetos com payback superior a 36 meses devem ser revistos — geralmente indicam workloads com perfil de uso variável ou subestimação de custos operacionais da infraestrutura privada.
Calculadora de TCO Cloud Repatriation
Compare o custo total do seu ambiente atual de cloud pública com o de infraestrutura privada gerenciada pela Adentro. Inclui compute, storage, rede, operação e migração.
Adentro Cloud Repatriation Index (ACRI)
O Adentro Cloud Repatriation Index (ACRI) é um framework proprietário de avaliação que ajuda organizações a quantificar o potencial de benefício da repatriação de cada workload em sete dimensões. O ACRI não substitui a análise de TCO, mas complementa com fatores qualitativos e estratégicos que a análise financeira isolada não captura.
Custo Comparativo
Diferença entre TCO cloud pública e TCO privado em 36 meses. Quanto maior a diferença, maior o score nesta dimensão.
Previsibilidade de Demanda
Variação do consumo de recursos ao longo do tempo. Workloads estáveis pontuam alto; workloads com picos intensos pontuam baixo.
Conformidade e Soberania
Exigências regulatórias, de localização de dados e de auditoria. Quanto mais rígidas, maior o potencial de benefício da infraestrutura privada certificada.
Intensidade de Dados
Volume de dados processados e movimentados. Avalia impacto de egress fees e custo de storage.
Risco de Lock-in
Grau de dependência de serviços nativos do provedor de cloud. Menor dependência facilita e viabiliza a repatriação.
Capacidade Operacional
Competência interna ou disponibilidade de parceiro para operar a infraestrutura privada com o nível de SLA exigido.
Continuidade e Resiliência
Capacidade de garantir RPO e RTO equivalentes ou superiores em infraestrutura privada, considerando backup, DR e redundância.
Como interpretar o ACRI
| Score ACRI | Interpretação | Ação recomendada |
|---|---|---|
| 70–100 | Alta aderência à repatriação | Avançar para planejamento detalhado de migração |
| 40–69 | Aderência moderada | Aprofundar análise de TCO e avaliar workload individualmente |
| 20–39 | Aderência baixa | Considerar otimização FinOps na cloud pública antes de repatriar |
| 0–19 | Não recomendado | Manter na cloud pública e revisar em 12 meses |
O ACRI é uma ferramenta de triagem, não de decisão final. Scores altos indicam potencial de repatriação, mas não substituem a análise financeira detalhada, o planejamento técnico e a avaliação de capacidade operacional. Workloads com score ACRI alto mas custo de migração proibitivo podem não ser candidatos práticos a repatriação no curto prazo.
Riscos da repatriação e como mitigá-los
Subdimensionamento de capacidade
Risco: Migrar para hardware subdimensionado pode resultar em degradação de performance piora do que o ambiente de cloud pública.
Mitigação: Monitorar a utilização real do ambiente de cloud pública por pelo menos 90 dias antes de definir o dimensionamento da infraestrutura privada. Adicionar 20-30% de headroom sobre o pico observado.
Déficit de competência operacional
Risco: Equipes acostumadas a usar console web e CLI de cloud pública podem não ter experiência em gerenciar hypervisors, storage arrays, switches e firewalls físicos.
Mitigação: Mapear competências antes da migração. Definir modelo de operação: equipe interna, operação gerenciada por terceiro ou modelo híbrido.
Interrupção durante a migração
Risco: Migração mal planejada pode causar janelas de indisponibilidade não previstas.
Mitigação: Planejar migração em fases, com ambiente paralelo e período de validação antes do cutover definitivo. Documentar plano de rollback para cada workload.
Regressão de observabilidade
Risco: Perda de visibilidade operacional ao migrar de ferramentas nativas de cloud (CloudWatch, Azure Monitor) para ambientes privados sem solução de monitoramento equivalente.
Mitigação: Definir e implantar solução de monitoramento e observabilidade antes de iniciar a migração. Ferramentas como Prometheus, Grafana e Zabbix oferecem capacidades equivalentes.
Cloud Repatriation vs. Arquitetura Híbrida
Na prática, a maioria das organizações que executam Cloud Repatriation não abandonam completamente a cloud pública. O resultado mais comum é uma arquitetura híbrida deliberada: workloads previsíveis, regulados e intensivos em dados em infraestrutura privada; workloads elásticos, globais e temporários em cloud pública.
| Critério | Cloud Pública | Cloud Privada |
|---|---|---|
| Workloads elásticos / imprevisíveis | Vantagem | Desvantagem |
| Workloads previsíveis / 24×7 | Desvantagem | Vantagem |
| Presença global | Vantagem | Limitado |
| Controle total sobre a pilha | Limitado | Vantagem |
| TCO para alto volume de dados | Custo alto | Custo baixo |
| Egress fees | Presente | Eliminado ou mínimo |
| Conformidade e auditabilidade | Depende do provedor | Controle total |
| CapEx inicial | Zero | Investimento necessário |
| Velocidade de provisioning | Minutos | Dias a semanas |
| Dependência de fornecedor | Alta | Baixa |
Erros comuns e como evitá-los
1. Repatriar sem análise de TCO completa
Decidir repatriar com base apenas no sentimento de que “a cloud está cara” — sem calcular o custo total de ambos os lados — é o caminho mais rápido para uma decepção. A repatriação tem custos de migração, operação e manutenção que precisam entrar no modelo.
2. Repatriar tudo ou nada
Migrar toda a infraestrutura para privado porque “a cloud é cara demais” sem avaliar cada workload individualmente tende a resultar em um ambiente privado superdimensionado e subutilizado, ou em workloads inadequados sobrecarregando hardware limitado.
3. Ignorar o custo e o risco da migração em si
A migração de workloads críticos exige planejamento, recursos e tempo. Subestimar esse custo — especialmente em ambientes com alta interdependência entre serviços — pode fazer o payback projetado demorar muito mais do que o esperado.
4. Subestimar a operação da infraestrutura privada
Cloud pública inclui operação. Infraestrutura privada exige operação dedicada: atualização de firmware, substituição de hardware com falha, gestão de patches, monitoramento 24×7, gestão de capacidade. Esses custos e responsabilidades precisam ser previstos antes da decisão.
5. Não planejar continuidade e DR para o novo ambiente
Ambiente de cloud pública tem failover automático e replicação geográfica por padrão em muitos serviços. Infraestrutura privada precisa que o plano de continuidade seja projetado explicitamente. RPO e RTO precisam ser definidos e testados antes do go-live.
Checklist de Avaliação de Cloud Repatriation
- FASE 1 — DIAGNÓSTICO E INVENTÁRIO
- Inventariar todos os workloads atualmente em cloud pública (nome, tipo, recursos, custo mensal)
- Medir utilização real de CPU, memória, storage e rede nos últimos 90 dias
- Identificar workloads com uso previsível (variação <30% no período)
- Mapear dependências entre workloads (quais serviços conversam entre si)
- Listar todos os serviços nativos de cloud utilizados (ex.: RDS, SQS, Lambda) e avaliar portabilidade
- FASE 2 — ANÁLISE DE CUSTOS
- Extrair fatura completa dos últimos 12 meses por workload ou tag
- Identificar e quantificar egress fees no período
- Calcular custo de recursos órfãos e subutilizados
- Obter cotação de infraestrutura privada equivalente (hardware, colocation ou cloud privada gerenciada)
- Calcular TCO comparativo de 36 e 60 meses para cada workload candidato
- Estimar custo de migração (planejamento, execução, testes, contingência)
- FASE 3 — AVALIAÇÃO REGULATÓRIA E DE SEGURANÇA
- Identificar workloads que processam dados pessoais (LGPD) ou dados sensíveis
- Verificar exigências regulatórias específicas do setor (BACEN, ANS, ANVISA, etc.)
- Avaliar se o provedor de infraestrutura privada possui ISO 27001 e ISO 27701
- Verificar SLAs disponíveis e compatibilidade com exigências de negócio
- FASE 4 — CAPACIDADE OPERACIONAL
- Avaliar competências da equipe para operar infraestrutura privada
- Definir modelo de operação: próprio, gerenciado ou híbrido
- Garantir solução de monitoramento e observabilidade antes da migração
- FASE 5 — PLANEJAMENTO DE MIGRAÇÃO
- Priorizar workloads para migração (menor interdependência e maior ROI primeiro)
- Definir janelas de migração e planos de rollback para cada workload
- Planejar período de operação paralela (cloud + privado) para validação
- Definir critérios de sucesso e métricas de validação pós-migração
- Documentar e testar plano de Disaster Recovery no novo ambiente
Exemplos práticos por segmento
Os cenários abaixo são exemplos hipotéticos criados para fins didáticos. Não representam clientes ou casos reais da Adentro.
Hospital de médio porte
Contexto: 300 leitos, sistema de prontuário eletrônico (PEP) e sistema de imagens (PACS) em cloud pública. Dados de pacientes (dados pessoais sensíveis pela LGPD). Contrato com plano de saúde exige SLA de 99,9%.
Perfil de uso: Alta previsibilidade. Pico diário entre 7h e 22h. Storage crescendo 20% ao ano em função de imagens radiológicas.
ACRI estimado: Alto (~75). TCO comparativo em 36 meses: infraestrutura privada gerenciada pode representar redução de 40-60% no custo total, especialmente pelo volume crescente de storage e ausência de egress fees para integração com equipamentos de imagem.
Decisão recomendada: Repatriar PEP e PACS para cloud privada certificada ISO 27001 + ISO 27701. Manter ferramentas de comunicação e sistemas SaaS na cloud pública.
Empresa de software (SaaS) com base de clientes estabelecida
Contexto: Produto SaaS com 2.000 empresas clientes no Brasil. Carga de trabalho relativamente previsível durante o horário comercial. Banco de dados PostgreSQL com 8 TB de dados de clientes. Fatura AWS de R$ 120.000/mês.
Análise: Banco de dados e storage representam 65% da fatura. Egress para backups e relatórios equivale a R$ 18.000/mês.
Decisão recomendada: Repatriar camada de dados (banco de dados + storage) para infraestrutura privada. Manter frontend, CDN e funções de notificação em cloud pública. Resultado projetado: redução de 45% na fatura total.
Indústria de médio porte
Contexto: Fabricante com ERP, MES (Manufacturing Execution System) e sistema de BI em cloud pública. Integração com equipamentos de chão de fábrica exige baixa latência. Dado operacional sensível.
Decisão recomendada: ERP e MES em cloud privada próxima à fábrica (colocation regional ou edge). BI e relatórios em cloud pública ou privada, dependendo do volume. Resultado: latência reduzida, melhor integração com SCADA e PLC, SLA definido contratualmente.
FAQ — Perguntas Frequentes sobre Cloud Repatriation
Não. Cloud Repatriation faz sentido para organizações com workloads previsíveis e de alto consumo, que já têm maturidade operacional suficiente para gerenciar infraestrutura privada (própria ou gerenciada), e cujo TCO na cloud pública é consistentemente superior ao da alternativa privada em horizontes de 3 a 5 anos.
Cloud Repatriation não necessariamente implica retorno a data centers próprios com administração manual. A maioria das empresas que repatriam migra para cloud privada gerenciada, colocation ou IaaS de provedor privado — mantendo os benefícios de gerenciamento profissional, SLAs contratuais e modernização de infraestrutura, sem o modelo de precificação por uso da cloud pública.
Depende da complexidade e do número de workloads. Migrações pontuais de sistemas individuais podem ser concluídas em 4 a 8 semanas. Projetos de repatriação de ambientes completos costumam durar de 6 a 18 meses, com migração em fases e períodos de operação paralela.
Sim, com planejamento adequado. A abordagem mais segura é criar o ambiente privado em paralelo, migrar dados e workloads com ferramentas de replicação, validar o novo ambiente por um período de observação e, só então, realizar o cutover definitivo — com plano de rollback documentado.
Não necessariamente. Infraestrutura privada moderna é escalável — é possível adicionar capacidade de compute e storage. A diferença em relação à cloud pública é que o scale-up requer planejamento de ciclo mais longo e, em geral, envolve CapEx. Para workloads com previsão de crescimento acelerado e imprevisível, a cloud pública permanece mais adequada.
A LGPD exige que as organizações saibam onde seus dados estão, quem tem acesso e como são protegidos. Em infraestrutura privada certificada com ISO 27701, é mais simples estabelecer e demonstrar essas garantias ao DPO, a reguladores e a auditores externos. Isso não significa que cloud pública não possa ser usada para dados pessoais — mas o grau de controle e auditabilidade tende a ser maior em ambientes privados.
Os próprios provedores de cloud pública oferecem calculadoras de custo (AWS Pricing Calculator, Azure TCO Calculator), mas são tendenciosas. Para uma análise completa, recomendamos usar essas ferramentas em conjunto com cotações de fornecedores de infraestrutura privada e incluir todos os custos indiretos: operação, conectividade, licenças, migração e ciclo de vida do hardware.
Egress fee é a cobrança pelo tráfego de dados que sai do ambiente de cloud pública — seja para a internet, para outro provedor ou para sistemas locais. Para aplicações com alto volume de transferência de dados, esse custo pode representar 15% a 30% da fatura total. É um dos principais fatores que tornam a repatriação economicamente atrativa para ambientes intensivos em dados.
Não. A operação de infraestrutura privada moderna — especialmente com virtualização, Kubernetes, backup e DR — exige competências específicas. O perfil muda: menos foco em console web do provedor de cloud e mais foco em gestão de infraestrutura, storage e rede. Muitas organizações optam por infraestrutura privada gerenciada para não precisar internalizar todas essas competências.
Sim. Cloud privada gerenciada é infraestrutura dedicada — física ou virtualizada — operada por um provedor, mas com recursos exclusivos do cliente. Não há compartilhamento de hardware com outros clientes (diferente da cloud pública). O modelo de precificação pode ser por subscription fixa ou por capacidade reservada, eliminando a variabilidade de custo da cloud pública.
O plano de Disaster Recovery precisa ser redesenhado para o novo ambiente. Ferramentas como Veeam permitem replicação e backup com RPO e RTO definidos. Ambientes críticos podem ser replicados geograficamente entre dois data centers privados ou usar cloud pública como destino de DR — mantendo a cloud pública apenas como ambiente de contingência, não como ambiente primário.
O custo varia amplamente com o tamanho do ambiente, número de workloads e grau de complexidade das interdependências. Projetos simples (1-3 workloads) podem ser executados por R$ 30.000 a R$ 100.000. Projetos complexos de grandes ambientes podem chegar a R$ 500.000 ou mais. O investimento na migração é geralmente recuperado em 12 a 24 meses de economia operacional.
Vendor lock-in é a dependência crescente de um único fornecedor de tecnologia, que torna a migração futura cara ou tecnicamente difícil. Na cloud pública, o lock-in se aprofunda à medida que workloads consomem serviços nativos do provedor (ex.: Lambda, DynamoDB, BigQuery). Repatriar para infraestrutura baseada em tecnologias abertas (KVM, Kubernetes, PostgreSQL, S3-compatible) reduz essa dependência e aumenta a portabilidade futura.
Não. Mover apenas backups para infraestrutura privada é uma estratégia de otimização de storage, não Cloud Repatriation. A repatriação envolve mover a carga de trabalho em si — o ambiente ativo, as aplicações e os bancos de dados — para fora da cloud pública.
A ISO 27001 é a norma internacional para Sistemas de Gestão de Segurança da Informação (SGSI). Um provedor de infraestrutura privada com certificação ISO 27001 demonstrou, por meio de auditoria independente, que seus processos de segurança atendem a controles específicos documentados. Isso oferece evidência objetiva — não apenas declaração — de maturidade em segurança, o que é relevante especialmente para organizações em setores regulados.
Glossário
Conclusão e próximos passos
Cloud Repatriation não é uma tendência passageira nem um retrocesso tecnológico. É a maturidade natural de uma estratégia de infraestrutura que passou da fase de adoção acelerada para a fase de otimização deliberada.
A pergunta relevante não é “cloud ou não cloud”. É: qual workload pertence a qual ambiente? Workloads elásticos, globais e temporários se beneficiam da cloud pública. Workloads previsíveis, intensivos em dados, regulados e de uso contínuo frequentemente têm TCO melhor em infraestrutura privada bem dimensionada.
Para tomar essa decisão com segurança, é necessário:
- Inventariar e classificar todos os workloads com base em perfil de uso, volume de dados e requisitos de conformidade.
- Calcular o TCO comparativo honesto, incluindo todos os custos indiretos de ambos os lados.
- Avaliar a capacidade operacional interna ou a disponibilidade de um parceiro confiável para operar o novo ambiente.
- Planejar a migração em fases, com operação paralela e critérios de validação claros.
- Projetar o ambiente de continuidade antes de migrar qualquer workload crítico.
Organizações que executam Cloud Repatriation com essa disciplina tendem a chegar a uma arquitetura híbrida mais eficiente, com melhor controle de custos, maior previsibilidade financeira e infraestrutura alinhada aos requisitos reais de cada carga de trabalho.
Avalie o potencial de repatriação do seu ambiente
O Cloud Repatriation Assessment da Adentro analisa seus workloads atuais, calcula o TCO comparativo e identifica as oportunidades de economia — sem compromisso.
Metadados SEO e Publicação
/cloud-repatriation/
Cloud Repatriation: Guia Estratégico Completo (2025)
Entenda o que é Cloud Repatriation, quando migrar workloads de volta para cloud privada faz sentido econômico, como calcular o TCO e quais riscos evitar.
Cloud Repatriation: Quando retornar para cloud privada compensa?
cloud repatriation
repatriation cloud, repatriar workloads, cloud repatriation TCO, custo cloud pública, cloud privada vs cloud pública, quando repatriar cloud
H2 “O que é Cloud Repatriation” + definição direta
Quando Cloud Repatriation vale a pena? / O que é egress fee? / Como calcular TCO de cloud?
Calculadora TCO · Cloud Privada Adentro · Backup como Serviço · ISO 27001 · LGPD e cloud
Article + FAQPage + BreadcrumbList + Organization (publisher)
https://adentro.com.br/cloud-repatriation/
A cada 6 meses — preços de cloud mudam com frequência
Continue lendo neste cluster
- → Egress Fee: o custo escondido que drena o orçamento de cloud
- → Cloud Privada vs. Cloud Pública: comparativo completo por critério
- → TCO Cloud: como calcular o custo total real da cloud pública
- → Workloads elegíveis para repatriação: como classificar seu ambiente
- → FinOps: quando otimizar não é suficiente e é hora de repatriar
- → LGPD e Cloud: onde hospedar dados pessoais com conformidade
- → Cloud Repatriation Assessment: diagnóstico técnico e financeiro
