Voc\u00ea n\u00e3o subiu uma feature nova. N\u00e3o escalou o time. O tr\u00e1fego do produto est\u00e1 est\u00e1vel h\u00e1 tr\u00eas meses. Mesmo assim, a fatura de cloud chegou mais alta que a do m\u00eas anterior, de novo.<\/p>\n\n\n\n
O primeiro instinto \u00e9 abrir o console e procurar o recurso errado: alguma inst\u00e2ncia esquecida ligada, algum bug de configura\u00e7\u00e3o. \u00c0s vezes \u00e9 isso. Na maioria das vezes, n\u00e3o tem nenhum vil\u00e3o \u00fanico para encontrar.<\/p>\n\n\n\n
Esse padr\u00e3o n\u00e3o \u00e9 bug de billing nem coincid\u00eancia. \u00c9 o resultado esperado de como provedores de nuvem cobram: por consumo vari\u00e1vel, n\u00e3o por capacidade fixa.<\/p>\n\n\n\n
Cada camada de elasticidade que resolveu um problema de performance no passado, autoscaling, replica\u00e7\u00e3o entre zonas, storage em camadas, adicionou uma dimens\u00e3o de custo que ningu\u00e9m monitora ativamente no dia a dia. A fatura sobe porque a arquitetura foi desenhada para responder a demanda, n\u00e3o para conter gasto.<\/p>\n\n\n\n
O relat\u00f3rio FinOps in Focus, da Harness<\/a> (2025) projetou US$ 44,5 bilh\u00f5es em desperd\u00edcio de infraestrutura cloud para 2025. Isso equivale a 21% de todo o gasto corporativo em nuvem no mundo.<\/p>\n\n\n\n O State of the Cloud Report 2025, da Flexera<\/a>, chegou a um n\u00famero parecido pelo outro lado: 84% das organiza\u00e7\u00f5es apontam a gest\u00e3o de gasto em cloud como o principal desafio atual. O or\u00e7amento planejado j\u00e1 est\u00e1 sendo ultrapassado em 17% na m\u00e9dia.<\/p>\n\n\n\n Nenhum desses n\u00fameros descreve empresas mal geridas. Descreve o comportamento padr\u00e3o de uma arquitetura el\u00e1stica quando ningu\u00e9m est\u00e1 olhando para ela todo dia.<\/p>\n\n\n\n Autoscaling resolve pico de tr\u00e1fego, mas raramente volta ao tamanho original com a mesma agilidade com que cresce. A causa costuma ser configura\u00e7\u00e3o assim\u00e9trica: o time define alarmes agressivos para escalar (scale-out a 60% de uso de CPU, por exemplo) e limites bem mais conservadores para reduzir (scale-in s\u00f3 abaixo de 15%). O autoscaler sobe r\u00e1pido e desce devagar, quando desce.<\/p>\n\n\n\n Segundo o levantamento da Harness<\/a>, 71% dos times de desenvolvimento n\u00e3o fazem spot orchestration e 61% n\u00e3o fazem rightsizing das inst\u00e2ncias depois que elas sobem. O resultado \u00e9 um parque de m\u00e1quinas maior do que o necess\u00e1rio, travado no limiar do pior dia do trimestre por causa de alarmes mal calibrados, rodando o m\u00eas inteiro nesse tamanho.<\/p>\n\n\n\n Isso n\u00e3o aparece como uma linha de custo isolada na fatura. Aparece distribu\u00eddo em dezenas de recursos pequenos, cada um alguns reais acima do necess\u00e1rio. Juntos, formam a diferen\u00e7a entre a conta que voc\u00ea esperava e a que chegou. Sem um processo recorrente de revis\u00e3o de inst\u00e2ncias, esse excesso vira base, n\u00e3o pico.<\/p>\n\n\n\n O problema raramente \u00e9 t\u00e9cnico. Rightsizing existe como pr\u00e1tica h\u00e1 anos, e a maioria das ferramentas de cloud j\u00e1 exp\u00f5e m\u00e9trica de utiliza\u00e7\u00e3o por inst\u00e2ncia.<\/p>\n\n\n\n O que falta \u00e9 rotina: algu\u00e9m revisando esses n\u00fameros toda semana, com autoridade para desligar ou redimensionar o que sobrou de um pico que j\u00e1 passou. Sem esse dono, o dimensionamento de pico vira o dimensionamento padr\u00e3o.<\/p>\n\n\n\n Volume de disco de um teste que terminou em mar\u00e7o. Load balancer de uma vers\u00e3o do produto que j\u00e1 foi descontinuada. IP el\u00e1stico reservado para uma migra\u00e7\u00e3o que nunca aconteceu.<\/p>\n\n\n\n Nenhum desses itens aparece em um dashboard de performance, porque nenhum deles est\u00e1 fazendo nada. \u00c9 por isso que continuam ativos: ningu\u00e9m recebe alerta de que um recurso parado est\u00e1 sendo cobrado.<\/p>\n\n\n\n Menos da metade das equipes tem visibilidade em tempo real sobre isso. Segundo a mesma pesquisa da Harness<\/a>, 43% enxergam recursos ociosos e 39% enxergam recursos \u00f3rf\u00e3os.<\/p>\n\n\n\n Na pr\u00e1tica, o tempo m\u00e9dio entre um recurso virar lixo e algu\u00e9m notar \u00e9 de 31 dias. Multiplique isso pelo n\u00famero de squads rodando workloads em paralelo, e o ac\u00famulo deixa de ser marginal.<\/p>\n\n\n\n Storage parado tem custo previs\u00edvel. Egress, a sa\u00edda de dado para a internet, e tr\u00e1fego cross-AZ s\u00e3o cobrados por gigabyte transferido, n\u00e3o por gigabyte armazenado. Na era de Kubernetes e microsservi\u00e7os, arquiteturas distribu\u00eddas movem dado o tempo todo: um pod na Zona A consultando um banco na Zona B, backup incremental, tr\u00e1fego roteado de forma ineficiente atrav\u00e9s de um NAT Gateway, sincroniza\u00e7\u00e3o de cache entre r\u00e9plicas.<\/p>\n\n\n\n Cada uma dessas opera\u00e7\u00f5es \u00e9 invis\u00edvel no c\u00f3digo. S\u00f3 fica vis\u00edvel na fatura, semanas depois.<\/p>\n\n\n\n Dobrar a resili\u00eancia de uma aplica\u00e7\u00e3o, replicando servi\u00e7os em m\u00faltiplas zonas, quase sempre dobra parte do custo de rede junto. Isso acontece mesmo sem dobrar o tr\u00e1fego de usu\u00e1rio final.<\/p>\n\n\n\n A conta reflete decis\u00f5es de arquitetura tomadas meses atr\u00e1s, executadas em sil\u00eancio todo m\u00eas desde ent\u00e3o.<\/p>\n\n\n\n Compromissos de capacidade reservada, Reserved Instances ou Savings Plans, deveriam reduzir custo. Na pr\u00e1tica, segundo o mesmo relat\u00f3rio da Harness<\/a>, 55% dos desenvolvedores dizem que essas decis\u00f5es de compra s\u00e3o baseadas em estimativa, n\u00e3o em dado real de uso.<\/p>\n\n\n\n Do lado da governan\u00e7a, 52% dos l\u00edderes de engenharia apontam a desconex\u00e3o entre FinOps e times de desenvolvimento como causa direta de desperd\u00edcio. Apenas 32% dos times t\u00eam automa\u00e7\u00e3o real para impor pol\u00edtica de custo.<\/p>\n\n\n\n O efeito pr\u00e1tico: quem decide a arquitetura n\u00e3o v\u00ea a fatura, e quem v\u00ea a fatura n\u00e3o decide a arquitetura. Cada lado otimiza para o pr\u00f3prio objetivo, entrega r\u00e1pida de um lado, or\u00e7amento fechado do outro, e o custo vari\u00e1vel fica sem dono.<\/p>\n\n\n\n Um erro comum de arquitetura: o time reserva capacidade baseando-se no pico de tr\u00e1fego do ano anterior, uma Black Friday, por exemplo, em vez de comprometer apenas a linha de base constante do sistema. Doze meses depois, o provedor continua faturando esse compromisso superdimensionado todo m\u00eas, independente de o produto ter crescido, encolhido ou mudado de arquitetura no meio do caminho.<\/p>\n\n\n\n Ningu\u00e9m tomou uma decis\u00e3o errada ao buscar o desconto do compromisso de longo prazo. O erro foi aplicar esse modelo de reserva sobre uma m\u00e9trica de pico el\u00e1stico, em vez do baseline. Faltou um gatilho para revisar essa decis\u00e3o depois.<\/p>\n\n\n\n Parte desse problema \u00e9 estrutural ao modelo de cloud p\u00fablica global: pre\u00e7o em d\u00f3lar, cobran\u00e7a por dezenas de m\u00e9tricas separadas, regi\u00e3o e zona influenciando o valor final do mesmo recurso.<\/p>\n\n\n\n Uma base s\u00f3lida de infraestrutura no Brasil ataca justamente esse ponto. O Locaweb Cloud<\/a> roda em data center brasileiro, com faturamento em real e gerenciamento das m\u00e1quinas virtuais centralizado em um \u00fanico painel. A plataforma tamb\u00e9m n\u00e3o cobra por tr\u00e1fego de entrada ou sa\u00edda, o que remove de vez a vari\u00e1vel de egress e cross-AZ que mais surpreende quem migra de uma cloud p\u00fablica global. Isso elimina boa parte da fragmenta\u00e7\u00e3o de custo que aparece em ambientes multi-servi\u00e7o: voc\u00ea v\u00ea o que est\u00e1 rodando, sem reconciliar dez itens de linha em d\u00f3lar para entender de onde veio o aumento.<\/p>\n\n\n\n Para workloads com padr\u00e3o de uso mais est\u00e1vel, sem necessidade de elasticidade agressiva, migrar parte da carga para um servidor VPS<\/a> com custo fixo mensal remove de vez a vari\u00e1vel mais dif\u00edcil de prever: o consumo que oscila sem aviso.<\/p>\n\n\n\n Workloads core do produto, aqueles que rodam o tempo todo em volume parecido, raramente precisam da elasticidade completa de uma cloud p\u00fablica. \u00c9 o mesmo racioc\u00ednio por tr\u00e1s de um certificado SSL, item de custo fixo e previs\u00edvel, contra o tr\u00e1fego de rede, que nunca \u00e9.<\/p>\n\n\n\n Antes de decidir entre nuvem p\u00fablica, VPS ou modelo h\u00edbrido, compare as diferen\u00e7as reais entre on-premise e cloud computing<\/a> e o que uma arquitetura IaaS bem dimensionada<\/a> resolve na pr\u00e1tica.<\/p>\n\n\n\nO provisionamento nunca fica parado<\/h2>\n\n\n\n
Por que o autoscaling n\u00e3o volta sozinho<\/h3>\n\n\n\n
Quem deveria estar revisando isso<\/h3>\n\n\n\n
Recursos que continuam cobrando depois que o motivo acabou<\/h2>\n\n\n\n
Os recursos \u00f3rf\u00e3os mais comuns<\/h3>\n\n\n\n
O tempo que leva para algu\u00e9m notar<\/h3>\n\n\n\n
Tr\u00e1fego entre zonas cobra pelo que se move<\/h2>\n\n\n\n
Onde o tr\u00e1fego se esconde<\/h3>\n\n\n\n
O pre\u00e7o de mais resili\u00eancia<\/h3>\n\n\n\n
Capacidade reservada \u00e9 decidida com pouco dado real<\/h2>\n\n\n\n
A desconex\u00e3o entre FinOps e dev<\/h3>\n\n\n\n
Um compromisso que ningu\u00e9m revisita<\/h3>\n\n\n\n
Onde previsibilidade entra na conta<\/h2>\n\n\n\n
Faturamento em real, painel \u00fanico<\/h3>\n\n\n\n
Quando VPS resolve melhor que elasticidade<\/h3>\n\n\n\n
Para aprofundar antes de decidir<\/h3>\n\n\n\n