Como otimizar custos em nuvem pública

A otimização de custos em nuvem pública é uma disciplina essencial para organizações que buscam maximizar o retorno sobre investimento em infraestrutura digital. Com modelos de faturamento complexos e recursos elásticos, é fácil incorrer em gastos desnecessários sem uma estratégia clara. Este artigo aborda as principais práticas para reduzir custos em provedores como AWS, Azure e Google Cloud, com exemplos práticos de implementação.

1. Compreendendo os modelos de precificação e faturamento

1.1. Diferenças entre modelos on-demand, reservados e spot

Os provedores de nuvem oferecem três modelos principais de precificação:

  • On-demand: Pagamento por hora/segundo sem compromisso de longo prazo. Ideal para cargas imprevisíveis, mas com custo mais alto.
  • Instâncias reservadas (RI): Contrato de 1 ou 3 anos com desconto de 30% a 60% em troca de compromisso.
  • Instâncias spot: Capacidade ociosa com descontos de até 90%, mas com risco de interrupção.
Exemplo de comparação de custos (AWS EC2 t3.medium, us-east-1):
- On-demand: $0.0416/hora
- RI 1 ano (padrão): $0.0250/hora (40% de economia)
- Spot (média): $0.0125/hora (70% de economia)

1.2. Identificando os principais componentes de custo

Os três maiores geradores de custo são:

  • Computação: VMs, containers e funções serverless
  • Armazenamento: Discos, buckets e backups
  • Rede: Transferência de dados entre regiões e saída para internet

1.3. Ferramentas nativas de análise de faturamento

# Exemplo de consulta no AWS Cost Explorer via CLI
aws ce get-cost-and-usage \
  --time-period Start=2024-01-01,End=2024-01-31 \
  --granularity MONTHLY \
  --metrics "BlendedCost" "UnblendedCost" \
  --group-by Type=DIMENSION,Key=SERVICE
  • AWS Cost Explorer: Visualização e análise de gastos por serviço
  • Azure Cost Management: Orçamentos e recomendações de economia
  • GCP Cost Tools: Relatórios detalhados e alertas

2. Direito ao dimensionamento (rightsizing) de recursos

2.1. Monitoramento contínuo de utilização

O rightsizing consiste em ajustar recursos ao real necessário. Utilize métricas de CPU, memória e I/O por 14 a 30 dias.

# Comando para verificar utilização média de CPU no Azure (via CLI)
az monitor metrics list \
  --resource /subscriptions/.../virtualMachines/minha-vm \
  --metric "Percentage CPU" \
  --interval PT1H \
  --aggregation average \
  --query "value[].timeseries[].data[].average"

2.2. Estratégias para reduzir instâncias superdimensionadas

  • Identifique VMs com utilização de CPU abaixo de 20% por mais de 30 dias
  • Reduza para famílias menores (ex: de m5.large para t3.medium)
  • Consolide workloads em menos instâncias

2.3. Uso de instâncias burstable e famílias otimizadas

Instâncias burstable (como AWS T3, Azure B-series) acumulam créditos de CPU para picos. Ideais para servidores web com tráfego variável.

# Recomendação: substituir m5.large (2 vCPU, 8 GB) por t3.medium (2 vCPU, 4 GB)
# Economia estimada: 30-40% para cargas com picos esporádicos

3. Implementação de instâncias reservadas e savings plans

3.1. Como calcular o ponto de equilíbrio

Calcule o break-even point comparando custo total de RI vs on-demand para o período do contrato.

# Cálculo simplificado para AWS t3.large
On-demand anual: $0.0832/hora * 8760 horas = $728.83
RI 1 ano padrão: $0.0499/hora * 8760 horas = $437.12
Economia: $291.71 (40%)
Break-even: aproximadamente 5 meses de uso contínuo

3.2. Savings Plans vs Reserved Instances

  • Savings Plans: Mais flexíveis, aplicam-se a qualquer instância na mesma família
  • Reserved Instances: Específicas para uma configuração, maior desconto

3.3. Estratégias para cargas sazonais

Para cargas previsíveis (ex: Black Friday), combine:
- RI para base (60% da capacidade)
- On-demand para picos (30%)
- Spot para processamento batch (10%)

4. Automação para desligamento de recursos ociosos

4.1. Políticas de schedule para ambientes de desenvolvimento

Ambientes de dev/test frequentemente ficam ociosos 70% do tempo.

