# FinOps para IA Generativa: Dissecando o Padrão de Custo Bedrock no CUR 2.0

Com a disponibilização de metadados padronizados do Bedrock no AWS Data Exports, a atribuição de custos de IA generativa deixa de depender de parsing frágil de campos livres e passa a ter estrutura nativa no CUR 2.0. Neste artigo, disseço a anatomia desse padrão, os cenários onde ele resolve o problema de verdade e as armadilhas que ainda persistem quando a governança de IA não está alinhada ao pipeline de FinOps.

- URL: https://fernando.moretes.com/blog/finops-para-ia-generativa-dissecando-o-padrao-de-custo-bedrock-no-cur--aws-data-exp

- Markdown: https://fernando.moretes.com/blog/finops-para-ia-generativa-dissecando-o-padrao-de-custo-bedrock-no-cur--aws-data-exp/article.md?lang=pt

- Published: 2026-07-21T09:03:29.237Z

- Category: IA & Agentes

- Tags: finops, bedrock, cur2, aws-data-exports, cost-attribution, generative-ai, athena, governance

- Reading time: 9 min

- Source: [AWS Data Exports now provides standardized Amazon Bedrock product metadata](https://aws.amazon.com/about-aws/whats-new/2026/07/aws-data-exports-amazon-bedrock-product-metadata/)

---

Durante meses, equipes de FinOps em organizações que adotaram Amazon Bedrock enfrentaram o mesmo problema silencioso: o CUR 2.0 entregava linhas de custo para inferência de modelos, mas os campos de produto eram inconsistentes entre provedores, modalidades e modos de serving. A consequência prática era um pipeline de atribuição cheio de regex frágil, lógica de mapeamento manual e relatórios que divergiam a cada novo modelo lançado. Em 20 de julho de 2026, a AWS anunciou metadados padronizados do Bedrock no AWS Data Exports — e isso muda a geometria do problema. Não é uma feature menor: é a fundação que faltava para tratar gasto com IA generativa com a mesma disciplina que aplicamos a EC2 ou RDS há anos.

## O Problema Real: Custo de IA Generativa é Estruturalmente Diferente

Quando você gerencia custos de EC2, a unidade de medida é estável: horas de instância, com tipo, família e região como dimensões fixas. O modelo mental de FinOps funciona bem porque a granularidade do produto corresponde à granularidade do negócio. Com Bedrock, a realidade é outra. Um único workload de RAG pode gerar linhas de custo para tokens de entrada, tokens de saída, embeddings, chamadas de Knowledge Base e invocações de agentes — cada uma com um modelo diferente, de um provedor diferente, em um modo de serving diferente (On-Demand vs. Batch). Antes dessa mudança, o campo `product/productFamily` no CUR 2.0 não tinha um valor unificado para Bedrock, e atributos como nome do modelo e provedor estavam enterrados em colunas de mapa não estruturadas ou simplesmente ausentes para determinadas SKUs. O resultado era que equipes de engenharia precisavam manter tabelas de mapeamento externas, cruzando `lineItem/UsageType` com documentação de pricing que mudava a cada novo modelo. Em ambientes financeiros — onde chargeback por centro de custo não é opcional, é auditável — essa fragilidade era inaceitável. O custo não era apenas operacional: era de confiança. Relatórios de showback que divergem entre si corroem a credibilidade do time de plataforma junto às unidades de negócio, e em um contexto onde o gasto com IA generativa pode escalar de milhares para dezenas de milhares de dólares por mês em semanas, a falta de atribuição confiável se torna um risco financeiro real.

## Anatomia do Padrão: O Que Mudou Estruturalmente no CUR 2.0

O anúncio introduz cinco atributos padronizados que formam o núcleo do padrão. Três deles — `model_provider`, `model_name` e `inference_type` — estão disponíveis dentro da coluna `product` como um mapa JSON no CUR 2.0. O atributo `feature` (que representa o modo de serving: On-Demand ou Batch) também está nesse mapa. O `pricing_unit` é exposto como coluna direta. E, crucialmente, o `product/productFamily` agora retorna o valor unificado `"Amazon Bedrock"` para todas as SKUs do serviço, eliminando a fragmentação anterior onde diferentes tipos de uso apareciam com famílias de produto distintas ou inconsistentes.

O que isso significa em termos de query? Com Athena sobre o S3 bucket do Data Export, uma query de atribuição que antes exigia múltiplos `CASE WHEN` sobre `lineItem/UsageType` agora pode ser escrita de forma limpa:

```sql
SELECT
  line_item_usage_account_id,
  product['model_provider']        AS model_provider,
  product['model_name']            AS model_name,
  product['inference_type']        AS inference_type,
  product['feature']               AS serving_mode,
  pricing_unit,
  SUM(line_item_unblended_cost)    AS total_cost,
  SUM(line_item_usage_amount)      AS total_usage
FROM cur2_export
WHERE product_family = 'Amazon Bedrock'
  AND line_item_line_item_type = 'Usage'
GROUP BY 1,2,3,4,5,6
ORDER BY total_cost DESC;
```

A query acima é direta, auditável e não depende de nenhuma lógica externa. Para ambientes com múltiplas contas (AWS Organizations), o padrão se compõe naturalmente com a consolidação de CUR no nível de management account, onde a coluna `line_item_usage_account_id` permite o chargeback por conta sem lógica adicional. O fato de os campos serem disponibilizados por padrão, sem custo adicional, elimina a decisão de opt-in que frequentemente atrasa a adoção em organizações com processos de aprovação lentos.

## Pipeline de Atribuição de Custos Bedrock via CUR 2.0

Fluxo completo desde a geração de custo no Bedrock até o chargeback por centro de custo, mostrando os campos padronizados como eixo central do padrão.

### 🤖 AI Workloads

- RAG App Knowledge Base (ai)
- Bedrock Agent On-Demand (ai)
- Batch Inference Job (ai)

### 💰 Billing Engine

- CUR 2.0 product map column (data)
- Standardized Fields model_provider · model_name inference_type · feature pricing_unit (security)

### 🪣 Storage & Query

- S3 Bucket Data Export (Parquet) (storage)
- Glue Crawler Schema catalog (data)
- Athena SQL attribution query (compute)

### 📊 FinOps Consumers

- QuickSight Showback dashboard (frontend)
- Data Warehouse Chargeback ETL (storage)
- CloudWatch Cost anomaly alert (messaging)

### Fluxos

- rag -> cur2: gera linha de custo
- agent -> cur2: gera linha de custo
- batch -> cur2: gera linha de custo
- cur2 -> fields: product map column
- fields -> s3: export diário/horário
- s3 -> glue: crawl schema
- glue -> athena: catálogo
- s3 -> athena: query direta
- athena -> qs: showback
- athena -> dw: chargeback ETL
- athena -> alert: anomalia de custo

## Quando Usar Este Padrão — e Por Que Ele Importa em Ambientes Financeiros

Este padrão é o caminho correto quando sua organização tem três condições simultâneas: (1) uso ativo de Amazon Bedrock com múltiplos modelos ou provedores, (2) necessidade de chargeback ou showback por unidade de negócio, produto ou centro de custo, e (3) volume de gasto com IA generativa que justifica governança formal — na prática, qualquer ambiente onde o gasto mensal com Bedrock ultrapasse alguns milhares de dólares ou onde existam SLAs de custo acordados com stakeholders internos.

Em ambientes financeiros regulados, a atribuição de custo não é apenas operacional — ela é parte da auditoria de controles internos. Se sua organização opera sob SOX, PCI-DSS ou frameworks equivalentes, a rastreabilidade de gasto por sistema, por produto e por responsável técnico é um requisito de controle, não uma conveniência. O padrão de CUR 2.0 com metadados padronizados do Bedrock satisfaz esse requisito de forma nativa, sem a necessidade de sistemas auxiliares de rastreamento.

O padrão também se encaixa bem em arquiteturas de Data Mesh onde o domínio de plataforma de IA é tratado como um data product com SLOs de custo. Nesse contexto, os campos `model_name` e `inference_type` funcionam como dimensões de partição natural para queries de custo por domínio consumidor. A granularidade de `inference_type` — que distingue tokens de entrada de tokens de saída — é particularmente valiosa porque o perfil de custo de um modelo varia significativamente dependendo da proporção input/output do workload. Um agente que gera respostas longas tem um perfil de custo completamente diferente de um classificador que processa documentos grandes mas retorna labels curtos.

Para organizações que já usam AWS Cost Anomaly Detection, o campo `product_family = 'Amazon Bedrock'` agora funciona como filtro confiável para criar monitores de anomalia específicos para IA generativa, sem o risco de falsos positivos causados por SKUs mal classificadas anteriormente.

## Antes vs. Depois: Atribuição de Custos Bedrock no CUR 2.0
| Critério | Dimensão | Antes (pré-Jul/2026) | Depois (metadados padronizados) |
| --- | --- | --- | --- |
| Identificação do modelo | Inferido via regex em lineItem/UsageType | product['model_name'] — campo direto e estável | — |
| Provedor do modelo | Ausente ou inconsistente entre SKUs | product['model_provider'] — padronizado | — |
| Tipo de inferência | Não disponível como campo estruturado | product['inference_type'] (input/output tokens) | — |
| Modo de serving | Codificado em UsageType, sem semântica explícita | product['feature'] (On-Demand / Batch) | — |
| Família de produto | Fragmentada entre tipos de uso | Unificada como 'Amazon Bedrock' | — |
| Manutenção de mapeamento | Tabela externa, atualização manual a cada novo modelo | Zero — campos nativos, atualizados pela AWS | — |

## Design de Referência: Pipeline de FinOps para IA Generativa em Escala

Um pipeline de FinOps para Bedrock em produção vai além de uma query Athena ad-hoc. O design de referência que eu recomendo tem quatro camadas: ingestão, enriquecimento, atribuição e ação.

**Ingestão**: Configure o AWS Data Export com granularidade horária (não diária) para ambientes onde o gasto pode escalar rapidamente. O export deve ser entregue em formato Parquet com compressão Snappy para um bucket S3 dedicado, com particionamento por `year/month/day/hour`. Use S3 Object Lock no modo Compliance com retenção de 7 anos para satisfazer requisitos de auditoria financeira. A política de bucket deve restringir acesso ao role do Data Export e ao role de leitura do pipeline de FinOps, com condição `aws:SourceAccount` para prevenir confused deputy.

**Enriquecimento**: Um Glue Crawler com agendamento horário mantém o catálogo atualizado. A tabela resultante no Glue Data Catalog deve ter as colunas do mapa `product` explicitamente mapeadas como `product_model_provider`, `product_model_name`, etc., via um Glue ETL job que normaliza o mapa JSON em colunas tipadas — isso reduz o custo de scan do Athena em 40-60% comparado a queries que fazem extração de mapa em tempo de execução. Para organizações com múltiplas contas, o export consolidado no management account já inclui `line_item_usage_account_id`, mas adicione uma tabela de enriquecimento que mapeia account ID para nome de time, produto e centro de custo — essa tabela é o ativo de governança mais valioso do pipeline.

**Atribuição**: Views materializadas no Athena (ou tabelas CTAS atualizadas diariamente) para os três cortes principais: por modelo/provedor, por conta/time e por modo de serving (On-Demand vs. Batch). O corte por `inference_type` é especialmente útil para otimização: se o custo de output tokens domina, o workload é candidato a prompt compression ou caching. Se o custo de input tokens domina com contextos longos, é candidato a Batch inference, que tipicamente oferece desconto significativo sobre On-Demand.

**Ação**: Integre as views com AWS Cost Anomaly Detection usando filtros em `product_family = 'Amazon Bedrock'` e `product['model_name']` para alertas granulares. Para chargeback automatizado, um Step Functions workflow diário pode ler as views Athena, calcular alocações por centro de custo e publicar no sistema de billing interno via API.

## Armadilhas que Persistem — O Que Este Padrão Não Resolve

- **Atribuição sem tags de aplicação**: Os metadados padronizados identificam o modelo e o tipo de inferência, mas não o sistema de negócio que fez a chamada. Se suas invocações do Bedrock não passam por um proxy ou gateway que injeta tags de custo (via resource tags ou cost allocation tags no nível da conta), você terá visibilidade de 'quanto gastamos com Claude 3.5 Sonnet' mas não de 'qual
- **Granularidade de request-level**: O CUR 2.0 agrega custos por período de billing, não por invocação individual. Para rastreabilidade de custo por usuário final, sessão ou transação, você ainda precisa de instrumentação no nível da aplicação — por exemplo, capturar tokens consumidos por request via CloudWatch custom metrics ou OpenTelemetry e correlacionar com o custo unitário do modelo.
- **Latência do export**: O AWS Data Export tem latência de entrega que pode chegar a 24 horas para dados diários e algumas horas para dados horários. Para alertas de custo em tempo quase real, o CUR não é a fonte correta — use AWS Cost Anomaly Detection com notificações SNS, que opera sobre dados de billing com latência menor.
- **Custos de infraestrutura associados**: O padrão cobre o custo direto de inferência do Bedrock, mas workloads de RAG têm custos associados em outros serviços — S3 para armazenamento de documentos, OpenSearch Serverless ou Aurora para o vector store, Lambda para orquestração.
- **Dependência de export único sem validação**: Times que constroem pipelines de chargeback sobre o CUR sem validação cruzada com AWS Cost Explorer ou com o billing dashboard da conta correm o risco de discrepâncias causadas por créditos, refunds ou ajustes de billing que aparecem como linhas separadas.

> **Configure Cost Allocation Tags Antes de Escalar o Uso do Bedrock:** Os metadados padronizados do CUR 2.0 resolvem a dimensão 'o que' (qual modelo, qual tipo de inferência), mas a dimensão 'quem' (qual time, produto ou aplicação) ainda depende de cost allocation tags ativadas no nível da conta AWS. Ative as tags `Environment`, `Application`, `CostCenter` e `Team` no AWS Billing Console antes de onboarding de novos workloads Bedrock. Tags não ativadas não aparecem no CUR e não podem ser retroativamente aplicadas a dados históricos — o custo de não fazer isso no início é perda permanente de rastreabilidade.

## Segurança e Governança do Pipeline de FinOps

Um pipeline de FinOps que contém dados de custo detalhados por modelo e por conta é, em si, um ativo sensível. Em ambientes financeiros, a visibilidade de quanto cada time gasta em quais modelos de IA pode ser informação competitiva ou regulatória. O design de segurança do pipeline precisa ser tratado com o mesmo rigor que dados de negócio.

Para o bucket S3 que recebe o export, aplique: criptografia SSE-KMS com uma CMK dedicada ao pipeline de FinOps (não a chave padrão da conta), política de bucket com `aws:SecureTransport: true` para forçar HTTPS, bloqueio de acesso público habilitado em todas as quatro dimensões, e S3 Object Lock em modo Compliance para imutabilidade de registros de auditoria. O IAM role usado pelo Glue Crawler e pelo Athena para leitura deve ter permissão apenas de `s3:GetObject` e `s3:ListBucket` no bucket específico, com condição `s3:prefix` restringindo acesso ao prefixo do export — nunca conceda `s3:*` ou acesso ao bucket inteiro.

Para o Athena, habilite workgroup com resultado de query criptografado em S3 com a mesma CMK, e configure `EnforceWorkGroupConfiguration: true` para prevenir que queries ad-hoc de usuários individuais contornem a configuração de segurança. Use IAM conditions `athena:WorkGroup` para restringir quais roles podem executar queries no workgroup de FinOps.

No nível organizacional, considere que o export consolidado do management account contém dados de todas as contas filhas. O acesso a esse export deve ser restrito ao time de FinOps central, com views separadas por conta expostas via Lake Formation para times de engenharia individuais — isso implementa o princípio de least privilege sem duplicar os dados. CloudTrail com filtro em `s3:GetObject` no bucket do export e em queries Athena no workgroup de FinOps fornece o audit trail necessário para demonstrar controle de acesso em auditorias.

## Lente Well-Architected: Pipeline de FinOps para Bedrock

- **security**: CMK dedicada para o bucket S3 do export; IAM roles com least privilege e condições s3:prefix; S3 Object Lock Compliance para imutabilidade; Lake Formation para controle de acesso granular por conta em ambientes multi-account.
- **reliability**: Export horário com validação de reconciliação diária contra AWS Cost Explorer; Glue Crawler com retry automático e alarme CloudWatch em falha de crawl; particionamento S3 por hora para limitar o impacto de reprocessamento.
- **performance**: Glue ETL job normalizando o mapa JSON em colunas tipadas reduz custo e latência de scan Athena em 40-60%; workgroup Athena com limite de scan por query para prevenir queries não otimizadas de consumir TB de dados.

> **Nota do Arquiteto:** Na prática, o maior obstáculo para FinOps de IA generativa não é técnico — é organizacional: times de engenharia que provisionam workloads Bedrock sem coordenar com o time de plataforma, resultando em contas sem tags e pipelines de custo cegos. O que eu faria em qualquer organização que está escalando uso de Bedrock é simples: antes de qualquer otimização de query ou dashboard, garanta que as cost allocation tags estejam ativadas e que exista um processo de onboarding que inclua verificação de tags como gate de deploy. Os metadados padronizados do CUR 2.0 são uma fundação excelente, mas fundação só tem valor se a governança organizacional está construída sobre ela. A lição que aprendi da forma mais cara é que dados de custo sem dimensão de 'quem' são apenas ruído — você sabe que está gastando, mas não sabe onde agir.

## Veredicto: Adote, Mas Não Pare Aqui

Os metadados padronizados do Bedrock no AWS Data Exports são uma mudança genuinamente útil que elimina uma classe inteira de trabalho de manutenção em pipelines de FinOps. O padrão é sólido: campos estáveis, sem custo adicional, compostos naturalmente com a infraestrutura existente de CUR 2.0 e Athena. Para qualquer organização com uso ativo de Bedrock e necessidade de chargeback ou showback, a adoção é direta e o ROI é imediato — a redução de manutenção de tabelas de mapeamento manuais sozinha justifica a migração. O que este padrão não resolve — e onde a maioria das organizações vai tropeçar — é na dimensão de atribuição por aplicação e por usuário, que ainda depende de disciplina de tagging e instrumentação no nível da aplicação. Minha recomendação: adote o padrão de CUR 2.0 com metadados Bedrock como fundação, combine com cost allocation tags ativadas e um Glue ETL job que normaliza o mapa de produto em colunas tipadas, e trate a atribuição por request como um problema separado a ser resolvido com OpenTelemetry e métricas customizadas no CloudWatch. A fundação está finalmente disponível — o que você constrói sobre ela é sua responsabilidade.

**Rating:** Adopt

## Referências

- [AWS What's New: AWS Data Exports now provides standardized Amazon Bedrock product metadata (Jul 20, 2026)](https://aws.amazon.com/about-aws/whats-new/2026/07/aws-data-exports-amazon-bedrock-product-metadata/)
- [AWS Data Exports – Product Overview](https://aws.amazon.com/aws-cost-management/aws-data-exports/)
- [AWS Data Exports User Guide – Product columns (CUR 2.0)](https://docs.aws.amazon.com/cur/latest/userguide/table-dictionary-cur2-product.html)
- [Amazon Bedrock – Product Page](https://aws.amazon.com/bedrock/)
- [AWS Cost Anomaly Detection – User Guide](https://docs.aws.amazon.com/cost-management/latest/userguide/getting-started-ad.html)
- [AWS Lake Formation – Column-level security for Athena](https://docs.aws.amazon.com/lake-formation/latest/dg/column-level-security.html)
- [FinOps Foundation – FinOps for AI/ML Workloads](https://www.finops.org/)
- [AWS Blog – Querying AWS Cost and Usage Reports with Amazon Athena](https://aws.amazon.com/blogs/aws-cost-management/querying-your-aws-cost-and-usage-report-using-amazon-athena/)