2 anos após migrar da AWS para bare metal: respostas às perguntas sobre sair da AWS

 (oneuptime.com)
16 pontos por GN⁺ 2025-10-30 | 3 comentários | Compartilhar no WhatsApp
  • Relatório que reúne respostas complementares a várias perguntas da comunidade, após compartilhar há 2 anos a experiência de migrar da AWS para bare metal e economizar US$ 230 mil por ano Revela dados reais de operação ao longo de 2 anos e afirma ter alcançado mais de US$ 1,2 milhão de economia anual
  • Com a operação prática, a economia aumentou para mais de US$ 1,2 milhão por ano, e esse valor foi reinvestido em servidores para resumo de incidentes com IA e correção automática de código, resultando em melhoria da qualidade do serviço
  • Com base na stack MicroK8s + Ceph, manteve 99,993% de disponibilidade e eliminou pontos únicos de falha com uma configuração de dois datacenters
  • Explica os principais pontos de discussão, como custos reais de operação, resposta a falhas, vida útil do hardware, certificações de segurança e serviços alternativos à nuvem, com números concretos
  • Como resultado, tanto a estabilidade quanto a eficiência de custos melhoraram, concluindo que, para sistemas com carga constante acima de certo porte, bare metal é mais racional

Resumo dos resultados de 2 anos de operação

  • Operando a stack MicroK8s + Ceph em produção por 24 meses, alcançou 99,993% de disponibilidade
    • Para resolver o problema de rack único, adicionou um segundo rack em Frankfurt e configurou uma ligação redundante DWDM com o rack principal em Paris
    • Com NVMe local e a eliminação de interferência de ruído, reduziu a latência dos clientes em 19%
  • Reinvestiu os custos economizados na compra de servidores bare metal para IA, ampliando os recursos de resumo de alertas com LLM e correção automática de código da OneUptime

Economia e comparação de custos

  • A economia inicialmente prevista era de US$ 230.000 por ano, mas agora aumentou para mais de US$ 1,2 milhão
    • Isso corresponde a cerca de 76% de redução de custos em comparação com a AWS
    • Em termos de custo global de mão de obra, equivale ao salário anual de 2 a 5 engenheiros
  • Mesmo aplicando Savings Plans / Reserved Instances, bare metal ainda leva vantagem
    • Savings Plans não se aplicam a custos de S3, egress e Direct Connect
    • Custos como US$ 1.260/mês do plano de controle do EKS e US$ 600/mês de NAT Gateway também não podem ser reduzidos
    • Como a carga era constante 24/7 (steady workload), a eficiência de instâncias reservadas era limitada

Migração e custos operacionais

  • A migração inicial foi concluída com cerca de 1 semana de trabalho de engenharia
    • A maior parte consistiu em trabalhos que já eram necessários, como organização de IaC e reforço da política de backup
  • Os custos atuais de operação são os seguintes:
    • Gestão direta: cerca de 24 horas por trimestre (incluindo patches e atualizações de firmware)
    • Remote Hands: só precisou intervir 2 vezes em 24 meses (principalmente por problemas de disco), com tempo médio de resposta de 27 minutos
    • Automação: boot PXE (Tinkerbell), gerenciamento de imagens Talos, automação de configuração com Flux/Terraform
  • A equipe de operações passou a ter maior velocidade de release do que na época da AWS, e também foi confirmado o efeito de eliminar o peso das “reuniões de otimização de custos”

Preparação para falhas e garantia de disponibilidade

  • Com a adição de um segundo rack em Frankfurt e conexão redundante por dois caminhos DWDM, eliminou pontos únicos de falha
    • Configuração com espelhamento Ceph baseado em replicação assíncrona e plano de controle duplo
    • Com a adição de um caminho de gerenciamento via 4G/satélite, o acesso remoto é possível em caso de falha de rede
  • Em transição de MicroK8s para Talos
  • O cluster de backup para failover na AWS ainda é mantido, com ensaios trimestrais de recuperação de desastres
  • Com Ingress baseado em Anycast+BGP, o atraso de troca de DNS também foi reduzido para menos de 1 minuto
  • Manteve 99,993% de disponibilidade por 2 anos e não foi afetado por falhas recentes de região da AWS

