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

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.

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:

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.

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.

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.

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.