Otimização de custos na AWS: um playbook de FinOps para times de SaaS

A maioria das empresas de SaaS não tem um problema de fatura da AWS. Tem um problema de responsabilidade que aparece na fatura da AWS. Instâncias criadas para um teste em março continuam rodando em outubro, um banco de staging tem o mesmo tamanho do de produção, e ninguém sabe dizer qual cliente ou funcionalidade pesa mais na conta. Otimizar custos na AWS tem menos a ver com truques espertos e mais com enxergar para onde vai o dinheiro, eliminar o desperdício óbvio e criar um hábito para que ele não volte. Este playbook percorre as três etapas, nessa ordem, com as ferramentas da AWS que fazem o trabalho.

O que FinOps significa para um time pequeno de SaaS

FinOps é o nome desse hábito. A FinOps Foundation o define como “uma estrutura operacional e uma prática cultural que maximiza o valor de negócio da tecnologia, viabiliza decisões rápidas baseadas em dados e cria responsabilidade financeira por meio da colaboração entre as áreas de engenharia, finanças e negócios.”

Em uma grande empresa, isso significa um time dedicado de FinOps. Em uma empresa de SaaS com 20 pessoas, costuma significar um engenheiro, o CTO e quem paga as faturas combinando três coisas: como a fatura deve ser, quem responde por cada parte dela e quando alguém vai olhar. A otimização de custos na nuvem funciona do mesmo jeito em qualquer provedor, mas as ferramentas abaixo são específicas da AWS.

A AWS expressa a mesma ideia no pilar de otimização de custos do seu Well-Architected Framework. As três etapas a seguir são uma versão desse pilar dimensionada para um time sem departamento de FinOps.

Etapa 1: ganhe visibilidade antes de cortar qualquer coisa

Não dá para otimizar o que não se consegue atribuir a alguém. Comece por aqui, mesmo que você já suspeite de onde está o desperdício.

Ative o Cost Explorer e use-o toda semana. O AWS Cost Explorer mostra os gastos por serviço, conta, região e tipo de uso, e é onde a maioria das outras ferramentas de custo exibe seus dados. Agrupe por tipo de uso, não só por serviço. O “EC2-Other” esconde volumes EBS, snapshots, cobranças de NAT gateway e transferência de dados, que muitas vezes são as surpresas.

Aplique tags nos recursos e depois ative as tags. Tags como team, service, environment e customer permitem dividir a fatura pelo que importa para o seu negócio. Um detalhe pega muitos times: uma tag em um recurso não faz nada pela cobrança até você ativá-la como tag de alocação de custos no console de Billing and Cost Management, e as tags ativadas podem levar até 24 horas para aparecer. Torne as tags obrigatórias nos seus módulos de Terraform ou CloudFormation, em vez de pedir que as pessoas se lembrem delas.

Exporte os dados detalhados. Quando o Cost Explorer não tem granularidade suficiente, o AWS Data Exports entrega o Cost and Usage Report 2.0 (CUR 2.0) em um bucket do S3, com detalhe por linha de item. A AWS chama o CUR 2.0 de forma recomendada de receber dados detalhados de custo e uso. É o que você precisa para calcular o custo por cliente ou o custo por requisição, que é o número que um negócio de SaaS realmente deveria acompanhar.

Separe os ambientes em contas. Se produção, staging e desenvolvimento dividem uma única conta da AWS, toda conversa sobre custo começa com uma discussão sobre quais recursos pertencem a quê. Contas separadas no AWS Organizations tornam essa divisão automática.

Etapa 2: aproveite os ganhos rápidos

Com a visibilidade resolvida, a primeira rodada de economia costuma vir dos mesmos poucos lugares.

Comece pelo AWS Cost Optimization Hub

A própria AWS aponta muitos deles: o Cost Optimization Hub reúne recomendações de rightsizing, recursos ociosos, Savings Plans e Reserved Instances entre contas e regiões, e as de rightsizing e de recursos ociosos vêm do AWS Compute Optimizer. Trate essas recomendações como uma lista de partida, não como uma lista de tarefas. Uma recomendação de reduzir uma instância não sabe que ela roda um processo em lote de fechamento de mês. Depois de ativar, leva cerca de 24 horas para popular, então ligue cedo.

Recursos ociosos e superdimensionados

Procure instâncias com uso de CPU e memória constantemente baixo, load balancers sem destinos, volumes EBS desanexados e bancos de dados de ambientes não produtivos rodando o dia inteiro. Ambientes de desenvolvimento e staging que ninguém usa à noite ou nos fins de semana podem ser desligados por agendamento. Vale fazer o rightsizing com cuidado: mude uma coisa, acompanhe a latência e as taxas de erro por alguns dias e só então passe para a próxima.

Armazenamento

