Índice
- O que é repatriação na nuvem?
- Tendências de repatriação da nuvem: por que as empresas estão migrando cargas de trabalho de volta para a nuvem.
- Repatriação total versus parcial: quais cargas de trabalho são boas candidatas?
- Custo da nuvem versus custo local: como comparar o Custo Total de Propriedade (TCO).
- Estratégia de saída da nuvem passo a passo
- Riscos da migração reversa para a nuvem e como minimizá-los
- Exemplos divulgados publicamente: 37signals, Dropbox e GEICO.
- Como a plataforma Hystax oferece suporte à repatriação da nuvem
Principais conclusões
- Cargas de trabalho estáveis tendem a custar menos em infraestrutura própria. Cargas de trabalho com picos repentinos geralmente custam menos na nuvem pública.
- Descontos por dimensionamento adequado e compromisso podem reduzir tanto a diferença entre os custos da nuvem pública e da infraestrutura própria que a migração deixa de ser vantajosa.
- Os provedores de nuvem isentam as taxas de rescisão para clientes que cancelam seus serviços, e a Lei de Proteção de Dados da UE proíbe a cobrança de taxas de mudança a partir de janeiro de 2027.
- Após a repatriação, a nuvem pública pode continuar sendo usada como um site de recuperação de desastres.
A repatriação da nuvem significa mover aplicativos, dados ou máquinas virtuais de uma nuvem pública de volta para a infraestrutura controlada pela empresa. Essa infraestrutura pode ser uma nuvem privada, um data center local ou um serviço de colocation. A maioria dos projetos abrange cargas de trabalho selecionadas; a repatriação completa é rara.
O que é repatriação na nuvem?
Durante anos, a estratégia padrão era "prioridade à nuvem", e muitas equipes migraram o máximo possível. Atualmente, a maioria das empresas opera com uma combinação de ambientes: de acordo com Relatório "Estado da Nuvem 2026" da Flexera, 73% das organizações usam uma nuvem híbrida. Em uma configuração híbrida, a repatriação da nuvem faz parte do posicionamento da carga de trabalho. Os termos abaixo são frequentemente confundidos, então aqui está a diferença entre eles.| Prazo | O que significa | Escopo típico |
|---|---|---|
| Repatriação em nuvem | Migrar cargas de trabalho ou dados da nuvem pública para infraestrutura privada, local ou de colocation. | Um aplicativo, uma camada de dados ou um grupo de máquinas virtuais. |
| Migração reversa para a nuvem | Outro nome para repatriação que enfatiza a direção do movimento. | O mesmo que repatriação |
| Saída da nuvem | Abandonar completamente um provedor de nuvem pública, optando por uma infraestrutura local ou outra nuvem. | Todas as cargas de trabalho e dados |
| Alocação de carga de trabalho | A prática contínua de decidir onde cada carga de trabalho deve ser executada. | O portfólio completo |
Tendências de repatriação da nuvem: por que as empresas estão migrando cargas de trabalho de volta para a nuvem.
Custo de cargas de trabalho estáveis
O modelo de preços "pague conforme o uso" é ideal para demandas variáveis. Uma carga de trabalho que opera no mesmo nível 24 horas por dia, 7 dias por semana, é outra história e, ao longo de alguns anos, pode custar mais na nuvem do que em hardware próprio. O modelo de preços sob demanda permite aumentar ou diminuir a capacidade a qualquer momento, e uma carga de trabalho que nunca escala ainda paga por essa opção sem precisar usá-la.
Taxas de saída
Cargas de trabalho de IA e GPU
Segurança e soberania de dados
Preocupações com violações de dados e conformidade também atrasam algumas cargas de trabalho. Empresas em setores regulamentados, como finanças e saúde, precisam saber onde seus dados estão armazenados e quem pode acessá-los. Para algumas, isso significa migrar sistemas sensíveis para uma nuvem privada. Outras migram para uma nuvem soberana, como a nuvem pública. STACKIT, que armazena dados em centros de dados da UE.
Agende uma demonstração para ver como migrar suas VMs da AWS, Azure ou Google Cloud para uma nuvem privada.
Obrigado pelo seu pedido!
Entraremos em contato em breve.
Repatriação total versus parcial: quais cargas de trabalho são boas candidatas?
A repatriação total é adequada para empresas com demanda estável, uma fatura de nuvem alta que praticamente não varia de mês para mês e sua própria equipe de operações. A maioria das outras opta pela repatriação parcial, migrando as cargas de trabalho onde a infraestrutura própria é claramente mais vantajosa e mantendo o restante na nuvem.
| Bons candidatos para repatriação | É melhor mantê-lo na nuvem pública. |
|---|---|
| Cargas de trabalho de produção com demanda constante 24 horas por dia, 7 dias por semana: pagam preços sob demanda pela capacidade que sempre utilizam. | Cargas de trabalho sazonais: o hardware próprio ficaria ocioso entre os picos de demanda. |
| Bancos de dados grandes e camadas de armazenamento com alta taxa de saída: cada transferência de saída aumenta a fatura. | Ambientes de desenvolvimento e provas de conceito de curta duração: eles terminam antes que o investimento em servidores se pague. |
| Inferência de IA em produção com uso constante de GPUs: as GPUs estão ocupadas o tempo todo. | Experimentos que exigem as GPUs mais recentes por algumas semanas: comprar esse hardware para um teste curto raramente vale a pena. |
| Sistemas com regras rígidas de residência ou auditoria de dados: a infraestrutura própria facilita a comprovação da localização dos dados. | Aplicativos baseados em serviços gerenciados e específicos do provedor: cada serviço teria que ser substituído ou reconstruído. |
| As VMs legadas foram migradas sem alterações: como não utilizam serviços nativos da nuvem, a migração ocorreu sem necessidade de retrabalho. | Serviços globais que exigem várias regiões: para atender a essa demanda, é necessário operar muitos data centers. |
Cargas de trabalho ociosas ou superdimensionadas são um caso à parte. O relatório da Flexera para 2026 estima o desperdício de gastos com nuvem em 291 mil e 3 trilhões de dólares, seu primeiro aumento em cinco anos. Esse desperdício é um gestão de custos problema, e mover as cargas de trabalho para hardware próprio resolve o problema.
Custo da nuvem versus custo local: como comparar o Custo Total de Propriedade (TCO).
Comparar os custos da nuvem com os custos de infraestrutura local é mais difícil do que parece. Na pesquisa da Flexera de 2026, 431 mil entrevistados citaram essa dificuldade como um dos maiores desafios da migração para a nuvem, classificando-a em terceiro lugar. Uma comparação justa utiliza o mesmo horizonte temporal para ambas as situações (normalmente de três a cinco anos) e o mesmo nível de serviço.
Essa fórmula se aplica tanto à nuvem pública quanto à nuvem privada:
Custo Total de Propriedade (TCO) = custos iniciais + custos operacionais mensais × número de meses
Na nuvem pública, quase tudo tem um custo operacional: computação, armazenamento, saída de dados, suporte e serviços gerenciados. Uma nuvem privada concentra grande parte dos gastos iniciais em hardware e no projeto de migração. Ela também adiciona custos operacionais com espaço em data center, licenças, equipe de operações e um site de backup ou recuperação de desastres.
Exemplo prático
Os números abaixo são ilustrativos. O exemplo pressupõe 200 máquinas virtuais (VMs) de produção estável ao longo de três anos.
| Linha de custo | Nuvem pública, 3 anos | Nuvem privada, 3 anos |
|---|---|---|
| Computação e armazenamento | $1.620.000 ($45.000/mês) | $450.000 (hardware) |
| Saída | $108.000 ($3.000/mês) | — |
| Centro de dados, energia e rede | — | $216.000 ($6.000/mês) |
| Suporte, licenças e serviços gerenciados | $180.000 ($5.000/mês) | $180.000 ($5.000/mês) |
| Projeto de migração pontual | — | $80,000 |
| Site de recuperação de desastres e backup (mantido na nuvem pública) | — | $72.000 ($2.000/mês) |
| Total | $1,908,000 | $1,448,000 |
Nesse cenário, a nuvem privada economiza 1.460.000 ao longo de três anos, ou cerca de 241.300.000. Com um investimento inicial de 1.453.000 em hardware e migração, o retorno do investimento ocorre em aproximadamente 19 meses. Os valores da nuvem pública consideram que a infraestrutura de computação e armazenamento inclui backup e redundância em múltiplas zonas.
A otimização da infraestrutura em nuvem muda o cenário. Se os descontos por compromisso e o dimensionamento adequado reduzirem a linha de custos de computação e armazenamento em nuvem em um quarto, a diferença cai para cerca de 1.040.550.000, um valor muito pequeno para justificar uma mudança baseada apenas em custos.
Estratégia de saída da nuvem passo a passo
Mesmo uma migração parcial exige um plano que funcione como uma estratégia de saída da nuvem. Segue a lógica de qualquer projeto de migração, só que ao contrário.
- Avaliar. Liste as cargas de trabalho, dependências, volumes de dados e custos atuais e, em seguida, marque cada um como mover, manter ou retrabalhar.
- Escolha o alvo. Escolha uma plataforma que sua equipe possa usar a longo prazo. Considere as habilidades existentes, os custos de licenciamento e se as VMs precisam ser executadas próximas aos contêineres, como acontece no KubeVirt e no Red Hat OpenShift Virtualization. Muitas equipes optam por uma plataforma que permita a execução de um software de gerenciamento de software. Plataforma baseada em KVM como OpenStack ou OpenNebula. Dimensionar recursos de computação e armazenamento considerando o crescimento futuro.
- Reproduzir. Copie as VMs e os dados em segundo plano e mantenha as cópias sincronizadas até a migração completa.
- Teste. Execute migrações de teste em uma rede isolada para verificar integrações e ordem de inicialização sem afetar a produção.
- Corte por cima. Execute uma sincronização incremental final durante uma janela de manutenção curta e planejada, com um plano de reversão pronto.
- Proteger. Tenha um plano de recuperação de desastres e backup implementado para a nova plataforma antes de desativar os recursos na nuvem.
Riscos da migração reversa para a nuvem e como minimizá-los
Os problemas em um projeto de repatriação geralmente têm origem em custos ou dependências não previstos durante o planejamento. A tabela lista os mais comuns e como minimizá-los.
| Risco | Como reduzir isso |
|---|---|
| Dependências ocultas em serviços de nuvem gerenciados | Mapeie as dependências antecipadamente e planeje substituições para bancos de dados proprietários, filas e serviços de identidade. |
| Custos de hardware e pessoal subestimados | Inclua ciclos de atualização, capacidade ociosa e salários operacionais no modelo de Custo Total de Propriedade (TCO). |
| Tempo de inatividade durante a transição | Replique continuamente e teste as migrações, para que a mudança final seja breve. |
| Perda de resiliência após sair da nuvem multirregional | Configure a recuperação de desastres em um segundo local; uma região de nuvem pública funciona. |
| Custos de saída durante a mudança | Verifique as isenções do provedor e faça um orçamento para o tráfego caso algumas cargas de trabalho permaneçam na nuvem. |
| Lacuna de competências | Treine a equipe antes da transição ou contrate um provedor de serviços gerenciados. |
Exemplos divulgados publicamente: 37signals, Dropbox e GEICO.
Três empresas descreveram suas movimentações com suas próprias palavras. Cada uma transferiu uma parcela diferente de sua carga de trabalho.
37 sinais
Dropbox
GEICO
Como a plataforma Hystax oferece suporte à repatriação da nuvem
A plataforma abrange o lado técnico da repatriação: a própria mudança, a recuperação de desastres e o backup posterior.
O Hystax Migration move VMs da AWS, Azure, Google Cloud e Oracle Cloud para plataformas privadas, soberanas e de virtualização. Com fontes de nuvem pública, um agente de replicação é executado dentro de cada sistema operacional convidado e copia os dados em segundo plano, enquanto a produção continua funcionando. Após a primeira cópia, apenas os blocos alterados trafegam pela rede.
- Os objetivos apoiados incluem Pilha aberta, Serviços Red Hat OpenStack no OpenShift, Nebulosa Aberta, Apache CloudStack, KubeVirt, Virtualização Red Hat OpenShift, Oracle Linux KVM, Oracle Linux Virtualization Manager, Virtuozzo, CloudSigma, STACKIT, VMware e oVirt.
- O Direct2Target grava dados diretamente nos discos de destino sem depender das APIs de gerenciamento da plataforma, portanto, qualquer ambiente com acesso de gravação em nível de disco pode servir como destino.
- Os testes de migração são executados em uma rede isolada, sem limite de quantidade. A migração final leva de 1 a 3 minutos em média.
- Os planos de migração definem a ordem de inicialização e as configurações de rede, para que os aplicativos sejam iniciados na sequência correta.
O Constructor Group, um ecossistema global de pesquisa, educação e tecnologia, utilizou o Hystax Migration para migrar suas cargas de trabalho do Google Cloud para o Virtuozzo. A empresa citou os custos a longo prazo e a dependência da plataforma como razões para a mudança, e afirmou que desejava uma plataforma que pudesse controlar e ajustar de forma mais completa. Seus aplicativos permaneceram online durante toda a transição.
O Hystax Disaster Recovery protege as cargas de trabalho após a migração. Deixar um hiperescalador não significa abrir mão da nuvem pública como rede de segurança: com recuperação de desastres entre nuvens, AWS, Azure ou Google Cloud podem servir como site de recuperação. As réplicas são mantidas nesses locais como volumes e snapshots, e as VMs completas são iniciadas somente quando necessário.
Para um período de retenção mais longo, o Hystax Backup grava pontos de restauração em armazenamento de objetos compatível com S3 ou em compartilhamentos NFS e Samba. Em armazenamento compatível com S3 configurado com Bloqueio de Objeto, os pontos de restauração permanecem imutáveis durante todo o período de retenção.
Você pode implantar o software em seu próprio ambiente, mantendo o controle dos dados de replicação. Os provedores de serviços gerenciados recebem um portal de parceiros multilocatário para executar diversos projetos de clientes simultaneamente. Os cenários de migração suportados estão listados no [link para a documentação]. migração para nuvem página.
Descreva seu ambiente. Nossos engenheiros mapearão as opções para suas plataformas de origem e destino, incluindo a recuperação de desastres após a migração.
Obrigado pelo seu pedido!
Entraremos em contato em breve.
Perguntas frequentes
O que é repatriação na nuvem em termos simples?
Significa transferir cargas de trabalho ou dados de uma nuvem pública e executá-los em uma infraestrutura controlada pela sua empresa. Por exemplo, um banco de dados com carga constante pode ser migrado da AWS para uma nuvem privada OpenStack.
Migração reversa para a nuvem é o mesmo que repatriação para a nuvem?
Os dois termos descrevem a mesma mudança. Uma saída da nuvem é um termo diferente: significa abandonar completamente um provedor, e as cargas de trabalho podem ser migradas para infraestruturas locais ou para outra nuvem.
A repatriação de capital na nuvem sempre gera economia?
Não. As economias aparecem em cargas de trabalho estáveis e previsíveis em grande escala. Cargas de trabalho com picos repentinos podem custar mais, assim como projetos que subestimam os custos de hardware, pessoal ou migração. Crie primeiro um modelo de Custo Total de Propriedade (TCO) de três a cinco anos.
Quanto tempo demora um projeto de repatriação?
Não existe um valor típico: a duração depende do número de cargas de trabalho, do volume de dados e da largura de banda da rede. A produção permanece online durante a replicação, e a própria transição do Hystax leva em média de 1 a 3 minutos.
Posso continuar usando a nuvem pública após o repatriamento?
Muitas empresas fazem isso. Uma configuração híbrida comum mantém as cargas de trabalho estáveis em uma nuvem privada e usa a nuvem pública para picos repentinos, experimentos e recuperação de desastres.
Preciso de agentes para migrar VMs da AWS, Azure ou Google Cloud?
Para essas fontes, sim. O Hystax replica VMs de nuvem pública por meio de um agente instalado no sistema operacional convidado. A replicação sem agentes no sistema operacional convidado está disponível apenas para fontes VMware, oVirt e OpenStack.