A Cloud Está Cara: O Que Fazer Antes de Subir Seus Dados

A fatura chegou. AWS, GCP ou Azure — não importa qual. O número era o dobro do esperado. Acontece com quase todo mundo que sobe uma estrutura de dados na cloud sem planejamento. E o pior: o problema raramente está nos dados. Está nas decisões tomadas antes de subir qualquer coisa.

Este artigo é um guia prático. Vamos cobrir o que avaliar antes de subir um banco de dados, Data Lake, Data Warehouse ou Data Mart na nuvem — e quais boas práticas e scripts ajudam a manter o custo sob controle sem sacrificar performance.

⚠️ Antes de tudo: Cloud não é barata por padrão — é barata quando bem planejada. Mover dados para a cloud sem estratégia é trocar um problema local por uma fatura crescente todo mês.

1. Entenda o que você está subindo — e por quê

O primeiro erro é subir tudo. Dados históricos de 10 anos que ninguém consulta, logs de sistema que nunca foram analisados, backups que poderiam ficar on-premise. Cada gigabyte armazenado e cada query executada tem custo.

Antes de qualquer migração, responda:

Quem vai acessar esses dados? Frequência de acesso determina a classe de storage ideal.
Com que frequência? Dados acessados diariamente têm custo diferente de dados consultados uma vez por trimestre.
Qual SLA de disponibilidade você precisa? 99.999% é muito mais caro do que 99.9%.
Esses dados crescem quanto por mês? Projetar o crescimento evita surpresas na fatura.

💡 Regra prática: Classifique seus dados em três camadas antes de subir — Hot (acesso frequente), Warm (acesso mensal) e Cold (acesso raro ou apenas para compliance). Cada camada tem pricing diferente em todos os provedores.

2. Escolha a arquitetura certa para o seu caso

Não existe arquitetura universal. A escolha entre banco relacional, Data Lake, Data Warehouse ou Data Mart depende do volume, velocidade e variedade dos seus dados — e do que você precisa fazer com eles.

Banco de Dados Relacional na Cloud (RDS, Cloud SQL, Azure SQL)

Ideal para dados transacionais estruturados com alto volume de leituras e escritas. Cuidados principais: dimensionar corretamente a instância desde o início (oversizing é o erro mais caro), configurar auto-scaling com limites máximos definidos, e usar read replicas apenas quando realmente necessário — cada réplica é uma instância separada paga.

Data Lake (S3, GCS, Azure Data Lake)

Ideal para armazenar grandes volumes de dados brutos de múltiplas fontes. O Data Lake é barato para armazenar, mas caro para processar se mal estruturado. O maior vilão aqui é o full table scan — processar tabelas inteiras para extrair uma fração dos dados.

Data Warehouse (BigQuery, Redshift, Synapse)

Ideal para análises complexas sobre grandes volumes de dados históricos. Cada provedor tem um modelo de pricing diferente: BigQuery cobra por dados escaneados na query, Redshift cobra por instância ativa, Synapse cobra por DWU. Entender o modelo de cobrança do seu DW é obrigatório antes de escalar.

Data Mart

Subconjunto do DW focado em uma área de negócio. É a opção mais econômica para times que precisam de análises específicas sem acessar o DW inteiro. Sempre considere se um Data Mart resolve o problema antes de expandir o DW.

3. Boas práticas de custo antes de subir

Particionamento de tabelas

Particionar por data é a prática mais impactante em custo. Uma query filtrada por data em uma tabela particionada escaneia apenas as partições relevantes — reduzindo custo e tempo de execução em 80-95% em muitos casos.

-- BigQuery: criar tabela particionada por data
CREATE TABLE `projeto.dataset.eventos`
PARTITION BY DATE(created_at)
OPTIONS (
  partition_expiration_days = 365  -- expira dados após 1 ano
)
AS SELECT * FROM `projeto.dataset.eventos_raw`;

-- Redshift: criar tabela com distribuição e sort keys
CREATE TABLE fato_vendas (
  data_venda    DATE        NOT NULL,
  id_cliente    INTEGER     NOT NULL,
  valor         DECIMAL(10,2),
  ...
)
DISTKEY(id_cliente)
SORTKEY(data_venda);

-- DISTKEY define como os dados são distribuídos entre nós
-- SORTKEY otimiza filtros por data (o mais comum em análises)

Clustering e compressão

Clustering organiza fisicamente os dados no disco por colunas de alta cardinalidade usadas em filtros frequentes. Compressão reduz o tamanho dos dados armazenados e escaneados.

-- BigQuery: clustering por colunas de filtro frequente
CREATE TABLE `projeto.dataset.pedidos`
PARTITION BY DATE(data_pedido)
CLUSTER BY id_cliente, status
AS SELECT * FROM `projeto.dataset.pedidos_raw`;

-- Agora queries que filtram por id_cliente E status
-- escaneiam muito menos dados

Materialização estratégica de views

Views que são consultadas com alta frequência devem ser materializadas. Uma view comum re-executa a query toda vez que é acessada. Uma materialized view armazena o resultado e atualiza em intervalos definidos.

-- BigQuery: criar materialized view para KPIs diários
CREATE MATERIALIZED VIEW `projeto.dataset.mv_kpis_diarios`
OPTIONS (enable_refresh = true, refresh_interval_minutes = 60)
AS
SELECT
  DATE(created_at)        AS data,
  COUNT(*)                AS total_pedidos,
  SUM(valor)              AS receita_total,
  AVG(valor)              AS ticket_medio,
  COUNT(DISTINCT id_cliente) AS clientes_unicos
FROM `projeto.dataset.pedidos`
WHERE status = 'CONCLUIDO'
GROUP BY 1;

