# Reduzir custo na AWS: 5 ajustes sem refatorar a aplicação

> Cinco ajustes para pagar menos na AWS sem mexer no código: CloudFront, Graviton, desligar fora do horário, EC2 de geração nova e região mais barata.

- Autor: Henrylle Maia, consultor AWS
- Publicado em: 2026-10-15
- Assuntos: Custos, Rede
- URL: https://pages.formacaoaws.com.br/blog/reduzir-custo-na-aws-sem-refactor/
- Aula de origem: "5 estratégias validadas para redução de custo na AWS sem precisar de refactor no seu projeto" (https://www.youtube.com/watch?v=eEjx_XfaARg)

Dá para pagar bem menos na AWS sem refatorar a aplicação. Aqui estão os cinco ajustes que eu coloco na largada (CloudFront, arquitetura ARM, desligar ambiente fora do horário, geração mais nova de EC2 e região mais barata), com os números que usei para comparar.

## Antes de culpar a nuvem, olhe a conta

Vi matérias de empresas que querem sair de uma realidade multi-cloud e voltar para o on-premise por causa de custo. No cliente que eu ajudo com consultoria, eu vejo o caminho inverso: lá usamos a AWS massivamente. No último mês ajudei uma conta desse cliente a reduzir o custo em torno de 40%. Em outro projeto do mesmo cliente, a redução foi em torno de 53%.

Duas das estratégias que usei lá estão nesta lista: processadores Graviton no banco e uma região mais barata. Existem muitas outras, mas o ponto é este: o problema não está na nuvem que você escolheu, e sim em saber explorar o que ela oferece.

Nenhuma das cinco é reserva ou Savings Plans. São recursos básicos que não geram compromisso com a sua conta.

## Passo 1: coloque o CloudFront na frente da aplicação

Usar CDN é entregar a aplicação na borda, mais perto do usuário. Na AWS, é colocar o Amazon CloudFront na frente da aplicação, que está, por exemplo, numa EC2 da sua conta. O CloudFront tem servidores pelo mundo todo e entrega tanto a parte estática quanto a dinâmica.

O ganho aparece na transferência de dados para a internet (data transfer out):

- **EC2 em São Paulo:** US$ 0,15 por GB.
- **CloudFront, América do Sul:** US$ 0,11 por GB. Só nessa diferença são aproximadamente 30% a menos.
- **Franquia grátis:** a EC2 dá 100 GB de transferência de saída por mês. O CloudFront dá 1 TB.

![Preço do CloudFront por GB de saída para a internet: US$ 0,110 nos primeiros 10 TB na América do Sul](https://pages.formacaoaws.com.br/blog/assets/posts/reduzir-custo-na-aws-sem-refactor/cloudfront-america-do-sul.webp)

![Nível sempre gratuito do CloudFront: 1 TB de transferência de dados de saída por mês](https://pages.formacaoaws.com.br/blog/assets/posts/reduzir-custo-na-aws-sem-refactor/cloudfront-nivel-gratuito.webp)

Há um extra: o Savings Bundle do CloudFront, que economiza mais 30%. Eu só citei esse recurso, sem mostrar a configuração, então confira o nome e as condições na página oficial do CloudFront antes de contar com ele.

## Passo 2: use a arquitetura ARM (Graviton)

A AWS tem a arquitetura ARM com os processadores Graviton. Nas instâncias de propósito geral, a família T, as que terminam em `g` usam ARM: T4G em vez de T3.

Comparando a T3 micro (US$ 0,0104 por hora) com a T4G micro (US$ 0,0084): a T4G é mais rápida e fica em torno de 20% mais barata. Pode ser que sua aplicação não precise de nenhuma adequação para rodar nela, e ainda fique mais rápida.

Isso vale para EC2 e para RDS. No cliente, eu usei Graviton no banco.

> **Importante:** eu disse "pode ser" que a aplicação não precise de adequação. Não é garantia de que a sua rode em ARM sem ajuste.

## Passo 3: pare os recursos fora do horário comercial

O exemplo da aula: uma conta com duas instâncias de produção e uma de homologação. Quem acessa a homologação é gente de dentro, como o gerente de produto e quem faz os testes, no horário comercial. Digamos das 8h às 18h, 10 horas por dia.

De segunda a sexta, são 50 horas. Com o servidor ligado 24 horas por dia, são 168 horas por semana. Só com essa estratégia, o tempo ligado cai cerca de 70%.

![Servidor ligado das 8h às 18h: 10 horas por dia, 50 horas na semana, contra 168 horas ligado 24 horas, cerca de 70% menos](https://pages.formacaoaws.com.br/blog/assets/posts/reduzir-custo-na-aws-sem-refactor/desenho-horas-ligadas.svg)

Dá para automatizar de duas formas:

- **Auto Scaling** para parar as EC2.
- **Lambda**, criando uma automação, para parar o cluster Aurora ou uma instância RDS, por exemplo com PostgreSQL sem ser Aurora.

Os 70% valem para os ambientes nesse escopo, como a homologação do exemplo, não para a conta inteira.

## Passo 4: suba a geração da instância EC2

Na família T, o número depois do T é a geração. Quem ainda abre a conta e encontra T2 está gastando à toa. Os preços por hora da micro, que comparei numa tabela de instâncias (Linux, sob demanda, região da Virgínia do Norte):

| Instância | Preço por hora |
|---|---|
| T2 micro | US$ 0,0116 |
| T3 micro | US$ 0,0104 |
| T3A micro | US$ 0,0094 |
| T4G micro | US$ 0,0084 |

![Tabela de instâncias micro da família T, Linux sob demanda: de US$ 0,0116 por hora na T2 a US$ 0,0084 na T4G](https://pages.formacaoaws.com.br/blog/assets/posts/reduzir-custo-na-aws-sem-refactor/instancias-t2-t3-t4g.webp)

De T2 para T3, sem mudar arquitetura nem nada, são cerca de 10%. Até a T4G, em ARM, a redução chega a cerca de 30%. Além de pagar menos, você leva mais poder computacional.

## Passo 5: escolha uma região mais barata

Se a aplicação está em São Paulo só para ficar mais rápida para o cliente, você está gastando com nuvem sem necessidade. Dá para migrá-la para a Virgínia ou para Ohio, regiões mais baratas, e fazer a saída 100% pelo CDN.

São Paulo deixa mesmo mais rápido, desde que você não use CDN. Com o CDN na frente, o custo cai ainda mais e a aplicação fica mais rápida. O caminho fica assim:

**Fluxo:** Usuário (acessa a aplicação) → Amazon CloudFront (entrega pela borda) → Amazon EC2 (em região mais barata)

> **Importante:** isso vale se nada obriga você a ficar na região mais cara. Se há algo que obrigue, esse ajuste não é para você.

## Sobre os valores

Todos os preços acima são os que apareceram na aula, em junho de 2023, e podem ter mudado. Antes de calcular a economia da sua conta, confira nas páginas de preços da AWS (Amazon EC2, Amazon CloudFront) os valores atuais da sua região.

## Checklist

- Coloque o CloudFront na frente da aplicação e compare a transferência de saída da EC2 com a do CDN.
- Veja se a aplicação pode rodar numa instância ARM (T4G, ou Graviton no RDS).
- Liste os ambientes que só são usados em horário comercial e automatize a parada deles com Auto Scaling ou Lambda.
- Procure instâncias de geração antiga, como T2, e troque para a mais nova.
- Pergunte se existe motivo real para a aplicação estar na região mais cara. Se não, avalie a Virgínia ou Ohio com o CDN na frente.
- Refaça as contas com os preços atuais da página oficial.

Dá para aplicar os cinco em conjunto e trazer uma grande redução, sem redesenhar a aplicação. Se você pensa em trocar de nuvem por custo, comece por eles.