Cloud: custos, deploy, lock-in e como decidir sem escolher no escuro
Entenda custos Cloud além da fatura: compute, storage, egress, ociosidade, serviços gerenciados, deploy, lock-in e critérios para escolher abstrações e provedores sem ranking universal.
Cloud permite criar infraestrutura em minutos.
Essa velocidade resolve um problema antigo — e cria outro.
Quando comprar servidor deixa de ser uma decisão de semanas e passa a ser um clique, uma API ou um pipeline, o custo deixa de estar concentrado num momento de compra e passa a acompanhar o comportamento do sistema.
Uma máquina ligada custa.
Storage acumulado custa.
Tráfego pode custar.
Backups, snapshots, bancos gerenciados e observabilidade podem custar.
Ambientes esquecidos continuam existindo até alguém destruí-los.
Por isso “pagar pelo que usa” não significa automaticamente “pagar pouco”.
O modelo mental mais útil é:
Cloud transforma custo em uma variável operacional que precisa de feedback contínuo.
Isso conecta finanças, arquitetura e operação.
Também muda a forma de pensar deploy e lock-in.
Se cada escolha de serviço altera quem opera determinada camada, quanto custa mantê-la e quão fácil seria substituí-la, então custo não é uma planilha separada da arquitetura.
É parte dela.
Custo Cloud não começa na calculadora
Calculadoras de preço são úteis.
Mas a primeira pergunta deveria ser:
qual resultado o sistema precisa entregar e qual capacidade realmente sustenta esse resultado?
Sem essa pergunta, é fácil otimizar a coisa errada.
Você pode reduzir a classe de uma VM e piorar latência.
Pode remover redundância e aumentar risco de indisponibilidade.
Pode trocar serviço gerenciado por software autogerenciado e economizar na fatura — enquanto transfere horas de patching, backup e incidentes para a equipe.
Os Well-Architected Frameworks dos grandes provedores tratam cost optimization como disciplina contínua justamente porque custo precisa ser avaliado junto de confiabilidade, segurança, performance e operação.
Uma arquitetura barata que não cumpre os requisitos não está otimizada.
Está subdimensionada.
Pay-as-you-go muda a natureza do desperdício
Em infraestrutura própria, desperdício costuma aparecer como hardware comprado e pouco utilizado.
Em Cloud, desperdício pode ser invisível e recorrente.
Exemplos:
- VM superdimensionada;
- ambiente de teste ligado 24 horas;
- volume sem owner;
- snapshot antigo;
- banco criado para prova e nunca removido;
- storage em classe inadequada;
- recurso duplicado após migração;
- logging excessivo sem retenção definida;
- IP, gateway ou serviço gerenciado esquecido.
O problema não é apenas o valor unitário.
É a combinação de:
recurso × quantidade × tempo × padrão de uso
Se qualquer dimensão cresce sem feedback, a fatura acompanha.
Compute: tempo e capacidade continuam importando
Compute é frequentemente cobrado com base em duração, capacidade ou unidades de execução.
Mesmo quando o produto comercial do provedor esconde detalhes, o princípio permanece:
- mais CPU/memória tende a custar mais;
- mais tempo ativo tende a custar mais;
- capacidade reservada ou comprometida pode alterar tarifa;
- workloads elásticos podem variar custo conforme demanda.
Isso cria um trade-off.
Provisionar “para o pior caso” reduz risco de falta de capacidade e pode criar ociosidade permanente.
Provisionar agressivamente para a média reduz custo e pode deixar pouco headroom.
Autoscaling tenta ajustar essa relação.
Mas autoscaling não é uma máquina de economizar dinheiro.
Se o sinal de scaling é ruim, você pode escalar demais.
Se o workload cresce por bug, o autoscaler pode transformar um problema lógico em consumo maior.
Se dependências não escalam, adicionar compute pode aumentar custo sem aumentar throughput.
A pergunta continua sendo:
qual recurso limita o resultado e quanta margem operacional precisamos?
Storage custa mais que espaço
Storage não é apenas “GB por mês”.
O modelo pode envolver:
- volume armazenado;
- classe/tier;
- operações;
- requisições;
- leitura;
- recuperação;
- replicação;
- transferência;
- retenção;
- snapshots e backups.
Por isso dois sistemas com o mesmo volume de dados podem ter custos muito diferentes.
Um arquivo acessado raramente pode se beneficiar de classe de storage diferente de um objeto lido milhares de vezes por hora.
Logs sem política de retenção crescem para sempre.
Backups redundantes podem ocupar mais do que a base original.
Replicar dados para múltiplas regiões melhora determinados cenários de resiliência e também aumenta consumo.
A disciplina é relacionar dado a necessidade:
- frequência de acesso;
- requisito de recuperação;
- durabilidade;
- localização;
- performance;
- retenção.
Guardar tudo na camada “mais rápida” para sempre costuma ser simples — e caro.
Egress: o custo que o diagrama não mostra
Fluxos de dados também importam.
Quando uma arquitetura distribui componentes entre regiões, provedores ou Internet, o caminho da informação pode gerar custo.
Nem todo tráfego é tarifado da mesma forma, e as regras mudam conforme provedor, região e serviço.
Por isso este artigo não fixa preços.
O princípio durável é:
movimentar dados tem arquitetura e economia.
Um sistema pode parecer barato olhando apenas compute e storage e ficar caro por transferência.
Exemplos:
- processar numa região e armazenar em outra;
- replicar grandes volumes;
- servir arquivos diretamente da origem sem CDN quando uma camada de distribuição faria sentido;
- exportar telemetria em volume muito alto;
- chamar frequentemente serviço em outra região;
- mover dados entre clouds.
Egress precisa aparecer na revisão arquitetural antes de virar surpresa na fatura.
Serviço gerenciado: caro comparado a quê?
Um banco gerenciado pode parecer mais caro que uma VM.
Essa comparação é incompleta.
A alternativa não é apenas:
R$ X de banco gerenciado
versus
R$ Y de VM
A alternativa real pode incluir:
VM
+ patching
+ backup
+ monitoramento
+ failover
+ upgrade
+ incidentes
+ conhecimento especializado
+ tempo de engenharia
Se o serviço gerenciado elimina trabalho relevante, uma fatura maior pode representar custo total menor.
O inverso também existe.
Um serviço premium para um workload simples pode adicionar preço e lock-in sem comprar capacidade útil.
O critério é:
qual trabalho operacional estou deixando de executar e quanto esse trabalho vale?
Essa pergunta é mais madura que “managed service é caro”.
Custo técnico e custo humano fazem parte da mesma decisão
Azure Well-Architected enfatiza que decisões de custo devem considerar tecnologia, automação, treinamento, operação e mudança.
Esse ponto é importante porque equipes tendem a medir apenas a invoice.
Imagine duas opções.
Opção A
Infraestrutura mais barata, porém:
- exige pessoa especialista;
- upgrades manuais;
- plantão;
- recovery complexo;
- tooling próprio.
Opção B
Serviço mais caro, porém:
- atualizações gerenciadas;
- HA pronta;
- menos manutenção;
- suporte e integração melhores.
A escolha depende de escala, risco e competência da equipe.
Custo é também uma função do sistema sociotécnico.
Budget não é limite mágico
AWS, Google Cloud e Azure oferecem mecanismos de orçamento, alertas e cost management.
Eles são essenciais para feedback.
Mas budget não deve ser confundido com interruptor universal que impede gasto.
Em várias plataformas, budgets são principalmente mecanismos de monitoramento e notificação; automações adicionais podem reagir aos eventos.
O valor está em tornar desvio visível.
Você quer perceber:
- gasto acelerando;
- serviço novo consumindo acima do esperado;
- ambiente que deveria estar desligado;
- mudança de padrão após deploy;
- projeto sem owner;
- custo unitário piorando.
Budget sem alguém olhando é apenas mais um dashboard.
Custo precisa de owner
AWS chama atenção para ownership em Cloud Financial Management.
Isso não significa que toda empresa precisa de uma equipe FinOps formal.
Significa que alguém precisa ser responsável por responder:
- quem revisa gasto?;
- quem investiga anomalias?;
- quem decide trade-offs?;
- quem remove recursos abandonados?;
- quem define budgets?;
- quem acompanha custo por produto ou ambiente?
Quando custo é “responsabilidade de todos”, frequentemente não é responsabilidade de ninguém.
Unidade econômica é melhor que fatura total
A fatura pode subir porque o negócio cresceu.
Isso não é automaticamente ruim.
O sinal mais útil pode ser uma unidade:
- custo por usuário ativo;
- custo por pedido;
- custo por transação;
- custo por job;
- custo por GB processado;
- custo por cliente;
- custo por resultado.
Se gasto dobra e volume triplica, eficiência pode ter melhorado.
Se gasto fica estável e receita cai, custo unitário piorou.
A pergunta certa é:
quanto custa entregar uma unidade de valor?
Deploy também tem custo operacional
Deploy em Cloud não é apenas copiar artefato.
É uma transição controlada entre estados do sistema.
Ela envolve:
- artefato;
- configuração;
- runtime;
- secrets;
- infraestrutura;
- migrations;
- health checks;
- observabilidade;
- rollback ou roll-forward.
Cloud adiciona abstrações para automatizar isso.
VMs podem receber imagens imutáveis.
Containers podem ser substituídos por novas revisions.
Plataformas gerenciadas podem oferecer rollout e tráfego gradual.
Funções podem ter versões e aliases.
O princípio comum é:
tornar o deploy repetível e verificável.
Imutabilidade reduz diferenças invisíveis
Quando você altera servidores manualmente ao longo de meses, cada host pode acumular estado diferente.
Uma abordagem mais imutável tenta criar um novo artefato e substituir instâncias, em vez de editar produção indefinidamente.
Isso ajuda porque:
- build vira evidência;
- versão é identificável;
- rollback tende a ser mais claro;
- ambientes ficam mais reproduzíveis;
- drift diminui.
Nem todo sistema precisa de uma plataforma sofisticada.
Mas quanto maior a escala, mais caro fica não saber exatamente o que está rodando.
CI/CD continua sendo o mecanismo de entrega
Cloud não substitui CI/CD.
Ela fornece destinos e primitives.
Um pipeline saudável ainda precisa:
commit
↓
build
↓
test
↓
artefato
↓
deploy
↓
validação
↓
observabilidade
A diferença é que o destino pode ser VM, container, função, PaaS ou serviço gerenciado.
O contrato de entrega deve sobreviver à mudança de plataforma.
Rollback não apaga efeitos externos
Rollback de artefato pode restaurar versão anterior do código.
Não desfaz automaticamente:
- migration destrutiva;
- mensagem publicada;
- email enviado;
- dado transformado;
- chamada externa;
- recurso deletado;
- side effect financeiro.
Isso vale em Kubernetes, VM, serverless ou PaaS.
Cloud oferece mecanismos de versionamento e rollout.
A aplicação continua responsável por mudanças compatíveis e estratégia de recuperação.
Roll-forward pode ser mais seguro
Em alguns incidentes, voltar versão é a melhor opção.
Em outros, o estado já mudou e corrigir com uma nova versão é mais seguro.
Isso é roll-forward.
O importante é que deploy não dependa de “editar produção até voltar”.
O sistema precisa ter uma resposta previsível a erro de release.
Lock-in não é binário
“Tem lock-in” e “não tem lock-in” são simplificações ruins.
Dependência de plataforma existe em várias dimensões.
Lock-in de API
A aplicação usa uma API exclusiva.
Lock-in de dados
Mover o volume é difícil, lento ou caro.
Lock-in operacional
A equipe domina tooling e processos daquele provedor.
Lock-in de arquitetura
O design depende de um modelo que não possui equivalente simples em outro lugar.
Lock-in comercial
Descontos, contratos ou compromissos influenciam saída.
Lock-in de competência
Treinamento, certificação e experiência concentram conhecimento.
Cada dimensão possui custo de saída diferente.
Usar serviço proprietário pode ser racional
Evitar toda dependência proprietária pode custar caro.
Imagine que um serviço gerenciado reduz seis meses de engenharia para uma semana.
Talvez a dependência seja uma ótima decisão.
O erro não é usar algo proprietário.
É não saber qual dependência está aceitando.
Uma decisão madura registra:
- benefício;
- alternativa;
- custo de saída;
- criticidade;
- dados envolvidos;
- possibilidade de exportação;
- plano proporcional ao risco.
Não precisamos construir portabilidade que nunca será usada.
Precisamos evitar dependência inconsciente.
Portabilidade também tem custo
Arquitetura totalmente portátil tende a usar abstrações mais comuns e operar mais camadas diretamente.
Isso pode aumentar:
- trabalho;
- manutenção;
- complexidade;
- tempo de entrega.
Portabilidade é uma opção.
Opção tem preço.
Se o negócio nunca pretende mover determinado workload, gastar muito para preservar mobilidade perfeita pode ser desperdício.
Se o componente é crítico, regulado ou estratégico, a opção de saída pode valer muito.
Não existe percentual universal.
Multi-cloud não é antídoto automático para lock-in
Executar tudo em três clouds pode parecer máxima liberdade.
Na prática, pode criar:
- três IAMs;
- três redes;
- três modelos de billing;
- três observabilidades;
- três pipelines;
- competências duplicadas;
- menor uso de serviços avançados de cada plataforma.
Multi-cloud faz sentido quando existe requisito real.
Não como reflexo contra lock-in.
Às vezes o melhor hedge é muito mais simples:
- dados exportáveis;
- contratos claros;
- formatos abertos;
- camada de aplicação bem separada;
- backups independentes;
- documentação de saída.
Como escolher entre AWS, Google Cloud e Azure
Não existe vencedor universal.
A decisão depende de contexto.
Perguntas úteis:
Ecossistema
A empresa já usa Microsoft/Entra/Windows intensamente?
Possui stack de dados integrada a Google?
Já opera AWS em escala?
Serviços necessários
Qual provedor possui a capacidade específica na região desejada?
O serviço é maduro?
Região e compliance
Existe região adequada?
Residência de dados atende requisitos?
Equipe
Qual plataforma a equipe sabe operar?
Quanto custa aprender outra?
Contratos
Existe compromisso comercial ou desconto relevante?
Integração
Quais sistemas existentes precisam conversar?
Portabilidade
Qual dependência proprietária estamos dispostos a aceitar?
A escolha deveria resultar dessas respostas, não de um ranking de YouTube.
Comparar conceitos antes de marcas
A matriz que acompanha este artigo mapeia conceitos entre os três provedores.
Ela não diz que dois produtos são equivalentes em todos os detalhes.
Serve para traduzir vocabulário.
Se você entende:
- compute;
- object storage;
- managed relational database;
- virtual network;
- IAM;
- load balancing;
- functions;
- managed containers;
- secrets;
- monitoring;
então aprender outro provedor vira um problema de mapear contrato, escopo e limites — não reaprender Cloud do zero.
Um checklist para decidir arquitetura Cloud
Antes de aprovar um desenho, responda:
Valor
- qual problema o recurso resolve?
- qual capacidade compra?
Custo
- qual principal driver de consumo?
- há egress relevante?
- existe ociosidade?
- qual custo por unidade de valor?
Operação
- quem mantém?
- qual camada o provedor assume?
- como monitora?
- como recupera?
Deploy
- artefato é reproduzível?
- mudança é automatizada?
- como valida?
- como volta ou corrige?
Lock-in
- qual dimensão de dependência existe?
- qual custo de saída?
- vale o benefício atual?
Governança
- há owner?
- budget?
- alertas?
- tags/metadados?
- revisão periódica?
Se essas perguntas têm resposta, você está tomando uma decisão arquitetural.
Se a resposta é “porque esse serviço parece legal”, ainda está navegando catálogo.
Cloud madura é feedback
A ideia que conecta todo o ciclo é feedback.
Responsabilidade compartilhada exige saber quem opera o quê.
Regiões e rede exigem observar disponibilidade e tráfego.
Compute e storage exigem medir capacidade e uso.
IAM exige auditoria.
Custos exigem acompanhar consumo e valor.
Deploy exige validar mudança.
Lock-in exige revisar dependências ao longo do tempo.
Cloud não é um conjunto de produtos.
É um modelo operacional em que infraestrutura se tornou programável, mensurável e substituível em diferentes graus.
A vantagem aparece quando a equipe usa essa flexibilidade com disciplina.
O objetivo final não é “usar mais cloud”.
É:
usar a abstração certa para entregar o resultado certo, com custo, risco e operação que o negócio consegue sustentar.