Estratégia de Saída da Nuvem: Migrar do AWS para On-Premises em 2025

Em 2024, uma empresa de manufatura no Brasil descobriu que sua fatura mensal da AWS havia ultrapassado R$ 450 mil — quase três vezes o orçamento original previsto quando migraram para a nuvem em 2021. Depois de 18 meses tentando otimizar custos com Reserved Instances, Savings Plans eSpot Instances sem sucesso, tomaram uma decisão impensável dois anos antes: repatriar workloads críticos de volta para infraestrutura on-premises. Este cenário não é isolado. Segundo dados do Gartner, aproximadamente 15% das organizações que migraram para a nuvem pública entre 2019 e 2022 estão considerando ou já executando cloud repatriation em 2025.

O Que É uma Estratégia de Saída da Nuvem (Cloud Exit Strategy)?

Uma cloud exit strategy é um plano estruturado e documentado para repatriar cargas de trabalho de um provedor de nuvem pública — neste caso, AWS — de volta para infraestrutura on-premises ou data centers dedicados. O termo cloud repatriation tornou-se mainstream a partir de 2023, quando análises do IDC revelaram que 40% das empresas no Brasil reportaram "surpresa de custo" (bill shock) em suas faturas de nuvem, especialmente em serviços como RDS, EKS e Data Transfer.

Diferente de uma simples migração, a saída da nuvem exige:

• Análise de TCO completa: Comparar custos diretos (EC2, S3, RDS) e indiretos (egress fees, suporte) com CAPEX + OPEX on-premises
• Mapeamento de dependências: Identificar integrações entre serviços AWS nativos (Lambda ↔ DynamoDB, S3 ↔ CloudFront) e equivalentes on-premises
• Validação de compliance: Garantir que a infraestrutura repatriada atende requisitos LGPD, ISO 27001, e normas do setor
• Planejamento de continuidade: Manter operações durante transição sem downtime significativo

Quando Faz Sentido Migrar do AWS para On-Premises?

Nem toda frustração com custos justifica repatriação. Baseado em implementações que conduzi nos últimos três anos, identifico cinco cenários onde a cloud exit strategy faz sentido:

1. Workloads com uso consistente acima de 70% de utilização
Se seus EC2 instances operam em média acima de 70% de CPU/memória 24/7, você está essencialmente pagando por infraestrutura ociosa. Reserved Instances com 1-year commitment oferecem 30-40% de desconto, mas ainda assim superam custos de hardware próprio após 24 meses.

2. Requisitos de latência sub-5ms
Aplicações de trading, sistemas de automação industrial (SCADA), e bases de dados OLTP com milhares de transações por segundo pagam fortunas em Enhanced Networking e Reserved Instances Premium. Um cluster PostgreSQL on-premises com NVMe SSDs (Intel Optane) consegue latências de 0.3-0.8ms, compares to 2-5ms via AWS Direct Connect.

3. Volumes massivos de dados com acessibilidade imprevisível
S3 Intelligent-Tiering parece atraente, mas egress fees de R$ 0,09 por GB (região São Paulo) destroem a economia para aplicações que precisam mover dados regularmente. Uma empresa de mídia com 500TB de archives descobriu que pagar R$ 45 mil/mês de egress fees era mais caro que construir um Object Storage on-premises com MinIO e fita LTO-9 para archiving.

4. Restrições regulatórias e soberania de dados
Setores como healthcare, banking, e government têm mandates que increasingly impedem dados sensíveis fora de jurisdição específica. A resolução CMN 4.893/2021 do Banco Central e a LGPD criaram ambiguidades que levam CISOs a optarem por controle total — mesmo que isso signifique higher operational burden.

5. Stack profundamente acoplada à AWS
Quando sua arquitetura depende massivamente de serviços proprietários (Lambda, DynamoDB, Cognito, AppSync), migrar para alternativas open-source (Kubernetes + PostgreSQL + Keycloak) pode ser tão complexo quanto uma reengenharia completa. Nesses casos, avaliar se o vendor lock-in justifica os custos torna-se crítico.