TTL e políticas de expiração

Dados não precisam ficar na cloud para sempre. Defina políticas de retenção desde o início — dados de mais de X anos vão para cold storage ou são deletados.

-- BigQuery: definir expiração em tabelas de log
ALTER TABLE `projeto.dataset.logs_aplicacao`
SET OPTIONS (
  expiration_timestamp = TIMESTAMP_ADD(
    CURRENT_TIMESTAMP(), INTERVAL 90 DAY
  )
);

-- S3 Lifecycle Policy (JSON para bucket de logs)
{
  "Rules": [{
    "ID": "MoverParaGlacier",
    "Status": "Enabled",
    "Transitions": [
      { "Days": 30,  "StorageClass": "STANDARD_IA" },
      { "Days": 90,  "StorageClass": "GLACIER" }
    ],
    "Expiration": { "Days": 365 }
  }]
}

4. Scripts de monitoramento de custo

Subir dados sem monitoramento de custo é pilotar sem painel. Configure alertas antes de colocar qualquer workload em produção.

BigQuery: identificar queries caras

-- Top 10 queries mais caras dos últimos 7 dias
SELECT
  user_email,
  ROUND(total_bytes_billed / POW(1024,3), 2)  AS gb_cobrados,
  ROUND(total_bytes_billed / POW(1024,3) * 5 / 1000, 4) AS custo_usd,
  query,
  creation_time
FROM `region-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECT
WHERE
  creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY)
  AND job_type = 'QUERY'
  AND state = 'DONE'
ORDER BY total_bytes_billed DESC
LIMIT 10;

BigQuery: estimar custo antes de executar

-- Use --dry_run para estimar custo sem executar
bq query --dry_run --use_legacy_sql=false \
'SELECT * FROM `projeto.dataset.tabela_grande`
 WHERE DATE(created_at) = "2026-06-01"'

# Saída: "Query successfully validated. Bytes processed: 2.1 GB"
# Custo estimado: 2.1 GB × $5/TB = ~$0.0105

Redshift: identificar queries lentas e caras

-- Queries com mais tempo de execução e I/O
SELECT
  q.userid,
  q.query,
  q.querytxt,
  q.starttime,
  DATEDIFF(seconds, q.starttime, q.endtime) AS segundos,
  s.rows,
  s.bytes / 1024 / 1024                      AS mb_lidos
FROM stl_query q
JOIN stl_scan s ON q.query = s.query
WHERE q.starttime >= DATEADD(day, -7, GETDATE())
ORDER BY segundos DESC
LIMIT 20;

Monitoramento de storage crescente (Python + boto3 para S3)

import boto3
from datetime import datetime, timedelta

def relatorio_custo_s3(bucket_name, prefixo=''):
    s3 = boto3.client('s3')
    cw = boto3.client('cloudwatch')

    # Tamanho atual do bucket
    response = cw.get_metric_statistics(
        Namespace='AWS/S3',
        MetricName='BucketSizeBytes',
        Dimensions=[
            {'Name': 'BucketName', 'Value': bucket_name},
            {'Name': 'StorageType', 'Value': 'StandardStorage'}
        ],
        StartTime=datetime.now() - timedelta(days=2),
        EndTime=datetime.now(),
        Period=86400,
        Statistics=['Average']
    )

    if response['Datapoints']:
        tamanho_gb = response['Datapoints'][-1]['Average'] / (1024**3)
        custo_mensal_usd = tamanho_gb * 0.023  # Standard: $0.023/GB/mês
        print(f"Bucket: {bucket_name}")
        print(f"Tamanho: {tamanho_gb:.2f} GB")
        print(f"Custo estimado/mês: ${custo_mensal_usd:.2f}")

relatorio_custo_s3('meu-data-lake')

5. Os 7 pontos críticos antes de subir qualquer estrutura

Classifique os dados por frequência de acesso antes de escolher a classe de storage. Não coloque tudo em Standard/Hot.
Defina particionamento desde a criação das tabelas. Retroativamente é muito mais caro e trabalhoso.
Configure budget alerts no provedor (AWS Budgets, GCP Budget Alerts, Azure Cost Alerts) com threshold em 80% do orçamento.
Estabeleça políticas de TTL/expiração para dados temporários, logs e dados de auditoria.
Evite SELECT * em tabelas grandes. Selecione apenas as colunas necessárias — em DWs colunar, isso reduz custo diretamente.
Use views materializadas para KPIs e dashboards de alto acesso em vez de re-computar a cada consulta.
Revise permissões de acesso — queries de usuários sem treinamento em otimização são uma fonte comum de custo inesperado.

🎯 Resumo executivo: 80% do custo desnecessário em cloud vem de três fontes — armazenamento mal classificado, queries sem particionamento e workloads superdimensionados. Endereçar esses três pontos antes de subir é o que separa uma migração de sucesso de uma fatura que assusta.

Conclusão: cloud é investimento, não despesa

Cloud bem planejada entrega elasticidade, disponibilidade e capacidade analítica que nenhuma infraestrutura on-premise consegue replicar com o mesmo custo total. O problema não é a cloud — é subir sem planejar.

O checklist é simples: classifique seus dados, particione suas tabelas, monitore desde o primeiro dia, e revise as queries antes de ir para produção. Feito isso, a fatura vai ser proporcional ao valor que você está extraindo.

Quer revisar sua arquitetura de dados na cloud?

A InForge faz diagnóstico de custo e performance em ambientes cloud — identificando onde você está pagando mais do que deveria e como otimizar.

Bruno Macedo

Dados & IA Corporativa

Especialista em estruturar dados e IA para empresas que querem crescer com inteligência — não com achismo.