Se a fatura cloud aumentou, a primeira pergunta não deveria ser “qual servidor posso desligar?”. Deveria ser: “que decisão arquitetural está sendo paga aqui e qual necessidade ela atende?”. A otimização de infraestrutura cloud consiste em alinhar capacidade, complexidade e operação ao momento real do produto. No case apresentado, essa revisão reduziu em 90% os custos com servidores cloud ao substituir uma estrutura com load balance e Kubernetes por uma solução mais enxuta baseada em Docker, CI/CD e GHCR. O percentual pertence àquele contexto específico; não é uma economia garantida para outras empresas.
Esse ponto é importante porque uma conta cloud registra mais do que consumo. Ela também revela escolhas acumuladas: componentes adotados para uma fase anterior, margens de segurança que nunca foram reavaliadas e ferramentas que passaram a existir sem uma demanda proporcional. A análise responsável não transforma Docker em vencedor nem Kubernetes em erro. Ela verifica se cada recurso continua justificável diante da carga, da disponibilidade esperada, da segurança, da equipe e do crescimento provável.
Leia a fatura como um registro de decisões
Uma fatura detalhada mostra itens cobrados, mas não explica sozinha por que eles foram contratados. Para encontrar desperdícios, é necessário reconstruir a relação entre recurso e finalidade. Uma instância pode atender à carga atual, manter uma margem para picos, sustentar redundância ou simplesmente ter sido herdada de uma configuração antiga. Esses quatro casos aparecem misturados quando a infraestrutura cresce por adições sucessivas.
O primeiro trabalho, portanto, é criar um inventário: servidores, serviços, volumes, balanceadores, ambientes, imagens, rotinas de backup e mecanismos de monitoramento. Depois, associe cada item a uma demanda concreta, a um requisito de negócio ou a um risco deliberadamente aceito. O que não tiver uma justificativa clara não deve ser removido imediatamente; deve entrar na lista de investigação. Essa distinção evita que uma suspeita de excesso seja tratada como autorização para cortar.
A documentação do AWS Well-Architected Framework recomenda modelar custos e selecionar tipo, tamanho e quantidade de recursos com base no uso e em métricas. A orientação ajuda a estabelecer um método, mas não prescreve um desenho universal. Uma arquitetura econômica é aquela que entrega o nível necessário de serviço com o menor desperdício compatível com os riscos que a empresa decidiu aceitar.
O que o resultado de 90% permite concluir
As informações fornecidas descrevem uma estrutura anterior que utilizava load balance e Kubernetes sem necessidade proporcional à aplicação. Na revisão, o desenho foi substituído por uma abordagem baseada em Docker, CI/CD e GHCR. Docker empacota e executa a aplicação em contêineres; CI/CD organiza a integração e a entrega de mudanças; o GitHub Container Registry, ou GHCR, armazena e distribui imagens de contêiner. O resultado informado foi uma redução de 90% nos custos com servidores cloud.
A conclusão profissional é mais específica do que “a nova tecnologia é melhor”. O case sugere que existia uma diferença entre a capacidade e a coordenação oferecidas pela estrutura anterior e aquilo que a aplicação efetivamente precisava naquele estágio. A economia veio do redesenho da capacidade e da operação. Não há, no material fornecido, dados sobre cliente, datas, valores absolutos, tráfego, quantidade de servidores, disponibilidade, latência ou período de medição. Por isso, o resultado deve ser apresentado como relato informado no briefing, não como estudo independente ou média de mercado.
A infraestrutura precisa acompanhar o momento real do produto. Complexidade só se justifica quando resolve um problema que a aplicação de fato tem.
— Síntese do case informado
Superdimensionamento não é apenas recurso ocioso
O superdimensionamento ocorre quando a capacidade provisionada excede de forma relevante e persistente a demanda e os requisitos do sistema. O custo direto é o mais evidente: pagar por processamento, memória ou quantidade de instâncias que raramente são utilizados. Há, porém, um custo menos visível. Mais componentes significam mais configurações para compreender, mais alertas para acompanhar, mais permissões para administrar e mais caminhos possíveis para uma falha.
Essa complexidade pode ser adequada quando existe uma necessidade concreta de distribuir carga, escalar componentes de maneira independente, suportar falhas ou operar múltiplos serviços. Também pode ser desproporcional quando a aplicação tem carga previsível, poucos componentes e uma equipe que precisa reduzir a superfície operacional. O tamanho da empresa, por si só, não decide a questão. O que importa é a combinação entre demanda, risco, competências disponíveis e evolução prevista.
| Pergunta de decisão | Estrutura com load balance e Kubernetes | Estrutura enxuta com Docker, CI/CD e GHCR |
|---|---|---|
| Qual problema pode resolver? | Coordenação de contêineres, réplicas, implantação e cenários que exigem escala ou operação distribuída. | Empacotamento consistente, entrega repetível e distribuição centralizada de imagens para uma topologia mais simples. |
| Que esforço adiciona? | Mais configuração, monitoramento, manutenção e conhecimento especializado, conforme o desenho adotado. | Menor superfície de coordenação, sem eliminar a necessidade de observabilidade, segurança e recuperação. |
| Quando pode ser proporcional? | Quando requisitos de escala, disponibilidade ou independência entre serviços justificam a complexidade. | Quando a carga e a topologia são mais previsíveis e a simplicidade atende aos requisitos atuais. |
| Qual é o risco de uma decisão precipitada? | Manter capacidade e operação acima do necessário apenas por hábito ou expectativa de crescimento. | Remover redundância, controles ou capacidade de recuperação sem demonstrar que deixaram de ser necessários. |
Defina os limites antes de mexer na capacidade
Antes de reduzir servidores, réplicas ou componentes, registre o comportamento que precisa continuar funcionando. Levante carga observada, horários de pico, desempenho esperado, disponibilidade mínima, rotinas de backup, requisitos de segurança, frequência de deploy e crescimento já contratado ou sustentado por evidências. Se esses dados não existem, a etapa mais urgente não é a redução: é criar uma linha de base.
A equipe também precisa avaliar a operação da solução proposta. É possível publicar uma mudança sem procedimento manual frágil? Uma versão anterior pode ser restaurada? Os erros serão percebidos rapidamente? As credenciais estão protegidas? Existe alguém capaz de investigar um incidente fora do caminho habitual? Docker, CI/CD e GHCR podem apoiar uma operação previsível, mas a presença dessas ferramentas não garante, por si só, controle ou disponibilidade.
O crescimento deve ser tratado com a mesma disciplina. Escalabilidade não significa começar com o arranjo mais complexo possível. Significa saber como aumentar a capacidade quando a demanda justificar a mudança. Uma arquitetura enxuta pode ser adequada hoje, desde que seus limites sejam conhecidos e que a equipe consiga evoluí-la sem reconstruir tudo às pressas.
Quando a economia apenas muda de lugar
Cortar um recurso sem compreender sua função pode reduzir a fatura e aumentar o custo de indisponibilidade, recuperação ou manutenção. Um deploy pode voltar a depender de uma única pessoa; a recuperação pode ficar mais lenta; uma redundância importante pode desaparecer; ou um controle de segurança pode ser substituído por uma rotina informal. Nesse caso, não houve otimização estrutural, mas transferência de risco.
Também é preciso separar economia recorrente de redução pontual. Uma alteração pode diminuir a cobrança no primeiro mês, mas criar mais trabalho operacional ou exigir ferramentas adicionais depois. O acompanhamento deve observar custo, erros, desempenho, disponibilidade, segurança e esforço da equipe. Uma fatura menor só representa melhoria quando o serviço continua adequado ao negócio.
Faça da revisão um experimento reversível
Eu começaria com um inventário dos recursos, custos e dependências, seguido por uma linha de base de uso e comportamento. Em vez de declarar que a arquitetura antiga está errada, formularia uma hipótese: determinado componente pode ser simplificado porque sua função não é sustentada pela carga ou por um requisito atual. A hipótese precisa indicar o que será alterado, quais limites devem ser preservados e que evidência fará a equipe interromper a mudança.
A transição deve ser controlada, com observabilidade suficiente para detectar desvios e uma versão de retorno preparada. O objetivo não é provar que uma decisão anterior foi um erro. É reduzir a capacidade ou a complexidade somente quando os dados indicarem que isso é seguro. A reversibilidade protege o negócio contra conclusões precipitadas e permite aprender com o comportamento real do sistema.
Depois da mudança, marque uma nova revisão. O produto pode conquistar usuários, incorporar novas jornadas ou passar a exigir outra disponibilidade. O que era margem excessiva em um estágio pode se tornar proteção necessária em outro. A otimização de infraestrutura cloud funciona melhor como ciclo de observação, decisão e ajuste do que como uma intervenção única motivada por uma fatura alta.
A melhor arquitetura é a que pode ser explicada
O case de 90% é útil porque desloca a conversa da preferência tecnológica para a justificativa do investimento. A pergunta não é se Kubernetes, load balance ou Docker são modernos, simples ou populares. A pergunta é se o desenho atual pode ser explicado por uma demanda observada, um requisito de disponibilidade, uma necessidade de segurança, um risco aceito e uma capacidade operacional compatível com a equipe.
Não há evidência fornecida para afirmar que a mesma redução ocorrerá em qualquer projeto, nem para tratar a arquitetura anterior como inadequada fora do cenário descrito. Há, sim, um aprendizado aplicável: quando a conta cresce, investigue a capacidade provisionada e as decisões que a sustentam antes de contratar mais recursos ou remover componentes. Reduzir custo com responsabilidade significa preservar desempenho, segurança, recuperação e possibilidade de evolução.
