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

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.

1Coloque 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.

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.

2Use 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.

3Pare 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%.

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.

4Suba 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

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.

5Escolha 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:

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.