Achando o desperdício de nuvem que ninguém está procurando

A maioria do desperdício de nuvem não é uma decisão ruim que alguém tomou de propósito. É um disco que ninguém desconectou depois que um servidor foi redimensionado há oito meses, um load balancer apontando pra um serviço que foi desativado, um snapshot guardado “só por precaução” que ninguém mais pensa há tempos. Nada disso aparece na fatura como uma linha única e óbvia — fica espalhado fino o suficiente pra que ler a fatura linha por linha quase nunca pegue isso.

O que realmente é escaneado

O Railyard nunca coloca markup no compute — todo servidor é cobrado pelo preço real do provedor de nuvem. A página Costs usa as mesmas credenciais de nuvem já salvas pra criar servidores, e escaneia contas da DigitalOcean, Hetzner, Vultr e AWS diretamente: cada conta por vez, a AWS região por região, com progresso em tempo real enquanto roda. Os valores cobrados vêm da própria API de faturamento de cada provedor, onde ela existe (AWS Cost Explorer, faturas da DigitalOcean, cobranças pendentes da Vultr, créditos e reembolsos incluídos) — a Hetzner não tem API de faturamento, então os números dela vêm da própria tabela de preços em tempo real da Hetzner.

Não para só nos servidores que o Railyard criou: discos, endereços IP, snapshots, imagens de máquina, NAT gateways, load balancers e bancos de dados — qualquer coisa na conta, incluindo recursos que o scan não teve nada a ver com provisionar.

O que ele realmente encontra

Agrupado por quão fácil é a correção — correções fáceis, médias, mudanças maiores e coisas que vale a pena olhar de novo — com cada achado explicando por que foi sinalizado, o que corrigi-lo faz com a aplicação em execução, e como:

• Discos desconectados, e discos sentados em servidores parados há muito tempo
• Endereços IP não usados, NAT gateways ociosos e load balancers sem tráfego real
• Snapshots e imagens de máquina antigos que ninguém usa há tempos
• Servidores rodando ociosos, sem nenhuma aplicação, ou só com aplicações paradas
• Um servidor dimensionado bem acima do que sua própria média de 14 dias e o pico real de CPU/memória precisam
• Tipos de instância AWS de gerações anteriores, e onde ARM (Graviton) custaria menos pelo mesmo trabalho
• Discos AWS e armazenamento de banco de dados que poderiam migrar pra gp3

A parte que importa mais do que a lista: a maior parte é um clique

Onde uma correção é segura de automatizar, o achado tem um botão de verdade — apagar disco, liberar IP, apagar snapshot, terminar, converter pra gp3, parar, redimensionar — cada um pedindo confirmação e deixando claro o impacto antes (“apaga o disco e os dados dele — tire um snapshot antes”). Um redimensionamento tira um snapshot do servidor automaticamente antes de tocar nele. As mudanças maiores, como mover um servidor inteiro pra ARM, vêm com os passos reais em vez de um botão de um clique, porque essa não é uma decisão segura de automatizar por completo.

Proteções, não só um relatório

Defina um orçamento mensal e regras de notificação disparam em 50%, 80% e 100% da previsão de fim de mês — além de sempre que o gasto tiver um pico ou aparecer desperdício novo. Marque Hard cap e o Railyard aplica em vez de só alertar: em 100% do orçamento, toda aplicação fora de produção vai dormir e novos servidores deixam de poder ser criados até o gasto voltar pra baixo da linha ou o orçamento ser aumentado. É essa a diferença entre um dashboard de custos e algo que de fato impede a fatura de sair do controle num feriado longo que ninguém está acompanhando.

O que ele é honesto em não saber

Os números de economia usam o preço de lista público de cada provedor pra região — um desconto negociado de nível enterprise não é visível pro scan. As divisões de custo por ambiente no canvas são a fatia de cada serviço no preço do seu servidor, calculada a partir do uso de memória — uma estimativa real, apresentada como tal, não como uma fatura exata.

Referência completa, incluindo a política exata de IAM da AWS necessária: Costs and savings.