A verdade sobre separar ambientes na nuvem sem queimar orçamento
A maioria dos times que eu vejo tenta replicar a infraestrutura de produção em cada ambiente de desenvolvimento, staging e teste. Isso funciona até o terceiro mês, quando a conta chega e todo mundo olha para o saldo negativo com cara de quem não reconhece aquele número. Já passei por isso em três empresas diferentes. O problema não é a ferramenta. É a mentalidade de que ambiente de teste precisa ser idêntico ao de produção. Em 90% dos casos, essa premissa é absurda. Um banco de dados RDS instância db.r6g.xlarge rodando 24/7 só para testes não gera valor. Nunca gerou.
como dividir ambientes de forma barata: o método que realmente funciona
O primeiro passo é entender o que cada ambiente realmente consome. Produção roda banco de dados grande, filas, cache, múltiplas réplicas. Staging precisa de dados reais mas em escala reduzida. Desenvolvimento local pode rodar containers com tudo que precisa e desligar quando não está usando. A economia real acontece quando você para de tratar todos os ambientes como gêmeos idênticos. No meu trabalho com infraestrutura, aprendi que a técnica mais subestimada é o uso de ambient scaling seletivo. Isso significa que você defini políticas automáticas de ligar e desligar recursos. Banco de dados, filas e caches param fora do horário comercial em ambientes de desenvolvimento e staging. O ganho médio que eu vejo na prática é entre 60% e 75% de redução na conta mensal desses ambientes. Não é theoretical. É o que aparece nos reports depois de trinta dias rodando.
Outro ponto que ninguém comenta muito: a separação de contas na AWS ou projetos no GCP para isolamento orçamentário. Parece óbvio, mas vi times com dezenas de contas espalhadas sem custo centralizado e sem forma de saber onde o dinheiro estava sendo gasto. A solução prática foi criar uma conta por ambiente principal, com tagging obrigatório de projeto e time. Isso permite ver exatamente quanto cada coisa custa sem precisar de auditoria manual. O detalhe que mais causa problemas é a migração de dados entre ambientes. Uma vez fiz deploy de staging com dados de produção truncados em 20%. O banco virou uma cópia reduzida com scripts de sanitização rodando durante a madrugada. O problema era que alguns serviços de QA quebraram porque os dados não tinham integridade referencial completa. A correção foi criar um pipeline de geração de dados sintéticos com regras de consistência, usando ferramentas como GoFullFill ou scripts customizados com Faker. Foi mais trabalho na implementação, mas economizou horas de troubleshooting toda semana.
Alternativas que poucos consideram
Containers com Kubernetes em modo spot ou preemptível podem reduzir custos em até 70% para workloads tolerantes a interrupção. Desenvolvimento e testes não são workloads críticos. Rodar no EKS com auto-scaling para zero quando ninguém está usando, e scale-up automático quando alguém precisa, é muito mais barato do que manter instâncias rodando o tempo todo. O lado ruim é que isso exige maturidade operacional. Se seu time não consegue fazer deploy automatizado e rollback rápido, o risco de ficar parado esperando recuperação de ambiente justifica manter máquinas ligadas. Eu recomendo essa abordagem apenas para times que já têm pipelines estabelecidos e documentação clara de troubleshooting.
👉 Clique no botão abaixo para saber mais sobre o assunto!
Uma alternativa mais simples para times menores é o uso de multi-tenancy por namespace em Kubernetes. Você compartilha o cluster entre ambientes, isolando recursos via namespaces e resource quotas. O custo é muito menor porque você não paga por infraestrutura duplicada. A limitação é que problemas de rede ou configurações equivocadas em um namespace podem afetar outros. Já vi um desenvolvedor configurar um limitador de CPU errado no namespace de QA e derrubar o serviço de logging do staging inteiro. A solução foi implementação de Pod Disruption Budgets e políticas de rede por namespace.
O que realmente economiza de verdade
Redução de instâncias ociosas é o fator número um. Na média, 30% a 40% dos recursos em ambientes não-produção ficam ociosos fora do horário de trabalho. Ferramentas como AWS Instance Scheduler, Cloud Autoscaler ou soluções de terceiros como Spot Instants conseguem automatizar isso. Configure políticas de shutdown às 19h e startup às 8h em ambiente de desenvolvimento. Para staging, adapte para o horário comercial do time. A economia varia conforme a região e o tipo de instância, mas é comum ver quedas de 50% a 70% na fatura mensal só com essa mudança. Desligar bancos de dados é ainda mais efetivo. Um RDS t3.medium custa aproximadamente US$ 35 por mês ligado. Desligando fora do horário de trabalho, o custo cai para cerca de US$ 12 a US$ 15. A diferença não é insignificante. E com snapshots automatizados, você recupera o ambiente em minutos quando precisa.
O uso de reserved instances ou savings plans para recursos que precisam ficar ligados 24/7, mesmo em ambientes não-críticos, também faz diferença. Um compromisso de um ano com uma instância pode reduzir o custo em 30% a 40%. O risco é ficar preso a uma capacidade que não usa mais se o projeto for descontinuado. A mitigação é revisar o uso trimestralmente e ajustar os compromissos.
Cenários onde a abordagem barata falha
Se você precisa de ambientes de teste com carga realista e simulação de picos, técnicas de scaling agressivo não resolvem. Nesse caso, o custo de ambiente de performance testing é inerente e não há como reduzi-lo drasticamente sem comprometer a validade dos resultados. A melhor alternativa é alugar ambientes sob demanda via marketplaces de cloud ou usar ferramentas de teste como k6 e Locust que permitem simular carga em infrastructures menores por períodos curtos. Outro caso é quando a governança corporativa exige isolamento total entre ambientes por compliance. Nesse cenário, a economia vem de outro lugar: otimização de tamanho de instância e revisão periódica de recursos não utilizados. A separação física não precisa significar superprovisionamento. Uma instância subdimensionada e bem configurada geralmente atende melhor do que uma superdimensionada por segurança.
A dica final que eu dou sem romantismo é simples: faça auditoria mensal de custos por ambiente. Anote o que está rodando, o que deveria estar rodando e o que é desperdício. A maioria dos gastos desnecessários em divisão de ambientes aparece claramente nessa análise. Comece pelos recursos que ninguém reclama quando desliga.