Hardware e gestão de CapEx

  • Os servidores são operados com base em depreciação de 5 anos (2×EPYC 9654, 1TB de RAM, configuração NVMe)
    • Quando a performance satura, são movidos para o cluster de análise e substituídos por novos servidores
    • Graças às economias, passou a ser possível um refresh de 40% a cada 2 anos, ainda assim com economia anual frente à AWS
  • Extensão de garantia da Supermicro + 3 servidores de reserva
    • A vida útil real é de 7 a 8 anos, mas foi calculada conservadoramente em 5 anos

Lógica para substituir serviços gerenciados

  • A filosofia de produto da OneUptime é possibilitar self-hosting, por isso é necessário manter a mesma stack
    • Mantém a consistência de open stack com Kubernetes, Postgres, Redis, ClickHouse etc.
  • Evoluiu de Terraform + EKS + RDS para MicroK8s + Argo Rollouts + Ceph
    • Usa open source puro, sem forks próprios
  • Ainda usa nuvem em paralelo: AWS Glacier (backup), CloudFront (cache de edge), instâncias temporárias para teste de carga
  • A nuvem é adequada para elasticidade, enquanto bare metal é adequado para carga base

Rede e segurança

  • Garantiu 2 links de 5Gbps (95th percentile), 8 vezes mais baratos que o egress da AWS
  • A proteção contra DDoS foi resolvida com Cloudflare na frente de tudo
  • Conta com uma rede de gerenciamento independente baseada em 4G/satélite, permitindo acesso remoto durante incidentes

Compliance e resposta a auditorias

  • Mantém certificações SOC 2 Type II e ISO 27001
    • Utiliza materiais do colocation, como certificação Tier III, logs de acesso e CCTV
    • Usa logs de configuração do Terraform/Talos como evidência de histórico de mudanças
  • Os auditores avaliaram isso como mais confiável do que capturas de tela do console da AWS

Comparação com alternativas de nuvem

  • Comparou Hetzner, OVH, Leaseweb, Equinix Metal e AWS Outposts
    • Hyperscalers ainda têm custo de egress alto
    • Hosts europeus têm dificuldade para atender requisitos de SLA e grandes clusters Ceph
    • O Equinix Metal tem um prêmio de 25~30% em relação ao CapEx
    • Operar hardware próprio leva vantagem em densidade elétrica e liberdade de upgrade
  • No fim, graças à configuração de rack de 15kW e à possibilidade de reutilização de componentes, o colocation ficou à frente em custo e desempenho

Medição da carga operacional (TOIL)

  • Semanal: patches de kernel/firmware e inspeção do Ceph (1 hora)
  • Mensal: upgrade canário do plano de controle do Kubernetes (2 horas)
  • Trimestral: treino de DR, planejamento de capacidade e revisão de contratos com operadoras (12 horas)
  • Total de cerca de 14 horas por mês, semelhante ao período na AWS, mas com o foco mudando de “acompanhamento de custos” para “automação operacional”

Quando a nuvem ainda faz sentido

  • Quando a carga de trabalho tem picos ou padrão sazonal
  • Quando há alta dependência de serviços gerenciados como Aurora Serverless, Kinesis e Step Functions
  • Quando não há capacidade para operar diretamente Kubernetes, Ceph, monitoramento e resposta a incidentes
  • Ou seja, para negócios em estágio inicial ou com carga muito variável, a nuvem ainda tem vantagem

Próximos planos

  • Pretende divulgar módulos Terraform e runbooks para prever orçamento de colo
  • Também está preparando um post técnico aprofundado sobre a experiência operacional com Talos
  • Continuará respondendo a feedbacks no HN e Reddit e compartilhando casos centrados em números reais

