Economia sem mudar a arquitetura
A maior parte da economia possível em uma conta AWS não exige reescrever nada. Ela vem de ajustes de configuração em serviços que quase toda aplicação usa, como S3, Lambda, EC2, rede, bancos de dados e logs. Este artigo reúne os ganhos mais simples de aplicar, serviço por serviço, em ordem de esforço crescente, com os preços e as regras oficiais da AWS como referência. Os valores citados são de lista e podem variar conforme a região, então vale conferir a página de preços do serviço antes de estimar o seu caso.
Visibilidade de custo
Nenhuma otimização funciona sem saber onde está o gasto. O AWS Cost Explorer mostra a fatura por serviço, conta e tag, e é o primeiro lugar para descobrir quais serviços pesam de verdade. O AWS Budgets avisa quando o gasto previsto passa de um limite definido, e o AWS Cost Anomaly Detection usa machine learning para identificar gastos fora do padrão e apontar a causa, o que pega um recurso esquecido ligado antes de ele virar surpresa no fim do mês.
Duas práticas completam a base. As tags de alocação de custo permitem separar o gasto por projeto, ambiente ou cliente, e o AWS Compute Optimizer recomenda ajustes de tamanho para instâncias EC2, funções Lambda e volumes EBS com base no uso real. O pilar de custos do Well-Architected Framework descreve essa mesma disciplina de forma mais ampla.
O que ajustar em cada um
Amazon S3
O S3 Intelligent-Tiering move os objetos entre camadas conforme o padrão de acesso, sem taxa de recuperação. Objetos sem acesso por 30 dias vão para o tier infrequente, com economia de até 40%, e depois de 90 dias vão para o Archive Instant Access, com até 68% de economia e acesso ainda em milissegundos. Objetos menores que 128 KB não entram na movimentação automática, e existe uma pequena taxa mensal de monitoramento por objeto.
O segundo ajuste é uma regra de lifecycle para abortar uploads multipart incompletos. As partes de um upload que nunca foi concluído continuam armazenadas e cobradas até alguém removê-las, e a AWS recomenda essa regra justamente para controlar o custo. Sete dias é um bom ponto de partida.
AWS Lambda
Funções em arquitetura arm64, baseada em Graviton2, têm a duração cobrada 20% mais barata que em x86, com até 34% de melhor relação preço e performance segundo a AWS. A troca é uma única propriedade na função, mas dependências compiladas para x86 precisam ser reconstruídas, então vale testar antes.
O segundo ajuste é a memória. No Lambda a CPU cresce junto com a memória, então uma função com pouca memória pode demorar tanto que fica mais cara do que com mais memória. A ferramenta de código aberto AWS Lambda Power Tuning executa a função em várias configurações e mostra qual entrega o menor custo.
Amazon EC2 e Amazon EBS
Ambientes de desenvolvimento e homologação raramente precisam rodar à noite e nos fins de semana. Uma instância parada deixa de cobrar horas de computação, embora os volumes continuem cobrados, e agendar esse desligamento é uma das economias mais diretas que existem.
No EBS, a migração de gp2 para gp3 reduz o custo do armazenamento. Nos exemplos da página de preços do EBS, o gp3 custa US$ 0,08 por GB-mês contra US$ 0,10 do gp2, ou seja, 20% menos, e a troca é feita no próprio volume, sem desanexar nem criar snapshot. Também vale procurar volumes sem anexo e snapshots antigos, que seguem cobrados mesmo depois de a instância ter sido apagada.
Para cargas estáveis, o Compute Savings Plans oferece até 66% de desconto sobre o preço sob demanda, aplicado a EC2, Fargate e Lambda em troca de um compromisso de uso por hora em 1 ou 3 anos. E as instâncias baseadas em Graviton custam até 20% menos que as equivalentes x86.
Amazon VPC e Load Balancers
O NAT Gateway cobra por hora e por volume de dados processado, e nos exemplos da página de preços da VPC os dois valores são de US$ 0,045. Quando recursos em subnets privadas acessam o S3 ou o DynamoDB pelo NAT, todo esse tráfego é cobrado por GB. Os Gateway VPC endpoints de S3 e DynamoDB não têm cobrança por hora nem por processamento de dados, e desviam esse tráfego do NAT.
Cada endereço IPv4 público também é cobrado a US$ 0,005 por hora, em uso ou ocioso, o que dá cerca de US$ 3,65 por mês por endereço. Vale listar os Elastic IPs sem uso. O mesmo raciocínio vale para Load Balancers esquecidos, já que o Application Load Balancer cobra US$ 0,0225 por hora enquanto estiver rodando, com ou sem tráfego, cerca de US$ 16 por mês cada um.
Amazon RDS
Bancos de desenvolvimento podem ser parados temporariamente, o que elimina a cobrança das horas de instância. Há duas regras importantes. A AWS inicia a instância novamente sozinha depois de 7 dias, e o armazenamento provisionado e os backups continuam cobrados durante a parada. Por isso o desligamento funciona melhor quando agendado, e não como ação única.
Os demais ajustes seguem a lógica do EC2, usar armazenamento gp3, considerar instâncias Graviton, que estão disponíveis no RDS, e revisar a retenção de snapshots manuais, que não expiram sozinhos.
Amazon DynamoDB
Em tabelas grandes com acesso raro, a classe Standard-IA reduz o custo de armazenamento em 60%, de US$ 0,25 para US$ 0,10 por GB-mês nos exemplos da AWS, ao custo de requisições cerca de 25% mais caras. Ela compensa quando o armazenamento é o maior item da fatura da tabela.
A AWS recomenda o modo sob demanda na maioria dos cenários, e o modo provisionado para cargas estáveis e previsíveis, em que dá para estimar a capacidade. Completa o conjunto o TTL, que expira automaticamente itens antigos sem consumir capacidade de escrita para apagá-los.
Amazon CloudWatch Logs
O padrão de um log group é nunca expirar. Como o Lambda cria um log group por função automaticamente, os logs se acumulam indefinidamente e o armazenamento cresce a cada mês. Definir uma retenção, por exemplo 30 ou 90 dias conforme a necessidade de investigação e de auditoria, resolve o problema. Para logs que precisam ficar mais tempo, o caminho é exportar para o S3 e aplicar as regras de lifecycle. O artigo sobre Observabilidade na AWS detalha os preços de ingestão e armazenamento de logs.
Em aplicações com IA generativa, o consumo de tokens também entra na conta. O artigo sobre Otimização de Tokens na AWS trata desse tema.
Comandos e configurações
1. Migrar um volume de gp2 para gp3
CLIaws ec2 modify-volume \
--volume-id vol-0abc123def456789 \
--volume-type gp32. Limpar uploads incompletos e ativar o Intelligent-Tiering no S3
JSON{
"Rules": [
{
"ID": "limpar-uploads-incompletos",
"Status": "Enabled",
"Filter": {},
"AbortIncompleteMultipartUpload": { "DaysAfterInitiation": 7 }
},
{
"ID": "intelligent-tiering",
"Status": "Enabled",
"Filter": {},
"Transitions": [
{ "Days": 0, "StorageClass": "INTELLIGENT_TIERING" }
]
}
]
}aws s3api put-bucket-lifecycle-configuration \
--bucket meu-bucket \
--lifecycle-configuration file://lifecycle.json3. Rodar uma função Lambda em arm64
CloudFormationMinhaFuncao:
Type: AWS::Lambda::Function
Properties:
Runtime: python3.12
Architectures:
- arm64
Handler: app.handler
Role: !GetAtt FuncaoRole.Arn
Code:
S3Bucket: !Ref CodigoBucket
S3Key: funcao.zip4. Criar um Gateway endpoint do S3 na VPC
CloudFormationS3GatewayEndpoint:
Type: AWS::EC2::VPCEndpoint
Properties:
VpcId: !Ref Vpc
ServiceName: !Sub "com.amazonaws.${AWS::Region}.s3"
VpcEndpointType: Gateway
RouteTableIds:
- !Ref PrivateRouteTable5. Parar um banco de desenvolvimento e mudar a classe de uma tabela DynamoDB
CLIaws rds stop-db-instance --db-instance-identifier meu-banco-dev
aws dynamodb update-table \
--table-name MinhaTabela \
--table-class STANDARD_INFREQUENT_ACCESS6. Definir retenção nos logs
CLIaws logs put-retention-policy \
--log-group-name /aws/lambda/minha-funcao \
--retention-in-days 30Prática, economia e esforço
| Serviço | Prática | Economia | Esforço |
|---|---|---|---|
| CloudWatch Logs | Definir retenção por log group | Evita crescimento indefinido do armazenamento | Baixo |
| S3 | Abortar uploads multipart incompletos | Remove armazenamento que não serve a ninguém | Baixo |
| EBS | Migrar gp2 para gp3 | 20% menos por GB | Baixo |
| VPC | Gateway endpoints de S3 e DynamoDB | Tira o tráfego dos serviços do NAT, que cobra por GB | Baixo |
| VPC e ELB | Remover IPv4 públicos e load balancers ociosos | US$ 3,65 por IP e cerca de US$ 16 por ALB ao mês | Baixo |
| EC2 e RDS | Desligar dev e homologação fora do horário | Elimina as horas de instância paradas | Baixo a médio |
| S3 | Intelligent-Tiering | Até 40% a 68% em dados sem acesso | Baixo |
| DynamoDB | Classe Standard-IA em tabelas grandes e raras | 60% menos no armazenamento | Baixo |
| Lambda | arm64 e ajuste de memória | 20% menos na duração | Médio |
| EC2 | Graviton e Compute Savings Plans | Até 20% e até 66% | Médio |
Uma ordem prática
Comece pela visibilidade, ligando o Cost Anomaly Detection e as tags de custo. Em seguida, aplique os ajustes que não alteram comportamento nenhum e podem ser feitos em minutos, retenção de logs, uploads incompletos, gp3 e Gateway endpoints. Depois cuide dos recursos ociosos, IPs, load balancers, volumes e snapshots órfãos, e do desligamento agendado de ambientes de desenvolvimento.
Por último vêm as mudanças que exigem teste, arm64 no Lambda, Graviton e a classe Standard-IA no DynamoDB. O Savings Plans fica por fim de propósito, porque o compromisso deve ser calculado sobre o uso já otimizado. Contratar antes disso significa se comprometer com um gasto que a própria otimização reduziria.
Além da otimização técnica
Reduzir o consumo é metade da conta. A outra metade é como a fatura chega até a empresa. Ter um parceiro AWS responsável pelo faturamento muda isso sem custo adicional, e o pacote de Faturamento e Gestão Financeira AWS da Lascasas Consulting reúne esses benefícios. A fatura passa a ser emitida em reais, com nota fiscal, sem IOF e sem exposição à flutuação cambial, o que torna o orçamento previsível. O prazo para pagar a conta AWS chega a 50 dias após o fechamento do mês, o que ajuda no fluxo de caixa.
Há também o lado técnico. O pacote inclui passagem de conhecimento sobre os serviços, workshops hands-on e apoio arquitetural em projetos, e nas faixas de maior consumo entra um relatório FinOps customizado. Esse relatório é feito por especialistas que olham a conta com a visão deste artigo, e aponta onde estão os desperdícios daquele ambiente específico, em vez de uma lista genérica de boas práticas.
Resumo e recomendações
Reduzir a conta AWS raramente exige uma grande iniciativa. Na maioria dos ambientes, uma lista curta de ajustes de configuração, aplicados com método e em ordem de risco, já devolve uma parte relevante do gasto.
O mais importante é transformar isso em rotina. Recursos ociosos e logs sem retenção voltam a aparecer a cada projeto novo, então a visibilidade de custo precisa continuar ligada e alguém precisa olhar os alertas.