• Migre os volumes gp2 para gp3. A AWS afirma que os volumes gp3 têm um preço por GiB 20% menor que o gp2, com uma base de 3.000 IOPS e 125 MiB/s incluída. A mudança pode ser feita no lugar com Elastic Volumes, sem parar a instância.
• Escolha a classe de armazenamento certa no S3. Para dados com acesso imprevisível, o S3 Intelligent-Tiering move os objetos para camadas mais baratas depois de 30 e 90 dias sem acesso, por uma pequena taxa de monitoramento. Objetos com menos de 128 KB não são movidos entre camadas, então ele ajuda menos em buckets cheios de arquivos minúsculos. Para dados com acesso previsível, como logs que você guarda por um ano, regras de ciclo de vida para uma classe específica são mais simples.
• Limpe os snapshots. Snapshots antigos de EBS e snapshots manuais de RDS se acumulam em silêncio. Apague o que você não precisa e, para snapshots que precisam ser mantidos por 90 dias ou mais, o EBS Snapshots Archive oferece um custo de armazenamento até 75% menor, ao preço de uma restauração mais lenta.

Dados no NAT gateway

Os NAT gateways cobram por hora e por gigabyte de dados processados, além da transferência de dados normal. Sub-redes privadas que baixam imagens de contêiner, enviam logs ou leem do S3 por um NAT gateway podem gerar um item grande e fácil de passar despercebido. Os VPC endpoints do tipo gateway para S3 e DynamoDB não têm cobrança por hora nem por processamento de dados, então rotear esse tráfego por eles costuma ser a mudança de rede mais barata que você vai fazer. Os endpoints de interface para outros serviços custam dinheiro, então compare-os com o tráfego de NAT que eles substituiriam.

Savings Plans vs. Reserved Instances

Quando o uso estiver bem dimensionado, assuma o compromisso com a base que você sabe que vai rodar. Se assumir antes do rightsizing, você trava o desperdício.

Os Savings Plans trocam o compromisso de gasto por hora, por um ou três anos, por tarifas menores. A AWS oferece quatro tipos:

• Os Compute Savings Plans, com até 66% de desconto sobre On-Demand, valem para famílias, tamanhos e regiões de instâncias EC2 e também para Fargate e Lambda.
• Os EC2 Instance Savings Plans, com até 72% de desconto, exigem uma família de instância específica em uma região específica.
• Os Database Savings Plans, com até 35% de desconto, cobrem Aurora, RDS, DynamoDB, ElastiCache e vários outros serviços de banco de dados.
• Os SageMaker AI Savings Plans cobrem o uso de instâncias do SageMaker.

As Reserved Instances ainda existem para serviços como RDS, ElastiCache, OpenSearch e Redshift, e prendem você a uma configuração mais específica. Para um time de SaaS em crescimento, cuja arquitetura vai mudar, a flexibilidade costuma valer mais que os últimos pontos de desconto, o que aponta primeiro para os Compute Savings Plans. O Cost Explorer gera recomendações de Savings Plans a partir do seu uso real, e o AWS Budgets pode avisar quando a utilização ou a cobertura cair, que é a forma de perceber um compromisso de que você não precisa mais.

Etapa 3: faça disso um processo, não um projeto

Uma faxina de custos sem processo dura cerca de um trimestre. Estas boas práticas de otimização de custos na AWS mantêm a economia.

Dê um dono a cada dólar. Cada conta, serviço ou valor de tag deve corresponder a uma pessoa ou time que responda por ele. Quando a conta do serviço de busca dobrar, alguém específico recebe a pergunta.

Defina orçamentos e alertas de previsão. O AWS Budgets pode avisar sobre o gasto real e sobre o gasto previsto, antes que o dinheiro acabe, e pode disparar ações como aplicar uma política de IAM que bloqueia novos recursos em uma conta. Defina um orçamento por conta e por serviço principal, enviado ao responsável, não a uma caixa compartilhada que ninguém lê.

Ative a detecção de anomalias. O AWS Cost Anomaly Detection usa machine learning para sinalizar gastos incomuns por serviço, conta, tag de alocação de custos ou categoria de custo, e pode alertar por e-mail, SNS ou Slack. A AWS observa no seu FAQ que a detecção depende dos dados do Cost Explorer, com até 24 horas de latência, então ela pega um job descontrolado no segundo dia, não no segundo minuto. Ainda assim, é muito melhor do que descobrir na fatura.

Revise todo mês. Trinta minutos por mês com os responsáveis pelos custos bastam para a maioria dos times pequenos: o que mudou, por quê e o que vem a seguir. Acompanhe uma métrica unitária, como o custo de infraestrutura por cliente ativo, para que o crescimento não esconda ineficiência.

Ferramentas de otimização de custos na AWS: o que usar e quando