Leituras relacionadas

3 comentários

 
okxrr 2025-10-30

Trabalho em uma empresa que usa AWS com entusiasmo, mesmo sem usar absolutamente nenhum serviço exclusivo da AWS.

É uma história meio triste e engraçada ver como o desejo extremamente pessoal de alguns líderes de desenvolver a própria carreira pesa bastante nessa decisão..
 
GN⁺ 2025-10-30
Comentários no Hacker News

  • A AWS é cara demais. Há menos motivos do que parece para colocar um sistema inteiro em cima da AWS. Antigamente todo mundo sabia operar servidores bare metal por conta própria, mas parece que isso foi sendo esquecido. Nossa equipe manteve 99,993% de disponibilidade por mais de 730 dias e também escapou da recente queda de região da AWS. Usamos Cloudflare para defesa contra DDoS, então entendo que gerenciar DNS ou ingress pode virar um trabalho em tempo integral. Mas alguns microsserviços e um banco de dados já são perfeitamente administráveis por conta própria. Para a maioria das empresas, a AWS cobra demais

    • O verdadeiro problema da AWS é a dependência organizacional dos funcionários em relação à AWS. As pessoas tiram certificação AWS e entram no clima de que tudo precisa seguir o AWS Well-Architected Framework, e acabam parando de pensar por si mesmas. Os serviços de lock-in da AWS são precificados para parecer baratos de propósito, mas no fim prendem você ainda mais. Por exemplo, migrar de PostgreSQL para DynamoDB pode parecer economia no curto prazo, mas no longo prazo aumenta a dependência da AWS
    • On-premises é barato, mas é difícil encontrar especialistas. Funciona bem para produtos simples, mas em sistemas complexos o custo de pessoal e o risco operacional podem acabar sendo maiores. AWS/Azure/GCP não são perfeitos, mas hoje especialistas em on-premises estão raros demais
    • Quando se critica a AWS, há muita gente que reage de forma estranha. No Reddit acontece algo parecido. Dá até a sensação de que alguém está sendo pago para defender a AWS
    • Relatos de sucesso com self-hosting têm viés de confirmação. Operar servidores diretamente parece ótimo no começo, mas depois de um ano a documentação já divergiu da configuração real, e quando a pessoa responsável sai da empresa o caos aumenta. No fim, muitas startups voltam para a AWS. Esses casos de fracasso quase não são compartilhados
    • Para operar bare metal direito, são necessários engenheiros experientes. É difícil fazer isso só com júnior ou com “especialistas em nuvem” vindos de consultoria

  • A nuvem no começo era simples e oferecia bom custo-benefício, mas hoje virou um emaranhado de mais de 200 serviços complexos. Se você não gerenciar bem, a conta explode

    • Na verdade, a AWS nunca teve como principal proposta ser “barata”, e sim “escalar rapidamente”. No começo dos anos 2010 já era cara, mas tinha como vantagem a flexibilidade. Até hoje o preço por desempenho continua alto. Se você tiver o básico de administração de servidores, servidor dedicado é muito melhor
    • A AWS agora está excessivamente inflada, com mais de 200 serviços. Precisa voltar a focar no básico
    • Toda vez que entro no console da AWS, vem uma sensação de complexidade e cansaço. Ficou grande demais
    • O custo-benefício varia muito entre os serviços da AWS. Especialmente os serviços centrais mais antigos ainda têm valor

  • A verdadeira função da AWS é: (1) permitir expansão organizacional e estruturas de poder, (2) possibilitar tratamento contábil como OpEx em vez de CapEx, (3) esconder estruturas de contratação incompetentes. Antes era possível tocar um datacenter com 5 a 10 pessoas; agora surgem organizações de DevOps com 3.000 pessoas

    • Não entendo por que a diferença entre OpEx e CapEx seria tão importante. No fim, dinheiro não é dinheiro do mesmo jeito?
    • A nuvem é útil para startups em estágio inicial. Dá para crescer rápido sem se preocupar com planejamento de capacidade. Mas, para empresas com crescimento baixo, continuar na nuvem acaba sendo ineficiente
    • On-premises costuma ser muito customizado, então é difícil substituir pessoas. Já profissionais de AWS dá para encontrar em qualquer lugar
    • Administradores de sistemas experientes realmente são difíceis de achar e caros. Já vi casos em que tentaram economizar e o backup ficou sem funcionar por dois anos

  • A chave desse sucesso é uma carga constante 24/7. Na prática, a maioria das empresas também segue um padrão parecido

    • Na verdade, no começo foi sorte ter começado com um único rack e um único datacenter. Foi porque não pagaram antecipadamente o custo da confiabilidade
    • Artigo relacionado: One Big Server
    • A AWS muitas vezes diz que está “sem capacidade” e força o uso de instâncias reservadas. No fim, fica parecido com custo de operação contínua
    • Lugares como a Hetzner oferecem o mesmo desempenho por um preço 10 vezes menor que a AWS. A “elasticidade” da nuvem é um mito exagerado

  • O ponto central é elasticidade vs. carga de base. A nuvem só leva vantagem quando o tráfego explode de forma repentina, como em coleta de dados. Na maioria dos casos, bare metal é melhor

  • Nos anos 2010, hardware e rede eram lentos, mas hoje o desempenho e a eficiência de CPU melhoraram centenas de vezes. O que antes exigia 64 servidores hoje cabe em 1. No futuro, isso pode chegar a uma relação de 100:1. Nesse contexto, as vantagens da nuvem vão diminuindo cada vez mais

  • Do ponto de vista de um funcionário da Amazon, autogerenciar Kubernetes é arriscado demais. Componentes como etcd são instáveis, e ainda tivemos que aplicar patches por conta própria. O self-hosting citado no texto subestima os riscos

    • Outros hiperescaladores também já sofreram grandes incidentes por falhas na gestão de Kubernetes. Alternativas mais simples para rack único, como Microk8s, são melhores. Artigo relacionado: Microk8s 6 Months Later
    • Ambientes complexos são difíceis em qualquer lugar e, no fim, é preciso ter especialistas. Na AWS também não é fácil. Mesmo quando a nuvem cai, o mundo continua girando
    • Versões leves como k3 são bem mais simples
    • Kubernetes só deve ser usado quando realmente necessário. Adotá-lo como padrão é desperdício de tempo e dinheiro

  • Muitas startups talvez nem tivessem existido se dependessem dos preços da AWS. Por exemplo, algo como o download gratuito de GeoIP (link) seria inviável. A nuvem é lenta, com alta latência de disco e CPU supercompartilhada. Até US$ 10 mil por mês pode ser aceitável, mas acima disso bare metal é muito mais eficiente

    • As pessoas se acostumam com o desempenho lento da nuvem e acabam desenvolvendo uma adaptação estranha. A comparação sempre deveria ser feita tendo bare metal como referência

  • A empresa em que eu trabalhava também tinha pouco tráfego, mas queria migrar para a AWS. O motivo era simples — queriam colocar AWS no currículo. Isso valia tanto para desenvolvedores quanto para executivos. “Liderou uma migração para AWS” parecia bom para a carreira. No fim, a empresa foi vendida e o escritório ficou vazio. Talvez agora “saiu da AWS” vire um novo ponto positivo no currículo

    • Se os desenvolvedores querem AWS, a próxima geração vai conhecer apenas AWS. A discussão fica enviesada
    • No fim, a decisão depende da vontade da liderança

  • No fim das contas, o importante é o que você está tentando fazer

    • Se for um site interno centrado em dados, um único rack de servidores já basta
    • Se for tráfego massivo, irregular e impossível de cachear, a nuvem é mais vantajosa
    • Se DNS ou ingress forem complexos, uma abordagem híbrida é melhor
    • Quanto maior a escala de dados, mais a estrutura de depreciação de longo prazo da nuvem pode se tornar vantajosa