Como estimar o custo de servidores da AWS / Google Cloud antes de iniciar o desenvolvimento
Guia para arquitetos e CTOs calcularem o custo de computação, armazenamento e largura de banda para evitar surpresas financeiras na fatura da nuvem.
Começar um projeto de tecnologia sem estimar os custos de infraestrutura de nuvem é o equivalente a construir um prédio sem orçamento para materiais. No modelo atual de desenvolvimento ágil, onde novos serviços são criados com poucos cliques, a falta de visibilidade financeira sobre a nuvem costuma gerar surpresas desagradáveis no fim do mês: faturas de milhares de dólares na AWS ou no Google Cloud que inviabilizam o caixa da startup.
A estimativa de custos em nuvem (frequentemente associada à cultura de FinOps) é a prática de planejar, dimensionar e calcular antecipadamente os custos operacionais de recursos computacionais, bancos de dados, armazenamento e tráfego de dados com base na projeção de uso real da aplicação e no comportamento do usuário final, garantindo a viabilidade financeira da arquitetura proposta antes do início da codificação.
Dominar essa disciplina exige que o arquiteto técnico mapeie quais recursos o software consome e monte um modelo matemático de faturamento.
Os 4 Grandes Componentes do Faturamento em Nuvem
Para estimar os custos na AWS ou GCP, você precisa decompor sua arquitetura nos quatro pilares básicos de precificação:
- Computação (Compute): Cobrado com base na quantidade de CPUs virtuais (vCPUs) e memória RAM por hora de execução. (Exemplo: AWS EC2, AWS ECS Fargate, GCP Compute Engine, GCP Cloud Run).
- Banco de Dados (Databases): Cobrado pela capacidade do hardware alocado (instâncias RDS) ou pelo volume de leituras e escritas realizadas (serviços serverless como DynamoDB ou Firestore).
- Armazenamento (Storage): Cobrado pela quantidade de gigabytes (GB) armazenados mensalmente, além de taxas adicionais para leitura/escrita desses arquivos. (Exemplo: AWS S3, GCP Cloud Storage).
- Transferência de Rede (Data Transfer Out - Egress): O custo oculto mais perigoso da nuvem. Enquanto os provedores geralmente cobram zero para os dados entrarem (ingress) em sua nuvem, eles cobram taxas por GB para qualquer dado que saia (egress) dos seus servidores para a internet ou para outras regiões geográficas.
Comparativo: Equivalentes e Modelos de Faturamento
A tabela abaixo compara os principais componentes de infraestrutura entre a Amazon Web Services (AWS) e o Google Cloud Platform (GCP):
| Categoria | Serviço AWS | Serviço GCP | Modelo de Precificação Principal |
|---|---|---|---|
| Computação Standard | EC2 | Compute Engine | Segundos/Horas de uso da VM ativa. |
| Computação Serverless | Lambda / ECS Fargate | Cloud Run / Cloud Functions | Tempo de execução exato consumido em milissegundos. |
| Banco de Dados SQL | RDS | Cloud SQL | Instância alocada (db.t3.medium) + Armazenamento. |
| Banco de Dados NoSQL | DynamoDB | Firestore | Volume de requisições de leitura/escrita de dados + armazenamento. |
| Armazenamento de Objetos | S3 | Cloud Storage | Gigabytes armazenados por mês + solicitações API. |
| Monitoramento de Custos | AWS Budgets | GCP Billing Budgets | Alertas de custos com base em limites de faturamento diário/mensal. |
Template Prático de Modelagem de Custos (SaaS 10k MAU)
Para simular o custo mensal de um produto SaaS com 10.000 Usuários Ativos Mensais (MAU), desenhe uma planilha de custos preliminar dividida por demandas de tráfego projetado:
| Componente Técnico | Recurso Alocado | Volume Estimado | Custo Estimado Unitário (AWS) | Custo Total Mensal |
|---|---|---|---|---|
| API Backend | 2x Instâncias ECS Fargate (0.5 vCPU, 1GB RAM) | 730 horas/mês cada | R$ 0,016 por vCPU/Hora | ~ R$ 120,00 ($24 USD) |
| Banco de Dados | 1x AWS RDS PostgreSQL (db.t3.medium) | 730 horas/mês + 50GB SSD | RDS: $0.0416/hr + Storage | ~ R$ 250,00 ($50 USD) |
| Arquivos estáticos | AWS S3 (Armazenamento de mídia de clientes) | 100 GB Armazenados + 10k GETs | $0.023 por GB | ~ R$ 15,00 ($3 USD) |
| Largura de Banda | Data Transfer Out (Imagens + Respostas da API) | 300 GB transferidos para internet | $0.09 por GB transferido | ~ R$ 135,00 ($27 USD) |
| Total Estimado | ~ R$ 520,00 / mês |
Implementação Prática: Configurando Alertas de Orçamento com Terraform
A melhor forma de evitar faturas indesejadas é automatizar a criação de travas financeiras na infraestrutura. O código em Terraform abaixo demonstra como criar um AWS Budget Alert corporativo. Se o custo mensal previsto ultrapassar o limite de $100 dólares, um alerta de e-mail é disparado imediatamente para o CTO.
# Definição do Provedor de Cloud AWS
provider "aws" {
region = "us-east-1"
}
# Recurso de Orçamento da AWS
resource "aws_budgets_budget" "custo_mensal_limite" {
name = "alert-custo-limite-mensal-saas"
budget_type = "COST"
limit_amount = "100" # Limite máximo de custos em dólares (USD)
limit_unit = "USD"
time_unit = "MONTHLY" # Ciclo de faturamento recorrente mensal
# Notificações estruturadas com base no consumo real e previsto
notification {
comparison_operator = "GREATER_THAN"
threshold = 80 # Alerta enviado quando atingir 80% do valor limite
threshold_type = "PERCENTAGE"
notification_type = "ACTUAL"
subscriber_email_addresses = ["[email protected]"]
}
notification {
comparison_operator = "GREATER_THAN"
threshold = 100 # Alerta preventivo se a projeção mensal estimar estouro
threshold_type = "PERCENTAGE"
notification_type = "FORECASTED"
subscriber_email_addresses = ["[email protected]", "[email protected]"]
}
tags = {
Ambiente = "Producao"
FinOps = "True"
DynamicCost = "Alert"
}
}
Boas Práticas para Reduzir Custos no Dia Zero
- Use CDNs para Egress Cost Protection: Proteja sua infraestrutura configurando o Cloudflare na frente da sua aplicação. O Cloudflare oferece transferência de dados (egress) gratuita, o que pode cortar até 80% da sua fatura de tráfego da AWS.
- Configuração de Auto-Scaling Conservador: Defina regras de escalabilidade com limites máximos rigorosos. É preferível que sua aplicação fique temporariamente lenta sob ataque de robôs do que escalar infinitamente e gerar uma fatura de R$ 50.000 da noite para o dia.
- Desligamento de Ambientes de Staging: Configure scripts simples para desligar instâncias de bancos de dados e APIs de testes e staging durante os finais de semana e noites. Ambientes não produtivos não precisam ficar ligados 24 horas por dia.
Conclusão: Arquitetura Orientada a Custos
A arquitetura de software moderna não se limita à estabilidade do código; ela inclui a eficiência de custos como um requisito não-funcional de primeira classe.
Ao adotar práticas de estimativa antes de escrever a primeira linha de código, projetar limites de tráfego de rede inteligentes e automatizar alertas de orçamento via infraestrutura como código (Terraform), você protege a saúde financeira da sua organização e garante a estabilidade de longo prazo do produto digital.