Custo e faturamento

No Airframe, cada produto tem um único orçamento mensal, escrito uma vez na sua entrada do catálogo, e uma mudança que custaria mais que esse orçamento não pode fazer o merge. Esta página é o guia prático para conviver com essa regra: ler o preço que um merge request traz, aumentar o orçamento quando o produto precisa, colocar um produto na conta de faturamento ou tirá-lo dela, e acompanhar o que ele realmente gasta. Os motivos estão na página de FinOps.

Onde fica o orçamento

Onde: o repositório do catálogo, a entrada do produto, products/<journey>.<domain>.<context>.<product>.yaml, campo monthly_budget.

O valor é em dólares americanos por mês, produção e não produção juntas. O lint do catálogo verifica que os orçamentos de todos os produtos e espaços de teste ainda cabem no orçamento mensal da organização no catalog.yaml. Todo o resto lê a entrada: as regras de custo, os limites do painel de custos e os orçamentos do Google Cloud nos projetos do produto.

1. Leia o custo em um merge request

Quando um responsável aprova o merge request de um produto, o executor planeja cada raiz do produto, infra/np, infra/prod e infra/sandbox, calcula o preço de cada plano com o Infracost, e publica uma nota por raiz. As linhas de custo de uma nota são como na ilustração abaixo, que põe no formato de hoje os números do ensaio registrado da verificação de custo da plataforma, um banco de dados pequeno contra um orçamento de 20 dólares:

Cost: USD 27.27 a month, from USD 0 (delta USD 27.27,
no base to compare); budget USD 20. 5 usage-based and
3 unsupported resources are not in the number.

Abaixo vêm os recursos cujo custo mensal mudou, e o veredito das regras de custo:

WARN quando a mudança acrescenta mais de 10 dólares por mês ou mais de 25 por cento. A ideia é que precise da aprovação da equipe de plataforma, o que está projetado: hoje não impede nada.
FAIL quando essa raiz sozinha passa do orçamento.
Cost: not estimated quando não foi possível calcular o preço do plano. A mudança não é admitida sem preço.

O merge request também traz uma verificação de status chamada “Airframe cost”, que o controle de aprovação define quando o plano de cada raiz terminou. Ela passa só quando cada raiz tem preço e a soma está dentro do orçamento. Ela falha quando uma raiz é recusada, um plano falhou, uma raiz não tem preço, ou a soma passa do orçamento. Até ela passar, o GitLab mantém o merge fechado (aplicado: a configuração do projeto segundo a qual as verificações de status precisam passar). A recusa de uma soma nomeia o total, a parte de cada raiz e o que fica de fora; ela fica registrada nas execuções de plano e impressa no log do job do executor, enquanto cada nota dá o número de uma raiz.

2. Aumente o orçamento

Quando a verificação falha por custo, há duas saídas: deixar a mudança menor, ou aumentar o orçamento.

Onde: o repositório do catálogo. Mude monthly_budget na entrada do produto, em um merge request.
Quem aprova: um líder do domínio do produto, porque o valor sobe, mais um responsável pela entrada (a equipe do produto, os líderes do contexto ou os do domínio) que não seja o autor. A aprovação de um líder do domínio cobre as duas. Onde os líderes do domínio não têm conta no GitLab, a equipe de plataforma os substitui. Depois o controle de aprovação adiciona a sua (aplicado). Hoje essas aprovações são das próprias contas do mantenedor: o mecanismo está aplicado, mas a separação entre duas pessoas ainda não é real.
Se o lint disser que os produtos não cabem mais no orçamento da organização, aumentar esse orçamento no catalog.yaml é uma mudança separada, que a equipe de plataforma aprova duas vezes; hoje são duas das próprias contas do mantenedor.
Depois que o merge request do catálogo tiver o merge, aprove de novo o merge request do produto. A nova aprovação planeja e calcula o preço de cada raiz contra o orçamento novo, e a verificação é resolvida de novo.

O executor lê o orçamento da entrada do catálogo na main, nunca da cópia que fica dentro do repositório do produto.

3. Coloque um produto no faturamento

Os dois projetos de um produto novo existem sem faturamento, com as suas identidades e permissões. O pipeline dele planeja de verdade, e o apply para no primeiro serviço que precisa de faturamento.