Quais São os Custos Reais da Repatriação em 2025?

A pergunta que todo CTO precisa responder antes de iniciar cloud exit: "Quanto vou pagar agora versus quanto pagarei em 3 anos?"

Cenário Típico: Empresa Médio-Porte no Brasil

Perfil da carga:

• 50 EC2 instances (mix m5.xlarge, r5.2xlarge)
• 100TB S3 Standard
• 3 clusters RDS PostgreSQL (db.r5.large)
• EKS com 40 pods
• Data transfer: 5TB/month egress

Custo mensal AWS atual:

• EC2 (on-demand): ~R$ 85.000
• S3: ~R$ 9.200
• RDS: ~R$ 22.000
• EKS: ~R$ 2.400
• Data Transfer: ~R$ 450 (egress)
• Total: ~R$ 119.050/mês

Custo on-premises equivalente:

• Hardware (3 anos amortizado): 2x Dell PowerEdge R750xs, 500TB usable storage (Nutanix HCI AOS 6.5), networking 10GbE
  • CAPEX: ~R$ 1.200.000 (depreciação 3 anos = R$ 33.333/mês)
• OPEX mensal: energia (~R$ 8.000), cooling (~R$ 3.000), suporte técnico (~R$ 5.000), equipe 2 SysAdmins (
  R$ 20.000)
  • OPEX: ~R$ 36.000/mês
• Total: ~R$ 69.333/mês

Economia: R$ 49.717/mês → ROI em 25 meses

Estes números ignoram custos de implementação (profissionais de projeto, ferramentas de migração,可能的 downtime) estimados em R$ 200.000-400.000 adicionais.

Como Planejar a Migração AWS para On-Premises?

Fase 1: Discovery e Inventário (4-8 semanas)

Antes de tocar em qualquer servidor, você precisa de visibilidade completa. Ferramentas como AWS Cost Explorer, Trusted Advisor, e Third-Party tools como CloudHealth ou Spot.io fornecem dados essenciais.

1. Catalog all resources: Use AWS Config Aggregator para exportar inventory completo de EC2, RDS, S3 buckets, Lambda functions, e network resources
2. Analyze usage patterns: Identifique horários de pico, sazonalidade, e correlação entre serviços
3. Map dependencies: AWS Application Discovery Service ajuda a identificar comunicações inter-serviços
4. Classify workloads: Categorize por criticidade (Tier 1-4), compliance requirements, e technical complexity

Fase 2: Arquitetura da Infraestrutura Alvo

Com inventory em mãos, projete a infraestrutura on-premises que acomodará seus workloads.

Opções de plataforma:

Para o cenário da empresa médio-porta acima, recomendo Nutanix HCI com AHV hypervisor. A curva de aprendizado é menor que VMware, o management é unificado via Prism Central, e o licensing está incluído no appliance — eliminando conversas complicadas com VMware subscription renewals.

Fase 3: Estratégia de Migração

Escolher a estratégia certa evita o "big bang migration" que derruba sistemas produtivos.

Approach recomendado: Migration em ondas (Wave Migration)

1. Wave 0 - Infraestrutura base (Semanas 1-4)

   • Deploy e validar ambiente on-premises
   • Configurar networking, storage, e backup
   • Establish connectivity (VPN site-to-site ou Direct Connect emulation)

2. Wave 1 - Workloads não-críticos (Semanas 5-10)

   • Migrar dev/test environments
   • Validar performance benchmarks
   • Treinar equipes operacionais

3. Wave 2 - Aplicações secundárias (Semanas 11-18)

   • Batch processing, reporting, analytics
   • Database replicas para validar data integrity

4. Wave 3 - Core systems (Semanas 19-28)

   • Application servers críticos
   • Databases principais (com cutover strategy detalhada)

