S4 Metrics
Controle a cardinalidade de métricas do CloudWatch
Quando isso se paga?
Exemplo: US$ 5.000/mês em métricas customizadas do CloudWatch
Com US$ 5.000/mês em métricas customizadas do CloudWatch, uma redução conservadora de 60% equivale a cerca de US$ 3.000/mês de cobrança bruta de uso evitada — antes da taxa de software S4, EC2 e diferenças de workload.
Estime sua economia
Informe seu gasto ou uso mensal relevante para uma estimativa aproximada — sem upload de fatura.
Reduza sua conta de métricas customizadas do CloudWatch: controle a cardinalidade das métricas no ingest, depois gere baseline automaticamente e consolide economias em toda a sua AWS Organization.
S4 Metrics controla a cardinalidade de métricas customizadas do CloudWatch na borda de ingest — remove dimensões de alta cardinalidade, agrupa dimensões numéricas em buckets e agrega janelas ANTES do PutMetricData, para que você pague pelas séries de que precisa em vez de uma explosão sem limite. O coletor open-source metricsd (entrada StatsD/DogStatsD + OTLP/EMF/PutMetricData) faz o controle e emite para CloudWatch, além de um tee opcional de resolução completa para S3/Prometheus. A camada comercial adiciona auto-baseline e rollup consolidado do AWS Organizations.
O problema
O CloudWatch cobra métricas personalizadas por série temporal única (combinação de namespace + nome da métrica + valor da dimensão), onde as primeiras 10.000 séries custam $0.30 cada por mês em uma tarifa em camadas. Algumas dimensões de alta cardinalidade — user_id, request_id, path, instance_id — se multiplicam de forma combinatória em milhares de séries. O que infla a fatura não são os bytes ou o volume de requisições, mas essa explosão ilimitada de séries exclusivas.
Como funciona
- 1
Aponte a telemetria para o metricsd
Sobrescreva apenas o endpoint dos seus emissores StatsD/DogStatsD, OTLP, EMF ou PutMetricData para o coletor metricsd, deixando o código da aplicação intacto.
- 2
Defina uma baseline para suas dimensões mais caras
O auto-baseline escaneia sua conta em modo somente leitura via ListMetrics, classifica as dimensões por sua contribuição para a contagem de séries faturáveis e propõe um conjunto de regras de governança precificado.
- 3
Aplique governança antes do PutMetricData
Aplique as regras para fazer drop, rollup, bucket e agregação por janela das dimensões antes de emiti-las, para que apenas as séries que realmente valem a pena cheguem ao caminho de faturamento do CloudWatch.
Destaques
Controle de cardinalidade no ingest: drop / bucket / aggregate antes do PutMetricData.
Auto-baseline ranqueia suas dimensões mais caras e propõe um conjunto de regras com preço.
Rollup consolidado do AWS Organizations por meio de uma função cross-account READ-ONLY (somente ListMetrics).
O que está incluído
- Coletor de código aberto metricsd — ingestão de StatsD/DogStatsD, OTLP, EMF e PutMetricData, seguido de governança, agregação e envio para o CloudWatch.
- Mecanismo de governança — keep / drop / rollup / bucket / sample determinísticos nas dimensões, com agregação em janelas de 60 segundos e quantis DDSketch para que você pare de enviar uma série por requisição.
- Dry-run em dólares compatível com as camadas de preço — uma estimativa de antes/depois/economia precificada em relação às camadas do CloudWatch, a partir de um arquivo ou escaneamento em tempo real somente leitura via ListMetrics, antes de aplicar qualquer alteração.
- Proposta de regras de auto-baseline (comercial) — classifica as suas dimensões mais caras e gera um conjunto de regras precificado como YAML padrão do OSS.
- Consolidação de economia do AWS Organizations (comercial) — estimativas somente leitura, calculadas corretamente por camada de preço, por conta e para o total da organização.
- Tee opcional em resolução total — espelhe as dimensões descartadas para o S3 ou Prometheus remote-write para que nada seja jogado fora, apenas movido para fora do caminho de faturamento por série.
- Regras em YAML padrão do OSS — o metricsd de código aberto as lê diretamente, sem lock-in.
Casos de uso
Equipes cuja fatura de métricas personalizadas está fora de controle porque user_id, request_id ou path foram parar em uma métrica e explodiram em milhares de séries.
Organizações multicontas que precisam de uma visão consolidada e correta por camada de preço de onde estão os custos de cardinalidade.
Revisão de custos antes dos gastos — precifique um conjunto de regras candidato com o dry-run e compare a economia projetada com a tarifa da AMI antes de alterar qualquer coisa.
Equipes que precisam manter detalhes em resolução total para investigações, mas desejam removê-los do caminho de faturamento por série (tee S3 / Prometheus).
FAQ
Vou perder os dados que descartar?
Não. As dimensões descartadas podem ser direcionadas via tee em resolução total para o S3 ou Prometheus remote-write. Os detalhes não são excluídos, apenas movidos para um armazenamento que não é cobrado por série, permitindo que você leia o user_id de volta a partir do tee durante uma investigação.
Isso gera lock-in?
Não. Toda regra é um YAML padrão do OSS que o metricsd de código aberto lê de forma idêntica, e as propostas passam por uma validação completa (round-trip) no mecanismo do OSS antes de serem exibidas. Cancele a assinatura e seu coletor e regras continuarão funcionando sem alterações.
Como ele acessa minha conta com segurança e onde é executado?
A CLI comercial é estritamente somente leitura — cloudwatch:ListMetrics, organizations:ListAccounts, sts:AssumeRole — e nunca emite métricas ou altera sua conta. Os scans cross-account assumem uma função que você cria e que concede apenas ListMetrics, com um nome de sessão fixo para auditoria no CloudTrail. Tudo é executado em uma AMI dentro da sua própria VPC.
Quais inputs são suportados?
O metricsd ingere StatsD/DogStatsD (UDP), além de métricas OTLP, EMF e PutMetricData via HTTP. A migração requer apenas uma sobrescrita de endpoint.
Qual é a diferença entre a versão de código aberto e a comercial?
O coletor (ingest/govern/aggregate/emit) e o dry-run ciente de camadas são open-source Apache-2.0 metricsd. A camada comercial adiciona o auto-baseline ListMetrics que escreve regras para você, o rollup consolidado do AWS Organizations, um dashboard de economia e deploy de AMI/CloudFormation com um clique — construído sobre o core OSS, nunca um fork.
Por que é mais barato
Pressuposto: 100 mil séries temporais customizadas (com dimensões de alta cardinalidade) em us-east-1.
- Primeiras 10k séries (×$0,30)
- $3,000 / mês
- Próximas 90k séries (×$0,10)
- $9,000 / mês
- Total mensal
- $12,000 / mês
- Armazenamento S3 (Parquet agregado)
- $25 / mês
- Instância S4 Metrics (m5.large + taxa de software)
- $100 / mês
- Total mensal
- $125 / mês
Dimensionar a instância S4 Metrics conforme o número de séries
| Nº de séries | Instância recomendada | Custo da instância S4 Metrics | Total mensal vs. CloudWatch |
|---|---|---|---|
| ~10k | t3.medium | $45 / mês | $50 / mês (CWL $3.000, −98 %) |
| ~100k | m5.large | $100 / mês | $125 / mês (CWL $12.000, −99 %) |
| ~1M | m5.2xlarge | $310 / mês | $420 / mês (CWL $64.500, −99 %) |
Exemplo ilustrativo. As métricas customizadas do CloudWatch são cobradas em camadas (primeiras 10k séries $0,30, próximas 240k $0,10, depois $0,05 / $0,02). O S4 Metrics grava Parquet agregado no S3 e encaminha apenas um subconjunto quente ao CloudWatch. Se você mantiver 10k séries quentes, esse piso permanece, então a economia real varia entre 70–98 %.
Modelo de precificação
Taxa de software por hora + EC2 (classe t3 / m5). Medição por tipo de instância, opção anual disponível.
Outros produtos S4
S4 — Squished S3
Gateway transparente de compressão S3 com GPU
S4 Logs
Arquive CloudWatch Logs em S3 com zstd
S4 NAT
NAT com custo otimizado para Amazon VPC