AWS Billing Conductor e Billing Transfer passam a alimentar custom billing views

O que mudou

A AWS passou a permitir que billing group views do AWS Billing Conductor e views do AWS Billing Transfer sejam usadas como source views dentro de uma custom billing view. Antes, cada billing group e cada relação de transfer gerava sua própria visão isolada, mantida automaticamente pela AWS; não havia como combiná-las num único recurso de relatório.

Uma custom billing view é um recurso com ARN próprio que agrega, filtra e compartilha dados de custo. Ela aparece no AWS Cost Explorer, no AWS Budgets e no console do AWS Billing and Cost Management, e pode ser compartilhada com outras contas via AWS Resource Access Manager (RAM).

O detalhe que importa para quem revende AWS ou rateia custo entre unidades: o AWS Billing Conductor gera uma billing group view por grupo configurado, com o preço customizado que você definiu para ele. Já o AWS Billing Transfer gera duas views por relação de transferência: uma My view, com o que a conta de bill transfer deve pagar à AWS, e uma Showback/Chargeback view, com o valor configurado para repassar ao cliente final. Agora dá para apontar uma custom billing view para várias dessas views de uma vez.

O exemplo que a própria AWS usa no anúncio ilustra o caso de uso: a AnyCompany Distribution revende AWS para centenas de clientes finais pela conta de bill transfer 111122223333. O time de billing operations cria uma view chamada total-customer-cost, somando todas as My views (o que a empresa paga à AWS), e outra chamada total-customer-billings, somando todas as Showback/Chargeback views (o que ela cobra dos clientes). As duas ficam lado a lado no seletor de billing views do Cost Explorer, agrupáveis por serviço, conta ou mês.

Onde está disponível

Segundo a AWS, o recurso está disponível em todas as regiões comerciais da AWS ("all commercial AWS Regions"), o que inclui a região América do Sul (São Paulo), sa-east-1. Vale o aviso de praxe: billing views é uma camada de reporting operada a partir da management account da organização, não um serviço que roda dentro de uma região específica de workload, mas o console e as APIs envolvidas estão liberados nela.

Três pré-requisitos precisam estar resolvidos antes de criar a view:

• A conta precisa usar as ações fine grained do AWS Cost Management, já ativas por padrão em contas standalone e em organizações criadas a partir de 6 de março de 2023; organizações mais antigas rodam os scripts de bulk policy migrator pela management account.
• Para compartilhar uma view, o principal IAM usado na management account precisa de permissão para criar e compartilhar recursos no AWS RAM; contas-membro que recebem a view não precisam de permissão extra, mas destinatários fora da organização precisam poder aceitar convites do RAM.
• Para que contas-membro abram a view compartilhada no Cost Explorer, a management account precisa ter concedido a elas acesso ao Cost Explorer.

Quanto custa

A fonte não traz um modelo de preço específico para o uso de billing group views ou billing transfer views como source views de uma custom billing view, nem menciona cobrança adicional por criar, associar fontes ou compartilhar uma view via RAM. O anúncio também não compara esse custo com o de manter um pipeline próprio (por exemplo, exportar o Cost and Usage Report e somar as views manualmente em planilha ou data warehouse), caminho que o texto da AWS cita como o que esse recurso substitui.

Para o gestor de TI que está avaliando a mudança, o ponto prático é que o preço do AWS Billing Conductor e do AWS Billing Transfer em si (por conta monitorada, por relação de transferência) continua sendo o já contratado; o que muda aqui é só a camada de consolidação do relatório.

Como começar

No console, o caminho é: AWS Billing and Cost Management > Cost Management Preferences > aba Billing View > Create multi-source view. Na criação, selecione as My views de Billing Transfer (ou as billing group views do Billing Conductor) que vão compor a view, escolha o filtro (sem filtro para trazer tudo, ou filtro por Accounts ou por cost allocation tags) e dê um nome, como total-customer-cost. A AWS valida a view de forma assíncrona; quando termina, ela fica "healthy" e disponível em qualquer lugar que suporte custom billing views.

Para compartilhar, na aba Billing View selecione a view e escolha Share view, depois Within AWS organization (para contas-membro) ou With any account (informando o ID de 12 dígitos de uma conta externa), selecione uma permissão gerenciada e confirme. Dentro da organização o acesso é imediato; fora dela, o destinatário precisa aceitar o convite no AWS RAM antes de a view aparecer para ele.

Não há API nova para aprender: CreateBillingView, AssociateSourceViews e DisassociateSourceViews passaram a aceitar ARNs de billing group e billing transfer views, além das views primárias e customizadas já suportadas. Cada chamada de AssociateSourceViews aceita até 10 ARNs; o console divide automaticamente quando o conjunto de fontes é maior. Para checar as fontes por trás de uma view existente, o comando é:

aws billing list-source-views-for-billing-view \
--arn "arn:aws:billing::111122223333:billingview/custom-total-customer-cost"

O que muda para quem já usa

Quem já opera AWS Billing Conductor para ratear custo entre unidades de negócio, ou já é parceiro de revenda com AWS Billing Transfer, ganha uma forma de consolidar relatórios sem montar pipeline. Antes, somar dezenas (ou centenas) de billing groups ou relações de transferência exigia exportar dados e tratar fora da AWS; agora o agregado vive dentro do próprio Cost Explorer, com ARN e permissões próprias.

Para quem fecha a fatura em reais com o cliente final, o ganho prático está em comparar duas views lado a lado, no mesmo grão (serviço, conta, mês): total-customer-cost mostra o que a empresa pagou à AWS pelo conjunto de clientes, total-customer-billings mostra o que cobrou deles pelos preços configurados no Billing Conductor. É a conta que a controladoria faz todo mês para calcular margem por cliente, agora sem precisar reconciliar planilha com dois sistemas de origem.

O crescimento da carteira também fica mais simples: ao onboardar um novo cliente, a boa prática é adicionar a nova billing transfer view à view agregada existente via AssociateSourceViews, e o relatório mensal já nasce com o novo cliente dentro, sem reconstrução. Um AWS Budget criado sobre a view agregada também passa a alertar sobre o gasto total transferido, em vez de monitorar relação por relação.

Fica em aberto uma limitação que vale registrar antes de migrar o relatório principal para uma custom billing view: ela suporta granularidade mensal e diária, mas granularidade por hora, AWS Cost Anomaly Detection e recomendações de rightsizing continuam disponíveis só na billing view primária. Quem depende de alerta de anomalia em tempo quase real precisa manter esse monitoramento na view primária e usar a custom view só para o relatório consolidado de chargeback.

Fonte: AWS Cloud Financial Management Blog