# Exemplo de schedule com AWS Lambda (Python)
import boto3
def lambda_handler(event, context):
    ec2 = boto3.client('ec2')
    # Desliga instâncias com tag "Environment=dev" entre 20h e 6h
    instances = ec2.describe_instances(
        Filters=[{'Name': 'tag:Environment', 'Values': ['dev']}]
    )
    for reservation in instances['Reservations']:
        for instance in reservation['Instances']:
            if instance['State']['Name'] == 'running':
                ec2.stop_instances(InstanceIds=[instance['InstanceId']])

4.2. Uso de tags e políticas de governança

Tags como Environment, Project, Owner permitem identificar e automatizar ações.

# Política de governança no Azure Policy
{
  "if": {
    "field": "tags['AutoShutdown']",
    "equals": "enabled"
  },
  "then": {
    "effect": "DeployIfNotExists",
    "details": {
      "roleDefinitionIds": ["..."]
    }
  }
}

4.3. Ferramentas de automação

  • AWS Instance Scheduler: Solução gerenciada para schedules
  • Azure Automation: Runbooks para shutdown programado
  • Scripts customizados: Com cron jobs ou Cloud Scheduler (GCP)

5. Otimização de armazenamento e transferência de dados

5.1. Escolha do tier de armazenamento adequado

# Custos por GB/mês no AWS S3 (us-east-1)
Standard: $0.023
Infrequent Access: $0.0125
Glacier: $0.004
Glacier Deep Archive: $0.001

Migre dados não acessados há mais de 30 dias para tiers mais frios automaticamente.

5.2. Redução de custos com transferência de dados

  • Evite transferência entre regiões (custo de $0.01 a $0.09/GB)
  • Use VPC Peering ou PrivateLink para tráfego interno
  • Consolide workloads na mesma região

5.3. Uso de CDN e caching

CDNs como CloudFront (AWS) reduzem custos de saída de dados em até 70%.

# Custo de saída de dados do S3 (10 TB/mês)
Direto: 10.000 GB * $0.09 = $900
Com CloudFront: 10.000 GB * $0.085 = $850 + taxas de request
Economia adicional com cache: 30-50% menos requests de origem

6. Adoção de arquiteturas serverless e conteinerizadas

6.1. Quando migrar de VMs para funções serverless

Serverless é ideal para:
- Processamento por eventos (uploads, mensagens)
- APIs com tráfego variável
- Tarefas batch curtas (< 15 minutos)

# Comparação de custos mensais (1 milhão de execuções, 1s cada)
Lambda (1 GB): $1.67 + $0.20 por requests = $1.87
EC2 t3.nano (sempre ligada): $4.70/mês
Economia: 60%

6.2. Benefícios de custo com orquestração de containers

Clusters Kubernetes com auto-scaling pagam apenas pelos recursos utilizados.

# Cluster EKS com 3 nós t3.medium
Sob demanda: 3 * $30.24/mês = $90.72
Com auto-scaling (média 2 nós): $60.48
Economia: 33%

6.3. Comparação entre abordagens

  • VMs: Previsível, mas paga por capacidade ociosa
  • Containers: Mais eficiente, escala horizontalmente
  • Serverless: Pagamento por execução, ideal para workloads esporádicos

7. Monitoramento contínuo e alertas de anomalias de custo

7.1. Configuração de orçamentos e alertas

# AWS Budget via CLI
aws budgets create-budget \
  --account-id 123456789012 \
  --budget-name "Mensal-Infra" \
  --budget-type COST \
  --time-unit MONTHLY \
  --budget-limit Amount=10000,Unit=USD \
  --notifications-with-subscribers \
    Notification={NotificationType=ACTUAL,ComparisonOperator=GREATER_THAN,Threshold=80,ThresholdType=PERCENTAGE},Subscribers=[{Address=email@exemplo.com,SubscriptionType=EMAIL}]

7.2. Análise de tendências e detecção de picos

Configure alertas para:
- Aumento > 20% em relação ao mês anterior
- Gastos em serviços não autorizados
- Picos noturnos em ambientes de produção

7.3. Relatórios periódicos com foco em FinOps

# Relatório semanal de top 5 serviços por custo
Serviço          | Custo Semanal | % do Total | Tendência
EC2              | $1,234.56     | 45%        | ↑ 5%
S3               | $567.89       | 21%        | → 0%
RDS              | $345.67       | 13%        | ↓ 2%
Lambda           | $123.45       | 5%         | ↑ 10%
CloudFront       | $98.76        | 4%         | → 0%

Referências