Onde: landing-zone, a fábrica de projetos do domínio, roots/project-factory/<journey>-<domain>/variables.tf. Adicione o nome do produto a billed_products.
Quem aprova: a equipe de plataforma, e depois o controle de aprovação.
O próprio pipeline do landing-zone do merge aplica só a raiz da fábrica, porque um push na main aplica só as raízes cujo diretório mudou. A fábrica habilita os serviços do produto e cria um orçamento do Google Cloud em cada projeto a partir de monthly_budget: 70 por cento para produção e 30 para não produção, com alertas em 80 e 100 por cento.
A raiz de rede conecta os projetos à rede compartilhada em um pipeline posterior do landing-zone. Para um produto novo cuja entrada do catálogo tem o merge depois do faturamento, a cadeia de reconciliadores do catálogo o roda, como no ensaio da plataforma de 2026-09-20. Senão, rode o pipeline do landing-zone na main sob demanda. O GitLab deixa rodar um pipeline em uma main protegida só quem pode fazer merge nela: no landing-zone, os desenvolvedores e líderes da equipe de plataforma com conta no GitLab, e a conta de administração. Hoje são as próprias contas do mantenedor.
Inicie um pipeline novo na main do produto. As pessoas autorizadas a fazer merge no produto podem fazer isso. Esse pipeline aplica.

A cota de projetos. A conta de faturamento só pode vincular um número limitado de projetos, e cada produto ocupa dois. No momento em que isto foi escrito a cota é de quatorze, e os projetos da própria plataforma usam nove. Aumentá-la é um pedido ao Google, feito à mão pela conta de administração por um formulário no console do Google Cloud, e registrado com a resposta do Google no docs/bootstrap-log.md do landing-zone.

4. Tire um produto do faturamento

A ordem importa, porque o Google Cloud se recusa a desconectar um projeto enquanto algo nele ainda usa a rede compartilhada.

Pare antes o ambiente de execução do produto. O guia do ciclo de vida dos produtos do landing-zone dá a forma de parar um produto em funcionamento sem removê-lo: aposentá-lo, em um merge request do catálogo que define o ciclo de vida dele como retiring com um retire_after distante. Esse merge request leva o rótulo lifecycle e precisa de duas aprovações: uma da equipe e uma de um líder do domínio ou da equipe de plataforma; hoje as duas vêm das próprias contas do mantenedor. A aposentadoria leva os serviços dele a zero e retira as suas rotas.
Espere. O Cloud Run libera os endereços de rede que os seus serviços reservaram até duas horas depois que eles param, e até lá os projetos não podem sair da rede compartilhada.
Onde: landing-zone. Tire o produto de billed_products, em um merge request que a equipe de plataforma e o controle de aprovação aprovam. O próprio pipeline dele aplica só a raiz da fábrica.
Peça a alguém autorizado a rodar pipelines na main do landing-zone (seção 3, passo 4) que rode dois ali sob demanda: no primeiro, a fábrica libera os projetos e a raiz de rede os desconecta; no segundo, a fábrica desvincula o faturamento e remove o orçamento. O agendamento diário só planeja e nunca aplica.

Os projetos, as identidades, os segredos e as chaves ficam; os nomes de host param de responder. Os planos do pipeline continuam rodando e cada apply falha no primeiro serviço que precisa de faturamento. Enquanto o estado do Terraform do produto ainda tiver recursos que precisam de faturamento, os planos dele falham e a verificação de custo recusa todos os merge requests.

5. Acompanhe o gasto

O painel de custos. A pasta de cada produto no Grafana tem <product> cost: o acumulado do mês e a previsão contra monthly_budget, em laranja em 80 por cento e em vermelho em 100. Um job diário, cost:report, lê a exportação de faturamento e envia o custo de cada produto como métricas. Os números são o que o Google fatura, descontados os créditos. O platform cost da pasta da plataforma mostra a organização contra o seu orçamento. Veja Observabilidade.

Os orçamentos do Google Cloud. Cada projeto de produto faturado tem um orçamento a partir de monthly_budget. Hoje os alertas deles vão por e-mail aos administradores e usuários da conta de faturamento, o comportamento padrão do Google; chegar à equipe do produto está projetado. A conta de faturamento tem o seu próprio orçamento de 150 dólares por mês, que avisa o grupo de plataforma em 50, 80 e 100 por cento.

O que fica fora do número do merge request. A prévia, que é temporária; os recursos cobrados por uso, como as requisições, o tempo do Cloud Run, os backups e os dados de log; e os recursos a que o Infracost não dá preço. A nota conta os dois últimos. Os custos compartilhados da plataforma, como a borda e os runners, não pertencem a nenhum produto. O painel mostra o que foi realmente faturado.

Hoje nenhum produto da demo é faturado, então nenhum tem ainda séries de custo nem orçamentos de projeto.

Onde fica

No repositório control-plane:

No repositório landing-zone:

No repositório operations:

roots/cost/: a exportação de faturamento