5. Wave 4 - Descomissionamento (Semanas 29-32)

   • Validate all applications on-premises
   • Cancelar Reserved Instances e recursos AWS
   • Document lessons learned

Ferramentas para Migration:

• AWS Server Migration Service (SMS): Replica VMs EC2 (imported via VM Import/Export) para ambientes on-premises. Gratuito, mas lento para bases grandes
• Zerto: Enterprise-grade replication com WAN optimization. Custo ~R$ 25.000/ano para 100 VMs. Ideal para databases com RPO de minutos
• AWS Database Migration Service (DMS): Para RDS → PostgreSQL/MySQL on-premises. Suporta Ongoing replication
• Velero: Para workloads Kubernetes (EKS → OpenShift on-prem). Backup/restore e migration de persistent volumes
• Rclone + MinIO: Para S3 → Object Storage on-premises. Sync incremental com bandwidth control

Fase 4: Execução e Validação

Migration day nunca sai 100% conforme planejado. Tenha war room configurado, runbooks documentados, e rollback procedure testada.

Checklist de cutover:

• DNS TTLs reduzidos para 60 segundos 24h antes
• Backup completo de databases (com point-in-time recovery testado)
• Connection strings atualizadas
• Monitoring configurado no novo ambiente
• Team on-call com acesso root
• Estimated cutover window communiqué aos stakeholders
• Go/No-go criteria definidos antes de iniciar

Quais São os Riscos e Como Mitigá-los?

Honestamente, cloud exit strategy tem riscos significativos que você deve avaliar com olhos abertos:

Risco 1: Subestimação de complexidade operacional
On-premises significa que você é o próprio "cloud provider". Patch management, hardware failures, capacity planning, e security hardening caem sobre sua equipe. Se você não tem pelo menos 2 SysAdmins dedicados com experiência em VMware/Linux, a repatriação criará mais problemas que resolve.

Risco 2: Vendor lock-in reverso
Ao migrar workloads para uma plataforma on-premises específica (ex: Nutanix), você troca um vendor lock-in por outro. Avalie contratos de suporte e exit fees antes de comprar hardware.

Risco 3: Custo de energia e facilities
Se seu data center atual não tem capacity, custos de construção, cooling, e UPS podem facilmente dobrar o CAPEX. Data centers no Brasil cobram R$ 150-300 por kW/mês em São Paulo.

Risco 4: Skills gap
Equipes que operaram primariamente em AWS por anos podem ter atrophied skills para troubleshooting de hardware, network config, e storage administration. Budget para 3-6 meses de training antes da migração.

Conclusão: Vale a Pena?

Cloud repatriation não é anti-cloud — é cloud optimization em sua forma mais radical. Para workloads com usage patterns previsíveis, requisitos regulatórios strictos, e custos mensais que superam consistentemente TCO on-premises, a repatriação faz sentido business.

Para aplicações com demanda altamente variável, equipes small, ou requisitos de scale elástico, permanecer na AWS com ferramentas de FinOps ( Savings Plans otimizados, Auto Scaling refined, Graviton instances) continua sendo a escolha racional.

A decisão não é binary. Architectures híbridas que mantêm workloads bursty na nuvem enquanto repatriam steady-state workloads são increasingly common. O importante é ter dados, não emoção, guidando suas decisões.

Se você está considerando cloud exit strategy para sua organização, comece com uma análise de TCO rigorosa usando dados reais de seus últimos 6 meses de AWS billing. Se a economia projetada não justifica 24+ meses de payback, provavelmente você precisa otimizar sua presença na nuvem — não abandoná-la.

Nota do autor: Os custos apresentados neste artigo são estimativas baseadas em pricing público da AWS (região São Paulo, Fevereiro 2025) e benchmarks de hardware típico. Custos reais variam significativamente baseados em negotiated contracts, volume discounts, e specific workload requirements. Recomendo validation detalhada com seu team de finanças e infrastructure antes de tomar decisões de migração.