AWS para Hetzner: Quando Bare Metal Faz Sentido Financeiramente

A conta de cloud computing da sua empresa está crescendo mais rápido que o tráfego? Em 2025, o movimento de “cloud repatriation” ganhou tração significativa, e discussões sobre migrar workloads de AWS para provedores bare-metal como Hetzner estão gerando centenas de upvotes em fóruns técnicos. Mas os números realmente fazem sentido, ou é apenas hype temporário?

Vamos examinar os custos reais, as métricas de performance verificáveis e os trade-offs operacionais que ninguém menciona nos posts celebrando economias de 70%. A migração de cloud pode fazer sentido estratégico para perfis específicos de workload — só não é uma decisão que se toma baseada apenas em planilhas de comparação de preços.

A Matemática Brutal dos Custos de Compute

A diferença de custo entre AWS e Hetzner é significativa, mas precisa ser analisada com nuance. Segundo pricing oficial, um servidor Hetzner AX52 (AMD Ryzen 7 3700X, 8 cores/16 threads, 64GB RAM, 2x512GB NVMe) custa €49.90/mês (~$54). Para obter capacidade comparável na AWS? Um EC2 c6a.4xlarge (16 vCPUs AMD EPYC 3rd Gen, 32GB RAM) sai por aproximadamente $552/mês on-demand em us-east-1.

A diferença por vCPU é ainda mais reveladora: Hetzner cobra aproximadamente €6.57 por vCPU/mês, enquanto AWS cobra cerca de $34.50 — uma diferença de 5.2x segundo dados do instances.vantage.sh. Essa comparação direta, porém, esconde complexidades importantes.

O primeiro problema: vCPUs da AWS não são equivalentes a cores físicas dedicadas. O Hetzner AX52 fornece cores físicas reais sem noisy neighbors, enquanto o c6a.4xlarge compartilha recursos de CPU com outras instâncias. Em workloads CPU-bound com alta variabilidade de demanda, essa diferença pode ser crítica.

O segundo fator são os custos ocultos de rede. Hetzner inclui 20TB de tráfego de saída sem custo adicional em todos os servidores dedicados. Na AWS, você paga $0.09/GB após os primeiros gigabytes gratuitos. Para aplicações com alto tráfego de saída — APIs públicas, CDNs, streaming de mídia — esse custo se acumula exponencialmente. Uma API servindo 10TB/mês de dados pagaria cerca de $900 apenas em bandwidth na AWS, valor já incluído no Hetzner.

Performance de Storage: Onde Hetzner Realmente Domina

A vantagem mais significativa do bare metal não é CPU ou RAM. É storage.

Hetzner fornece NVMe local diretamente conectado, enquanto AWS oferece EBS (Elastic Block Store) que, apesar de conveniente, adiciona latência de rede ao caminho crítico de I/O. Os números são concretos: NVMe RAID em servidores Hetzner atinge 6,000+ MB/s em throughput sequencial, comparado a 1,000 MB/s do EBS gp3 padrão da AWS. Em operações random 4K, Hetzner entrega aproximadamente 500,000 IOPS, contra 16,000 IOPS base do gp3 (configurável até mais, mas com custos adicionais).

Mais importante: a latência de storage no NVMe local é menor que 100 microssegundos, versus aproximadamente 1 milissegundo do EBS gp3 segundo benchmarks do cloudbench.io. Para databases transacionais onde cada microssegundo conta, essa diferença é transformativa. Um benchmark independente de 2023 mostrou PostgreSQL rodando em bare metal Hetzner entregando 3.2x mais transações por segundo (TPS) que AWS RDS equivalente. A latência de intra-datacenter também favorece Hetzner: ~0.2ms comparado a 0.5-1ms entre instâncias na mesma availability zone da AWS.

Aqui está o primeiro grande trade-off: NVMe local no Hetzner não possui replicação automática. AWS EBS é automaticamente replicado dentro da zona de disponibilidade. Se o disco falha no Hetzner, você depende inteiramente dos seus próprios backups e estratégias de recovery. O Hetzner Storage Box (backup via WebDAV/SFTP/Samba) existe, mas não é block storage de alta performance equivalente ao EBS — é fundamentalmente diferente em arquitetura e propósito.

Trade-offs Operacionais que Ninguém Menciona

A migração para bare metal não é apenas uma questão de provisionar servidores mais baratos. A complexidade operacional aumenta significativamente, e esse custo raramente aparece nas comparações diretas de preço.

