Como Reduzir Custos de Infraestrutura na AWS em Até 60%

A fatura da AWS chegou e o número é maior do que você esperava — de novo. Aquele servidor "temporário" que foi criado há 6 meses ainda está rodando. Instâncias superdimensionadas consumindo recursos que nunca usam. Snapshots de EBS acumulados que ninguém lembra de apagar. Se essa situação é familiar, saiba que você não está sozinho: pesquisas indicam que empresas desperdiçam em média 30% a 35% dos seus gastos com cloud.

Para empresas brasileiras, o problema é ainda maior. A AWS cobra em dólar, e com a cotação acima de R$ 5,40, cada recurso mal dimensionado pesa o dobro no orçamento. Uma instância EC2 t3.medium que custa US$ 30/mês na verdade custa R$ 162 — e se você tem 10 delas rodando sem necessidade, são R$ 1.620/mês jogados fora.

A boa notícia é que reduzir custos na AWS não exige migrar para outro provedor ou sacrificar performance. Com as técnicas certas, é possível economizar 40% a 60% mantendo a mesma infraestrutura — ou até melhorando-a.

Erros comuns que inflam a conta

Antes de otimizar, vale entender onde o dinheiro está indo. Os erros mais frequentes que encontramos ao auditar contas AWS de empresas brasileiras são:

Instâncias superdimensionadas

O erro número 1. Na dúvida, a equipe escolhe uma instância maior "para garantir". Um servidor de aplicação que precisaria de 2 vCPU e 4GB roda em uma instância com 8 vCPU e 32GB. A utilização média de CPU fica em 10% e de memória em 25%.

Esse excesso custa caro. A diferença entre uma t3.medium (2 vCPU, 4GB) e uma m5.2xlarge (8 vCPU, 32GB) é de US$ 30/mês para US$ 280/mês — quase 10 vezes mais.

Recursos esquecidos

Elastic IPs não associados (cobram US$ 3,65/mês cada), load balancers sem targets, snapshots de EBS antigos, volumes EBS desanexados, ambientes de desenvolvimento ligados 24/7 (sendo usados 8h/dia). Cada item parece pequeno individualmente, mas a soma é significativa.

Sem reservas nem compromissos

Pagar tudo on-demand é como pagar diária de hotel todo dia durante um ano, quando um aluguel custaria a metade. Se você sabe que vai usar determinados recursos pelos próximos 12 meses, existe maneira muito mais barata de pagar por eles.

Transfer de dados excessivo

A AWS cobra pela saída de dados (data transfer out). APIs mal otimizadas que transferem dados desnecessários, imagens não comprimidas e falta de CDN inflam esse custo silenciosamente.

Armazenamento mal gerenciado

Dados no S3 Standard que poderiam estar em S3 Glacier. Logs acumulados sem lifecycle policy. Backups diários mantidos por anos quando semanais seriam suficientes.

Reserved Instances vs On-Demand vs Spot

A escolha do modelo de precificação é onde está a maior oportunidade de economia. A AWS oferece três modelos principais:

On-Demand

Pagamento por hora ou segundo, sem compromisso. Máxima flexibilidade, mas o preço mais alto.

Quando usar: ambientes de desenvolvimento, testes, workloads temporários e picos imprevisíveis de demanda.

Reserved Instances (RI)

Compromisso de uso por 1 ou 3 anos em troca de desconto significativo.

| Tipo de RI | Desconto vs On-Demand | Compromisso | |-----------|----------------------|-------------| | Standard 1 ano (sem upfront) | ~36% | Tipo e tamanho fixo | | Standard 1 ano (all upfront) | ~42% | Tipo e tamanho fixo | | Standard 3 anos (all upfront) | ~62% | Tipo e tamanho fixo | | Convertible 1 ano | ~31% | Pode trocar tipo | | Convertible 3 anos | ~54% | Pode trocar tipo |

Para uma instância m5.xlarge (4 vCPU, 16GB) na região us-east-1:

• On-Demand: US$ 140/mês (~R$ 756/mês)
• RI 1 ano (all upfront): US$ 81/mês (~R$ 437/mês) — economia de R$ 319/mês
• RI 3 anos (all upfront): US$ 53/mês (~R$ 286/mês) — economia de R$ 470/mês

Para 10 instâncias desse tamanho, a economia anual com RI de 3 anos é de R$ 56.400.

Savings Plans

Os Savings Plans são a evolução das Reserved Instances, oferecendo mais flexibilidade:

• Compute Savings Plan: desconto se aplica a qualquer instância EC2, Lambda e Fargate. Você se compromete com um valor por hora (ex: US$ 10/hora) por 1 ou 3 anos.
• EC2 Instance Savings Plan: desconto maior, mas restrito a uma família de instância e região.

A vantagem sobre RIs tradicionais é que Savings Plans permitem trocar de tipo de instância sem perder o desconto. Se você migrar de m5 para m6i, o desconto continua valendo.

Spot Instances

Capacidade ociosa da AWS oferecida com descontos de até 90%. O catch: a AWS pode interromper a instância com 2 minutos de aviso quando precisa da capacidade de volta.

Quando usar: workloads tolerantes a interrupção — processamento em batch, renderização, machine learning training, CI/CD pipelines, workers de fila.

Quando NÃO usar: bancos de dados, servidores web de produção, qualquer coisa que não pode ser interrompida.

Na prática, uma estratégia mista é o ideal:

• Base estável (servidores que rodam 24/7): Reserved Instances ou Savings Plans.
• Carga variável (auto-scaling): On-Demand para garantir disponibilidade.
• Workloads tolerantes: Spot Instances para máxima economia.

Right-sizing: usar o tamanho certo

Right-sizing é o processo de ajustar o tamanho das instâncias para corresponder ao uso real. É a técnica com maior impacto imediato porque não exige mudanças arquiteturais — apenas trocar o tipo de instância.

Como identificar instâncias superdimensionadas

O AWS Compute Optimizer analisa o uso histórico de CPU, memória e rede e recomenda o tipo de instância mais adequado. É gratuito e deveria ser a primeira ferramenta que você olha.

Regras práticas:

• CPU médio abaixo de 20%: a instância provavelmente pode ser reduzida em pelo menos um tamanho.
• CPU médio abaixo de 5%: a instância está grosseiramente superdimensionada. Considere reduzir 2-3 tamanhos.
• Memória usada abaixo de 40%: considere uma família com menos memória.

Exemplo prático

Uma empresa com 15 instâncias EC2 depois de uma análise de right-sizing:

| Instância original | Uso real | Recomendação | Economia mensal | |-------------------|----------|-------------|----------------| | m5.2xlarge (8 vCPU, 32GB) | 12% CPU, 20% RAM | m5.large (2 vCPU, 8GB) | US$ 210 | | c5.xlarge (4 vCPU, 8GB) | 8% CPU | t3.medium (2 vCPU, 4GB) | US$ 100 | | r5.xlarge (4 vCPU, 32GB) | 15% CPU, 35% RAM | r5.large (2 vCPU, 16GB) | US$ 130 |

No total, o right-sizing dessas 15 instâncias gerou economia de US$ 2.800/mês (R$ 15.120/mês) — sem impacto na performance.

Instâncias burstable (família T)

As instâncias T3 e T3a usam um modelo de créditos de CPU: acumulam créditos quando estão ociosas e gastam quando precisam de mais CPU. São ideais para workloads que têm picos curtos mas uso médio baixo.

Uma t3.large (2 vCPU, 8GB) custa US$ 60/mês, enquanto uma m5.large equivalente custa US$ 70/mês. Para servidores web com tráfego variável, a família T é frequentemente a opção mais econômica.

Otimização de armazenamento S3

O S3 é um dos serviços mais usados da AWS e também um dos mais mal otimizados. A chave é usar a classe de armazenamento correta para cada tipo de dado.

Classes de armazenamento

| Classe | Custo (GB/mês) | Caso de uso | |--------|---------------|-------------| | S3 Standard | US$ 0,023 | Dados acessados frequentemente | | S3 Intelligent-Tiering | US$ 0,023 + monitoramento | Dados com padrão de acesso imprevisível | | S3 Standard-IA | US$ 0,0125 | Dados acessados raramente (1x/mês) | | S3 One Zone-IA | US$ 0,01 | Dados raros, recriáveis | | S3 Glacier Instant | US$ 0,004 | Arquivo com acesso imediato | | S3 Glacier Flexible | US$ 0,0036 | Arquivo com acesso em horas | | S3 Glacier Deep Archive | US$ 0,00099 | Arquivo de longo prazo (acesso em 12h) |

A diferença entre S3 Standard e Glacier Deep Archive é de 23x. Para 1TB de dados que nunca são acessados (logs antigos, backups de compliance), a economia é de US$ 23/mês para US$ 0,99/mês por TB.

Lifecycle Policies

Configure lifecycle policies para mover dados automaticamente entre classes:

1. Dados novos → S3 Standard (primeiros 30 dias).
2. Após 30 dias sem acesso → S3 Standard-IA.
3. Após 90 dias → S3 Glacier Instant Retrieval.
4. Após 365 dias → S3 Glacier Deep Archive.
5. Após 7 anos → Delete (se não houver obrigação regulatória).

Para buckets de logs, configure exclusão automática após o período necessário. Manter 3 anos de logs de acesso no S3 Standard é um desperdício que vemos constantemente.

Auto Scaling: escale automaticamente

Auto Scaling permite que sua infraestrutura aumente quando a demanda sobe e diminua quando a demanda cai. Isso evita pagar por capacidade ociosa durante períodos de baixo tráfego.

Target Tracking Scaling

A política mais simples e eficiente: defina um target (ex: CPU média de 60%) e o Auto Scaling ajusta automaticamente o número de instâncias para manter esse nível.

Scheduled Scaling

Para padrões previsíveis (ex: e-commerce com pico à noite e final de semana), agende escalas para subir capacidade antes do pico e reduzir depois.

Economia com Auto Scaling

Uma empresa que mantém 10 instâncias fixas 24/7, mas só precisa de 10 durante o horário comercial e 3 durante a madrugada:

• Sem Auto Scaling: 10 instâncias × 24h = 240 instâncias-hora/dia.
• Com Auto Scaling: (10 × 12h) + (3 × 12h) = 156 instâncias-hora/dia.
• Economia: 35% na conta de EC2.

AWS Cost Explorer e Budgets

A AWS oferece ferramentas nativas para monitorar e controlar gastos:

Cost Explorer

Dashboard que mostra para onde seu dinheiro está indo. Permite filtrar por serviço, região, tag, conta e período. Os relatórios mais úteis:

• Custo por serviço: identifica quais serviços consomem mais.
• Custo por tag: se você tageia recursos por projeto/equipe, consegue saber quanto cada um gasta.
• Custo diário: identifica picos anormais rapidamente.
• Recomendações de RI: mostra quanto economizaria com Reserved Instances baseado no uso real.

Budgets e alertas

Configure alertas para ser notificado quando os gastos atingem limites definidos:

• Alerta em 80% do orçamento mensal: para ter tempo de agir.
• Alerta em 100%: para saber quando estourou.
• Alerta de anomalia: detecta gastos fora do padrão automaticamente.

Sem esses alertas, é comum descobrir o prejuízo só quando a fatura fecha — e a AWS não faz reembolso por recursos que você esqueceu ligados.

Serverless para redução de custos

Para workloads com uso intermitente, serverless (Lambda, API Gateway, DynamoDB) pode reduzir custos drasticamente porque você paga apenas pelo que usa, sem pagar por tempo ocioso.

Quando serverless faz sentido

• APIs com tráfego variável: uma API que recebe 100 requests/hora à noite e 10.000/hora durante o dia. Com EC2, você paga por capacidade para o pico. Com Lambda, paga apenas pelas execuções.
• Processamento em batch: processar uploads, gerar relatórios, enviar e-mails. Lambda executa só quando há trabalho.
• Webhooks e integrações: receber webhooks de terceiros e processá-los. Zero custo quando não há eventos.

Exemplo de economia

Uma API REST com média de 1 milhão de requests por mês:

• EC2 (t3.medium): US$ 30/mês + Load Balancer US$ 16/mês = US$ 46/mês (~R$ 248)
• Lambda + API Gateway: ~US$ 4/mês (~R$ 22)

Para APIs com tráfego moderado, a economia é de 90%+.

Mas atenção: para workloads com tráfego constante e alto (milhões de requests por hora), EC2 com Reserved Instances pode ser mais barato que Lambda. Faça as contas para o seu caso específico.

Checklist de otimização imediata

Para começar a economizar hoje:

1. Acesse o AWS Compute Optimizer e aplique as recomendações de right-sizing.
2. Identifique e exclua recursos esquecidos (Elastic IPs, volumes EBS não usados, snapshots antigos).
3. Configure lifecycle policies nos buckets S3.
4. Compre Savings Plans para instâncias que rodam 24/7.
5. Configure Auto Scaling em ambientes de produção com tráfego variável.
6. Configure AWS Budgets com alertas em 80% e 100% do orçamento.
7. Desligue ambientes de desenvolvimento fora do horário comercial.
8. Avalie migração de workloads pontuais para serverless.

Cada uma dessas ações pode ser implementada em horas, não semanas. E o impacto na próxima fatura será visível imediatamente. Se a otimização parece complexa ou se sua equipe não tem tempo para executar, um parceiro de tecnologia pode fazer a auditoria e implementar as mudanças em poucos dias — com retorno que se paga no primeiro mês.