Necessidade	Ferramenta da AWS
Ver para onde vai o dinheiro	Cost Explorer
Atribuir gastos a times, serviços, clientes	Tags de alocação de custos, AWS Organizations
Detalhe por linha e custos unitários	Data Exports (CUR 2.0)
Encontrar rightsizing e recursos ociosos	Compute Optimizer, Cost Optimization Hub
Assumir compromisso com o uso de base	Savings Plans, Reserved Instances
Pegar gasto excessivo cedo	AWS Budgets, Cost Anomaly Detection

Nenhuma ferramenta de otimização de custos da AWS cobre tudo isso, e é por isso que a tabela associa necessidades a ferramentas. As plataformas de custo de terceiros acrescentam visões multicloud, alocação de custos de Kubernetes e relatórios mais bonitos. Vale avaliá-las quando as ferramentas nativas deixarem de responder às suas perguntas, não antes.

Onde entra um agente

A maior parte desse trabalho não é difícil. É só fácil de adiar, porque nenhuma tarefa isolada é urgente e as pessoas que poderiam fazê-la estão ocupadas entregando produto. É aí que a automação se justifica: alguém precisa ler os dados de custo todo dia, notar o volume desanexado e a frota de gp2 e colocar uma recomendação clara na frente de uma pessoa que possa decidir.

Na Webera, esse é o trabalho do Optimizer, um dos nossos nove agentes de IA. Ele analisa os gastos na nuvem, identifica desperdício, recomenda rightsizing e capacidade reservada, monta dashboards de custo e alertas de orçamento e acompanha a economia ao longo do tempo. O Navigator, o agente de rede, olha os custos de rede e de transferência de dados, incluindo o tráfego do NAT gateway. Os agentes propõem; os engenheiros decidem. Desativar uma instância ou comprar um compromisso de três anos é uma decisão que uma pessoa toma junto com o seu time, não algo que um agente faz sozinho.

O trabalho com custos também se cruza com a confiabilidade. Fazer rightsizing de forma agressiva demais causa incidentes, e esse é um dos motivos para ele ficar com o time que carrega o pager. Nossos posts sobre site reliability engineering vs. DevOps e gestão de incidentes para SaaS tratam desse lado. Para uma visão mais ampla do que um time externo assume, veja o que uma assinatura de DevOps gerenciado substitui.

Perguntas frequentes

Quais são os cinco pilares da otimização de custos na AWS?

A rigor, Cost Optimization é um dos seis pilares do AWS Well-Architected Framework. Dentro desse pilar, a AWS agrupa suas orientações em cinco áreas: praticar o Cloud Financial Management, consciência de gastos e uso, recursos com bom custo-benefício, gerenciar a oferta e a demanda de recursos e otimizar ao longo do tempo. Esses cinco são o que as pessoas costumam querer dizer com os cinco pilares da otimização de custos na AWS.

A otimização de custos na AWS é gratuita?

Em parte. O Cost Optimization Hub não tem cobrança adicional, e o Cost Explorer, o Budgets e o Cost Anomaly Detection ficam no console de Billing and Cost Management, mas confira o preço de cada um antes de depender dele em escala. O que custa dinheiro é o tempo para agir sobre o que for encontrado e compromissos como os Savings Plans, que reduzem as tarifas em troca de um compromisso de gasto de um ou três anos.

Por que a AWS custa tanto?

Para a maioria dos times de SaaS, a fatura é alta por causa de um desperdício que ninguém assume, e não por causa das tarifas da AWS: instâncias de teste esquecidas, staging do tamanho de produção, volumes desanexados, snapshots antigos e cobranças de dados do NAT gateway. Sem tags e sem um responsável por cada parte da fatura, esses custos crescem em silêncio.

Como otimizar o custo do EC2?

Comece fazendo o rightsizing das instâncias com uso de CPU e memória constantemente baixo, usando as descobertas do Compute Optimizer como lista de partida, e agende o desligamento das instâncias não produtivas à noite e nos fins de semana. Migre os volumes gp2 para gp3 e limpe os snapshots antigos. Quando o uso estiver bem dimensionado, cubra a base estável com Compute Savings Plans ou EC2 Instance Savings Plans.

Coloque o FinOps no prato de alguém

A Webera é uma assinatura de DevOps para times de SaaS na AWS: engenheiros seniores e nove agentes de IA, com monitoramento 24/7 e resposta a incidentes e solicitações ilimitadas em todos os planos. O Pro custa US$ 4.999 por mês, o Elite US$ 9.999 e o Platform US$ 14.999, todos com mínimo de três meses e, depois, mês a mês. Todo o código e toda a configuração são seus.

Se a sua fatura da AWS não para de crescer e ninguém responde por ela, compare os planos e veja o que seria preciso para transformar a revisão de custos em um hábito semanal, em vez de uma correria anual.