Ausência de ferramentas de migração automatizada. AWS possui ecossistemas maduros de migration tools — Database Migration Service, Application Migration Service, etc. Para Hetzner, você está essencialmente fazendo lift-and-shift manual. O Terraform provider oficial existe (hetznercloud/terraform-provider-hcloud com 10k+ stars no GitHub), mas você precisará reprojetar significativamente sua infraestrutura como código.

Gerenciamento de alta disponibilidade se torna responsabilidade sua. Na AWS, você configura Auto Scaling Groups e Elastic Load Balancers. No Hetzner, você implementa isso manualmente — seja com Keepalived, HAProxy, ou clustering de aplicação. Não é impossível, mas requer expertise e tempo de engenharia.

Cobertura geográfica limitada. Hetzner opera em 5 regiões (3 na Europa, 2 nos EUA) contra 30+ regiões globais da AWS. Se você precisa servir usuários na Ásia-Pacífico ou América do Sul com baixa latência, Hetzner simplesmente não é opção. Ping times entre regiões europeias do Hetzner (Falkenstein-Nuremberg) são excelentes — ~5ms — mas você está confinado geograficamente.

Menos serviços gerenciados. AWS oferece RDS, Lambda, S3, DynamoDB, SQS, e dezenas de outros serviços prontos. No Hetzner, você está majoritariamente gerenciando compute e storage básicos. Isso significa mais infraestrutura self-hosted — mais PostgreSQL configurado manualmente, mais Redis que você mantém, mais message queues que você opera.

Quando a Migração Realmente Faz Sentido

A decisão não deveria ser binária “AWS ou Hetzner”. O que você precisa é identificar workloads específicos onde bare metal oferece vantagem estratégica real.

Perfil ideal para migração:

Aplicações com alto throughput de saída de rede. Se você está pagando milhares de dólares mensais em bandwidth na AWS, Hetzner incluindo 20TB sem custo adicional muda fundamentalmente a equação. Fathom Analytics reportou 90% de redução em custos de servidor após migração, e Baserow (alternativa open-source ao Airtable) documentou ~70% de redução em infraestrutura — ambos casos com alto volume de tráfego de saída.

Databases transacionais com workloads I/O intensivos. Se você está pagando premium por AWS io2 Block Express (que pode atingir 256,000 IOPS mas custa $0.125/GB-mês + $0.065/IOPS), testar PostgreSQL ou MySQL em NVMe local Hetzner pode oferecer performance superior por fração do custo.

Workloads compute-bound estáveis. Se você precisa de capacidade consistente e previsível (não workloads que escalam horizontalmente de 10 para 100 instâncias em minutos), cores físicas dedicadas oferecem performance mais consistente que vCPUs compartilhadas.

Quando definitivamente NÃO migrar:

Aplicações que dependem fortemente de serviços gerenciados AWS (Lambda, DynamoDB, S3 com integrações complexas). O custo de reimplementar esses serviços supera qualquer economia de compute.

Workloads com padrões imprevisíveis de demanda que requerem autoscaling agressivo. Bare metal não oferece a elasticidade instantânea de cloud.

Aplicações com requisitos de compliance específicos (SOC2, ISO, HIPAA) onde você confia nas certificações AWS. Implementar compliance do zero em infraestrutura self-managed é projeto multimês.

Estratégia Híbrida: O Pragmatismo Vence

A abordagem mais pragmática não é migração total, mas arquitetura híbrida cuidadosamente planejada. Mantenha na AWS componentes que realmente se beneficiam do ecossistema gerenciado — Lambda para processamento serverless, S3 para object storage com CDN CloudFront, RDS para databases que não são performance-critical.

Migre para Hetzner workloads que são compute/storage intensive e geograficamente concentrados. Seu database principal de alta performance, seus workers de processamento de background, seus caches Redis — componentes onde você já gerencia complexidade operacional significativa e onde latência de storage faz diferença mensurável.

Use VPN site-to-site (WireGuard é excelente opção) para conectar ambientes. A latência adicional entre clouds é gerenciável se você projetou suas APIs com isso em mente.

A migração AWS-Hetzner não é sobre abandonar cloud pública completamente. É sobre reconhecer que diferentes workloads têm diferentes perfis de custo-benefício, e que o toolkit moderno de infraestrutura permite combinar providers estrategicamente. Os 70% de economia existem — mas apenas se você aceitar os trade-offs operacionais e tiver workloads que realmente se beneficiam de bare metal.

Avalie seus custos de bandwidth, meça sua performance de I/O real, calcule o tempo de engenharia necessário para migration e operação continuada. Se depois disso os números ainda fazem sentido, a migração pode ser excelente movimento estratégico. Se não, você economizou meses de trabalho ao não perseguir otimização prematura de infraestrutura.